炎上プロジェクトの立て直し方7ステップ｜PMOコンサルが実践する火消しの手順

「順調です」と聞いていたはずのプロジェクトが、ある日を境に「間に合わないかもしれません」に変わる。ベンダーの報告は信じられなくなり、経営からは毎週のように説明を求められ、現場には疲弊と沈黙が広がっていく——この記事を開いたあなたは、いままさにその渦中にいるのだと思います。先に結論を言うと、炎上プロジェクトは、正しい順番で手を打てば立て直せます。逆に、焦って人を追加する、ベンダーを詰める、といった「気持ちのいい一手」から入ると、火は確実に広がる。僕はPMとして50以上のプロジェクトを見てきました。その経験をもとに、発注側の責任者が今日から動ける立て直しの7ステップを解説します。

まず押さえてほしいのは、炎上は突然起きないという事実です。僕の経験では、本格的な炎上の2〜4週間前には必ず兆候が出ています。その代表が、「大丈夫です」「対応中です」という報告の頻度が増えること。これは「大丈夫」なのではなく、状況を把握できていないが、そう答えるしかない状態のサインなんです。

YouTubeでもこのテーマを話したことがあります。

format_quote

プロジェクトでよく「順調です」っていう報告、聞いたことありませんか？ この「順調です」っていう報告が、一番危ない報告なんですよね。

なぜ危ないのか。「順調です」という言葉の裏側で、プロジェクトの状況を映す仕組みそのものが壊れていることが多いからです。業務知識が特定個人の頭の中にしかない属人化。WBSやマスタースケジュールが作りっぱなしでメンテナンスされていない。タスクの完了定義が曖昧で、「終わった」はずの成果物が後から戻ってくる。現場の課題を吸い上げる場がなく、問題がPMにすら届かない。こうして情報の通り道が一つずつ塞がれていき、誰も嘘をついていないのに、誰も本当の状況を知らない状態ができあがる。僕はこれを「透明性の崩壊」と呼んでいます。

format_quote

自分も前に見たことあるんですけれども、「順調です」って報告をPMがしているんですけれども、蓋を開けてみたら問題の兆候はだいぶ前からあって、もうプロジェクトの納期は間に合わないんじゃないかという、支援必須の状況直前だったんですよね。

発注側の立場でも、この構造は同じように使えます。次の表は、僕が危険信号として見ている兆候と、その裏で起きていることの対応表です。

2つ以上当てはまるなら、すでに燃え始めていると判断してください。早い段階で気づけたなら、それはむしろ幸運です。この段階であれば、遅延の予兆を定量的に掴む進捗管理を先に手当てすることで、火消しではなく予防で済ませられる可能性が残っています。

透明性が崩壊していくメカニズムは、動画で9つの阻害要因に分けて詳しく解説しています。動画で詳しく知りたい方は、以下もあわせてご覧ください。

「炎上PJで必ず起きている“透明性崩壊”の正体【プロジェクトマネジメントの教室】」

ここからが本題です。火消しは打ち手の中身と同じくらい、順番が重要です。よくある失敗は、現状把握を飛ばして「人の追加」や「再計画」から入ること。燃えている場所が分からないまま水をまいても、火は消えません。

ステップ1：事実ベースの現状把握——「大丈夫です」を分解する

最初にやるのは、責任追及でも再計画でもなく、事実の棚卸しです。僕が現場で使ってきたのは、「何がどこまで終わっていて、残りは何日で完了する想定ですか」という、「大丈夫」の中身を分解する質問。気合いや見通しではなく、成果物ベースで確認します。どの成果物が完成していて、その「完成」は誰がどう確認したのか。未着手のタスクは何か。課題は何件積み上がっているのか。

このとき、表面的な症状と真因を混同しないことも大切です。現場の全員が「スケジュール遅延」を問題だと思っていても、遅延は症状であって、真因はスコープの定義がクライアントの真の課題とズレていること——遅延は症状にすぎない、というのが僕の持論です（遅延そのものの原因分析やリカバリ手法の詳細は、この記事では踏み込みません）。

現状把握には期限を切ってください。目安は1〜2週間。精緻さより全体像です。ここで1か月かける火消しは、把握している間に状況が悪化します。

ステップ2：犯人探しを封印し、止血する——タスクのトリアージ

火消しの初動で絶対にやってはいけないのが犯人探しです。責任の所在を先に議論し始めると、現場もベンダーも防御に回り、情報が出てこなくなる。つまりステップ1が止まります。プロジェクトの失敗原因は発注側にも受注側にもある、というのが僕の持論で、原因の総括は鎮火後にやればいい。

並行して止血します。全部を守ろうとしないこと。残タスクと要件を「絶対に守るもの」「延ばせるもの」「やめるもの」の3つに仕分けます。判断基準はただ一つ、事業影響です。リリースを守れないと売上・法令・顧客対応のどこにどれだけ響くのか。ここの優先順位づけは発注側にしかできない仕事であり、ベンダーに委ねてはいけない部分です。

ステップ3：ステークホルダーへの開示と期待値のリセット

現状が見えたら、悪い情報こそ先に、定量で開示します。経営やユーザー部門に対して、当初計画がもう成立していないことを認め、期待値をリセットする。ここで「なんとか間に合わせます」と言ってしまうと、数週間後により大きな二次炎上を招きます。開示が遅れるほど、選択肢は減り、信頼の回復コストは膨らむ。痛みは先に取りにいくべきです。

ステップ4：体制と報告ラインの再設計

炎上した現場では、PMがプレイヤー化して障害対応に埋もれていたり、報告ルートが複線化して数字が食い違っていたりします。誰が全体を見るのかを決め直し、報告を一本化する。タスク管理ツール上のカードには完了定義（Definition of Done）を必ず書く——僕がPMをやるチームで必ずルール化していたことです。「作成したら完了」なのか「レビュー指摘の反映まで完了」なのかが揃っていないと、この後の再計画の前提がまた崩れます。

ステップ5：再計画——「立て切る」ことに投資する

止血と体制ができたら、再計画です。世の中ではシステム開発の成功率は3割と言われますが、僕はプロジェクトの成功で一番重要なのは、徹底した計画がきちんとできているかどうか、それだけだと思っています。3億円以下ぐらいの規模なら、計画さえ立て切れれば大コケすることはあんまりない。行き当たりばったりでやらず、やること・やらないことを全部洗い出して計画に落とし切る。計画にはコストがかかりますが、その分だけ品質が上がるんです。

炎上後の再計画で特に注意すべきは、「バッファを積み増しただけの旧計画」を作らないこと。ステップ2で仕分けたスコープを前提に、楽観シナリオではなく実績ベースの生産性で引き直します。一度崩れた計画への信頼は、二度目の未達で完全に消えます。

ステップ6：定量指標で進捗を測る運用に切り替える

再計画を作ったら、進捗の測り方を変えます。ここを変えないと、数週間後にまた「順調です」が返ってくるだけです。

format_quote

順調な理由をセットで定量的に説明できていれば「順調です」って報告が返ってきてもいいんですけれども、「順調です」だけとか、「やや遅延してるけどリカバリできます」とか、定量的に報告できていない場合っていうのは、感覚で進捗を判断している状態になってしまっているので非常に危ない。

ガントチャートにイナズマ線を引く、先行・遅延タスクの件数を数える、EVMで出来高を測る。手法は何でも構いません。大事なのは、感覚ベースの報告を「禁止」するのではなく、数字で語れるフォーマットを現場に渡すことです。報告者の誠実さに頼る運用は、炎上現場ではもう機能しません。仕組みで担保します。数字を受け取る側の器も同時に整えたい方は、報告会を「判断の場」に変える進捗会議の再設計もあわせて進めてください。

ステップ7：再発防止——予兆を拾う構造を残す

鎮火して終わりにしないでください。冒頭で書いたとおり、炎上の2〜4週間前には必ず兆候が出ています。それを個人の注意力ではなく、組織のルーチンで拾う構造に変える。「大丈夫です」が増えたら分解する質問をする、定量指標の乖離を週次で見る、完了定義を全タスクに義務づける——今回の火消しで導入した仕組みを、平時の標準として残すことが最大の再発防止策です。あわせて言えば、開発プロジェクトの7割は上流で決まります。次のプロジェクトでは、火消しに払ったコストの一部を計画段階に前倒しで投資してください。

7ステップと並行して、火消しの成否を分けるのがステークホルダー対応です。相手ごとに作法が違います。

経営層には「定量＋選択肢」で報告する

経営が一番困るのは、悪い報告ではなく、判断できない報告です。動画でも話しましたが、透明性を失ったプロジェクトでは支援の要請すらままならなくなります。

format_quote

自分たちの状況をきちんと定量的にも定性的にも言語化できるような透明性を持てていないと、上に「ちょっと整理できてなくて申し訳ないんですけど、なんとなく今うまくいってないと思ってて、なんとなく2人ぐらい追加で欲しいんですよ」みたいな報告になる。これだと上司も非常に判断しづらいから、PM自身もヘルプを外側から受けづらいですよね。

報告には必ず選択肢をつけます。「リソースを追加するのか、スコープを削るのか、納期を動かすのか。それぞれ何を犠牲にするのか」。定量的な現状と選択肢のセットで持っていけば、経営は数十分で判断できます。

ベンダーは「詰める」より「開かせる」

炎上時、発注側は契約や責任論でベンダーを詰めたくなります。気持ちは分かりますが、詰めるほど情報は閉じます。ベンダーが守りに入れば、あなたはますます状況が見えなくなり、透明性の崩壊が加速する。いま必要なのは謝罪ではなく事実です。「責任の整理は後でやる。いまは正確な状況だけ欲しい」と明示的に伝え、悪い数字を出しやすい場を作ってください。同時に、発注側の自己点検も必要です。意思決定の遅れ、要件の揺れ、レビューの滞留——火に薪をくべていたのが自分たちだった、という例は珍しくありません。

現場には「詰める質問」ではなく「分解する質問」

現場のメンバーに「なぜ遅れたのか」と問い詰めても、出てくるのは謝罪と沈黙だけです。ステップ1で紹介した「何がどこまで終わっていて、残りは何日で完了する想定ですか」のように、事実を分解する聞き方に変える。質問の形を変えるだけで、上がってくる情報の質は目に見えて変わります。

最後に、外部の支援を入れるかどうかの判断です。すべての炎上に外部支援が必要とは思いません。ただ、次のチェックリストに複数当てはまるなら、社内だけでの立て直しは厳しい可能性が高い。

• ステップ1の現状把握が、2週間たっても終わらない（事実を洗い出せる人手が社内にない）
• PM・リーダーが経営向けの説明資料づくりに忙殺され、現場の指揮が止まっている
• 発注側とベンダーの相互不信が深く、どちらの報告も額面どおりに受け取れない
• 経営に報告するたびに数字が変わり、社内の信用を失いつつある
• 炎上プロジェクトを立て直した経験者が、社内に一人もいない

外部コストをためらう気持ちは分かります。ただ、問題への事後対処のコストは事前対処の3〜5倍かかるというのが僕の実感で、すでに燃えている状況から見ても同じことが言えます。こじらせてから頼むほど高くつく。第三者を入れる価値は、単なる人手ではなく、利害から独立した目で現状把握とステークホルダー間の翻訳ができることにあります。具体的に頼めるのは、現状の棚卸しの代行、再計画の策定支援、経営報告の定量化、進捗管理の仕組みの導入といったところです。PMO支援で任せられる業務範囲と導入の流れを先に押さえておくと、依頼時のミスマッチを防げます。

一つだけ注意点を。火消しPMOを入れても、スコープの優先順位づけや期待値リセットといった意思決定は発注側にしかできません。丸投げは第二の炎上のもとです。なお、すでにPMOを入れているのに機能していない場合は、支援内容と期待値の再設計というまた別の論点になるため、本記事では扱いません。

• 炎上は突然始まらない。2〜4週間前から「大丈夫です」の増加、数字のない報告、WBSの更新停止といった兆候が出る
• 火消しは順番が命。犯人探しと人の追加から入らず、現状把握→止血→開示→体制再設計→再計画→定量運用→再発防止の順で進める
• 再計画は「立て切る」。やること・やらないことを全部洗い出せば、3億円以下の規模で大コケすることはあまりない
• ステークホルダーには悪い情報ほど先に、定量と選択肢のセットで。ベンダーは詰めるより開かせる
• 現状把握が進まない、相互不信が深い、経験者がいない——この状態なら外部の火消しを入れる方が結果的に安い

炎上の渦中にいると、視野は目の前の障害と怒っている人たちでいっぱいになります。でも、あなたがいま本当に取り戻すべきなのは納期そのものではなく、「自分たちがうまくいっているのかどうかが見える状態」です。それさえ戻れば、打ち手は必ず絞り込めます。

---

燃えているプロジェクトを、これ以上ひとりで抱え込む前に

「ベンダーの『順調です』がもう信じられない」「経営にどう説明すればいいか分からない」「現状把握をやり切る人手も時間もない」——いま炎上の渦中にある方は、こうした状態に心当たりがあるはずです。火消しは初動の数週間で結果が大きく変わるため、迷っている時間そのものがコストになりがちです。

クリエイティブテックスタジオでは、炎上プロジェクトの現状把握から再計画、経営報告の立て直しまでを支援しています。まずは無料相談で状況をお聞かせください。社内で立て直せる見込みがあればその進め方を、他社の支援が適していればその旨も正直にお伝えします。

火消しを含むPMO支援の全体像はPMO支援サービスでも紹介しています。まだ相談段階でなくても、この記事の兆候チェックリストだけは今週のうちに一度、自社のプロジェクトに当ててみてください。