アイアイシー / IIC
— 問題は“途中”ではなく“最初”に仕込まれている —
はじめに
「プロジェクトが炎上した」
IT業界ではよく聞く言葉です。
納期遅延、品質問題、コミュニケーション崩壊…。
原因は様々に見えますが、実は多くのケースで共通しています。
結論から言うと、
炎上プロジェクトの原因は、ほぼすべて“初期設計”にあります。
炎上は「途中で起きる」のではない
多くの人は、炎上はプロジェクトの途中で発生すると考えます。
例えば、
- 想定外の不具合が出た
- 仕様変更が多すぎた
- メンバーが足りなかった
こういった“事件”がきっかけに見えます。
しかし実際には、
それらはトリガーであって、原因ではありません。
本当の原因はもっと前、
プロジェクトが始まる前の段階にあります。
よくある炎上の構造
① ゴールが曖昧
「何を作るのか」が明確でないままスタートするケースです。
・完成の定義が人によって違う
・どこまでやれば終わりか分からない
この状態では、後から必ずズレが発生します。
② スコープが無制限に広がる
プロジェクトが進むにつれて、
- 「これもやりたい」
- 「ついでにこれも」
と要求が増えていくパターンです。
問題は、
やらないことが決まっていないことです。
③ タスクが分解されていない
大きな塊のまま作業が進むと、
- 進捗が見えない
- 問題の発見が遅れる
- 手戻りが大きくなる
といった状況になります。
④ 認識が揃っていない
関係者間で、
- 仕様の理解
- 優先順位
- 品質基準
がズレていると、後半で一気に噴き出します。
⑤ 「なんとかなる」で進めてしまう
初期段階で曖昧なまま進めてしまい、
「後で調整しよう」
「やりながら考えよう」
となるパターンです。
これが積み重なると、確実に破綻します。
炎上プロジェクトの共通点
ここまでの内容をまとめると、炎上プロジェクトには共通点があります。
- ゴールが曖昧
- スコープが制御されていない
- タスクが粗い
- 認識が揃っていない
- 段取りが不足している
つまり、
設計が甘いままスタートしている
なぜそれでもスタートしてしまうのか
分かっていても、この状態で始まってしまう理由があります。
- 早く始めたい（スピード優先）
- 詳細を詰める時間がない
- 関係者が多く調整が難しい
しかし、ここを省略すると、
後で何倍ものコストを払うことになります。
炎上を防ぐためにやるべきこと
① ゴールを明確にする
「何ができたら成功か」を具体的に定義することが最優先です。
② スコープを固定する
・やること
・やらないこと
を明確にし、途中で膨らませない設計にします。
③ タスクを細かく分解する
小さな単位で進めることで、
- 進捗が見える
- 問題が早く見つかる
ようになります。
④ 早く確認する
完成を待たず、途中段階で確認を入れることで、 手戻りを最小化できます。
⑤ 「段取り」に時間を使う
開発そのものよりも、
始める前の整理に時間を使うことが重要です。
まとめ
炎上プロジェクトは、偶然起きるものではありません。
ほとんどの場合、
最初の段階で原因が作られています。
逆に言えば、
正しく設計すれば、炎上はかなりの確率で防げる
ということです。
IICでは、この「炎上しないための設計」を重視し、
無理なく成功するプロジェクト推進を支援しています。