要件定義書なしで発注すると何が起きるか？元開発SEが見てきた5つのトラブルと最低限の準備
アカンパニー・パートナーズ
システム開発を「要件定義書（何を作るかの計画書）」なしで発注すると、「追加費用の発生」「納期の大幅な遅延」「言った・言わないの水掛け論」「現場で使えない機能不足」「最後のチェックでの揉め事」という5つの致命的なトラブルがほぼ確実に発生します。日経コンピュータ誌の調査でも、システム開発が失敗する原因の第1位は「要件定義の不備」です。この記事では、かつて開発会社のSE（システムエンジニア）として数々の修羅場を見てきた筆者が、現場の実態と、ITに詳しくない経営者でも発注前に最低限これだけは決めておくべき3つのポイントをわかりやすく解説します。
要件定義書なしで発注すると起きる5つのトラブル
要件定義書がない発注は、ゴール（完成形）の基準がない状態です。そのため、費用が倍増し、納期が遅れ、最終的に「現場でまったく使えないシステム」が出来上がるという最悪の結果を招きます。
【5つのトラブル・まとめリスト】
トラブル① 追加費用が当初見積もりの1.5〜2倍に膨らむ
トラブル② 納期が数ヶ月単位で大幅に遅延する
トラブル③ 「言った・言わない」の水掛け論になり、関係が悪化する
トラブル④ 完成品が「こんなはずじゃなかった」と現場に拒絶される
トラブル⑤ 完成後の最終チェック（検収）で双方が揉めてプロジェクトが止まる
日経コンピュータの調査では、システム開発プロジェクトの失敗理由の第1位が「要件定義の不備」と報告されています。（出典：stelaq.co.jp「ソフトウェア要件定義とは？」https://stelaq.co.jp/column/1025 2025年7月）
トラブル① 追加費用が当初見積もりの1.5〜2倍に膨らむ
要件定義書がない状態で発注すると、開発会社（受注側）は「自分たちの解釈」で見積もりを作ります。発注者側が後から「この機能も必要だった」「この動きは違う」と気づくたびに、追加費用が発生します。受注側のSIerとして経験した肌感では、要件定義なし案件の追加費用は当初見積もりの1.5〜2倍になることが多いです。「300万円で発注したら最終的に600万円かかった」というケースは珍しくありません。
トラブル② 納期が大幅に遅延する
要件定義なし発注では、開発途中での仕様変更・追加要望が頻発します。変更のたびに設計をやり直すため、当初の納期を大幅に超過します。受注側も「こんなに変わるなら最初から教えてほしかった」という状態になり、双方のモチベーションが低下します。開発途中での仕様変更は、最終工程（テスト後）に変更が発生するほどコストが大きくなります。（出典：WEB制作会社Y's「システム開発の失敗事例と原因」https://ysinc.co.jp/blog/system-failure-cases/ 2026年1月）
トラブル③ 「言った・言わない」の水掛け論になる
口頭で合意した内容は、記録が残りません。「あの時こう言った」「そんなことは聞いていない」という認識の相違が、プロジェクト後半に深刻なトラブルとして噴出します。法的には、請負契約において「完成物の仕様」が不明確な場合、何が「完成」かの判断基準がなくなるため、検収（完成したシステムが正しく動くかの最終チェック）を巡る訴訟リスクも生じます。最悪の場合、裁判沙汰になるリスクすら孕んでいます。
トラブル④ 完成品が「こんなはずじゃなかった」になる
要件定義書がないと、開発会社は「最も一般的な解釈」でシステムを作ります。発注者が業種特有のフローや独自の業務ルールを伝えていなければ、完成したシステムが自社の業務に合わないという事態が起きます。「今までExcelで楽にできていた作業が、システムを入れたせいで3倍の手間になった」という悲劇は、これが原因で起きます。
トラブル⑤ 完成後の最終チェック（検収）で揉める
開発が完了した時点で「これは依頼した内容と違う」「いや、指示通りに作った」という対立が起きます。要件定義書があれば「書かれた要件を満たしているか」という客観的な判断基準になりますが、それがないと検収基準が曖昧になります。開発会社は「作ったからお金を払ってほしい」と言い張り、経営者は「使えないから払えない」と主張し、プロジェクトは完全に暗礁に乗り上げます。
元開発SEが明かす「要件定義なし発注」の不都合な真実
ITベンダー（開発会社）は、要件定義がない案件を「超高リスク」とみなします。そのため、あらかじめ失敗を見越した「高い安全マージン（上乗せ費用）」を積んだ見積もりを提示せざるを得ないのが実態です。
受注側は要件定義なし案件をどう見ているか
受注側の開発会社は、要件定義なし発注を「リスクの高い案件」として認識しています。明示されていないリスクを見積もりに含めるため、要件定義なし案件の見積もりは「安全マージン」を多く積んだ高めの金額になりやすいです。あるいは逆に、リスクを意識せず低い見積もりで受注し、後から追加費用を請求するという構造になることもあります。
要件定義書が整備されている案件は、受注側も「明確な要件通りに作ればいい」と安心して価格を下げられます。つまり、発注者がしっかり要件定義書を用意することで、見積もり精度が上がり、最終的なコストを下げられるという逆説的な関係があります。
「とりあえず作ってください」が最も危険な言葉
「まずは動くものを作ってから、詳細を詰めましょう」という進め方は、中小企業のシステム発注でよく聞かれます。この進め方は「アジャイル開発（作りながら少しずつ進める手法）」に似た響きがありますが、要件の合意なしに「とりあえず作る」のは、アジャイルでもなく単なるノープランです。ノープランで作り始めるのは、設計図なしで家を建てるのと同じです。アジャイル開発は「小さな要件を都度定義して開発を繰り返す」という方法であり、「要件定義をしない」という意味ではありません。
口頭合意がなぜ機能しないか
システム開発は、担当者が複数存在します。打ち合わせに参加した担当者Aが「こう決まった」と認識していても、実際に開発するエンジニアBには正確に伝わらないことが多いです。記録のない口頭合意は、伝言ゲームのように劣化し、間違った形で現場に届きます。要件定義書という文書が、この劣化を防ぐ唯一の手段です。
【実務コメント】
ITベンダー（受注側SE）として11年間、数多くの「要件定義なし発注」の修羅場を経験してきました。最も多かったのは、「打ち合わせのたびに、発注者側の言うことが変わる」パターンです。最初の合意内容が、3ヶ月後には「そんな話はしていない」となる。
これは経営者の方が嘘をついているのではなく、記録がないために、日々の業務の忙しさの中で「各自の都合のいい解釈」に記憶がすり替わってしまうのです。
現在はITコーディネーターとして、100%発注者（中小企業）の味方に立って伴走していますが、「最初に要件を正しく整理して文書化してあるか」、これだけでプロジェクトの成功率は文字通り天と地ほど変わります。
要件定義書がないと具体的にコストはどう変わるか
要件定義フェーズで決めると安い・後工程で変えると高い
システム開発では「早い工程での変更ほど安く、遅い工程での変更ほど高い」という鉄則があります。システム開発の世界で40年以上支持されている有名な研究データ（ソフトウェア工学の通説）によると、工程が進んでからの仕様変更コストは以下のように膨れ上がります。
- 要件定義（計画段階）での変更コスト：1
- 基本設計（設計図段階）での変更コスト：3〜5倍
- 実装・テスト（製造段階）での変更コスト：10〜20倍
- リリース（本番稼働後）での変更コスト：50〜100倍
画面のボタン1つ、データの項目1つを追加するだけでも、完成間近であればあるほど「他のシステムへの影響調査」「プログラムの書き直し」「再テスト」が発生し、莫大な人件費が追加請求されます。
要件定義あり vs なしの発注比較
| 比較軸 | 要件定義書あり | 要件定義書なし |
|---|---|---|
| 見積もりの精度 | 高い（根拠ある見積もり） | 低い（安全マージン込みで高くなりがち） |
| 追加費用のリスク | 低い（変更は合意書ベース） | 高い（際限なく追加が発生しうる） |
| 納期の安定性 | 高い | 低い（仕様変更のたびに遅延） |
| 完成品の品質 | 要件通りに判断できる | 「こんなはずじゃなかった」が起きやすい |
| 法的リスク | 低い（検収基準が明確） | 高い（「完成」の定義が曖昧） |
追加費用が発生する3つの典型パターン
① 機能の追加要望：「やっぱりこの機能も必要だった」という後付けの要望。設計・実装・テストのやり直しが発生します。
② 仕様変更：「この動きを変えてほしい」という修正。既存コードへの影響調査・修正・再テストが必要になります。
③ 認識の相違の修正：「こういう意味で言っていたのに違う実装になった」という解釈の相違。最悪の場合、ゼロから作り直しになります。
最低限これだけ決めてから発注する3つの事項
要件定義書を完璧に作れなくても、以下の3つを文書化してから発注することで、トラブルリスクを大幅に下げられます。
① 「何のために作るか」目的と解決課題
「現在の〇〇という業務課題を、システム化によって解決したい」という1文を書きます。「とにかくシステムが欲しい」ではなく「受注管理に週10時間かかっているのを自動化したい」という粒度が必要です。
② 「誰が使うか・何をするか」対象ユーザーと主要機能
「営業担当者5名が、顧客情報と商談履歴を入力・確認する」という形で、使うユーザーと主要な操作を箇条書きにします。全機能を網羅する必要はありませんが、「最も重要な3〜5機能」は必ず明記します。
③ 「予算・納期・制約条件」の明文化
「予算の上限は300万円」「◯月◯日の新規事業立ち上げまでに稼働させたい」「既存の会計ソフト（弥生会計など）とデータ連携させたい」といった制約条件をあらかじめ文書に残します。これを伝えないと、ITベンダーは「一番高機能で高額な提案」を持ってくることになります。
【発注前チェックリスト：最低3項目の確認】
□ 解決したい課題と目的を1文で書けるか
□ 使うユーザーと主要機能（3〜5つ）を書き出しているか
□ 予算上限・納期・制約条件を文書化しているか
この3つが揃っていない場合は、発注を一旦止めて要件整理を先に行うことを推奨します。要件定義だけを外部に依頼する方法については「要件定義だけ外注できる？中小企業の部分依頼ガイド」をご参照ください。
要件定義書を作れない場合の現実的な対処法
ITコーディネーターに要件整理を依頼する方法
自社に要件定義を作成できる人材がいない場合は、ITコーディネーターに要件整理を依頼することが最も現実的な選択肢です。ITコーディネーターは特定の開発会社と利害関係を持たない中立的な立場で、「何を作るべきか」の整理から「どのベンダーに発注すべきか」の選定まで支援できます。
詳細は「ITコーディネーターとは？何をしてくれるのか」・費用の目安は「ITコーディネーターの費用・料金相場」をご参照ください。ベンダー選定での失敗を防ぐ方法は「中小企業がベンダー選定で失敗する原因」もご参照ください。
自社で要件定義 vs 外注する場合の比較
| 比較軸 | 自社で要件定義 | ITCに外注する |
|---|---|---|
| 費用 | 人件費のみ（実質コスト） | 20〜80万円（補助金活用で1/2〜2/3減） |
| 時間 | 1〜3ヶ月（IT知識が必要） | 2〜6週間（プロが主導） |
| 品質 | スキルに依存・漏れが多い | 標準的な要件定義書の品質が担保 |
| 中立性 | 自社の偏りが入りやすい | ベンダー中立で客観的 |
| 補助金対象 | 対象外 | NICO等の専門家派遣で補助可能 |
段階発注（フェーズ分割）で要件定義を最初の発注に含める
「全体システムの発注」と「要件定義フェーズの発注」を分けるという方法もあります。まず「要件定義フェーズ」のみを50〜100万円規模で発注し、要件定義書が完成してから「開発フェーズ」を複数社に競争入札で発注します。この方法により、要件定義を開発会社に丸投げするリスクを回避できます。
CRM・基幹システム・業務システム等の要件整理について、中立的な立場でご相談に乗ります。
新潟を拠点に、オンラインで全国対応しています。初回相談無料です。
よくある質問
-
要件定義書がなくても発注できますか？
-
技術的には可能ですが、本記事で示した5つのトラブルリスクが大幅に上がります。最低限「目的・主要機能・予算」の3つを文書化してから発注することを強く推奨します。
-
要件定義書と仕様書の違いは何ですか？
-
要件定義書は「何を作るか（What）」を定義する文書で、仕様書は「どう作るか（How）」を定義する文書です。発注者が作るのが要件定義書、受注側（開発会社）が作るのが仕様書という役割分担が一般的です。
-
要件定義書を作るのにどのくらいかかりますか？
-
自社で作る場合は1〜3ヶ月・ITコーディネーターに依頼する場合は2〜6週間が目安です。費用は外注で20〜80万円が相場です。詳細は「要件定義だけ外注できる？」をご参照ください。
-
要件定義なし発注で起きたトラブルへの対処法は？
-
今この瞬間から「現時点で合意できていること（マル）」と「保留事項（サンカク）」を両者で書き出し、文書にしてサインを取り交わします。感情がこじれている場合は、ITコーディネーターなどの中立な第三者を間に入れて交通整理することをお勧めします。
-
中小企業が要件定義をする場合、どこに頼めばいいですか？
-
ITコーディネーターへの依頼が最適です。新潟県ではNICO専門家派遣事業で費用の1/2〜2/3が補助され、自己負担を数万円程度に抑えられるケースがあります。詳細は「ITC費用相場」をご参照ください。
-
要件定義なしで発注してしまった場合、今からでも間に合いますか？
-
開発着手前であれば十分間に合います。開発途中でも、現時点での仕様を「要件定義書」として文書化することでトラブル予防になります。今すぐITコーディネーターに相談することをお勧めします。
参考：stelaq.co.jp「ソフトウェア要件定義とは？」https://stelaq.co.jp/column/1025（2025年7月・日経コンピュータ調査引用）／ WEB制作会社Y's「システム開発の失敗事例と原因」https://ysinc.co.jp/blog/system-failure-cases/（2026年1月）／ DX・リスキリングサプリ「システム開発の発注トラブルとその回避策」https://www.internetacademy.co.jp/trends/it-strategy/order-trouble.html
投稿者プロフィール
- 代表
-
プログラマーとしてキャリアをスタートし、製造業の社内SEとして「工場」の論理を、士業事務所の社内SEとして「先生」の論理を肌で学んできました。異なる文化を持つ組織の中でITを推進するには、技術力以上に「聴く力」と「翻訳力」が必要です。
現在はその経験を活かし、新潟の中小企業のDXを支援しています。
ITコーディネーター／上級ウェブ解析士／上級SNSマネージャー
