システム開発を外注したら追加費用が増えた……なぜ起きる？契約前に確認すべきこと

「当初の見積もりの1.5倍になった」「仕様変更のたびに追加請求が来る」——受託開発のトラブルで最も多いのが、追加費用問題だ。

開発会社が悪意を持っているケースは少ない。大半は、契約前に論点が曖昧だったことが原因だ。追加費用は突然発生しない。曖昧さが、後から請求書になる。

見積もりを安く取るより、追加費用が起きにくい契約設計の方が、トータルコストは下がる。

追加費用が発生する5つの典型パターン

1. スコープ外だった機能の追加

「当然含まれると思っていた」機能が、見積書上はスコープ外だった。管理画面、通知機能、レポート出力——地味な機能ほど見落とされやすい。

2. 要件の解釈差

「ユーザー管理機能」の解釈が発注者と開発側でズレる。権限管理、SSO連携、監査ログ——粒度の差が工数差になる。

3. 外部連携の不確定要素

API仕様の変更、外部サービスの制約、データ形式の不一致——契約前に洗い出されていない外部依存は、追加費用の定番原因。

4. 仕様変更の積み重ね

小さな変更が50件積み重なると、工数は想定の数倍になる。変更管理のルールがないプロジェクトでは避けられない。

5. 品質問題による手戻り

テスト工程が見積もりに含まれていなかった、または不十分だった場合、バグ修正が「追加対応」として請求される。

深掘り事例：月次の「小さな変更」が四半期で400万になった案件

匿名化した一例だ。請負に近い準委任で始まった社内ツール開発で、初月の追加は「文言修正」「項目追加」程度だった。Slack上の一言依頼が多く、変更管理表はなかった。

3ヶ月後の実態はこうだった。

• 変更チケットが60件超。1件あたり小さな工数でも累計が数百人時
• 「ユーザー管理の強化」が権限・監査・CSVに枝分かれし、別見積もりに発展
• 外部会計APIの仕様差異が発覚し、連携やり直しで120万

当初契約が900万、追加が約400万。悪質な請求というより、変更を変更として扱わない運用が費用を作った。契約書に「変更は見積もり・承認後」とあっても、現場がSlack即対応を続けると形骸化する。

構造的な原因

追加費用が起きやすい構造は、だいたい次のどれかだ。

• 含む／含まないが一覧になっていない
• 変更の定義（仕様変更 vs バグ修正）が共有されていない
• 外部依存の責任分界が契約にない
• 定例でスコープと残工数を突き合わせていない

「追加を請求する会社が悪い」だけでは再発する。発注側の習慣と契約設計の両方を直す。

契約前に確認すべき4つのこと

論点	確認内容
スコープ定義	機能一覧と「含まないもの」の明記
変更管理	変更の判断基準、見積もり・承認フロー
リスクバッファ	不確定要素に対する予備費の有無
追加費用の上限	契約金額に対する上限設定

特に変更管理のルールは、契約書に明文化しておく。口頭合意だけでは、双方にとって不利になる。

追加費用を防ぐ発注側の習慣

• 要件を「Must / Want / Won't」で分類する
• 変更要求は必ず文書化する（Slack 1行でも、変更票に残す）
• 月次でスコープと工数の乖離を確認する
• 「これは追加費用になるか」を都度確認する
• 即対応してほしい緊急度と、見積もり必須の変更を分ける

判断軸：追加を飲む／見直す

状況	推奨
当初スコープ外が明確で、事業上必須	追加見積もりを取り、優先度を付けて実施
Slack依頼の積み上げで請求が膨らんだ	一旦変更を止め、Mustだけ残す
解釈差が原因で双方の記録が弱い	仕様を文書化し、以降の変更ルールを再合意
テスト不足の手戻りを「追加」と言われた	契約時の品質範囲を確認。曖昧なら再発防止を先に決める

次に確認すること

1. 含む／含まない一覧はあるか
2. 変更管理の承認者とフローは契約に書かれているか
3. 外部連携のリスクは誰の責任か
4. 追加費用の上限または通知義務はあるか
5. 月次で残スコープと消化工数を見る場はあるか
6. Must / Want / Won't は分かれているか

まとめ

追加費用は突然発生しない。契約前の曖昧さと、現場の変更放置が、後から請求書になる。

見積もりを安く取るより、追加費用が起きない契約設計と運用の方が、トータルコストは下がる。

---

契約設計・要件整理からの相談は、お問い合わせフォーム からどうぞ。