システム開発の仕様変更で追加費用が発生する理由と、揉めずに防ぐ方法

「開発の途中で少し仕様を変えたいと伝えたら、想定外の追加費用を請求された」——システム開発でよく起きるトラブルです。仕様変更そのものは悪いことではなく、むしろ良いものを作るために必要な場合もあります。問題は、なぜ追加になるのか・どこからが追加なのか・いくらなのかが曖昧なまま進むことです。この記事では、仕様変更が追加費用に変わる仕組みから、揉めない防ぎ方、契約形態による違いまでを具体的に解説します。読み終えるころには、変更を「怖いもの」ではなく「管理できるもの」として扱えるはずです。

なぜ仕様変更は「追加費用」になるのか

システム開発は、先に決めた仕様を土台にして設計・実装を積み上げていく作業です。家を建てるのに近く、間取りを決めてから基礎・柱・壁と進みます。途中で「部屋をもう一つ」と言えば、すでに引いた図面や組んだ柱に手を入れる必要が出てきます。ソフトウェアも同じで、変更は次のような形で作業量を増やします。

• 作り直し：すでに書いたプログラムや作った画面を、新しい仕様に合わせて修正・再作成する
• 手戻り：終わったはずの設計やテストの工程まで戻ってやり直す
• 影響範囲の波及：一か所の変更が、つながっている別の機能にも波及して修正が必要になる
• テストのやり直し：直した部分と、その影響を受ける部分をもう一度動作確認する
• スケジュール変更：作業が増えたぶん納期がずれ、体制の調整や再見積もりが発生する

これらはどれも「新たに生まれた作業」です。作業が増えれば工数が増え、工数に応じて費用が上乗せされます。つまり追加費用は業者が儲けるための口実ではなく、増えた作業量の対価というのが本質です。ここを理解しておくと、請求の妥当性を冷静に判断できます。

見落とされがちなのが、変更は目に見える部分だけで完結しないという点です。たとえば「入力項目を1つ増やしたい」という一見小さな変更でも、画面の見た目を直すだけでなく、その項目を保存するためのデータの入れ物（データベース）を変え、保存・読み出しの処理を直し、既に登録済みのデータをどう扱うかを決め、最後に一連の動作をテストし直す——という具合に、裏側の作業が連なります。発注側からは「ちょっとした変更」に見えても、開発側では複数の工程にまたがる作業になるため、感覚のズレが生じやすいのです。このズレを埋めるには、変更を伝えるときに「なぜそれが必要か（目的）」まで共有し、開発側から「それならこの方法のほうが安く済む」という代案を引き出すのが有効です。

同じ「機能を1つ足す」変更でも、それを言い出すタイミングで費用は大きく変わります。早ければ図面の描き直しだけで済み、遅ければ組み上がった建物を壊してやり直すことになるためです。

変更を伝える時期	影響範囲	追加費用の傾向
要件定義中	文書の修正のみ	ほぼ無料〜小さい
設計中	設計図の描き直し	小〜中
開発（実装）中	コードの作り直し＋設計修正	中〜大
テスト中・納品直前	広範囲の作り直し＋再テスト	大きい

この傾向は「変更は早いほど安い」という原則で覚えられます。だからこそ、作るものを固める要件定義の工程が重要になります。何を作るかを最初に丁寧に決めるほど、後からの高い変更を減らせます。要件定義で何をするかは要件定義とは何をするかで解説しています。

もちろん、最初にすべてを完璧に決めきるのは現実的ではありません。使ってみて初めて気づくこともあります。大切なのは変更をゼロにすることではなく、**「決めるべきことを、決められるうちに決めておく」**こと。画面の見た目やちょっとした文言は後から柔軟に直せますが、データの持ち方や機能の骨格といった土台の部分は、後から変えると影響が広範囲に及びます。土台に関わる判断ほど早い工程で固め、細部の調整は後回しにする——この優先順位づけができると、変更コストを大きく抑えられます。

どこからが「追加」か——当初範囲の線引き

追加費用の話がこじれる最大の原因は、「どこまでが最初の約束に含まれるか」の認識が発注側と開発側でズレていることです。基準はシンプルで、当初の見積もり（＝要件定義で決めた機能）に含まれるかどうかです。

• 範囲内（追加になりにくい）：誤字の修正、ボタンの色や文言の微調整、決めた仕様どおりに動かすための不具合対応
• 範囲外（追加になりやすい）：新しい機能・画面の追加、決めた仕様の作り替え、対応端末やブラウザの追加、外部サービスとの新たな連携

ただし、この線引きは会社によって微妙に違います。「軽微な調整は無料」の範囲も、A社は寛容でB社は厳格、ということが普通に起こります。だからこそ、着手前に「何が範囲内で、何が追加になるか」を見積書か契約書に書いておくことが決定的に重要です。曖昧なまま進めると、開発側は「それは別料金」、発注側は「聞いていない」となり、感情的な対立に発展します。線引きを最初に文面化することが、後のトラブルを防ぐ一番の予防策です。契約書で確認すべき点は契約書チェックの勘所も参考になります。

追加費用の相場感——工数×単価で考える

仕様変更の追加費用に定価はありません。金額は「増える工数 × 人月単価」で決まります。人月単価は1人が1ヶ月働く作業量あたりの費用で、中堅で60万〜100万円が目安です。1人月＝約20営業日なので、1日あたりおよそ3万〜5万円と考えると小さな変更の見当がつきます。人月の考え方は人月・人月単価とはで解説しています。

変更の規模	作業量の目安	追加費用の目安
文言・レイアウトの微調整	数時間	数万円、または範囲内で無料
画面に項目・ボタンを追加	1〜3日	数万〜十数万円
機能・画面を1つ新設	1〜2週間	数十万円
決済・外部連携の追加	2週間〜	数十万〜100万円超
データ構造の根本的な作り替え	数週間〜	100万円超になることも

あくまで幅であり、実際の作業内容で上下します。ここで大切なのは金額そのものより、「どう算定するのか」を事前に共有できているかです。「1件いくら」なのか「時間×単価」なのか、無料修正は何回までか——この算定ルールが決まっていれば、請求が来ても納得して判断できます。逆にルールがないと、同じ変更でも言い値になりがちです。費用の全体像はシステム開発の費用相場、見積書の読み方は見積もりの見方もあわせてご覧ください。

揉めるパターンと、その防ぎ方

追加費用でトラブルになるケースには、はっきりした型があります。型を知っておけば、事前に手を打てます。

揉めるパターン	何が起きているか	防ぎ方
「ついで」の積み重ね	口頭で小さな変更を頼み続け、総額が膨らむ	変更は必ず書面で依頼し、費用と納期を都度確認
範囲の認識ズレ	発注側は「含まれるはず」、開発側は「別料金」	要件定義で作る範囲を文書に固める
後出しの要望	テスト段階で大きな仕様変更を出す	早い工程で仕様を確定し、変更は早めに伝える
無料か有料か曖昧	修正が無料の範囲を決めていない	無料修正の回数・条件を契約時に明記

これらを防ぐ土台が「変更管理」という考え方です。具体的には、変更が出るたびに次の3点を書面（変更依頼書やメール）に残します。

• 変更の内容：何を、どう変えるのか
• 費用への影響：追加でいくらか、または範囲内か
• 納期への影響：何日ずれるのか

そのうえで、変更に優先順位をつけます。「絶対に必要」「あれば嬉しい」「なくてもよい」に仕分けし、本当に必要なものだけを通す。こうすると、思いつきの変更で費用と納期が際限なく膨らむのを防げます。ポイントは、変更を止めることではなく見える化して合意しながら進めることです。変更の履歴が文面で残っていれば、後から「言った・言わない」で揉めることもありません。発注全体の流れは発注の流れも参考になります。

契約形態による違い——請負と準委任

追加費用の扱いは、契約の形によっても変わります。システム開発でよく使われるのは「請負契約」と「準委任契約」の2種類です。

項目	請負契約	準委任契約
約束するもの	決めた成果物を完成させること	決めた業務を遂行すること
費用の形	総額固定が基本	稼働（時間・人月）に応じて支払い
仕様変更の扱い	範囲外は追加見積もりで対応	稼働が増えれば費用も増える
向いている場面	作るものが明確に決まっている	要件が固まりきらず柔軟に進めたい

請負は「この仕様でいくら」と決めるため、当初範囲は総額に含まれますが、範囲外の変更は追加見積もりになります。範囲の線引きが特に重要になる契約です。一方準委任は、作業した時間や人員に応じて支払うため、仕様変更にも柔軟に対応できますが、変更が増えればそのぶん費用も積み上がります。どちらが良い・悪いではなく、案件の性質に合わせて選ぶものです。要件がある程度固まっているなら請負、探りながら作るなら準委任、というのが基本的な考え方です。

なお、実際の案件では「要件定義は準委任、開発は請負」というように、工程ごとに契約を分ける進め方もよく使われます。作るものが曖昧な前半は柔軟に、固まった後半は総額を確定させて、という組み合わせです。契約書を受け取ったら、自分の案件がどちらの形なのか、そして仕様変更が出たときの費用の扱いがどう書かれているかを必ず確認しましょう。契約時の注意点は開発契約の注意点で詳しく解説しています。

発注側が仕様変更を減らす工夫

追加費用を抑える一番の近道は、そもそも大きな仕様変更が起きにくい進め方をすることです。発注側にもできる工夫があります。

• 要件の優先順位を最初に決める：全機能を同列に扱わず、「最初のリリースで絶対に要る機能」と「後回しでよい機能」を分ける
• MVP（最小限の形）から始める：欲張って全部を一度に作らず、核となる機能だけで小さく作り、使いながら足していく
• 使う人の声を早めに集める：完成間際ではなく、設計や初期段階で実際に使う人に確認し、後出しの変更を減らす
• 決まっていないことを正直に伝える：曖昧な点を隠さず共有すると、開発側が前提を置いて設計でき、認識ズレが減る

特に効果が大きいのがMVPで小さく始める進め方です。最初から完璧を目指すと、作っている間に「やっぱりこうしたい」が次々に出て、大きな作り直しにつながります。まず動くものを作り、実際に使ってみて必要な変更を見極めるほうが、無駄な作り直しを減らせます。

**例：予約管理システムを作るケース。**最初に「予約の受付・一覧・キャンセル」だけをMVPとして作り、リリース後に「自動リマインド」「決済連携」を追加していく。こうすれば、使ってみて本当に必要と分かった機能だけを足せるため、想像で盛り込んで作り直す無駄がありません。要件を固める段階から相談に乗ってくれる会社を選ぶと、この進め方がやりやすくなります。

追加費用で損しないためのチェックリスト

契約に進む前に、次の項目を上から順に確認してください。半分以上に「はい」と言えないなら、質問して埋めてから契約に進むのが安全です。金額の大小より、これらが明確かどうかが後のトラブルを分けます。

• 作る機能の範囲が、要件定義として文書に固められているか
• 「何が範囲内で、何が追加になるか」の線引きが見積書か契約書に書かれているか
• 無料で対応する修正の回数・条件が明記されているか
• 追加費用の算定方法（1件いくら／時間×単価）が事前に決まっているか
• 変更が出たときに、内容・費用・納期への影響を書面化する手順があるか
• 契約形態（請負／準委任）が案件の性質に合っているか
• 仕様が固まりきらない部分について、進め方を相談できる相手か
• 完成後のソースコードの権利が自社に渡るか

この8項目は「追加費用のルールが成立しているか」の点検です。ここが埋まっていれば、変更が発生しても慌てずに判断できます。逆に空欄が多いまま契約すると、開発が始まってから一つずつ交渉することになり、立場が弱くなります。会社の見極め方はシステム開発会社の選び方もあわせてご覧ください。

一律料金なら、範囲内の追加費用は発生しない

ここまで見てきた通り、追加費用のトラブルは突き詰めると「総額がいくらになるか、最後まで確定しない」という不確実性から生まれます。線引きを文書化し、変更管理をし、契約形態を選ぶ——これらはすべて、この不確実性を減らすための工夫でした。

D-oneAppは料金が一律100万円（大規模なプロプランは一律200万円）で、着手前に総額が確定し、範囲内の作り込みでは追加費用が発生しません。決めた範囲の中であれば、作りながら細部を調整しても総額は動かない仕組みです。もちろん、当初の範囲を大きく超える別機能の新設まで無限に含まれるわけではありませんが、「少し変えたら追加請求されるのでは」と身構えながら進める必要がなくなります。悩む対象は「限られた範囲で何を優先して作るか」だけになります。さらに完成したソースコードの権利は顧客に渡るため、あとで別の会社に引き継いで改修することもできます。100万円でどこまでできるかは100万円でできることもご覧ください。

まとめ

仕様変更が追加費用になるのは、作り直し・手戻り・テストのやり直しといった新たな作業が生まれるからで、着手が遅いほど費用は膨らみます。揉めないためには、①当初範囲を要件定義で文書に固める、②変更が出たら内容・費用・納期への影響を毎回書面化する、③優先順位をつけて本当に必要な変更だけ通す——この3つが基本です。契約形態（請負／準委任）は案件の性質で選び、発注側はMVPで小さく始めることで大きな変更を減らせます。

変更そのものは悪ではありません。管理されていない変更が、費用と納期を静かに膨らませるのです。追加費用の不確実性そのものをなくしたいなら、総額が最初から固定される無料相談で、「決まった予算の中で何をどう作るか」を一緒に整理してみてください。