フレームワーク活用ガイドひとことで言うと#
プロジェクトの「心拍」を毎週チェックし、異常を早期に検知する仕組み。5〜7つの健康指標を定期的に測定し、「正常（緑）・注意（黄）・危険（赤）」の3段階で評価する。心臓モニターのように、脈が乱れた瞬間にアラートを出す。
押さえておきたい用語#
- ハートビート（Heartbeat）
- プロジェクトの定期的な健康チェックの単位。通常は1週間サイクルで実施する。心拍のように途切れることなく続けるのが原則。
- RAGステータス（Red / Amber / Green）
- 赤・黄・緑の3色で状態を表す信号灯方式。一目で「この指標は大丈夫か」が分かる。
- リードインジケーター（先行指標）
- 問題が起きる前に兆候を示す指標を指す。「バグ件数」（遅行）ではなく「テストカバレッジの推移」（先行）のように、将来の問題を予測する指標。
- エスカレーション閾値
- 指標が赤に転じた時に上位者に報告する基準。事前に合意しておくことで、判断の遅れを防ぐ。
プロジェクト・ハートビートの全体像#
こんな悩みに効く#
- プロジェクトの問題に気づくのがいつも手遅れ
- 「順調です」と報告されていたのに、突然炎上する
- ステークホルダーへの報告に毎回時間がかかる
- チームの疲弊に気づけず、メンバーが離脱する
基本の使い方#
プロジェクトの性質に合わせて、定期的にチェックする指標を選ぶ。多すぎると形骸化するので 7つ以下 に絞る。
| 分類 | 指標の例 |
|---|---|
| スケジュール | マイルストーン遅延日数、スプリントのベロシティ推移 |
| 予算 | 予算消化率 vs 進捗率、追加コスト発生額 |
| スコープ | 要件変更件数（週）、未確定事項の数 |
| 品質 | 未解決バグ数、テストカバレッジ |
| チーム | 平均残業時間、チームの満足度スコア |
各指標に「緑・黄・赤」の閾値を事前に設定する。主観で色分けすると「いつも緑」になりがちなので、数字で基準を決める。
例: スケジュール遅延
- 緑: 遅延0〜2日
- 黄: 遅延3〜4日
- 赤: 遅延5日以上
基準はプロジェクト開始時にステークホルダーと合意しておく。
「心拍」なので、一定間隔で途切れずに実施することが重要。金曜の午後やスプリントレビュー後に 15〜30分 で行う。データ収集は可能な限り自動化し、判定と議論に時間を使う。
ハートビートシートは1枚のスプレッドシートにまとめ、過去の推移がグラフで見えるようにする。
具体例#
従業員18名のSaaSスタートアップ。CTOが「体感で順調だと思っていたのに、リリース2週間前にバグが大量発覚してリリースが1か月延期」を経験。
ハートビートを導入し、毎週金曜に5つの指標を15分でチェック。
| 指標 | 緑 | 黄 | 赤 |
|---|---|---|---|
| スプリント完了率 | 80%以上 | 60〜79% | 60%未満 |
| 未解決バグ数 | 10件以下 | 11〜20件 | 21件以上 |
| テストカバレッジ | 70%以上 | 50〜69% | 50%未満 |
| 残業時間（平均） | 月20h以下 | 21〜35h | 36h以上 |
| 未確定仕様数 | 3件以下 | 4〜7件 | 8件以上 |
導入3か月後、テストカバレッジが黄色に転じた週にすぐ対策を打ち、バグの大量発覚を未然に防げた。リリース延期は 0回 に。CTOは「15分のチェックで1か月の遅延を防げるなら安い投資だ」と振り返る。
従業員400名のSIer。大型受託開発（チーム30名、期間18か月）で、毎週のステークホルダー報告書の作成に PMが4時間 かけていた。しかも報告内容が「テキストの長文」で、経営層からは「結局どうなのかが分からない」と言われていた。
ハートビートのRAGシートに置き換えた。
- 指標: スケジュール・予算・スコープ・品質・リスク・チーム健全性・顧客満足度の7つ
- フォーマット: A4横1枚に7つの指標を色付きで一覧表示、前週比の矢印（↑↓→）付き
- 報告時間: 週次MTGは30分に短縮（以前は60分）
変更後:
- PM の報告書作成時間: 4時間 → 45分
- 経営層の評価: 「これなら一目で分かる。赤だけ説明してくれればいい」
- プロジェクト全体の問題検知から対策着手までの期間: 平均2.5週 → 0.5週
赤の指標が出た際、経営層が即座にリソース追加を承認できるようになった点が最大の効果。
従業員70名の建設会社。現場の安全パトロールは月1回だが、事故やヒヤリハットは突発的に発生する。直近3年で労災事故が 年3件 発生しており、元請けから改善要求を受けていた。
現場ごとに週次ハートビートを導入。
| 指標 | 内容 | 赤の基準 |
|---|---|---|
| ヒヤリハット報告数 | 週あたりの報告件数 | 0件（報告が出ていない = 見えていない） |
| 安全装備着用率 | 抜き打ちチェック結果 | 95%未満 |
| 新規作業員比率 | 当週の新規入場者割合 | 30%以上（不慣れなメンバーが多い） |
| 工程遅延 | 計画との乖離 | 3日以上 |
| 残業時間 | 現場作業員の平均 | 月45h以上 |
ヒヤリハット報告が0件の週を「赤」（見えていない状態）と定義したのがポイント。報告を促す仕組みに変えたことで、ヒヤリハット報告は月 2件 → 11件 に増加。小さな危険を事前に潰せるようになり、導入後2年間の労災事故は 0件 を維持している。
やりがちな失敗パターン#
- 指標が多すぎる — 10個以上の指標を毎週チェックしようとすると、形骸化する。5〜7個に絞り、本当に重要な「生死に関わる指標」だけを監視する。
- RAGの基準を主観にする — 「なんとなく黄色」では意味がない。数字で閾値を事前に決め、誰がやっても同じ色になる客観基準にする。
- 赤を隠す文化 — 赤を出すと「PMの責任」とされる環境では、誰も赤を報告しない。赤は「早く気づけた」という良い兆候であり、むしろ歓迎する文化を作る。
- データ収集に時間をかけすぎる — 指標の収集は可能な限り自動化する。手動でデータを集めるのに1時間かかるなら、仕組みが悪い。
まとめ#
プロジェクト・ハートビートは、5〜7つの定量指標をRAG（赤黄緑）で毎週チェックする仕組み。「体感で順調」を「数字で順調」に置き換えることで、問題の早期発見と迅速な対応が可能になる。成功のポイントは、閾値を数字で事前に決めること、赤を出しやすい文化を作ること、データ収集を自動化すること。15分の週次チェックで数週間の遅延を防げるなら、導入しない理由はない。