ハクソク

世界を動かす技術を、日本語で。

Microsoft OfficeのSource DepotからGitへの移行

348日前原文(danielsada.tech)

概要

  • 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導入でビルド高速化
  • 生産性・コードレビュー効率の大幅向上
  • 新規採用者も即戦力化

大規模移行から得た教訓

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

Hackerたちの意見

2016年のマイクロソフトのインターンシップで、ソースデポのサポートを自動コードレビューツールに追加するのにほぼ1週間かけたんだけど、ソースデポが何か全然知らなかった！当時でも結構な数の開発者が使ってたよね。もう全部gitに移行されてるのかな？

└

いやいや、まだまだSDで動くものはたくさんあるよ！！SDコマンドとか設定するの、なんかゾクゾクする！！

└

今は日常的にはほとんどgitでやってるね。

└

毎日CodeFlowが恋しい。あれは本当に使いやすいツールだったよね。

大きなリポジトリをPerforceからGitに移行したことがあるけど、いくつかの問題には共感できるよ。幸いにもVFSを自分たちで作る必要はなかったけど、大きなファイルにはgit-lfsが役立ったね。

「本物さが生産価値よりも重要だった。」この本物のストーリーをシェアしてくれてありがとう！2015年にソースデポからGitに切り替え始めた比較的小さなプロダクトラインで元MSFTとして、君たちがやった仕事の素晴らしさに本当に共感できるよ！

└

ほんと、長い旅だったよ。こんなことがあったなんて信じられない。コメントありがとう。

マイクロソフトが内部でVisual SourceSafeから移行したのはいつなのか知りたいな… 継続的な公的使用を避けるために、リコールすべきだったよね…

└

マイクロソフトのSourceSafeが存在してたことすら知らなかった。

└

彼らが内部でそれを使ってたかどうかはわからないけど、少なくとも大きなプロジェクトには使ってなかったと思う。もし使ってたら、あんな風に売り出すことはなかっただろうし… TFSについては説明できないけど、内部でも外部でもまだゴミだったよ。

└

ほとんどのチームが使ってたとは思えないな。マイクロソフトで数年過ごしたけど、うちのチームはソースデポを使ってた。多くの人が自分たちの製品は特別だと思ってたし、マイクロソフト自身のソース管理（当時のTFS）も十分じゃなかったからね。前の仕事でTFSを使ってたけど、あんまり好きじゃなかった。でも、ソースデポを使うようになってからは本当に恋しかったよ。

└

2000年頃かな？俺が知ってる中でそれを使ってたプロジェクトは.NETだけで、その頃にはSDで動いてたよ。

俺はMicrosoftがXNSからTCP/IPに移行するチームにいたんだ。あれはもっと簡単だったけど、似たような教訓は得られたよ。でも、MSMAILからExchangeへの移行は、本当に大変だった。

└

それが「Exchange: Microsoftで最も恐れられ、嫌われているチーム」というナンバープレートフレームのインスピレーションになったの？言葉がちょっと間違ってるかも。20年近く前に見たからね。

疑ってるわけじゃないけど、OneNoteの浅いクローンが200GBになる理由がわからないな。

└

動画かバイナリがあるに違いない。

└

OneNoteじゃなくて、Office全体の浅いクローンだよ。

もうロングテールに突入してる気がするんだけど、他にSCMシステムはあるのかな？それともソースコントロールはこれで終わりで、gitが唯一の解決策ってこと？

└

Mercurialもまだ息してるし（Metaのフォークは除いて）、jjも少しずつ伸びてるし、fossilも存在してるよ。あと、P4は今でも結構使われてるみたい。DVCS全般、特にgitは大きなバイナリアセットの扱いが苦手だから、例えば大規模なゲーム開発にはあまり向いてないんだよね。Unityは数年前にPlasticSCMを買収して、クラウドサービスの一部として使ってるし。GoogleはP4を超えた時に開発した独自のVCS、Piperを使ってるよ。

└

他にもいくつかの解決策（例えば、gitをストレージ媒体として使いつつ、コミットの扱いに違いがあるjujutsuみたいなの）があるけど、gitが全てのソースコントロールのニーズに応える一元的な存在になったっていう重要なポイントに達したと思う。

└

Perforceはゲーム開発やアニメーションなどで使われてるけど、gitは本当に大きなアセットを扱うのが苦手なんだよね。

└

Gitだけだと、XLコードベースにはあまり向いてないことが多い。FacebookやGoogle、他の多くの会社やプロジェクトは、Gitを拡張して使いやすくしたり、カスタムソリューションに切り替えたりしてる。AOSPは5000万行のコードを持ってて、リポジトリのリポジトリをつなぐために、manifestベースのdepth=1ツール「repo」を使ってる。「なんでGitサブモジュールを使わないの？」って思うかもしれないけど、GitサブモジュールはUXが悪くて、扱うのが大変だから、カスタムツールの方がいいんだ。MetaはカスタムVCSを使ってるし、最近「sapling」っていうのをリリースしたよ。一般的に、分散VCSが中央集権型より優れているっていう哲学は、実際にはかなり疑問だと思う。自分の同僚が何をしているのか、何に取り組んでいるのかを知りたいし、マージのコンフリクトを避けたいんだ。VCSの外での同期がないDVCSは、マージ地獄を引き起こすことが多い。Gitのデフォルトのパックファイル設定は悪夢で、ほとんどのチェックアウトはdepth==1にすべきだし、そのファイルがローカルでアクセスされたときだけ動的にするべきだよ。VCSとビルドシステム、ファイルシステムの深い統合があれば、もっと良くなると思う。VCSの分野にはまだまだ革新の余地がたくさんあると思う。人々は自分のコアなワークフローを壊したくないから、変化に対して自然と抵抗があるんだよね。

この古い話の新しい語りを読むのはいつも楽しいね。TFAは「オフィスリポジトリの取得に数時間かかった」とか言ってるけど、実際にはgitでは新しいファイルシステム（VFS）を作らないとそんな操作はほぼ不可能だったんだよね。Perforceはユーザーが必要な部分だけをチェックアウトできるから、たぶんほとんどのSDユーザーはオフィススイートのアプリを毎回全部取得するんじゃなくて、必要な部分だけを取ってたと思う。VFSはgitのそのギャップを埋めるもので、「VFS for Gitは必要なオブジェクトだけをダウンロードする」って感じ。Perforce/SDは当時は素晴らしかったし、中央集権的なVCSの使い方には合ってたけど、時代は進んだんだろうね。

└

いくつかの企業はPerforce用にVFSみたいな独自の技術を開発して、アプリケーションのスイート全体をチェックアウトできるけど、特定の方法でアクセスしようとした時にだけファイルを引っ張ってくるって感じ。これはゲーム開発では特に重要で、大きなソースバイナリアセットがテキストファイルと一緒に保存されてるからね。これ、リモートドライブプログラムが使ってる技術と同じだと思う。個人的には、チェックアウトする時に全履歴をローカルに保持せずに会社のソースセットを全部保存できるサーバーベースのVCSが欲しいんだけど、今のところgitがマシン間でアドホックに使うには十分だから、まだ中央サーバーやCI/CDパイプラインを設定する必要を感じてないんだよね。それに、スタッシュしたり、ハンクをステージングしたり、インタラクティブにリベースしたりする機能が好きで、今の作業スタイルにも合ってるし。

└

うちの会社はまだPerforceを使ってるけど、正直誰も好きじゃないと思う。新入社員に「うちは世界の他の会社みたいにGitは使ってない」って言うと、目が死んでいくのが見えるよ。

90年代に自分もVSSを使ってたから、全然言及されてないのが驚きだったよ。VSS（Visual SourceSafe）はマイクロソフトの独自のソースバージョニングプロトコルで、PerforceからライセンスされたSource Depotとは違うんだよね。

└

うん、90年代にソロ開発者としてVSSを使ってたよ。当時は衝撃的だった。大学院で他のVCSシステム（RCS、CVS）に出会ったし。2004年にMSFTで仕事を始めた時、誰かがVSSは安全じゃなくて壊れやすいって説明してたのを覚えてる。真実かどうかは分からないけど、ただの伝説かもしれないし、仕事には使えなかったけどね。

└

90年代にVSSも使ってたけど、チームで作業するのは悪夢だった。確か、マイクロソフト自身も内部ではVSSを使ってなかったはず、少なくとも大半のことにはね。

IBMのRational Team Concertをもう使わなくて済むなんて、ほんとありがたい。考えるだけでゾッとするわ。