「ちょっとした変更だから無料でやってくれるよね」とベンダーに伝えた瞬間から、トラブルは始まります。中小企業のシステム開発で発生する仕様変更トラブルには、経営者側の言動に共通点があります。本記事では仕様変更でベンダーともめる経営者の3つの共通点と、トラブルを防ぐための発注時合意事項を経営者目線で解説します。
この記事の結論（3行）
- もめる経営者には「契約後の変更は無料」「現場の声を都度反映」「追加見積もりを値切る」の3共通点がある
- 仕様変更1件あたり20〜100万円が標準で、安易な変更要求は総額を1.5〜2倍に膨らませる
- 発注時に「変更管理ルール」を文書化しておけば、トラブルの大半は防げる
なぜシステム開発の仕様変更でトラブルになるのか
中小企業のシステム開発では、契約後の仕様変更でベンダーともめる現象が頻発します。「これくらいなら無料でやってくれると思った」「追加見積もりが高すぎる」「変更したのにスケジュールが延びるのはおかしい」——こうした経営者の言動が、ベンダーとの関係を壊しプロジェクトを停滞させていきます。
- 契約後の変更は無料で対応してもらえると思い込んでいる
- 現場から上がってきた要望を都度ベンダーに流す
- 追加見積もりに対して「高すぎる」と値切り交渉する
仕様変更はシステム開発で避けられない事象ですが、扱い方を間違えるとプロジェクト全体が崩壊します。経営者の意識1つで、円滑に進むか泥沼化するかが分かれます。
契約後の変更は無料で対応してもらえると思い込んでいる
最も多いトラブル要因が、「契約後の仕様変更も契約金額の範囲内」と思い込んでいる経営者です。建築工事と同じ感覚で「ちょっとした修正なら追加費用なし」と発言してしまうと、ベンダー側は「仕様外の作業をタダで要求された」と感じます。この認識のズレが、関係悪化の起点になります。
現場から上がってきた要望を都度ベンダーに流す
現場担当者から「この画面にもボタンを追加して」「色を変えて」という要望が上がるたびに、経営者がベンダーに直接伝えてしまうパターンです。整理されないまま要望が流れると、ベンダーは「結局何が確定仕様か」がわからなくなり、開発が止まります。要望は社内で集約してから渡すのが原則です。
追加見積もりに対して「高すぎる」と値切り交渉する
仕様変更の追加見積もりが届いたときに「高すぎる」と値切るパターンも、トラブルの典型です。ベンダーは追加分の工数を見積もっているため、値切られると工数を削るしかなく、品質が下がります。値切りが繰り返されると、ベンダーは「割に合わない発注者」と判断し、リソースを他案件に回します。
仕様変更トラブルになる経営者の3つの共通点
仕様変更でベンダーともめる経営者の共通点を、3つのパターンで整理します。
| 共通点 | 起きるトラブル | 影響 | |---|---|---| | 「無料で当然」発想 | ベンダーとの関係悪化 | プロジェクト停滞 | | 要望の都度伝達 | 仕様が確定しない | 開発スケジュール崩壊 | | 追加見積もり値切り | 品質低下・人員削減 | リリース後のバグ多発 |
この3つは独立して発生するわけではなく、組み合わさって「仕様変更トラブルの連鎖」を生みます。発注時に1つずつ整理しておくことで、トラブルの大半は防げます。自社のベンダー管理に共通点がないか業務改善・システム見積もりAI適正診断で確認できます。
共通点1: 「無料で当然」発想
「契約金額に含まれているはず」「これくらいの変更は無料でしょう」という発想は、最もトラブルを生む要因です。システム開発契約は、要件定義書に基づく仕様で見積もりされており、それ以外の作業は追加見積もり対象です。「無料で当然」発想を持つ経営者とは、ベンダーは長期的な関係を結びたがりません。
「変更は無料が当然」という認識は、社内向けの工事や買い物の感覚から来ていることが多くあります。しかしシステム開発は「設計図通りに作る」工程に近く、設計図そのものを変更するのは追加コストの対象になります。発注時にこの前提をベンダーと共有しておく必要があります。
共通点2: 要望の都度伝達
現場から上がる要望を整理せず、思いつくたびにベンダーに伝える経営者も、トラブルの温床です。ベンダー側は「先週の要望と今週の要望が矛盾している」「結局どの仕様で作ればいいかわからない」状態になり、開発が止まります。要望は社内で月1回など定期的に集約し、優先度を付けてから伝えるのが原則です。
「現場の声を即対応する」のは一見良いことに見えますが、整理されていない要望をそのまま流すと、システム全体の整合性が崩れます。要望を整理する役割を社内に置き、ベンダーへの窓口を1本化することで、開発がスムーズに進みます。
共通点3: 追加見積もり値切り
仕様変更の追加見積もりに対して「高すぎる」と値切るパターンは、ベンダーとの関係を悪化させます。ベンダーは追加分の工数を見積もって金額を出しており、値切られると工数を削るしかなく、品質が下がります。リリース後にバグが多発する原因の1つは、値切りによる品質低下です。
追加見積もりが妥当かどうかを判断するには、「工数の根拠」を聞くのが正しいやり方です。「人月いくらで何人月分の追加か」を確認し、相場と乖離していなければ受け入れる。乖離していれば工数の見直しを依頼する。値切るのではなく根拠を確認する姿勢が、ベンダーとの信頼関係を維持します。
仕様変更のコスト構造を分解する
仕様変更が発生した場合のコストはどう積み上がるか分解します。
中小企業のシステム開発で発生する仕様変更1件あたりの追加コスト構造は、要件再整理が0.5〜1人月（30〜80万円）、追加開発が1〜3人月（60〜240万円）、再テストが0.5〜1人月（30〜80万円）、合計で1件20〜100万円が標準です。
問題は、仕様変更が1件で終わらず連鎖することです。1つの仕様を変更すると、それに伴って関連する別の仕様も変更が必要になり、3〜5件の連鎖変更が発生します。1件20〜100万円が3〜5件積み重なれば、合計100〜500万円の追加費用です。当初500万円の見積もりが、仕様変更で1,000万円に膨らむケースは珍しくありません。
さらに深刻なのが、納期への影響です。仕様変更1件で2〜4週間の追加期間が必要で、連鎖変更が発生すると2〜3ヶ月の納期延長になります。リリース予定日に間に合わず、既存業務の継続コストが乗ります。月20〜50万円の人件費が、リリース延期期間中に毎月発生します。
経営者目線で考える「仕様変更を健全に扱う判断軸」
ここからは経営の話です。仕様変更を「悪」として扱うのではなく、「コストと納期に影響する経営判断」として扱うのが、健全なベンダー関係への入り口です。仕様変更ゼロは現実的ではないため、発生したときに健全に処理する仕組みを作っておく必要があります。
経営者が仕様変更を判断する視点は3つです。第一に、「いまリリースして後から改修」と「リリース前に変更を入れる」のコスト比較。リリース前に入れる方が安く済む変更もあれば、リリース後に入れた方が安く済む変更もあります。どちらが得かを判断するのが経営者の役割です。
第二に、変更要望を「業務が止まる」「業務が便利になる」「あれば嬉しい」の3段階で評価しているか。業務が止まる変更は最優先で入れる、業務が便利になる変更は次回フェーズへ、あれば嬉しい変更は却下、という整理が必要です。全ての要望を同列に扱うと、コストが青天井になります。
第三に、変更管理ルールを発注時に合意しているか。「変更要望はどう伝えるか」「追加見積もりの基準は何か」「承認は誰が行うか」を発注時に文書化しておけば、トラブルの大半は防げます。発注後にルールを作ろうとすると、その時点ですでにトラブルが発生していることが多くあります。
「仕様変更は経営判断」という認識を持つことが、ベンダーとの健全な関係の基盤になります。変更要求を出すのも止めるのも経営者の役割で、現場の声をそのまま流したり、ベンダーの追加見積もりを値切ったりするのは経営者の仕事ではありません。
ある小売業C社の場合：仕様変更で総額が1.8倍に膨らんだ事例
ぷらすわんに相談に来た小売業C社のケースをお伝えします。社員40名規模で、在庫管理と受発注を統合するシステムを600万円で発注しました。要件定義は2ヶ月かけて行い、ベンダーとの契約も適切に進めたのですが、開発開始後に現場から次々と要望が上がりました。
経営者は「現場の声を大事にしたい」という思いで、要望を全てベンダーに流しました。3ヶ月で12件の仕様変更要求があり、各20〜80万円の追加見積もりが出されました。経営者は「高すぎる」と感じて全件を値切り交渉し、最終的に8件を採用、合計400万円の追加費用が発生しました。当初600万円が1,000万円に膨らみ、納期は3ヶ月延びました。
ぷらすわんが入って整理した結果、原因は「要望を整理せずに流していた」ことと「変更管理ルールがなかった」ことだとわかりました。本来は、要望を社内で月1回集約し、優先度を付けてからベンダーに渡すべきでした。さらに、変更管理ルールを発注時に合意しておけば、値切り交渉のような不毛なやり取りも不要だったはずです。
C社にはその後、変更管理ルールを再合意し、要望集約の社内担当者を1名置く体制を整えました。次のフェーズ開発では、仕様変更が3件に減り、追加費用は80万円に収まりました。仕様変更の扱いを経営判断として整理することで、コストの膨張は大幅に抑えられます。手元のプロジェクトで変更管理に懸念がある場合は診断することで、ルール整備の出発点を確認できます。
仕様変更トラブルを防ぐ5つの実践
最後に、システム開発で仕様変更トラブルを防ぐための、5つの実践的なポイントをお伝えします。
- 発注時に「変更管理ルール」を文書化する
- 変更要望は社内で集約してから伝える
- 追加見積もりは「工数根拠」を確認する
- 要望を3段階の優先度で評価する
- リリース後の改修フェーズを最初から計画に入れる
この5つは、いずれも発注時から運用までのベンダー関係を健全に保つ項目です。発注後に整えようとすると、すでにトラブルが発生していることが多く、修復に時間がかかります。
発注時に「変更管理ルール」を文書化する
発注契約と同時に、変更管理ルールを文書化してください。「変更要望はメールで○○宛に提出」「追加見積もりは○営業日以内に提示」「承認は経営者または担当役員が行う」など、シンプルなルールで構いません。発注時に合意しておくことで、運用開始後のトラブルが大幅に減ります。
変更要望は社内で集約してから伝える
現場から上がる要望を社内の窓口で集約し、月1回など定期的にベンダーに伝える運用にしてください。要望集約担当者を1名置き、優先度・影響範囲・代替案を整理してから渡すと、ベンダーの混乱も減り、開発がスムーズに進みます。
追加見積もりは「工数根拠」を確認する
追加見積もりが届いたら、値切るのではなく工数根拠を確認してください。「人月いくらで何人月分か」「どの作業にどれだけ時間がかかるか」を聞き、相場と乖離していなければ受け入れる。乖離していれば工数の見直しを依頼する。この姿勢がベンダーとの信頼関係を維持します。発注時に追加開発の単価を整理する場合は項目別に整理してから契約するのが安全です。
要望を3段階の優先度で評価する
社内で集約した要望を「業務が止まる」「業務が便利になる」「あれば嬉しい」の3段階に分けてください。業務が止まる要望は最優先、便利機能は次フェーズ、あれば嬉しい要望は却下、という方針で進めると、コストが青天井にならずに済みます。
リリース後の改修フェーズを最初から計画に入れる
仕様変更ゼロは現実的ではないため、リリース後3〜6ヶ月の「改修フェーズ」を最初から計画に入れてください。リリース後に発覚する課題を、このフェーズでまとめて改修する方が、開発中に都度変更を入れるより安く済みます。リリース後改修の予算を初期予算の20〜30%確保しておくのが標準的です。
まとめ
システム開発の仕様変更でベンダーともめる経営者には、「無料で当然」発想・要望の都度伝達・追加見積もり値切りという3つの共通点があります。ベンダーの問題ではなく、発注者側の変更管理の問題です。仕様変更1件あたり20〜100万円が標準で、安易な変更要求は総額を1.5〜2倍に膨らませます。
経営者が変更管理ルールを発注時に合意し、要望を社内で集約してから伝える姿勢を持てば、トラブルの大半は防げます。ベンダー関係を健全に保ちたい経営者の方は、現状を比較を依頼する流れで整理してから次のフェーズに進むのがお勧めです。