アイアイシー / IIC
— 「炎上しない構造」を最初から作る —
はじめに
プロジェクトの炎上は珍しい話ではありません。
納期遅延、品質問題、手戻りの連鎖…。
一度崩れ始めると、立て直すのは簡単ではありません。
IICでは、こうした状況を「防ぐべきもの」と考えています。
そのために行っているのは、特別なことではなく、
当たり前のことを、徹底してやるというシンプルな方針です。
① いきなり作らない。まず整理する
多くの炎上プロジェクトは、
「とりあえず作り始める」ことから始まります。
IICでは、まず以下を整理します。
- 業務の現状（As-Is）
- 課題の構造
- 本当に解決すべきポイント
例えば、ある案件ではExcelで業務が回っているように見えても、
実際には属人化や二重管理が発生していました。
こうした状況を整理せずにシステム化すると、
問題をそのままシステムに持ち込むことになります。
② 必要な部分だけを設計する
すべてをシステム化・自動化するのが正解とは限りません。
特に現場業務では、
- 人が判断した方が良い部分
- 柔軟に対応すべき部分
が必ず存在します。
IICでは、
- ITで処理する部分
- 人が介在する部分
を切り分け、現場に無理のない形で設計します。
③ スコープを明確にする
プロジェクトが炎上する大きな原因の一つが、
スコープの膨張です。
IICでは、
- 今回やること
- 今回はやらないこと
を明確に定義します。
特に初期フェーズでは、
「まず出す」ための最小構成に絞ることを重視しています。
④ タスクを細かく分解する
大きな単位のまま進めると、進捗も問題も見えなくなります。
そのため、
- 機能単位
- 画面単位
でタスクを分解し、一つずつ確実に完了させる進め方を取ります。
これにより、
- 進捗が見える
- 問題が早く見つかる
- 手戻りが小さくなる
といった効果が生まれます。
⑤ 早く作って、早く確認する
完成してから確認するのではなく、
途中で確認を入れることを重視しています。
モックや初期実装の段階で方向性を合わせることで、
後半の大きな手戻りを防ぎます。
⑥ 「認識ズレ」を潰す
炎上の原因の多くは、技術ではなく認識のズレです。
IICでは、
- 仕様の言語化
- 完成条件の明確化
- レビュー観点の共有
を通して、関係者間の認識を揃えます。
⑦ 「段取り」に一番時間を使う
開発そのものよりも重要なのが、
始める前の準備です。
IICでは、
- マーケティング戦略
- 要件定義
- モック作成
- 開発運用ルール
といった段階をしっかり踏んだ上で開発に入ります。
この時点で大枠が決まっているため、
開発中に迷うことがほとんどありません。
まとめ
IICで行っていることをまとめると、
- いきなり作らず、まず整理する
- 必要な部分だけ設計する
- スコープを明確にする
- 小さく分解して進める
- 早く確認する
- 認識ズレを防ぐ
- 段取りに時間を使う
といったシンプルな内容です。
特別な手法ではありませんが、
これを徹底することで、
炎上しないプロジェクトは作れると考えています。
プロジェクトでお困りの方は、ぜひ一度ご相談ください。