こんにちは。エンジニアの濱田 (@hamakou108) です。
先日、弊社主催の「PHPerKaigi2023（勝手に）リジェクトカンファレンス」というイベント1 で登壇させていただき、弊社の開発フロー改善の軌跡について Four Keys や継続的デプロイと絡めて紹介しました。元々のプロポーザルで20分想定だった内容を5分で発表したため、泣く泣く削った内容が多々ありました。今回の記事はその補完という形で、弊社における Four Keys の位置付けと取り組んでいる施策について触れたいと思います。
弊社での Four Keys の位置付け
まず弊社での Four Keys の位置付けについて紹介したいと思いますが、その前にそもそも Four Keys の定義について振り返りたいと思います。
Google Cloud による Four Keys Project の紹介では、 Four Keys はソフトウェア開発チームのパフォーマンスを示す指標であるとした上で、次のように定義しています。
- デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度
- 変更のリードタイム - commit から本番環境稼働までの所要時間
- 変更障害率 - デプロイが原因で本番環境で障害が発生する割合（%）
- サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間
Google Cloud の DORA チームは Four Keys を使って計測したチームのパフォーマンスが組織のパフォーマンスの予測指標になることを突き止めており、ほぼ毎年 State of DevOps Report という形で調査結果を発表しています。
弊社では MVV を体現するための中長期的な投資として Four Keys を位置付けています。私たちの開発チームが 2021年の DORA レポート2 においてどのクラスターに分類されるか検証したところ、「デプロイ頻度」と「変更障害率」に関しては Elite に、「リードタイム」と「サービス復旧時間」に関しては High に分類されることが分かりました。2つのメトリクスが Elite に分類されていない状況には私たちのチームがM&Aクラウドの MVV を体現するためのヒントが隠れていると解釈しています。
例えば「変更のリードタイム」が Elite でない点について、長期的にはシステムの変更容易性が低下することを示唆していると仮説を立てることができます。具体的には次のようなシナリオです。
- システム全体に自動テストが網羅されていないので修正箇所によっては障害のリスクが高い。このリスクを下げるためには念入りな手動確認を行う必要があり、変更のリードタイムが長くなる。このような箇所が広がっていくにつれてこの影響が拡大し、長期的には変更容易性が低下する
- メンバー同士の情報のやり取りが、結果（プルリクエスト）を主として行われており、そのプロセスや思想に対して行われていない。この結果コミュニケーションコストが増大し、変更のリードタイムが長くなる。チーム数が増えるにつれてこの影響が拡大し、長期的には変更容易性が低下する
長期的な変更容易性の向上は弊社の Vision である「時代が求める課題を解決し時価総額10兆円企業へ」を実現するために必須であると考えています。また「サービス復旧時間」については直接的にユーザーが不利益を被ってしまう時間に関係しており、弊社の Value の1つである「2nd Priority 3」の体現を阻害するものと捉えています。
上述した問題に対してどのように対処すれば良いでしょうか。書籍「LeanとDevOpsの科学」では、ソフトウェアデリバリーのパフォーマンスを統計的に有意な形で改善できるケイパビリティ24個が特定されており、適切なケイパビリティに焦点を当てることで成果を上げることができると記述されています。弊社ではこれを意識した最初の取り組みとして継続的デプロイの導入を行っています。詳しくは冒頭で紹介したカンファレンスの資料をご覧ください。
このように適切なケイパビリティを獲得していくことで、開発チームは MVV の実現に近づき、定量的な結果指標として Four Keys を活用することができると考えています。
Four Keys のモニタリング基盤の構築
Four Keys の活用を進めるにあたって目下取り組んでいる課題が Four Keys のモニタリング基盤の構築です。
前述したクラスター分類に使った Four Keys の数値は、実は手作業で算出されています。手作業だとスポットの数値しか算出できず、今後取り組んでいく施策によってデリバリーのパフォーマンスに改善効果があったのか検証するのも困難です。この問題を解決するために Four Keys のモニタリング基盤の構築に取り組み始めました。昨年からM&Aクラウドではデータ基盤の構築プロジェクトが進行中で、それらのアセットが活用できることも追い風となっています。
実際に基盤構築を進めるにあたって、1点難しい課題がありました。「変更のリードタイム」の計測です。「変更のリードタイム」を算出するためには起点となる commit の時刻、そしてそのリビジョンのデプロイの完了時刻のデータを集計する必要があります。自分が調査した範囲ではこれを実現できる OSS などのツールを見つけることができませんでした。
そこで開発したのが depwatch です。
このツールによって「変更のリードタイム」の算出するために必要な時刻のデータを GitHub や CircleCI から取得することができます。開発の詳細に関しては自分の個人ブログをご覧ください。
このツールで収集したデータおよび障害の発生・復旧に関するデータを組み合わせ、 BigQuery 上で加工し、 Four Keys を週次や月次で表示できる基盤を着々と構築しています。今後はモニタリングされる Four Keys の数値から仮説を立て、施策を立案し、検証するサイクルを回していきたいと考えています。
まとめ
弊社での Four Keys の位置付けとモニタリング基盤の構築について紹介しました。 depwatch は OSS として公開しており、今後も機能の拡充を進めていく予定ですので、ニーズにマッチする方がいらっしゃればぜひご活用ください！
- PHPerKaigi 2023及び、PHPerKaigi 2023 実行委員会とは無関係のイベントです。↩
- 最新の DORA レポートは 2022年に発表されていますが、クラスターの数が4つから3つに減るなど従来のレポートと比較して大きな変化があったことから、2021年のレポートの定義を採用しています。↩
- 次のような内容のバリューです。「顧客第一になろう。それ以外の都合は２番目に置いておいて、まずはなによりユーザーを大事にすること。ユーザーが求めることの本質に応えること。長期の視点ではユーザーにもっとも価値を提供できる会社が、必ず流通革命を起こす。自分たちの作ったサービスで、ユーザーが喜ぶ瞬間は最高の時間だ。とにかく迷ったら自分達のことより、ユーザーのことを考えよう。」↩
(図：信頼できないデータ（基盤）の例、DPRプロジェクトのキックオフ資料より引用)
(図：３つのフェーズ、DPRプロジェクトのキックオフ資料より引用)
