「このプロジェクト、ちょっと見てくれないか」
ある日、上司からそう言われて途中からアサインされた案件。150人月規模のDBのバージョンアップ対応プロジェクト。蓋を開けてみると、プロジェクト計画はほぼなく、進捗管理も課題管理も機能していない。ベンダーへの丸投げ状態。テストフェーズでは想定外の課題が噴出し、本番移行のリスクが日に日に高まっていました。
いわゆる「炎上プロジェクト」です。
PMをやっていると、こうした状況に直面することは少なくありません。自分が最初から関わっているプロジェクトでも、途中からアサインされる立て直し案件でも、「どうやって対処すればいいのか」は共通の悩みです。
この記事では、実際に炎上案件を立て直した経験をもとに、炎上プロジェクトの対処法と予防策を解説します。
この記事でわかること
- なぜプロジェクトは炎上するのか
- よくある炎上パターン3つ
- 炎上したときにやるべき「立て直しの5STEP」
- 炎上しないためにできること
なぜプロジェクトは炎上するのか
まず押さえておきたいのは、プロジェクトがある日突然炎上することは、ほとんどないという点です。
炎上には、必ず予兆があります。
- 少しずつ遅れていた進捗
- 放置されていた課題
- 「まあ大丈夫だろう」で見逃されたリスク
これらの小さな火種が、じわじわと積み重なった結果として、ある日「もう手に負えない」状態になる。これが炎上のメカニズムです。
つまり、炎上の本質は「小さな問題の放置」にあります。
1週間の遅れが2週間になり、2週間が1ヶ月になる。課題が1つ増え、3つに増え、10個に膨らむ。じわじわですが、確実に効いてくるダメージの蓄積です。
言い換えると、火種の段階で気づき、早めに対処できれば、多くの炎上は防げるということです。
ではなぜ、火種を放置してしまうのか。そこにはいくつかのパターンがあります。
よくある炎上パターン
炎上プロジェクトを何件か経験してきましたが、だいたい次の3パターンに集約されます。
パターン①：要件追加が止まらない
発注側の企画部署から、いつまでも要件の追加・変更が止まらないパターンです。
ベンダーが受けきれなくなり、開発が遅延し始める。でも要件は次々に降ってくる。結果として、スケジュールもコストも当初計画から大幅に乖離してしまいます。
こんな兆候があったら要注意
- 要件定義フェーズが終わったはずなのに、企画部署から「あと一つだけ」が止まらない
- ベンダーが追加対応に追われ、本来のタスクが遅延している
対処： 要件追加の受付をいったん止める。場合によっては、要件定義をやり直す判断も必要です。
予防策： 要件追加のルールを最初に決めておく。また、ウォーターフォールにこだわらず、アジャイル的に早めの曝露をするプロジェクト計画にすることで、変更の影響を小さくできます。
パターン②：品質が悪い
テスト段階でバグが大量に発生する、もしくはUAT（ユーザー受入テスト）で認識のズレが大量に発覚するパターンです。
設計段階での認識合わせが不十分だったり、レビューが形だけだったりすると、テストで一気に問題が噴き出します。
こんな兆候があったら要注意
- テストでのバグ件数が想定を大幅に超えている
- UATで「これは要件と違う」という指摘が多発する
- 設計のレビューを発注側でしていない
対処： スケジュールを延伸する、もしくは人員を追加してテスト・修正のリソースを確保する。
予防策： 設計段階でのレビューを厚くして、品質を作り込む。テスト計画を早期に策定し、テスト観点の認識合わせを先にやっておく。
パターン③：PMが管理していない
そもそもPMがプロジェクト計画を引いていない、各種管理をやっていない、ベンダーに丸投げしている。これが実は一番厄介なパターンです。
計画がないと、「遅れているかどうか」すら判断できません。管理がないと、課題が埋もれていても誰も気づかない。気づいたときには手遅れになっている。
こんな兆候があったら要注意
- 常にオンスケの報告が続いている
- タスク・課題チケットが山積している
- 計画書の類が存在しない
このパターンが特に厄介なのは、PM本人が問題だと思っていないことが多いからです。そして、プロジェクトそのものの土台から立て直しが必要になるため、局所的な対処では追いつかず、立て直しの難易度も上がります。
このパターンが最も厄介な理由
- 遅れやリスクが可視化されていないため、ステークホルダーにも伝わらない
- 立て直しには、プロジェクト管理そのものの再構築が必要になる
- PM本人は問題だと思っていない
対処： PMの交代、もしくはPMOのアサインでプロジェクト管理体制を立て直す。
予防策： プロジェクト計画やWBSをPMOやPOがレビューする。月次等でPO・PMOによる状況確認の場を設ける。
実はこの③が、私が途中からアサインされた案件そのものでした。ここからは、その案件での立て直しの経験をもとに、炎上したときに具体的に何をすればいいのかを解説していきます。
炎上したらやること：立て直しの5STEP
炎上プロジェクトに直面したとき、やるべきことは次の5STEPです。
ケーススタディとして参照する案件
- 規模： 150人月
- 内容： 社内の複数事業部横断で利用しているDBのバージョンアップ対応
- 体制： 基盤チームが主導し、各事業部のIT部門が紐づく構成
- 炎上のきっかけ： テストフェーズで想定外の課題が発生し、当初スケジュールでの本番移行リスクが高い状況に
- 私の役割： PMOとして途中からアサイン。立て直しを担当
STEP1：立ち止まる
炎上していると、プロジェクトの現場は焦ります。「なんとかしなきゃ」「遅れを取り戻さなきゃ」と走り続けたくなる。でも、まず一番大事なのは、立ち止まることです。
プロジェクトそのものを中断する必要はありません。ただ、PMやリーダー層は一度立ち止まって、炎上と正面から向き合う時間を確保することが大事です。
走りながら考えようとすると、目の前のタスクに追われて、真因を見逃します。結果として、モグラ叩きの対処が続き、根本解決に至らない。要は場当たり対応をし続けることになります。
怖いかもしれませんが、数日でも手を止めて炎上に向き合う時間を確保することが、最初の、そして最大の一手です。
STEP2：現状と課題の整理
立ち止まったら、次にやるのは現状の確認です。ここが5STEPの中で最も重要で、最も手間がかかるところです。
何が起こっているかの事実確認をする。感覚や噂ではなく、ファクトベースで現状を把握します。
まず確認する観点は、QCDの3軸です。
| 観点 | 確認すること |
|---|---|
| Q（品質） | テストの進捗と結果、バグの発生状況、品質基準を満たしているか |
| C（コスト） | 予算消化率、追加コストの見込み、リソースの過不足 |
| D（納期） | 各工程の進捗、遅延の規模、クリティカルパスへの影響 |
まずQCDの観点で現状を把握したうえで、「何が問題か」「その中でも、最も影響が大きい課題はどこにあるか」を特定します。
ポイント：表面の課題だけでなく、その下にある真因を探る
顕在化している問題（進捗の遅れ、バグの多発など）はあくまで「症状」です。大事なのは、なぜそれが起きているのかという構造的な原因を特定すること。ここを見誤ると、STEP3以降の対応方針がズレます。
私がアサインされた案件では、このSTEP2が最も大変でした。
プロジェクトに入ってまず確認したいのはプロジェクト計画書。でも、このプロジェクトにはそれがありませんでした。また、テストで問題が起こってるので、テスト計画も確認しようとしたら、それもありませんでした。
表面的にはテストで想定外の課題が見つかったと言っているものの、原因はそこではないと気づきました。
進捗管理も課題管理も機能していない。基盤チームが主導していたものの、そこのプロジェクト管理もずさん。私たちの領域の管理もずさん。全体として、プロジェクト管理そのものが存在しない状態でした。
つまり、「想定外の課題が発生している」や「進捗が遅れている」という表面的な問題の下に、「管理の仕組みそのものがない」という真因があったわけです。
この案件では、立て直しの対象が「特定の課題の解決」ではなく「プロジェクト管理の再構築」だと判断しました。
STEP3：対応方針の検討
課題が特定できたら、次は対応方針を考えます。ここで大事なのは、方針を1つではなく、複数案出すことです。
それぞれの方針について、QCD観点やメリット・デメリットで比較を行います。
この案件では、次の2つの方針を検討しました（今回はメリット・デメリットのみで比較）。
| 方針 | 概要 | メリット | デメリット |
|---|---|---|---|
| A：当初スケジュールで押し切る | 炎上は継続するが、馬力でなんとかする | スケジュール変更なし | 品質リスクが高い。メンバーの疲弊 |
| B：品質重視でリスケする | 追加対応も踏まえてプロジェクト計画を引き直す | 品質を担保できる。管理体制の再構築が可能 | スケジュール延伸。追加コストの発生 |
方針を並べることで、意思決定者がトレードオフを理解したうえで判断できる状態を作ります。
やりがちなNG
- 「なんとかします」と方針なしで走る
- 方針が1案しかなく、比較ができない
- QCDのトレードオフが整理されていない
加えて、判断の軸も併せて提示できると意思決定がスムーズになります。例えば、QCDのどれを重視するのか？などです。判断軸が決まっていれば、その軸に照らし合わせて判断をできます。
先の案件で言うと、判断軸はQ>C・Dでした。なので、品質が最も高くなる案を選択すればよいということになります。
STEP4：決断する
方針が出揃ったら、意思決定を行います。
ここで重要なのは、PMが独断で決めるのではなく、PO（プロジェクトオーナー）などの責任者にジャッジしてもらうことです。
炎上しているプロジェクトは情報が錯綜しがちです。だからこそ、
- 誰が
- いつ
- 何を根拠に
- どの方針を選んだか
を記録に残すことが重要です。曖昧なまま走り出すと、後から「そんなこと聞いてない」が発生します。
私の案件では、方針B（品質重視＋リスケ）を選択しました。その時もPOを交えて意思決定の場を持ち、議事録としてやり取りと結果を残すことで、意思決定の正当性を担保しました。
STEP5：再計画する
意思決定された方針に従って、プロジェクト計画やWBSを再作成します。
やることはシンプルです。
- プロジェクト計画書のアップデート（もしくは新規作成）
- WBSの引き直し
- 体制の見直し（必要に応じて増員やPMO追加）
- ステークホルダーへの共有と合意
「再計画」と言うと大げさに聞こえますが、要はSTEP2で把握した現状とSTEP4で決めた方針をもとに、ゴールまでの道筋を引き直す作業です。
再計画で最低限やること
- スケジュール（マイルストーン）の再設定
- タスクの洗い出しとWBS更新
- リスクの洗い出しと対策の記載
- 体制と役割の再確認
私の案件でも、プロジェクト計画を一から引き直しました。管理体制も再構築し、進捗管理・課題管理の仕組みを整えた。結果として、リスケ後のスケジュールで本番移行を完了させることができました。
炎上しないためにできること
ここまで「炎上したらどうするか」を解説しましたが、できれば炎上させたくないですよね。
先ほどの案件を振り返ると、「最初からこれがあったら炎上しなかったのに」と思うことが3つあります。
① プロジェクト計画を引く
当たり前のことですが、プロジェクト計画がないプロジェクトは炎上しやすいです。
計画があれば、「今どれくらいズレているか」を検知できます。でも計画がないと、そもそもズレていることに気づけません。
先ほどの案件では、プロジェクト計画がなかったことが最大の問題でした。計画がないから管理もできない、管理できないから火種に気づけない。典型的な悪循環です。
まずはフォーマットに沿ってでもいいので、プロジェクト計画を作ること。それだけで、炎上のリスクは大きく下がります。
② リスク管理を行う
リスク管理とは、「炎上のきっかけになりそうなこと」をあらかじめ洗い出し、対策を考えておくことです。
私の案件では、テストフェーズでの影響範囲の想定が甘かったことが炎上のきっかけでした。事前にリスクとして洗い出し、「影響範囲が想定以上だった場合のバッファ」を計画に組み込んでおけば、ダメージは小さく済んだはずです。
リスクをゼロにすることはできません。でも、想定しておくことで、顕在化の確率を下げるとともに、顕在化したときの対処スピードが格段に変わります。
③ こまめな確認と早期の手当
定例会議での状況確認を丁寧に行うこと。これが地味ですが、最も効果的な予防策です。
- 進捗は計画通りか
- 新しい課題は発生していないか
- リスクの予兆はないか
こうした確認をこまめに行い、何か発生したらすぐに手を打つ。「少しの遅れ」を見逃さないことが、炎上を防ぐ最大のポイントです。
まとめ
炎上プロジェクトは、ある日突然発生するものではありません。小さな火種の放置が、やがて手に負えない状態を作り出します。
炎上したら、まず立ち止まる。そして5STEPで立て直す。
- 立ち止まる — 走りながら考えない
- 現状と課題の整理 — QCDの観点でファクトを把握し、真因を特定する
- 対応方針の検討 — 複数案を出し、トレードオフを比較する
- 決断 — 責任者にジャッジさせ、記録を残す
- 再計画 — 方針に基づいてプロジェクト計画を引き直す
そして、炎上しないためにできることは、
- プロジェクト計画を引く
- リスク管理を行う
- こまめな確認と早期の手当
このシンプルな3つです。
プロジェクトマネジメントの本質は、問題を起こさないことではなく、問題に早く気づき、適切に対処できる状態を作ることです。
炎上は怖いですが、正しく立ち止まり、正しく対処すれば、必ず立て直せます。
おまけ：NGパターン
最後に、炎上時にやりがちなNGパターンを3つ紹介します。
NG① 馬力で走り続ける
「遅れているから、もっと頑張ろう」「残業で取り戻そう」
気持ちはわかりますが、立ち止まらずに馬力で走り続けても、構造的な問題は解決しません。むしろ、メンバーが疲弊して判断力が下がり、さらに悪化するリスクがあります。
- 残業・休日出勤で「リカバリー」しようとする
- 立ち止まることを「遅れ」だと感じてしまう
炎上しているときこそ、一度止まる勇気を持ちましょう。
NG② 真因を見ずにモグラ叩き
目の前のバグを直す、目の前のタスクをこなす。それ自体は必要なことですが、表面的な対処だけを繰り返しても、根本原因が残っている限り問題は再発します。
- 「とりあえずこのバグを直そう」の対処が延々と続く
- 課題の構造を整理しないまま、対症療法を繰り返す
STEP2で解説した通り、大事なのは表面の課題の下にある真因を特定することです。ここを特定するためにも立ち止まって考えることが重要です。
NG③ 雰囲気の悪さを放置する
発注側とベンダーの力関係が強すぎて、ベンダーが意見できない。チーム内で情報共有がされない。悪い報告が上がってこない。こういう関係性の悪さにも要注意です。
- ベンダーが「言いたいことを言えない」空気がある
- 悪い報告ほど遅れる、もしくは隠される
こうした雰囲気の悪さは、炎上の予兆を埋もれさせます。コミュニケーションを円滑にし、情報をオープンにすること。悪い報告こそ早く上がる仕組みを作ることが、炎上の予防にも立て直しにも効きます。
関連記事