炎上したプロジェクトの立て直し方
「進捗はどうですか」「90％です」。先週も90％、その前も90％。これが3週続いたら、そのプロジェクトは炎上しています。
炎上したプロジェクトを立て直すときに大事なのは、頑張りではなく順番です。順番を間違えると、どれだけ人と時間をつぎ込んでも戻りません。
■ 炎上しているサイン
次のどれかに当てはまったら、通常の進め方では戻らない状態だと考えます。
進捗が「90％」から動かない 残り10％に、実は全体の半分の作業が入っています
課題管理表の件数が増え続けている 閉じる速度より開く速度が速い状態です
会議で誰も悪い話をしなくなる 言っても解決しないと諦められています
残業が常態化し、離任者が出始める もっとも危険なサインです
■ ① 止める
最初にやるのは、新しい作業の受け入れを一時的に止めることです。穴の空いたバケツに水を注ぎ続けても、水位は上がりません。
変更の受付を止める（緊急のものを除く）
走っている作業も、いったん棚卸しする
「まず現状を正確に測らせてください」と、期限を切って宣言する（例：1週間）
止めることは勇気が要ります。しかし、正確な現状が分からないまま打ち手を選んでも、外します。期限を切って宣言すれば、関係者も待てます。
■ ② 測る
炎上しているプロジェクトでは、報告されている進捗と実態がずれています。進捗率を聞いても意味がありません。数えるのは次のものです。
完了したもの（他人が完了と判定できるもの）の数
残っているものの数と、それぞれの残日数
未解決のバグの件数と、重要度の内訳
未着手のテストケースの数
まだ決まっていない仕様の一覧
ここで最も重要なのは、この時点では責任を問わないことです。「どうしてこうなったんだ」と言った瞬間、正確な数字は出てこなくなります。
「怒りません。正確に出してください。そこからでないと手が打てません」。これを本気で伝えます。
■ ③ 絞る
測った結果、間に合わないことが分かります。ここで出す範囲を決め直します。
業務が回る最低限は何かを、業務側と一緒に決める
第1弾と第2弾に割る。落とすものは文書に残す
落とした機能を、稼働後にどう補うか（手作業での代替、時期）も決める
決裁者の承認を取る。PMだけで決めない
「全部やる」という選択肢は、もうありません。範囲を決め直すことが、唯一の現実的な打ち手です。
■ ④ 組み直す
絞った範囲で、計画と体制を作り直します。ポイントは、古い計画に手を入れるのではなく、残作業からゼロで引き直すことです。
古い計画には、すでに達成できない前提が埋め込まれています。それを引きずると、また同じところで詰まります。
体制も見直します。炎上の原因が意思決定の遅さであることは少なくありません。
判断が誰のところで止まっているか
決裁ラインを短くできないか
業務側の窓口が忙しすぎて機能していないなら、代わりの人を立てられないか
■ ⑤ 回す
立て直しの初期だけ、確認の周期を短くします。週次の定例を、日次の短い確認（15分程度）に切り替えます。
目的は監視ではなく、詰まりをその日のうちに解くことです。「何か止まっていませんか」を毎日聞く場を作ります。
同時に、小さな完了を積み上げます。炎上しているチームは「何をやっても終わらない」という感覚になっています。確実に終わるものを1つずつ終わらせ、それを共有します。
回復してきたら、日次を週次に戻します。短い周期を続けると、今度は疲弊します。
■ 人のことを忘れない
炎上プロジェクトでは、チームが疲れています。立て直しと並行して、次のことをやります。
連続した休みを取れるように調整する
「ここまで戻れば通常に戻る」という見通しを示す
責任を問う場を作らない。振り返りは収束してから
離任の申し出には早く対応する（無理に引き止めると、他にも広がります）
■ まとめ
炎上プロジェクトの立て直しは、止める → 測る → 絞る → 組み直す → 回すの順です。
いちばんやってはいけないのは、測らずに「とにかく急げ」と言うことです。正確な現状を出してもらうために、まず責任を問わないと決める。ここが出発点になります。