マイクロソフトの機能リリースのプロセスとは？
「Azure DevOpsとGitHubは同じチームが開発しており、今後もどんどん統合を進めていく」――セッションは服部氏のこの力強いメッセージから始まった。
GitHub Satelliteで発表されたGitHub Actions v2はAzure Pipelinesとの連携が実現。Azure Pipelinesのエンジニアが数十人規模でGitHub Actionsの開発チームに異動するなど、今組織もドラスティックに変化しているのだそうだ。「MicrosoftもGitHubが中心の開発に舵を切っている」と服部氏は言い切る。
Azure DevOpsとGitHubが統合されることで、GitHubアカウントでAzureにサインインしたり、Azure ADでGitHub Enterpriseに対してシングルサインオンで認証できるようになる。もちろんCI/CDの連携も密になる。「Azure DevOpsとGitHubの連携はまだ過渡期。今後、さらに統合を加速させていく」と服部氏。
マイクロソフトではどのようなプロセスで機能をリリースしているのか。まず、マイクロソフトには、カスタマーオブセッションのカルチャーがある。これは「顧客志向」と訳されることが多いが、マイクロソフトでは「好きで好きで仕方がない」という強い言葉として捉えられているという。これは、Azure DevOpsのチームが、年間5000のユーザーオブザベーション（ユーザー観察）と5000のユーザーインタビューをこなしていることからも明らかだ。
またリーン開発のカルチャーがあり、それを先導するためのカルチャールームも用意しているという。「だがこれは最近の話」と服部氏。かつてのマイクロソフトは組織の規模が拡大するに伴い、官僚的組織となり、コラボレーションが低下。リポジトリも大きくなり「ソースコードレベルでも共有できないことが起こっていた」と服部氏は明かす。
そこでまず取り入れたのが、GitHubでの「インナーソース」の実現である。インナーソースとは組織内においてオープンソースの文化とベストプラクティスを実現すること。社内にソースコードとライブラリ群が共有される環境が生まれ、コラボレーションが増加したという。「どういう人がどういう技術を持ち、どう動いているか。組織内でチームの見える化が実現した」と服部氏。そのほかにも、組織のサイロを壊すこと、興味のあるプロジェクトに取り組み、スキルを向上できるなど開発者の満足度向上にもつながったという。メリットはそれだけではない。
「インナーソースの取り組みをすると、最終的にオープンソースのリポジトリとして社外に公開しやすくなったり、社外のコラボレーターを引き寄せやすくなったりする。そういったメリットがあるため、マイクロソフトではインナーソースを採用している」（服部氏）
次に、開発においては、デプロイを自動化するなら完全にすることにこだわったという。つまり部分的な自動化は避け、すべて自動化するのである。「Azure DevOpsのチームも一日の成果物をケアレスミスの手動処理によってまるごとつぶしてしまったことがある」と明かす。
また、開発チームが積極的に行っているプラクティスがバグキャップである。バグキャップは単純なルールで、次の式で求めることができる。
- チームのエンジニア数×係数＝バグキャップ
係数は経験則から求める。例えばチームに7人のエンジニアがいて、経験則から求めた係数が4だとすると、7×4＝28となり、28という値を上回るバグが発生すると、新しい機能の開発はその段階で止め、バグの解決に専念する。バグキャップを超さない状態になって初めて、新しい機能を開発するというルールだ。「インナーソースの活動がどんどん盛んになると、たくさんの人が開発に参加することで、メンテナンスが追いつかなくなることがある。バグキャップはそんな負債を負い続けないようにするためのプラクティスだ」と服部氏は説明する。
従来、マイクロソフトではウォーターフォールでの開発を行ってきた。ウォーターフォールの課題は、統合テストの量が非常に多いこと。小さな単位で変更をコミットしても統合テストが走り、そのレスポンスが返ってくるまでに時間がかかるからだ。「UIテストもエンドツーエンドのテストだと、反映するまで1時間ほどかかることもあった」と服部氏。そこでマイクロソフトでは、統合テストから単体テストへのシフトレフトを進めている。
「今ではエンジニアが1つ変更点を加えたら、10分ぐらいでそのコミットがテストに通ったかどうか、わかるようになった」（服部氏）
リリース・ライブサイトのプラクティス
テストだけではない。マイクロソフトは安全にリリースする策として、カナリヤリリースを採用している。
Azure DevOpsのチームの場合、まずカナリヤ（内部ユーザー）に公開。Azure ポータルでプレビューをテストする。次に最小の外部データセンターにデプロイ。最小とは、ユーザーが少ないデータセンターを使うということ。全体のダメージを減らしてから、最大の外部データセンター、国際データセンター、残りすべてといった流れで範囲を広げていく方法だ。
「アプリケーションのデプロイだけではなく、データベースのコンフィギュレーション、それに伴うインフラの設定など、膨大なカナリヤリリース環境がマイクロソフトは構築できている。これらは、Azure DevOpsやGitHub Actionsを使うとできること。ぜひ、みなさんもトライしてほしい」（服部氏）
リリースが完了した後の、ライブサイト（プロダクション環境）カルチャーも重要になる。マイクロソフトではフィーチャーチーム（機能ごとのチーム）を形成し、ライブサイトにおけるステータス確認を最優先事項として活動。縦型統合の組織で、PMやテストエンジニアなどあらゆる役割の人が1つのチームに属しており、オンコール対応や毎週のライブサイトレビューなどがフィーチャーチーム内で完結するようになっているという。情報共有はAzure Boardで行っている。
服部氏は「当社ではこのような開発スタイルで、カスタマーオブセッションやリーン開発を実現している。参考にしてほしい」と語り、GitHubの田中氏にバトンタッチした。
