追加費用請求に怯えないために。契約前に握っておくべき「変更管理」のルール
「追加費用が発生します」という言葉への恐怖
「仕様変更があったので、追加で200万円かかります」
「当初の見積もりには含まれていない機能なので、別途費用が必要です」
「この修正は契約範囲外なので、追加工数として請求させていただきます」
システム開発を外注した経験のある方なら、このような言葉に冷や汗をかいた経験があるのではないでしょうか。
追加費用の請求は、開発会社との関係を悪化させる最大の原因の一つです。
発注側は「言っていたことと違う」「なぜ最初に言ってくれなかったのか」と不信感を抱き、開発会社側は「要望が変わったのだから当然だ」と主張する。
この溝が埋まらないまま、プロジェクトは険悪なムードで進み、最悪の場合は途中で頓挫してしまいます。
しかし、追加費用トラブルの多くは、契約前の「変更管理ルール」の取り決めが曖昧だったことが原因です。
つまり、契約前に適切なルールを握っておけば、追加費用に怯える必要はなくなるのです。
本記事では、非エンジニアの起業家やスタートアップ創業者に向けて、契約前に確認・合意すべき変更管理のルールを詳しく解説します。
なぜ「追加費用」は発生するのか？その仕組みを理解する
「そもそも、なぜ追加費用が発生するの？最初の見積もりは何だったの？」
そう思われる方も多いでしょう。まずは、追加費用が発生する仕組みを理解しましょう。
システム開発の見積もりは「仮定」に基づいている
システム開発の見積もりは、プロジェクト開始時点での「仮定」に基づいて算出されています。
- 画面は10画面程度
- ユーザー登録機能は〇〇の仕様
- 外部連携はA社のAPIのみ
- 管理画面は基本的なCRUD機能
これらの仮定が契約後に変わると、当初の見積もりの前提が崩れることになります。
「仕様変更」と「仕様の明確化」の境界線
追加費用トラブルで最も揉めるのが、**「これは仕様変更なのか、仕様の明確化なのか」**という問題です。
発注側の主張： 「この機能が必要なのは当然でしょう。最初から言っていたつもりです」
開発会社の主張： 「その機能は聞いていません。追加の要望です」
この認識のズレは、「言った・言わない」の水掛け論に発展しがちです。
追加費用が発生する典型的なパターン
追加費用が発生する典型的なパターンを整理すると、以下のようになります。
① 機能の追加
- 当初の要件にはなかった新しい機能を追加したい
- 例：「やっぱりSNSログイン機能も欲しい」
② 機能の変更
- 決定済みの仕様を変更したい
- 例：「一覧画面の表示項目を5つから10に増やしたい」
③ 仕様の後出し
- 当初の要件定義で詰め切れていなかった詳細を後から指定
- 例：「この入力項目はリアルタイムでバリデーションしてほしかった」
④ 外部要因による変更
- 連携先のAPI仕様変更や法改正など
- 例：「連携先のサービスがバージョンアップして仕様が変わった」
⑤ 手戻り
- 確認済みの成果物に対してやり直しを依頼
- 例：「やっぱりデザインを全面的に変えたい」
これらのパターンを理解した上で、どのケースでどう対応するかを契約前に決めておくことが重要です。
変更管理とは何か？基本を押さえる
変更管理の基本
「変更管理」という言葉は、ITプロジェクトでは一般的に使われる用語です。ここでは、非エンジニアの方にもわかりやすく解説します。
変更管理の定義
**変更管理（チェンジマネジメント）**とは、プロジェクトの途中で発生する仕様変更や要件追加を、体系的に管理・制御する仕組みのことです。
具体的には、以下のプロセスを指します。
- 変更要求の受付 - 「こう変えたい」という要望を正式に受け付ける
- 影響範囲の分析 - その変更が他の機能やスケジュールに与える影響を調査
- 見積もり・判断 - 追加費用や納期延長の必要性を算出し、実施可否を判断
- 承認プロセス - 発注者が費用・納期を確認した上で正式に承認
- 変更の実施 - 承認後に実際の変更作業を行う
- 記録・管理 - 変更内容を文書化して管理する
変更管理がないとどうなるか
変更管理のルールがないプロジェクトでは、以下のような問題が起こります。
- 口頭での依頼が積み重なり、誰が何を依頼したかわからなくなる
- 「これくらいは含まれているだろう」という思い込みでトラブルになる
- 開発会社が勝手に判断して追加作業を行い、後から請求される
- 発注者が気軽に変更を依頼し続け、スケジュールが破綻する
- 「言った・言わない」の水掛け論で関係が悪化する
逆に言えば、変更管理のルールを契約前に握っておけば、これらの問題は大幅に軽減できるのです。
契約前に握っておくべき「変更管理」の7つのルール
変更管理の7つのルール
ここからは、契約前に開発会社と合意しておくべき7つの変更管理ルールを具体的に解説します。
ルール1：「変更」の定義を明確にする
まず最も重要なのが、「何をもって仕様変更とするか」の定義を明確にすることです。
契約書・要件定義書に明記すべき事項
- 仕様変更の定義：要件定義書に記載されていない機能の追加、または記載内容と異なる仕様への変更
- 仕様明確化の定義：要件定義書に記載された内容の詳細化であり、工数に影響しないもの
- バグ修正の定義：要件定義書の記載通りに動作しない不具合の修正
ポイント
「要件定義書に書かれているかどうか」を判断基準にするため、要件定義書の品質が重要になります。
曖昧な表現（「使いやすい画面」「高速な処理」など）は避け、具体的な仕様を記載してもらいましょう。
ルール2：変更要求の「正式な手続き」を決める
「ちょっとこれ変えてほしいんですけど」
口頭やチャットでの気軽な依頼が、後々のトラブルの元になります。変更要求の正式な手続きを決めておきましょう。
決めておくべきこと
- 変更要求の提出方法：専用フォーム、メール、課題管理ツールなど
- 変更要求に含める情報：変更内容、変更理由、希望納期、優先度など
- 受付確認の方法：開発会社からの受領連絡の期限
推奨される手続き
1. 発注者が「変更要求書」を書面（メール可）で提出
2. 開発会社が2営業日以内に受領確認
3. 開発会社が5営業日以内に影響分析・見積もりを回答
4. 発注者が承認または却下を通知
5. 承認後に変更作業を開始
口頭での依頼は「正式な変更要求」として認めないというルールにしておくと、トラブルを防げます。
ルール3：変更時の「見積もり方法」を合意する
追加費用でトラブルになるのは、**「見積もりの根拠がわからない」**ことが原因であることが多いです。
合意しておくべき見積もり方法
① 単価の明示
- エンジニアの工数単価（1人日あたり〇〇円）を契約書に明記
- 役割別の単価（PM、SE、PGなど）も明示
② 見積もりの内訳開示
- 変更ごとに工数の内訳を提示してもらう
- 「設計〇〇時間、開発〇〇時間、テスト〇〇時間」のように
③ 最小見積もり単位
- 1時間単位か、0.5人日単位か、1人日単位か
- 単位が大きいと小さな変更でも高額になる
契約書への記載例
仕様変更が発生した場合、乙（開発会社）は変更内容の影響範囲を分析し、追加工数を「作業内容別の時間内訳」とともに提示するものとする。追加費用は、別紙に定める工数単価に基づき算出する。
ルール4：変更の「承認プロセス」を決める
見積もりが出た後、誰がどのように承認するかを決めておくことも重要です。
決めておくべきこと
- 承認者：誰が変更を承認する権限を持つか（代表者、PM、担当者など）
- 承認期限：見積もり回答から何営業日以内に承認・却下を通知するか
- 承認方法：書面（メール可）での明示的な承認が必要か
- 未回答時の扱い：期限内に回答がない場合はどうするか
重要なポイント
「黙認」は承認とみなさないというルールを入れておきましょう。
「返事がないから進めました」という開発会社側の主張、「承認した覚えはない」という発注者側の主張、どちらのトラブルも防げます。
ルール5：「軽微な変更」の取り扱いを決める
すべての変更に対して正式な手続きを踏むと、プロジェクトの進行が遅くなります。軽微な変更の取り扱いを別途決めておきましょう。
軽微な変更の定義例
- 追加工数が〇〇時間（例：4時間）以内の変更
- UIの微調整（色、文言、配置の軽微な変更）
- バグ修正に付随する軽微な改善
取り扱いの選択肢
① バッファ方式
- 当初見積もりに「変更対応バッファ」として〇〇%（例：10%）を含めておく
- バッファ内の軽微な変更は追加費用なし
- バッファを超えた分から追加費用発生
② 回数制限方式
- 納品までに〇〇回（例：5回）までの軽微な変更は無償
- 6回目以降から追加費用発生
③ 都度精算方式
- 軽微な変更も含め、すべて都度見積もり・承認
- 手間はかかるが、透明性は最も高い
ルール6：変更による「スケジュール影響」を明確にする
追加費用だけでなく、納期への影響も明確にしておく必要があります。
合意しておくべきこと
- 納期延長の可否：変更が発生した場合、納期延長を認めるか
- 延長日数の算出方法：追加工数に応じて自動的に延長か、都度協議か
- 延長できない場合の対応：納期固定の場合、他の機能を削減するなど
注意点
「納期は変えられないが、機能は追加したい」という要望は、開発チームに過剰な負荷をかけることになります。
納期・コスト・スコープ（機能範囲）は相互に関連しており、どれか一つを変えれば、他も調整が必要という原則を理解しておきましょう。
ルール7：変更履歴の「記録・管理方法」を決める
最後に、変更履歴をどのように記録・管理するかを決めておきましょう。
記録すべき情報
- 変更要求日
- 変更内容
- 変更理由
- 影響範囲
- 追加費用・追加工数
- 承認日・承認者
- 完了日
管理方法の選択肢
- スプレッドシート：シンプルだが共有・更新の管理が必要
- 課題管理ツール（Backlog、Jira、Asanaなど）：履歴が自動で残る
- 専用の変更管理台帳：大規模プロジェクト向け
どの方法でも、**「誰でも最新状況を確認できる状態」**にしておくことが重要です。
契約書に盛り込むべき「変更管理条項」のチェックリスト
ここまで解説したルールを、実際に契約書に盛り込む際のチェックリストをまとめます。
必須項目
- 仕様変更の定義
- 変更要求の提出方法と受付期限
- 見積もり回答の期限
- 工数単価と見積もり内訳の開示義務
- 承認者と承認方法
- 承認期限と未回答時の扱い
- 軽微な変更の定義と取り扱い
- スケジュール変更時の対応
推奨項目
- 変更対応バッファの設定
- 変更履歴の管理方法
- 変更要求のテンプレート
- 変更頻度の上限（月〇〇件までなど）
- 緊急変更時の特別対応
こんな方は特に変更管理を重視してください
以下に当てはまる方は、変更管理のルールを特に重視して契約を結ぶことをおすすめします。
-
初めてシステム開発を外注する → 何が「仕様変更」になるかの感覚がないため
-
要件が固まりきっていない状態で開発を始める → 開発途中で変更が発生する可能性が高いため
-
アジャイル開発を採用する → 仕様変更が前提のため、費用の取り扱いを明確にする必要がある
-
過去に追加費用トラブルを経験した → 同じ失敗を繰り返さないために
-
予算に余裕がない → 想定外の追加費用が致命的になり得るため
技術的な知識がなくても、変更管理のルールを理解し、適切に契約に盛り込むことで、追加費用トラブルの大部分は防げます。
アトリエ・バイナリでは、「技術がわからないことで挑戦を諦める非エンジニア起業家をゼロにする」というビジョンのもと、こうした契約面でのアドバイスも行っています。開発会社との契約内容に不安がある場合は、お気軽にご相談ください。
まとめ：契約前の「変更管理ルール」が追加費用トラブルを防ぐ
変更管理のまとめ
本記事では、システム開発における追加費用トラブルを防ぐための「変更管理ルール」について解説しました。
重要ポイントのおさらい
追加費用が発生する原因を理解する
システム開発の見積もりは「仮定」に基づいており、仕様変更があれば追加費用が発生するのは当然のこと。問題は、その取り扱いが曖昧なことにあります。
契約前に握っておくべき7つのルール
- 「変更」の定義を明確にする - 要件定義書を基準に
- 変更要求の「正式な手続き」を決める - 口頭依頼は認めない
- 変更時の「見積もり方法」を合意する - 単価と内訳を明示
- 変更の「承認プロセス」を決める - 黙認は承認とみなさない
- 「軽微な変更」の取り扱いを決める - バッファ方式などを検討
- 変更による「スケジュール影響」を明確にする - 納期・コスト・スコープの関係を理解
- 変更履歴の「記録・管理方法」を決める - 誰でも確認できる状態に
追加費用に怯えながら開発を進めるのは、発注者にとっても開発会社にとっても不幸なことです。
契約前に変更管理のルールを明確にしておくことで、お互いの期待値を合わせ、健全なプロジェクト運営が可能になります。
「この変更は費用がかかるのか、かからないのか」が明確になれば、安心して必要な変更を依頼できるようになります。
これからシステム開発を外注する方は、ぜひ本記事のチェックリストを活用して、契約交渉に臨んでください。正しい知識を持って契約を結ぶことが、あなたのビジネスを守る第一歩です。
