Follow-the-Sun デリバリー — 3拠点同期で24/7納品、燃え尽きなし。

Follow-the-Sun デリバリーは、スライドに貼り付けたバズワードではない。9年間、本番稼働中のプロダクトで、実際のSLAを支払うクライアントのために運用してきたオペレーティングモデルだ。同期する3拠点 - パリ、モントリオール、東京。営業日あたり24時間の有効デリバリー。深夜3時にタイムゾーンを追いかけるエンジニアはゼロ。これがアダプティブFollow-the-Sun。それ以外はマーケティングにすぎない。

課題 - なぜ24/7は9-to-5の中で死んだのか

多くのSIerはオンコールローテーションを積み重ねて24/7を売る。19時に閉まるパリチーム、消火活動的に引き継ぐオンコール担当、翌朝10件のチケットでリスタートするバックログ。24時間支払って、8時間しか出荷できない。

もう1つの定番 - インドや北アフリカの低コストニアショア。重複時間は4-6時間稼げるが、品質、知財管理を失い、Slackで「私の担当じゃない」とチケットを投げ合う2チームになる。チケットは16時間眠る。

単一拠点デリバリーが重要プロダクトで生む隠れコスト -

• 市場投入の遅延 - 営業時間外のインシデント対応はMTTRが3-5倍に膨らむ。
• 構造的バーンアウト - 繰り返すオンコールでシニアは18ヶ月以内に離脱する。
• 見えない技術的負債 - 疲弊したオンコールが深夜2時に書いたコードは、6ヶ月後に課金バグとして表面化する。
• モメンタムの喪失 - 金曜夜にデリバリーされた機能は月曜朝まで検証待ち。リリースごとに60時間の遅延。

アダプティブFollow-the-Sunメソッド

アダプティブと呼ぶのは、3つの並列チームが互いを踏みつけるのではなく、1つのプロダクトを中心に同期する3セルをオーケストレーションするからだ。バックログは1つ、品質基準は1つ、Definition of Doneは1つ。パリ、モントリオール、東京のエンジニアは同じGit、同じRunbook、同じADRで動く。

秘密はタイムゾーンではない。ハンドオーバーにある。我々は4年かけて拠点間の引き継ぎを工業化した - 12項目のチェックリスト、5分以内の非同期Loom動画、共有ステータスダッシュボード、PRごとに記録されるオーナーシップ。東京が1日を終えるとき、パリは東京が止めた地点から正確に再開する。重複なし、再オンボーディングなし、「文脈を再度教えて」もなし。

アダプティブFollow-the-Sunを成立させる3つの技術的柱 -

• Documentation as code - すべてのアーキテクチャ決定はバージョン管理され、すべてのRunbookは実行可能、すべてのインシデントは自動でインデックス化されたポストモーテムを生成する。
• 共有オブザーバビリティ - GrafanaまたはDatadogのダッシュボードを3拠点で共有、アクティブな拠点へアラートをルーティング、累積オンコールなし。
• トランクベース開発 + フィーチャーフラグ - タイムゾーン間で乖離する長期ブランチなし、継続的リリース、30秒でロールバック。

具体的にどう動くか - 8時間ごとのハンドオーバー

Follow-the-Sunプロダクトの典型的な1日はこうなる。時刻はCETだが、どの拠点が始まろうと仕組みは同じだ。

1. 08:00 CET - パリ始動。東京のハンドオーバー(Loom + ダッシュボード)を読み、東京が残したバックログを引き継ぐ。
2. 12:00 CET - パリ-モントリオール15分同期(モントリオールは現地7時に始動したばかり)。
3. 16:00 CET - パリが構造化ハンドオーバーでモントリオールへ引き継ぎ。Loom + チェックリスト。パリ終了。
4. 20:00 CET - モントリオール継続、東京は始動準備(東京現地5時)。
5. 00:00 CET - モントリオールが東京へ引き継ぎ。東京はインシデントと優先機能を主導。
6. 08:00 CET - 東京がパリへ引き継ぎ。ループ完了。

証拠 - ル・モンド紙での6年間のFollow-the-Sun

ル・モンド紙は6年間、データとインサイトのスタックで我々を信頼してくれている。ミッションはパリで開始、新聞社のInsightsチームに組み込まれた。2023年、リードエンジニアのAlexandre L.が東京へ移住。ミッションは止まらなかった。むしろカバレッジが広がった。

現在、ル・モンドはCET 5時から22時のレンジで能動的なカバレッジを得ている。政治ライブ放送中の朝6時にパリで編集インシデントが発生したとき、東京は午後の真っ最中で、パリがコーヒーを飲み終える前に修正を発動する。私が知る限り、この規模のフランスメディアで本番稼働しているFollow-the-Sunはここだけ。そしてそれが6年続いている。

なぜ3拠点で、2でも4でもないのか

正当な質問、RFPごとに聞かれる。答えは戦略的である前に数学的だ。

• 2拠点(パリ-東京またはパリ-モントリオール) - 1日16時間カバー、8時間の穴。Follow-the-Sunではなく単なる延長営業日。
• 3拠点(パリ-モントリオール-東京) - 24時間カバー、各拠点8時間稼働、各ハンドオーバーは同期(隣接拠点間で1-2時間の重複)。スイートスポット。
• 4拠点以上 - ハンドオーバーごとにノイズ、手戻り、文脈の希釈が増える。3を超えると、調整コストがカバレッジ利得を上回る。

パリ、モントリオール、東京 - これはロマンチックな地理的選択ではない。文化的摩擦を最小化しつつ時間カバレッジを最大化する三角形だ。3つの作業言語(FR, EN, JP)、3つのコードレビュー文化、1つの共通基準。

我々が避けること(アンチパターン)

• 累積オンコール - 絶対にしない。Follow-the-Sunでオンコールを軽減する目的で導入したのに、エンジニアが夜間呼び出されるなら、何も得ていない。
• ドキュメント化されない口頭ハンドオーバー - 「Zoomで簡単に説明」は離職に耐えない。すべてLoom + ダッシュボード経由。
• 3つの並列バックログ - バックログは1つ、Definition of Doneは1つ、プロダクトオーナーは1人。さもなくばサイロ化した3つのミニチームになる。
• 機械的な太陽追跡 - パリで18時だからという理由だけで東京にチケットを送ったりしない。東京がそのチケットに最適な拠点(スキル、文脈、優先度)である場合に送る。
• 3声のレポーティング - PMは1人、レポートラインは1つ、クライアント側の窓口は1人。クライアントが3チームを「管理」することは絶対にあってはならない。