システム開発が失敗するパターンと、発注側で防げること

炎上したプロジェクトに途中から入る仕事を何度か経験しました。
失敗には共通の型があり、その多くは発注側の対応で軽減できます。

パターン1：要件が決まらないまま実装が始まる

最も多い失敗です。

「とりあえず作り始めてください、詳細は追って」
   ↓
実装が進む
   ↓
「思っていたのと違う」
   ↓
作り直し

防ぐには：実装前に画面イメージを見て確認する工程を入れます。
文書での確認には限界があるため、動く試作を触るのが確実です。

作り直しの費用は、試作を作る費用より遥かに大きくなります。

パターン2：決定できる人が会議にいない

打ち合わせ → 持ち帰り → 社内調整 → 2週間後に回答

これが繰り返されると、開発は待ち時間だらけになります。
待っている間も費用は発生します。

防ぐには：窓口を1人に決め、その人に一定の決定権を持たせます。
決められない事項は「いつまでに誰が決めるか」を先に決めます。

パターン3：関係部署が後から出てくる

開発終盤 →「経理部門から追加要望が出ました」

初期に全部署の要件を聞いていないと、終盤で大きな変更が入ります。

防ぐには：要件定義の段階で、実際に使う部署を全部出席させます。
1回の会議で済むことが、後からだと数十万円の追加になります。

パターン4：テストを発注側がやらない

「完成したので確認してください」と言われ、
実際の業務データで試さないまま検収する。運用開始後に問題が噴出します。

防ぐには：検収時に、実際の業務を通しで試す時間を確保します。
できれば1週間程度、並行運用の期間を設けます。

パターン5：移行を軽く見る

既存システムからのデータ移行は、新規開発と同等の難易度になることがあります。

• データが想定より汚れている（表記ゆれ、欠損、重複）
• 過去分をどこまで移すか決まっていない
• 移行中の業務をどうするか決まっていない

防ぐには：早い段階で実データのサンプルを開発側に渡します。
「移行は後で」にすると、終盤で予定が崩れます。

パターン6：運用体制を決めずにリリース

リリース → 誰が問い合わせを受けるのか決まっていない
        → 誰がマスタを更新するのか決まっていない

防ぐには：開発と並行して、運用の担当と手順を決めます。
これは開発会社では決められない、発注側の仕事です。

発注側で打てる手のまとめ

開発側にも聞いてよいこと

進行中に不安を感じたら、遠慮なく確認して構いません。

• 今どこまで進んでいますか（動くものを見せてください）
• 想定より遅れていませんか
• 今の時点で懸念していることはありますか

進捗を動くもので確認するのが最も確実です。
資料上は100%でも、動かないものは0%です。

まとめ

失敗の多くは技術ではなく、意思決定の遅さと認識のズレから生まれます。
発注側で打てる手は思っているより多く、
特に「早い段階で動くものを触る」ことの効果が最大でした。