システム開発契約書のトラブルを防ぐ！仕様変更のルールと注意点

発注者側から、「開発途中で仕様を少し変えてほしいとお願いしたら、追加費用を請求された」
受注者側から、「口頭でOKをもらったはずなのに、納品物が思っていたものと違った」
——システム開発の現場では、こうした仕様変更をめぐるトラブルが後を絶ちません。

私自身、システム開発の現場で受注者側として、契約に記載されていない新規機能案件（お客様は追加、と思っていらっしゃらない）の費用説明には苦慮しました。

プロトタイプの説明中、「〇〇ってできないのー？」というちょっと一言から始まり、それまでの明るい雰囲気が雷雲の中に入ったような殺伐とした空気に変わります。

つまり、発注者側は「ちょっとした修正・追加のつもり」でも、受注者側は「大幅な作業工数の増加」と捉えていることがあります。この認識のズレが、費用の請求・納期の遅延・関係の悪化へとつながっていきます。

この記事では、システム開発契約書における仕様変更のルールをどう定めればトラブルを防げるかについて、具体的なポイントをわかりやすく解説します。発注者・受注者どちらの立場の方にも参考になる内容です。

この記事のポイント

• 仕様変更トラブルの多くは、契約書に変更手続きのルールがないことが原因
• 仕様変更は「書面による合意」を原則とすることがトラブル防止の基本
• 変更内容・追加費用・納期への影響を記録に残す仕組みが重要
• 契約書に「変更管理条項」を盛り込むことで、認識のズレを未然に防げる

なぜ仕様変更でトラブルが起きるのか

システム開発のプロジェクトは、開発が進むにつれて「やっぱりここを変えたい」という要望が生まれやすい性質があります。それ自体は自然なことですが、問題はその変更をどう扱うかのルールが曖昧なまま進んでしまうことです。

たとえば、発注者が口頭で「この画面のボタンを増やしてほしい」と伝え、受注者が「わかりました」と返答した場合を考えてみます。
この場合、発注者は「無償で対応してもらえる」と思い込み、受注者は「追加費用が発生する作業として対応した」と認識していることがあります。

この認識のズレが生まれる根本的な原因は、変更の合意方法・費用負担・納期への影響について、契約書に明確なルールが定められていないことです。

また、「仕様変更」と「仕様の確認・修正（バグ修正）」の境界線が不明確なまま進むケースも多く見られます。どこからが追加費用の対象になるのかを最初に取り決めておかないと、後になって双方の主張が食い違ってしまいます。

契約書に盛り込むべき「変更管理条項」とは

仕様変更トラブルを防ぐために、契約書には「変更管理条項（チェンジコントロール条項）」を設けることが有効です。これは、仕様変更が発生した際の手続きを定めた条項で、次のような内容を含みます。

①変更の申請・協議プロセス

仕様変更を希望する場合は、口頭ではなく書面（またはメール等の記録が残る方法）で申請することを原則とします。受注者はその変更内容を確認し、作業量・追加費用・納期への影響を見積もったうえで書面で回答する、というプロセスを定めておくと安心です。

②合意の方法

変更内容・費用・納期のすべてについて、双方が書面で合意した場合にのみ変更が確定すると定めることが重要です。口頭での合意を有効とすると、後から「言った・言わない」の争いになりやすいためです。

③変更前の作業継続・中断の取り扱い

仕様変更の協議中に、既存の作業をどう扱うかも決めておく必要があります。

変更合意が得られるまでは現行仕様で作業を続けるのか、いったん作業を止めるのかによって、納期や費用の計算が変わってきます。

この3点目は前述の2つよりは、地味な条項ですが、実際の開発の現場でもとてもグレーになってい軽視しがちな点だと思います。

たとえば住宅建築であれば、家の構造に手を入れるのか、手すりの高さを変えたいだけなのか、によって、工事を止めるのか止めないのか発注者側も受注者側も認識を合わせやすいです。

しかしシステム開発においては発注者側が理解しにくいソースコードの改修にどの程度時間がかかるのか、作業を止めるほどなのか、客観的な判断が難しい面が多くあります。

後々のトラブルを防ぐため、ぜひ条項に加えることを検討ください。

仕様変更ルールを定める際の主なチェックポイント

契約書に仕様変更のルールを盛り込む際には、以下の項目を整理しておくとトラブルを未然に防ぎやすくなります。

チェックポイント	確認すべき内容
変更の申請方法	書面・メールなど記録が残る方法に限定しているか
見積もりの提示	追加費用・追加工数を受注者が書面で提示するか
合意の成立条件	双方の署名・捺印または書面承認が必要か
納期への影響	変更に伴う納期変更の手続きが明記されているか
変更の上限・回数制限	無制限の変更を防ぐ条件が設けられているか
変更履歴の管理	変更内容を記録・保管するルールがあるか

特に「追加費用の発生条件」は曖昧になりがちな箇所です。たとえば「軽微な変更は無償で対応する」と定める場合、「軽微」の範囲を具体的に定義しておかないと、再びトラブルの原因になります。作業時間の上限（例：1回あたり〇時間以内）や変更箇所の規模など、できる限り数値や基準で明示することが望ましいです。

仕様変更と「バグ修正」の違いを契約書に明記する

システム開発契約でよく起きる混乱のひとつが、「これは仕様変更なのか、それともバグ修正（瑕疵担保責任の範囲）なのか」という問題です。

バグ修正（瑕疵修補）とは、当初の仕様どおりに動かない不具合を直すことを指します。一方、仕様変更とは当初の仕様には存在しなかった機能・画面・処理を追加・変更することです。この区別が契約書に明記されていないと、発注者は「バグを直してもらっているだけ」と思い、受注者は「これは仕様変更だから追加費用が発生する」と主張するという事態になります。

契約書には「仕様変更」と「瑕疵修補」の定義を明確に分けて記載し、それぞれの費用負担と手続きを別々に定めておくことが重要です。また、仕様書（設計書）を契約書の別紙として添付し、「この仕様書に基づいて判断する」と明記することで、基準を明確にできます。

まとめ

システム開発契約における仕様変更トラブルは、「口頭でのやり取り」と「ルールの不在」が主な原因です。防止策の核心は、変更手続きを書面化・ルール化することにあります。

改めて要点を整理すると、次のとおりです。仕様変更はすべて書面で申請・合意することを原則とする。追加費用・納期への影響を明確にしてから変更を確定させる。「仕様変更」と「バグ修正」の区別を契約書に明記する。変更の記録を残す仕組みを仕組みとして設ける。これらを契約書に盛り込むことで、認識のズレから生じるトラブルをかなりの程度防ぐことができます。

ただし、個々のプロジェクトの規模・内容・取引関係によって、適切な条項の内容は異なります。

「既存の契約書に仕様変更のルールが入っているか確認したい」「これから契約書を作成したい」という場合は、IT開発現場経験のある当事務所にご相談ください。

“`