システム開発で追加作業が止まらない。「追加費用を請求できるか」より先に経営者が決めるべきこと

2026.08.13

「この機能も追加してほしい」

「ここも少し変更してほしい」

システム開発では、プロジェクトが進むにつれて顧客から追加要望が出ることがあります。

営業としては、大切な顧客からの依頼です。

しかも次の案件も期待できる。

そうなると、

「今回はサービスで対応しましょう」

という判断をしてしまうことがあります。

ところが、その「少しだけ」が積み重なり、気がついたときには数千万円の赤字になっている。

私は、この問題の本質は「追加費用を請求できるか」だけではないと考えます。

本当に怖いのは、顧客から追加要求が出るたびに、価格も納期も決めないまま開発を続ける会社になってしまうことです。

相談事例

ある業務システム開発会社が、大手製造業から生産管理システムを受注しました。

契約金額は1億2,000万円。

会社にとって過去最大級の案件です。

契約当初の開発原価は約8,500万円を予定していました。

ところが開発開始後、顧客から追加要求が次々に出始めます。

• スマートフォン対応
• 多言語対応
• BIダッシュボード
• 外部システムとの追加連携
• 権限管理機能の拡張

営業担当者は、今後の取引を考え、正式な追加見積を出さないまま、

「対応可能です」

「こちらで吸収します」

「まず実装を進めます」

と回答していました。

その結果、開発原価は約1億4,500万円まで膨らむ見込みとなりました。

予想される赤字は約4,000万円。

会社全体の年間営業利益は約3,600万円です。

つまり、この案件一つで年間利益がほぼ消える規模の問題になったのです。

この問題の本質

私は、この問題の本質は契約書の不備だけではないと考えます。

もちろん、仕様変更時の追加費用や納期変更の手続を契約書で明確にしていなかったことは問題です。

しかし、もっと大きな問題があります。

それは、

「営業が約束する → 開発が対応する → 原価が膨らむ → 最後になって経営者が知る」

という仕事の進め方です。

この構造を変えなければ、今回の4,000万円を何とか回収できても、次の大型案件で同じことが起こります。

よくある失敗① 大口顧客だから最後まで無償対応する

営業部からは、こんな意見が出るかもしれません。

「ここで揉めたら次の案件がなくなります。」

確かに、大口顧客との関係は重要です。

しかし、だからといって赤字を無制限に受け入れてよいわけではありません。

特に危険なのが、

「今回4,000万円損しても、次の1億円案件で取り返せばいい」

という考え方です。

次の案件は、まだ受注していません。

さらに、今回の対応によって、

「追加要求をしても無料で対応してくれる会社」

という認識を顧客側に作ってしまえば、次の案件でも同じ問題が起きる可能性があります。

売上を増やすことと、利益を残すことは別です。

よくある失敗② 追加費用を払うまで全部止める

反対に、

「追加費用3,500万円を払わないなら、今日から開発を止めます」

と全面停止するのも危険です。

なぜなら、すべての作業が追加開発とは限らないからです。

当初の契約で明確に約束した機能もあります。

本来対応すべき不具合修正もあります。

それらまで一律に停止すれば、今度は会社側の納期遅延や契約上の責任が問題になる可能性があります。

だから「全部やる」「全部止める」の二択にしてはいけません。

私なら、まず作業を4つに分けます

私なら、最初にすべての作業を次の4つに分類します。

1. 当初仕様として明確に約束しているもの
2. 当初仕様に対する不具合修正
3. すでに実施している追加開発
4. これから求められている追加開発

ここを混ぜないことが重要です。

特に4番目の「これから求められている追加開発」については、無条件での着手を止めます。

新しい要求が出たら、まず、

• 何を変更するのか
• 何人日必要なのか
• いくら追加になるのか
• 納期にどの程度影響するのか

を明確にします。

そのうえで顧客と合意してから着手します。

「追加請求3,500万円」だけで交渉しない

この段階で顧客へ、

「追加で3,500万円払ってください」

とだけ要求しても、交渉は難しいでしょう。

顧客からすれば、

「今まで追加料金の話をしていなかったのに、なぜ突然3,500万円なのか」

となるからです。

私なら、追加要求を機能単位まで分解します。

例えば、

• スマートフォン対応：追加○万円、納期＋○週間
• 多言語対応：追加○万円、納期＋○週間
• BI機能：今回納品から除外
• 追加システム連携：第2フェーズへ移行

という形です。

価格だけではなく、「機能・価格・納期」をセットで交渉します。

顧客側も一枚岩とは限らない

今回のようなケースでは、顧客側の現場担当者と購買部で意見が違うことがあります。

現場は、

「確かにかなり追加要求した」

と理解している。

一方、購買部は、

「契約金額は1億2,000万円でしょう」

と主張する。

ここで「A社が払ってくれない」と一括りにすると、交渉材料を失います。

誰が何を要求したのか。

その要求によって工数がどれだけ増えたのか。

顧客側の誰がその必要性を理解しているのか。

これを整理して交渉する必要があります。

現場の退職リスクは4,000万円とは別に考える

このケースで私が特に危険だと思うのは、開発現場の疲弊です。

すでに中心エンジニア2名から、

「この案件が終わったら辞めたい」

という話が出ています。

経営者としては、

「納期まであと5週間だから頑張ってほしい」

と言いたくなるかもしれません。

しかし、それで納品できても、優秀なエンジニアが退職すれば次の案件を回せません。

プロジェクトを守るために、会社の生産能力そのものを失ってはいけません。

だから私は、顧客交渉とは別に、現場へ投入する人員と残業の上限も決めます。

営業部長を処分すれば解決するのか

今回、営業部長にも大きな問題があります。

追加見積を出さず、開発部から警告を受けても作業を続けたからです。

しかし私は、最初に営業部長を降格させることを優先しません。

今の最優先課題は、誰が悪かったかを決めることではなく、これ以上損失を増やさないことだからです。

しかも社長自身が、

「A社だけは絶対に失うな」

というメッセージを出していたのであれば、営業部長だけの問題とも言い切れません。

責任検証は必要です。

ただし順番を間違えてはいけません。

最善策

私なら次の順番で進めます。

1. 新たな無償追加作業を止める
2. 当初契約上やるべき作業は継続する
3. 仕様書・メール・議事録などを整理する
4. 追加機能ごとの工数と原価を算定する
5. 完成までの最大損失を確定する
6. 顧客と機能・価格・納期を再交渉する
7. エンジニアの投入上限を決める
8. 社内の仕様変更ルールを作り直す

ここで重要なのは、追加料金を最大限取ることではありません。

これ以上、赤字が無制限に膨らまない境界線を作ることです。

契約書だけ直しても再発する

もちろん、今後の契約書では仕様変更手続を明確にする必要があります。

例えば、仕様変更が発生した場合には、

変更要求 → 工数算定 → 追加費用 → 納期への影響 → 双方承認 → 開発着手

という流れを決めておきます。

しかし、契約書だけ修正しても十分ではありません。

営業担当者が、

「お客様から頼まれたから、先にやっておいて」

と言えば開発が動く会社なら、同じことが起こります。

一定規模以上の仕様変更は、営業だけでは承認できない仕組みにする必要があります。

なぜ法律だけでは解決できないのか

このケースでは、追加費用を法的に請求できるかは重要です。

しかし、それだけでは経営判断になりません。

仮に追加料金を一部請求できたとしても、優秀なエンジニアが辞めれば会社は弱くなります。

反対に、顧客関係を守るために赤字をすべて飲めば、会社の年間利益が消えます。

さらに、無償追加が常態化すれば次の案件でも同じ問題が起きます。

法律上いくら請求できるかと、経営上どこまで仕事を続けるべきかは、分けて考える必要があります。

実務上のチェックポイント

• 当初仕様書は具体的になっているか
• 追加要求を記録しているか
• 誰が追加要求を承認したか分かるか
• 追加作業の工数を記録しているか
• 不具合修正と追加開発を区別しているか
• 営業担当者だけで仕様変更を受けていないか
• 変更時に追加見積を出しているか
• 変更による納期影響を顧客へ説明しているか
• プロジェクト原価を月次で確認しているか
• 赤字見込みが一定額を超えたら経営陣へ報告されるか
• 未着手の追加要求を把握しているか
• エンジニアの残業・疲弊を把握しているか
• 将来案件を理由に現在の赤字を放置していないか
• 仕様変更の承認フローが社内にあるか

まとめ

システム開発で追加要求が膨らんだとき、経営者は、

「追加費用を請求できるのか」

を考えます。

もちろん、それは重要です。

しかし私は、その前に決めることがあると考えます。

これ以上、どこまで会社の人とお金を投入するのか。

その境界線です。

まず新たな無償追加を止める。

次に、本来やるべき仕事と追加作業を分ける。

原価を確定する。

そして顧客と、価格だけではなく機能と納期も含めて交渉する。

短期・中期・長期を分けて考える必要があります。

短期では、損失拡大と現場疲弊を止める。

中期では、顧客との条件を再設定する。

長期では、営業だけで追加開発を約束できない会社に変える。

重要なのは、誰が悪かったかではなく、これ以上会社を傷つけないことです。

私は、このケースで本当に見直すべきなのは契約書だけではなく、

「営業が約束して、開発が無料で何とかする」という仕事の進め方そのもの

だと考えます。

※本記事は、経営判断を考えるための架空の事例をもとに作成しています。実際の追加報酬請求、仕様変更、検収、契約不適合、納期等の判断は、契約書、仕様書、見積書、議事録、メールその他の具体的な事実関係によって異なります。