システム開発の要件定義が失敗する原因8つ｜発注側ができる対策も解説

システム開発の要件定義が失敗する原因の大半は、技術ではなく発注側と開発側の認識ズレにあります。目的が曖昧なままの丸投げ、「よくある機能」といった曖昧な言葉、際限のない要望追加が典型です。この記事では、見積もりが10倍開いた実例や賠償41億円に至った裁判例を交えて、失敗原因を発注側5つ・開発会社側3つに整理し、発注側が今日からできる防ぎ方を手順で解説します。

要件定義の失敗はなぜシステム開発全体を壊すのか？

要件定義とは「何を、なぜ、どこまで作るか」を発注側と開発側で合意する工程で、ここでの誤りは設計・開発・テストの全工程に増幅されて波及します。要件の漏れや誤解が後の工程で見つかるほど手戻りは大きくなり、リリース直前や運用開始後に発覚した場合は作り直しに近い費用がかかります。失敗の原因分析をプログラミングより前のこの工程に集中させる価値は、ここにあります。

規模の大きい案件では、要件定義の失敗が裁判にまで発展しています。スルガ銀行が勘定系システム開発の頓挫をめぐり日本IBMを訴えた事件では、2013年に東京高裁が約41億7,000万円の賠償を命じ、2015年に最高裁で確定しました。このプロジェクトは要件定義の段階から難航しており、海外製パッケージと日本の銀行業務との適合を十分に検証しないまま進めたことが争点になりました。

文化シヤッターと日本IBMの訴訟でも、2022年に東京地裁が約19億8,000万円の賠償を命じています（控訴審を経て確定）。標準機能を中心に使うはずだった販売管理システムのカスタム開発比率が95%まで膨らみ、結合テストの途中で数百件の欠陥が見つかりました。要件と製品の適合を見誤ったまま走り出すと途中で止まれなくなる、という構図を示す判例です。

発注側に起因する要件定義の失敗原因5つ

発注側の失敗原因に共通する根っこは、「自社の業務を本当に知っているのは自社だけ」という前提の欠落です。開発会社は業務システムの作り方には詳しくても、あなたの会社の商習慣・帳票・例外処理は知りません。専門家に任せておけば大丈夫という丸投げは、要件の漏れに直結します。代表的な原因は次の5つです。

特に危ないのが2つ目の「曖昧な言葉」です。ある案件では、発注者が「よくある会員登録機能」とだけ伝えて要件定義を終えました。発注者の頭にあったのはSNSアカウント連携やSMS認証まで備えた最近のアプリ水準、開発者が想定したのはメールアドレスと住所を登録する昔ながらのフォームです。画面設計の段階で初めてズレが発覚し、見積もり工数は大きく狂いました。双方とも「常識」のつもりだったことが原因で、どちらか一方を責めても解決しません。

決裁者の一声も根が深い原因です。役員同士の付き合いで製品が事実上決まっており、コンペが形だけだったという例は実際にあります。決めた人が業務とシステムの両方に詳しければ機能しますが、そうでない場合は、現場の業務に合わない土台の上で要件定義を始めることになり、後工程の苦労がいくら積み上がっても土台は覆せません。

• 目的が曖昧なまま機能の話から始める（何のためのシステムかを誰も説明できない）
• 「よくある機能」「普通の画面」という曖昧な言葉で仕様を伝える
• 業務フローと例外処理を洗い出さず、ヒアリングを受け身で済ませる
• 現場を巻き込まず、決裁者の一声で製品や仕様を決める
• 開発中の要望追加に歯止めがなく、範囲が膨張する（スコープクリープ）

開発会社側に起因する原因3つと見極め方

原因は発注側だけではありません。裁判例では、開発を主導するベンダーには、リスクを検証し計画を適切に管理する「プロジェクトマネジメント義務」があるとされ、実際に賠償の根拠になっています。発注側がどれだけ準備しても、開発会社側に次の3つの問題があれば要件定義は失敗します。

とりわけ注意したいのがパッケージ適合の見誤りです。パッケージ製品は標準のまま使うから安く速いのであって、カスタマイズを重ねた瞬間にその前提が崩れます。バージョンアップのたびに改修部分の動作検証が必要になり、費用も保守負担も増え続けます。文化シヤッター事件のカスタム比率95%という数字は、その行き着く先を示しています。パッケージを選ぶなら業務側を合わせる覚悟を決める、合わせられないならはじめから個別開発を選ぶ、という二択を要件定義の入口で明確にすべきです。

変更要望を安易に受け入れる開発会社も、短期的には親切に見えて危険です。影響の説明がないまま「対応します」が続く場合、後でまとめて追加請求が来るか、テストや品質が静かに犠牲になっているかのどちらかです。要望を伝えたときに、費用と納期への影響を数字で返してくる会社の方が、長い目で見れば信頼できます。

発注側にできる見極めは、会社の看板ではなく担当者を見ることです。大手だから安心という保証はなく、プロジェクトの成否を左右するのは目の前の担当者の業務理解と経験です。初回の打ち合わせで自社の業務についてどれだけ具体的な質問が出てくるかは、分かりやすい判断材料になります。開発会社の比較軸は関連記事でも詳しく解説しています。

• ヒアリング不足のまま「できます」と請けてしまう
• パッケージやプラットフォームと業務の適合性を検証しない
• 発注側の要望を安易に受け入れ、範囲の膨張を止めない

要件定義が甘いと損害はいくら？見積もりに10倍の差が出た実例

要件定義が固まる前に相見積もりを取ると、各社は足りない情報を自社の経験と想像で補うため、金額は大きくブレます。実際に、要件定義書がない状態で約10社のコンペを行ったところ、見積もりが1,000万円から1億円まで10倍開いた例があります。この状態では、どの金額が妥当かを発注側が判断できず、社内の稟議すら上げられません。安い会社を選んでも、その金額に根拠がない以上、途中で予算が膨らむリスクを抱えたままです。

この案件では、開発と切り離して要件定義だけを専任体制で数か月かけて実施し、詳細な要件定義書を作ってから再度コンペを行いました。結果、各社の見積もりの開きは3倍以内に収まりました。要件定義を経て当初見積もりの3倍に膨らんだ会社もあり、もし最初の安い金額だけを信じて発注していれば、途中で資金が尽きて頓挫していた可能性が高い案件です。

10倍の開きは大型案件の話ですが、構図は数百万円規模の業務システムでも同じです。要件が曖昧なまま始めれば、開発の中盤で「聞いていた業務と違う」という発見が積み重なり、追加費用の交渉と納期延長が発生します。金額の桁が違うだけで、原因をたどれば冒頭に挙げた認識ズレと丸投げに行き着きます。

教訓はシンプルで、一定規模の開発では要件定義を開発と切り離して先に行うことです。成果物の要件定義書は、そのまま複数社を同じ条件で比較する共通資料として使えます。開発費用の目安や内訳は費用相場の記事に譲りますが、要件定義への投資は見積もりの精度と失敗確率の両方に直接効きます。

発注側が要件定義の失敗を防ぐ5つの手順

実際の支援現場でよくあるのは、機能一覧は立派に揃っているのに「この画面を誰が、いつ、どの業務で使うのか」に発注側が答えられないケースです。機能から入ると要件は際限なく増えます。目的から入り、業務に沿って絞り込む順番に変えるだけで、要件定義の質は大きく変わります。具体的には次の5つの手順で進めます。

5つ目の議事録は地味に見えますが、最も効きます。冒頭で紹介した裁判例でも、裁判所が判断の決め手にしたのは双方の主張ではなく打ち合わせの議事録でした。誰が何を求め、どう合意したかの記録は、紛争時の証拠である以前に、日々の認識合わせの道具です。毎回の打ち合わせ後に決定事項と宿題を数行残すだけでも、認識ズレの発見が早まります。

当社（UniGain）の業務アプリ・システム開発（80万円〜）でも、着手前の要件整理に最も時間をかけます。業務フローの棚卸しから伴走した業務システム構築では、工数60%削減・対応速度2.5倍という結果につながりました（詳細は事例ページで紹介しています）。最初から大きく作らず、優先度の高い業務から小さく作って検証する進め方が、結果として失敗の確率を最も下げます。

• 目的と成果指標を文書化する（何が改善されたら成功かをA4一枚に）
• 業務フローと例外処理を現場担当者と棚卸しする
• 参照サービスを具体名で指定する（「このアプリのこの画面と同じ」）
• must（必須）とwant（希望）に分け、予算超過時に削る順番を先に決める
• 議事録と変更ルールを整え、要件追加は費用・納期への影響確認とセットにする