ソフトウェア開発メトリクス
メトリクスの目的: ステアリングと改善測定
2つの目的の違いを、Dave Nicolette は InfoQ Q&A で次のように述べている: "First, we need to know if the work is on track with respect to our expectations or plans... I call this 'steering' the work. Second, we need to know whether our attempts to improve delivery are helping or hurting."
各メトリクスはステアリング（進行中の作業の軌道修正）か改善測定（改善努力の効果測定）かで使い方が違う。同じサイクルタイムでも、ステアリングなら閾値超過時に介入を判断する用途、改善測定なら週次・月次の中央値推移を改善施策の効果検証に使う。
メトリクスの3機能
メトリクスの目的（ステアリング / 改善測定）が「何のために使うか」だとすれば、機能は「使った結果として実際に何が起きるか」を表す軸である。メトリクスには3つの機能・効果がある。
情報提供（informational）: 状況を平易に伝える
診断（diagnostic）: 問題に注意を喚起する
動機づけ（motivational）: 人々の行動に影響を与える
3機能は同時に発生し、動機づけ効果は意図しなくても起きる。マネジメントがベロシティを「目標」として掲げた瞬間、ベロシティは情報提供メトリクスから動機づけメトリクスに用途が移り、見積り値が次第に膨らんでいく。各メトリクス節の「失敗パターン」の多くは、意図しない動機づけ効果が指標を腐らせる現象（Goodhart則、キャンベル則）を扱っている。Goodhart則の四類型と運用の落とし穴は 指標をめぐる認知バイアス で扱っている。診断機能を期待した指標が動機づけ機能を発動すると、メトリクスは目的を果たさなくなる。設計時には「このメトリクスは誰のどの行動に影響を与えるか」も併せて考える。
前方メトリクスと後方メトリクス
目標が過去にあるか未来にあるかでメトリクスの向きが分かれる。
後方メトリクス（backward-looking）: 事前に作成した計画を成功の定義とし、計画への追従度を測る。予測型開発で機能する
前方メトリクス（forward-looking）: 未来状態のビジョンを成功の定義とし、ビジョンへの軌道を測る。適応型開発で機能する
シングルループ学習: 既存の目標・前提を所与として、行動だけを修正する。「計画通り進んでいるか」を問う
ダブルループ学習: 目標・前提そのものを問い直し、必要なら書き換える。「そもそもこの目標で正しいか」を問う
後方メトリクス（EV、SPI/CPI、スコープ進捗率）は計画固定を前提とし、計画と実績のズレに行動を合わせる。前方メトリクス（スループット + モンテカルロ予測、エイジング・チャート + SLE）は将来予測の更新を前提とし、予測の更新に応じてビジョンや計画の側を書き換える余地を残す。
ダブルループ学習が回るかは、各プロセスが何度繰り返されるかに依存する。単一デリバリ（1案件で完結する個別プロジェクト）は契約・計画が一度きりなので、前方メトリクスを使っていても目標・前提を書き換えるサイクルが構造的に少ない。継続デリバリ（同じプロダクトを繰り返しリリースする継続サポート）は、各リリース後に予測と実測を突き合わせて目標自体を組み替える機会が毎回ある。後方／前方の選択はメトリクスの設計、ダブルループが回るかはデリバリモードの問題、と分けて考える。各メトリクス節の冒頭に「向き」を明示する。
先行指標と遅行指標
3機能と並ぶもう1つの軸。
遅行指標（trailing / lagging）: すでに起きたことを測る。例: サイクルタイム（完了後にしか確定しない）、変更失敗率（リリース後に判定）
先行指標（leading）: 将来の傾向を予測する。例: 項目経過日数（停滞中アイテムの遅延予兆）、エラーバジェット消費速度（信頼性枯渇の予兆）
先行指標は遅行指標の蓄積から導出されることが多い。両者をペアで運用するのが基本。
以降の各メトリクス節では「向き」を 後方 / 前方 と 先行 / 遅行 の2軸併記で書く。前者は目標の所在（過去の計画か未来のビジョンか）、後者は観測タイミング（事象が起きた後か前か）を表す独立な軸である。
一次観測量と派生指標
メトリクスは一次観測量と、それを使って計算される派生指標の2層に分かれる。たとえば SLI（成功率、レイテンシ等）は一次観測量、SLO はそれに対する目標設定、エラーバジェットは 100% - SLO の派生値、エラーバジェット消費速度はさらにその派生比率である。同様に SPI / CPI / EAC はアーンドバリューの派生、SLE はサイクルタイム分布の85パーセンタイルの派生、Flow Efficiency はフロー時間の派生、DRE は不具合検出数の派生比率になる。
派生指標は単独で扱えず、元になる一次観測量と運用ルール（目標設定、再計算頻度、閾値）の3点セットで意味を持つ。
適用条件の4軸
以上を踏まえ、各メトリクスの適用条件は4つの観点で分類する。
開発アプローチ: 予測型（traditional、計画通りに事象が進む前提）/ 適応型（adaptive、変化を前提として方向修正する）
プロセスモデル: 線形 / イテラティブ / タイムボックス型 / 連続フロー
デリバリモード: 個別プロジェクト / 継続サポート
メトリクスの向き: 後方（計画追従）/ 前方（ビジョン軌道）/ 両用
開発アプローチは「予測可能性が前提として成り立つかどうか」で分かれる。要件・技術・市場が安定し、計画通りに事象が進むと仮定できるなら予測型、変化を前提として方向修正が必要なら適応型。プロセスモデルの4分類は2012年のブログ "Process models" で定義された。線形＝ウォーターフォール型 SDLC、イテラティブ＝変化を常態とみなす、タイムボックス型＝固定長のイテレーション内で目標達成、連続フロー＝バリューストリーム型。 Nicolette 自身が「ある程度の規模があるソフトウェア組織では、ほとんどの場合、仕事の性質に応じて、異なるタイプの仕事に異なるプロセスを適用している」「どのようなプロセスであっても、書籍で定義されたとおりに使用する組織はごく少数」と前置きしている。混在は例外ではなく標準である。後段の「メトリクスの選び方」も、組織全体ではなく作業種別ごとに適用する前提で読む。
指標群はデリバリモードで分岐しやすい
DORA・SPACE・DevEx は継続デリバリで繰り返しリリースされるプロダクトを前提に組まれている。IPA / JUAS / SQuBOK 系の密度指標と信頼度成長曲線は単一デリバリーでのリリース検収判定を前提に組まれている。デリバリモードが指標群の設計前提の中で目立つ分岐点になっている。
IPA/SEC自身も近年はLOCベースの限界を認識している。2022年版データ集のアジャイルメトリクスFAQでは「アジャイル開発ではばらつきが大きく、妥当なメトリクスがまだ少ない」と認めている。NTTデータの「観点カバレッジ・DDPモニタリング」もこの転換点に位置する。 ただしデリバリモード一つで指標が決まるわけではない。ソフトウェア開発プロジェクトの設計で挙げた4論点（開発ライフサイクル / 固定するプロジェクト変数 / デリバリーケイデンス / 効率パラダイム）はそれぞれ独立に決められ、組み合わせ次第で必要な指標が変わる。同じ組織内に複数の組み合わせが混在する場合、どの指標群を主軸にするかが Decision Quality のフレーム問題になる。 ステアリング・メトリクス
進行中の作業を軌道に乗せるための指標群。観測対象は「予定スコープに対する進捗」「フローの停滞」「品質工程の妥当性」「本番サービスの信頼性」に大別される。以下の4区分で扱う。
進捗・スコープ系: 計画したスコープ・予算・ビジネス価値に対し、今どこまで来ているか。スコープ進捗率・EVM・バーンダウン・ベロシティなど
フロー系: 作業項目の流れに詰まりがないか。サイクルタイム・スループット・WIP・項目経過日数など
品質・検収判定系: 検収前の品質が基準値の範囲内か。バグ密度・テスト密度・ゾーン分析・信頼度成長曲線など
信頼性系: 本番のサービスレベルがユーザー期待を満たしているか。SLI・SLO・エラーバジェット
ステアリングは「閾値を割ったら介入する」運用が前提で、判断者と判断頻度を必ずセットで設計する。読み手が人間でもコーディングエージェントでも基本構造は同じ。
進捗・スコープ系
スコープ進捗率（Percentage of scope complete）
完了スコープ÷総スコープの率。
https://gyazo.com/a42189d5c692169a4ba2b849d46e136b
目的: 予定スコープを予定通り完了するための進捗状況はどうか
適用条件:
開発アプローチ: 予測型、または適応型（スコープ固定の場合）
プロセスモデル: 問わない
デリバリモード: 個別プロジェクト
向き:
目標所在: 後方（事前計画への追従度）
観測タイミング: 遅行（完了済み分のみ可視化）
計測方法: 計画段階で WBS や機能一覧を凍結して総スコープ N とし、検収済み単位を C として C/N を週次で記録する。プロジェクト管理ツール（MS Project、Redmine など）の WBS 完了率がそのまま使える
活用方法: 月次のステアリング会議で「予定線（線形補間）と実績線の差分」を判断材料にする。組織で合意した遅延閾値（経験的には1割前後を採る現場が多い）を超えたら挽回計画・リソース追加・スコープ削減を検討する。判断者はプロジェクトマネージャ
失敗パターン:
イージーライダー: マネージャーやチームが、予測型手法の簡単な部分と適応型手法の簡単な部分を選び、難しい部分を避ける。スコープの100%の信頼できる定義もなく、可変スコープを管理する堅牢なメカニズムもない。ステークホルダーが「最初のスコープ声明は希望機能のハイレベル要約に過ぎないのに、デリバリ組織側の確固たるコミットメントを表している」と思い込み、コスト・スケジュールの予測可能・回避可能な超過が頻繁に繰り返される
動く分母: スコープが動く適応型開発で使うと「90%完了が3週間続く」現象が典型。原因は分母（総スコープ）が固定されていないこと。検知は「進捗率が一定週数同じ値で止まる」かどうかで判別する。回避策は分母を確定できないなら使わず、サイクルタイムやスループットに切り替える
初心者チーム: マネージャやチームが初めて適応型開発手法を適用するとき、綿密な要求分析や先行設計といった予測型のプラクティスは時代遅れで文脈に関係なく不要だと思い込む。適応的な取り組みのコンテキストがスコープ固定なら、完了しなければならない作業項目の包括的な定義は必要。スコープ固定の前提のときに包括定義を捨てると進捗率を追跡する根拠が無くなる
アーンドバリュー（EV / EVM）
PMI由来。実施した作業の予算換算値とその派生指標群。PMBOKでは出来高管理（EVM）として体系化されている。
https://gyazo.com/37251fee6a0a00e49c3a1175ea3d55ed
目的: 予定スコープを予定通り、割り当てられた予算内で完成させる目途は立っているか。計画値・出来高・実コストの3つの数値で進捗を多次元評価する
適用条件:
開発アプローチ: 予測型
プロセスモデル: 線形
デリバリモード: 個別プロジェクト
その他: 請負契約
向き:
目標所在: 後方（計画コスト・スケジュールへの追従度）。EACで将来予測も可能で、その意味では前方要素も含む
観測タイミング: 遅行（完了済み作業の事後集計）
成功要因: スコープ・スケジュール・予算の100%の初期定義が確定し完成していること
計測方法: 各タスクに予算 BAC を割り当て、PV（計画値、当該時点で完了予定だった作業の予算合計）、EV（出来高、実際に完了した作業の予算合計）、AC（実コスト、消費した実工数 × 単価）を月次で集計する
派生指標: SPI = EV/PV（スケジュール効率）、CPI = EV/AC（コスト効率）、EAC = BAC/CPI（完成時総コスト見積）
活用方法: 月次のステアリング会議でSPI・CPIが0.9を下回ったら挽回策（クラッシング、ファストトラッキング、要員追加、スコープ削減、納期再交渉）を判断する
失敗パターン:
適応型開発への流用: スコープ追加でBACが事後に膨らみSPI・CPIが改善したように見える「数字上の挽回」が起きる。逆に、PVを月次で更新せざるを得ない運用では「計画値が常に実績に追従する」状態になりSPIが常に1.0付近で動かない。いずれも原因は計画スコープ・計画値固定の前提が満たされていないこと。検知はBAC・PVの改訂頻度で判定する（毎月改訂されるならEVは機能していない）。回避策はEVMを使わずスループット・リードタイム・デプロイ頻度といったフロー指標に切り替える。批判対象はEVM自体ではなく、前提を満たさない適応型開発への流用
単なる書き換え: イニシアチブの目的が「同じ機能を持つ新しいソリューションで既存ソリューションを置き換える」場合、計画者は代替ソリューションの機能要件を調査しなくてよいと想定する（誰もが旧システムの機能をすでに知っているはず）。コスト削減のため旧システムを見たことがない派遣プログラマーを参加させ、新機能もついでに入れる。コストとスケジュールの大幅な超過を覚悟しなければならない
英語圏での位置付け: 米国防総省系の大規模案件・PMBOK系プロジェクトで使われている。SEIは「EVMはアジャイルとの整合に9ヶ月の整合化期間が要る」と指摘している。DORAはリードタイム・デプロイ頻度のフロー指標を中心に据え、EVMを直接の指標としては扱わない 予算消化率 / バッファ消化率（Budget Burn / Buffer Burn Rate）
予算消化率とバッファ消化率。
https://gyazo.com/d8b41b58d5e98eaead4a02948a979eb7
https://gyazo.com/5302e577805b09a56cabc7424c3420bf
目的: 時間切れになる前に資金が尽きるか。計画バッファを超えるか
適用条件:
開発アプローチ: 問わない
プロセスモデル: 問わない
デリバリモード: 個別プロジェクト（予算消化率は経常費用予算ではない資金調達モデルが前提）
向き:
目標所在: 後方（計画予算・バッファへの追従度）
観測タイミング: 先行（バッファ枯渇予兆として将来リスクを示唆）
計測方法: 予算消化率は 累積実コスト / 総予算 を週次で。バッファ消化率は CCPM（Critical Chain Project Management）のプロジェクトバッファ残量を 消費したバッファ日数 / 総バッファ日数 で計算
活用方法: バッファ消化率を縦軸、進捗率を横軸に取ったフィーバーチャートを作り、緑・黄・赤の3ゾーンで判断する。黄ゾーン（バッファ消費が進捗より速い）で挽回策を検討、赤ゾーン（バッファ枯渇接近）でスコープ調整・追加投入を判断
失敗パターン:
継続サポートでのバッファ無効化: 継続予算では「バッファ」概念が定義できず、バッファ消化率が常に0付近で動かない。原因は終了点が無いプロダクトに対し終了前提のメトリクスを使っていること。検知は「バッファ消化率が3ヶ月連続で動かない」で見分けられる。回避策は継続サポートでは単位アウトプットあたりコストに切り替える
アジャイルブラインドネス: 「軽量」管理方法を使う場合に、チームが予算燃焼の追跡を怠る現象。一般的なアジャイル手法は受託管理について沈黙し、フローや柔軟性にフォーカスする。マネージャやチームが「アジャイルであること」に熱中するあまり資金がどこに流れているかわからなくなり、予期しないコスト超過に見舞われる。「軽量」とは管理を捨てる意味ではない
Earned Business Value
EV の派生で、価値次元を金額ではなく業務価値で測る。Dan Rawsthorne 提唱。
https://gyazo.com/6068da340a49ed78aa577e8d69ea8377
目的: 予想ビジネス価値の何割が現時点で提供されたか。勝利宣言して次に進むのに十分な目標達成か。残機能の開発はコストに見合うか
適用条件:
開発アプローチ: 適応型
プロセスモデル: イテラティブ・タイムボックス・連続フローのいずれか
デリバリモード: 個別プロジェクト
向き:
目標所在: 前方（ビジョンに対する価値創出度）
観測タイミング: 遅行（リリース後に確定）
成功要因: 意思決定権を持つ主要ステークホルダーの積極的参加。各機能の相対ビジネス価値は機能定義時にステークホルダーが割り当てる
計測方法: バックログ項目ごとにビジネス側が価値ポイント（売上見込・コスト削減額・KPI改善幅など）を付与し、リリース済み項目の累積価値ポイントを記録する。価値ポイントの合意は四半期計画時にプロダクトマネージャとビジネス側で実施
活用方法: 価値ポイント消化カーブと実コストカーブを並べ、ROI 推移を四半期レビューで判断材料にする。投資継続・撤退・方向転換の意思決定に使う
失敗パターン:
不在の意思決定者: 適応型開発の前提は意思決定権を持つステークホルダーが開発チームと直接関わっていること。これが成立しない場合にチームがビジネス価値を最善の推測で補おうとし、早い段階で間違った機能を提供して時間切れになる。推奨される対応は「ビジネス価値の追跡はやめて、意思決定者の不在を潜在的なビジネスリスクとして提起する」
ビジネス価値と努力レベルの混同: チームが「50%の作業を完了した時点でプロジェクトのビジネス価値の50%を提供した」と思い込む。納品された価値と納品されたソフトウェアの量は別の検討事項で、別々に追跡する必要がある
サロゲーション: 価値ポイントが実際の売上やKPI改善と乖離していく。原因はリリース後の実測値と事前付与した価値ポイントを照合する仕組みが無いこと。検知は四半期ごとに「価値ポイント上位5件のリリース後KPI実績」を抽出して相関を取れば分かる。回避策は最低でも年2回、価値ポイント定義を実測フィードバックで較正する
Running Tested Features（RTF）
https://gyazo.com/82cff2c16922bf07c0c3ff25986cc7a4
目的: 計画機能のうち何個が本番投入可能か。新機能導入で回帰が起きていないか。スケジュール通りに十分な機能を完成させられそうか
適用条件:
開発アプローチ: 適応型
プロセスモデル: イテラティブ・タイムボックス・連続フローのいずれか
デリバリモード: 個別プロジェクト
向き:
目標所在: 前方（ビジョンに対する完成機能の累積）
観測タイミング: 遅行（受け入れテスト合格時点で確定）
成功要因: 開発期間中ソリューションのサブセットをターゲット環境に段階的に提供し、複数抽象度の自動テストで完成機能が壊れていないか定期検証していること
計測方法: 各機能を1つ以上の受け入れテストに紐付け、CI上で「全受け入れテストがパスしている機能の累積数」を日次で記録する。Cucumber・SpecFlow などの BDD ツールで機能単位の合格率を集計
活用方法: 累積カーブを週次のレビュー会議で示す。線形に伸び続けていればデリバリが回っている証拠、停滞期があれば「機能は触っているがどれも完成していない」状態を検知。リリース判断の前提条件としても使える
失敗パターン: イージーライダー。RTFは「ターゲット環境にソリューションインクリメントを定期的に提供する」「自動テストでコードを定期的に実行する」の2つに敏感だが、適応型を称しながらこの規律を守らず予測型と適応型の簡単な部分だけを組み合わせるチームで発生する。機能が並列に作りかけで残り、リリース直前までRTFが0のまま推移してリリース週に一気に跳ね上がる。原因は最終結合テストまで機能完成判定ができないウォーターフォール的な構造を残していること。検知は「RTFカーブがS字を描かず、垂直に立ち上がる」形状から判別する。回避策は規律の側を直す（インクリメンタルなデプロイと自動テストの徹底）。それが成立しないなら適用条件から外れているということなので、RTFを諦めてEVや工程別進捗に切り替える
適用条件外: Nicolette自身もInfoQ Q&Aで「RTF is meaningless and useless for traditional development」と言い切っている。予測型開発でRTFを使うこと自体が前提違反である ベロシティ（Velocity）
1イテレーションあたりの相対見積点数の消化量。「手法はどれでも」と整理されており、予測型開発でアジャイル手法を機械的に使う場面でもベロシティは算出されうるが、本質的にはタイムボックス型プロセスの仕組み。
https://gyazo.com/134f75d7b78776d45f52da744cf8b394
目的: 単位時間あたりのチームの平均的なデリバリ能力はどれくらいか。チームは安定した速度でデリバリしているか
適用条件:
開発アプローチ: 問わない
プロセスモデル: タイムボックス型
デリバリモード: 個別プロジェクト
向き:
目標所在: 前方（次イテレーションの引き受け量決定）
観測タイミング: 遅行（過去実績の経験データ）
計測方法: イテレーション終了時に完了した項目の相対見積点数を合計。Jira・Azure DevOps の標準レポートで自動集計可能。直近3〜6イテレーションの平均と分散を取る
活用方法: チーム自身が次イテレーションで引き受ける作業量の上限を決める材料に使う。計画会議で「直近平均±1σ」をキャパシティとして設定。マネジメントへの報告には使わない
成功要因: タイムボックス化したイテレーションごとに、生産可能な作業ユニットをある程度の数完成させる。プロジェクト全体を通じて一貫した方式と尺度で見積りを行う（他チームと比較する必要はない、通常は比較しない）
失敗パターン:
ベロシティの目標化: マネジメントが目標化すると、見積りインフレ（同じ作業に高い点数が付く）が起きる。原因はベロシティの設計上の機能（情報提供・診断）に対し、目標化が動機づけ機能を強制発動させること。情報提供メトリクスを動機づけ用途に切り替えた瞬間に診断機能が失われる典型例。検知は「同等作業の歴史的点数が時系列で増加傾向」を見れば判定できる。回避策はベロシティをチーム外に共有しない、レポーティング指標をサイクルタイム・スループットに切り替える
ベロシティを完成率として使う: 適応型プロジェクトを予測型の考え方で追跡するマネージャが、最初のハイレベル総スコープ見積を揺るぎないコミットメントと思い込み、ベロシティと完成率を同一視する。これは適応型ソフトウェア開発を理解していないサイン
いきなり最大のベロシティ: チームがプロジェクト開始直後から通常ベロシティで動くと仮定して将来予測すると、傾向線が「プロジェクトが完成しない」かのように見え、不快な会話を招く。実際は3〜4イテレーション必要。20%×3経験則（次節）で調整
希望的観測に基づくパフォーマンス（別名「魔法の妖精の粉」）: 不調時にプロジェクトマネージャがバーンチャートに「ある時点で何の理由もなく実績線が突然自己修正して理想線と合流する」予測を描く。ベロシティは経験的指標であり、デリバリ能力が突然4倍になることはない。希望ではなく現実を反映した計画修正が必要
ベロシティを使ったチーム比較: チームAの200ポイント/イテレーションとチームBの25ポイント/イテレーションは、チームAがチームBの8倍効果的という意味ではない。相対ポイントは1つのチームが自分の文脈で作業項目の相対大きさを認識することに限定される
混在ワークフローにベロシティを活用する: 同じチームが計画的プロジェクト作業と計画外の本番サポート作業を同時に処理する場合、ベロシティは意味のある計測値にならない。連続フロー型プロセスモデルとサイクルタイムに切り替える
"Velocity is designed to be an empirical observation of actual delivery performance. When we set Velocity targets, we completely break the metric. It becomes utterly meaningless."
ベロシティを改善追跡に使う3条件は (1) イテレーション長を変えない (2) 相対見積基準を変えない (3) 経営が目標値を設定しない。改善追跡にはベロシティではなくサイクルタイムが推奨される。
ベロシティを「計画コミットメントに対する達成率」として運用すると、ゲーミングと主観のゆらぎで計画予測可能性の指標として機能しなくなる。直近3〜4イテレーションの平均を予測値として使うYesterday's Weatherへの切り替えで何が変わるかは ソフトウェアの見積もりで扱う。 立ち上がり要因の20%×3経験則は、上記「いきなり最大のベロシティ」アンチパターンの整理である。チームが初期からフル稼働のベロシティで動くと仮定すると将来予測が誤る。新規メンバーが入った場合は通常ベロシティの約20%影響、新技術スタックの場合はさらに20%、新ビジネスドメインの場合はさらに20%を、最初の数回のイテレーションで予測値から差し引いて調整する。学術的研究ではなく経験則で、自組織の文脈に応じて補正する。チームメンバーが内部の序列を調整しユニットとして機能するまで、新規参入者は通常3〜4イテレーション必要とされている。
バーンダウンチャート（Burn Chart）
残作業量を時系列でプロットする図。集計範囲で2種類に分かれる。イテレーションバーンダウンは単一イテレーション内の残作業を日次でプロットするもので、計画達成可否の日次判断に使う。リリースバーンチャート（リリースバーンアップ／バーンダウン）は複数イテレーションにまたがる累積を週次でプロットするもので、リリース全体のデリバリ軌道を見る。後者は単一イテレーションの変動を平均化するため、ベロシティがギザギザでもデリバリが安定しているかを判定する材料になる。
https://gyazo.com/b9cd78a32574df73f84c8e534191b380
目的: チームはデリバリ目標を達成できそうか。計画範囲を完成させるためにどれくらいの時間が必要か。指定された期日までにどれだけ完成させられるか
適用条件:
開発アプローチ: 問わない
プロセスモデル: 問わない
デリバリモード: 個別プロジェクト
向き:
目標所在: 前方（イテレーション目標達成への軌道）
観測タイミング: 先行（残作業傾向から達成可否を予測）
成功要因: 「作業項目」を構成するものを一貫して理解する。作業項目を「完了」と宣言することの意味を明示的・実証的・二値的に定義する
計測方法: イテレーション開始時の総作業量（点数または項目数）を起点に、毎日の残作業量をプロットする。Jira・Azure DevOps の標準機能。理想線は線形補間（総作業量から0まで等速で減少）
活用方法: 日次の同期で実績線が理想線から大きく上に乖離したら、スコープ削減・支援要請・阻害要因の除去を判断する。イテレーション中盤で乖離が固定化したら、イテレーション目標の再交渉
失敗パターン:
スコープ追加が日常化: イテレーション中の追加で残作業ラインが下がっては上がってを繰り返し、進捗判断ができなくなる。原因はイテレーションスコープを「契約」として扱う規律が無いこと。検知は「イテレーション中の追加スコープ件数」を Jira から抽出すれば一目瞭然。回避策はスコープ追加時に同等量を別項目に振り替える、緊急時のみプロダクト責任者承認で追加を許可する
ホッケースティック: イテレーションの90%を過ぎるまで何も完了せず、最後の10%で一気に駆け込みでデリバリされる形。原因は要件・実装・テストを直線的にバッチ処理していること、機能スペシャリスト間のハンドオフが多いこと、WIPが高すぎてゾーンに入れないこと。検知はイテレーション1〜2回でこのパターンが出れば1回限り、3イテレーション以上連続なら構造問題。回避策はWIP制限、要件のテスタブル化、機能スペシャリスト間の協働強化
More is Less: 同じ情報をバーンアップとバーンダウン両方で同時表示すると、2倍の効果を持つように見えて実際はチャートのS/N比が下がる。意思決定者は明確で簡潔な情報を必要としている。どちらか1つに絞る
アート＆クラフト: プロジェクト管理ソフトのグラフィック機能に魅了され、棒グラフ・折れ線・円グラフを並べたカラフルなプレゼンを作る。1つで十分な情報を3つに分けるとS/N比が下がる
PI予測可能性指標（PI Predictability Measure）
https://gyazo.com/a39057939c957bb5928d5e9ae075207b
目的: ART（SAFeのチーム束）がPI計画通りにビジネス価値を提供できているか
適用条件:
開発アプローチ: 適応型
プロセスモデル: タイムボックス型（PI = 8〜12週）
デリバリモード: 問わない
その他: SAFe を導入する組織
向き:
目標所在: 後方（PI計画への追従度）
観測タイミング: 遅行（PI終了後に確定）
計測方法: PI計画時に各目標に確約目標値（commit 10pt、stretch 5pt 等）を設定し、PI終了時に 実績点数 ÷ 計画点数 を算出。チーム別に計算して ART（Agile Release Train、SAFeのチーム束）単位で平均
活用方法: 80〜100%の範囲に収まっているかを ART レベルの Inspect & Adapt ワークショップで判断。常時100%超なら計画が保守的、80%未満なら計画が楽観的との診断材料
失敗パターン: 確約目標とストレッチ目標の区別が曖昧だと、容易な目標を確約に積んで100%超を演出する「サンドバッギング」が発生する。原因は目標設定時のレビュー不在（Lean Wisdom解説）。検知はチーム間の予測可能性値が異常に揃う（全チーム95%前後）かどうかで判別する。回避策は他チームによる目標レビューを PI 計画に組み込み、ビジネス価値の妥当性を相互チェック フロー系
サイクルタイム・スループット・仕掛中項目数（WIP）の3つはリトルの法則 平均サイクルタイム = 平均仕掛中項目数 / 平均スループット で結ばれており、片方を絞れば他方が動く関係にある。
サイクルタイム（Cycle Time）
作業開始から完了までの所要時間。
https://gyazo.com/fde48a5be14a414c36bbdf493e9163e3
目的: 1作業項目を完成させるのに必要な平均時間はどのくらいか。チームのデリバリ実績はどの程度安定しているか。デリバリ問題につながる共通特性を持つ作業項目はどれか
適用条件:
開発アプローチ: 問わない（手法非依存メトリクス）
プロセスモデル: 問わない
デリバリモード: 問わない
向き:
目標所在: 両用（過去傾向の改善測定と将来予測のSLE導出の両方に使う）
観測タイミング: 遅行（完了後にしか確定しない）
成功要因: 各カテゴリーの作業項目について、開始と終了の定義を一貫させること
計測方法: 各作業項目に「開始」（着手状態への遷移）と「完了」のタイムスタンプを付け、完了 - 開始 を日数で記録する。Jira・Linear・GitHub Projects のステータス変更履歴から自動取得。サイクルタイム散布図（横軸: 完了日、縦軸: サイクルタイム）で可視化
活用方法: 中央値・p85・p95 を週次で確認。p85 をサービスレベル期待値（SLE）の根拠に使い「85%は N日以内に終わる」予測値として運用。改善施策の前後で中央値・p85 がどう動いたかを月次でふりかえる。個別項目が p85 を越えそうなら日次の同期で対処を判断
派生指標: サービスレベル期待値（Service Level Expectation, SLE） はサイクルタイム分布の85パーセンタイルを取って「85%の項目は N日以内に終わる」と表現する自己観測の予測値（Vacanti When Will It Be Done? (2020) / Kanban Guide）。エイジング・チャート上にSLEラインを描き、走行中項目がSLEを越えそうかを日次で確認、越えそうな項目への介入判断に使う。利害関係者への「いつ終わる？」回答にも使える。SLAではなく自己観測値として運用し、データが蓄積されたら予測を更新する（ProKanban解説） 失敗パターン: チームが負荷分散のために項目を開きっぱなし（複数を着手状態に置く）にすると、開始タイムスタンプが実態より早くなりサイクルタイムが伸びる。原因はステータス遷移の運用ルール不在。検知は「着手状態に同時2件以上の項目を持つ担当者の比率」から判別する。回避策は仕掛中項目数（WIP）の上限を1〜2に絞る運用ルールを定め、Jira の担当者別仕掛中項目数レポートで監視する
スループット（Throughput）
単位時間あたりの完了項目数。スループットを引き上げる主な手段は (a) WIPを絞ってサイクルタイムを短縮するか、(b) 項目を小さく分割するか、のいずれかになる。
https://gyazo.com/e509f7fdcc4871329c38daa59e2e020f
https://gyazo.com/25d0065b2d5065e0bcfcee304bb7735e
目的: チームや組織は一定時間内にどれだけのソフトウェアを提供できるか。一貫したペースで結果を出しているか
適用条件:
開発アプローチ: 問わない（手法非依存メトリクス）
プロセスモデル: 問わない（タイムボックス型ではイテレーションごとの完了数、連続フローでは月次完了数として活用）
デリバリモード: 問わない
向き:
目標所在: 両用（過去実績の集計、かつモンテカルロ予測の入力）
観測タイミング: 遅行（完了済み項目を数える）
成功要因: 現実的で正直な「デリバリ」の定義（ステージング・テスト環境へのデプロイでは不十分。顧客がアクセスできる必要がある）。サイクルタイムを一貫して追跡していること
計測方法: 「単位期間（週・イテレーション）あたりに完了になった項目数」を Jira・Linear のフィルタで集計。直近12週分のデータがあれば確率的予測の入力として十分
派生指標: モンテカルロ予測（Monte Carlo / Probabilistic Forecasting） は過去のスループット分布から「いつまでにN個終わるか」「指定日までに何個終わるか」を50/85/95パーセンタイルで返すシミュレーション（Magennis Focused Objective が2015年前後から普及、Vacanti が書籍で体系化）。過去12週以上の週次スループットデータをシミュレータに入力し、10000回の試行を実施。Magennisの無料スプレッドシート、VacantiのActionableAgile、自前ならPythonのnumpy.random.choiceで実装可能（Magennis introduction）。リリース計画 / 顧客コミット / マネジメント報告に使う 失敗パターン: 1項目のサイズが極端に大きいロングテール分布だと、スループットが低い週と高い週が交互に来て予測区間が広がりすぎる（85%予測が3週〜20週のような実用にならない値）。原因は項目分割の粒度ルールが無いこと。検知はスループットの週次標準偏差 / 平均比を見れば判定できる（1.0超で要注意）。回避策はライトサイジングで「N日以内に終わるサイズに分割」を運用ルール化する
仕掛中項目数（Work in Progress, WIP）と累積フロー
同時に着手している項目の総数（Anderson Kanban 2010、Kanban Guide）。リトルの法則からサイクルタイムを直接動かすレバーとして機能する。
https://gyazo.com/35e518e8b7a953e5456f51ba44501219
目的: チームが同時に手を付けている項目数はいくつか。フローの停滞要因となる過剰並行を抑制する
適用条件:
開発アプローチ: 問わない
プロセスモデル: 連続フロー（カンバン）。タイムボックス型でもイテレーション内のWIP制限として有効
デリバリモード: 問わない
向き:
目標所在: 両用（過去のフロー診断と将来のサイクルタイム予測）
観測タイミング: 先行（WIP上昇がサイクルタイム伸長に先行する）
計測方法: ボード上の「着手中」状態にある項目数を日次で集計。ステージ別（分析中・開発中・レビュー中）と全体の両方を取る。Jira・Linear・Businessmap・ActionableAgile が標準提供
活用方法: 上限値（WIP制限、column WIP limit）を設定し、上限到達時には新規着手より既存項目の完了を優先する運用に切り替える。経験則として担当者あたり1〜2項目、チーム全体ではメンバー数の1.5倍程度が目安。リトルの法則を介してスループット改善とサイクルタイム短縮の両方に効く
派生表示: 累積フロー図（Cumulative Flow Diagram, CFD） はワークフローの各列（バックログ / 着手中 / レビュー中 / 完了 等）について日次で項目数を集計し、積み上げ面グラフでプロットする。完了線の傾き（= スループット）、着手中帯の縦幅（= 仕掛中項目数）、横幅（= サイクルタイム）の3点を一画面で確認できる
失敗パターン: WIP制限を設けず「全員が常に何かに着手している」運用を続けると、レビュー待ち・ブロック中の項目が積み上がり、サイクルタイムが指数的に伸びる。原因は稼働率最大化を流量最大化と取り違えていること。検知はサイクルタイム p85 がスループット低下を伴わず単独で伸びることで判定する。回避策は列ごとのWIP制限を明示し、上限到達時には「赤い帽子（誰かを助ける）」運用に切り替える
項目経過日数（Work Item Age）
開始済みで未完了の項目の「開始からの経過時間」（Vacanti 2015、Kanban Guide）。サイクルタイムが完了後にしか確定しないのに対し、項目経過日数は今日時点で走行中の各項目について毎日計算できる。同じデータの裏表だが、観測タイミングが違う。サイクルタイムは事後の改善測定に、項目経過日数は今日の介入判断に使う、という役割分担になる。
https://gyazo.com/1fa5325d6134d39ee807886c26c24c55
目的: 走行中の各項目はいま何日経過しているか。詰まっている項目はどれか
適用条件:
開発アプローチ: 問わない
プロセスモデル: 連続フロー（カンバン）。タイムボックス型でも応用可
デリバリモード: 問わない
向き:
目標所在: 前方（走行中項目の遅延予兆）
観測タイミング: 先行（サイクルタイムが完了後しか見えないのに対し、今日時点の停滞を毎日見られる）
計測方法: ボード上の各着手中項目について 今日 - 開始日 を日次で計算。ActionableAgile・Businessmap が標準提供、Jira ならスクリプト化が必要
派生表示: エイジング・チャート（Aging WIP Chart） は項目経過日数を縦軸、ワークフローのステージを横軸にプロットした図（Vacanti、ActionableAgile Analytics で体系化）。背景に過去サイクルタイムの p50/p85/p95 を水平線で描き、日次で「p85ライン超えの項目」「p95ライン超えの項目」を順に議論する。累積フローが集計量の推移を見るのに対し、エイジング・チャートは個別項目の停滞を直視するため、即日アクションに直結する
活用方法: 日次の同期で「右端の老けた項目から話す」運用にする（55degrees解説）。SLE 超過が近い項目を同期会議でエスカレーション、ペア作業・知見共有・スコープ縮小などの介入を判断する 失敗パターン: SLE と切り離して「古い=悪い」運用にすると、まだ SLE 内の項目まで早期完了を急かされ、品質を犠牲にしたショートカットが増える。原因は項目経過日数を単独閾値で使うこと。検知は「経過5日の項目へのレビュー差し戻し率」が他より高いかで判別する。回避策は SLE ラインを必ず併記し、SLE 超過接近項目だけを介入対象にする
ライトサイジング（Right-sizing、項目サイズ上限管理）
相対見積を廃して「N日以内に終わるサイズに分割し直す」運用ルール（Vacanti、Singhが推進）。
目的: 見積りに時間をかけずに完了予測精度を上げる。サイズ分布の上裾を切り落としてモンテカルロ予測とSLEを安定させる
適用条件:
開発アプローチ: 適応型
プロセスモデル: 連続フロー（カンバン）
デリバリモード: 問わない
その他: Scrum.org の Professional Scrum with Kanban で普及
向き:
目標所在: 前方（将来項目のサイズ上限を事前に固定）
観測タイミング: 先行（モンテカルロ予測の精度を底上げ）
計測方法: 上限日数（例: 14日）をワークフロー定義（Definition of Workflow）に明記し、バックログふりかえり時に各項目が上限を越えそうかチェック。チェックには過去類似項目のサイクルタイム中央値を参照する
活用方法: 上限超過予測の項目は分割してから着手する運用ルール。サイズ分布の上裾を切り落とすことでモンテカルロ予測と SLE の予測精度が上がる（ライトサイジング解説）。ベロシティを「サイズ見積り×個数」から「右サイズに揃った個数=スループット」に置き換える効果。Story Point からの移行理由と、サイズばらつきがCT分布に乗る因果はソフトウェアの見積もり で扱う 失敗パターン: 業務上一塊で扱うべき機能（決済処理、認証フローなど）を機械的に分割すると、リリース時に部分機能が露出して整合がとれなくなる。原因はサイズ閾値を技術視点だけで適用していること。検知は「分割項目のうち単独デプロイされた割合」が低い（多くがまとめてリリース待ちになる）ことで判定できる。回避策は分割可否をプロダクトマネージャ判断とし、不可分なものはライトサイジング例外として明示
WSJF / CD3（Cost of Delay派生）
SAFe WSJF と Joshua Arnold の CD3。元はReinertsen 2009 Principles of Product Development Flow だが、2015年以降にバックログ並べ替えの実運用指標として広く流通した。 https://gyazo.com/a0fe3b89e0da8df0833f246380686336
目的: 次にどの項目を流すか決める。バックログの並べ替え基準
適用条件:
開発アプローチ: 問わない
プロセスモデル: 連続フロー、またはタイムボックス型のバックログ運用
デリバリモード: 問わない
向き:
目標所在: 前方（次に流す項目の優先順位決定）
観測タイミング: 先行（着手前に並べ替えに使う）
計測方法: 各バックログ項目に遅延コスト（Cost of Delay: ユーザー価値 + 時間的緊急性 + リスク低減・機会創出価値）と作業規模（または所要期間）を1/2/3/5/8/13のフィボナッチ数列で相対見積し、WSJF = 遅延コスト ÷ 作業規模 を算出。バックログふりかえり時にチームで合意
活用方法: バックログを WSJF 降順で並べ替えて計画会議の優先順位とする。Earned Business Value が「価値の進捗」を測るのに対し、WSJF/CD3 は「次に何を流すか」を決める並べ替え指標
失敗パターン: 遅延コストの3要素を線形足し算した結果、本来非線形な「期日が来たら価値0になる項目」（規制対応など）の優先度が低く出る。原因は遅延コストの式が時間非線形性を表現できないこと。検知は「期日のある項目が期日直前まで上位に来ない」現象から判別する。回避策は「期日付き項目」「市場機会窓項目」を別カテゴリで管理し、WSJF と並列で扱う
品質・検収判定系
請負契約・検収判定の文脈で工程完了やリリース可否を判断するためのステアリング指標群。継続デプロイ前提では DORA 変更失敗率に役割が移る。
バグ密度 / 不具合密度
KLOCまたはFPあたりの不具合件数（IPA白書）。
https://gyazo.com/50c0e9790cde9cd257daf6350246edbf
目的: テスト工程の検出バグ密度・リリース後不具合密度が基準値の範囲内か。工程完了判定の根拠
適用条件:
開発アプローチ: 予測型
プロセスモデル: 線形
デリバリモード: 個別プロジェクト
その他: 請負契約
向き:
目標所在: 後方（事前定義した基準値への適合度判定）
観測タイミング: 遅行（テスト工程完了後に集計）
計測方法: テスト工程ごとに検出バグ件数を集計し、対象モジュールのKSLOC（kilo source lines of code、空行・コメント除く実行行数）またはFPで割る。バグ管理ツール（Redmine、JIRA、Bugzilla）から検出工程別に集計、KSLOC は cloc・scc などのツールで測定
活用方法: 工程完了判定基準として使用。検出バグ密度が IPA 基準値（テスト工程は1,000FPあたり平均122件・中央値90.3件、IPA白書2018-2019）に対して大きく外れたら「テスト不足」「品質異常」を疑う。リリース後は IPA 2022年版基準（新規開発のリリース後不具合密度は平均0.100件/KSLOC、P75が0.077件/KSLOC、IPA分析データ集2022解説）で品質判定 失敗パターン: 同じ仕様でもJava→Kotlin、JavaScript→TypeScript、AI生成コード混在などでKLOCが大きく変動し、密度の経年比較・案件間比較が成立しなくなる。原因は分母（KLOC）が言語・スタイル依存であること。検知は技術スタック変更前後で密度が大きく変わるかどうかで判別する。NTTデータ自身も2021年に「5M（材料・設備・作業者・方法・測定）が統一されないプロジェクト間で密度を比較しても意味がない」と表明している。回避策は密度を絶対値ではなく自社の同条件プロジェクト群との相対比較に使う、または FP 母数に切り替える 英語圏での位置付け: 不具合密度（defect density）は英語圏でも業界標準的な品質指標として定着しており、Graphite や Kiuwan などのベンダー解説で広く扱われている。一方 DORA / SPACE / DevEx は不具合密度を直接拾わず、変更失敗率に置き換えている テスト密度（テストケース密度）
KLOCまたはFPあたりのテストケース数（IPA白書）。
目的: テストの「量」が業界基準を満たしているか。テスト不足の早期警告
適用条件:
開発アプローチ: 予測型
プロセスモデル: 線形
デリバリモード: 個別プロジェクト
その他: 請負契約
向き:
目標所在: 後方（事前定義した基準値への適合度判定）
観測タイミング: 遅行（テスト計画完成後に集計）
計測方法: テスト管理ツール（TestRail、Zephyr、Excel）から各テスト工程のケース数を集計し、対象規模（KSLOC または FP）で割る。IPA白書2018-2019では1,000FPあたり平均3,860ケース・中央値2,055ケース
活用方法: テスト計画レビューで「テスト密度が業界平均より低い→テスト不足」を判定する材料に使う。バグ密度と組み合わせてゾーン分析に投入
失敗パターン: 「業界平均ケース数を満たせ」と目標化すると、メンバーが「同じ確認項目を条件違いで分割」「無意味な等価クラスを作る」などで数を稼ぎ、テストの実質網羅性が落ちる。原因はテストケース数が「品質シグナル」として誤用されていること（liveBook ch.6 "Reporting useless but mandated metrics" の警告対象）。検知は1ケースあたり実行時間の経年短縮とケース重複率の上昇から判別する。回避策はテストケース数を目標化せず、コードカバレッジ・要件カバレッジ（要件とテストケースのトレース行列）に切り替える 英語圏での位置付け: 英語圏のテストメトリクス解説で重心となるのはテスト網羅率（カバレッジ）。"test cases per KLOC" を業界基準値として運用する実務文献は、確認できる範囲では英語圏より日本（IPA / JUAS）の方が体系化されている
レビュー指摘密度
レビュー対象ページ・KLOC・FPあたりの指摘件数（IPA白書）。
目的: レビューで検出された指摘の量が基準値の範囲内か。上流工程の品質評価
適用条件:
開発アプローチ: 予測型
プロセスモデル: 線形（上流工程の品質測定）
デリバリモード: 個別プロジェクト
その他: 請負契約
向き:
目標所在: 後方（事前定義した基準値への適合度判定）
観測タイミング: 遅行（レビュー完了後に集計）
計測方法: 設計レビュー・コードレビューでの指摘件数を、レビュー対象のページ数（仕様書）またはKLOC（コード）で割る。レビュー記録票（Excel・Confluence・Backlog）から集計。IPA白書で平均0.65件/ページ、中央値0.28件/ページ
活用方法: 工程完了判定（QGate）で「指摘密度が基準値内なら次工程へ」の判定材料。指摘ゼロは「レビューが甘い」、指摘過多は「品質異常」と判定
失敗パターン: 指標をめぐる認知バイアスで挙げた「指摘密度が基準値に満たないので何でもいいので指摘ありませんか」というキャンベル則の典型例。原因は基準値そのものを目標として運用すること。検知はレビュー指摘の中身が形式的なもの（typo、スペース、命名）に偏るかどうかで判別する。回避策は指摘の重要度別（致命・重大・軽微・表記）に分けて集計し、致命・重大の検出率を別指標として追跡 英語圏での位置付け: code review に関する指標自体は SPACE の "Activity" 軸でレビュー実施数として現れる。「指摘密度を業界基準値と比較して工程完了判定の根拠にする」運用例は、確認できる範囲ではIPA 白書を出典に持つ日本のSI現場で多く、英語圏のレビュー指標解説（SmartBear など）はレビュー速度・コメント分布の議論が中心 ゾーン分析
バグ密度を縦軸・テスト密度を横軸に取り、基準値の上下に4象限を切って案件を評価する手法（IPA/SEC『統計指標に基づく品質マネジメント実践集』）。
https://gyazo.com/16f8748929f9520563965ae2d905ab92
目的: バグ密度とテスト密度の組み合わせから「テスト不足」「品質危機」などを4象限で判定する
適用条件:
開発アプローチ: 予測型
プロセスモデル: 線形（検収前の品質評価）
デリバリモード: 個別プロジェクト
その他: 請負契約
向き:
目標所在: 後方（事前定義した基準値による象限判定）
観測タイミング: 遅行（テスト工程完了後に判定）
計測方法: バグ密度・テスト密度を計測し、IPA基準値（中央値や平均値）を境界線として4象限を描く。テスト密度高 × バグ密度高、テスト密度高 × バグ密度低、テスト密度低 × バグ密度高、テスト密度低 × バグ密度低の4象限
活用方法: 検収前のステアリング会議で象限位置を確認し、「テスト密度低 × バグ密度低→テスト不足の疑い、追加テスト指示」「テスト密度高 × バグ密度高→品質危機、リリース延期検討」など判定
失敗パターン: 同じプロジェクトでも担当ベンダー・使用言語が違えば基準値の妥当性が成立せず、判定が「データに基づく」見かけだけで実態とずれる。原因は5M（前述）の不一致を吸収する仕組みが無いこと。検知は同じ象限判定でも実際の品質結果が大きく違う事例の発生で判定する。回避策はゾーン分析を「絶対判定」ではなく「議論のたたき台」に格下げし、最終判定はQAリードの定性判断と組み合わせる
英語圏での位置付け: IPA/SEC の体系として整備されてきた手法で、nehori.com の解説 でも "In Japan, there is a zone analysis" と紹介されている。Capers Jones 系の "defect potential vs removal efficiency" マトリクスが概念的に近い 信頼度成長曲線（ゴンペルツ曲線 / ロジスティック曲線）
横軸テスト時間/ケース数、縦軸累積バグ数のS字曲線で残バグを推定する（IPA/SEC、SQuBOK）。応用情報技術者試験に出題されるレベルで日本では標準語彙。
https://gyazo.com/c68d04f6538c99b87348390664567318
目的: 残バグ数を推定してリリース可否を判定する
適用条件:
開発アプローチ: 予測型
プロセスモデル: 線形（検収判定）
デリバリモード: 個別プロジェクト
その他: 請負契約
向き:
目標所在: 前方（残バグ数の将来予測）
観測タイミング: 先行（テスト中の収束予測でリリース可否を事前判定）
計測方法: テスト実行ログから日次の累積バグ検出数をプロットし、ゴンペルツ曲線 N(t) = a × exp(-b × exp(-c × t)) またはロジスティック曲線でフィッティング。Excelのソルバー、R・Pythonの非線形回帰でパラメータ推定
活用方法: 検収判定会議で曲線の漸近値（推定総バグ数）と現時点の検出累積を比較。漸近値の95%以上を検出済みかつ検出ペースが鈍化していればリリース可、そうでなければテスト延長を判断
失敗パターン: テスト実行ペースが時間で大きく変動する（最初の1週間は密、その後失速）と、フィッティングが「実態の収束」ではなく「テストの失速」を捉えるだけになる。原因はテスト実行リソースの非定常性。検知は曲線フィッティングの残差プロットでテスト実行ペースとの相関を取れば判別できる。回避策は横軸を「経過日数」ではなく「累積実行ケース数」に取る
信頼性系
SLI（Service Level Indicator）
https://gyazo.com/31627229e95640a350b6747627058a38
https://gyazo.com/9c217b8f64a4b22d2946e1fe5c9f1fd2
目的: ユーザー視点のサービスレベルを観測する
適用条件:
開発アプローチ: 適応型
プロセスモデル: 連続フロー
デリバリモード: 継続サポート
その他: 自社プロダクトの継続デプロイ
向き:
目標所在: 両用（過去達成率の追跡と将来の信頼性投資判断）
観測タイミング: 遅行（観測時点までの計測値）
計測方法: ユーザー視点の計測値（成功リクエスト率、レイテンシのp99、データ鮮度など）。Datadog・Grafana・Honeycomb・Prometheus などのオブザーバビリティツールで継続計測
派生指標:
SLO（Service Level Objective）: SLI に対する目標水準（例: 「直近30日間の成功リクエスト率99.9%以上」）。SLI と SLO の定義はサービスレベルドキュメント（SLD）として文章化
エラーバジェット: 100% - SLO（例: SLO 99.9%ならバジェットは0.1%）
エラーバジェット消費速度（Error Budget Burn Rate）: 現在の失敗率 ÷ バジェット を時間窓（1時間・6時間・24時間・7日・30日）別に計算。Google SRE Workbook ch.5 のマルチウィンドウ・マルチバーンレートアラートが標準。Sloth・Pyrra などの SLO ツールが計算を自動化 活用方法: 月次レビューで SLO 達成率を確認、未達ならアラート設計・キャパシティプランニング・アーキテクチャ見直しを判断する。日次運用ではバジェット消費速度で意思決定: 消費速度 ≥ 14.4（1時間窓）でページ発令・即時対応、≥ 6（6時間窓）でデプロイ凍結検討、30日バジェット消費率 ≥ 100% で翌月の機能リリースを止め信頼性改善に集中
失敗パターン:
SLI を内部メトリクスで組む: CPU使用率、メモリ消費率、DBコネクション数で SLI を組むと、それらが正常でもユーザーが体感障害を経験する乖離が起きる。原因はGoogle SREが言う「ユーザージャーニーから SLI を導出する」原則の軽視。検知はユーザー苦情件数と SLI 違反件数の相関を見て、相関が弱いなら SLI が間違っている。回避策はユーザー操作1つ（ログイン、購入、検索）に対して「成功とは何か」を定義して SLI を設計
SLO が緩すぎる: バジェットが常に潤沢で、デプロイ凍結の判断材料として機能しない。原因は SLO 設定がユーザー期待ではなく現状値ベースになっていること。検知はバジェット消費率が3ヶ月連続で20%未満かどうかで判別する。回避策は SLO を半年ごとにユーザー満足度調査と突き合わせて見直す
SLO が厳しすぎる: 常時バジェット枯渇で機能リリースが止まる。原因は競合製品基準で過剰設定していること。検知はバジェット消費率が常時120%超かどうかで判別する。回避策は SLO を半年ごとにユーザー満足度調査と突き合わせて見直し、自社プロダクトのユーザー期待値ベースに引き戻す
関連: DORA Five Keys の信頼性を「単一スカラーにしない」設計判断と整合する。SLO/SLI ごとに個別に評価し、エラーバジェット消費速度でデプロイ可否を決定する構造
コーディングエージェント向けセンサー
ここまでの指標は人間が読んでチームを舵取りするものとして紹介した。コーディングエージェントが自律的に開発ループを回す場合に必要な信号群は、Birgitta Böckeler が Sensors for Coding Agents（Martin Fowler 寄稿、2025）で「センサー（sensor）」として整理している。エージェント自身がループ中にリアルタイムで参照し、継続 / 修正 / 完了の判断材料にする。 ここで挙がるセンサー群（型整合性、リンタ、SAST、テスト、ミューテーション、シークレット混入検知など）は、人間の開発者が IDE 上で常時使ってきた仕組みと本質的に同じである。違いはインタフェース層で、人間は赤線やコンパイラ警告として暗黙に受け取り、エージェントはテキスト化されたシグナルとして受け取る。「コーディングエージェント向け」という括りが立っているのは、エージェント側の開発ループ設計が新しく、明示的な体系化が必要な過渡期にあるためで、将来的には人間と共有するコーディング中の即時フィードバック層に統合されていく性質のものである。
センサーは「過去〜現在の傾向を人が読む」のではなく、「今書いたコードが妥当か」を即時に問うための個別信号として機能する。良し悪しの定義が状況依存（"good and bad does not have a clear definition, instead it is all about what is appropriate"）なため、計算的センサーだけでは設計レベルの妥当性は判定できず、意味的な解釈は LLM 自体が担うことになる。
センサーは設置層で3層に分かれる: コーディング中（即時フィードバック）/ パイプライン（同等センサーをクリーン環境で再実行）/ スケジュール実行（ドリフト検知）。
型整合性センサー
何を測るか: 静的型システムの違反
AIに返すシグナル: 違反箇所と理由を伴うコンパイルエラー
ループでの判断: 違反が残る限り次工程に進めない。修正後に再実行
設置層: コーディング中 / パイプライン
失敗パターン: 型を緩める方向（any、unknown へのキャスト、型注釈削除）でエージェントが違反を回避すると、シグナルが消えるだけで品質は劣化する。検知は型注釈の経年密度低下から判別する。回避策は any / unknown 使用率を別センサーとして並列に取る
代表的なツール例: TypeScript Compiler、mypy、Rust borrow checker、Java javac
静的コード規約センサー（リンタ）
何を測るか: コードスタイル違反、複雑度、引数数、関数・ファイル長、命名規約逸脱
AIに返すシグナル: 違反箇所と自己修正のための説明文（カスタムフォーマット）
ループでの判断: 違反があれば修正して再実行。設定で「正当化コメント付きの抑制」を許容する運用も成立する
設置層: コーディング中 / パイプライン
失敗パターン: エージェントが違反を全件「正当化コメント付きで抑制」して回避する。検知は suppression コメント数の急増から判別する。回避策は suppression を許容するルールと許容しないルールを分け、後者は強制違反扱いにする
代表的なツール例: ESLint、Pylint、golangci-lint、Checkstyle
静的セキュリティセンサー（SAST）
何を測るか: 既知の脆弱性パターン（インジェクション、安全でない API 使用、認証情報のハードコード等）
AIに返すシグナル: 検知ルールと違反箇所
ループでの判断: 違反があれば修正して再実行。深刻度別に閾値を設定可能
設置層: コーディング中 / パイプライン
失敗パターン: ルールセットが固定で AppSec チェックリストとずれていると、検知漏れが累積する。検知は脆弱性発見と SAST 検知率の乖離で判別する。回避策はルールセットを四半期ごとに AppSec チェックリストと突き合わせて更新する
代表的なツール例: Semgrep、CodeQL、SonarQube、Snyk Code
モジュール依存規約センサー
何を測るか: 内部モジュール間の import 規約違反（レイヤー逆参照、許可されていないクロス依存等）
AIに返すシグナル: 違反した import の組と適用された規約名（例: 「クライアントはサービスを直接 import しない」）
ループでの判断: 違反があれば修正、または既存制約内で新モジュールを作る判断材料にする
設置層: コーディング中 / パイプライン
失敗パターン: 規約が緩いまま運用すると、許容範囲が広がっていく方向にエージェントが解釈する。検知は許容ルール数の経年増加で判別する。回避策は規約変更を ADR で記録し、変更履歴を別に追跡
代表的なツール例: dependency-cruiser、ArchUnit、import-linter
テスト合否・カバレッジセンサー
何を測るか: 機能的正しさ（テストの pass/fail）とカバレッジ欠損
AIに返すシグナル: 失敗したテストの内容と未到達のコード箇所
ループでの判断: 失敗が残る限り終了しない。カバレッジ閾値超過まで繰り返す運用も成立する
設置層: コーディング中 / パイプライン
失敗パターン: エージェントがカバレッジを上げる目的でテストを増産し、アサーションの薄い形式的テストが増える。検知はミューテーションテストセンサーと並べて、カバレッジ上昇とミューテーション生存率上昇が同時発生していないかで判別する。回避策はカバレッジを単独閾値にせず、ミューテーション結果と併用
補足: テストは確認できる範囲では Reflexion 系の自律ループ研究でも completion proxy として最も多用されているシグナル
ミューテーションテストセンサー
何を測るか: テスト自体の検出能力。コードを意図的に変異させたときにテストが落ちる率
AIに返すシグナル: 生存したミューテーション（テストで検出されなかった変異）の箇所
ループでの判断: 生存ミューテーション率が閾値を超えていればテストを強化して再実行
設置層: コーディング中(差分のみ実行)/ パイプライン（全体実行）
失敗パターン: 全体ミューテーションは実行コストが高く、コーディング中に回しにくい。検知は CI 時間の経年悪化で判別する。回避策は差分ミューテーション（変更行に対するもの）に限定してコーディング中に回す
代表的なツール例: Stryker、PIT、mutmut
シークレット混入センサー
何を測るか: 認証情報・API キー・秘密鍵などのコミット直前混入
AIに返すシグナル: 検出されたシークレットの種類とファイル位置
ループでの判断: pre-commit フックで commit を拒否し、エージェントに除去を促す
設置層: コーディング中（pre-commit）/ パイプライン
失敗パターン: false positive を回避するために検知ルールを緩めると、本物のシークレットも見逃す。検知は false positive 件数と既知シークレット漏洩件数の比率で評価する。回避策は許可リスト（特定パターンを除外）で対処し、検知ルール自体は緩めない
代表的なツール例: GitLeaks、TruffleHog、detect-secrets
LLMによるセキュリティ姿勢レビュー
何を測るか: AppSec チェックリストに対する設計レベルのセキュリティリスク
AIに返すシグナル: チェックリスト項目ごとの推論的評価と該当箇所
ループでの判断: 即時ループには載せず、スケジュール実行で検出された項目をメンテナンスタスクとして取り込む
設置層: スケジュール実行（ドリフト検知）
失敗パターン: LLM の推論的評価は false positive と false negative の両方が出やすい。検知は人間のセキュリティレビュー結果との一致率で判別する。回避策は高信頼度で出た項目のみ自動取り込み、それ以外は人間レビューに回す
データ取り扱いポリシー違反検知
何を測るか: データポリシー（個人情報の流出経路、ログ出力範囲、外部送信先等）からの逸脱
AIに返すシグナル: ポリシーの該当項目と違反箇所
ループでの判断: スケジュール実行で検出された違反をリファクタリングタスクとして取り込む
設置層: スケジュール実行
失敗パターン: ポリシー自体が文書化されていないと、LLM の判定が組織の暗黙ルールと食い違う。検知はリファクタリング後にポリシー違反が再発するかで判別する。回避策はポリシーを自然言語の文書として明示的に保持し、判定プロンプトに渡す
依存関係鮮度センサー
何を測るか: 使用ライブラリの更新状況・廃止状況・コミュニティ活動度
AIに返すシグナル: ライブラリごとの推奨アクション（更新 / 置き換え / 静観）とリスク評価
ループでの判断: メンテナンス優先度の判定材料として使う
設置層: スケジュール実行
失敗パターン: 鮮度を絶対指標として更新を急ぐと、安定版を捨てて非互換変更を踏むリスクが上がる。検知は更新直後の変更失敗率上昇で判別する。回避策は鮮度を変更失敗率と組み合わせて評価し、安定版維持の判断軸を別に持つ
代表的なツール例: npm outdated、Dependabot、Renovate
結合度センサー
何を測るか: モジュール間の fan-in / fan-out、Dependency Structure Matrix
AIに返すシグナル: 影響範囲（impact radius）の可視化と数値化
ループでの判断: リファクタリング対象モジュールの優先度判定に使う
設置層: スケジュール実行
失敗パターン: 数値だけで「結合度が高い = 悪い」と判定すると、本質的に集約点として機能すべきモジュール（DI コンテナ、ルーター等）まで分割対象になる。検知は分割後のサイクルタイム悪化で判別する。回避策は数値判定に加えて、モジュールの役割を意味的に判定する LLM レビューを併用
代表的なツール例: madge、SonarQube の結合度メトリクス、Structure101
LLMによるモジュール性レビュー
何を測るか: 重複コードパターン、責務配置のズレ、設計パターンからの逸脱
AIに返すシグナル: 高信頼度の発見項目（「同じルーティングロジックが3箇所にある」「ビジネスロジックがコントローラに混ざっている」等）
ループでの判断: スケジュール実行で検出された項目をリファクタリング対象として取り込む
設置層: スケジュール実行
失敗パターン: 「good and bad does not have a clear definition」という性質上、LLM の判定が固定的になると、文脈に合った例外的設計まで「逸脱」として検出してしまう。検知はリファクタリング後にレビュアーが「元の方が良かった」と差し戻す率で判別する。回避策は判定結果を即適用せず、必ず人間または別の LLM レビューを経由させる
計算的センサーの限界
ここまで挙げたうち、型整合性・リンタ・SAST・依存規約・テスト・ミューテーション・シークレット混入は計算的に判定できる。一方、設計レベルの良し悪し（モジュール性、責務配置、セキュリティ姿勢、データ取り扱いの妥当性）は計算的センサーだけでは扱えず、意味的解釈を LLM 自体が担う層が要る。Böckeler は「codebase design and modularity seems like a concern where computational sensors alone cannot help us much, AI is needed to add semantic interpretation, and consider trade-offs」と述べている。
計算的センサーだけに頼ると "false sense of security and an illusion of quality" を招くという指摘もあり、センサー群は「計算的な層」と「LLM 推論を含む層」の二層構成で設計される。
改善測定メトリクス
改善努力の効果を測る指標群。改善測定の鍵となるテーゼは「開発手法に依存しないデリバリー指標こそがプロセス改善の効果測定に有用である」（liveBook ch.3）。手法を変えても比較できる手法非依存のメトリクスで改善を測れ、という主張である。 チームのデリバリ能力
プロセスサイクル効率（Process Cycle Efficiency, PCE）
価値付加時間 ÷ 総サイクルタイム。
https://gyazo.com/bee0eb118b3a1f78b81a88d712b65737
目的: 付加価値のない活動に時間を奪われているのはどこか。プロセスのどこにタイムシンクがあるか
適用条件:
開発アプローチ: 問わない（手法非依存。リーン系）
プロセスモデル: 問わない
デリバリモード: 問わない
向き:
目標所在: 両用（過去診断と改善余地の特定の両方）
観測タイミング: 遅行（完了済み項目の事後集計）
計測方法: バリューストリームマップ（VSM）を描き、各ステージを「キュー（待機）」と「アクティブ（実作業）」に分類。キュー時間はすべて非付加価値時間（NVA）、アクティブ時間のうち「複数項目の並行作業による文脈切替で失われた時間」も NVA に分類して アクティブ時の真のVA時間 ÷ 総リードタイム を計算
失敗パターン:
実作業時間定義のチーム内ばらつき: 「実作業時間」の定義をチームごとに勝手に決めると、再計算で20%が60%に跳ね上がるような誤った改善幻想を生む。原因は定義の文書化欠如。検知は他チームと値を並べたときの異常な差から判別する。回避策はバリューストリーム上の「キュー」と「アクティブ」の判定基準を組織横断で文書化し、チーム間で揃える
アクティブ＝VA の誤り: 1日に複数の項目を並行して触っていると、文脈切替で失われる時間（再びゾーンに入るのに10〜20分）が積み重なり、アクティブ時間の大半はNVAになるのに、それを付加価値時間として計上してしまう。原因は「アクティブ状態にいる時間＝付加価値時間」という暗黙視。検知は「メンバー1人が同時に何個の項目をアクティブにしているか」を測れば判別できる。回避策はWIP制限を1〜2に絞り、PCEを「キュー時間のNVA」と「アクティブ時間内のNVA」の2層で分けて記録する
使用上の注意: Nicolette 自身が「PCEの正確な生データ収集は困難なため常用には非現実的」と認めている。WIPやスループットに関する組織の思い込みに反証が要るときに、メンバーに文脈切替の事例を一時的に記録してもらって裏付けデータを取る使い方が推奨される。常時計測する指標ではない
バージョン管理履歴（Version Control History）
コミット履歴を改善測定のデータソースとして扱う。
https://gyazo.com/d99a124857eab06b88e2da191af90ff7
目的: 最も頻繁に変更されるファイルはどれか。定期的にチェックアウトされ修正されているファイルはどれか。リファクタリング投資先として最も投資回収率が高い箇所はどこか
適用条件:
開発アプローチ: 問わない
プロセスモデル: 問わない
デリバリモード: 問わない
向き:
目標所在: 両用（過去パターンの診断と将来リスクの兆候検出）
観測タイミング: 遅行（コミット済み履歴を分析）
活用方法: 改善施策（ペアプログラミング導入、テスト自動化など）の前後で履歴パターンを比較する月次レビュー素材。特定ファイルへの変更集中があれば設計負債としてリファクタリング対象に、特定時間帯への集中があれば属人化として知見共有・ペア作業対象に、それぞれ次月の改善アクションを決める
失敗パターン: コミット数や行数を指標化すると、意味のない分割コミットや無駄なフォーマット変更でメンバーが数字を稼ぎ出す。原因はGoodhart則の典型発現。検知は「1コミットあたりの平均変更行数」が時系列で減少し続けるかを見れば判別できる。回避策は履歴データを評価制度から切り離し、診断目的に限定する
DORA Four Keys から Five Keys へ
デプロイ頻度（Deployment Frequency, DF）
https://gyazo.com/f4c23737e454db1b47f131145d6b31ce
目的: 組織はどれくらいの頻度で本番に変更を届けているか。デリバリ速度の経年改善は出ているか
クラスタ: スループット系
適用条件:
開発アプローチ: 適応型
プロセスモデル: 連続フロー
デリバリモード: 継続サポート
向き:
目標所在: 両用（過去パフォーマンスの追跡と次月以降の改善方針判断）
観測タイミング: 遅行（実施済みデプロイを集計）
計測方法: 本番環境への正常デプロイ件数を CI/CD パイプライン（GitHub Actions・GitLab CI・Jenkins・Argo CD）のデプロイログから集計。週次・月次の中央値で見る。「デプロイ」の定義はチーム内で文書化する（機能フラグ切替を含むか、DBマイグレーションのみを含むかなど）
活用方法: 月次のふりかえりで自組織の経年比較を行い、改善施策（テスト自動化、トランクベース開発、機能フラグ導入など)の効果を判断。Elite・High・Medium・Low の4階級は組織横断比較ではなく自組織の経年比較に使う
失敗パターン: マネジメントが「デプロイ回数を増やせ」と目標化すると、コード変更を伴わない空デプロイや無意味な細分化デプロイで数字を稼ぐ動きが出る。原因は計測対象を「価値を運ぶデプロイ」に絞れていないこと。検知は「デプロイあたり変更行数」が時系列で減少しているかどうかで判別する。回避策はデプロイ頻度を単独で見ず、リードタイムと変更失敗率と組で評価し、変更を伴うデプロイのみカウントするフィルタを入れる
変更のリードタイム（Lead Time for Changes, LT）
目的: コミットから本番稼働までの時間。開発・レビュー・デプロイのどこに詰まりがあるか
クラスタ: スループット系
適用条件:
開発アプローチ: 問わない（手法非依存）
プロセスモデル: 問わない
デリバリモード: 問わない
向き:
目標所在: 両用（過去傾向の追跡と将来パイプライン改善の判断材料）
観測タイミング: 遅行（デプロイ完了後に確定）
計測方法: 「最初のコミット時刻」と「本番デプロイ完了時刻」の差分を PR・コミットID単位で集計。GitHub のコミットタイムスタンプと CI/CD のデプロイログを突き合わせる。Four Keys ダッシュボード（Google提供）でテンプレート化されている。中央値と p95 を見る 活用方法: 月次レビューで中央値の経年推移を確認し、CI高速化・PRサイズ縮小・レビュープロセス改善の効果を測る。p95 の悪化は「特定種別の変更だけ詰まっている」徴候として深堀り対象
失敗パターン: ブランチ運用が長寿命のフィーチャーブランチ中心だと、最初のコミットから本番までに数週間が混じり、開発本体の改善が見えなくなる。原因はリードタイムの分母に開発以外の待ち時間が混入すること。検知はトランクからの分岐生存期間の中央値から判別する。回避策はリードタイムを「PR作成→本番」に区切って計測、別にPR作成までの時間を取って分離
変更失敗率（Change Failure Rate, CFR）
https://gyazo.com/9696c699339b3dbecf7eb78b248c3851
目的: デプロイのうち失敗（ロールバック・緊急修正）を要するものの割合。速度を出しすぎていないかのガードレール
クラスタ: 不安定性系
適用条件:
開発アプローチ: 問わない（手法非依存）
プロセスモデル: 問わない
デリバリモード: 問わない
向き:
目標所在: 両用（過去パフォーマンスの追跡とリリース戦略見直しの判断）
観測タイミング: 遅行（リリース後の判定）
計測方法: 直近30日間の本番デプロイのうち、ロールバック・緊急修正・インシデント対応を要したものの割合。インシデント管理ツール（PagerDuty・Opsgenie）と CI/CD ログを突き合わせて自動集計
活用方法: デプロイ頻度・リードタイムを伸ばす施策が変更失敗率を悪化させていないかを月次で監視するガードレール指標。Elite 基準は0〜5%、悪化傾向で「速度を出しすぎている」サインとして打ち手（テスト追加、カナリアリリース、機能フラグ）を判断
失敗パターン: 「失敗」の判定基準が組織内で揺れる（緊急修正を失敗とカウントするチームとしないチームが混在）と、チーム間比較が成立せず経年比較の前提も揃わない。原因は失敗定義の標準化欠如。検知は他チームと数値が極端に違う場合に定義差を疑う。回避策は「ロールバック発生」「緊急修正デプロイ」「インシデント発令」の3条件のいずれかを変更失敗率に含めるルールを組織標準として固定する
失敗デプロイ復旧時間（Failed Deployment Recovery Time, FDRT、旧MTTR）
目的: 失敗デプロイから復旧までの時間。ロールバック自動化・カナリアリリース整備の効果測定
クラスタ: スループット系（2025年に安定性系から移動）
適用条件:
開発アプローチ: 問わない（手法非依存）
プロセスモデル: 問わない
デリバリモード: 問わない
向き:
目標所在: 両用（過去復旧能力の追跡と将来リスクの上限予測）
観測タイミング: 遅行（復旧完了後に確定）
計測方法: 失敗と判定されたデプロイ（変更失敗率の分子）について、失敗発生時刻から復旧（ロールバック完了または緊急修正デプロイ完了）までの時間を集計。中央値と p95 を見る。インシデント管理ツールのタイムスタンプから自動取得
活用方法: 月次レビューで「失敗からの復旧速度」を確認し、ロールバック自動化・カナリアリリース・機能フラグの整備効果を測る。2025年の再定義により、対象が「サービス全体障害」から「デプロイ失敗からの復旧」に絞られ、復旧の速さはスループットに寄与する性質と整理された
失敗パターン: ロールバック手段が無い組織では失敗デプロイを前進修正せざるを得ず、FDRT が時間〜日単位に伸びる。原因はリリースアーキテクチャ側の問題（DBマイグレーションの後方互換性欠如、機能フラグ未整備など）。検知は時系列で FDRT が改善しないかどうかで判別する。回避策はロールバック不能の根本原因（マイグレーション設計、フラグ運用）に踏み込み、デプロイ単位を「常にロールバック可能」に再設計
手戻り率（Rework rate）
目的: 計画外デプロイ（hotfix、ロールバック後の再リリース）の割合。AI生成コード時代の正味スループット評価
クラスタ: 不安定性系
適用条件:
開発アプローチ: 問わない（手法非依存）
プロセスモデル: 問わない
デリバリモード: 問わない
向き:
目標所在: 両用（過去の手戻り傾向追跡と次月以降のリリース戦略判断）
観測タイミング: 遅行（手戻りデプロイ後に確定）
計測方法: 直近30日のデプロイのうち、計画外デプロイ（緊急修正、ロールバック後の再リリース、直前デプロイの修正）の割合。CI/CDのデプロイトリガー種別（定期・緊急修正・ロールバック修正）でタグ付けして集計、または PR ラベル（hotfix・revert）で識別
活用方法: 変更失敗率と並べて月次レビュー。変更失敗率が捉えきれない不安定性（失敗ではないが計画から外れたリリース）を補う。AI生成コード時代の正味スループットを評価する補助指標として、生成速度が上がっても手戻りが増えていないか確認
失敗パターン: 計画外デプロイのタグ付けがチームの自己申告だと、メンバーが「手戻り」ラベルを避けて通常デプロイに分類するため数字が低く出る。原因はタグ付け運用の自動化欠如。検知はインシデント発令件数と手戻り率の相関を見て、相関がほぼゼロなら申告漏れを疑う。回避策はrevertコミット検出・hotfixブランチ検出をCI側で自動分類する
信頼性（Reliability、準メトリクス）
目的: ユーザー視点の信頼性（可用性・レイテンシ・エラー率）はSLOを満たしているか
適用条件:
開発アプローチ: 適応型
プロセスモデル: 連続フロー
デリバリモード: 継続サポート
その他: SLO と SLI が組まれている前提
向き:
目標所在: 両用（SLO達成度の過去追跡と劣化兆候による将来判断）
観測タイミング: 先行（エラーバジェット消費速度として将来枯渇を予測）
計測方法: ユーザー視点のSLI（可用性、レイテンシp99、エラー率）をオブザーバビリティツール（Datadog・Grafana・Honeycomb）で計測し、SLO目標値との差分を月次で集計。詳細は「ステアリング・メトリクス > 信頼性系」の SLI 節を参照
活用方法: 単一スカラーにせず SLO と SLI ごとに個別に評価する。DORAチームがこれを準メトリクス（quasi-metric）としているのは「組織横断のスカラー値にしない」設計判断
失敗パターン: SLO 閾値が「現状の実態」に合わせて緩く設定されると、エラーバジェットが常に余り、デプロイ抑制の判断材料として機能しなくなる。検知はエラーバジェット消費率が3ヶ月連続で20%未満なら閾値が緩い。回避策はユーザー苦情・離脱率から SLO を設定し、半年ごとに見直す
DORA 2025 で報告された AI Productivity Paradox は、AI採用が個人の生産性体感を押し上げる一方で、デリバリー指標（デプロイ頻度・リードタイム）に明確な改善が見られず、不安定性側（変更失敗率・手戻り率）の悪化傾向が観測されたという報告である。Thoughtworks 2025 DORA perspective はこれを「AI は既存の組織能力を増幅する」と要約する。 Flow Framework
Flow Items（フロー項目）は機能 / 不具合 / 負債 / リスクの4種に分類する。
Flow Velocity（フロー速度）
https://gyazo.com/eb8ad52b4db91a158d6ea73b1887f29a
目的: バリューストリーム単位で機能・不具合・負債・リスクの各種別がどれだけ完了したか
適用条件:
開発アプローチ: 適応型
プロセスモデル: 連続フロー
デリバリモード: 継続サポート
計測単位: バリューストリーム
向き:
目標所在: 両用（過去配分の追跡と将来投資判断）
観測タイミング: 遅行（完了済み項目を集計）
計測方法: バリューストリーム単位で機能・不具合・負債・リスクの4種別に「単位期間に完了したフロー項目数」を集計。Tasktop Viz などのバリューストリーム管理（VSM）ツールが標準。Jira・Azure DevOps と連携してバリューストリーム横断で集計 活用方法: 四半期レビューで4種別の伸び率を経営に提示し、投資配分の妥当性を判断する材料にする。機能だけが伸びて負債がゼロなら、技術的負債が積み上がっている兆候として再配分を検討
失敗パターン: バックログの分類運用が雑になり、不具合を機能に分類し直す圧力（数字を見栄えよくしたい）で負債 / 不具合数が見かけ上ゼロになる。原因は分類のレビュー体制不在。検知は4種別比率が時系列で「機能 100%、その他0%」のまま動かないことで判定できる。回避策はチケット作成時の分類を作成者以外（QA / エンジニアリングマネージャ / アーキテクト）がレビューする運用にする
Flow Time（フロー時間）
https://gyazo.com/9b2d194bf181d79871797eb0d03a4266
目的: 着手から顧客価値リリースまでの時間（バリューストリーム単位）
適用条件:
開発アプローチ: 適応型
プロセスモデル: 連続フロー
デリバリモード: 継続サポート
計測単位: バリューストリーム
向き:
目標所在: 両用（過去傾向の追跡と将来予測の入力）
観測タイミング: 遅行（完了後にしか確定しない）
計測方法: フロー項目の「着手」（バリューストリーム上の最初の作業ステージ入り）から「完了」（顧客価値リリース）までの時間を4種別に集計。VSMツールで自動取得、または Jira のステータス変更イベントから計算
派生指標: Flow Efficiency（フロー効率） は アクティブ時間 ÷ 経過時間（フロー時間）。リーン系のプロセスサイクル効率の組織版。10〜15%が一般的、改善で40%以上になる例もある。月次レビューで現状値を確認、待機が多いステージ（リリース承認待ち、外部チーム依存待ちなど）を特定して打ち手を判断
活用方法: 4種別の分布を月次で確認。機能が伸びているのに負債が短期化している場合は、負債を「軽い対応」だけで済ませている可能性。リスクの中央値が長期化していれば組織としてリスク対応が後回しになっている
失敗パターン: 「着手」の定義がチームごとに違う（要件定義入りを着手とするチームと、実装入りを着手とするチームが混在）と、フロー時間の値が組織横断で比較不能になる。原因はバリューストリーム定義の標準化欠如。検知はチーム別フロー時間中央値の極端な差（10倍以上）で疑う。回避策はバリューストリームマップを組織標準として描き、各ステージの定義を文書化
Flow Load（フロー負荷）
目的: バリューストリーム上で同時進行中の項目数はいくつか。過負荷の予兆検知
適用条件:
開発アプローチ: 適応型
プロセスモデル: 連続フロー
デリバリモード: 継続サポート
計測単位: バリューストリーム
向き:
目標所在: 前方（過負荷予兆としてのキャパシティ判断）
観測タイミング: 先行（負荷増加が時間遅れで時間に反映される）
計測方法: バリューストリーム上で同時に「着手中」状態にあるフロー項目数の日次平均。VSMツールから自動集計。Kanban Guide の仕掛中項目数を組織レベルに引き上げたもの
活用方法: フロー時間とのリトルの法則的関係（フロー時間 = フロー負荷 ÷ フロー速度）を月次で確認。負荷が増えて時間が伸びていれば過負荷の徴候。組織レベルでのキャパシティプランニングに使う
失敗パターン: 部門別のフロー負荷を単純合算すると、共通リソース（QA / インフラチームなど）の競合状況が消えて実態より楽観的に見える。原因は依存関係を考慮しない合算。検知はフロー速度がリトルの法則式と一致しないかどうかで判別する。回避策は共通リソース別のフロー負荷を別建てで取り、ボトルネック特定に使う
Flow Distribution（フロー配分）
https://gyazo.com/c2bc12738a585a3c2e04020f86b346b4
目的: 機能・不具合・負債・リスクへの投資配分の比率はどうか。戦略目標と整合しているか
適用条件:
開発アプローチ: 適応型
プロセスモデル: 連続フロー
デリバリモード: 継続サポート
計測単位: バリューストリーム
向き:
目標所在: 両用（過去配分の分析と将来投資戦略の判断）
観測タイミング: 遅行（完了済み項目から比率算出）
計測方法: 直近の四半期・半期に完了したフロー項目を機能・不具合・負債・リスクの4分類別にカウントし、構成比率を算出。バックログ作成時に分類タグを付与する運用が前提
活用方法: 四半期レビューで配分推移を経営に示し、戦略目標との整合を確認。機能偏重で負債が長期間ゼロなら将来コスト蓄積として警告、不具合偏重なら品質投資の必要性として議論
失敗パターン: 分類の付け方が組織政治の対象になり、負債を「機能の一部」として再分類する圧力が日常的にかかる。原因は経営報告で「機能比率が高い方がよい」という暗黙の評価。検知は同種作業の分類が時系列で変動するかどうかで判別する。回避策は分類の判定基準を組織横断で文書化し、分類変更には複数人レビューを必須にする
コードレビュー効率
PRサイクルタイム
https://gyazo.com/3a5280aeae955a4a05928ea28255bc2b
目的: PRが作成からマージまでどれくらいかかるか。どの区間（コーディング・レビュー待ち・レビュー・デプロイ）に詰まりがあるか
適用条件:
開発アプローチ: 問わない
プロセスモデル: 問わない（PRベースの開発フロー全般）
デリバリモード: 問わない
向き:
目標所在: 両用（過去ボトルネックの診断と将来パイプライン改善の判断）
観測タイミング: 遅行（マージ後に確定）
計測方法: GitHub・GitLab API から各PRの「最初のコミット時刻」「PR作成時刻」「最初のレビュー時刻」「承認時刻」「マージ時刻」を取得し、4区間に分解。
コーディング時間: 最初のコミット→PR作成
レビュー待ち時間: PR作成→最初のレビュー
レビュー時間: 最初のレビュー→承認
デプロイ時間: マージ→本番デプロイ
活用方法: 月次レビューで支配的な区間を特定し、改善打ち手を判断する。レビュー待ち時間支配ならレビュアー割当の自動化、レビュー時間支配ならPRサイズ縮小ルール、デプロイ時間支配ならCI/CD並列化
失敗パターン: 区間定義がツール間で揺れる（レビュー待ち時間を「PR作成→Ready for Review」とするツールと「PR作成→最初のコメント」とするツールが混在）と、ツール乗り換え時に経年データの連続性が失われる。原因は定義の文書化欠如。検知はツール変更前後で値がジャンプするかどうかで判別する。回避策は組織内で4区間の定義を文書化し、ツール選定時に同じ定義で計測できることを必須要件にする
レビュー待ち時間（Review Latency / Pickup Time）
https://gyazo.com/655277dee12fd3ce98ee26049ad0559f
目的: PR作成から最初のレビューまでどれくらい待つか。放置PRパターンの検知
適用条件:
開発アプローチ: 問わない
プロセスモデル: 問わない（PRベースの開発フロー）
デリバリモード: 問わない
向き:
目標所在: 両用（過去レビュー応答性の追跡と放置PRリスクの予兆検出）
観測タイミング: 先行（PR作成→放置の予兆を即日検知）
計測方法: 各PRについて「PR作成時刻」と「最初のレビューコメントまたは承認時刻」の差分を集計。GitHub APIで自動取得可能。中央値・p95・p99を週次で記録
活用方法: 週次のフローふりかえりで p95 を見て、放置PRパターンを検知。p95 超過PRの著者・対象モジュール・PR種別を分析して、特定領域だけ放置される構造（マイナーモジュールの担当者不在など）を特定
失敗パターン: チャット（Slack / Teams）で非公式レビューが先行している場合、ツール上のレビュー待ち時間は実態より長く出る。原因はレビュー記録チャネルの分散。検知はメンバーへの「レビューを受けた感覚」アンケートと数値の乖離から判別する。回避策はレビューコメントを必ずPR上に記録するルールを置き、チャットでの議論結果はPRコメントに転記
PRサイズ（変更行数 / 変更ファイル数）
https://gyazo.com/10f21daaf22a21301c77b787830e1bab
目的: PRの大きさはレビュー品質を保てる範囲か。AI生成コード混入によるサイズ膨張を検知
適用条件:
開発アプローチ: 問わない
プロセスモデル: 問わない（PRベースの開発フロー）
デリバリモード: 問わない
向き:
目標所在: 両用（過去傾向の追跡と将来のレビュー品質予測）
観測タイミング: 先行（大型PR増加が将来のレビュー漏れに先行する）
計測方法: 各PRの追加行数 + 削除行数 + 変更ファイル数を GitHub API から取得。中央値・p85分布で見る。生成ファイル（package-lock.json、自動生成コード）を除外するフィルタを設定
活用方法: 月次でPRサイズ分布を確認、大型化傾向ならPR分割文化の啓蒙・スタックドディフ・ツール 導入を判断。Google研究のPRサイズとレビュー深度の逆相関を根拠に「400行以下を目安」などの組織ガイドラインを設定 失敗パターン: AI生成コードや自動スキャフォールディングのPRが混入すると分布が歪む（Faros AI 観察でAI支援開発のPRサイズが+154%）。原因は除外フィルタ設定の不備。検知は中央値が短期間で50%以上跳ねるかどうかで判別する。回避策は自動生成パスのフィルタを継続メンテし、AI生成PRは別ラベルで分離計測 マージ頻度（Merge Frequency）
https://gyazo.com/b0005b4516fc6c0a155b7445ea25bdb1
目的: 単位期間あたりのマージ件数。DORAデプロイ頻度より上流のスループット指標
適用条件:
開発アプローチ: 問わない
プロセスモデル: 問わない（PRベースの開発フロー）
デリバリモード: 問わない
向き:
目標所在: 両用（過去スループットの追跡とパイプライン詰まりの兆候検出）
観測タイミング: 遅行（マージ済み件数を集計）
計測方法: 単位期間（週・月）あたりのマージ件数をリポジトリ別・チーム別に集計。GitHub API・GitLab API で自動取得
活用方法: DORA のデプロイ頻度と並べて月次レビュー。マージ頻度が高いがデプロイ頻度が低いならリリースパイプライン側のボトルネック、両者連動なら開発スループット改善が直接デリバリーに反映されている健全な状態
失敗パターン: マネジメントがマージ数を目標化すると、PR小型化の名目で意味のない分割PRが量産される。原因はマージ数を「価値のシグナル」と誤解した目標化。検知は1PRあたり変更行数の経年減少とマージ数増加の同時発生から判別する。回避策はマージ数を単独で評価せず、PRサイクルタイムと1PRあたり変更行数とセットで評価
不具合除去効率（Defect Removal Efficiency, DRE）
https://gyazo.com/8fed5da4d72178f14ed389a12cbde2e3
https://gyazo.com/3f56e8acfed8bcc3a360d6db92d69e8b
目的: 上流フェーズ（設計レビュー・コードレビュー・単体テストなど）の不具合検出能力はどうか
適用条件:
開発アプローチ: 問わない
プロセスモデル: 問わない
デリバリモード: 問わない（請負・内製を問わず、リリース後不具合を観測できる体制が前提）
向き:
目標所在: 後方（過去フェーズ別の検出能力評価）
観測タイミング: 遅行（リリース後N日経過してから確定）
計測方法: 不具合管理ツール（Jira、Bugzilla、ServiceNow等）で各不具合に「検出フェーズ」（設計レビュー・コードレビュー・単体テスト・結合テスト・システムテスト・リリース後）を必須項目で記録。リリース後N日（30日・90日・1年）の累積でDREを再計算
活用方法: リリース後30日 / 90日でDREを集計し、上流フェーズの検出能力を評価。設計レビューでの検出率が低ければレビュー手法の見直し、単体テストでの検出率が低ければカバレッジ強化を判断。業界平均は概ね85%、ベストプラクティスで95%以上
失敗パターン: リリース後検出をカウントするまで分母が確定しない遅行指標で、リリース直後の数字は楽観方向に偏る（リリース後不具合の発見にラグがある）。原因はDREの分母が時間とともに増えること。検知は「リリース30日時点DRE」と「リリース90日時点DRE」の差から判別する。回避策はDREを「リリース後N日」と明示してN別に並べる。N=30は速報値、N=90を確定値とする
英語圏での位置付け: DREはCapers JonesのSPR社ベンチマーク系で英語圏の品質工学に定着している。継続デプロイ環境では「リリース」が日次の出来事になるためフェーズ区切りが曖昧になり、DORAの変更失敗率と役割が重なる
規模・見積
ファンクションポイント（FP）法と工数生産性
機能規模を測る国際標準と、それを用いた人月生産性指標（IPA白書、JUAS、IFPUG / COSMIC ISO標準）。
目的: 機能規模を技術スタック非依存に測る。FP/人月で生産性を評価
適用条件:
開発アプローチ: 予測型
プロセスモデル: 線形
デリバリモード: 個別プロジェクト
その他: 請負契約の見積根拠
向き:
目標所在: 後方（過去案件のFP/人月で見積根拠を作成）
観測タイミング: 遅行（案件完了後にしか実績は確定しない）
計測方法: IFPUG計算ルールに従って、入力・出力・照会・内部論理ファイル・外部インタフェースファイルを数えて重み付け加算しFPを算出。FP/人月、KSLOC/人月でチーム別生産性を集計。人月単価の業界基準値はJUASのソフトウェアメトリックス調査で毎年公表されている 活用方法: 新規案件の見積根拠（過去類似案件のFP/人月から逆算）と、案件完了後の生産性評価（実績FP/人月の業界平均比較）に使う
失敗パターン: FP/人月は技術スタック・アーキテクチャ・チーム構成・要件複雑度で大きく変動するが、契約交渉では「業界平均と比較して妥当」の論拠として絶対視されがちで、案件特性に合わない見積を導く。原因は変動要因を吸収する補正係数の運用欠如。検知は同社内でも案件によって生産性が3倍以上違うかどうかで判別する。回避策はFP/人月を絶対値で論じず、案件特性別（業務系・組込系・Web系）の自社内ベンチマーク比で評価
英語圏での位置付け: IFPUG が国際標準として業務系で活動を続けている。Capers Jones はファンクションポイントを唯一妥当な普遍メトリクスと主張している。一方、アジャイル系の見積実務では相対見積（ストーリーポイント）が広く使われ、DORA / SPACE / DevEx は FP を直接の指標として採用していない 工程別工数配分基準
「企画」「要件定義」「設計」「製造」「テスト」工程ごとの人月配分の基準値（IPA白書、JUAS）。請負契約の見積根拠として機能している。
目的: 工程別工数配分が業界基準に対して妥当か（テスト工数不足・設計工数過多などの診断）
適用条件:
開発アプローチ: 予測型
プロセスモデル: 線形
デリバリモード: 個別プロジェクト
その他: 請負契約
向き:
目標所在: 後方（事前定義された業界基準値への適合度判定）
観測タイミング: 遅行（プロジ
観測タイミング: 遅行（プロジェクト終了後にしか確定しない）
計測方法: プロジェクト終了後にメンバーの工数記録（タイムシート、Redmine工数）を工程別に集計し、総工数に対する比率を算出。IPA白書 / JUAS 調査が基準値を提供
活用方法: 新規案件の見積で「設計30% / 製造40% / テスト30%」のような基準配分を参考に予算配分。完了後に基準値からの乖離を分析し、「テスト工程の比率が低い→品質リスク」「設計工程が肥大→過剰設計の疑い」などの診断材料
失敗パターン: 機能横断で工程を繰り返す適応型開発チームでは「工程」自体が連続的に進むため、配分基準を適用する対象がそもそも無い。原因はウォーターフォール工程モデルの暗黙前提。検知は1イテレーション内で全工程が並行している事実を見れば判別できる。回避策は適応型開発の案件で工程別配分を使わず、「機能 / 不具合 / 負債 / リスクへの配分」（Flow Distribution）に置き換える
英語圏での位置付け: 確認できる範囲では、Capers JonesのSPR社ベンチマークがフェーズ別工数配分の英語圏ベンチマークとして知られている。適応型開発の文脈では「工程」自体が短いサイクルで繰り返されるため、フェーズ別配分の枠組みは適用しにくくなる
開発者体験・組織健康度
ニコニコカレンダー（Niko-Niko Calendar）
チームメンバーが毎日の気分を顔マークで記録する。
目的: チームの感情状態が時間の経過とともにどう変化しているか。士気に影響する組織問題の早期警告
適用条件:
開発アプローチ: 問わない
プロセスモデル: 問わない
デリバリモード: 問わない
その他: 新規結成チームの形成期に特に有効
向き:
目標所在: 両用（過去のチーム状態を可視化、将来の問題兆候も拾える）
観測タイミング: 遅行（記録時点までの感情を集計）
成功要因: チームがデータ提供への参加に自発的に同意していること
活用方法: ふりかえりで2週間の推移を眺め、低調日の出来事を振り返る素材にする。Tuckman モデルの混乱期 / 規範期のチームで特に有効、機能期では不要になる（InfoQ Q&A） 失敗パターン:
評価制度との接続: 査定・昇格・賞与に紐づくとメンバーが本心と無関係に高評価マークを付け、データが無意味化する。原因は心理的安全性の欠如と匿名性の欠如。検知は全員が同じマークを付け続ける（分散ゼロ）かどうかで判別する。回避策は記録を評価から完全に切り離し、進行役 / エンジニアリングマネージャ以外がデータを見ない運用にする
ハッピーキャンパー: 1人のメンバーがほぼ常にポジティブで、他のメンバーが浮き沈みを示す中で例外的に見える。報復を恐れて公にネガティブを出せない / 純粋に楽天的 / ゲーム感覚で楽している、のいずれかを示唆する。職場で常時積極性を発揮するのはあまりに珍しく、調査の対象になる
オメガウルフ: 1人のメンバーが他のメンバーの感情と無関係に常にネガティブ。狼の群れにあるオメガ役と同じく、群れのフラストレーション解消弁として機能している可能性がある。その人を解雇しても他のメンバーが同じ役を担うようになる。組織のシステム的機能不全を疑い、個人ではなく組織側を変える
ゾンビチーム: 全員が常にニュートラルで、プロジェクトの好不調にも休日にも反応しない。マネジメントの細かい指示でチームが所有権を失っている / 熱狂的コーチがチームの作業習慣を所有してしまった / 成功しすぎて新規プラクティスのモチベーションが失われた、のいずれかを示唆する
感情振動曲線（Emotional Seismogram）
イテレーションを通じた感情の振れを線グラフで記録する。
目的: 前回のイテレーションの過程でチームメンバーはどう感じていたか。感情の浮き沈みにつながる問題の特定
適用条件:
開発アプローチ: 問わない
プロセスモデル: 問わない
デリバリモード: 問わない
向き:
目標所在: 後方（過去イテレーションの振り返り素材）
観測タイミング: 遅行（イテレーション終了後に事後記録）
成功要因: チームがハートビート・レトロスペクティブを実践していること
計測方法: イテレーション終了時のふりかえりで、メンバー各自がイテレーション期間を横軸、感情の高低を縦軸に取った線グラフを描く。ニコニコカレンダーが日次離散値なのに対し、感情振動曲線は事後にイテレーション全体を線で振り返る
活用方法: 各メンバーの線を重ねて、共通の山（盛り上がり）と谷（落ち込み）の出来事を特定し、改善アクションの素材にする
失敗パターン: 成果が良かったイテレーションでは記憶が美化され、谷も浅く描かれる結果バイアスが乗る（InfoQ Q&A）。原因は事後一括記録という記録方式そのもの。検知は事前にメモを取っていたメンバーと取っていないメンバーの線を比較すると差が出る。回避策は週次や日次のメモ（ニコニコカレンダー）と組み合わせ、ふりかえり時点ではメモを参照させる Happiness Index
チームメンバーが幸福度を数値で自己評価する。
https://gyazo.com/9d2eba739e9b9d67455edf7a0a10ea74
目的: チームメンバーはどのような思いで働いているか。モラルの低下傾向を早期察知してチーム崩壊を防ぐ
適用条件:
開発アプローチ: 問わない
プロセスモデル: 問わない
デリバリモード: 問わない
向き:
目標所在: 両用（過去傾向の追跡と退職リスクの予兆検出）
観測タイミング: 先行（離職や燃え尽きの予兆として機能することがある）
成功要因: ポジティブでない感情を表明したときに安全を確保する組織文化があること。安全でない文化では入力を匿名化する
計測方法: 1〜5または1〜10のスケールでメンバー各自が幸福度を週次または隔週で記録。Officevibe / Culture Amp / Google Forms などのアンケートツールで匿名収集
活用方法: チーム平均と分散を月次で追跡し、改善施策（働き方変更、ツール導入、組織変更）の前後で変化を比較。下降傾向時に1on1やふりかえりで深堀り
失敗パターン: 査定や OKR に幸福度指標を結びつけると、低い値を付けにくくなり全員が4点以上に固まる。原因はサロゲーション（数字が実態を置き換える）。検知は分散がほぼゼロになることで判定できる。回避策は人事や評価者が個人別データにアクセスできない仕組み（チーム平均のみ閲覧可）にし、解釈は「絶対値ではなく変化」に限定する
Health and Happiness Index
観測されたデリバリー実績（Health）と知覚された実績（Happiness）のギャップを見る指標。
https://gyazo.com/a47a73bd9541565a27012503321bf885
目的: チームの自己認識と実態は乖離していないか。過信や過小評価の方向と原因を探る
適用条件:
開発アプローチ: 問わない
プロセスモデル: 問わない
デリバリモード: 問わない
向き:
目標所在: 両用（過去ギャップの診断と将来の認識ズレリスク検出）
観測タイミング: 遅行（観測データと主観評価の事後比較）
計測方法: Health側はサイクルタイム・スループット・変更失敗率（CFR）などの客観メトリクスからスコア化、Happiness側はチームの主観評価アンケート。両者を同じスケール（1〜10）に正規化して並べる
活用方法: 月次レビューで両者のギャップを確認。Happiness > Health なら過信（実態より良いと感じている）、Happiness < Health なら過小評価（実態より悪いと感じている）。前者ならフィードバックループの不足、後者なら成功事例の見落としを疑う
失敗パターン: Health側に主観的な評価（「うまくいったと思う度合い」など）を混ぜると両者が同じ方向に動き、ギャップが恒常的にゼロになる。原因はHealthを客観指標に縛るルールの欠如。検知は両指標の相関係数が0.9以上で疑う。回避策はHealth側を必ず計測値（サイクルタイム、CFRなど）から算出する手順に固定し、定義を文章化
SPACE 5次元
https://gyazo.com/9706a963695b874ca3725d64ff18e4ce
目的: 開発者生産性を単一指標に還元せず多次元で捉える。次元間のトレードオフを可視化する
適用条件:
開発アプローチ: 問わない
プロセスモデル: 問わない
デリバリモード: 問わない
その他: 開発者生産性を多次元で測る場面
向き:
目標所在: 両用（過去傾向の追跡と組織課題の予兆検出）
観測タイミング: 遅行と先行の混在（Activityなどは遅行、Satisfactionは先行）
計測方法: 各次元から具体メトリクスを選択し、ツールで自動取得し、アンケートで主観値を補う。
満足度: 四半期eNPS、退職意向アンケート
パフォーマンス: DORA Five Keys
活動量: Git・PRデータ（LinearB・Faros AI）
コミュニケーション: PRレビュー時間
効率: サイクルタイム、中断頻度
活用方法: 四半期レビューで複数次元を並べて確認し、トレードオフを明示する。例: 活動量上昇 + 満足度低下＝過負荷の徴候、パフォーマンス維持 + 効率悪化＝個人努力で吸収している徴候。経営報告ではダッシュボード化せず議論材料に留める
失敗パターン: 活動量（コミット数、PR数）を単独で評価指標にすると、メンバーが意味のない小コミットを量産する。原因は活動量メトリクスの動機づけ機能を制御せず評価制度に直結させたこと（情報提供→動機づけへの用途変更）。SPACE論文が「単一次元を指標化するな」と明示する原則の軽視でもある。検知は1コミットあたり変更行数の経年減少、PRサイズの異常な小型化で判別する。回避策は活動量を必ず他4次元と組で見て、評価面談では活動量単独の言及を禁じる
関連: 上記5次元のうち満足度・幸福は Happiness Index、パフォーマンスはDORA系を流用可能
フィードバックループ
https://gyazo.com/e4c6bf2ccf67cea94bc487212ea77b10
目的: 主要なフィードバックループ（CI・レビュー・デプロイ・ユーザー）の応答時間は許容範囲か
適用条件:
開発アプローチ: 問わない
プロセスモデル: 問わない
デリバリモード: 問わない
向き:
目標所在: 両用（過去応答時間の追跡と将来投資判断）
観測タイミング: 遅行（観測完了後に集計）
計測方法: 主要フィードバックループの応答時間を時系列で取得。
コミット→CI結果: GitHub Actionsログ
PR→初回レビュー応答: GitHub API
デプロイ→オブザーバビリティデータ: Datadog・Grafana
ユーザーリリース→フィードバック: NPS、レビューサイト
各ループの中央値と p95 を月次集計
活用方法: ループ別に「許容上限」を設定（CI < 10分、PRレビュー < 4時間 等）。p95 超過のループから優先的に投資判断（CI並列化、レビュアー割当の自動化、オブザーバビリティ・ダッシュボード整備）
失敗パターン: CI時間を単純に短縮目標化すると、テストを並列化せず単に「重いテストをスキップする」「主要テストだけ通す」運用が出る。原因はフィードバックの「速さ」と「網羅性」のトレードオフを認識していないこと。検知は変更失敗率がCI短縮と並行して悪化するかどうかで判別する。回避策はCI時間と変更失敗率・手戻り率を必ずペアで監視し、CI短縮施策の副作用を検証
AI使用の影響
AI支援開発の新しい現象を測ろうとする指標群。いずれも単独で目標化するとGoodhart則が働く。Goodhart の四類型と運用の落とし穴は指標をめぐる認知バイアス参照。 AI提案受理率（AI Suggestion Acceptance Rate）
https://gyazo.com/83abce70af2cc80c0d60659deabe0018
目的: AIの提案がどれくらい受け入れられているか。導入支援対象の特定
適用条件:
開発アプローチ: 問わない
プロセスモデル: 問わない
デリバリモード: 問わない
その他: GitHub Copilot・Cursor・Claude Code 等のIDE統合AI
向き:
目標所在: 両用（過去のAI活用度の追跡と導入支援対象の特定）
観測タイミング: 遅行（受理・拒否の事象を集計）
計測方法: GitHub Copilot Metrics API、Cursor analytics、自社IDE拡張のテレメトリから「提案表示数」と「Tab/Acceptキーで受理された数」を集計し受理率を算出。チーム別・言語別・タスク種別（新規実装・リファクタリング・不具合修正）でセグメント
活用方法: AI導入施策（プロンプトテンプレート整備、社内ナレッジ連携、エージェント設定共有）の前後で受理率の変化を月次で確認。低受理率の言語・タスク種別を特定して導入支援対象にする
失敗パターン: マネジメントが受理率を目標化すると、AIが「受理されやすい無難な提案」（コメント追加、変数リネーム、自明なボイラープレート）に最適化されて、本質的な実装支援価値が落ちる。原因は受理率を「品質シグナル」と誤解し、診断メトリクスを目標化して動機づけ用途に切り替えたこと。検知はAI支援前後でPRサイズが+154%、不具合が+9%の同時発生（Addy Osmani: Reality of AI-Assisted Productivity のFaros AI 観察）のような副作用から判定する。回避策は受理率を単独で見ず、AI起因の変更失敗率・手戻り率と必ず併記する AI起因の変更失敗率 / 手戻り率
https://gyazo.com/2dc16fbf0faf068a85bb2268fa501146
目的: AI生成コードが品質に与える影響を分離して評価する
適用条件:
開発アプローチ: 問わない
プロセスモデル: 問わない
デリバリモード: 問わない
その他: DORA運用と組で
向き:
目標所在: 両用（AI支援の品質影響を過去評価し、将来のAI使用範囲判断に使う）
観測タイミング: 遅行（リリース後に確定）
計測方法: PR・コミットに「AI生成」ラベル（Copilot コミットは co-authored-by から自動検出可、Cursor・Claude Code はコミット規約で付与）を付け、変更失敗率と手戻り率を「AI生成PR」「人間PR」のセグメント別に集計。差分を月次で算出
活用方法: 月次で AI生成PRの変更失敗率 ÷ 人間PRの変更失敗率 を見る。比率が1.0を大きく超えるならAI支援が品質を下げている、1.0以下ならAI支援が機能している。比率に応じてAI使用範囲（重要モジュールでの制限、レビュー強化）を判断
失敗パターン: 「AI由来」の分類自体が曖昧で、半分人間が修正したPRをどちらに分類するか判定不能。分類を避ける運用が出るとAI起因の問題が見えなくなる。原因はAI寄与度の二値分類しかできていないこと。検知は「AI生成」ラベル率の経年減少（実態は使っているのに記録が減る）から判別する。回避策はAI寄与度を5段階（生成のまま採用・部分修正・大幅修正・アイデアのみ参照・未使用）で記録し、段階別にメトリクスを集計
補足: METR 2025年RCT は経験豊富なOSS開発者16名でAI使用時に作業時間が19%増加することを観測。事前期待は -24%、事後体感は -20%、実測との約40ポイント差は知覚バイアスを示す 理解負債（Comprehension Debt）
目的: AI生成コードに対する人間側の理解度の不足を可視化する
適用条件:
開発アプローチ: 問わない
プロセスモデル: 問わない
デリバリモード: 問わない
その他: AI生成コードが蓄積する組織
向き:
目標所在: 前方（人間理解の喪失リスクを将来予測）
観測タイミング: 先行（人間の理解低下が将来の重大障害・属人化に先行する）
計測方法: 複数の代理指標を併用。バス係数（特定ファイルを最も変更している人数の少なさ、git blame から算出）、コード説明テスト（AIで生成→人間が説明できるかの合格率、四半期1回の社内テスト）、コード変更時のAI依存率（修正PR起こす際にAIに「このコードは何をしているか」を尋ねる頻度をIDE拡張で計測）
失敗パターン: 自己申告型のテストや調査だけで測ると、メンバーが評価を気にして「理解しているふり」を申告し過小評価される。原因は社会的望ましさバイアス。検知は申告値とコード変更の品質指標（変更失敗率、手戻り率）の相関がほぼゼロなら申告が機能していない。回避策は構造指標（バス係数、AI依存率）を主指標とし、自己申告は補助
仕様乖離率（Spec Drift Rate）
確立した呼称はまだなく、仕様駆動開発（SDD）の実務界隈で議論が始まっている指標。ここでは仮にこの名で呼ぶ。
https://gyazo.com/a755695ad1e3556656501f69df5eae52
目的: 実装と仕様の乖離を計測し、仕様が更新されないまま放置される事態を防ぐ
適用条件:
開発アプローチ: 問わない
プロセスモデル: 問わない
デリバリモード: 問わない
その他: 仕様駆動開発（Spec-Driven Development）
向き:
目標所在: 両用（過去乖離傾向の追跡と仕様陳腐化の予兆検出）
観測タイミング: 先行（乖離率の上昇が将来の重大障害に先行する）
計測方法: 仕様ファイル（CLAUDE.md・AGENTS.md・BDD feature・OpenAPI・ADR 等）と実装の整合をCIでチェック（仕様ロックCI、契約テスト、OpenAPI実装乖離検出）。違反件数 ÷ チェック実施回数 を週次で集計。仕様ファイルの最終更新日からの経過日数も併記
活用方法: 週次で違反率が閾値（例: 5%）超過時に開発を一時停止して整合作業を実施。仕様の最終更新が30日以上前なら「仕様が古い疑い」として更新優先度を上げる
失敗パターン: 違反率を下げる目的でドキュメントを機械的に更新（実装に合わせて仕様を書き換える）すると、仕様が「現状追認の記録」になり唯一の正解（Source of Truth）として機能しなくなる。原因は仕様の意図と実装の乖離を判断する人間レビュー不在。検知は仕様変更PRの中身が「実装に合わせる」ものばかりで議論コメントが少ない場合に判別する。回避策は仕様変更PRに必ず「変更理由」をテンプレート必須項目で書かせ、実装追従なら別プロセス（形式承認ではなくアーキテクトレビュー）を経由
AI生成コード比率（LLM Generated Code Share）
目的: コミット・PRに占めるAI生成コードの割合（観測値であって目標値ではない）
適用条件:
開発アプローチ: 問わない
プロセスモデル: 問わない
デリバリモード: 問わない
その他: AI導入の進捗測定
向き:
目標所在: 後方（過去のAI活用度を測る）
観測タイミング: 遅行（コミット済みコードを分析）
計測方法: コミット・PRに占めるAI生成行数の割合を git ログから算出（co-authored-by、コミットフッター、IDE拡張のテレメトリ）。ファイル別・言語別・モジュール別にセグメント
活用方法: 単独では使わず、変更失敗率・手戻り率・認知負荷・AI提案受理率と並べて「AI生成比率が高まる中で品質指標がどう動いたか」を月次で確認。Stack Overflow Developer Survey 2025 では45%がAI生成コードのデバッグコストが生成価値を超えると回答、66%が「almost right」な解が最大の時間泥棒と回答（出典は同 Addy Osmani）
失敗パターン: AI生成比率を「DX進捗のKPI」として目標化すると、不要な箇所までAI生成して比率を稼ぐ動きが出る。原因は比率を「成果」と誤解した目標化。検知はAI生成比率の上昇と変更失敗率・手戻り率の同時悪化から判別する。回避策はAI生成比率を「観測値」に留め、目標は変更失敗率・手戻り率改善と開発者満足度向上の同時達成に置く
複数メトリクスを組み合わせて判断する
単一メトリクスの傾向はデリバリ問題を示すことができるが、同様に誤検出も起こす。複数メトリクスを組み合わせると誤検出が見え、問題を早期に発見できる。複数メトリクスを協調させて状況を診断し打ち手を決めるパターンを3つ挙げる。
パターン1: 定期的なリファクタリングの繰り返し
チームが「できるだけ早く納品しろ」というプレッシャー（実体でも知覚でも）の下で内部品質への投資を後回しにし続け、コードベースが徐々に扱いにくくなる。あるイテレーションでコードが手に負えなくなり、チームは1イテレーション丸ごとコードのクリーンアップに費やす。きれいになったところで再びプレッシャーがかかり、同じパターンが繰り返される。
併せて見るメトリクス:
ベロシティ
サイクロマティック複雑度（静的コード解析）
自動テストカバレッジ
ニコニコカレンダー
症状の見え方:
ベロシティが徐々に低下→クラッシュ→回復→再び低下を繰り返す
サイクロマティック複雑度が徐々に上昇→是正期間で低下→再び上昇を繰り返す
テストカバレッジも低下→是正→低下のサイクル
ニコニコカレンダーは最初の数サイクルではこのリズムを反映するが、サイクルを繰り返すうちにチームがやる気を失い「ゾンビチーム」パターンに移行する
1指標では見えないもの: ベロシティだけ見ていると「平均すれば一定」に見える。複雑度だけ見ても「定期的に下がっている」と肯定的に解釈できる。4指標を併せて見て初めて、内部品質の劣化とモラルが連動して悪化する構造が見える。
是正措置: チームが内部品質への投資を後回しにせざるを得ない要因（実体プレッシャー / 知覚プレッシャー / 評価制度）を解除する。良いソフトウェア開発手法を学び・採用する時間を与える。改善後はベロシティが安定し、複雑度は許容範囲で平坦化し、カバレッジは漸近的に上昇し、ニコニコは正常な変動パターンに戻る。
パターン2: ベロシティは良さそうなのに、デリバリが少ない
ベロシティチャートは安定して見えるが、実際のデリバリが伴っていない。チームが「ストーリーポイントを稼ぐ」ためにユーザーストーリー以外の作業（要件ストーリー、設計ストーリー、テストストーリーなど）にポイントを付与している、あるいは縦割りではなく横割り（DB変更ストーリー、ミドル変更ストーリー、フロント変更ストーリー）でポイントを主張している。
併せて見るメトリクス:
ベロシティ
Running Tested Features（RTF）
Earned Business Value（EBV）
スループット（リリースごとの本番投入機能数）
症状の見え方:
ベロシティは安定しているように見える
一方 RTF は数イテレーションごとにしか上がらない（着実に伸びていない）
EBV も「ぱっと上がってまた止まる」というステップ状の伸び。S字カーブにならない
スループット（リリースあたり本番投入機能数）は期待値より大幅に低い
1指標では見えないもの: ベロシティだけ見ていると順調に見える。RTF・EBV・スループットを併せて見て初めて「ポイントは稼げているが価値は出ていない」が判明する。
是正措置: ベロシティのチーム外共有をやめる。タイムボックス内に完結しなくてもユーザーストーリー単位を厳密に守る。ベロシティを真の数値に戻すと一時的に大幅低下するが、これは「以前の数値が誤りだった」ことの可視化であって、悪化ではない。
パターン3: ベロシティは不規則だが、デリバリは安定
ベロシティチャートはイテレーションごとにギザギザだが、リリースバーンチャートを見るとデリバリは安定している。これは多くの場合「ホッケースティック」パターンで、各イテレーションの後半まで何も完了せず最後の1〜2日に駆け込みで完了する。
併せて見るメトリクス:
ベロシティ
リリースバーンチャート
日次イテレーションバーンダウン
仕掛中項目数（WIP）
症状の見え方:
ベロシティがイテレーションごとにギザギザ
リリースバーンチャート（複数イテレーションにまたがる累積）は滑らかに上昇
個別イテレーションのバーンダウンはイテレーションの最後の1〜2日で急降下するホッケースティック型
WIP はイテレーション前半で高水準のまま動かない
1指標では見えないもの: ベロシティのギザギザだけ見ると「チームが不安定」と誤解する。リリースバーンチャートも一緒に見ると、結局デリバリは安定していてベロシティの変動は表層的だと分かる。さらに日次バーンダウンと WIP を見ると、「イテレーションの最初に全項目を着手→最後にまとめて完了」というバッチ思考の問題が見える。
是正措置: WIP制限を1〜2に絞り、各メンバーが一度に1〜2項目に集中する。機能スペシャリスト間のハンドオフを減らし、テスト可能なサンプルから要件を駆動する。チームが継続フロー型の働き方に移行できれば、ベロシティのギザギザは収まる。
共通原則
3パターンを通して見える共通原則:
単一メトリクスは誤検出する。複数を組み合わせて打ち手を判断する
プロセス系・技術系・人的系の異なる分類を組み合わせると、状況がより豊かに見える
メトリクスは根本原因を教えない。「何かが期待からずれている」というフラグを示すだけで、原因分析と是正措置は人間の判断
進捗を追跡するメトリクスは継続的に、プロセス改善を測るメトリクスは一時的に使う。改善目標が達成されたらそのメトリクスの追跡は終了する
メトリクスの選び方
デリバリモード別の指標群
冒頭で示したデリバリモードによる分岐を、具体的な指標群で整理する。
単一デリバリーを前提に組まれた指標群は、検収前に品質を出し切るためのものが中心である。バグ密度、テスト密度、ゾーン分析、信頼度成長曲線、FP生産性、EVM、工程別工数配分基準がこの系統。アーンドバリュー、予算消化率、スコープ進捗率も重なる。
定期デリバリーや継続サポートを前提に組まれた指標群は、流量と復旧速度を見るものが中心である。DORA Five Keys、Flow Framework、DevEx 3軸、項目経過日数 + エイジング・チャート + SLE + モンテカルロ予測、SLI + SLO + エラーバジェットがこの系統。
複数デリバリーや、デリバリーケイデンスと開発ライフサイクルが組み合わせとして例外的な配置（適応型 + スコープ固定 + 複数デリバリーなど）の場合は、どちらの系統だけでも足りない。両系統から必要なものを選び合わせる設計判断が要る。
目的でステアリングと改善測定を分ける
ステアリング（進行中の作業の軌道修正）と改善測定（改善努力の効果測定）では使い方が変わる。
ステアリング用は観測対象別に組み合わせを選ぶ。
table:table
観測対象 推奨メトリクス
フロー全体の停滞 スループット + CFD + サイクルタイム
個別項目の停滞 項目経過日数 + エイジング・チャート + SLE
リリース予測 モンテカルロ予測（過去スループット分布から確率的に出す）
バックログ並べ替え WSJF / CD3
イテレーション内の進捗確認 バーンダウンチャート（チーム内で使う。ベロシティをチーム外に共有しない）
SAFe組織のPI達成 PI予測可能性指標
検収判定 ゾーン分析 + 信頼度成長曲線
信頼性 SLI + SLO + エラーバジェット消費速度
観測対象で具体メトリクスを選ぶ
table:table
観測対象 推奨メトリクス
組織のデリバリー能力比較 DORA Five Keys（ふりかえりで議論し改善アクションを決める）
バリューストリーム単位 Flow Framework 5メトリクス（Flow Distribution で投資配分を見る）
開発者体験 DevEx 3軸（構造指標 + アンケート併用）
コードレビュー効率 PRサイクルタイム + レビュー待ち時間
上流品質 DRE（不具合除去効率）
AI導入の影響 DORA手戻り率 + AI起因変更失敗率 + 認知負荷
AI提案受理率を単独で目標化しない、DORAをダッシュボードで監視しない、SLOを内部メトリクスで作らない、というのが各々の運用原則。コーディングエージェントが自律ループを回す場合に必要なセンサー群（型整合性、リンタ、SAST、テスト、ミューテーション、シークレット混入検知など）は、本質的には人間がコーディング中に使う即時フィードバック層と同じもので、観測者の違いで別軸を立てる話ではない。詳細は前段の「コーディングエージェント向けセンサー」節を参照。
