システム開発で発注側が不安に感じやすいのが、「当初の見積から金額がどんどん増えてしまうのではないか」という点です。実際、開発が進む中で追加費用が発生することは珍しくありません。ただし、その多くは不当な請求ではなく、当初の見積に含まれていなかった作業が、後の工程で必要になって表面化したものです。
本記事は連載第6回として、追加費用が発生しやすい項目を整理します。どこで追加費用が生まれやすいかを事前に知っておけば、見積段階で「この項目は含まれているか」を確認でき、後の認識のずれを抑えられます。
まず結論
- 追加費用は不当な請求とは限らず、見積時点で未確定だった作業が後から具体化して発生することが多いです。
- 発生しやすいのは、仕様変更、外部連携、データ移行、帳票、権限設定、テスト不足の6領域です。
- 変更管理のルール、追加単価、承認フローを先に決めると、発注後の交渉コストを抑えられます。
| 見る項目 | 判断のしかた | 発注前の確認ポイント |
|---|---|---|
| 仕様変更 | 要件追加・画面変更 | 変更依頼書と見積再提示のルール |
| 外部連携 | API・会計・在庫・CRM連携 | 接続先仕様の調査範囲 |
| データ移行 | 旧データの整形・重複処理 | クレンジングの責任分担 |
RESTAURANT DX
店長の経験と勘を、仕組みで再現できる店舗にしませんか？
発注／シフト／予約／FLコストを標準化する多店舗飲食特化のDX。食材ロス削減・インバウンド対応まで概算費用をその場で示します。
この連載での位置づけ
- 前に読む記事：連載第5回：安い見積と高い見積
- 次に読む記事：連載第7回：テスト・移行・教育
- 比較表で整理する：連載第11回：比較表
- 発注前の質問に落とし込む：連載第12回：開発会社への20問
追加費用が発生する仕組み
追加費用は、おおまかに次の3つのいずれかから生まれます。
- 当初は含まれていなかった作業が必要になった（移行・帳票など）
- 進める中で要件が変わった・増えた（仕様変更）
- 想定していた前提が実際と違った（データ量、連携先の仕様など）
いずれも、見積を作った時点では確定していなかったことが原因です。だからこそ、見積段階で「どこまでが含まれ、何が追加になり得るか」を確認しておくことが、追加費用と上手につき合う鍵になります。
追加費用が発生しやすい6つの項目
実務でとくに追加費用が生まれやすいのは、次の項目です。
| 項目 | 追加になりやすい理由 | 見積段階での確認点 |
|---|---|---|
| 仕様変更 | 進める中で要望が増える | 変更の取り扱いと単価の考え方 |
| 外部連携 | 連携先の仕様確認に手間がかかる | 連携本数と相手先の仕様の有無 |
| データ移行 | 既存データの状態が読めない | 移行対象・データ量・整形の要否 |
| 帳票・レポート | 種類が多く細部の調整が発生する | 帳票の種類数とレイアウトの確定度 |
| 権限・ロール設定 | 役割ごとの細かい制御が後から判明する | 利用者の役割と権限の整理状況 |
| テスト不足の補填 | 動作確認が不十分で後から追加する | テストの範囲と受入の基準 |
それぞれを順に見ていきます。
仕様変更
開発を進める中で「やはりこうしたい」という要望が出るのは自然なことです。問題は、変更の取り扱いが決まっていないと、その都度の交渉になりやすい点です。変更管理のルール（誰がどう判断し、どう見積もるか）を最初に決めておくと、追加費用の議論が整理されます。
外部連携
会計ソフトや在庫システムなど、外部のサービスと連携する場合、相手先の仕様を確認する作業が発生します。連携の本数や、相手先がAPIを公開しているかによって工数が変わります。連携の有無と本数は見積段階で確認しておきたい項目です。
データ移行
既存のExcelや旧システムからデータを移す作業は、データの状態によって手間が大きく変わります。表記ゆれや重複の整理（クレンジング）が必要だと、移行の工数は増えます。移行は連載第7回でも詳しく扱います。
帳票・レポート
請求書、納品書、各種集計レポートなどは、種類が多く、レイアウトや項目の調整が細かく発生します。「帳票一式」とまとめられている場合は、種類数を確認しておくと工数の前提が分かります。
権限・ロール設定
「管理者は全部見られて、一般社員は自部署だけ」といった権限の制御は、役割が増えるほど設定が複雑になります。利用者の役割を事前に整理しておくと、見積の前提が固まります。
テスト不足の補填
テストの範囲が狭いと、リリース後に不具合が見つかり、対応が追加作業になることがあります。テストの範囲と受入の基準を見積段階で確認しておくことが、後の追加を抑えることにつながります。追加費用のパターンは見積書の内訳ガイドでも整理しています。
変更管理のルールを最初に決める
追加費用と上手につき合うには、「変更が出たときにどう扱うか」を最初に決めておくことが有効です。具体的には、変更の要望を誰が受け、どう影響（費用・納期）を見積もり、誰が実施を判断するか、という流れを決めておきます。このルールがあると、変更のたびに交渉から始める必要がなくなり、判断が速くなります。小さな変更まですべて止める必要はありませんが、費用や納期に影響する変更は記録に残す運用にしておくと、後の認識のずれを防げます。
追加費用を見積に織り込む2つの考え方
追加費用への備え方には、大きく2つの考え方があります。1つは、あらかじめ一定のバッファ（予備費）を予算に見込んでおく方法です。もう1つは、変更が出るたびに都度見積もる方法です。前者は予算の見通しが立てやすく、後者は使った分だけで済みます。どちらが適しているかは、要件の固まり具合によります。要件がまだ動く可能性があるなら、予備費を見込んでおくほうが、途中で予算が不足する事態を避けやすくなります。
発注前チェックリスト（追加費用）
- 仕様変更が発生したときの取り扱い（変更管理）が決まっているか
- 追加費用が発生する条件と、単価の考え方が示されているか
- 外部連携の本数と、相手先の仕様の確認状況が分かるか
- データ移行の対象・データ量・整形の要否が見積に反映されているか
- 帳票・レポートの種類数が見積に明記されているか
- 利用者の役割と権限が整理され、見積に反映されているか
- テストの範囲と、受入（検収）の基準が定義されているか
- 「別途協議」とだけ書かれた項目について、考え方を確認したか
開発会社に確認する質問
- 「仕様変更が出たとき、どのように見積もり、判断しますか」
- 「この見積で、追加費用が発生しやすいのはどの部分ですか」
- 「外部連携は何本を想定し、相手先の仕様は確認済みですか」
- 「データ移行は、どの範囲・どの状態のデータを想定していますか」
- 「テストはどの範囲まで行い、検収はどの基準で判断しますか」
「追加費用が出やすいのはどこか」を率直に説明できる相手は、リスクを先に共有してくれる傾向があり、進行中の認識のずれを抑えやすくなります。
相談前に整理しておくとよい情報
- 連携が必要な既存システム・サービスの一覧
- 移行したい既存データの種類・量・保存形式
- 必要な帳票・レポートの一覧
- 利用者の役割（管理者・一般・閲覧のみ など）
- 「最初は固めずに進めたい部分」と「最初に確定したい部分」の区別
これらを整理しておくと、追加費用が出やすい項目を見積段階で前倒しに確認でき、後の交渉を減らせます。
追加費用を防ぐための具体的な記録方法
追加費用を完全になくすことはできませんが、発生条件を記録しておくことで、後からの認識違いは減らせます。打ち合わせでは、要望を聞いた日、誰が依頼したか、影響する画面・帳票・API、追加見積の要否、承認者を1行で残します。たとえば「5月25日、営業部から請求書レイアウト2種類の追加依頼、帳票10件中2件に影響、追加見積が必要、承認は管理部長」という粒度です。
この記録があると、開発会社も追加工数を説明しやすく、発注側も社内で判断しやすくなります。特に500万円以上の開発や、3部署以上が関わる案件では、口頭合意だけで進めず、変更管理表を共有しておく方が安全です。
GXOの発注前レビューで見る実務メモ
GXOが見積書の相談を受けるときは、最初から「高い」「安い」を判定せず、見積の前提を分解します。まず初期費用、月額費用、追加費用、発注側作業、リスク項目の5区分に分けます。そのうえで、3社比較、5年TCO、社内稟議、契約条件の順に確認します。これにより、金額の差が価格差なのか、範囲差なのか、リスクの見込み方の差なのかを説明しやすくなります。
発注側で用意しておくとよいのは、完璧な要件定義書ではありません。現行業務の流れ、利用者数、画面・帳票・連携の数、希望時期、予算の幅、社内決裁者、止められない業務、個人情報や機密情報の有無です。これらが曖昧なまま見積を取ると、開発会社ごとに前提が変わり、相見積もりの比較が難しくなります。
| 確認領域 | 発注側が用意する情報 | 見積で確認すること |
|---|---|---|
| 業務範囲 | 対象部署、利用者数、現行フロー | どこまでが開発対象か |
| 機能規模 | 画面数、帳票数、API本数 | 工数の根拠が説明できるか |
| データ | 移行対象、件数、クレンジング要否 | 移行費・移行リハーサルの有無 |
| 運用 | 利用時間、障害時の影響、社内担当 | 保守範囲、SLA、月額費用 |
| 契約 | 請負/準委任、検収、知財、再委託 | 責任分界と追加費用の条件 |
| 稟議 | 予算上限、比較対象、判断基準 | 3社比較や5年TCOで説明できるか |
この整理を先に行うと、AI開発、セキュリティ要件、補助金活用を含む案件でも、見積の前提を同じ粒度にそろえやすくなります。特に補助金を使う場合は、対象経費と対象外経費、発注前着手の可否、証憑の残し方を見積段階で確認しておく必要があります。
追加費用の判断では、金額だけでなく発生頻度も見ます。1回限りの30万円なのか、毎月5万円の追加運用なのかで、稟議への影響は変わります。仕様変更が10件以上出そうな案件では、都度見積よりも月次で変更一覧を確認する運用にした方が、判断の遅れを抑えやすくなります。
実務では、見積書の1行だけで判断せず、議事録、提案書、契約書、メール回答を合わせて読みます。見積書に書かれていない前提でも、提案書に「別途」と書かれていれば追加対象になります。逆に、口頭で含むと言われた内容も、契約前に文書で残しておかないと、担当者変更後に確認が難しくなります。発注前の30分で前提を文書化するだけでも、後工程の手戻りは減らせます。
さらに、見積確認の結果は「採用する/しない」だけで終わらせず、未確認事項リストとして残します。未確認事項が5件以内なら契約前の確認で解消しやすいですが、10件以上残る場合は、見積比較より先に要件整理やRFP作成へ戻る判断も必要です。
この段階で判断に迷う場合は、発注ではなく見積レビューだけを先に行い、1週間以内に不足情報をそろえる進め方もあります。
参考にすべき一次情報・確認観点
見積書を社内稟議やベンダー比較に使う場合は、一般論だけで判断せず、公式資料と自社データを照合してください。特に契約形態、責任分界、DX投資の目的、セキュリティ要件は、見積金額より前にそろえるべき前提です。
- IPA「情報システム・モデル取引・契約書」：請負、準委任、成果物、検収、責任分界を確認する際の参考になります。
- 経済産業省「DX推進指標」：経営課題、ITシステム、組織体制を分けて、DX投資の目的を確認する際の参考になります。
- 自社の見積比較では、3社比較、5年TCO、月額5万円・10万円・15万円、画面20件、帳票10件、API3本、移行データ1000件、受入テスト5日、操作研修2回、障害受付24時間、初期予算500万円・1000万円など、仮でも数字を置いて前提をそろえます。
- AI開発、セキュリティ要件、補助金活用を含む案件では、機能要件だけでなく、ログ保管、個人情報、権限管理、証跡、補助対象経費の切り分けも見積条件に入れてください。
よくある質問
Q. 追加費用は必ず発生しますか。
A. 必ず発生するわけではありませんが、仕様変更や前提のずれによって生じることはあります。見積段階で「追加が出やすいのはどこか」「発生する条件は何か」を確認しておくと、後の認識のずれと交渉を抑えられます。
Q. 「別途協議」とだけ書かれた項目は、どう扱えばよいですか。
A. 条件や単価の考え方を、見積段階で確認しておくのが安全です。協議のたびに交渉から始めると判断が遅れるため、どういう場合に・どう見積もるか、という流れを先に決めておくとスムーズです。
Q. 追加費用に備えるには、どうすればよいですか。
A. 一定の予備費を予算に見込む方法と、変更が出るたびに都度見積もる方法があります。要件がまだ動く可能性があるなら、予備費を見込んでおくほうが、途中で予算が不足する事態を避けやすくなります。
まとめ
追加費用は、不当な請求というより、見積時点で確定していなかった作業が後から表面化することで生まれます。仕様変更・外部連携・データ移行・帳票・権限・テストという典型項目を知り、見積段階で「含まれているか」「追加になる条件は何か」を確認しておくことで、後の認識のずれと交渉を抑えられます。次回は、本番化に必要でありながら見落とされやすい「テスト・移行・教育費」を扱います。
関連記事
システム開発の見積・相見積もりを整理しませんか
GXOでは、システム開発の見積書、相見積もり、要件定義、開発会社選定について、発注前の整理をご支援します。総額だけでなく、工数、保守範囲、追加費用、体制、契約条件まで確認し、自社に合う進め方を一緒に整理します。
※ 初回相談では、営業資料の説明よりも見積内容と発注前の論点整理を優先します。