追加費用は見積書の外から来る｜発注後に金額が増える3つの原因

システム開発で、発注側も開発側も嫌な言葉があります。

「こちらは追加費用になります」

発注側からすると、「え、最初から必要だと思っていたんだけど」です。

開発側からすると、「いや、それは最初の見積りに入っていません」です。

これ、どちらかが悪意を持っているとは限りません。

普通に起きます。

自分も15年間システム開発をやってきて、ココナラでも販売実績270件まで対応してきましたが、追加要望そのものが悪いと思ったことはありません。

むしろ実物を見て初めて気づくことはかなりあります。

問題は、追加が出たことではなく、「追加が出たときの扱い」を決めずに始めていることです。

以前の自分はここが甘くて、「これくらいなら入れておこう」をやりすぎました。

一つひとつは小さいんですよね。項目を1個増やす、表示を少し変える、出力形式を足す。

でも、それが積み重なると普通に別機能になります。

はい。

無料修正のつもりが、気づけば仕様追加祭りです。

自分で見積りを出して、自分で苦しくなる。なかなか芸術点が高いです。

そこから、追加費用が発生しやすい原因をかなり意識するようになりました。

大きく分けると3つあります。

■ 原因1　作業範囲が「機能名」だけで決まっている

たとえば「請求管理システムを作る」という依頼があったとします。

この一文では、見積りできそうで、実はできません。

請求内容を入力する。

PDFを出す。

一覧で検索する。

承認する。

差し戻す。

添付資料を付ける。

CSVを出す。

支払済みにする。

全部「請求管理」の中に入ります。

しかも、利用者が1種類なのか、管理者と一般ユーザーに分かれるのかで変わります。

スマホ対応が必要か、PCだけでいいかでも変わります。

自分が相談を受けたときも、最初の一言だけでは作業量を決めません。

「入力」「確認」「出力」「権限」「例外」「納品後」のように分けて聞きます。

ここを飛ばして「だいたい○万円です」とやると、後で抜けが出ます。

発注側としては、見積書に書いてある機能名を読むだけではなく、「この機能の中にどこまで含まれますか」と聞くのが大事です。

■ 原因2　実際の運用ルールが後から出てくる

システム開発で一番厄介なのは、コードではなく運用ルールだったりします。

誰が入力するのか。

誰が確認するのか。

確定後に直せるのか。

間違えたら誰が戻すのか。

同じデータが2回来たらどうするのか。

こういう話です。

依頼者側も、最初から全部説明できるとは限りません。

普段は当たり前にやっているので、わざわざ説明する項目だと思っていないこともあります。

たとえば「日付順に並べる」だけでも、同じ日付が複数ある場合はどうするのか、空欄は上か下か、締め後のデータは対象にするか、など細かい話が出ます。

開発者が勝手に決めると、「うちではそういう運用じゃない」となります。

これ、技術的には正しく動いているのに、現場では使えないという一番悲しいパターンです。

自分は業務システムを作るとき、既存のExcelやCSV、現在の作業手順をなるべく見せてもらうようにしています。

言葉で聞くだけより、現物を見る方が圧倒的に早いからです。

「この列、実は手入力なんです」

「このファイルだけ月末に別担当が直します」

こういう情報が後から出ると、仕様が変わります。

■ 原因3　「修正」と「仕様変更」が混ざっている

ここは本当に揉めやすいです。

ボタンを押すとエラーが出る。

これは不具合です。

最初は1人承認だったけど、運用してみたら3人承認にしたい。

これは仕様変更です。

ただ、発注側から見るとどちらも「直してほしい」なんですよね。

さらに厄介なのが、見た目は小さい変更でも裏側が大きいケースです。

入力項目を1個追加するだけでも、保存先、一覧表示、検索、CSV、PDF、既存データとの互換性まで影響することがあります。

画面の1文字だけ見れば小さい。

システム全体で見ると小さくない。

自分も昔は「1項目くらいなら」と受けて、関連箇所を全部直すことになったことがあります。

それが何回か続いてから、仕様変更は仕様変更として切り分けるようになりました。

最近は、追加対応が発生したら、元の依頼と分けて見積りを出すこともあります。

その方が、何にお金がかかっているか双方で分かります。

■ 追加費用をゼロにするより「増えるルール」を決める

ここが一番伝えたいところです。

システム開発で、最初から全部を100％決めるのはかなり難しいです。

特に業務システムは、画面を見てから気づくことがあります。

だから「追加費用が一切出ない契約」を目指すより、追加が出たときのルールを決める方が現実的です。

自分なら、発注前に次を確認します。

・今回の作業範囲

・対象外になる内容

・不具合修正の扱い

・軽微な調整の範囲

・仕様変更時の見積方法

・納期が変わる条件

これがあるだけで、「言った・言わない」がかなり減ります。

■ 安い見積りが悪いわけではない。でも安い理由は見た方がいい

もちろん、安く作れるならその方がいいです。

自分も依頼する側なら安い方がうれしいです。

ただ、20万円と40万円の見積りがあったとき、20万円の方が必ずお得とは限りません。

40万円側には、データ移行、テスト、本番反映、マニュアル、保守まで入っているかもしれません。

20万円側は開発だけかもしれません。

ここを確認せずに比較すると、最終的な支払額では逆転することがあります。

総額ではなく、「同じ条件にそろえて比較する」。

これが大事です。

■ 見積書にないものを想像する

自分が見積書を見るときは、書いてある内容より先に空白を見ます。

データ移行は？

既存環境との接続は？

スマホは？

納品後の不具合は？

追加修正は？

この「書いていないけど必要そうなもの」が、あとから費用になることが多いからです。

発注前に全部を見抜く必要はありません。

分からなければ、そのまま質問すれば大丈夫です。

自分は現役SEとして、システム開発の見積書や提案書を第三者目線で確認するサービスも始めています。

金額だけでなく、要件の抜け、追加費用が出そうな部分、ベンダーへ確認した方がいい質問まで整理します。

「この見積り、このまま発注して大丈夫かな」と思った段階で十分です。

■ 「追加費用が出るのは悪い会社」とは限らない

ここも少し補足しておきます。

追加費用が発生したからといって、その開発会社が悪いとは限りません。

最初の要件から本当に増えたのであれば、追加見積りになるのは自然です。むしろ、作業が増えているのに何も説明せず進める方が、後から別の問題が出ることもあります。

自分が見るのは「追加費用があるか」ではなく、「なぜ追加なのかを説明できるか」です。

当初の範囲はここ。

今回増えた要望はここ。

この変更で影響するのはここ。

だからこの金額になる。

ここまで説明されれば、発注側も判断できます。

逆に「それは追加です」だけだと、納得しにくいですよね。

発注時には、変更が出たら作業着手前に金額を確認するルールにしておくのもおすすめです。先に作って、後から請求額を知る形は避けた方がいいです。

自分も追加対応を別見積りにする場合は、元の範囲と何が変わったかをできるだけ分けて伝えるようにしています。面倒そうに見えますが、結局それが一番早いです。

システム開発の見積りチェックはこちら

#システム開発

#追加費用

#見積り

#IT外注