「このプロジェクト、明日から見てもらえますか」

渡された資料を開くと、納期は2ヶ月遅延、予算は1.4倍超過、バグは未解決が200件。前任のPMは体調を崩して離脱。クライアントは怒っており、経営層は説明を求めている。

炎上プロジェクトのレスキューは、通常のプロジェクト管理とはまったく別の技術だ。平時の最適解が、危機では最悪手になる。丁寧に情報を集めていては手遅れになり、すぐ謝れば信頼をさらに失い、言われた通りコストを削れば品質が崩壊する。

本稿では、炎上と危機の局面でPMが取るべき判断を、行動経済学・認知科学・危機管理の実践知・AI活用の4軸で解体する。感情と政治とサンクコストに支配される状況で、それでも構造的に判断するための具体策を提示する。

危機㉛ 炎上プロジェクトの「レスキュー」初動――最初の72時間で何を捨てるか

なぜ初動を誤るのか：「情報を集めきってから動きたい」という罠

炎上プロジェクトに投入されたPMが最初に陥る失敗は、「全体を正確に把握してから対策を立てる」という、平時なら正しいアプローチだ。しかし炎上中のプロジェクトは毎日悪化している。3週間かけて完璧な現状分析を終えたときには、状況はさらに深刻になっている。

認知科学的には「分析麻痺（Analysis Paralysis）」だ。不確実性が高く責任が重い状況で、人間は「もっと情報が必要だ」と感じ、意思決定を先延ばしにする。しかも情報収集は「仕事をしている感覚」を与えるため、先延ばしの罪悪感も薄い。危機の初動で必要なのは網羅的な理解ではなく、「止血できる場所の特定」だけだ。

具体的な実践策

【「資料より人」から始める】
炎上プロジェクトのドキュメントは、たいてい実態と乖離している。更新が止まり、都合の悪い情報が省かれている。最速で実態を掴む方法は、現場メンバー全員に15分ずつ「今、一番まずいと思っていることは何ですか」と聞くことだ。全員が同じことを3回言ったら、それが真の問題だ。資料の読み込みは後でいい。

【「追加凍結宣言」を最初の24時間で出す】
炎上プロジェクトは、燃えているのに追加要望が入り続けていることが多い。着任初日に「現状把握と再計画のため、〇日まで新規の要望受付を一時停止します」と全ステークホルダーに宣言する。これは交渉ではなく通告だ。流入を止めなければ、どんな対策も無効化される。

【AIによる「大量情報の高速サーベイ」】
議事録・課題管理表・チャットログ・進捗報告をまとめてAIに投入し、「これらの資料から、①繰り返し言及されている未解決の問題 ②意思決定が保留されたまま放置されている論点 ③関係者間で認識が食い違っている箇所 を抽出してください」とプロンプトを投げる。人間が3日かけて読む量を数分で構造化できる。初動の速度が決定的に変わる領域だ。

危機㉜ 「謝る」タイミングと「対策を示す」順序――早すぎる謝罪は信頼を下げる

なぜ起きるのか：「謝罪の誤配」と「回復への期待」

問題が起きたとき、多くのPMは反射的に謝罪する。誠実な態度に見えるが、対策のない謝罪は信頼を回復しない。むしろ下げることがある。

危機コミュニケーションの研究が示すのは、相手が求めているのは謝罪そのものではなく「この人は状況をコントロールできているか」という確信だという点だ。「申し訳ありません、原因を調査中です」だけを繰り返すと、相手には「この人は何も分かっていない」と伝わる。行動経済学の「コントロール感の欲求」から見れば、不安の源は「損失」ではなく「予測不能性」だ。予測可能性を提供しない謝罪は、不安を増幅させる。

一方で謝罪を遅らせすぎるのも致命的だ。責任回避と受け取られ、感情的な対立に発展する。順序が鍵になる。

具体的な実践策

【「事実・影響・対策・謝罪・次回報告」の5点順序を固定する】
悪い報告の型を事前に決めておく。危機の最中に構成を考える余裕はないため、テンプレート化しておくことが唯一の防衛策だ。特に重要なのは最後の「次回報告の日時明示」だ。「進捗があればご連絡します」ではなく「明日17時に必ず報告します」と約束することで、相手の予測不能性が下がり、不安が管理可能なものになる。

【「悪い報告の初回」を最速で出す】
悪いニュースは、時間が経つほど「なぜ早く言わなかった」という第二の問題を生む。情報が不完全でも「現時点で分かっていること・分かっていないこと・いつまでに調べるか」を早期に共有する。完全な情報を待つより、不完全でも早いほうが信頼を守る。

【AIによる「報告文の受け取り方シミュレーション」】
危機報告のドラフトをAIに貼り付け、「あなたは怒っているクライアントの担当者です。この報告を読んでどう感じるか、不安が残る箇所・不誠実に感じる箇所・説明が不足している箇所を率直に指摘してください」とプロンプトを投げる。感情的になっている自分では気づけない「相手の受け取り方」を、送信前に検証できる。危機の局面で最も価値の高いAI活用の一つだ。

危機㉝ 予算削減時の「スコープ交渉」技術――削るのはコストではなく範囲

なぜ起きるのか：「品質を犠牲にする」という最悪の逃げ道

「予算を20%削ってくれ」と言われたとき、最も安易な対応は「品質を落とす」ことだ。テストを削り、レビューを省き、ドキュメントを書かない。これは短期的には予算に収まるが、後の障害対応・手戻り・信頼喪失で数倍のコストになって返ってくる。

プロジェクト管理の古典的な「鉄の三角形（スコープ・コスト・時間）」では、品質は3要素のバランスの結果として現れる。コストを削るなら、スコープか時間のどちらかを調整しなければならない。しかし多くのPMは「スコープを削る交渉」を避ける。「機能を減らしてください」と言うのは、相手の期待を裏切る行為に感じられるからだ。行動経済学の「損失回避」により、クライアントは機能を減らされることを強い損失と感じ、PMもそれを言い出すことを避ける。結果、誰も口にしないまま品質という「見えない部分」が削られる。

具体的な実践策

【「機能の価値ランキング」を先に作らせる】
「どの機能を削りますか」と聞くと相手は答えられない。代わりに「この30機能を、御社のビジネス価値の順に並べてください」と依頼する。ランキングができた時点で、下位から削る議論は自然に成立する。削除の意思決定を「損失」ではなく「優先順位づけ」というフレームに変換するリフレーミング技術だ。

【「フェーズ分割」で削除を延期に変える】
「この機能はやめましょう」ではなく「この機能はフェーズ2に回しましょう」と提案する。相手にとって「削除」は損失だが「延期」は許容しやすい。実質的な内容は同じでも、心理的な受容度がまったく違う。行動経済学のフレーミング効果を、健全な合意形成に使う。

【AIによる「スコープ削減シナリオ」の複数案生成】
機能一覧・見積もり工数・ビジネス価値の情報をAIに入力し、「予算を20%削減するためのスコープ削減案を3パターン作成してください。それぞれについて削る機能・残す機能・ビジネスインパクト・リスクを整理してください」とプロンプトを投げる。単一案を持っていくと交渉が「Yes/No」になるが、3案あれば「どれを選ぶか」の議論になる。交渉の構造そのものを変えられる。

危機㉞ チームの緊急離脱――48時間以内に判断すべきこと

なぜ混乱するのか：「代替の幻想」と「情報の同時消失」

主要メンバーが突然の退職・病欠で離脱したとき、PMが最初に考えるのは「代わりの人を探す」ことだ。しかしブルックスの法則が示す通り、新メンバーの投入は短期的にはむしろ生産性を下げる。緊急離脱の局面で最も重要なのは「人の補充」ではなく「離脱者が持っていた情報とタスクの回収」だ。

離脱で失われるのは労働力だけではない。進行中のタスクの状態、口頭で受けていた依頼、外部との調整の経緯、コードの意図、「あの件はあの人に聞けば分かる」という暗黙の依存。これらが同時に消失することが本当の危機だ。しかも本人が体調不良や心情的な理由で離脱した場合、詳細な引き継ぎは期待できない。

具体的な実践策

【人員追加より「スコープ削減」を先に検討する】
1人抜けたら1人足す、という反射を止める。まず「この納期でスコープを削れないか」「納期を延ばせないか」を検討し、それでも不足する場合に限って人員追加を考える。ブルックスの法則により、危機の最中の人員追加は既存メンバーの教育負荷を増やし、短期的には状況を悪化させる可能性が高い。

【離脱者を「責めない」情報回収の依頼】
体調不良や不満での離脱の場合、責める姿勢は情報回収を不可能にする。「これまでありがとうございました。引き継ぎのため、進行中の作業だけ30分教えていただけませんか」と、感謝と限定的な依頼にとどめる。感情的な対立を作ると、本人の頭の中にある最後の情報も失われる。

【AIによる「離脱者の作業痕跡の再構成」】
離脱者のコミット履歴・チケットのコメント・Slackの発言・ドキュメントの編集履歴をAIに投入し、「この人物が直近1ヶ月で取り組んでいた作業内容、未完了と思われる項目、他メンバーが把握していない可能性の高い依存関係を推定してまとめてください」とプロンプトを投げる。本人からの引き継ぎが得られない場合の、最も現実的な情報復元手段になる。

危機㉟ 「もう終わりにしよう」の判断基準――撤退はサンクコストとの戦い

なぜ判断できないのか：「サンクコスト効果」と「撤退のスティグマ」

続けても損失が拡大するだけのプロジェクトを、それでも止められない。理由は明白だ。「これまで投じた費用と労力が無駄になる」という感覚――行動経済学の「サンクコスト効果（Sunk Cost Fallacy）」だ。しかし経済合理性から言えば、すでに支払ったコストは今後の判断に影響させるべきではない。判断すべきは「今から先の投資と、今から先のリターン」だけだ。

さらに組織的には「撤退のスティグマ（失敗の烙印）」が働く。撤退を提案した人が「諦めた人」として評価を下げるリスクを負う構造では、誰も言い出せない。結果、全員が破綻を予感しながら進み続ける。

具体的な実践策

【プロジェクト開始時に「撤退条件」を事前合意する】
「予算超過が50%を超えた場合」「主要な前提（市場・法規制・技術）が崩れた場合」「〇月末までにマイルストーンXが未達の場合」――こうした撤退検討のトリガーを、プロジェクト開始時にスポンサーと合意し文書化する。危機の渦中では感情と政治が判断を歪めるため、冷静な時点で判断ルールを決めておくことが唯一の防衛策だ。

【「撤退の提案」を評価する文化を作る】
撤退を提案した人が不利になる構造では、誰も言い出さない。「早期に撤退を提案して損失を最小化した判断」を、成功事例として明示的に評価する。Amazonなどが実践する「失敗を早く止めることを称賛する」文化設計だ。撤退は敗北ではなく、リソースの再配分という積極的な経営判断だと位置付ける。

【AIによる「感情を除いた撤退分析」】
プロジェクトの現状・残投資見込み・想定リターン・代替の選択肢をAIに入力し、「サンクコストを完全に除外した上で、このプロジェクトを継続する場合と撤退する場合、縮小着地する場合の3シナリオを比較分析してください。それぞれの経済的な期待値とリスクを整理してください」とプロンプトを投げる。当事者は必ずサンクコストに引きずられるため、感情を持たないAIの分析が「言いにくい結論」を提示してくれる。判断の最終責任は人間が負うが、選択肢の客観的な整理においてAIは極めて有用だ。

危機対応に共通する原則――「平時に決めたルール」だけが危機で機能する

5つの危機に共通する構造がある。危機の最中に、人間は正しい判断ができないということだ。

炎上中は分析麻痺に陥り、批判されると反射的に謝罪し、コスト削減を求められると言いにくいスコープ交渉を避け、人が抜けると反射的に補充を考え、失敗が明らかでもサンクコストで止められない。これらはすべて、プレッシャー下で認知能力が低下し、短期的な心理的安全を選ぶという人間の設計だ。意志の強さでは克服できない。

だからこそ危機対応の本質は、「平時にルールを決めておくこと」にある。72時間ロードマップ、報告の5点順序、機能の価値ランキング、48時間チェックリスト、撤退条件（Kill Switch）――これらは危機の最中に考案するものではなく、冷静なときに用意しておく武器だ。

そしてAIは、危機の局面で最も価値を発揮する道具になる。大量情報の高速サーベイ、報告文の受け取り方シミュレーション、スコープ削減の複数案生成、離脱者の作業痕跡の再構成、サンクコストを排した撤退分析。人間の判断力が最も落ちる局面で、AIの判断力は落ちない。この非対称性を、危機管理の設計に組み込むべきだ。

まとめ：危機対応の5つの局面と打ち手

今日から一つだけ始めるとすれば、現在進行中のプロジェクトに「撤退検討のトリガー条件」を1つ設定することを勧める。「予算超過40%」でも「〇月末のマイルストーン未達」でもいい。平時に決めた一行が、いつか感情と政治に飲まれかけたときのあなたを救う。危機管理の質は、危機が起きる前の準備で決まる。