仕様変更・追加費用のトラブルを防ぐ方法

システム開発の途中で「この機能も入っていると思っていた」「それは追加費用です」と揉めるのは、よくあるトラブルです。仕様変更と追加費用のトラブルの多くは、最初に決めた開発範囲を書面に残していないことから起こります。この記事では、トラブルの原因、開発範囲を契約書に残す方法、仕様変更管理表の運用例、無償対応を求められる範囲の線引きを、発注者向けに整理します。

追加費用トラブルの多くは「当初範囲」を書面化していないこと

追加費用の話になると、発注者は「最初から含まれていたはず」、開発会社は「見積に入っていない」と主張しがちです。どちらが正しいかは、最初に何を合意したかで決まります。その合意が提案書の口頭説明や打ち合わせの雰囲気にしか残っていないと、判断できません。

よくある原因は次のとおりです。

• 見積書に「顧客管理機能 一式」のような粗い書き方しかない
• 打ち合わせで出た要望を、範囲内か追加かを決めないまま進めた
• 画面のレイアウトや項目、帳票の数など、細部が決まっていなかった
• 外部サービスとの連携やデータ移行など、範囲の境目があいまいだった

裁判例でも、この点は繰り返し問題になっています。発注者が打ち合わせのたびに新たな要求を追加して要件定義を確定させず、追加費用の負担にも応じなかったことが失敗の主な原因だとして、発注者の損害賠償請求が棄却された例があります（東京地判平成22年7月22日。Westlaw Japan 判例コラムで紹介）。同じコラムが解説する札幌高裁平成29年8月31日判決でも、仕様凍結の合意後に発注者が大量の追加要望を出したことが、発注者の協力義務違反と判断されました。

契約書の別紙で開発範囲を明記する方法

範囲を書面に残すには、契約書の本文ではなく別紙（仕様書や機能一覧）に具体的に書き、契約書から参照する形が実務的です。別紙には次の項目を入れます。

特に効果があるのは「範囲外の事項」を書くことです。含まないものを明記しておくと、後から「入っていると思っていた」が起きにくくなります。

見積書の「前提条件」も読み飛ばさないでください。「発注者からの回答は3営業日以内」「データは発注者が指定の形式で用意する」といった前提が崩れると、それ自体が追加費用や納期延長の理由になります。守れない前提があれば、契約前に修正を求めましょう。見積書の読み方は見積書の見方で詳しく解説しています。

仕様変更管理表の運用例

開発が始まった後の変更は、口頭で済ませず、記録して判断する仕組みを作ります。IPA（情報処理推進機構）の情報システム・モデル取引・契約書（第二版）は、変更の提案を受けた側が「変更管理書」を作り、定例の協議の場で可否を話し合い、双方の責任者が承認して初めて変更が確定する手続きを示しています。変更管理書の記載事項には、変更の理由、詳細、費用、スケジュール、契約条件への影響などが挙げられています。

中小規模の案件なら、スプレッドシートで次のような管理表を作れば十分です。

運用のコツは、定例会で毎回この表を確認し、「区分」と「判断」を空欄のまま残さないことです。費用や納期に影響する変更は、管理表の承認とは別に、変更契約や注文書で確定させます。

無償対応を求められる範囲の線引き

すべての変更が有償になるわけではありません。一般的な線引きは次のとおりです。

一方で、開発会社にも責任があります。モデル契約書の解説は、専門業者である開発会社が変更の影響を分析・説明せずに安易に応じ、遅延や不具合が生じた場合、開発会社が責任を負う可能性があると指摘しています。変更の影響を説明してくれる開発会社かどうかは、選定時の見極めポイントにもなります。

発注者側でできる予防策

線引きを決めても、変更そのものをゼロにはできません。発注者側では、次の準備をしておくと追加費用で慌てずに済みます。

• 予算に予備費を確保しておく。社内稟議の段階で「変更対応の枠」として説明しておくと、追加の承認が早くなる
• 画面モックや試作品を早い段階で触り、要望を開発の前半に出し切る
• 社内の要望の窓口を1人に絞り、部署ごとにばらばらに開発会社へ伝えない
• 「今回は見送り、次の段階で対応」という選択肢を常に持っておく

特に、要望の窓口を絞ることは効果があります。複数の部署から別々に要望が届くと、開発会社はどれが正式な依頼か判断できず、手戻りや認識違いの原因になります。

受託開発の現場から

ある受託開発会社では、仕様変更について次のように考えています。

• 受入の段階で「直したい」は必ず出る。 実物が動くと「やはりここを直したい」が必ず出るので、ある程度変更の余地を残した契約にした方が、開発会社との無駄なやり取りが起きにくい、という見方です。事業によっては、外部環境の変化で収益モデルを変えなければならないこともあり、仕様変更は避けられない前提で契約と予算を組むべきという考えです。
• 工数を「相殺」して振り替える。 スコープを増減させる場合、既存契約の範囲で工数を振り替える進め方をとっています。構築とほぼ同じ規模になる検証作業を外し、その工数を別の実現性検証の報告書に回した例があります。
• 見積への影響を分けて示す。 追加の要望には、既存見積の範囲内で対応できるものと別途オプションを分けて示し、オプションは単価と試算の前提を出したうえで「サンプル1件で実工数を測ってから確定」としています。
• 上限と受け皿を先に決める。 見積には「作業範囲が大幅に変わる場合は別途見積」を必ず書き、保守契約では「月◯時間まで」の上限を設けています。開発では最後のスプリントを仕様変更の受け皿として確保した例もあります。

まとめ

• 追加費用トラブルの多くは、当初の開発範囲を書面に残していないことが原因
• 契約書の別紙に機能一覧と「範囲外の事項」を具体的に書く
• 変更は管理表で記録し、区分・影響・承認者を毎回確定させる
• 不具合は無償、追加機能は有償が基本。迷ったら仕様書に立ち返る

本記事は一般的な情報提供を目的としたもので、個別の契約や法的判断については弁護士などの専門家にご相談ください。

開発範囲をどこまで決めればよいか分からない段階でも、FastProposal の無料AI相談なら、案件の整理と費用の目安を数分で確認できます。提案書と動くモックで範囲を具体的に比べられるので、後からの認識違いを減らせます。