four keysについてと何が良いのか？

four keysとは

**LeanとDevOpsの科学で取り上げられたState of DevOps ReportやDevOps Research and Assessment（DORA）**チームの研究・調査から導き出されたソフトウェア開発チームのパフォーマンスを示す4つの指標(最近5つに増えた)
DORA metricsやfour core DevOps metricsと呼ばれる事も多い(英語記事はDORA metrics率が高いと勝手に思っている)

LeanとDevOpsの科学/**State of DevOps Reportで提唱され、Google CloudのDevOps Research and Assessment（DORA）チームのAccelerate State of DevOps Report**で引き続き調査や改善が行われているらしい。

簡単に説明すると以下4つの指標の事を指す。

デプロイの頻度

本番環境へのリリースの頻度
リードタイムの削減に加え、バッチサイズ(一度に進める作業のサイズ)削減もリーン手法の目玉の一つ
- サイクルタイムの短縮
- フローにおける変動の軽減
- フィードバックの高速化
- リスクと諸経費の低減
- 効率
- モチベーション
- 緊急性の認識の向上
- コストとスケジュールの膨張の抑制
しかしソフトウェアの場合はバッチサイズの測定が難しい
そのため代わりにデプロイ頻度を測定基準として選定
- デプロイ頻度の方が測定が容易 && 変動も小さい
- また厳密にいえばバッチサイズとデプロイ頻度には逆の相関関係がある
  - デプロイ頻度を上げるとバッチサイズが小さくなる
    - 参照: forsgren and bumble2016

変更のリードタイム

commitから本番環境反映までの所要時間
リードタイムの削減はリーン手法の目玉
- 顧客のリクエストから満たされるまでの所要時間
リードタイムは二つの部分に分けられる
- 設計と検証にかかる時間
  - 計測をいつ始めるかが明確でない。また見積もりも結果の変動も非常に大きい
- 納品するための時間
  - 測定が比較的容易で変動も小さい
上記理由から後者のデリバリに関するリードタイムを測定指標として選定
リードタイムは短ければ短いほどいい
- 速度だけでなく、障害復旧も迅速になる

変更失敗率

デプロイ・リリースにより本番環境での稼働に失敗した割合
- 機能障害や稼働停止、ホットフィックスやロールバック、フィックスフォーワード(事態改善のための修正、hotfixよりは通常の開発フローに含まれる)、パッチが必要となったケースの発生率を調査

平均修復時間(MTTR)

本番環境での障害・サービス影響を与えるリリース失敗から復旧するのにかかる時間
安定性・信頼性に関する指標がなければ、単に安定性を犠牲する結果となる
また複雑なシステムが急速に変化する現代のソフトウェア開発において、障害は不可避。であればいかに迅速に復旧できるかにフォーカス

デプロイの頻度と変更のリードタイムは速度の指標で、変更障害率,平均修復時間(MTTR)は安定性の指標にあたる。　　

**2021年 Accelerate State of DevOps Reportでは、5番目の指標として信頼性が登場し、調査結果としてデリバリーのパフォーマンスレベルの異なる複数のチームで、デリバリーだけでなく運用のパフォーマンスも重視する場合に、より優れた結果を得られることが確認された**と報告されている

State of DevOps Reportについて

そもそもの前提

software is eating the world
ソフトウェアテクノロジーは価値を提供する際の重要な差別化要因で、あらゆる種類の組織に変革と加速化をもたらしている
- james BessenによるBessen 2017では、テクノロジーの戦略的活用の方がM&Aや起業家精神よりも収益や生産性の向上に寄与する割合が大きいことを示した
- andrew mcafeeとEric brynjolfssonが行なった研究も同様で、テクノロジーと収益性の関連が浮き彫りに

そんな状況において以下のような疑問を解明し、「統計的に優位な方法でパフォーマンスの改善を促すケイパビリティを特定・理解する方法を確立する」ことが目的で調査が行われた

「ハイパフォーマンスな技術系組織を生み出す要因は何か？」
「ソフトウェアは組織をどのような形で改善しうるのか」
「ソフトウェア開発とデリバリーを高速化し、ひいては組織全体への価値提供をも高速化する効果が高いのはどのようなプラクティスとケイパビリティなのか？」

判明したこと

プロセスの質を上げれば速度も安定性も向上する
速度と安定性はトレードオフではない　
- ハイパフォーマーはどの尺度でも優れている
- 安定性の欠如が速度低下にも影響
  - 障害多発していたらその分開発速度にも影響するよね
組織のソフトウェア開発能力が収益性、生産性、市場占有率を左右する
組織文化と技術的プラクティスも重要であり、両者がパフォーマンスに与える影響度も測定できる
2,3年、ハイパフォーマー集団が他の集団を引き離し続けている
- DevOpsの理念である継続的改善に効果があることの証左
- 常に改善し続けないとおいて行かれてしまうことも示唆

four keysを改善すると何が嬉しい？

調査では、four keysの数値をベースにハイ・ミドル・ローパフォーマーと集団に分類し、それらの集団において組織のビジネス上のパフォーマンスとして選択した以下3つの指標がどのような結果となっているかを検証している。

収益性
市場占有率
生産性

結論として、ソフトウェアデリバリーの速度や質を改善すると、上記ビジネス上のパフォーマンスにも大きなインパクトがある(収益性や市場占有率なども高い傾向)という結果が示された
→ 「組織のソフトウェアデリバリのケイパビリティは組織に競争上の優位性をもたらす」
→ 「ハイパフォーマーは商品やサービスの量、作業効率、顧客満足度、製品やサービスの質、組織での目標達成度で他集団を上回る傾向があり、その対比は2倍を超える」

上記の通り、組織パフォーマンス”とソフトウェアデリバリーの能力には明確な関係性があるため、four keysを測定し、継続的に改善することで、速度と安全性の両方を向上させ、またそれによりビジネス上の競争優位を獲得することに繋がる、と言うのがfour keysを測定・改善して嬉しい点の一つ。

個人的には前述した通り、four keysの特に速度に関する指標(デプロイ頻度、リードタイム)は、成功回数 = 試行回数(時間・人数 / 一回の試行にかかる時間) * 成功率の式のうち、それぞれ試行回数、一回の試行にかかる時間と捉える事が出来、これらを改善し試行回数を増やす事で、成功回数を増やし、ビジネス上の競争優位獲得する事が、four keysを改善する何よりのモチベーションだと捉えている。
安定性に関しても、システムや企業への信頼性ももちろんのこと、安定性の欠如が時間・人数の減少に影響し、それにより試行回数を落とす事にも繋がるため、速度とも大きく関連している。

four keysと従来の測定手法の差分

従来の測定手法の問題

以下2点

成果(アウトカム)よりも出力(アウトプット)に焦点を当てている
チームなどグローバルなレベルではなく、個人などローカルなレベルでの測定に焦点を当てている
従来の測定手法の例
- コード量(counting the number of lines of source code)
  - 現実的には1000行より10行で解決できる方が良い
    - 無駄に規模が増加し、保守と変更のコスト増を招く
  - とはいえ書いた本人以外が読めない1行のコードよりも、誰もが理解可能な10行のコードの方がまし
  - 共通ライブラリを作成したり、コードを共通化する事はネガティブに解釈される
- 速度(ベロシティ)
  - 本来は「キャパシティ計測の立案ツール」として使うべき
    - 計画され見積もられた作業を完了するのに要する時間について対象のチームが推定するのに使う
  - なぜ生産性の測定基準にするのが問題なのか？
    - チーム依存の相対的な尺度でしかない
      - チームを巡る状況はケースバイケース
        
        チーム同士で比較もできない
    - ベロシティ・SPはハックが容易
      - 見積もりをいじれる
      - 自チームのベロシティ・SP消化だけを追い求め、他チームとのコラボレーションを犠牲にする
        
        オンコールへの参加が消極的とか
- 利用率・リソース効率
  - 一定レベルを超えると余力がなくなり予想外の仕事や計画変更を入れる隙がなくなる
    - 結局はリードタイムが長くなる
  - 数学の待ち行列の理論
    - 利用率が100%に近づくにつれて、リードタイミは無限大に調べる
  - リードタイムとバランスをとり、全体の仕事が効率的に行われるように管理することが重要

望ましい測定手法

グローバルな成果に焦点を当て、チーム間の競争や対立を招かない
- スループットの多い開発者と安定性向上に寄与した運用担当者の奨励は従来の典型的なやり方
  - 混乱の壁の主な誘因となる
    - 開発と運用を隔てる縦割の壁
  - 開発チームが質の悪いコードを大量に書き、運用チームは修正を阻む
- 生産性の測定はコンテキストがすべて
  - プロジェクトはそれぞれ異なり、顧客基盤もユースケースもペルソナも、そしてチームの役割や立場も異なる
生産量ではなく成果に焦点を当てる
- 忙しいが価値のない見せかけの作業を推奨するべきでは無い

four keysは、上記基準を満たす指標として選定された

なぜfour keys？

従来の測定指標との差分以外にもなぜfour keys？を考えてみる。個人的に大きいのは以下3点

ビジネス面への好影響が示されている
車輪の再発明をしなくて済む
社内を超えて比較が可能

ビジネス面への好影響・関連が示されている

シンプルに説得力や会社として取り組むべき理由や意義が、ビジネスサイドにも理解・納得してもらいやすい。
エンジニアサイドに対しては、four keysは現代のソフトウェア開発における多くのトレンドやプラクティスに沿っているため、four keysの数値が悪い開発組織をイメージしてもらうだけでも、一定可視化して改善に取り組むことの意味を理解してもらいやすいと感じている

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

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

社内を超えて比較が可能

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

エリート DevOps チームであることを Four Keys プロジェクトで確認する

Take the DORA DevOps Quick Checkというツールもある

補足

four keysは企業間での比較も考慮した値になっているため、各社毎のコンテキストに依存しないような設計がされている。　　
しかしインパクトと結果に焦点を当てるべきという考えに立つのであれば、ビジネス指標などを生産性・パフォーマンスの測定基準として選定することは有用な選択肢の一つ。
例えばNetflixではインパクトと結果に焦点を当てるべきという考えの元、何よりも顧客満足度を重視しており、生産性・パフォーマンスの測定基準としても採用されているとのこと。
-> 何かをどのように提供するかも重要だが、提供されたもののインパクトが最終的にもっと重要

蛇足

four keysの事を**アウトカムを組織レベルで測定する指標であると紹介したが、LeanとDevOpsの科学の著者の一人であるNicole Forsgren氏が筆頭著者のレポートThe SPACE of Developer Productivity: There's more to it than you think - Microsoft Research**では、個人でも開発生産性を図るためのフレームワークが紹介されている(厳密に言うと個人・チーム・システムレベルの三軸)。