炎上プロジェクトの課題を短期間で収束させる優先順位づけ——「全部やる」という幻想を捨て、”収束の順番”を設計するPMの実践技法

炎上プロジェクトに放り込まれたPMが最初に直面するのは、「課題が多すぎて何から手をつければいいかわからない」という状態だ。課題リストは50件を超え、担当者は疲弊し、ステークホルダーは怒鳴り込んでくる。このとき「全部に対応しよう」とすることが、実は収束をもっとも遠ざける。この記事では、炎上プロジェクトに特有の課題構造を読み解き、短期間で状況を収束させるための優先順位づけの技法を、具体的なシナリオと数字を交えて解説する。

＜目次＞

炎上プロジェクトの課題は「量の問題」ではなく「構造の問題」だ
1. 課題が増殖する本当のメカニズム
2. 「課題の構造マップ」を30分で描く
「緊急×影響×解決可能性」の3軸で優先順位を決める
収束フェーズを「3つのステージ」に分けてスピードをコントロールする
まとめ：炎上収束の優先順位づけで押さえるべきポイント
よくある質問

炎上プロジェクトの課題は「量の問題」ではなく「構造の問題」だ

課題が増殖する本当のメカニズム

多くのPMは、炎上プロジェクトを「課題が多すぎる状態」と認識する。しかし本質はそこにない。炎上プロジェクトで課題が雪だるま式に増える理由は、「根本課題が放置されたまま、派生課題だけが表面に現れ続けている」からだ。

たとえば、ある基幹システム刷新プロジェクトでは、課題リストが60件を超えた。しかし詳細を分析すると、そのうち38件は「設計仕様の解釈がチームによってバラバラ」という1つの根本課題から派生していた。その根本課題を放置したまま派生課題を1件ずつ潰しても、翌週にはまた新しい課題が5件生まれる。「モグラ叩き」状態だ。

PMP知識体系（PMBOK）では課題管理を「プロジェクト遂行中に発生した問題を識別・追跡・解決する」プロセスとして定義するが、炎上状態においてはこの「識別」の段階に特別な注意が必要になる。単に課題を拾い上げるだけでなく、課題間の因果関係を構造的に把握することが収束への第一歩となる。

「課題の構造マップ」を30分で描く

炎上プロジェクトにアサインされたら、まず最初の2時間で課題リストを俯瞰し、「原因—派生」の関係を簡単な図（課題の構造マップ）として描くことを勧める。ホワイトボードでもポストイットでもいい。

やり方はシンプルだ。①既存の課題リストを全部並べる、②「この課題はなぜ起きたか？」と問いかけ、同じ原因に行き着く課題をグルーピングする、③グループの中心にある「根本課題」を特定する、以上だ。30分もあれば60件の課題が「5〜8個の根本課題クラスター」に収まることが多い。

この作業をすることで、「60件を全部対応する」ではなく「5つの根本課題を潰すことで30件以上を自然に解消できる」という見通しが生まれる。これが炎上収束の出発点だ。

「緊急×影響×解決可能性」の3軸で優先順位を決める

従来の2×2マトリクスが炎上状態では機能しない理由

よく知られる「緊急度×重要度」の2×2マトリクス（アイゼンハワーマトリクス）は、通常業務の優先順位づけには有効だ。しかし炎上プロジェクトでは機能しにくい。なぜか。炎上状態では「全部が緊急で全部が重要」になるからだ。マトリクスに課題を並べてみると、ほぼすべてが「緊急かつ重要」の第一象限に集まってしまい、差がつかない。

ある製造業のERP導入プロジェクトで、PMが2×2マトリクスを使って優先順位づけを試みたが、50件中43件が第一象限に入ってしまい「結局全部やらなければいけない」という結論になった。これでは何も変わらない。

3軸評価モデルの実践的な使い方

炎上状態では、以下の3軸で各課題を5段階評価することを勧める。

①プロジェクト継続への影響度（Impact）：この課題を放置すると、納期・予算・品質・ステークホルダーとの関係に対してどれほどのダメージがあるか
②解決の緊急性（Urgency）：今週対応しなければ手遅れになるか、来週でも間に合うか
③自分たちの解決可能性（Feasibility）：現在のリソース・権限・技術で、短期間に解決できるか

この3軸のスコアを合算または加重平均して優先順位をつける。ポイントは「③解決可能性」を必ず加えることだ。影響度が高くても解決可能性が低い課題（例：ベンダーの体制問題で自社側ではコントロールできない）を最優先にしても、リソースを消耗するだけで状況は改善しない。

特に有効なのは「Impact高×Urgency中×Feasibility高」のゾーンだ。これは「今すぐ手をつければ比較的短期間で大きな改善が得られる」課題群を指す。炎上収束の初期フェーズでは、このゾーンの課題を集中的に潰すことで「プロジェクトが動き始めた」という体感をチームとステークホルダーに与えることができる。これが次のアクションへの推進力になる。

「今週中に閉じる課題」を明示的に宣言する

優先順位づけを終えたら、「今週中に必ず解決する課題」を3〜5件に絞り込み、チーム全員と関係するステークホルダーに宣言する。これが重要だ。

宣言することには2つの効果がある。一つは担当者への集中のシグナルになること、もう一つはステークホルダーに「PMが状況をコントロールしている」という安心感を与えることだ。炎上プロジェクトでは、信頼の回復もPMの重要な仕事である。「今週はこの3件を確実に解決します」という宣言が守られたとき、プロジェクト全体の雰囲気が変わり始める。

なお、課題のエスカレーションが必要な場面では、単に「判断を委ねる」のではなく意思決定の場を設計することが求められる。この点についてはエスカレーションすべき課題の見極め方と上司への伝え方——「判断を委ねる」のではなく「意思決定の場を設計する」PMの実践技法も参考にしてほしい。

収束フェーズを「3つのステージ」に分けてスピードをコントロールする

ステージ1：止血（最初の1週間）

炎上収束における最初のゴールは「解決」ではなく「悪化を止めること」だ。医療でいえば止血だ。この段階では、以下の基準で課題を仕分ける。

放置すると来週さらに課題が増えるか？ → 最優先で対処
ステークホルダーの信頼をこれ以上損なうか？ → 最優先で対処
それ以外 → 一旦「今週は手をつけない」と明示的に決める

「手をつけない課題を明示的に決める」という行為が重要だ。「やらない」と決めることで、限られたリソースを最重要課題に集中できる。あるSIerのプロジェクトでは、課題リスト60件のうち15件を「今週対処する」、30件を「2〜3週間後に着手」、15件を「現時点では対処不要（派生課題のため根本解決で消える見込み）」に分類した。この仕分けにより、チームの集中力が劇的に上がり、1週間で8件の課題がクローズした。

ステージ2：構造改善（2〜3週間目）

止血が済んだら、根本課題の解決に着手する。ここでのポイントは、「課題を個別に潰す」から「仕組みを変える」へ視点をシフトすることだ。

たとえば「テスト結果の報告が遅れる」という課題が毎週発生しているなら、その都度担当者に催促するのではなく、報告のタイミングと様式を標準化し、自動リマインドを設定するほうが根本的だ。炎上プロジェクトでは「課題を解決する」よりも「課題が生まれにくい構造に変える」ことに投資する段階を意識的に作ることが、長期的な収束につながる。

また、課題管理台帳の運用が形骸化していることが多い。台帳を「生きた仕組み」に変える運用については、課題管理台帳が形骸化する理由と「生きた台帳」の運用術——「更新される仕組み」を設計することで、台帳はプロジェクトの神経系になるを参照してほしい。

ステージ3：定常管理への移行（4週間目以降）

構造改善が進み始めたら、課題管理を「炎上対応モード」から「定常管理モード」に切り替えるタイミングを見極める。具体的には、週次で新規発生する課題件数が減少傾向に転じたときがサインだ。このタイミングで課題レビューの頻度を「毎日」から「週2回」「週1回」と段階的に減らし、チームが自律的に課題を管理できる状態に移行させていく。

炎上収束後の定常管理においては、週次の課題レビュー会議をどう運営するかが重要になる。会議が形骸化せず課題消化エンジンとして機能するための設計については、「週次会議が課題の”墓場”になっていないか」——会議を課題消化エンジンに変える運営ルール設計の実践技法を参照してほしい。