紹介 - How Microsoft is modernizing its internal engineering processes
先日の Microsoft Build にて Microsoft のエンジニアリングを知るセッションがあったのですが眠くて逃してしまいました。
Expert Q&A: Modernizing Microsoft’s Internal Engineering Practices
あーあ逃しちゃった。他に似たような講演があったりしないだろうかと思って探して出てきたのがこれ。
とてもいい内容だったのですが、本稿執筆現在で50回しか再生されていません。 そこで、私がかいつまんだ内容を紹介することにしました。
Core Service Engineering and Operations (CSEO)
- Core Service Engineering and Operations (CSEO) は Microsoft 内部の IT 横断的な部門であり、法務、人事、財務、営業、調達などの縦割り部門や、エンドユーザー向けサービスの全てを支えている。3年前までは Microsoft I.T. と呼んでいた。
- CSEO とその影響がどれだけ大きいかを示す数字として次のものがある
- エンジニアとプログラムマネージャー (フルタイム) 5500人
- Git リポジトリ数 3500
- 1日あたりのコミット数 66000
- 1日あたりのビルド数 2800
- ビルドあたりの平均所要時間 16分
- 1日あたりの市場リリース回数 640
- Azure DevOps アカウント数 1 (訳注：single account, single project と言っているが single organization が正しいと思われる)
昔、現在、これから
- 2017年までは…講演者の予想では、60-70% のエンジニアはアウトソースで、フルタイムエンジニアは 30%。それぞれの縦割りビジネス組織では約500ものオンプレ版 Team Foundation Server が使用され、互いの情報を見ることは不可能だった。複数の組織にまたがる問題のトラッキングは難しかった。それぞれの組織が似たようなツールを作ってしまうこともあった。それぞれの組織が開発したプロダクトに対して UI の統一性を持たせることも困難だった。
- CSEO が生まれ、2020年現在は…約500の Team Foundation Server を1つの Azure DevOps に集約した。Microsoft に何のサービスがあるか、インシデントが何か、各サービスの稼働状況はどうなのかといった情報は集約された。ユーザーからどんなフィードバックがあり、それらのフィードバックを分析した結果が何で、ビジネスとエンジニアリングの計画にどう活かされたのか、わかるようになった。
- このようなモダナイジングは道半ばであり、これからは…新たなフィーチャーの実験的なリリース、インシデントの自動検出と自動修正をリリース前に行うこと、エンドツーエンドのビジネスモニタリング、シフトレフトと開発者のコーディング集中、Azure DevOps から GitHub へのリポジトリ移行をしようとしている。
何をモダナイズするのか、4つに分けた。
- サービスの信頼性が悪く、インシデントの解決に時間がかかる。時間がかかるのは開発者のレスポンスが悪いのではなく、ユーザーが怒って教えてくれるまで気づかないから。データもメトリクスもないから。だから、サービスがどう動いているのかをモニタリングして問題を見つける筋肉質な仕組みを作り、問題があればレビューとポストモーテムを行ってシェアするという live site first の文化を育むことを目標とした。
- サービスのセキュリティー、プライバシー、アクセシビリティのポリシーが一貫していない。主な原因は技術的負債。だから、技術的負債の解消に労力の20-40%を充てること、ポリシーに準拠しているかをパイプラインで確かめることを目標とした。
- 新ビジネスの勢いが続かない。これはビジネス部門同士がサイロ化しているため。だから、会社レベルでのコードの共有、継続的リリースの仕組みを作り、良いツールやプラクティスを会社全体に浸透させ、似たような仕組みを各々が作る必要がないようにし、エンジニア同士がイノベーティブな活動をできることを目標とした。
- UX が練られていない。UI に統一性がない。これは Microsoft の典型的な問題。だから、統一的で練られた UX のための標準デザインコンポーネントを開発するチームを立ち上げた。これも CSEO 内にある。
約700あるサービス、アプリケーションのポートフォリオはクラウドへ
- 一夜にしてではなく何年もかけて、いくつかのフェーズを経てクラウド化していった
- もはや使われない 30% のサービスを廃止
- 15% は SaaS を使ったもの、または SaaS に置き換えたもの
- 50% は PaaS, IaaS へ
- 5% はオンプレミスのまま
フィードバック駆動開発
- 講演の最初で述べたように、ユーザーのフィードバックを得て、組織的に共有し、次の開発計画を決め、実装後にパイプラインが流れたときもトレーサブルになるようにしている。
- この仕組みを実現するのも CSEO の仕事で、例えば Office のスマイルマークからフィードバックできる仕組みを実装している。
- CSEO がこの機能を開発するときは Office 開発チームと協力し、まず Microsoft 内部で使えるものか評価した。
- 真の変革はフィードバックをする仕組みの機能的な実現だけではなく文化の変革である。開発チームが、PMが、ユーザーのフィードバックを無視せずに向き合い、それらを発端として開発を駆動するようになることが必要である。
モダナイジングを通じて学んだこと
- モダナイジングを成功させるには、まずビジョンを立て、メトリックに基づいて進めること。それにより、何がキーとなる問題なのか、何から手をつけるべきなのかがわかる。
- 変革は、人、プロセス、技術の全てを通して達成できるものであるということ
- 技術的負債を解消するための時間を確保することの必要性。新たなフィーチャーを継続的に投入してゆくためには、労力の 20-40% を技術的負債の解消に投資する必要がある。
- 変革は、事業主体から顧客までのE2Eを通して考える機会となること
- この変革という旅をゴールとメトリックに基づいた一貫したものにすることの必要性
紹介者所感
アメリカの大手IT企業 (GAFAM と言われる企業) の組織構造を示す風刺画では、内部組織同士が銃を向け合っているものが Microsoft でした。これを解消し、全体最適を進め、その立役者が CSEO という事業横断組織だったということなのだと解釈しました。
Funny Organizational Structure of Apple, Facebook, Google, Microsoft, Oracle and Amazon! [PIC] - JUYOFO
もともと 700 もあった Team Foundation Server が 1つの Azure DevOps organization になり、ユーザーからのフィードバックも中央に集め全社的に共有できるような技術的仕組みと文化を醸成したというストーリーは、InnerSource を思い起こすものでした。また、DevOps における Monitoring→Planning→Development→Integration→Deployment→Monitoring→… を正攻法で達成していると思いました。
Windows, Office, Visual Studio, Azure など、従来はバラバラだったのであろう事業部門がビジョンを共有して文化の変革ができた主要因は何だったのでしょうね。従来の Microsoft I.T. から CSEO に変わったときに何が起きたのか、バルマーからナデラに変わったことがどこまで関係するのか、強烈なトップダウンと幾多のボトムアップが融合したのか、他の事業部門など関係ないと思っていた組織と人々を導くインセンティブを人事制度として設計したのか。
これらも併せて読むと見えてきそうです。
