概要

• Microsoft Office の大規模なバージョン管理システム移行の実体験談
• Source Depot から Git への移行の過程と技術的・人的課題
• VFS for Git 開発など、超巨大リポジトリ対応の工夫
• チャンピオン制 による全社的なコミュニケーション戦略
• 移行後の成果と大規模プロジェクトへの教訓

プロダクトから生産性向上への転身

• 開発者生産性向上 への情熱
• 「生産性は乗数効果」 というメンターの言葉
• 小さな時間短縮が 全体で膨大な効果 を生む現実

Source Depotの時代

• Source Depot はMicrosoft独自のバージョン管理システム
• Perforceベース で開発、当時の選択肢は極めて少数
• コードの取得やブランチ作成が 非常に遅く手間
• 中央集権型 でネットワーク障害に弱く、リモート作業は困難
• マージ作業 （RI/FI）は専門担当者の尊敬対象
• 長年の運用で 信頼性は高い が、時代遅れに

Git移行プロジェクトの開始

• Office Engineering が主導し、 Git移行 を決断
• メンテナンスコスト や スキル移転性 の課題
• 数年単位の計画 と全社的な調整が必要
• Officeは 多様なリリーススケジュール を持つ巨大組織
  • LTSC、半期、月次、Insidersなど多様なバージョン管理
• 旧・新システム同時運用 が長期間必須
• バージョン番号やビルド検証 の一貫性維持
• レガシーテストインフラ の移行など多岐にわたる課題

Office規模の難しさと体制構築

• 4,000人超 のエンジニアが協働する巨大組織
• 各製品（Word, Excel, PowerPoint, OneNote等）と 部門横断連携
• チャンピオン制（hub-spokeモデル） を導入
  • 各チームに Developer Satisfaction Champion を配置
  • フィードバックと調整役 として機能
• OneNoteチャンピオン として移行プロジェクトに参加

VFS for Gitの開発

• GitHubと共同開発 で VFS for Git を発明
• 巨大リポジトリ（クローンで200GB超）対応のため
• 必要なファイルのみオンデマンド取得
• Git操作の高速化 とディスク容量削減を実現
• Windowsチームの先行事例をさらに拡張

フェーズ1：パラレルユニバース戦略

• Gitネイティブなコードベース とSource Depotを 並行同期
• 自動化ブリッジ の構築に数回の失敗と試行錯誤
• 異なるブランチ・マージ概念 の変換作業
• コミット情報や履歴の忠実な移行 に苦労
• 低トラフィック領域 でのテスト導入から段階的展開

フェーズ2：等価性証明

• 両システムで全テストスイートを日次実行
• 微細な差異（改行・大文字小文字・出力形式） に苦戦
• 「bb」システム でのテスト結果検証
• 完全一致の日（all green） 達成で移行準備完了を確認

人的側面とコミュニケーション

• 技術的課題よりも人的課題 が失敗要因になりやすい
• 週次チャンピオン会議＋多重チャネル で情報伝達
• 重要情報は3回以上異なる手段で伝達
• トラブル時は即座に正直に共有 し、信頼を構築

Git定着のためのトレーニング

• Source Depot慣れした開発者向けの実践型トレーニング
• コマンド対比表・サンドボックス環境 の提供
• 動画ライブラリ でリアルな操作例を共有
• 「自信の醸成」 が最重要ポイント

ロールバック戦略

• 「レッドボタン」制度 で即時中止可能な体制
• 実際に 一度パフォーマンス問題で中断 を経験
• 心理的安全性 の確保と旧環境の長期保存

移行後の成果

• OneNote開発者の9割近くがGitを支持
• オンボーディング期間が半減
• VFS導入でビルド高速化
• 生産性・コードレビュー効率の大幅向上
• 新規採用者も即戦力化

大規模移行から得た教訓

• コミュニケーションへの投資は想定以上に重要
• 技術課題は解決できても人的課題がプロジェクトを頓挫させる
• 「パラレルユニバース」で等価性を証明してから切り替え
• 早期にチャンピオンを選定し、権限とリソースを集中投下