仕様変更・追加要望の正しい伝え方と追加費用の考え方

「せっかくなので、この画面にも検索機能をつけてもらえますか」——開発中の画面を初めて見せてもらったとき、担当者としてはごく自然にそう口にしただけだった。ところが数日後、開発会社から届いた見積もりには「追加開発費用：25万円」という一行が添えられていた。予算にはそんな項目はない。かといって、今さら「やっぱりいりません」とも言いにくい。上司に説明しようにも、なぜ費用が発生するのか自分でもうまく説明できない——。

このすれ違いは、決して珍しいものではありません。開発が進むにつれて、当初は気づかなかった不都合や、あった方が便利な機能が見えてくるのは自然なことです。問題は、その気づきをどう伝えれば、開発会社との間でトラブルにならずに済むのか、そして追加費用が発生するとしたらどこまでが妥当なのかを、多くの発注者が判断する材料を持たないまま現場に立たされていることにあります。

結論から言うと、仕様変更・追加要望は「発生すること自体」が問題なのではなく、「伝え方」と「費用が発生する境界線への理解」が曖昧なまま進めてしまうことが問題です。要望を思いついた順にチャットで伝える、口頭の立ち話で済ませる、といった伝え方を続けている限り、開発会社側も正式な変更として扱ってよいのか判断がつかず、結果として「言った・言わない」の水掛け論やなし崩し的な無償対応、あるいは逆に理不尽に感じる高額請求のいずれかに転びやすくなります。

この記事では、仕様変更・追加要望が起きる理由を整理したうえで、開発会社に正しく伝えるための具体的な手順、追加費用が発生する・しないの境界線の考え方、そして費用交渉で不利にならないための準備を、実務の流れに沿って解説します。契約書や見積書の用語に不慣れな方でも、自社の状況に置き換えながら読み進められる構成にしています。

この記事で分かること

開発プロジェクトの途中で仕様変更や追加要望が発生したときに、開発会社との関係を悪化させずに伝える手順と、追加費用が発生するかどうかの判断基準を解説します。具体的には、仕様変更が起きる典型的な原因、口頭やチャットで済ませてはいけない理由、変更を伝える際に使える依頼票のフォーマット、契約形態（請負契約と準委任契約）によって費用の考え方がどう変わるか、追加費用の見積もりが妥当かどうかを確認するチェックポイント、そして開発会社と費用面でもめてしまった場合の対処法まで、発注から検収に至るプロジェクト全体を通じて起こりうる場面を想定して順番に整理します。

なぜ仕様変更・追加要望は「必ず」発生するのか

まず理解しておきたいのは、仕様変更や追加要望の発生そのものは、プロジェクト運営の失敗ではないということです。システム開発の現場では、要件定義の段階でどれだけ丁寧に詰めたつもりでも、実際に動く画面を見て初めて気づく不都合、業務フローの理解不足、法改正や取引先の都合による後からの制約変更など、変更の芽は様々な理由で生まれます。

典型的なパターンを整理すると、次のようになります。

• 画面を見て初めて気づくケース: 要件定義書の文章だけでは実際の使い勝手がイメージできず、動くものを見て「思っていたのと違う」と気づく
• 業務側の変化によるケース: 開発期間中に組織変更や取引先との契約変更があり、当初の要件が実態に合わなくなる
• 法制度・外部環境の変化によるケース: 税制や業法の改正により、システムに反映しなければならない仕様が後から発生する
• 要件定義自体の粗さによるケース: 発注前の要件定義が十分に詰め切れておらず、開発が進んでから抜け漏れが判明する

これらのうち、最初の3つはある程度避けられない性質のものです。どれだけ経験豊富なプロジェクトマネージャーが関わっても、動くシステムを実際に触って初めて見えてくる気づきはゼロにはなりません。IPAが公開している「情報システム・モデル取引・契約書」でも、開発の途中で仕様の変更や追加が生じることを前提とした変更管理の手続きが規定として組み込まれており、変更が起こること自体は想定内の出来事として扱われています。

一方で4つ目の「要件定義自体の粗さ」については、発注前の準備によってある程度減らせる余地があります。この点は関連記事「要件のまとめ方: 開発会社に伝わる資料の作り方」で詳しく扱っていますので、まだ発注前の方はあわせて確認してください。

この記事で押さえておきたいこと

仕様変更・追加要望が発生すること自体は、プロジェクトの失敗を意味しない。問題になるのは「発生したときにどう扱うか」の手順が、発注者と開発会社の間で共有されていない場合である。

口頭・チャットだけで伝えることの何が問題か

開発中の担当者と、日々チャットツールやオンライン会議で頻繁にやり取りをしていると、思いついた要望をそのまま「ついでに」伝えてしまうことがよくあります。「あ、そういえばこの画面、もう一項目追加できますか」というひと言が、正式な依頼として扱われるのか、単なる雑談として流されるのか、実は発注者側にも開発会社側にも判断がつかないまま進んでしまうケースが少なくありません。

この曖昧さが後々のトラブルに直結する理由は、主に3つあります。

第一に、「言った・言わない」の水掛け論が起きやすくなることです。口頭や口頭に近いチャットのやり取りは、時間が経つと双方の記憶が食い違います。発注者は「あのとき伝えたはずだ」と思っていても、開発会社側では正式な依頼として記録・共有されておらず、結果として仕様に反映されないまま進んでしまう、あるいは逆に「言っていないことを勝手に追加された」という食い違いも起こり得ます。

第二に、開発会社側が「無償の範囲」か「有償の変更」かを判断する材料がないことです。ちょっとした一言のやり取りでは、それが軽微な修正なのか、設計に手を入れる規模の変更なのかが伝わりません。開発会社としても、都度立ち止まって「これは有償ですが進めてよいですか」と確認するのは現実的ではなく、なし崩し的に無償対応を続けるか、逆にプロジェクトの終盤でまとめて高額な追加請求が来るかのどちらかに転びやすくなります。

第三に、発注者側の社内稟議や予算管理と紐づかないことです。追加費用が発生する変更であれば、社内で決裁を取る必要が出てきます。しかし口頭でのやり取りだけでは、いつ・誰が・何を依頼したのかという記録が残らず、後から経理や上長に説明を求められたときに困る事態になります。

このため、どれほど気軽な関係性の開発会社であっても、仕様変更・追加要望は必ず書面（メールやチャットのテキストでも構いません。重要なのは記録が残る形で送ることです）で伝えるというルールを、プロジェクトの初期段階で開発会社と合意しておくことが実務上の第一歩になります。

仕様変更を伝えるときに使える「変更依頼票」の考え方

書面で伝えると言っても、思いつくままに文章を書き連ねただけでは、開発会社側も内容を正しく理解し、見積もりを出すことができません。IT業界の受託開発プロジェクトでは、こうした変更のやり取りを整理するための「変更管理」という考え方があり、変更内容を一定のフォーマットに沿って整理し、双方で合意したうえで正式な変更として扱う手続きが一般的に用いられています。

大がかりな様式である必要はありません。中小企業の実務では、以下の項目を箇条書きでまとめるだけでも十分に機能します。

この表をメールの本文やチャットのテキストにそのまま書いて送るだけでも、開発会社側は「これは正式な変更依頼だ」と認識でき、内容を検討して見積もりを返しやすくなります。逆に、こうした整理をせず「なんとなくこうしてほしい」という抽象的な依頼を送ってしまうと、開発会社側から確認の質問が何往復も返ってきて、かえって時間がかかることになります。

依頼を出す際は、次の点も意識しておくと交渉がスムーズになります。

• 変更の理由を添える。理由が分かれば、開発会社側も「他により簡単な実現方法はないか」といった代替案を提案しやすくなります
• 「絶対に必要」なのか「あれば嬉しい」なのかの優先度を明示する。すべてを同列に依頼すると、開発会社側は全部に対応する前提で見積もりを出さざるを得ません
• 依頼した日付が残るように、メールまたはチャットで送る（口頭で伝えた内容も、後追いで「先ほどお伝えした件、念のため書面でも送ります」という形でテキスト化しておくとよいでしょう）

実務のコツ

「なんとなく気になる」段階のうちは、正式な依頼にせず「相談」として伝えるのも一つの手です。「これは正式な変更依頼というより、一度相談したいのですが」と前置きするだけで、開発会社側も身構えずに一緒に検討しやすくなります。全部を正式依頼として送りつけると、関係がぎくしゃくすることもあります。

追加費用が発生するかどうかの境界線

仕様変更・追加要望を伝えたあと、多くの担当者が最も知りたいのが「これは無償の範囲なのか、追加費用がかかるのか」という点です。ここには明確な一律の基準があるわけではありませんが、考え方の軸を持っておくことで、開発会社からの説明を理解しやすくなり、不当な請求かどうかも見分けやすくなります。

契約形態によって考え方が変わる

まず前提として、開発会社との契約が請負契約なのか、準委任契約なのかによって、追加費用の考え方の出発点が異なります。

準委任契約は、業務の遂行そのものに対して報酬を支払う契約であるため、仕様変更によって作業量が増えれば、その増加分に応じた追加の工数（＝費用）が発生するのが基本的な考え方になります。一方で請負契約は、契約時点で合意した「完成させる成果物」に対して報酬を支払う契約であるため、契約範囲外の追加作業が発生した場合、それは元の契約の範囲を超えた「別の仕事」として扱われ、追加の契約・追加の報酬の対象になります。両者の違いについては、関連記事「請負契約と準委任契約の違い」で詳しく解説していますので、自社の契約がどちらに当たるか分からない場合はあわせて確認してください。

民法上、請負契約における報酬は「仕事の目的物の引渡しと同時に、支払わなければならない」（民法第633条）とされ、報酬の対象となる「仕事」の範囲は、契約時点で合意された内容に基づきます。つまり、契約時に定義された仕事の範囲を超える追加の要望は、法律上も当然に無償で含まれるものではなく、原則として別途の合意（追加の契約や見積もり）が必要になるという理解が基本線になります。

「合意した仕様書の範囲内」かどうかが分かれ目

より実務的な判断軸としては、「その変更が、契約時に合意した仕様書・要件定義書に書かれていた範囲に収まるかどうか」が最も重要なポイントになります。

• 仕様書に書かれていた内容の解釈・実現方法の調整 → 開発会社の責任で対応すべき範囲であり、追加費用の対象になりにくい
• 仕様書に明記されていなかった新しい機能・項目の追加 → 契約範囲外の追加要望であり、追加費用が発生しやすい
• 仕様書の記載自体が曖昧で、双方の解釈が食い違っていた → グレーゾーン。どちらの解釈が妥当か、仕様書の文言に立ち返って協議する必要がある

3つ目のグレーゾーンが、実務上もっとも揉めやすい領域です。発注者側は「当然この機能も含まれていると思っていた」と主張し、開発会社側は「仕様書に明記されていない以上、契約範囲外だ」と主張する、という構図になりがちです。ここで重要になるのが、発注前に交わしたSOW（作業範囲記述書）や仕様書の記載の精度です。曖昧な記載のまま契約してしまうと、いざ変更が発生したときに、どちらの言い分が正しいのかを判断する拠り所がなくなってしまいます。

費用が発生しやすい変更・発生しにくい変更の目安

すべての変更を一律に語ることはできませんが、実務上の傾向として、次のような整理が可能です。

「明らかな不具合の修正」と「新しい機能の追加」の境目は比較的分かりやすい一方、その中間にある「軽微な調整」は開発会社ごとに判断基準が異なります。契約時に、無償対応の範囲についてどこまで開発会社が想定しているのかを、事前にすり合わせておくと後々のトラブルを減らせます。

追加費用の見積もりが届いたら確認すること

開発会社から追加費用の見積もりが提示されたとき、金額の大小だけで判断するのではなく、内訳を確認する視点を持つことが重要です。見積書の読み方全般については関連記事「見積書、この内訳の見方で損を防ぐ」で詳しく扱っていますが、追加費用の見積もりに特有の確認ポイントとして、次の項目を押さえておくとよいでしょう。

• 作業内容の内訳が具体的か: 「追加開発費用一式」のような一行だけの見積もりではなく、設計・実装・テストなど、どの工程にどれだけの工数がかかるのかが分かる内訳になっているか
• 既存部分への影響範囲が説明されているか: 追加する機能が、既存の画面やデータ構造にどう影響するのか（影響範囲が広いほど、金額が上がる理由になり得ます）
• なぜその工数になるのかの説明があるか: 「なんとなくこの規模だから」ではなく、具体的な作業ステップに基づいた説明が受けられるか
• スケジュールへの影響が明示されているか: 追加対応によって、当初の納期がどれだけ延びるのか（あるいは延びないのか）

見積もりの金額そのものが高いか安いかを、発注者だけで正確に判断するのは難しいのが実情です。ただし、上記のような内訳や説明を求めたときに、開発会社側が具体的に答えられるかどうかは、その見積もりが妥当な検討を経て出されたものかどうかを見分ける手がかりになります。曖昧な説明しか返ってこない場合は、遠慮なく「もう少し詳しく教えてください」と質問してよい場面です。

確認の目安

見積もりに疑問を感じたら、その場で即決せず「一度社内で検討します」と持ち帰る選択肢を必ず残してください。開発会社との関係を気にして即答してしまうと、後から交渉の余地がなくなります。

追加費用を抑える・減らす交渉の考え方

追加費用の発生自体は避けられない場面が多いとしても、金額や範囲について交渉の余地がまったくないわけではありません。以下のような視点を持つと、無理な値切りではなく、建設的な調整につながりやすくなります。

• 優先度の低い要望を削る: 複数の変更依頼をまとめて出した場合、すべてを今回の予算内で実現しようとせず、「今回は最優先の2つだけ実施し、残りは次のフェーズで検討する」という切り分けを提案する
• 代替の実現方法を相談する: 「新しい画面を作る」のではなく「既存の画面に項目を1つ追加する」など、開発会社側の専門知識を借りて、より低コストな実現方法がないか相談する
• 無償対応の範囲について事前確認をしておく: プロジェクトの初期段階で、開発会社が「軽微な調整」としてどこまでを無償対応の範囲と考えているかを確認しておくと、後の交渉の土台になる
• 一括りにせず、変更ごとに個別の見積もりを求める: 複数の変更をまとめて「追加開発費用一式」として提示された場合、変更ごとの内訳を分けて見積もってもらうよう依頼する

ここで注意したいのは、追加費用そのものを一方的に拒否したり、大幅な値引きを強く迫ったりする交渉は、長期的には得策とは限らないという点です。開発会社にとっても、契約範囲外の作業には正当な対価が必要であり、無理な値引きを繰り返す発注者は、優先順位の低い顧客として扱われてしまうリスクがあります。追加費用の妥当性を確認する姿勢と、開発会社の専門性・工数に対する敬意を両立させることが、長期的に良い関係を維持するコツです。

検収前後で仕様変更が発覚した場合の対応

仕様変更・追加要望は、開発中だけでなく、検収の段階、あるいは検収後に発覚することもあります。このタイミングによって、対応の性質が変わってくる点に注意が必要です。

検収前に気づいた場合

納品前の段階で「これは仕様と違う」と気づいた場合は、まず「契約時の仕様書に記載されていた内容と異なるのか」「そもそも仕様書に記載がなかった新しい要望なのか」を切り分けます。前者であれば、開発会社の責任で無償修正を求めることができる可能性が高く、後者であれば、これまで解説してきた追加費用の検討対象になります。

検収後に不具合が見つかった場合

検収に合格したあとで、契約内容と異なる不具合が見つかった場合は、契約不適合責任の枠組みで対応を検討することになります。これは「仕様変更」とは別の話で、そもそも契約時に合意した内容通りに仕上がっていなかったケースを指すため、追加費用を発注者側が負担する話にはなりにくい領域です。契約不適合責任の考え方や、検収時に確認すべきテスト項目については、関連記事「検収とは？発注者がやるべきテスト」で詳しく扱っています。

民法第636条では、請負人（開発会社）が種類・品質に関して契約内容に適合しない仕事の目的物を注文者（発注者）に引き渡した場合について規定していますが、この条文は「注文者の供した材料の性質又は注文者の与えた指図によって生じた不適合」については、開発会社側の責任を制限する内容になっています。つまり、発注者側が誤った指示や不十分な情報を与えたことが原因で生じた不具合については、開発会社の契約不適合責任を問いにくくなる場合がある、ということです。この点からも、仕様変更を伝える際の依頼内容を正確に記録しておくことの重要性が見えてきます。

途中で開発をストップしたくなった場合の考え方

仕様変更の議論が難航し、「そもそもこの開発自体を見直したい」という話に発展することもあり得ます。民法第641条では、請負人が仕事を完成しない間は、注文者はいつでも損害を賠償して契約を解除できると定められています。つまり、発注者側から一方的に契約を打ち切ること自体は法律上可能ですが、その場合は開発会社が被った損害（それまでの作業に対する報酬相当額など）を賠償する必要が生じる点に注意が必要です。

また、民法第634条では、請負が仕事の完成前に解除された場合であっても、請負人がすでに行った仕事の結果のうち、注文者にとって利益となる部分があれば、その割合に応じた報酬を請求できるとされています。つまり「まだ完成していないのだから支払わなくてよい」という単純な話にはならず、それまでの進捗に応じた報酬の精算が必要になる場合が多いことは、あらかじめ理解しておくとよいでしょう。

途中解約という重い判断に至る前に、まずはプロジェクトの立て直しが可能かどうかを検討する余地があります。定例ミーティングの運営や進捗確認の見直しについては、関連記事「開発プロジェクトの定例ミーティングの回し方」や「進捗報告の見方」もあわせて参考にしてください。

仕様変更のやり取りをスムーズにする、契約前からの備え

ここまで、仕様変更・追加要望が発生してからの対応を中心に解説してきましたが、実は最もトラブルを減らせるのは、契約を結ぶ前の段階での備えです。

• 仕様書・要件定義書をできる限り具体的に書いておく: 「〇〇機能を実装する」だけでなく、「誰が」「何を」「どのような条件で」操作するのかまで書き込んでおくと、後から解釈の食い違いが生じにくくなります
• 変更管理のルールを契約時点で合意しておく: 「仕様変更が発生した場合はどのような手続きを踏むか」「無償対応の範囲はどこまでか」を、契約書または覚書に明記しておく
• 見積もりの前提条件を確認しておく: 見積もりが「どの範囲の仕様を前提にした金額か」を、契約前にはっきりさせておく

これらは、丸投げ発注にならないための発注者の役割の一部でもあります。契約後の関係の作り方全般については、関連記事「丸投げ発注が失敗する理由と発注者の役割」でも扱っていますので、あわせて確認しておくことをおすすめします。

まとめ

仕様変更・追加要望は、開発プロジェクトにおいて避けられない場面です。重要なのは、それをどう伝え、どこまでが無償の範囲でどこからが追加費用の対象になるのかを、双方が理解できる形で扱うことです。

• 仕様変更・追加要望は、必ず記録が残る書面（メール・チャットのテキスト）で伝える
• 依頼日・対象箇所・現状・変更後の希望・理由・希望時期を整理した「変更依頼票」の形式で伝えると、開発会社側も検討しやすくなる
• 追加費用が発生するかどうかは、契約時に合意した仕様書の範囲内かどうかが最大の分かれ目になる
• 契約形態（請負契約・準委任契約）によって、追加費用の考え方の出発点が異なる
• 見積もりが届いたら、金額だけでなく内訳・影響範囲・工数の根拠を確認する
• 途中解約は法律上可能だが、それまでの進捗に応じた報酬精算が必要になる場合が多い

仕様変更のたびに気まずさを感じる必要はありません。正しい手順で伝え、正しい基準で費用を判断できれば、開発会社との関係を損なうことなく、必要な変更を適切に反映していくことができます。

次は、そもそも仕様変更が起きにくい要件定義の作り方について、「要件のまとめ方: 開発会社に伝わる資料の作り方」で解説しています。これから発注する予定がある方、あるいは次のプロジェクトに向けて準備をしたい方は、あわせてご覧ください。