中堅の業務システム開発が炎上する5パターン

まず結論：炎上は「外注の質」だけでは説明できない

中堅企業の業務システム開発で止まる案件を見ると、技術力不足だけが原因であることは少ないです。業務オーナーがいない、切替を一気にやる、成功条件が「納品完了」しかない——こうした社内側の設計不足が、ベンダー選定の前後で重なります。

外注の失敗パターンと重なる部分もありますが、本記事は社内プロジェクト側で先に潰せる5型に絞ります。選定前にこの型を点検すると、見積比較の軸が「安い／高い」から外れやすくなります。

• 開発体制・進め方 →
• 外注でよくある失敗5パターン →

炎上する5パターン

商談と引き継ぎで繰り返し見える型です。一つでも当てはまれば、発注書やRFPの前に書き直した方が安全です。

• 業務オーナーの名前（または役割）が言えるか
• 今回やらない帳票・拠点・連携が書いてあるか
• 成功条件が「納品完了」「採択」以外の言葉になっているか
• 現場代表が毎日触る画面を1つ言えるか
• Excel併用を何週間まで許し、止める条件があるか

• 要件が曖昧なときのMVPの切り方 →
• 発注前RFP最小セット →

パターン1・2：オーナー不在と一括切替

オーナー不在は、経営決裁は通っているのに「今回の範囲を最終判断する人」が現場にも情シスにもいない状態です。ベンダーがヒアリングしても、要望が部署ごとに増え、見積の前提が毎週変わります。

一括切替は、痛みの強い帳票も弱い帳票も同時に変える進め方です。中堅では拠点・協力会社・Excelマクロが絡みやすく、同時切替は現場が旧運用に戻りやすいです。痛い一本から通し、次の判断日を先に置く方が安全です。

• 社内稟議用の作り方 →
• Excel業務のシステム化 →

パターン3・4：画面カタログ化と現場後回し

画面カタログ化は、機能一覧がそのまま要件になる状態です。「あるとよい」が全部入り、成功条件が測れなくなります。要件は画面数ではなく、誰が・何を・いつ確定するかで書きます。

現場後回しは、事務所と経営だけで設計し、リリース週に初めて現場が触るパターンです。入力の手間が増えるだけだと、どんなに正しい設計でも使われません。試作の段階から現場代表を入れ、毎日の操作を短く保ちます。

パターン5：検収と併用の終わりがない

「できた」の定義がないと、追加要望が検収のたびに増え、Excel併用が止まりません。検収は機能の有無だけでなく、成功条件に沿った運用が回るかで見ます。

併用期間は必要ですが、終わりの条件（例: 二重入力が週〇件以下、確定がシステム側のみ）を先に書いておきます。無期限の二重管理は、炎上の静かな継続です。

• Excel併用期間の設計 →
• 開発体制・品質管理 →

次の一歩

5型の点検表を一度通し、当てはまらない状態まで社内で埋めてから見積比較に入ると、手戻りが減ります。相談は、完成した要件書がなくても、オーナー・範囲・成功条件の下書きからで構いません。