はじめに
計画通りに進んでいたはずのプロジェクトが、ある日突然「炎上」し始める——スケジュールが目に見えて崩れ、ベンダーからの報告が歯切れ悪くなり、関係者の間に疑心暗鬼が広がる。発注側としてこの状況に直面したとき、何から手をつければよいか分からず、かえって状況を悪化させてしまうケースを何度も見てきました。
SIerで4年半、ITコンサルファームで4年半、要件定義からベンダーマネジメントまで一貫して対応してきた経験から、発注側が炎上の兆候に気づいたときにまず取るべき初動を整理します。
炎上のよくある引き金
炎上の原因は様々ですが、発注側に関係が深いものとして代表的なのは次の2パターンです。
- **要件定義の曖昧さに起因する仕様追加の連鎖**：要件が固まりきらないまま開発フェーズに入り、後から次々と仕様追加が発生して作業量が膨らんでいくパターン
- **外部環境の急変**：感染症の流行や法改正、災害など、プロジェクトの前提条件そのものが途中で崩れるパターン
どちらも「気づいた時点でどう動くか」によって、その後の被害の大きさが大きく変わります。
発注側がまず取るべき4つの初動
①現状を正確に棚卸しする（感情より事実）
炎上の兆候が見えたら、まず「誰が悪いか」ではなく「何がどれだけ遅れていて、何が未決定なのか」を事実ベースで棚卸しします。遅延日数、未決定事項のリスト、顕在化しているリスクを客観的に整理することが、その後のすべての判断の土台になります。感情的な責任追及から入ると、ベンダー側が防御的になり、正確な情報が上がってこなくなります。
②優先順位を決める仕組みを今すぐ作る
実際に私が経験したプロジェクトで、要件定義が曖昧なまま開発フェーズに入ってしまったことで、仕様追加が連続して発生し、作業量が当初の想定から大幅に増加したことがありました。さらに深刻だったのは、どの仕様を優先するかを決める仕組みがそもそも存在しなかったことです。その結果、現場では「何を先にやるべきか」の判断が人によってバラバラになり、混乱が混乱を呼んでプロジェクトは大幅に遅延しました。
この経験から言えるのは、炎上に気づいた時点で最優先すべきは「個々の仕様をどうするか」ではなく、仕様の優先順位やQCDのトレードオフを誰がどう決めるかという意思決定の仕組みを即座に作ることです。変更管理の会議体を週次で設置する、QCDのうち何を最優先するかを発注側として明確に宣言する、といった対応が有効です。仕組みがないまま個別対応を続けると、現場の疲弊と混乱が際限なく広がります。
③ベンダーとの体制・コミュニケーションを立て直す
炎上時は、ベンダー側の体制にも綻びが出ていることが多いです。失敗しないベンダー選定の基準でも触れた通り、提案時の体制と実際の稼働体制にギャップがないかを改めて確認し、必要であれば責任者を交えた定例会議体を再設計します。「誰が」「いつまでに」「何を」報告するかのルールを曖昧にしたままにしておくと、問題の発見が常に後手に回ります。
④不可抗力・外部要因にも備える（迅速な代替手段の構築）
炎上は発注側・ベンダー側どちらかの不手際だけが原因とは限りません。私が担当したプロジェクトでは、プロジェクト推進中に新型コロナウイルスの感染拡大が発生し、現地での開発作業そのものが困難になるという事態に直面したことがあります。このときは、リモートで作業を継続できる仕組みを急いで構築し、顧客への状況説明や環境面の手配に相当苦労しましたが、結果としてQCD（品質・コスト・納期）のすべてを守り切ってプロジェクトを完遂させることができました。
この経験から学んだのは、不可抗力が発生した際ほど、代替手段の構築スピードと、顧客に対する透明性の高い説明が信頼維持とQCD死守の鍵になるということです。問題を隠さず早期に共有し、「今何が起きていて、どう対応しようとしているか」を具体的に伝え続けることが、結果的に関係者の協力を引き出し、被害を最小限に抑えることにつながります。
まとめ
プロジェクトが炎上し始めたときに発注側がまず取るべきなのは、個別の問題を一つずつ潰すことではなく、「事実の棚卸し」「優先順位を決める仕組みづくり」「体制の立て直し」「不確実性への備えと透明なコミュニケーション」という土台を素早く整えることです。土台さえ整えば、個々の課題は意外と早く収束していきます。
より体系的に学びたい方は、IPA（情報処理推進機構）が公開している「ITプロジェクトの『見える化』〜総集編〜」も参考になります。問題プロジェクトの事例分析やPMOを活用した統合的マネジメントについてまとめられています。
執筆者プロフィール：SIerで4年半、ITコンサルファームで4年半、要件定義からベンダーマネジメントまで一貫して対応。基幹システム刷新・DX推進プロジェクトに多数従事。
コメント