LASSIC Media らしくメディア
DORA Four Keysで開発生産性を計測する外注
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- DORAのFour Keysが計測する4指標の定義と、指標が示すデリバリー能力の意味を整理します。
- 計測データの収集元と、個人評価への転用など誤用を避ける運用ルールを解説します。
- 計測基盤の構築・分析を外部委託する場合の委託範囲と、発注側が事前に準備すべき事項を紹介します。
目次
DORA Four Keysが計測する4指標の定義
DORA Four Keys（フォーキーズ）とは、Googleの調査プログラムDORA（DevOps Research and Assessment）が定義する、ソフトウェア開発チームのデリバリー能力を測る4つの指標を指します*1。デプロイ頻度・変更のリードタイム・変更障害率・サービス復旧時間（MTTR）の4つで構成されます。
4指標は「スループット」と「安定性」の2つの観点に分かれます*2。デプロイ頻度と変更のリードタイムはスループット（開発から本番反映までの速さ）を示し、変更障害率とサービス復旧時間は安定性（障害への強さ）を示します。
各指標の定義はGoogle Cloudの公式解説に基づきます*1。デプロイ頻度は「組織が本番環境へのリリースに成功する頻度」、変更のリードタイムは「コミットが本番環境に到達するまでの時間」です。変更障害率は「本番環境で障害を引き起こすデプロイメントの割合」、サービス復旧時間（MTTR、Mean Time To Restore）は「本番環境の障害から回復するまでにかかる時間」と定義されています。
DORAは現在、この4指標に加えて「デプロイメント再作業率」を含む5つの指標を提示しています*2。ただし実務では従来通り4指標を「Four Keys」と呼ぶ運用が広く定着しているため、本稿でもこの4指標を中心に解説します。
Elite・High・Medium・Lowという区分の現在地
Four Keysの各指標には、チームのパフォーマンスを段階分けする区分が長く使われてきました。ただし、この区分の内容は年ごとのDORA調査で変化している点に注意が必要です。
2024年版のDORA State of DevOps Reportまでは、Elite・High・Medium・Lowという4段階のパフォーマンスクラスタが採用されていました*2。同レポートでは、オンデマンドでのデプロイ・サブデイ（1日未満）のリードタイム・低い変更障害率・1時間未満の復旧時間を満たす層をEliteと位置づけていました。
2025年のDORA調査プログラムでは、この4段階のランキング形式そのものが見直されています*3。人的要因（バーンアウト・摩擦・仕事の実感）とデリバリー成果を組み合わせた「7つのチームアーキタイプ」という分類に移行し、単純な優劣ランキングとしての運用は推奨されなくなりました。
この変遷が示すのは、Four Keysの数値そのものより「自チームの過去の値からの変化」を追う運用が実務的だという点です。他社の公表区分と自チームの数値を機械的に比較する前に、どの年のどの調査に基づく区分かを確認する必要があります。
推測ではなくデータで開発プロセスを見直す理由
Four Keysを計測する目的は、開発プロセスの課題を推測ではなくデータで特定することです。「リリースが遅い気がする」という感覚的な課題認識では、どの工程を改善すべきか判断できません。
変更のリードタイムが長い場合、原因はコードレビューの待ち時間・テスト実行時間・承認プロセスの複雑さなど複数考えられます。指標を工程別に分解して計測すると、感覚では見えなかった滞留箇所が特定できます。
変更障害率とサービス復旧時間を継続的に追うと、リリース速度を上げた際に安定性がどう変化したかを確認できます。スループットの指標だけを見て安定性の指標を見落とすと、障害の増加に気づけません。DORAの調査でも、スループットと安定性は対立するものではなく両立できることが示されています*2。
計測を始める段階では、まず現状のベースライン値を把握することが出発点になります。目標値を先に決めるより、自チームの過去の値との比較から改善の方向性を判断する運用が実務的です。
Git・CI/CD・インシデント管理から指標を集める方法
Four Keysの計測データは、開発チームが日常的に使うツールから収集します。ツールを新設せず、既存の記録を集計する形が一般的です。
デプロイ頻度と変更のリードタイムは、Gitのコミット履歴とCI/CD（継続的インテグレーション・継続的デリバリー。コード変更を自動でテスト・本番反映する仕組み）のデプロイログから算出します。コミットのタイムスタンプとデプロイ完了のタイムスタンプの差分を追跡します。
変更障害率とサービス復旧時間は、デプロイ記録とインシデント管理システム（障害の発生・対応記録を管理する仕組み）の記録を突き合わせて算出します。あるデプロイが原因でインシデントが発生したかどうかの紐づけが必要になるため、デプロイIDとインシデント記録の連携ルールをあらかじめ決めておく必要があります。
Google Cloudは、これらのデータを自動収集する参考実装として「Four Keys」というオープンソースプロジェクトを公開しています*1。GitHubやGitLabのAPI、CI/CDツールのWebhookからイベントを受け取り、BigQueryに集計する構成です。自社のツール構成に合わせて収集経路を設計する必要があるため、既存の参考実装をそのまま使えるとは限りません。
個人評価への転用と指標ハックというよくある誤用
Four Keysの誤用として注意すべき代表例は、個人の評価指標への転用です。DORAの調査を主導したニコール・フォースグレン氏らは、これらの指標がチーム・システムレベルのデリバリー能力を測るものであり、個人の生産性評価に使う設計ではないと位置づけています*4。
個人単位でデプロイ頻度を評価対象にすると、レビューを簡略化して数だけ増やす、小さな変更に分割して件数を水増しするといった行動が起こります。これは「指標のハック」と呼ばれる現象で、数値は改善しても実際のデリバリー能力は向上しません。
変更障害率を個人評価に使う場合も同様の問題が生じます。障害の発生を避けるために新しい変更を控える、リスクの高い改善に着手しなくなるといった行動が誘発される可能性があります。
誤用を避けるには、指標の運用ルールを計測開始前に明文化することが有効です。「チーム・システム単位の傾向把握に限定する」「個人の人事評価と紐づけない」という原則を、計測導入時に関係者へ共有しておく必要があります。
SPACEフレームワークで補う視点
Four Keysはデリバリーの速さと安定性を数値化しますが、開発者の満足度や協働のしやすさといった要因は測っていません。この観点を補うフレームワークとして、SPACE（スペース）が提案されています。
SPACEは、Microsoft Research・GitHub・University of Victoriaの研究者らが2021年にACM Queueで発表したフレームワークです*4。Satisfaction and well-being（満足度・幸福感）・Performance（成果）・Activity（活動量）・Communication and collaboration（コミュニケーション・協働）・Efficiency and flow（効率・作業の中断のなさ）の5次元で構成されます。
提唱者らは、少なくとも3つの次元を組み合わせて測ることを推奨しています*4。Activity（活動量）だけを単独で追うと、コミット数やコード行数のような表面的な数値に偏る可能性があるためです。
Four KeysはPerformance（成果）に近い領域を定量的に扱う指標群と位置づけられます。SPACEのSatisfactionやCommunicationの観点は、サーベイやヒアリングといった別の手段で補う設計が必要です。
計測基盤構築・分析伴走という外注の委託範囲
Four Keysの計測を内製で立ち上げるには、Git・CI/CD・インシデント管理の各データを連携させる基盤構築と、指標を可視化するダッシュボードの整備が必要です。この領域を外部委託する場合、委託範囲は主に3つに分かれます。
第一に、データ収集基盤の構築です。各ツールのAPIやWebhookからイベントを取得し、指標算出に使えるデータベースへ格納する仕組みを作ります。既存のツール構成に合わせた設計が必要なため、自社の開発環境の把握が前提になります。
第二に、ダッシュボードの構築です。収集したデータを4指標として可視化し、チーム・プロジェクト単位で傾向を確認できる画面を用意します。誰が閲覧するか、どの単位で集計するかを事前に決めておく必要があります。
第三に、分析の伴走支援です。指標を導入しただけでは改善につながりません。指標が示す滞留箇所の解釈や、次の改善アクションの検討を継続的に支援する体制が求められます。
発注側が事前に準備すべき事項もあります。利用しているGit・CI/CDツールの構成、インシデント管理の運用ルール、指標を閲覧する対象者の範囲です。これらが未整理だと、委託先が収集経路の設計を進められません。内製でこの整理と基盤構築を並行して行うには、DevOpsツールの連携知識とデータ基盤構築の両方の知見が必要になり、担当者確保に時間を要します。
まとめ：Four Keys導入で押さえる3つの判断軸
本稿では、DORA Four Keysの4指標の定義・区分の変遷・計測方法・よくある誤用・外注範囲を整理しました。要点を3つに集約すると次の通りです。第一に、4指標はスループット（デプロイ頻度・リードタイム）と安定性（変更障害率・復旧時間）の両観点で構成され、両立を目指す指標です。第二に、Elite/High/Medium/Lowという区分は2024年で4段階分類が終了し、他社比較よりも自チームの過去値との比較運用が実務的です。第三に、個人評価への転用を避け、SPACEのような補完フレームワークと組み合わせて運用する設計が求められます。
よくある質問
Four Keysの計測はどのくらいの期間で効果が見えますか。
まずは数週間から数か月かけてベースライン値を蓄積する段階が必要です。データが少ない状態では傾向が判断できないため、最初の目標は「継続して計測できる状態を作ること」に置くのが実務的です。改善効果の判断は、同じ計測条件での前後比較が可能になった後に行います。
すでにあるCI/CDツールだけで計測できますか。
デプロイ頻度と変更のリードタイムはCI/CDのログから算出できるケースが多いです。一方で変更障害率とサービス復旧時間は、デプロイ記録とインシデント管理の記録を紐づける必要があり、両者の連携が未整備だと算出できません。連携ルールの設計が計測開始前の準備事項になります。
マイクロサービス構成でもFour Keysは同じように計測できますか。
サービスやリポジトリが多数に分かれる構成では、どの単位でデプロイ頻度を集計するかの設計が必要です。サービス単位で集計するか、プロダクト全体で集計するかによって数値の意味が変わるため、集計単位を関係者間で合意してから計測を始める必要があります。
Four Keysの数値が悪化したとき、まず何を確認すべきですか。
4指標のうちどれが悪化したかを個別に確認します。スループット系（デプロイ頻度・リードタイム）が悪化した場合はレビューやテストの工程を、安定性系（変更障害率・復旧時間）が悪化した場合はリリース前の検証プロセスを見直す起点になります。1つの指標だけで判断せず4指標を並べて確認することが大切です。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Google Cloud「Use Four Keys metrics like change failure rate to measure your DevOps performance」（2020年）
- *2 出典：DORA「Accelerate State of DevOps Report 2024」（Google Cloud、2024年）
- *3 出典：DORA「DORA’s software delivery performance metrics」（Google Cloud、dora.dev）
- *4 出典：Nicole Forsgren, Margaret-Anne Storey et al.「The SPACE of Developer Productivity」（ACM Queue 第19巻第1号、2021年）
