Four keysとは
Four Keysとは、一連の開発作業からそれが本番に反映されるまでのフルサイクルのパフォーマンスを測DevOpsの指標です。Google Cloud の「エリート DevOps チームであることを Four Keys プロジェクトで確認する」では以下のように記載されています。
- デプロイの頻度- 組織による正常な本番環境へのリリースの頻度
- 変更のリードタイム- commit から本番環境稼働までの所要時間
- 変更障害率- デプロイが原因で本番環境で障害が発生する割合（%）
- サービス復元時間- 組織が本番環境での障害から回復するのにかかる時間
引用：https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance
Four keysが注目を集める背景
Google が2019年に提唱する以前までは、フルサイクルのパフォーマンスを測る統一されたグローバル基準というものはありませんでした。そのような中でGoogleからこのような指標が発表されたことで、Four Keysを指標とする会社が増えてきている背景があります。
2019年以前はDDD数（deploys / a day / a developer）という、デプロイ数をエンジニア数と稼働日で割った指標を採り入れる組織や、GitHubのプルリクエスト単位の消化数、JIRAのストーリーポイント消化数など、Developの部分だけ（Opsは関係なく）計測していた組織もありました。
ただプルリクエストの消化数はチケットの粒度によって異なり、ストーリーポイントの定義も各社さまざまです。結果的に、DDD数は開発サイドやマネジメントサイドに寄りかかってしまう数値となり、他社と比較できる物差しにはならない課題がありました。
こういった背景の中、Four Keysであれば、安定したリリースや保守の観点を含めたDevOpsというフルサイクルを投資的な基準で捉えることもできるため、特にシリーズB以降のスタートアップやメガベンチャー、大手から注目を集めている傾向があります。
Four keysが必要な会社とは？
Four Keysは計測の手間が大きなネックになります。たとえばリードタイムを図るようなツールを導入したり、GitHubのアクティビティを全部集計する準備と運用体制が必要になり、組織の体力も必要になります。
障害率に関しても障害についての定義を定めたり、ポストモーテムの取り組みなどが必要になります。発生した障害に対して対応時間を計測する必要もあるので、チームとして一定の成熟した段階ではないと、諸々の指標はうまく計測・運用がいかないでしょう。
Four keysは採用効果になり得るか？
Four Keysは、Elite/High/Medium/Lowという4つのグレードで評価します。EliteであればDevOpsチームの一連のサイクルが健全であると示せますが、採用のアトラクトにはそれ以外にプロダクトの魅力であったり、会社のミッション・ビジョン、働く環境などもあるので、Four Keys自体が採用に直結するかについては懐疑的です。
ただ、Four Keysでの指標が高ければ、それだけプロダクティビティが高くなるようなエンジニアリング体制が整っていることを示せるので、ブランディングの一環としても外部発信することには一定の価値はあるはずです。
引用：https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance
overflow社の取り組み
Offersを運営するoverflowでも2021年からFour Keysを導入し、エンジニアのOKRとして運用しています。
実はFour Keys導入以前、overflowではエンジニアのOKRをスプリントのチケット消化数やデプロイ数に重きをおいてきましたが、これらの指標はどうしても外部要因に影響してしまう課題がありました。
例えばチケットの消化数であれば、PdMチームのレビューに時間がかかると変更を余儀なくされます。リリースの前に画面確認したら「もうちょっとこの要素をつけたいよね」という改善サイクルの中で当たり前に行われることが、結果的にその指標を満たさないというマイナスになってしまう結果になっていました。
そのため外部要因に縛られずに、DevOpsのサイクルの中で統一できるような指標は何かないかと検討し、Four Keysを導入。Four Keys導入後の変化について、overflowCTOの大谷は以下のように語ります。
「チームの今の健全性であったり課題について、数値ベースで明確に測れるようになったので、改善策も打ちやすくなりました。一方で、数値を正確に把握するためにモニタリングをちゃんと整理する必要があるなと再認識できました。」
大谷氏のコメントのように、計測についてまだ課題はあるものの、開発組織の健全化に向けて一定の手応えを感じているようです。また今後の活用法として、Four Keysを公開することで採用のアトラクトにも応用できないかという狙いもあるそうです。
Four keysの誤った使い方
Four Keysを導入して一番やっていけないのが、数値をもとにした組織内での競争です。たとえばA社の中でアプリチームとWEBチームが存在し、それぞれでFour Keysを計測したとします。APPではEliteを取得し、WEBはMiddleであった場合、APPチームの方が優秀であるかといえば、答えはノーです。
マネジメント上、チーム間の数値を絶対値として比較するのは好ましくありません。各チームでコンテキストが異なるため、あくまで全社的な目線で考えていきましょう。
参考URL
https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance
コメント
0件のコメント
サインインしてコメントを残してください。