フレームワーク活用ガイドひとことで言うと#
プロジェクトの進捗・品質・コスト・チーム状態を定量的な指標で計測し、「今プロジェクトは健全か？」をデータに基づいて判断するための指標体系。感覚ではなく数字で会話する文化を作る。
押さえておきたい用語#
- KPI（Key Performance Indicator）
- プロジェクトの成功度を測る重要業績評価指標のこと。「何を測るか」の選定がメトリクス設計の核心。
- EVM（Earned Value Management）
- 計画値・実績値・出来高の3つの数値でコストとスケジュールの効率を同時に計測する手法である。CPI（コスト効率指数）やSPI（スケジュール効率指数）を算出する。
- ベロシティ（Velocity）
- スプリントごとにチームが完了したストーリーポイントの合計値を指す。計画精度の基準として使う。
- リードタイム（Lead Time）
- 作業の要求が発生してから完了するまでの全体的な所要時間のこと。プロセスの効率を示す指標。
- しきい値（Threshold）
- メトリクスの「正常」「注意」「危険」を判定する境界値のこと。自動アラートの基準として設定する。
プロジェクトメトリクスの全体像#
こんな悩みに効く#
- プロジェクトの状況を聞かれると「順調です」としか答えられない
- 問題に気づくのがいつも遅く、手遅れになってから対処している
- チームの生産性が上がっているのか下がっているのか分からない
基本の使い方#
プロジェクトの特性に合わせて、4カテゴリから主要指標を選ぶ。
- 進捗: バーンダウン/バーンアップ、完了率、残作業量
- 品質: バグ発生率、バグ修正率、テストカバレッジ
- コスト: 予算消化率、EVM（アーンドバリュー）指標
- チーム: ベロシティ、リードタイム、サイクルタイム
ポイント: 全部計測しようとすると計測コストが膨大になる。各カテゴリ1〜2個、合計5〜8個に絞る。
各メトリクスの「正常」「注意」「危険」の基準を定める。
- 過去のプロジェクトデータがあれば、それを基準にする
- なければ、最初の2〜3スプリントで基準値を確立する
- 「注意」と「危険」の閾値を明確にし、アクションルールを決める
ポイント: 閾値は固定ではなく、プロジェクトの進行に合わせて調整する。
メトリクスを一覧できるダッシュボードを作成し、チームとステークホルダーに共有する。
- 信号機方式（緑・黄・赤）で直感的に状態が分かるようにする
- トレンド（推移グラフ）を必ず含める。スナップショットだけでは不十分
- ツール: Jira、Azure DevOps、Google Sheetsなど
ポイント: ダッシュボードは「見に行く」のではなく「目に入る」場所に置く。
計測して終わりにせず、メトリクスの変化に応じて具体的なアクションを実行する。
- 「黄色」が出たら原因を調査し、次のスプリントで対策を打つ
- 「赤」が出たらエスカレーションし、リカバリー計画を策定する
- レトロスペクティブでメトリクスの推移を振り返り、改善につなげる
ポイント: メトリクスは「報告のため」ではなく「行動のため」に使う。数字を眺めるだけでは意味がない。
具体例#
状況: 8名のスクラムチームで6ヶ月間のWebアプリ開発。2週間スプリント。ステークホルダーへの月次報告が義務。
選定メトリクス（6個）:
| カテゴリ | メトリクス | 現在値 | 基準 | 状態 |
|---|---|---|---|---|
| 進捗 | スプリント完了率 | 85% | ≥80%: 緑 / 60-79%: 黄 / <60%: 赤 | 緑 |
| 進捗 | バーンアップ（計画比） | 計画の95% | ≥90%: 緑 / 75-89%: 黄 / <75%: 赤 | 緑 |
| 品質 | スプリント内バグ発生数 | 12件 | ≤10: 緑 / 11-20: 黄 / >20: 赤 | 黄 |
| 品質 | バグ修正率（発生比） | 90% | ≥85%: 緑 / 70-84%: 黄 / <70%: 赤 | 緑 |
| コスト | 予算消化率（進捗比） | 1.05 | ≤1.1: 緑 / 1.1-1.2: 黄 / >1.2: 赤 | 緑 |
| チーム | ベロシティ（直近3SP平均） | 28pt | ±20%以内: 緑 / ±30%: 黄 / ±30%超: 赤 | 緑 |
アクション: 品質メトリクスが「黄」。バグ発生の傾向を分析し、特定モジュールのコードレビュー強化を次スプリントで実施。結果、翌スプリントのバグ数が8件に改善。
ダッシュボードの「黄色」を即座にアクションに変換できたことで、品質問題が「赤」に悪化する前に対処できた。メトリクスの価値は「早期検知→即行動」にある。
状況: 予算3.5億円、期間18ヶ月のオフィスビル改装プロジェクト。10ヶ月目の中間地点でEVMを用いた健全性チェックを実施。
EVM計測結果（10ヶ月目）:
| EVM指標 | 値 | 意味 |
|---|---|---|
| PV（計画値） | 2.0億円 | 本来ここまで完了しているべき金額 |
| EV（出来高） | 1.7億円 | 実際に完了した作業の価値 |
| AC（実コスト） | 1.9億円 | 実際にかかった費用 |
| SPI（スケジュール効率） | 0.85 | 計画の85%しか進んでいない |
| CPI（コスト効率） | 0.89 | 1円あたり0.89円分の成果 |
| EAC（完了時見積） | 3.93億円 | このペースだと最終的に予算超過 |
アクション: SPI・CPI共に0.9を下回り「赤」判定。PMがステアリングコミッティにエスカレーション。原因分析の結果、下請け業者の施工品質不良による手戻りが主因と判明。対策として下請け変更と検査頻度の強化を決定。
結果: 対策後3ヶ月でSPIが0.92、CPIが0.95に回復。最終的に予算3.6億円（3%超過）、スケジュール1ヶ月遅延で完了。
この取り組みが示すように、EVMがなければ「何となく遅れている」で済まされていたところ、数字で「このままだと4,300万円の超過」と示せたことで、経営層の即断即決を引き出せた。
状況: 東京・福岡・ベトナムの3拠点にまたがる12名のリモート開発チーム。「チームの状態が見えない」という課題を抱え、メトリクス導入を開始。
導入したメトリクス:
- リードタイム（チケット起票→完了）: 平均8.5日→目標5日以内
- サイクルタイム（着手→完了）: 平均4.2日→目標3日以内
- PR（プルリクエスト）のレビュー待ち時間: 平均28時間→目標12時間以内
- チームのNPS（月1回の匿名アンケート）: 現状+15→目標+30
改善サイクル（3ヶ月間）:
| メトリクス | 導入時 | 1ヶ月後 | 3ヶ月後 |
|---|---|---|---|
| リードタイム | 8.5日 | 6.8日 | 4.9日 |
| サイクルタイム | 4.2日 | 3.5日 | 2.8日 |
| PRレビュー待ち | 28時間 | 18時間 | 10時間 |
| チームNPS | +15 | +22 | +35 |
施策: PRレビュー待ちが最大のボトルネックと判明。「PRは24時間以内にレビュー」ルールを導入し、時差のある拠点間で「バトンリレー方式」のレビュー体制を構築。
リモートチームこそメトリクスが効く。「顔が見えない」不安をデータで補い、改善の効果を数字で実感できることがチームの一体感を高めた。
やりがちな失敗パターン#
- メトリクスを多く取りすぎる — 20個の指標を毎週更新するのは現実的でない。重要な5〜8個に絞り、運用負荷を最小化する
- メトリクスで人を評価する — 個人のベロシティやバグ数をランキングすると、チームの心理的安全性が壊れる。メトリクスはチーム単位で使う
- 計測するだけでアクションしない — きれいなダッシュボードを作っても、「赤」を見て何も変えなければ意味がない。メトリクスとアクションを必ずセットにする
- トレンドを見ずにスナップショットで判断する — 1回の数値だけで一喜一憂しない。3〜5スプリントの推移で判断する
まとめ#
プロジェクトメトリクスは、プロジェクトの健全性を「見える化」し、データに基づく意思決定を可能にする。進捗・品質・コスト・チームの4カテゴリから少数の重要指標を選び、閾値を設定し、ダッシュボードで共有し、変化に応じてアクションを取る。計測自体が目的にならないよう、常に「この数字を見て何をするか」を意識する。