ハイパフォーマンスな開発チームはどんな能力を備えており、それはどのような指標で説明できるのかという調査が毎年行われているらしい。
その調査結果が結構面白かったので簡単にまとめてみました。
以下のような話題が含まれています。

  1. 調査の手法について(ごく簡単にだけなので気になる方は最後に紹介している書籍をどうぞ)
  2. ハイパフォーマンスなソフトウェア開発組織に備わっているケイパビリティ(能力)
  3. ソフトウェア開発組織のパフォーマンスの高さを説明する4つのキーメトリクス

DevOps Research and Assessment(DORA)とは

DORAと呼ばれる調査が毎年実施されState Of DevOpsというレポートが公開されている。
調査の主体は以下の2チームが合同で取り組んでいるらしい。
当初の調査目的は「高業績の技術系組織を生み出す要因は何かを解明したい」というようなものだったらしい。

  • Google Cloudの内部にあるチーム
  • Puppet社

調査手法概要

具体的数値は2017年頃のもの

  • アンケート調査によるデータ収集を実施
    • スノーボールサンプリング(口コミ)
    • 回答数: 23,000名 2,000社以上
    • 回答者の組織のパフォーマンスもこのアンケートの「収益性」「市場占有率」「生産性」の3つの項目への回答で判定(先行研究あり)
  • 計量心理学の潜在的構成概念と統計学の推計予測的分析を用いて仮説検証を実施
  • 階層的クラスター分析を用いてハイ・ミドル・ローの3つのパフォーマンス群を得た
    • 2021年では群は4つに増えている(理由は不明)

調査結果概要

組織のパフォーマンスを改善する効果の高い以下の24のケイパビリティが見つかったとされている。

  • 継続的デリバリ
    • 成果物のバージョン管理
    • デプロイの自動化
    • 継続的インテグレーションの実装
    • トランクベース開発
    • テスト自動化
    • テストデータの適切な管理
    • 情報セキュリティのシフトレフト
    • 継続的デリバリの実践
  • アーキテクチャ
    • 粗結合なアーキテクチャ
    • チームがツールを選択できる権限を持つ
  • 製品とプロセス
    • 顧客フィードバックの収集・活用
    • 全業務プロセスの作業フローの可視化
    • 作業の細分化
    • チームによる実験の奨励
  • リーン思考
    • 負担の低い変更承認プロセス
    • 意思決定におけるアプリ・インフラのモニタリング結果の活用
    • システム健全性の予防的なチェック
    • WIP制限によるプロセス改善と作業管理
    • 作業の可視化による品質の監視と相互コミュニケーション推進
  • 組織文化
    • (Ron Westrum の)創造的な組織文化の育成
    • 学びの奨励と支援
    • チーム環境業の支援と促進
    • 有意義な仕事を可能にするツール等の資源の提供
    • 改善を促進するリーダーシップの実現や支援

また開発チームのパフォーマンスを測定する計測可能なメトリクスとして以下の4つが利用可能らしいことも発見された。

  • 変更のリードタイム
  • リリース頻度(バッチサイズ)
  • サービスの停止や品質低下を引き起こすような致命的障害の発生率
  • 障害発生時の復帰時間(MTTR)

調査への指摘

後述の書籍のなかでマーティン・ファウラーが以下の指摘をしている。
個人的にももっともな指摘だなあと感じています。

  • アンケート調査のサンプル集団が広く一般のIT業界の実態を反映していると言えるのか
    • 実際にCIやInfrastructure As Codeなどの用語を知らないという(ローパフォーマー群より更に低いと想定される)データは利用していないらしい
    • DevOpsを推進するべきという自説のために「確証バイアス」がかかっている可能性
    • 別の研究チームの異なるアプローチによる研究結果が必要
  • 調査の対象がソフトウェアのデリバリに限られている
    • ソフトウェアの開発にはもっといろいろな要素がある(要件定義など)

従来の評価メトリクスと今回の4メトリクスの比較

  • 既存のメトリクスは組織としての成果より単純なアウトプット量に焦点を当てがち
    • ステップ数
      • 巨大なソースコードや無意味に行数を圧縮したソースコードなど、多くても少なくても悪影響が考えられるので相関しないだろう
    • (スクラムの)ベロシティ
      • 異なるチーム間でベロシティを比較不可能
      • チームがベロシティを悪用するインセンティブを与える(ベロシティは比較的容易に操作可能なので)
    • 稼働率
      • 一定以上高くなると余力がなくなり逆に生産性が下がる(緊急度も重要度も高いタスクへの対応など)
  • 4つのキーメトリクス
    • 組織の成果に影響を与えていることが統計的有意に確認されている
    • チーム間の相対的な比較にも利用できる
    • 自己申告でもシステム化でも容易にメトリクスを採取できる
    • 速度にも安定性にも焦点を当てているので開発チーム・運用チーム間の対立を産まない

4メトリクスの詳細

変更のリードタイム

  • 定義
    • 実装開始からテストを経て本番環境へのリリースが完了するまでの時間
    • 仮説検証や機能・UIの設計などの（いわゆる）上流側で消費される時間は含まない
      • この部分は不確実性が高く計測に向かないため
  • パフォーマンスとの因果
    • 顧客に素早く価値を届けられる
    • フィードバックに基づく方針変更が素早く行える
    • 障害発生時の修正の反映も迅速になる
  • クラスタ間の比較
    • 2017年調査では高パフォーマンス群ではリードタムが平均1/440 になる
    • 2021年調査ではその差が1/6570になる

リリース頻度

  • 定義
    • 一度のリリースで行う変更の大きさ
      • ソフトウェアの場合測定が困難…
    • 代わりにリリースの発生頻度を採用
  • パフォーマンスとの因果
    • サイクルタイムの短縮によりフィードバックを高速に回す
    • 小さな変更であれば定型化、自動化が容易になる
    • 1回のリリースあたりの変更量をへらすことによって問題発生時の原因特定と修正を迅速にする
  • クラスタ間の比較
    • 2017年調査では高パフォーマンス群ではデプロイ頻度が46倍になる
    • 2021年調査ではその差が973倍になる

障害発生率

  • 定義
    • リリースを行った際にサービスの低下・停止を招くような障害が発生する確率
  • パフォーマンスとの因果
    • 機会損失の低減
      • 異常を検知できるような監視が行えているかどうか
    • 顧客満足度の維持
    • 成果物であるソフトウェアの品質そのもの
  • クラスタ間の比較
    • 2017年調査では高パフォーマンス群では障害発生率が1/5になる
    • 2021年調査ではその差が1/3になる

サービス復帰時間(MTTR)

  • 定義
    • ソフトウェアに問題が発生してからそれが解消されるまでにかかった時間
  • パフォーマンスとの因果
    • 機会損失の低減
      • 早期の異常検知ができているかどうか
    • 顧客満足度の維持
  • クラスタ間の比較
    • 2017年調査では高パフォーマンス群ではMTTRが平均1/170 になる
    • 2021年調査ではその差が1/6570になる

4つのキーメトリクスの測定

  • 基本的にはチーム内のメンバーへのヒアリングによって測定できる。
  • いくつか補助ツールが提供されている
    • 自分たちが同じ業界内でどのくらいの位置にいるのか クイック チェック
    • 4つのキーメトリクスを可視化するためのダッシュボードを構築するプロジェクト Four Keys
      • Githubなどと連携させることでメトリクスの自動収集も可能っぽい

4つのキーメトリクスに基づくチーム評価の推移

詳細は後述のレポート内で確認できるが、DevOpsなどの広がりによってこれらの指標は業界全体でも向上し続けている。
いずれはこの指標では統計的にチームの生産性を評価できなくなってくるのだろうか…？

  • 年を経る毎に中間パフォーマンスの層が高パフォーマンスの層に移行している
  • 業界全体のてきにこの4つのメトリクスは改善傾向にある

参考資料

(レポート)https://www.devops-research.com/research.html

(翻訳レポート)https://www2.circleci.com/jp-puppet-2021-state-of-devops.html

(原本) https://www.amazon.co.jp/dp/B07B9F83WM/ref=cm_sw_r_tw_dp_CGEYFV43Q3TDZY8ZF7Q7

(翻訳本) https://www.amazon.co.jp/dp/B07L2R3LTN/ref=cm_sw_r_tw_dp_F8XB42NBP4NQYFY9MC6E