Four Keysとは｜DORA 4指標の定義・計算方法とベンチマーク

Four Keysとは、DevOps（開発と運用の連携）チームのソフトウェア開発パフォーマンスを、4つの指標で定量化するフレームワークです。GoogleのDORA（DevOps Research and Assessment）チームが長年の調査から導き出したもので、書籍『LeanとDevOpsの科学（Accelerate）』でNicole Forsgrenらが体系化しました。感覚に頼りがちな「開発チームの生産性」を、デプロイ頻度・変更のリードタイム・変更失敗率・サービス復元時間という測定可能な数値に置き換えられる点が、現場に広く採用されている理由です。この記事では4指標それぞれの定義と計算方法、自チームの現在地を測るベンチマーク、そしてGoogleのオープンソース「Four Keys」を含む計測方法までを整理します。

まとめ：Four Keysの要点

• Four Keys＝DORAの4指標。デプロイ頻度・変更のリードタイムが「スループット（速さ）」、変更失敗率・サービス復元時間が「安定性（品質）」を表す。
• 4指標は速さと安定性のトレードオフではなく両立することが調査で示されており、上位チームは両方が高い。
• Elite / High / Medium / Lowの4クラスタで自チームの位置を把握できる。区分の境界値は年度版で変わるため公式レポートで確認する。
• 計測はGoogleのOSS「Four Keys」（GitHub/GitLabのイベントをBigQueryに集約しGrafanaで可視化）や、Findy Team+・Datadog・GitLabの標準機能で自動化できる。
• 単独の指標だけを追わない。4指標をセットで見ないと、デプロイ頻度だけ上げて失敗率が悪化するなど誤ったシグナルになる。

Four Keysの定義と全体像（DORAが提唱した4指標）

Four Keysは、DORAが6年以上のグローバル調査で「ソフトウェア開発組織のパフォーマンスを最もよく説明する」と特定した4つの指標を指します。狙いは、開発のスループット（変更をどれだけ速く届けるか）と安定性（届けた変更がどれだけ壊れないか）を同時に測り、どちらか一方に偏らないバランスで開発力を評価することにあります。かつては「速さを追うと品質が犠牲になる」と考えられていましたが、DORAの分析では上位チームほど両立できており、スループットと安定性は二者択一ではありません。

Four Keysは特定のツールや手法ではなく「何を測るか」を定めた指標セットです。そのため、ウォーターフォールかアジャイルかといったウォーターフォール・アジャイル・スクラムの開発手法の違いを問わず適用でき、CI/CDを整えたチームの改善サイクルの共通言語として使われます。なお2021年以降のDORAレポートでは、可用性を測る5つ目の指標「信頼性（Reliability）」も補助的に加えられています。

Four Keysの4つの指標と計算方法

デプロイ頻度（Deployment Frequency）

本番環境へコードをデプロイ（リリース）する頻度です。「1日に何回」「週に何回」といった単位で数え、値が高いほど小さな変更を継続的に届けられている＝バッチサイズが小さいことを示します。上位チームはオンデマンド（必要なときに1日複数回）で、下位チームは月1回〜数か月に1回にとどまります。計測は本番デプロイのイベント数をそのまま数えるだけで、4指標の中で最も取得しやすい値です。

変更のリードタイム（Lead Time for Changes）

コードをコミットしてから、その変更が本番環境で稼働するまでの所要時間です。要件定義からではなく「コミットからデプロイまで」を測る点に注意します。短いほどレビュー・テスト・デプロイのパイプラインが滑らかで、手戻りや待ち時間が少ないことを意味します。バージョン管理のコミット時刻と本番デプロイ時刻の差分から算出し、多くの変更の中央値で見るのが一般的です。

変更失敗率（Change Failure Rate）

本番へのデプロイのうち、障害を招き修正対応（切り戻し・ホットフィックス・パッチ適用など）を必要としたものの割合です。計算式は「失敗したデプロイ数 ÷ 全デプロイ数 × 100」。たとえば月20回のデプロイで2回が切り戻しになれば10%です。開発中に見つかったバグ件数ではなく、あくまで本番リリース起点の失敗を数えるのが定義のポイントで、テスト工程で防いだ不具合は含めません。値が低いほどリリースの信頼性が高いことを示します。

サービス復元時間（MTTR／失敗したデプロイの復旧時間）

本番で障害が発生してから、サービスを正常な状態に復旧させるまでの時間です。従来は平均復旧時間（MTTR：Mean Time To Restore）と呼ばれ、2024年のDORAレポートでは「失敗したデプロイの復旧時間（Failed Deployment Recovery Time）」へと名称が整理され、位置づけも見直されました。障害ゼロを目指すのではなく「壊れても素早く戻せるか」を評価する指標で、上位チームは1時間未満で復旧します。インシデントの検知時刻と解消時刻から算出します。

パフォーマンスのベンチマーク（Elite／High／Medium／Lowの目安）

DORAは4指標の水準から、開発組織を上位からElite・High・Medium・Lowの4クラスタに分類します。以下はDORA 2021／2022年版レポートで示された代表的な目安です。自チームの数値をこの表と照らして「どのクラスタか」「どの指標が足を引っ張っているか」を把握するのが基本的な使い方です。

ただし各クラスタの境界値はレポートの年度版ごとに見直されます。とくに変更失敗率の区分は変動が大きく、2024年版では中位群の失敗率が上位群を下回るなど、4指標が必ずしも同じ方向に動かない年もありました。最新の正確な区分はGoogle Cloudが公開するDORAレポート（公式）で確認してください。数値を絶対視するより、四半期ごとに自チームの推移を追うほうが実務的です。

Four Keysの計測方法とツール

4指標はいずれもデプロイ・変更・インシデントの記録から算出するため、まずはCI/CDでリリースイベントが残る状態が前提になります。Azure PipelinesでCI/CDパイプラインを組む手順のように、コミットからデプロイまでを自動化しておくと、リードタイムやデプロイ頻度の元データが自然に蓄積されます。

Google Four Keys（OSSダッシュボード）の仕組み

Googleが公開するオープンソースの「Four Keys」プロジェクト（github.com/dora-team/fourkeys）は、4指標を自動集計するダッシュボードを構築できます。なおこのリポジトリは2024年1月にアーカイブされ現在は公式には保守されていませんが、コードは公開されており、フォークして自前運用したり仕組みの参考にしたりできます。仕組みはWebhookでイベントを受け取るパイプラインで、GitHubやGitLabのコミット・デプロイ・Issueといったイベントを取り込み、それぞれをchanges（変更）／deployments（デプロイ）／incidents（インシデント）に分類してBigQueryへ格納します。たとえばGitHubのコミットはchanges、Cloud Buildのデプロイはdeployments、「incident」ラベルの付いたIssueはincidentsとして解釈されます。集計結果はGrafanaのダッシュボードで可視化され、Google Cloud上に構築します。HTTPリクエストを出せるツールなら拡張して連携できる汎用パイプラインである点が特徴です。

SaaS・既存ツールでの計測（Findy Team+／Datadog／GitLab）

自前構築の手間をかけずに済ませたい場合は、DORA metricsを標準搭載するサービスを使います。Findy Team+はGitHub/GitLab連携で4指標を可視化する国内向けサービス、DatadogはCI Visibility内でDORA Metricsを提供、GitLabはValue Stream管理の一部としてDORA metricsを内蔵しています。既にこれらのツールを導入済みなら、追加構築なしで計測を始められます。ツール選定では、自社のリポジトリ（GitHub/GitLab）とデプロイ基盤に連携できるか、インシデント管理と紐付けて変更失敗率・復元時間まで取れるかを確認します。

Four Keys運用の落とし穴（ノルマ化と単独指標の罠）

Four Keysは強力ですが、使い方を誤ると逆効果になります。最大の落とし穴は指標を「達成すべきノルマ」にしてしまうことです。デプロイ頻度を評価対象にすると、意味のない空デプロイで数字だけ上げる、といった歪みが起きます（測定値が目標になると指標として機能しなくなる、いわゆるグッドハートの法則）。Four Keysはあくまでチームの改善のための健康診断であり、個人の人事評価やチーム間の順位付けに使うべきではありません。

もう一つは、単独の指標だけを見ることです。前述のとおり4指標は連動しないことがあり、デプロイ頻度が上がっても変更失敗率が悪化していれば改善とは言えません。必ず4指標をセットで確認します。また、デプロイ頻度が月数回のチームが無理に「1日複数回」を目指す必要はありません。まずリードタイムのボトルネック（レビュー待ち・手動テスト・手動デプロイ）を1つずつ自動化し、その結果として頻度が上がる、という順序が現実的です。品質面ではCI/CDパイプラインでの脆弱性スキャンのようにデプロイ前の検査を組み込むことで、変更失敗率の悪化を抑えられます。

よくある質問（FAQ）

Four Keysとは何の略で、誰が提唱したものですか？

Four Keys（フォーキーズ）は「4つの主要な指標」という意味で、特定の頭字語の略ではありません。GoogleのDORA（DevOps Research and Assessment）チームが提唱し、書籍『LeanとDevOpsの科学（Accelerate）』で広まりました。「DORA metrics」とほぼ同義で使われます。

変更失敗率はどう計算しますか？

「障害を招き修正対応が必要になったデプロイ数 ÷ 全デプロイ数 × 100」で求めます。切り戻し・ホットフィックス・緊急パッチを要したデプロイが分子です。開発中に見つかったバグ件数は含めず、本番リリース起点の失敗だけを数えます。

Four Keysは5つの指標になったのですか？

基本は4指標のままです。2021年以降のDORAレポートで、可用性を測る5つ目の指標「信頼性（Reliability）」が補助的に追加されましたが、コアとなるのは従来どおりデプロイ頻度・変更のリードタイム・変更失敗率・サービス復元時間の4つです。

Four Keysの計測は無料で始められますか？

GoogleのOSS「Four Keys」を使えばライセンス費用なしで構築できます。ただし集計基盤としてBigQueryなどのGoogle Cloudサービスを使うため、その利用料は発生します。手早く始めるならDORA metricsを標準搭載するSaaSを使う選択肢もあります。

Four Keysとアジャイルやスクラムはどう関係しますか？

Four Keysは開発手法そのものではなく、手法の成果を測る指標です。スクラムなどのアジャイル開発で改善を回す際の共通の物差しとして使えます。手法自体の違いはウォーターフォール・アジャイル・スクラムの違いで整理しています。

関連記事

• ウォーターフォール・アジャイル・スクラムの違い｜3つの開発手法の比較と使い分け
• Azure Pipelinesの使い方｜YAMLでCI/CDを組む手順と無料枠・権限設定
• CI/CDパイプラインにおけるDocker脆弱性スキャンの重要性とその必要性
• Azure DevOpsは日本語化できる？UIを日本語にする方法とServices/Serverの違い