プロジェクトリカバリー

状況: 従業員600名の物流会社。基幹システム刷新プロジェクト（予算1.5億円、期間9ヶ月）。6ヶ月目の時点で完了率40%（計画では70%のはず）。要件変更が30件以上積み上がり、スコープが当初の1.5倍に膨張。チームの残業が月80時間超、2名が離脱。

アセスメント結果:

リカバリーアクション:

1. 30件の要件変更を精査。Must（12件）とNice-to-have（18件）に分離。Phase 2に18件を延期
2. 残作業を再見積もり → 現実的にはあと5ヶ月必要と判定
3. ボトルネックだったDB設計に経験者を2名追加投入
4. 4ヶ月延長でステークホルダーと合意

結果: 4ヶ月遅延でPhase 1を完了。品質は合格基準をクリア。Phase 2は翌四半期に着手。

スコープの50%増を放置したまま「頑張って間に合わせる」としていたら、品質崩壊とチーム全員の離脱に至っていた可能性が高い。「スコープを切る」決断が最も効いた。

状況: 年商45億円のアパレルEC。サイトリニューアルプロジェクト（予算6,000万円、期間6ヶ月）。リリース1ヶ月前のシステムテストで致命的バグが87件発見。受入テストに入れる状態ではなく、経営層が「本当にリリースできるのか」と不信感。

根本原因分析:

• 要件定義書の曖昧さ（「ユーザーにとって使いやすい」レベルの記述が23箇所）
• バックエンド開発とフロントエンド開発の結合テストを省略していた
• コードレビューが形骸化（レビュー時間が平均5分/PR）

リカバリー計画:

• リリースを6週間延期（繁忙期前の10月リリース→11月中旬に変更）
• 87件のバグをCritical（18件）・Major（32件）・Minor（37件）に分類
• Critical + Major の50件を最優先で修正。Minor 37件は初期リリース後に段階的修正
• 結合テストを追加実施（2週間）
• コードレビューのチェックリストを導入（最低15分/PR）

この取り組みが示すように、「予定通りリリースする」ことよりも「品質を確保してリリースする」ことを選んだ判断が正しかった。6週間の遅延を透明に説明し、週次で進捗を報告し続けたことで、経営層の信頼を回復できた。

状況: 人口25万人の自治体。防災アプリ開発を外部ベンダーに委託（予算3,000万円、期間8ヶ月）。5ヶ月目にベンダーの主要エンジニア2名が退職し、開発が事実上停止。納品予定日まで残り3ヶ月。

アセスメント: ベンダーに残ったメンバーでは技術的にバックエンドのAPI開発が困難。完了率は35%。残作業は当初見積もりの3倍の工数が必要と判明。

リカバリー判断の選択肢:

決断: 選択肢Cを採用。防災情報のプッシュ通知と避難所マップの2機能に絞り、残り3機能はPhase 2に延期。現ベンダーのフロントエンド担当2名は残っていたため、バックエンドのみ別ベンダーにスポット発注。

結果: 2ヶ月遅延でMVPをリリース。台風シーズン前に間に合い、初年度のダウンロード数は目標の85%を達成。

「全機能を揃えてリリース」にこだわらず「最低限の機能を最速でリリース」に切り替えたことが、市民の安全という本来の目的に最も貢献した。リカバリーとは「計画を取り戻す」ことではなく「目的を達成する最善の方法を見つける」ことである。