診断チェックリスト
Project Health Diagnostic Checklist — for PMO / Project Manager
2026年7月
本チェックリストの使い方
このチェックリストは、プロジェクトマネージャー（PM）およびPMOが、進行中のプロジェクトの「健全性」を体系的に診断するためのツールです。既に炎上しているプロジェクトの緊急評価はもちろん、「何か変だ」と感じた時の早期警戒診断にも活用できます。
| 重要度 | 意味 | 対応指針 |
| H（赤） | このまま放置すると プロジェクト失敗に直結するリスク | 即日対応が必要。 エスカレーションを検討 |
| M（橙） | 放置すると悪化する 中程度のリスク | 1週間以内に 対応計画を策定 |
| L（緑） | 改善できると なお良い項目 | 来月以降の 改善アクションに加える |
| 診断スコアの算出方法 |
|
Step 1：全チェック項目に「□」を入れる（「Yes＝問題あり」の項目にチェック） Step 2：チェックが入った項目の重要度をカウント H：____ 個 M：____ 個 L：____ 個 Step 3：重症度判定（第八章の重症度マトリクスを使用） Step 4：リカバリプランを選択（第九章） Step 5：エスカレーション要否を判定（第十章） ※ このチェックリストは定期的（月次）に再実施し、改善状況を継続モニタリングすること |
第一章：炎上の定義と早期警戒サイン
1.1 プロジェクト炎上とは
「プロジェクト炎上」とは、計画からの逸脱が複合的に発生し、プロジェクトの目標（スコープ・スケジュール・コスト・品質）達成が著しく困難になった状態を指します。炎上は突然発生するのではなく、初期段階から複数の警戒サインが積み重なった結果として顕在化します。PMO/PMが早期に警戒サインを読み取り、手を打てるかどうかがプロジェクトの成否を左右します。
1.2 早期警戒サイン（Red Flags）
| 確認 | 診断項目 | 重要度 |
| □ | スケジュールの遅延が2週間を超えており、回復見通しが立っていない | H |
| □ | プロジェクトマネージャーが課題・リスクを「自分で解決できる」と抱え込んでいる | H |
| □ | ステアリングコミッティへの報告が「緑（順調）」ばかりで課題が共有されていない | H |
| □ | チームの離脱者が相次いでいる（またはキーマンが休職・退職を示唆している） | H |
| □ | スコープの追加要望（スコープクリープ）が制御されていない | H |
| □ | 週次ステータスレポートに「課題なし」が続いているが実態は違う | M |
| □ | 会議の意思決定が後追いになっており、決定事項が実行されていない | M |
| □ | 進捗管理がExcel等の手動管理になっており、実態が不明確 | M |
| □ | チームメンバーが「残業が当たり前」の状態が1ヶ月以上続いている | M |
| □ | 顧客・ステークホルダーから同じ懸念が繰り返し提起されている | M |
| □ | プロジェクト計画書（WBS）が最後に更新されてから1ヶ月以上経過 | L |
| □ | リスク管理台帳が形式的で、実際のリスク状況と乖離している | L |
第二章：スコープ診断
2.1 スコープ定義の明確性
| 確認 | 診断項目 | 重要度 |
| □ | プロジェクトスコープ（何をやる・やらない）が文書化されておらず、関係者間で認識が統一されていない | H |
| □ | スコープに関するステークホルダー間の合意書（スコープ合意書・契約書別紙等）が存在しない | H |
| □ | 「当然入っているはず」という前提でスコープが拡大し続けている（スコープクリープ） | H |
| □ | スコープ変更管理プロセスが存在しない（または機能していない） | H |
| □ | 本番稼働日を固定したままスコープが縮小できず、無理なスケジュールになっている | H |
| □ | スコープの優先順位付け（MoSCoW分析等）がなく、全機能が同等優先で進んでいる | M |
| □ | 追加要件が口頭で承認され、正式な変更手続きを踏んでいない | M |
| □ | スコープ境界（他システムとのIF範囲等）が未確定のまま開発が進んでいる | M |
| □ | スコープ文書はあるが、開発チームと業務チームで解釈が異なる | M |
| □ | フィット&ギャップ分析の結果が古くなっており、設計内容と乖離している | L |
| スコープ診断の着目点 |
|
「スコープは合意されているか？」ではなく「スコープの境界を全員が同じ絵で描けるか？」を問う。 ステークホルダーに「このプロジェクトでやらないことを3つ挙げてください」と聞いてみる。 バラバラな回答が返ってきたら、スコープ合意は成立していない。 |
第三章：スケジュール診断
3.1 計画精度と進捗管理
| 確認 | 診断項目 | 重要度 |
| □ | クリティカルパスが特定されておらず、何を遅らせると本番に影響するか分からない | H |
| □ | バッファ（余裕日程）がゼロで、1日でも遅れると本番日程が変わる計画になっている | H |
| □ | 「作業開始=着手」が慣例になっており、完了の定義（Done Criteria）がない | H |
| □ | マイルストーンの達成基準が曖昧で、「完了した」かどうかの判定が主観的 | H |
| □ | 遅れを取り戻すための具体的なリカバリプランが存在しない | H |
| □ | WBS（作業分解構造）が粒度粗く、週単位の進捗追跡ができない | M |
| □ | 依存関係（前後の作業の順序制約）がWBSに反映されていない | M |
| □ | ベースライン（計画値）が変更されており、当初計画との乖離が不明 | M |
| □ | 外部依存（顧客提供物・承認待ち）の遅延がスケジュールに反映されていない | M |
| □ | テスト・UAT・ユーザー研修のスケジュールが圧縮され続けている | M |
| □ | ガントチャートが月に1回しか更新されていない | L |
| □ | 実績工数の集計が各担当者任せで、PMが把握できていない | L |
第四章：リソース・体制診断
| 確認 | 診断項目 | 重要度 |
| □ | プロジェクトマネージャーが兼務で、プロジェクトに専念できていない | H |
| □ | 業務部門のキーユーザー・プロセスオーナーのコミットメントが得られていない | H |
| □ | ベンダー・SIerの担当者が頻繁に変わり、引継ぎが不十分 | H |
| □ | 要員計画があるが、実際のアサイン状況と大きく乖離している | H |
| □ | スキルセットのギャップ（必要な専門知識を持つ人員の不足）が放置されている | H |
| □ | チームの意思決定に必要なRACIチャート（責任分担表）が存在しない | M |
| □ | 意思決定権者（業務部門の責任者）が会議に参加しておらず、決定が先送りになる | M |
| □ | 複数ベンダーが参画しているが、統括・調整するベンダー間調整役が不在 | M |
| □ | 新規参画メンバーへのオンボーディング（プロジェクト文脈の共有）が不十分 | M |
| □ | 技術的なキーマンが1名だけで、その人が抜けるとプロジェクトが止まる（単一障害点） | M |
| □ | チームのモチベーション・心理的安全性が低下している兆候がある | M |
| □ | 研修・ナレッジトランスファーの計画がない | L |
| □ | 外部委託の管理が不十分で、委託先の進捗が不透明 | L |
第五章：品質・成果物診断
| 確認 | 診断項目 | 重要度 |
| □ | 品質基準（What is 'Done'？）が定義されておらず、成果物の合否判定ができない | H |
| □ | テストが不十分なまま次フェーズに進んでいる（欠陥の積み残し） | H |
| □ | バグ・課題の件数が増加トレンドにあり、解消ペースが追いついていない | H |
| □ | 本番移行判定基準（Go/NoGo基準）が定義されていない | H |
| □ | ユーザー受入テスト（UAT）が未実施または形式的に終わらせようとしている | H |
| □ | 設計書・仕様書が実装（コード・設定）と乖離しており、更新されていない | M |
| □ | レビュープロセスが形式的で、実際には十分なレビューができていない | M |
| □ | 非機能要件（性能・セキュリティ・可用性）の検証がテスト計画に含まれていない | M |
| □ | テストデータが本番データと乖離しており、テスト結果の信頼性が低い | M |
| □ | 成果物の承認プロセスが長く、手戻りが多発している | M |
| □ | 成果物のバージョン管理が不徹底で、最新版がどれか分からない | L |
| □ | ドキュメントの品質基準（記載すべき項目・フォーマット）が統一されていない | L |
第六章：ステークホルダー診断
| 確認 | 診断項目 | 重要度 |
| □ | 経営層・プロジェクトスポンサーがプロジェクトに無関心または過度に楽観的 | H |
| □ | 顧客・エンドユーザーがプロジェクトに参画しておらず、要件確認ができない | H |
| □ | 複数の意思決定者（役員・部門長）の意向が対立しており、方向性が定まらない | H |
| □ | 「プロジェクトを失敗させてはいけない」という忖度で、問題が報告されていない | H |
| □ | PMOへの信頼感が失われており、チームが情報を開示しなくなっている | H |
| □ | 重要な意思決定がステアリングコミッティを通さず現場で決まっている | M |
| □ | コミュニケーション計画が存在しないか、機能していない | M |
| □ | プロジェクト外部（他部門・関連プロジェクト）との調整が不十分 | M |
| □ | 変更要求が業務部門から直接開発チームに流れており、コントロールされていない | M |
| □ | 合意事項の議事録・記録が残っておらず、後から「言った言わない」が発生 | M |
| □ | ステークホルダーマップ（誰が賛成・誰が抵抗）が整理されていない | L |
| □ | アジェンダなしの会議・不要な会議が多く、チームの会議疲れが見られる | L |
第七章：リスク・課題管理診断
| 確認 | 診断項目 | 重要度 |
| □ | リスク管理台帳（Risk Register）が存在しない、または形式的で活用されていない | H |
| □ | 特定されたリスクに対する対応策（回避・軽減・転嫁・受容）が決まっていない | H |
| □ | 重大課題（Issue）がクローズされないまま積み上がっている | H |
| □ | コスト超過のリスクが確認されているが、スポンサーに伝わっていない | H |
| □ | プロジェクト終了後の保守・運用体制が未確定のまま本番稼働が迫っている | H |
| □ | リスクのオーナー（誰が責任を持って対処するか）が決まっていない | M |
| □ | 外部環境の変化（法改正・業界動向・仕入先変更）がリスクとして認識されていない | M |
| □ | 課題の優先順位付けがなく、全課題が「急ぎ」として管理されている | M |
| □ | 「想定外」と言われる問題が頻発し、リスク特定の精度が低い | M |
| □ | リスク・課題のレビュー頻度が低く（月1回以下）、対応が遅れがち | M |
| □ | 過去の類似プロジェクトの失敗事例がリスク洗い出しに活用されていない | L |
| □ | リスク発生時の連絡フロー（エスカレーションパス）が未定義 | L |
第八章：重症度判定マトリクス
8.1 診断スコアの集計
第一章〜第七章のチェックリストでチェックを入れた項目を集計し、以下のマトリクスを用いてプロジェクトの重症度を判定します。
| 重症度レベル | H（赤）チェック数 | M（橙）チェック数 | 判定と推奨対応 |
| 緊急（Critical） | 5個以上 | 制限なし | 即時の緊急ステアリングコミッティ招集 独立したPMO介入または外部支援要請 本番稼働日の延期を真剣に検討 |
| 重篤（Serious） | 3〜4個 | 5個以上 | 週次エグゼクティブレポーティングの導入 リカバリプランの策定（2週間以内） 問題のある担当領域への集中支援 |
| 警戒（Warning） | 1〜2個 | 3〜5個 | 月次ステータスレポートの強化 リスクの集中管理（リスクオーナー明確化） 重点領域の根本原因分析 |
| 軽微（Minor） | 0個 | 1〜2個 | 通常の変更管理プロセスで対応 次回レビュー（月次）での経過確認 L項目の改善アクション計画を作成 |
| 健全（Healthy） | 0個 | 0個 | 良い状態を維持 定期チェックリスト再実施を継続 他プロジェクトへのナレッジ共有を検討 |
8.2 領域別ヒートマップ
チェックリストの7領域それぞれのH件数を以下の表に記入し、弱点領域を視覚化してください。最もH件数が多い領域がリカバリの最優先対象です。
| 診断領域 | H件数（記入欄） | M件数（記入欄） | 優先度評価 |
| 第一章：早期警戒サイン | ____ | ____ | |
| 第二章：スコープ | ____ | ____ | |
| 第三章：スケジュール | ____ | ____ | |
| 第四章：リソース・体制 | ____ | ____ | |
| 第五章：品質・成果物 | ____ | ____ | |
| 第六章：ステークホルダー | ____ | ____ | |
| 第七章：リスク・課題管理 | ____ | ____ | |
| 合計 | ____ | ____ | （第八章で重症度判定） |
第九章：リカバリプラン選択肢
9.1 緊急（Critical）レベルのリカバリオプション
| リカバリオプション | 概要 | 適用条件 | リスク |
| スコープ削減 （フェーズ分割） | 優先度の低い機能を第2フェーズに移し 本番稼働日は守る | スコープに優先順位がついており ステークホルダーが合意できる場合 | 重要機能が漏れると 本番後に問題が発生 |
| 本番稼働日延期 | 現実的なスケジュールに引き直し 十分なテスト期間を確保 | スポンサーが延期を承認できる 業務への影響が許容範囲内 | ビジネス機会損失 経営への説明責任 |
| プロジェクト体制強化 | 外部支援（コンサル・専門家）の投入 PMO機能の強化 | 予算の追加承認が得られる場合 組織内に必要スキルが不足 | 立ち上がりに時間がかかる チームへの影響 |
| 暫定移行 （ビッグバンを回避） | 一部拠点・一部機能のみ先行稼働 段階的に対象拡大 | システムが段階稼働に対応できる レガシー並行稼働が可能な場合 | 二重管理コスト 並行稼働期間の複雑性 |
| プロジェクト中断・再計画 | 現状を整理してゼロベースから計画再策定 根本原因への対処を優先 | スコープ・アーキテクチャに 抜本的問題がある場合 | ステークホルダー信頼の損失 再計画コスト |
9.2 重篤（Serious）レベルへの集中施策
| 30日間リカバリスプリントの進め方 |
|
Week 1：現状把握と優先課題の特定 ・全チームリードとの個別ヒアリング（本音ベース） ・課題・リスク・懸念の全量棚卸し（ブレインストーミング形式） ・ステークホルダーへの現状共有（「実はこうなっています」の正直な報告） Week 2：根本原因分析と対応計画 ・最重要課題（H項目）3〜5件を選んで根本原因分析（5Why） ・課題ごとに「誰が」「いつまでに」「何をする」を決定 ・スコープ・スケジュールの現実的な再計画案を作成 Week 3：ステアリングコミッティへの再計画提案 ・現状の正直な説明（美化しない） ・「このままでは失敗する」というリスクシナリオの提示 ・推奨リカバリプランと代替案の比較提示 ・スポンサーからの明確な意思決定を得る Week 4：リカバリプランの展開・実行開始 ・合意されたリカバリプランをチームに展開 ・週次の進捗・課題確認を強化（毎週ステアリングへ報告） ・改善指標（KPI）を設定してモニタリング開始 |
第十章：エスカレーション判断フレームワーク
10.1 エスカレーションの原則
PMはエスカレーションを「失敗の告白」と捉えがちですが、適切なタイミングでのエスカレーションはPMの重要な責務です。「自分で解決できる」と抱え込むことが炎上を拡大させる最大の要因の一つです。組織はPMが一人で解決できる問題しか起きないプロジェクトしか任せない、ということはありません。
| エスカレーション対象 | エスカレーション先 | タイミング |
| スコープ変更で予算・スケジュールに影響 （例：追加要件でコスト10%超増） | プロジェクトスポンサー ステアリングコミッティ | 発生時・即日 |
| 本番稼働日の変更が必要と判断した場合 | スポンサー・経営層 | 判断した時点・即日 |
| 予算超過が確実になった場合 （例：EVM でCPI < 0.8） | スポンサー・財務責任者 | 予算超過確定前（兆候の段階） |
| 外部ベンダーの重大なデリバリ遅延 （プロジェクトに影響するレベル） | ベンダーのエグゼクティブ 自社調達・法務 | 遅延が確認されてから48時間以内 |
| チームメンバーの重大なコンフリクト （プロジェクトに影響するレベル） | 部門長・HR | 発生時 |
| セキュリティ・コンプライアンスリスク | CISO・法務・コンプライアンス | 発見時・即日 |
| プロジェクトの継続可否に影響する 技術的アーキテクチャ上の問題 | 技術責任者（CTO/EA） スポンサー | 発見時・即日 |
10.2 エスカレーション時の「7つの報告原則」
| PMOが実践すべきエスカレーション報告の7原則 |
|
1. 事実を先に：「何が起きているか」を感情なく事実ベースで伝える NG：「みんな頑張っているのですが…」 OK：「テスト完了件数が計画比40%で、本番日程への影響が発生しています」 2. 影響を定量化：「どれくらい困るか」をスコープ/日数/コストで示す NG：「かなりまずい状況です」 OK：「このままでは本番日程が3ヶ月遅延する可能性があります」 3. 原因を簡潔に：5W1Hで根本原因を一言で OK：「テスト要員の不足（計画4名→実際2名）が主因です」 4. 自分の見解を持つ：PMO/PMとしての推奨案を必ず持っていく NG：「どうすればよいかご判断ください」 OK：「3つの選択肢を用意しました。私はOption Bを推奨します」 5. 意思決定を求める：報告で終わらず「承認いただきたい事項」を明示する OK：「本日この場でOption Bの承認をいただきたいです」 6. 次のアクションを明確に：承認後に誰が何をいつまでにするかを伝える OK：「承認後、明日中に全チームへ展開します」 7. 記録に残す：エスカレーションした事実・意思決定内容を必ず議事録に記録する |
10.3 「言いにくいことを言う」勇気
炎上プロジェクトの事後分析では、「早い段階でPMは問題を認識していたが、言えなかった」という事例が繰り返し登場します。組織の心理的安全性を高めることも重要ですが、PMO/PMとしては「言いにくいことを言える構造」を自ら作ることが求められます。エスカレーション先に定期的な「本音を話せる1on1」を確保すること、問題報告を「失敗」ではなく「リスク管理」として位置付けること、が炎上予防の根本的な処方箋です。
以上