プロジェクトレスキュー

英語名 Project Rescue
読み方 プロジェクト レスキュー
難易度
所要時間 診断1〜2週間 + 立て直し1〜3か月
提唱者 IT業界のプロジェクト回復(Project Recovery)手法を体系化
目次

ひとことで言うと
#

スケジュール崩壊・予算超過・品質劣化など破綻寸前のプロジェクトを外部から診断し、立て直すための緊急介入手法。まず「本当に救えるか」を48時間で判断し、救えるなら3段階(止血→再計画→再始動)でリカバリーする。

押さえておきたい用語
#

押さえておきたい用語
トリアージ(Triage)
複数の問題に優先順位をつけ、限られたリソースで最大の効果を出すための分類。医療の救急現場から来た用語で、プロジェクトレスキューでも最初に行う。
止血(Bleeding Stop)
現在進行中の損害をこれ以上広げないための応急処置を指す。根本解決ではなく、出血を止めてから治療に入るというアプローチ。
リベースライン(Re-baseline)
現実に合わなくなった計画を現時点の状況に基づいて再設定すること。元の計画を捨て、新しい基準線から再出発する。
キルデシジョン(Kill Decision)
プロジェクトを中止する判断。レスキュー不可能と診断された場合、損失を最小化するために撤退を決定する。

プロジェクトレスキューの全体像
#

プロジェクトレスキュー:診断→止血→再計画→再始動の4段階
Phase 1: 診断(48時間)何が壊れているかを特定「救えるか」「救うべきか」を判断Go / No-Go の決定Phase 2: 止血(1〜2週間)損害の拡大を止める応急処置スコープ凍結・人員再配置No-Go →プロジェクト中止Phase 3: 再計画(1〜2週間)リベースライン:現実に基づく新計画スコープ・予算・納期の再合意Phase 4: 再始動新計画に基づいて再出発週次ハートビートで再発防止レスキューの成功率を上げる鍵:最初の48時間の診断精度48時間1〜2週間1〜2週間継続
プロジェクトレスキューの実行フロー
1
48時間診断
何が壊れているかを特定し、救えるかを判断する
2
止血
スコープ凍結・不要作業停止で出血を止める
3
再計画
現実に基づいてスコープ・予算・納期を再設定する
4
再始動
新計画で開発を再開し短いサイクルで成果を出す
再発防止
週次チェックと振り返りで同じ失敗を繰り返さない

こんな悩みに効く
#

  • プロジェクトが炎上しているが、何から手をつけていいか分からない
  • 納期が大幅に遅延し、ステークホルダーの信頼を失いかけている
  • チームが疲弊して離脱者が出ている
  • 「もう少し頑張れば間に合う」と言い続けて状況が悪化している

基本の使い方
#

ステップ1:48時間診断を実施する

まず2日間で「何が壊れているか」を特定する。診断で確認すべき項目は以下の5つ。

  1. スケジュール: 元の計画と現実の乖離はどれくらいか
  2. スコープ: 当初の要件から何がどれだけ膨らんだか
  3. チーム: メンバーの稼働状況、離脱リスク、スキルギャップ
  4. 技術: アーキテクチャ上の問題、技術的負債の量
  5. ステークホルダー: 顧客・経営層との関係は修復可能か

診断の結果、救えない場合は中止を勧告する。損切りも立派なレスキュー。

ステップ2:止血する(1〜2週間)

診断結果をもとに、まず損害の拡大を止める。

  • スコープ凍結: 新しい要件追加を一切受け付けない
  • 不要作業の即停止: 「やっても意味がない」作業を特定して止める
  • ブロッカーの解消: チームが進めない原因(承認待ち、環境問題など)を即日で解消
  • チームのケア: 残業禁止期間を設け、疲弊したメンバーの回復を優先

止血フェーズでは「新しく何かを始める」のではなく「止めること」に集中する。

ステップ3:リベースラインで再計画する

元の計画は忘れる。現時点のリソース・スコープ・技術状況に基づいて、新しい計画を立て直す。

  • 必須機能と「あれば嬉しい」機能を分類し、必須だけに絞る
  • 新しい納期を現実的に見積もる(バッファは元の計画の 1.5倍 を見る)
  • 予算の追加が必要なら、具体的な金額と根拠を提示する
  • この再計画をステークホルダーと正式に合意する
ステップ4:短いサイクルで再始動する
新計画に基づいて開発を再開する。再始動後は 1〜2週間の短いサイクル で成果を出し続け、ステークホルダーの信頼を回復する。長期計画を立てて3か月後にデモ、ではなく、毎週何かしら動くものを見せる。

具体例
#

例1:ECリニューアルが炎上し、外部PMが立て直す

年商8億円のアパレルEC企業。自社ECサイトのリニューアルプロジェクト(予算 3,000万円、期間6か月)が、4か月目で進捗 28%。開発チーム(外注)とのコミュニケーション断絶、仕様変更 42件 が積み上がり、リリース見通しが立たない状態。

外部PMを招いてレスキューを実施。

48時間診断の結果:

  • 仕様変更42件のうち、実際にビジネスに必要なのは 14件
  • 開発チームの技術力は問題なし、仕様の確定が遅いのが原因
  • ステークホルダー(EC責任者)が週に2〜3回仕様を変更していた

止血(1週間):

  • 仕様変更を凍結、残り28件を「やらない」と決定
  • EC責任者との週次定例を設置し、仕様変更ルートを1本化

再計画:

  • スコープを必須14件に絞り、リリースを3か月延期(6か月→9か月)
  • 追加予算 500万円 で合意

結果、リニューアルは9か月目に無事リリース。初月のEC売上は前年同月比 +23% を記録。仕様変更の凍結がレスキューの最大の効果だった。

例2:基幹システム刷新で中止判断を下す

従業員600名の卸売業。基幹システムの刷新プロジェクト(予算 1.2億円、期間2年)が1年経過時点で進捗 15%。ベンダーの技術力不足、要件定義の甘さ、社内の抵抗が重なり完全に停滞していた。

外部コンサルタントが48時間診断を実施。

診断項目結果
スケジュール乖離12か月遅延(2年の計画に対し15%しか進んでいない)
予算消化4,800万円消化(予算の40%を使って進捗15%)
ベンダー技術力要件に対してスキルが不足
社内の巻き込み現場キーパーソン3名が非協力的
救済可能性追加 8,000万円 + 1年延長が必要

診断の結論は「中止勧告」。追加8,000万円を投じても成功の見込みが低いと判断。

経営層は中止を決定し、ベンダーとの契約を精算(違約金 1,500万円)。代わりにSaaS型のERPに切り替え、4,000万円・8か月で導入完了。結果として、元の計画より 4,200万円 安く、16か月 早くシステムが稼働した。「中止する勇気」が最良のレスキューになった事例。

例3:自治体のDXプロジェクトを住民対話から立て直す

人口12万人の市。住民向けオンライン手続きシステムの構築プロジェクト(予算 2,800万円、期間1年)が、8か月目で試験運用を開始したところ、住民からの苦情が殺到。「使い方が分からない」「窓口より面倒」という声が 1週間で230件

48時間診断:

  • システム自体に重大なバグはない
  • UIが複雑すぎる(1手続きに画面遷移が平均 11回
  • 住民テストを1回もせずにリリースしていた
  • 職員向けマニュアルも未整備で、窓口で案内できない

止血(2週間):

  • オンライン手続きの一時停止(窓口対応に戻す)
  • 住民5名にUI操作テストを実施し、問題箇所を特定

再計画:

  • 画面遷移を11回→5回に削減するUI再設計(追加予算 350万円
  • 職員向け操作研修を実施
  • 再リリース前に住民30名のテストを義務化

再リリース後、住民の利用率は 8% → 34% に上昇。苦情は月 12件 まで減少し、窓口の混雑も緩和された。「住民テストをやっていなかった」という根本原因の発見が、48時間診断の価値だった。

やりがちな失敗パターン
#

  1. 診断を飛ばしてすぐ「頑張る」 — 原因を特定せずにリソースを追加しても、同じ問題が繰り返される。48時間の診断は省略してはいけない。
  2. 中止という選択肢を排除する — サンクコスト(すでに投じた費用)に引きずられて「ここまでやったから続けよう」と判断すると、損失がさらに膨らむ。中止も立派なレスキュー。
  3. 止血せずに再計画する — 仕様変更が止まらない状態で新しい計画を立てても意味がない。まず出血を止めてから治療に入る。
  4. 元の計画を「修正」しようとする — 破綻した計画をパッチ修正しても機能しない。リベースライン(ゼロからの再計画)が必要。

まとめ
#

プロジェクトレスキューは「診断→止血→再計画→再始動」の4段階で炎上プロジェクトを立て直す手法。最も重要なのは最初の48時間診断で、「何が壊れているか」と「救えるか」を冷静に判断すること。救えない場合は中止する勇気も含めてレスキューの一部。止血フェーズでは「やめること」に集中し、再計画では元の計画を捨てて現実から再出発する。短いサイクルで成果を見せ続けることが、ステークホルダーの信頼回復への最短ルートになる。