去る2022年9月29日（アメリカ時間）にState of DevOps 2022が公表されました。
State of DevOpsとは、年に1回DORA（Google Cloud内のチーム）が発表しているソフトウェアのデリバリーパフォーマンスに関する調査結果レポートです。State of DevOpsでは、ソフトウェアデリバリーパフォーマンスの指標でもあるFour Keysや、Four Keysの改善効果が高いとされるケイパビリティについての詳細な内容が記載されています。
株式会社ビズリーチでは、日々プロセスをより良くするための活動を行っており、今回State of DevOps 2022の発表に伴い私が所属するプロセス改善部内でState of DevOps 2022に関する調査と議論を行いました。今回はプロセス改善部でまとめた内容を前編と後編の2部に分けて紹介したいと思います。
後編では、State of DevOps 2022およびFour Keysに対するプロセス改善部としての考えを紹介します（前編はこちらをご覧ください）。
なお、本記事ではElite、Highなど高パフォーマンスクラスターを総称して「Elite」と表記します。
State of DevOps 2022を受けて
今回State of DevOps 2022が発表されたのを機にプロセス改善部メンバーの協力のもとレポートを翻訳し、実施している施策を見直す必要があるのか議論しました。
私たちは計測を通して開発組織の現在位置を把握し、改善を進めるという改善サイクルを回していきたいと考えています（改善サイクルについての詳細は後述します）。
State of DevOps 2022ではEliteクラスターの除外や運用性を加えたクラスター分析、過去の結果を覆す調査内容など新しい発見がありました。
一方、これらの変更は改善サイクル自体には影響がないため、施策の方向性に変更はないという結論になりました。
Four Keysと向き合うとはどういうことか
プロセス改善部では改めてFour Keysについて議論し、計測活動を進める上で大事にしていきたいことをチームで確認したので紹介したいと思います。
Four Keysとケイパビリティで現状を把握する
前提として、改善活動を効果的に実施するには「事実を元に仮説を立て、仮説に基づいた対策案を実施し、その結果を計測した上で更に仮説を立てる」という改善サイクルを繰り返すことが有効であると考えています。この改善サイクルを表したのが下の図です。
仮説を立てるためにはデータ（事実）を計測することが重要ですが、どんなデータを集めればいいでしょうか？私たちは、State of DevOpsが提唱しているFour KeysとFour Keysの改善に効果的とされるケイパビリティ（以降ケイパビリティ）に着目し収集しています。
Four Keysによって現状を数値で定量化し、ケイパビリティによって組織の「強み」と「弱み」を定性的に把握します。
仮説を立てる上で定量・定性両方のデータがあることで確度の高い仮説を出すことができます。そのため、どちらか片方ではなくFour Keys・ケイパビリティ両方のデータを集めることが重要だと考えています。
こうして把握した事実からは、仮説を立て、対策案を考える材料が得られます。対策案を実施したあとは、またFour Keysを計測することで現状がどのように変化したか定量化し、次のアクションへとつなげられます。
前述の改善サイクルについてはDevOpsDays Tokyo 2022で登壇した際に説明しているのでよければご覧ください。
なお、State of DevOps 2022ではFour Keysのクラスターの見直しがありましたが、この改善サイクルを実行するという我々の行動には影響がないと考えています。
「Eliteになる」ことは計測の目的ではない
改善サイクルを回す上で注意すべきことがあります。
それは、計測自体が目的となってしまい、自分たちの「目指す姿」を見失っていないかということです。本来計測は何かしらのゴールに向かうための手段のはずです。ところが、計測することに注力しすぎるあまり、自分たちがどこに向かって改善を進めているのかわからなくなってしまう場合があります。
また、計測自体に目をむけすぎてしまうと、「Eliteになる」（Four Keysで高いパフォーマンス数値を出すこと）ことが目的になってしまう恐れがあります。
「Eliteになる」ことが目的だと改善活動を進める軸が「Four Keysの数値が改善するか否か」になる場合があります。
これは、プロダクトや事業の目的を考えると本来はすべき施策なのに、短期的にFour Keysの数値が悪化することを恐れるあまり優先度が落ちる可能性があるということを意味しています。
例えば、今まで十分に実施できていないリグレッションテストの拡充などの施策は短期的には変更リードタイムの増加に繋がり、優先度が落ちてしまうかもしれません。
これらを回避するには、下図のように自分たちの「目指す姿」を明確にすることが必要だと考えています。
加えて、改善サイクルを回す度に、自分たちの活動が「目指す姿」に近づいているのか確認し軌道修正をしながら進めていくことも重要です。
私たちの考えは決して「Eliteになる」ことを否定している訳ではありません。State of DevOpsでもFour Keysと組織パフォーマンスに相関関係があることは毎年言及されています。
一方で、Four Keysは自分たちの立ち位置を把握し改善を促す手段の一つです。
手段が目的化しFour Keysの数値を上げることがゴールになってはいけないと考えています。
「目指す姿」は自分たちで考えなければいけない
では目指す姿はどうしたら見つかるでしょうか？
残念ながら、それは自分たちで定めるしかありません。なぜなら、目指す姿はプロダクトや組織を取り巻く環境によって異なるためです。
例えば
- 「お客様からの信頼を落とさずに、価値を提供し続ける」
- 「今は市場不具合を減らすのが最優先」
など、状況により目指す姿は様々です。
昨今、Four Keysの計測については多くの記事が発信されているので参考にできる部分も多いと思います。
一方、計測を通してどんな姿になりたいかは自分たちで考える必要があります。
本記事のサブタイトルは「Four Keysと向き合うとはどういうことか」ですが、Four Keysと向き合うとは、自分たちの「目指す姿」は何なのかと向き合うことだと考えています。
終わりに
株式会社ビズリーチでは前述した通り「ファクトを元に改善活動を進める」文化を作るための施策としてFour Keysおよびケイパビリティの計測を引き続き進め、活動内容について継続的に発信していきます。直近では、プロセス改善部の高橋と内藤が今後の活動構想についてRSGT2023にて発表予定です。
最後に前編含め、本記事はプロセス改善部の皆さんの協力もあって書き上げることができました。
特に衣笠さんと角田さんにはState of DevOps 2022の翻訳作業から共にしていただき大変感謝しております。
