TL;DR
- 開発生産性指標は DORA / SPACE / DevEx の 3 つを役割分担で使い分けるのが現代の実務（[公式値] DORA は 2024 年に 5 指標モデル化、SPACE は 5 次元、DevEx は 3 軸）。
- 比較・選定の決定木は別記事 DORAとSPACEの選び方 に集約。本記事は 入門ハブ + 計測の最初の 1 週間 HOW-TO として位置付ける。
- 「数字そのもの」に意味はなく、変化を行動につなげるループを作るのが本質。Cycle Time の改善ループは Cycle Time をどう定義し改善するか を参照。
はじめに
こんにちは、みね（@s977043）です。
「開発生産性を可視化したい」という話は、どの現場でも必ず一度は上がります。しかし、「Four Keysがいいらしい」「SPACEフレームワークというのがあって...」と知識ばかりが増え、結局何から始めればいいのか迷子になっていないでしょうか。
本記事では、溢れる指標の中から**「今の自分たちに必要な定規」**を選び取り、最初の 1 週間で計測を開始するための具体的な手順を解説します。比較・選定の深掘りが必要な場合は DORAとSPACEの選び方 を併読してください。
- この記事の目的: チームの状態に合わせた指標選定の基準と、最小コストでの計測方法を提示すること。
- やらないこと: 各フレームワークの学術的な詳細解説や、専用高額ツールの導入ガイド。
- 想定読者: 「なんとなく測りたい」と思っているが手がつかないテックリード、EM、現場のエンジニア。
- ゴール: 読了後、自チームで計測すべき1〜2個の指標が決まり、Gitコマンドで現状値を確認できる状態になること。
- 免責: 本記事で紹介する分類やフェーズ定義は、筆者の経験に基づく実践的なモデルであり、原著論文の厳密な定義とは一部異なる場合があります。
1. なぜ「指標」が必要なのか（現在地を知る）
そもそも、なぜ指標が必要なのでしょうか。「なんとなく良くなってる気がする」ではなく、「先月よりデプロイ頻度が倍になった」と言えるようにするためです。
健康診断と同じで、「数字そのもの」に意味はありません。 数字の変化を見て、「最近運動不足だな（リファクタリング不足かな）」と気付き、行動を変えるきっかけにすることこそが本質です。
2. 地図を広げる：DORAとSPACEの違い
まず、代表的な2つのフレームワークを「道具」として整理します。
DORA Metrics
- 特徴: ソフトウェアデリバリーの「速度（Throughput）」と「安定性（Instability）」に特化。
- 対象: デプロイパイプライン、リリースプロセス。
- 使い所: 「とにかくリリースまでの詰まりを取り除きたい」とき。
- 指標数: かつて Four Keys として 4 指標で普及してきたが、2024 年に Deployment Rework Rate を加えて 5 指標モデルへ整理し直された[公式値]（DORA Metrics 公式ガイド）。
- 年次レポート: 2025 年に State of AI-assisted Software Development へ改称、2024 Accelerate State of DevOps Report と並行参照可能[公式値]。
- 深掘り: Cycle Time / Lead Time for Changes に絞った改善ループは Cycle Time をどう定義し改善するか、DORA / SPACE / DevEx の選定軸は DORAとSPACEの選び方 を参照。
SPACE Framework
- 特徴: 開発者の「満足度」や「コラボレーション」を含む 5 次元の視点（Satisfaction and well-being / Performance / Activity / Communication and collaboration / Efficiency and flow）[公式値]。
- 対象: チーム全体のウェルビーイング、開発体験（DevEx）。
- 使い所: 「リリースはできているが、チームが疲弊している気がする」とき。
- 出典: The SPACE of Developer Productivity (ACM Queue 2021)
- 原典の主張: 「生産性は 1 つの指標で測れない。3 次元以上を組み合わせろ」[公式値]。
DevEx Framework（補完）
- 特徴: SPACE と並ぶ補完的フレームワーク。Feedback Loops / Cognitive Load / Flow State の 3 軸に絞り、開発者個人の摩擦を扱いやすくしている[公式値]。
- 出典: DevEx framework (Noda, Storey, Forsgren, Greiler / ACM Queue 2023) と DevEx in Action (2024)。
- DORA との関係: DevEx 改善が DORA 指標も改善する相関が報告されている[公式値]。
- AI 時代の差し込み: AI コーディング導入後の生産性パラドックスは AI生産性のパラドックス で別途整理。
3. フェーズ別：どの定規を選ぶべきか
全ての指標を一度に追うのは不可能です。チームのフェーズに合わせて、「今見るべき1つ」を選びましょう。
Phase 1: リリースが不安定 / 怖い
- 選ぶ定規: DORA (安定性)
- 変更障害率 (Change Failure Rate)
- 復旧時間 (Time to Restore Service)
- 理由: まずは「壊れない」状態を作らないと、速度を上げることはできません。
Phase 2: リリースは安全だが、遅い
- 選ぶ定規: DORA (速度)
- デプロイ頻度 (Deployment Frequency)
- 変更のリードタイム (Lead Time for Changes)
- 理由: 安全が確保されたら、次は「小さく、速く」出すリズムを作ります。ここが多くのチームにとっての主戦場です。
Phase 3: 速いが、何かがおかしい
- 選ぶ定規: SPACE (Satisfaction / Communication)
- 開発者満足度、ドキュメントの検索容易性、会議の多さ
- 理由: 数字上の生産性が高くても、燃え尽き症候群になっては持続できません。人間的な側面（定性評価）を取り入れます。
4. 【実践】GitコマンドでFour Keysの「尻尾」を掴む
「高機能なダッシュボードツール」を入れる前に、まずはGitコマンド一発で現状を掴みましょう。
手順
- リポジトリのルートディレクトリに移動する。
- 以下のコマンドを実行し、直近30日のマージ数（≒デプロイ頻度の近似値）を確認する。
コマンド例（デプロイ頻度の簡易計測）
メインブランチへのマージ回数を「デプロイ回数」とみなす、最もシンプルな計測方法です。
# 直近30日間のメインブランチへのマージコミット数を集計
git log <メインブランチ名> --merges --first-parent --since="30 days ago" --oneline | wc -l
実行結果の読み方
- 週1以下 (〜4回): バッチサイズが大きすぎます。PRを小さく分割しましょう。
- 毎日 (20回〜): 素晴らしいリズムです。次はリードタイム（PR作成からマージまでの時間）に目を向けましょう。
5. ありがちな落とし穴（McKinseyの罠）
ここで絶対に避けるべき「地雷」があります。それは 「個人単位の指標」 を測ることです。
2023年にMcKinseyが発表した「開発者ごとの生産性測定」は、業界から猛烈な批判を浴びました（参考: Measuring developer productivity? A response to McKinsey）。
- NG例: 「Aさんはコミット数が多いから優秀」「Bさんはレビュー数が少ない」
- 結果: コードの行数を稼ぐための無意味な改行が増え、誰も他人のレビューをしなくなります。
指標は常に 「チーム全体」 の改善のために使いましょう。「誰が悪いか」ではなく「プロセスのどこが詰まっているか」を探すのです。
6. 現場の知恵：まずは無料で、手作業で
いきなりDatadogやFindyなどの有料ツールを導入するのはお勧めしません（これらは素晴らしいツールですが、使いこなすには準備が必要です）。
みねのTips
- スプレッドシートで始める: 週に一度、上記のGitコマンドの結果をシートに記録するだけで十分です。推移が見えれば会話が生まれます。
- 定性情報を侮らない: 毎回のレトロスペクティブで「今週の開発は楽しかったか？」を5段階で聞く（SPACEのS）。これだけで、異常事態を検知できることが多々あります。
7. 計測を始める「最初の 1 週間」HOW-TO
「定規を選んだ」次の壁は、運用に乗せる最初の 1 週間 です。組織を巻き込む前に、自チームだけで小さく回す手順をテンプレ化しました（経験則・5〜30 名規模で複数チーム）。
Day 1: ベースライン取得
git log --merges --first-parent --since="30 days ago" --oneline | wc -lで過去 30 日のデプロイ回数を出す- スプレッドシートに
週 / デプロイ回数 / Lead Time（手動でいくつかの PR から平均値）/ Change Failure Rate（hotfix PR 数 / 全 PR 数）/ MTTR（Incident 復旧時間平均）の 5 列を作る - 目的: 「先月は何回出していたか」を 30 分以内に答えられる状態にする
Day 2-3: 観測とアラート設計
- デプロイの定義を 1 行で固定する（例: 「main ブランチへの merge commit = デプロイ」）
- Failed Deployment（rollback / hotfix）を区別するラベル運用を Issue / PR テンプレに埋める
- 通知は Slack
#deployなどに集約。アラート粒度・ローテ設計は オンコール疲弊を防ぐ運用設計 を参照
Day 4-5: SPACE Satisfaction の手動取得
- 週次レトロスペクティブで「今週の開発は楽しかったか？」を 5 段階で 1 問だけ聞く（SPACE の S）
- 数値が連続して下がるチームは、指標値より先に疲弊兆候を捕捉できる（経験則）
Day 6-7: 共有と次の打ち手決定
- 朝会で 1 つだけ数字を共有：「先月のデプロイ回数 ◯ 回 / Lead Time 中央値 ◯ 日」
- 改善打ち手は 1 つだけ選ぶ（例: PR テンプレに「変更ファイル数」のセクションを追加してレビュー時間短縮）
- 4 週間後に再測して Δ を記録
このループを 3 サイクル（約 12 週間）回すと、ほぼ間違いなく Δ が現れます。3 週間で諦めると失敗パターン 4（仕様駆動開発の落とし穴と対策 参照）と同じ罠にはまります。
8. おわりに：まずは今日、デプロイ頻度を測る
計測なき改善は迷走します。しかし、計測のための計測は時間の無駄です。
まずは今日、ターミナルを開いて先ほどの git log コマンドを叩いてみてください。 その数字が、あなたのチームの現在地です。
git log <メインブランチ名> --merges --first-parent --since="30 days ago" --oneline | wc -l
数字が出たら、明日の朝会で「うちのチーム、先月は◯回デプロイしてたよ」と共有することから始めてみませんか。具体的な指標選定の決定木は DORAとSPACEの選び方 で、レビュー運用ボトルネック診断は AI時代のレビュー運用設計 で扱っています。
FAQ
Q1. DORA Four Keys と 2024 年以降の 5 指標モデルはどう違いますか？
DORA は 2024 年に Deployment Rework Rate を 5 番目の指標として追加し、現行公式は Throughput（Deployment Frequency / Change Lead Time / Failed Deployment Recovery Time）と Instability（Change Fail Rate / Deployment Rework Rate）の 5 指標構成です[公式値]。Reliability は 2021 年に「fifth metric」と紹介された運用パフォーマンス側の概念で、現行のソフトウェアデリバリー 5 指標の 5 番目ではありません。詳細は DORA 公式履歴 を参照。
Q2. SPACE は 5 次元すべて測らないと意味がないのですか？
ない。SPACE 原典は「3 次元以上を組み合わせろ」と主張しており、5 次元全部とは書いていません[公式値]。最初は Performance + Satisfaction + Efficiency の 3 次元から始めるのが運用しやすいです。
Q3. DevEx は SPACE の置き換えになりますか？
置き換えではなく 補完です。DevEx は SPACE と同じく単一指標を避ける思想を共有しつつ、Feedback Loops / Cognitive Load / Flow State に測定対象を絞った独立フレームワークです（DevEx in Action 2024）[公式値]。SPACE が「組織の状態地図」、DevEx が「個人の摩擦の温度計」と捉えると役割が分かれます。
Q4. 経営層への業界比報告にはどの指標が向きますか？
DORA がほぼ唯一の選択肢です。Elite / High / Medium / Low の 4 ティアに分けたベンチマークが世界規模の調査で提示されているためです[公式値]（State of AI-assisted Software Development 2025）。SPACE / DevEx は自社推移用なので、経営層への単独報告には向きません。詳細は DORAとSPACEの選び方 を参照。
Q5. 計測を始める前に、最初の 1 週間で何を準備すべきですか？
本記事「§7 最初の 1 週間 HOW-TO」を参照。Day 1 でベースライン（過去 30 日のデプロイ回数 / Lead Time / CFR / MTTR）、Day 2-3 で観測とアラート設計、Day 4-5 で SPACE Satisfaction の手動取得、Day 6-7 で共有と打ち手決定、というテンプレで運用に乗せます。3 サイクル（約 12 週間）回すと Δ が見えます（経験則）。
参考資料
- DORA Metrics 公式ガイド — 5 指標モデルの公式定義
- DORA Insights - DORA metrics history — Reliability や Deployment Rework Rate の歴史的経緯
- State of AI-assisted Software Development 2025 — 最新年次レポート（2025 改称）
- The SPACE of Developer Productivity (ACM Queue 2021) — SPACE 原典
- DevEx framework (ACM Queue 2023) — DevEx 3 軸の原典
- DevEx in Action (2024) — DevEx と DORA の相関
- Accelerate: The Science of Lean Software and DevOps — DORA 共著者の単行本
