開発組織の生産性・パフォーマンス測定にFour keysの何が良いのか?

four keysとは

LeanとDevOpsの科学で紹介されたState of DevOps ReportDevOps Research and Assessment(DORA)チームの研究・調査から導き出されたソフトウェア開発チームのパフォーマンスを示す4つの指標

詳細な時系列は把握していないが、LeanとDevOpsの科学/State of DevOps Reportで提唱され、Google Cloud の DevOps Research and Assessment(DORA)チームのAccelerate State of DevOps Reportで引き続き調査や改善が行われているらしい。

完全に体感値だが開発生産性といえばだいだいこの指標、もしくはgit baseのアクティビティメトリクスなどを追っているイメージ。
関連記事や書籍はたくさん存在しているが、簡単に説明するとfour Keysとは以下4つの指標の事を指す。

  • デプロイの頻度
    • 本番環境へのリリースの頻度
  • 変更のリードタイム
    • commitから本番環境反映までの所要時間
  • 変更障害率
    • デプロイにより本番環境で障害が発生する割合
  • 平均修復時間(MTTR)
    • 本番環境での障害から復旧するのにかかる時間

デプロイの頻度と変更のリードタイムは速度の指標で、変更障害率,平均修復時間(MTTR)は安定性の指標にあたる。
four keysを改善する事の影響として、レポートや書籍では、ハイパフォーマーにおいてはデリバリーのスピードとシステムの安定性と品質がトレードオフにならない、またソフトウェアデリバリーの速度や質を改善するとビジネス上も大きなインパクトがあるという結果が示されている。

four keysの特徴としては、アウトカムを組織レベルで測定する指標であることも挙げられる。
LeanとDevOpsの科学では、以前のソフトウェア開発チームのパフォーマンス測定の問題点として、アクティビティを重視し、かつ個人などのレベルに焦点を当ててる事だと述べられており、前者のアクティビティ指標の問題点はコード量やリソース利用率、後者は速度(ベロシティ)を尺度した場合の例などで説明されている。

コード量は必ずしもパフォーマンスや生産性が高い事を示唆しない。1000行のコードを書かずとも10行のコードで解決できるのであればその方が望ましい、もしくはコードを書かずに解決出来るのであればそれでも良い。また誰も理解出来ない1行のコードよりも、理解しやすい数行のコードの方が良い。
速度に関しては、アジャイル開発で用いられるストーリーポイントやベロシティでは、チーム間の比較に利用されがち && コンテキストに依存する相対的な尺度である、と言う点が述べられている。またこれらの指標はハックする事が比較的容易なため、チーム間のコラボレーションを妨げかねないとされている。

four keysは上記問題を踏まえて、個人やチームなどのローカルなレベルではなく、組織全体/グローバルなレベルでの測定を行い、生産量ではなく成果にフォーカスすることで「価値のない、見せかけの作業」の発生や評価されることを防ぐ事が出来る指標として選定されている。

またfour keysとは言いつつ、2021年 Accelerate State of DevOps Reportでは、5番目の指標として信頼性が登場している。
今までのfour keysはMTTRも含まれてはいるがデリバリーのパフォーマンスという側面が強かったが、とはいえ実際の開発サイクルの中で運用が占める割合は大きく、信頼性を取り入れた方が正確にパフォーマンスを測ることが出来る、というのは妥当な話に聞こえる。
またデリバリーのパフォーマンス レベルの異なる複数のチームで、デリバリーだけでなく運用のパフォーマンスも重視する場合に、より優れた結果を得られることが確認されました。というのもそうだよなという感想。

この辺の話で言うと書籍やレポート自体もそうだが、texta.fmのAccelerateの回も非常に面白い
5. Accelerate by texta.fm

余談だが、デプロイ頻度は例えば2週間に1度のリリースサイクルを回している組織では、単純に頻度を出しても変化のある数値は取れないため、何らかの指標を加味して1デプロイあたりの質を測定することを目指すアイディアもある気がしている。
具体的なイメージはついてない部分は多いが、例えばコミット数、PR数、Issue数などのGitベースからより多くの機能やコードをデプロイした事の計測を目指すか、SP数やチケットのクローズ数などで機能の提供数を加味するか、もしくは顧客満足度や利用率などからどれだけユーザー・顧客に価値のある機能の提供が行えていたことの計測を加味する事は出来ないかなと最近考えている

またこちらも蛇足だが、four keysの事をアウトカムを組織レベルで測定する指標であると紹介したが、LeanとDevOpsの科学の著者の一人であるNicole Forsgren氏が筆頭著者のレポートThe SPACE of Developer Productivity: There's more to it than you think - Microsoft Researchでは、むしろ個人・チームレベルでも開発生産性を図るためのフレームワークが紹介されている。

なぜfour keys?

以下3点あると考えている。

  • ビジネス面への好影響が示されていることによる説明・導入のしやすさ
  • 車輪の再発明をしなくて済む
  • 社内を超えて比較が可能

ビジネス面への好影響が示されていることによる説明・導入のしやすさ

シンプルに説得力や会社として取り組むべき理由や意義が、ビジネスサイドにも理解・納得してもらいやすい。
エンジニアサイドはfour keysの数値が悪い開発組織をイメージしてもらえれば、一定可視化して改善に取り組むことの意味を理解してもらうのは難しくはない

車輪の再発明をしなくて済む

自社でオリジナルの何かを生み出すのも悪くはないが、過去 7 年間で、32,000 人を超える世界中の専門家が参加しているAccelerate State of DevOps Reportとあるように、単純にこれだけ多くの関係者が長期間にわたった成果であるfour keysより優れた指標を生み出せる組織はほとんどない。変に独自指標をこねくりますよりは業界のベストプラクティス・デファクトに乗るのがベター

社内を超えて比較が可能

エリート DevOps チームであることを Four Keys プロジェクトで確認する | Google Cloud Blogでもある通り、客観的に自分達がどの位置にいるかを判断・比較可能な点は大きい
State of DevOps ReportAccelerate State of DevOps Reportでも、four keysを元に「エリート」「ハイ」「ミディアム」「ロー」に組織を区分しており、自分達がどこに含まれるかを判断する事ができる。
それぞれの組織やチームのコンテキストに沿った生産性指標は存在しうると思っているが、それを追う前にまずはfour keysでエリートチームになってから考えるべきでは?と思う

まとめ

参考・関連