Microsoft OfficeがSource DepotからGitへ移行した過程

• Microsoft Office は長年、社内のソース管理システムである Source Depot を使用していたが、開発者体験と技術革新のために Gitへの大規模移行 を進めた
• Source Depot は 中央集権型、遅いブランチ作成、不便なワークフロー により生産性に限界があり、Gitへの移行には数百人のエンジニアと数年にわたる作業が必要だった
• 移行プロセスでは VFS for Gitのような新技術の開発、既存のビルド／テストインフラの移植、並行システム運用など、大規模な技術的・組織的課題を乗り越えた
• 成功する移行のために、「チャンピオン」中心のコミュニケーション体制、大胆な透明性、実践的な教育、即時ロールバック戦略など、協調的で人間中心のアプローチを重視した
• 移行後はオンボーディング時間の短縮、Git選好率の増加（89%）、生産性向上などの前向きな成果が得られ、大規模な技術変化における重要な教訓も残した

---

Source DepotからGitへ: Microsoft Officeの大規模移行の経験

開発者生産性を最大化する新たな挑戦

• 開発者生産性を高める取り組みは 'Multiplier work' であり、大規模な組織ほどその価値は大きい
• Microsoft OfficeのSource DepotからGitへの移行 プロジェクトは、その代表的な経験だった
• この作業は単なるツール変更ではなく、数百人のエンジニア、複雑なシステム、長期間にわたる大規模プロジェクトだった

Source Depot: あの時代のソース管理の話

• 2000年代初頭、Microsoftは Perforce 技術ベースの独自バージョン管理システムである Source Depot を運用していた
• Source Depot は 遅いブランチ作成、中央集権化、長いコードチェックアウト時間、不便なマージ方式（Reverse/Forward Integrate）などにより、作業効率に限界があった
• 開発インフラ全体（ビルド、リリース、ワークフロー）と強く結びついており、単純な置き換えが不可能な構造だった
• Microsoft Officeの Git移行 には数年と数百人のエンジニアの努力が必要だった

OneNoteを皮切りに: 移行の始まり

• Officeのエンジニアリング組織では、Source Depotの維持・パッチコスト と「競争力のある技術」への要求から、大規模なGit移行が決定された
• Office製品群はリリース周期（数か月、半期、月次、インサイダー）ごとに開発スケジュールが異なるため、長期間の Source Depot-Git並行運用 が必要だった
• Officeのバージョン管理の一貫性、ビルド検証、レガシーテストインフラの移植などが必須課題として浮上した

Officeの規模とコミュニケーション戦略

• Officeは当時、4,000人規模のエンジニア が協業する超巨大組織だった
• チームごとに 'Developer Satisfaction Champion' を指定し、各チームをつなぐ hub-spokeモデル を通じて、円滑なフィードバックとコミュニケーション構造を整えた
• 筆者はOneNoteのチャンピオンとして、大規模移行の現場で中核的な役割を担った

VFS for Git: 超巨大コードベースの限界突破

• 1回の git clone に200GB以上必要になるほどコード規模が大きく、GitHubと共同開発した Virtual File System for Git (VFS for Git) によって問題を解決した
• VFS for Git は実際に使うファイルだけを取得する方式で、標準的なGitの限界を克服した
• Microsoft Windowsと連携しながら、業界最大級のバージョン管理システムの限界を乗り越える経験だった

移行の段階的アプローチ

1段階: 並行宇宙（Parallel Universe）

• Source DepotとGitをリアルタイム同期するブリッジ サービスを構築し、両システムの不一致やモデル差異（ブランチ構造、changelist など）の問題を繰り返し改善した
• Officeのメイン／Privateブランチ-同期-ビルドのプロセスを24/7の自動化システムで運用した
• 3回にわたる再試行の末に、安定して動作する並行システムを実装した

2段階: 等価性の検証

• すべての テストスイート を両システムで繰り返し実行し、ビルド結果が完全に同一であることを証明した
• 改行方式、大文字小文字、テスト結果フォーマットなどの微妙な差を数か月かけてデバッグし、解決した
• 'Green across the board' （両システムともにテスト通過）という成果により、実際の移行段階に入る準備が整った

人間中心のアプローチ

マルチチャネルでの反復的コミュニケーション

• 4,000人超のエンジニアと数十チーム のスケジュールを合わせるため、各チームのチャンピオンを通じた集中的なコミュニケーション体制を構築した
• 重要なお知らせは最低3回（メール、Teams、Wiki、会議など）繰り返し伝え、混乱を最小化した
• 問題発生時には、即時かつ透明性の高い情報公開 によって信頼を確保した

Git導入教育と適応

• 10年間Source Depotに慣れたエンジニアのために、実習型の教育環境 や 移行コマンドガイド など、段階的な学習体制を整えた
• 実践重視の動画ライブラリなどを通じて、実際のシナリオに基づく学習 を提供した
• 不安の解消と能力強化 を超えて、既存ワークフローへの適応も支援した

ロールバック戦略と安全装置

• 実際の切り替え時には Directorに「赤いボタン」を提供 し、深刻な問題が起きた場合はいつでも即時ロールバックできるようにした
• 過去のSource Depotの一部記録は長期間保存し、既存の開発履歴を安全に維持した

結果と主な成果

• 移行後、オンボーディング時間が50%短縮 され、Git選好率89%が確認され、ビルド性能の改善、コードレビュー効率と協業の増加など、生産性向上の効果 が現れた
• エンジニアたちは 業界内で転用可能なスキルの習得 を前向きに評価した
• 新規人材が即戦力として参加しやすくなった

大規模移行の重要な教訓

• 成功のためには、技術要素だけでなく人間中心のコミュニケーション に予想以上の投資をする必要がある
• 並行システムの構築と完全な等価性の証明、初期段階からの確実なロールバック設計、重要人材（チャンピオン）の重視が重要だった
• 満足度などの定性的指標も並行して測定 することが不可欠であり、変化の過程では組織的安定と心理的安全性が重要となる
• 大規模な変化の本質は、組織全体にわたる柔軟で体系的な変化管理 にある

結論と今後への適用

• OfficeのGit移行は、数年にわたる準備と数か月の実行によって実現した歴史的プロジェクトだった
• 最終的には、数千人の業務の連続性を確保しながら組織的変化を成功裏に推進した事例 として残った
• クラウド移行、モノリシックアーキテクチャの分解、フレームワークのアップグレードなど、ほかの大規模変化でも 並行検証、反復的コミュニケーション、迅速なロールバック設計 は同様に適用できる
• 技術的詳細（ビルドインフラ、オフライン／契約上の問題など）には追加で触れていないが、大規模な技術変化では戦略的・組織的アプローチが最も重要な教訓である

[ndrgrd]

バイナリファイルを多く扱うならGitは向かないかもしれませんが、コード中心のリポジトリであればGitで十分なようです。

[rtyu1120]

MS社内でも大きな変化だったでしょうが、そのおかげで partial clone や sparse checkout のような機能や Scalar のようなツールも外部に公開されて使えるようになったのは、良い影響だったと思います（笑）

[GN⁺]

Hacker Newsのコメント

• こういう昔話を新鮮に語り直してくれる記事を読むのはいつでも楽しい。元記事では「Office リポジトリ全体を取り込むのに数時間かかった」と触れているが、実際には git では VFS のような新しいファイルシステムなしでは、こうした作業自体ほぼ不可能だった点を事実上省いている、という指摘。Perforce ではユーザーが必要な部分だけをチェックアウトできたので、Source Depot ユーザーの大半も毎回 Office 全体を取得していたのではなく、必要な部分だけ取っていたはずだという推測。VFS は git で必要なオブジェクトだけをダウンロードさせることで、この差を縮めてくれる。Perforce / Source Depot は当時としては非常に優れた中央集権型 VCS だったが、今では時代が変わったという感想。
  • Perforce でも、VFS のように必要になった瞬間だけファイルを取得する独自技術を作った会社がある、という説明。これはゲーム開発で、テキストファイルと一緒に大容量のバイナリなソースアセットを保管する際にとくに重要。Windows に組み込まれているリモートドライブ用プログラムが使う技術と同じ系統だと思う。個人的には、会社全体のソースを保存しつつ、ローカルに全履歴を複製する必要のないサーバーベースの VCS を今でも望んでいる。ただ、git は複数デバイス間の単発的な協業には十分実用的なので、中央サーバーや CI/CD パイプラインまで構築する必要性はまだ感じていない。git の stash、hunk 単位の stage、interactive rebase など、さまざまなワークフローはとても気に入っている。
  • うちの会社はいまだに Perforce を使っているが、もう誰も Perforce を好きではないのが残念だ。新入社員に「うちは git を使いません」と言った瞬間、彼らの目から光が消えるのを実際に見た。
  • VFS では Perforce を完全には置き換えられない。実際、AAA ゲーム会社の大半はいまだに Perforce を使っている、という強調。アセットファイルに lock をかけて、2 人が同時に編集してマージ不可能になるのを防ぐ必要があり、あるアーティストの成果を捨てる羽目になる時間の無駄を減らすために不可欠だ。
  • なぜ git が今なお、リポジトリツリーの特定部分だけを選択的にチェックアウトする機能を提供しないのか、正直不思議だ。オブジェクトファイルなどを理解する中間サービスを挟めば、簡単に拡張できるように思える。
• 2016 年の Microsoft インターンシップで、Source Depot をサポートする自動コードレビューワーを作っていたとき、Source Depot が何なのかも知らないまま、この機能にほぼ 1 週間を費やした経験がある（https://austinhenley.com/blog/featurestheywanted.html）。その当時も、まだ多くの開発者が Source Depot を使っていた。今ではみんな git に移行したのか気になる。
  • CodeFlow が今でも毎日恋しい。本当にすばらしいツールだった。
  • いまだに Source Depot が活発に使われている領域は多い、という話。Source Depot のコマンドや環境設定にはいつも緊張させられる感じがする。
  • 日常業務の大半は、今では git で処理しているという近況。
• 90 年代に実際に vss(Visual SourceSafe) を使っていた立場からすると、今回の記事でその話がまったく言及されていないのは驚きだ。Visual SourceSafe は Microsoft が自社で作ったソースバージョン管理プロトコルだったが、Source Depot は Perforce をライセンスして使っていた点が違っていた。
  • VSS(Visual SourceSafe) は Raleigh の One Tree Software を買収して取り込んだ製品で、製品名を「SourceSafe」から「Visual SourceSafe」に変え、Visual C や Visual Basic などと同様にバンドル提供していた。それ以前には「Microsoft Delta」というバージョン管理製品を売っていたが、価格は高く品質は低く、NT ではまったくサポートされていなかった。One Tree の買収で加わった人物の 1 人に Brian Harry がいて、この人が Team Foundation Version Control(TFS) を率いた。SQL Server をリポジトリとして使うことで、VSS より管理性と信頼性が大きく向上した。Brian Harry は今は引退したようで、ブログももう更新されていない。当時 VSS を使っていて覚えていることの 1 つは、ネットワークファイルロックを SMB で処理していたため頻繁なネットワークエラーに弱く、リポジトリ破損がよく起きていたことだ。そのため、毎日未明に復旧バッチを走らせて夜間に自動修復させていた。朝には使える状態でなければならなかったからだ。
  • 90 年代に VSS を使っていた経験からすると、チームで使うには悪夢に近かったし、知る限り Microsoft も社内ではほとんど使っていなかった記憶がある。
  • 90 年代に 1 人で開発していたとき VSS を使っていたが、当時としては新世界のように感じた。大学院では別の VCS(RCS、CVS など) に触れた。2004 年にマイクロソフトへ入社したとき、誰かが VSS は安全でなく壊れやすいと説明してくれたのを覚えている。本当かどうかは分からないが、とにかく会社では VSS は選択肢ですらなかった。
• Microsoft を XNS から TCP/IP に移行するとき、私はそのチームの一員だった。この作業は思ったほど複雑ではなかったが、似たような教訓を得た。MSMAIL から Exchange への移行は本当に大変だった。
  • 昔「Exchange: The Most Feared and Loathed Team in Microsoft」と書かれたナンバープレートフレームを見たことがあるが、それはそのときの経験が理由なのか気になる。20 年前のことなので正確な文言は覚えていない。
• 「Authenticity mattered more than production value」という言葉が本当に刺さる。退職直前の 2015 年になってようやく Source Depot から Git への移行を始めた小規模プロダクトラインで働いていた元 Microsoft 社員として、こうした作業にどれほどの労力がかかるか完全に共感できる。本当にすばらしい偉業だ。
  • 自分もこういう過程をすべてくぐってきたなんて信じがたい気持ちだ。ありがとう。
• 2000 年代初頭に Microsoft が直面していた状況を考えると、Windows はとてつもなく複雑化し、何百万行ものコードにバージョン管理が必要だったが、git はまだ存在せず、SVN も立ち上がりつつある時期だった。Microsoft が 1998 年に開発され 2000 年に公開された BitKeeper のような商用製品も積極的に検討していたのか気になる。おそらく当時は Perforce のような中央集権型システムが主流で、BitKeeper のような分散型は異質に見えたり、実績が十分でなかったりしたのかもしれない、という推測。
  • 当時は VSS(Visual SourceSafe) もあり、その後は TFVC もあった。
• Source Depot の謎を教えてくれた開発リードたちに、私のような若手エンジニアとして感謝を伝えたい。Source Depot の構造をきちんと理解したとき、本当に目が開けるような体験だった。私は WinCE と IE にしか依存していなかったので、clone に 20 分しかかからず、何日もかからなくて本当に助かった。助けてくれた人たちの名前はもう忘れてしまったが、新人を助けて仕事を始めやすくしようとする姿勢は、今でも自分のチームで受け継いで実践している。
• 多くの人は git 導入を技術的勝利として記憶しているが、実際の革新は、開発者一人ひとりが自分でワークフローを制御できるようになったことだった。もう同期ウィンドウを待つ必要も、ブランチアクセス権をリードに頼む必要もない。今では誰もが自由にスピードを上げて働きつつ、互いに衝突しない環境になった。この変化は、生産性ダッシュボードよりも雰囲気の改善にずっと大きな影響を与えたという強い印象がある。git は単なるツールではなく、開発ループへの信頼そのものを変えたきっかけだった。
• Microsoft が社内で Visual SourceSafe からいつ脱却したのか気になる。もっと早く終了させて、少なくとも外部で使われ続けることだけでも防ぐべきだったと思う。
  • ほとんどのチームは実際には VSS を使っていなかったのではと思う。Microsoft で働いていたとき、うちのチームは Source Depot を使っていた。当時 TFS も触ったがあまり好きではなかった。それでも Source Depot を使ったあとだと、むしろ TFS が恋しくなった。
  • Microsoft 社内で VSS を主要用途に使っていたのか疑問だ。もし本当に社内で使っていたなら、あんなに杜撰な状態の製品を出しはしなかっただろうと思う。TFS はどうにも理解しがたい体験で、社内でも社外でもいまひとつだった。
  • 2000 年ごろだったはずだ。自分の知る限り、使っていた唯一のプロジェクトは .NET だったが、それでさえすでに Source Depot に移っていた。
  • Microsoft SourceSafe なんてものがあったこと自体知らなかった、という反応。
• OneNote の shallow clone が 200GB という話がよく分からない。
  • 実際には OneNote ではなく、Office 全体の shallow clone だったという説明。
  • 動画や大容量バイナリが含まれていたのではないかという推測。