Follow-the-Sun開発：Hamburg + Ho Chi Minh City = 24時間エンジニアリングの実現

欧州チームが業務を終えても、スプリントを止める必要はありません。Follow-the-Sun開発は、タイムゾーンをまたいで生産的なエンジニアリング時間を拡張し、誰にも通常業務時間外の勤務を強いることなく、デリバリーサイクルを短縮します。ヘッドカウントを増やさずにリリース速度を上げる必要がある企業にとって、これは分散型ソフトウェア開発において最も活用されていないモデルの一つです。

課題は、このモデルを運用していると主張するチームの多くが、実際には運用できていない点にあります。このモデルが実際に何を必要とするか、そしてGradionがHamburgとHo Chi Minh Cityの間でどのように運用しているかをご説明いたします。

Follow-Sunソフトウェア開発とは何か？

Follow-the-Sun（FTS）は、Carmel、Espinosa、Dubinskyの言葉を借りると——このモデルの学術的基盤を確立した研究者たちですが——市場投入までの時間を短縮することを目的として設計された、グローバルナレッジワークフローの一形態です。各拠点が業務を終えるたびに、地理的に分散したチーム間で作業が引き継がれます。受け取るチームはそのまま作業を継続し、開発は止まりません。

2拠点の場合、生産時間は1日16時間に拡張されます。3拠点では24時間になります。IBMが1990年代半ばにこのアプローチを先駆けて取り入れました。最初の試みは失敗しました——アイデア自体が間違っていたわけではなく、日次ハンドオフが一貫して実行されなかったためです。

これが、ほとんどの解説が見落としている洞察です。Follow-the-Sunはタイムゾーンの配置ではありません。それは規律です。タイムゾーンは前提条件です。規律こそが成果をもたらします。

なぜHamburgとHo Chi Minh Cityなのか？

Hamburgは冬季にCET（UTC+1）、夏季にCEST（UTC+2）で稼働します。Ho Chi Minh Cityは通年ICT（UTC+7）で稼働します。時差は夏季に5時間、冬季に6時間です。

GradionはCairoにもエンジニアリングハブを運営しています。エジプトは通年EET（UTC+2）で稼働しており、2011年に夏時間が廃止されました。これによりCairoはHamburgと同じタイムゾーン帯に位置します。夏季は同一、冬季はCairoが1時間先行します。

FTSの観点から見ると、HamburgとCairoは合わせて一つの西側アンカーを形成します——独立した2つの中継点ではありません。両都市は欧州とMENAの午前の時間帯を共有し、西側の総合的なエンジニアリング能力を強化し、GradionのMENA市場へのカバレッジを拡大します。欧州とMENAがクローズすると、作業はHCMCへ東に引き継がれ、翌朝には西側チームへと戻ります。

これにより自然なオーバーラップウィンドウが生まれます。HamburgとCairoは現地時間09:00に業務を開始します。HCMCはICT14:00——午後の本格稼働中です。09:00から11:00 CETの構造化された同期セッションにより、双方が共通の文脈を持ちます。その後、西側チームがハンドオフを行い、HCMCが作業を夕方まで継続します。

HCMCが18:00 ICTにクローズする頃、Hamburgは翌日の12:00〜13:00 CETにあたります。完了した作業が待っています。レビューが始まります。サイクルが続きます。

16時間の生産的なエンジニアリング時間。誰も通常時間外に働かなくてよい。英雄的な努力も不要です。

ここにGradionの拠点配置が単なるタイムゾーンの計算を超えた深い意味を持つ理由があります。Hamburgはドイツエンジニアリングの厳格さをもたらします——構造化されたアーキテクチャ上の意思決定、規律ある文書化、精密なハンドオフ基準。CairoはMENA市場への近接性とエンジニアリングの厚みを西側アンカーに加えます。HCMCはデリバリー速度をもたらします——高いアウトプット量、迅速なイテレーション、スピードを出せるよう構築されたシニアエンジニアリングチーム。まとめると、これらは単により多くの時間をカバーするだけではありません。より広い領域をカバーしているのです。

実際に機能させるために必要なこと

Kroll et al.（2013）はFollow-the-Sun実装における36のベストプラクティスをレビューしました。その結論：ハンドオフの質が最も重要な単一要因です。コンテキスト転送の不備こそがFTSが機能しなくなる原因であり——タイムゾーンの差や文化的な違いではありません。

実際に機能するFTSワークフローには、4つの要件があります：

構造化されたハンドオフドキュメント。拠点間で引き継がれるすべてのタスクには、現在の状態、未解決のブロッカー、行われた意思決定、および次に必要なアクションが含まれていなければなりません。タイムゾーンをまたいだ口頭でのハンドオフはハンドオフではありません。それは数時間のコストを招く思い込みです。

固定されたオーバーラップ時間。オーバーラップウィンドウは進捗の確認のためではありません。それはアラインメントのためです。ブロッカーを解消し、優先事項を確認し、受け取りチームがサポートなしに作業する前に曖昧さを排除する場です。Gradionでは、このウィンドウは固定されています——柔軟ではありません。

非同期優先のコミュニケーション。オーバーラップウィンドウ外では、両チームが非同期で稼働します。意思決定はライブの会話を待てません。ドキュメント、非同期のPRレビュー、書面によるアーキテクチャ上の意思決定はオーバーヘッドではありません。それがオペレーティングシステムなのです。

継続的デリバリーインフラ。自動化されたパイプライン、共有環境、テストカバレッジは交渉の余地がありません。Hamburgチームだけが実行方法を知っているビルドは、HCMCがそれを必要とするたびに6時間の遅延を招きます。

Follow-the-Sunではないもの

FTSはしばしば主張されますが、実際に実践されることはまれです。Treinen and Miller-Frost（2006）は、IBM Systems Journalのケーススタディにおいて、FTS実装の成功例と失敗例の両方を記録しました。最も一般的な失敗：チームが順次ではなく並行して作業していたこと。両拠点が稼働していました。しかし、どちらも相手の成果物の上に積み上げていませんでした。結果として、重複、マージコンフリクト、タイムゾーンの優位性を完全に消し去る調整オーバーヘッドが生じました。

自社モデルをFollow-the-Sunと称しながらハンドオフプロセスを説明できないベンダーは、FTSを運用していません。より洗練されたポジショニングを持つ分散チームを運営しているだけです。

この違いが異なる成果をもたらします。並行分散開発はキャパシティをスケールします。Follow-the-Sun開発はスピードをスケールします。一方はエンジニアを増やします。もう一方はカレンダーを圧縮します。

Gradionモデルの実践

GradionのセットアップはFTS原則に基づいて最初から設計されました——既存の構造に後付けしたものではありません。

Hamburgチームはクライアントとの関係、アーキテクチャ上の意思決定、スプリントのオーナーシップを担います。Cairoは西側アンカーを強化し——同じタイムゾーン帯内でエンジニアリングの厚みとMENA市場カバレッジを拡張します。HCMCはリソースプールではなく、完全なデリバリーパートナーとして主要なエンジニアリングボリュームを担います。

ハンドオフは書面で文書化されます。オーバーラップウィンドウは保護されます。非同期コミュニケーションはデフォルトであり、代替手段ではありません。

クライアントにとって、これは17:00 CETに解消されたブロッカーが翌朝09:00まで待たされないことを意味します。その夜にHCMCで対応されます。HamburgとCairoが業務を開始する頃には、成果物が用意されています。

スプリントを通じて、四半期を通じて、その短縮は計測可能です。それはまた、このモデルが大規模でのデリバリーリスクを軽減するために、地理的条件だけでなくガバナンスを必要とする理由でもあります。

Follow-the-Sunベンダーへの確認事項

ベンダーが本当にFTSベースで運用しているかどうかを評価する際は、3つの質問をお聞きください：

1. 業務終了時に拠点間で作業をどのように文書化し、引き継ぎますか？ハンドオフ成果物はどのようなものですか？
2. 固定されたオーバーラップウィンドウはいつで、誰が参加を求められますか？
3. ハンドオフ後に発生したブロッカーはどのように対処しますか？

3つすべてに具体的に答えられるベンダーはこのモデルを運用しています。タイムゾーンの広がりは説明できてもハンドオフプロセスを説明できないベンダーは運用していません。

Follow-the-Sun開発はオペレーティングモデルの意思決定です。地理的条件がそれを可能にします。規律がそれを機能させます。

参考文献

• Carmel, Espinosa & Dubinsky (2010), Follow-the-Sun Software Development, Journal of Management Information Systems
• Treinen & Miller-Frost (2006), IBM Systems Journal — successful and failed FTS case studies
• Kroll et al. (2013), systematic literature review — 36 FTS best practices identified
• Wikipedia — Follow-the-sun (citing Carmel, Dubinsky & Espinosa, 2009, Hawaii International Conference on System Sciences)
• Timezone offsets: CET UTC+1, CEST UTC+2, EET UTC+2 year-round (Egypt abolished DST 2011), ICT UTC+7