システム開発の仕様変更で追加費用が発生する原因と、発注者が取れる具体的な防止策
「最初の見積もりは300万円だったのに、最終的な請求は560万円になった。なぜこうなったのか、正直なところよく分からない。」
システム開発を外注した経験がある方なら、このような状況に直面したことがあるかもしれません。開発の途中で「仕様変更が発生したため、追加で〇〇万円の費用が発生します」という連絡が届く。その内容が本当に正当な請求なのか、それとも避けられたはずのコストなのか、判断する基準を持てていない方が多いのが現状です。
追加費用の請求があるたびに不信感が募り、「もしかして言い値で払わされているのでは」という疑念が生まれる。しかし反論する根拠も持てないため、結局そのまま承認してしまう。この繰り返しが、最終的に大幅な予算超過につながっています。
実はこの問題には、構造的な原因があります。ベンダー（開発会社）側には「どのタイミングで追加費用を請求するか」について、独自の判断ロジックがあります。そのロジックを発注者が理解していないことが、追加費用トラブルの本質的な原因です。
本記事では、受託開発会社の視点から「なぜ仕様変更が追加費用になるのか」という内部の構造を解説し、発注者が契約前・開発中にできる具体的な予防策をチェックリスト付きでお伝えします。
目次
失敗しないためのシステム開発の考え方と開発パートナー選定チェックリスト
この資料でわかること
こんな方におすすめです
「見積もりと全然違う金額になった」はなぜ起きるのか
よくある追加費用トラブルの実例
ある中小企業が、社内の顧客管理システムを500万円で受託開発会社に依頼したとします。要件定義を経て開発がスタートし、最初の数ヶ月は順調に進みます。
しかし、開発が進むにつれてこんな依頼が積み重なっていきます。
- 「やっぱりこの画面にCSVダウンロード機能も欲しい」（+20万円）
- 「営業部長からの指示で、集計レポートの形式を変更したい」（+15万円）
- 「スマートフォンからも操作できるようにしてほしい」（+80万円）
- 「最初に話したデータ連携の仕様を、実際に使ってみたら変えたい」（+40万円）
最終的に請求額は「500万円 + 追加費用200万円 = 700万円」となり、当初見積もりの1.4倍になりました。発注者は「こんなに増えるとは思っていなかった」と困惑しますが、ベンダー側は「仕様変更に対応した分を請求しています」と説明します。
発注者が感じる「不信感」の正体
このトラブルで発注者が感じる不信感の根本は、「自分が依頼した変更のどれが追加費用の対象になり、どれがならないのか、事前に知らされていなかった」という点にあります。
ベンダー側には追加費用を請求する基準があります。その基準を知らずに開発を進めると、思わぬ場面で追加請求が来て不信感が生まれます。まずはその構造を理解することが、解決への第一歩です。
仕様変更コストが生まれる3つの構造的原因
追加費用が発生する根本的な原因は、次の3つに集約されます。
原因① 要件定義が曖昧だと「全部が仕様変更」になる
システム開発において「仕様変更」かどうかを判断する基準は、要件定義書（または仕様書）の内容との比較です。
要件定義書に明記されていた機能・仕様の変更 → 追加費用の対象 要件定義書に書かれていなかった機能・仕様の追加 → 追加費用の対象
逆に言えば、要件定義書が曖昧であったり、作成されていなかったりすると、ベンダーは「これは最初の仕様に含まれていない」と判断できる範囲が広がります。
要件定義の段階で「○○画面には○○機能が必要」という具体的なレベルまで落とし込まれていないと、開発が進んでから発注者が「こうしてほしかった」と言っても、それは新たな仕様変更として扱われます。
結果として、「要件定義が甘い = 追加費用が発生しやすい」という関係が成り立ちます。詳細な要件定義の作り方についてはシステム開発の要件定義を成功させる完全ガイドで解説しています。
原因② 口頭・メールでの変更依頼がスコープをじわじわ拡大する
開発途中での依頼方法も、追加費用の発生に大きく影響します。
「ちょっとこの機能を直してほしいんですが」「次の定例のときに伝えようと思うんですが」という形で、変更依頼が口頭やチャット・メールで断片的に伝えられることがあります。
このとき問題が起きます。ベンダー側は「それは仕様変更なのか、それとも最初から含まれていたものの修正なのか」を都度確認する工数がかかります。そして曖昧なまま変更が積み重なると、最終的に「これだけ積み上がっているので請求します」という形でまとめて請求されます。
これが「スコープクリープ」と呼ばれる現象で、最初は小さかったスコープが少しずつ拡大し、気づいたときには大幅なコスト増加につながっているパターンです。
原因③ 請負と準委任で「追加費用」の判定基準が変わる
契約形態によって、仕様変更の取り扱いが根本的に異なります。
請負契約の場合、ベンダーは「仕事の完成」に対して報酬が発生します。契約書に定めた成果物を完成させることが義務であるため、要件定義書の範囲内での変更は無報酬で対応する義務があります。しかし、要件定義書の範囲を超えた変更は「新たな仕事」として別途費用が発生します。
準委任契約（月額制・時間単価制）の場合、ベンダーは「作業した時間・工数」に対して報酬が発生します。変更依頼があっても、それに対応した分の時間が積み上がるだけで、大きな追加請求にはなりにくい一方、最終的なコストが変動します。
多くのシステム開発では、初期フェーズは「請負契約」で固定費用、保守・改善フェーズは「準委任契約」で月額制という組み合わせが使われます。どちらの契約形態で開発を依頼しているかによって、仕様変更への対応方法が変わります。
契約前にできる仕様変更コスト防止策
仕様変更による費用増加を防ぐ最も効果的な方法は、開発が始まる前に手を打つことです。
要件定義書を「仕様凍結ドキュメント」として活用する
要件定義書は、単なる機能一覧ではなく「この開発で作るものと作らないものの境界線を明確にするドキュメント」として機能させることが重要です。
要件定義書に含めるべき項目:
項目 |
内容 |
|---|---|
機能要件 |
各機能の詳細仕様（画面・操作フロー・入力値・出力値） |
非機能要件 |
パフォーマンス・セキュリティ・可用性の基準 |
スコープ外の明記 |
「今回の開発には含まない」ものを明示する |
前提条件・制約 |
連携するシステム、使用するインフラ、期間・予算の制約 |
特に重要なのは「スコープ外の明記」です。「〇〇機能は今回含まない」と明示することで、後から「あの機能はどうなった?」という曖昧さをなくします。
要件定義書を作成したら、ベンダーとの合意（サインまたは確認メール）を取り、「この内容で開発する」という共通認識を持つことが必須です。
契約書に変更管理プロセスを明記する
要件定義書だけでなく、契約書に「変更が発生したときの対応プロセス」を明記することで、開発途中での追加費用トラブルを防ぎます。
契約書に盛り込むべき変更管理に関する条項（チェックリスト）:
- 仕様変更の判断基準（何をもって「仕様変更」とするか）
- 変更依頼の申請方法（書面・変更依頼書など）
- 変更依頼を受け取ってからベンダーが影響見積もりを提示するまでの期間
- 追加費用が発生する場合の算定方法（時間単価、工数見積もりなど）
- 発注者による承認なしに変更作業を開始しないこと
- 変更に関するコミュニケーション記録の保存方法
これらが契約書に明記されていれば、「なぜこの費用が発生するのか」をベンダーに説明させる根拠が生まれます。見積もりの精度を上げる方法についてはシステム開発における見積もりのチェックポイントも参考にしてください。
開発中の変更管理プロセスを構築する方法
契約後、開発が進んでいく中でも変更管理の仕組みを実際に運用することが重要です。
変更依頼書（CR）の作り方と運用ルール
Change Request（CR）とも呼ばれる変更依頼書は、仕様変更を正式に記録・管理するための書類です。口頭やメールで断片的に伝えた変更依頼を一本化し、「誰が・いつ・何を・なぜ変更したいのか」を明確にします。
変更依頼書に含める項目:
項目 |
記載内容 |
|---|---|
変更依頼番号 |
CR-001, CR-002... などの連番 |
依頼日 |
変更依頼を提出した日付 |
依頼者 |
依頼した担当者名・部署 |
変更の概要 |
何を変えたいかを具体的に記述 |
変更の理由 |
なぜこの変更が必要か |
対象機能・画面 |
変更が影響する機能・画面名 |
優先度 |
高・中・低 |
影響見積もり（ベンダー記入欄） |
追加工数・費用・スケジュールへの影響 |
承認欄 |
発注者の承認サイン・日付 |
変更依頼書の運用ルールとして、「口頭・メールによる変更依頼のみでは作業を開始しない」ことをベンダーと事前に合意しておくことが重要です。これにより、変更の積み重ねを防ぎます。
発注者側の変更承認フローを設計する
変更依頼書を提出したあと、どのプロセスで承認するかを設計します。
- 発注者側での変更依頼書の作成・提出（担当者）
- ベンダー側の影響見積もり提示（3営業日以内など期限を設定）
- 発注者内での承認判断（担当者→上長→最終承認者）
- 承認後のベンダーへの通知（書面・メールで記録を残す）
- 変更内容に基づく作業開始
このフローのポイントは、「承認なしに作業を開始しない」というルールをプロジェクトの開始前にベンダーと合意しておくことです。
「小さな変更」を積み重ねないための合意の取り方
スコープクリープは「小さな変更の積み重ね」から起きます。「これくらいならいいかな」という感覚で口頭で伝えた変更が、気づかないうちに大量に積み上がっているのが典型的なパターンです。
対策として、変更の大小にかかわらず必ず変更依頼書を起票するルールを徹底します。追加費用が発生しない「軽微な変更」であっても記録に残すことで、後から「あのとき言ったこれはどうなった?」という曖昧さをなくすことができます。
また、定例ミーティング（週次・隔週など）の場で変更依頼書の一覧を確認し、「保留中の変更依頼は何件あるか」「どれが承認済みでどれが未承認か」を可視化することも有効です。
アジャイル開発を使った「変更を織り込んだ外注」という選択肢
仕様変更を完全にゼロにするのが難しい場合は、「変更を前提とした開発方式」を選ぶことが合理的な選択肢になります。
アジャイル開発での「仕様変更」の扱い方
アジャイル開発（特にスクラム）では、開発を「スプリント」と呼ばれる短期間（1〜2週間）のサイクルで繰り返します。各スプリントの開始時に「このスプリントで作るもの」を確定し、スプリント中の仕様変更は次のスプリントに持ち越します。
このアプローチの利点は、「変更を禁止するのではなく、変更を次のサイクルで取り込む」という構造にあります。発注者は各スプリントの成果を見ながら優先度を変更でき、「やっぱりこっちの機能を先に作ってほしい」という方向転換が可能です。
アジャイル外注での予算管理の考え方（タイムボックス型）
アジャイル外注での費用管理は「タイムボックス型」が基本です。「このプロジェクトには月額○○万円・○ヶ月間」と時間・費用の上限を設定し、その範囲内で最大の価値を実現する機能を優先的に開発していきます。
要件が固まっていない段階でのシステム開発や、仕様変更が多く発生することが予想されるプロジェクトでは、「一括請負」より「アジャイル型の準委任契約」の方が総コストを抑えられることがあります。
ただし、アジャイル外注はベンダーの管理能力と発注者の関与度（毎週のレビュー参加など）に依存します。自社のリソースと照らし合わせて検討してください。
追加費用が来たときの交渉ポイント
すでに追加費用の請求が来てしまった場合でも、適切な対応が可能です。
追加費用が「正当」か「不当」かを見極める3つの基準
-
要件定義書との照合: 追加費用が発生した機能・変更が、要件定義書に明記されていたかどうかを確認します。明記されていた内容であれば、追加費用を要求される根拠がありません
-
変更依頼の記録の有無: 「発注者側がいつ、どのような変更を依頼したか」の記録（メール・チャット・変更依頼書など）を確認します。記録がない変更については、追加費用の根拠を説明させる権利があります
-
変更承認の有無: ベンダーが変更作業を開始する前に、発注者の承認を得ていたかどうかを確認します。「勝手に変更して費用を請求された」という場合は、未承認の作業であることを主張できます
交渉時に使えるエビデンスの集め方
追加費用の交渉には「記録」が最大の武器です。以下の記録を整理して交渉に臨みます。
- メール・チャットのスクリーンショット（変更依頼の内容・日時・担当者）
- 変更依頼書の控え（承認有無・日付）
- 定例ミーティングの議事録（変更の議論が記録されているもの）
- 要件定義書・仕様書の原本
逆に、今後のプロジェクトのために「連絡はメールで記録を残す」「口頭で指示した場合はメールで事後確認する」という習慣を今から始めることが、将来の費用トラブル防止につながります。
詳細な外注の進め方についてはシステム開発RFPの書き方完全ガイドも合わせてご覧ください。
まとめ：追加費用ゼロを目指す発注者チェックリスト
仕様変更による追加費用トラブルは、「構造的な原因」と「防止策」を知ることで、大きく減らすことができます。本記事の内容を以下のチェックリストにまとめます。
契約前チェックリスト
- 要件定義書に「スコープ外の機能」を明記した（何を作らないかを合意した）
- 要件定義書の内容について、ベンダーとの確認・合意が取れている
- 契約書に「仕様変更の定義と変更管理プロセス」が明記されている
- 追加費用が発生する条件と算定方法を契約書で確認した
- 「承認なしに変更作業を開始しない」という合意がある
開発中チェックリスト
- 変更依頼は必ず変更依頼書（CR）で記録している
- 変更依頼書には「影響見積もり（費用・工数・スケジュール）」をベンダーに記入させている
- 発注者内での変更承認フローが機能している（担当者→上長の承認ルートがある）
- 定例ミーティングで変更依頼書の一覧を確認・可視化している
- 口頭・メールのみの変更依頼では作業を開始させないルールが守られている
仕様変更を「完全にゼロ」にすることは現実的ではありません。しかし「変更が発生したとき、どのプロセスを経て、どのように費用が決まるか」を発注者が主導権を持って管理することは十分に可能です。
失敗しないためのシステム開発の考え方と開発パートナー選定チェックリスト
この資料でわかること
こんな方におすすめです
作業時間削減
システム化を通して時間を生み出し、ビジネスの加速をサポートします。
システム開発が可能に
