要件定義の「変更」が追加費用になる境界線

「これくらいの変更、追加費用にはならないですよね」——開発会社に投げたこの一言に対して返ってきた見積もりを見て、困惑した経験はないでしょうか。現場の感覚では「ちょっとした調整」のつもりでも、開発側からすると「別の作業」として扱われることがある。この温度差の正体が分からないまま費用の話だけが先に進むと、現場責任者としては納得感のないまま押し切られたような気持ちになります。

実はこの問題、開発会社の対応が硬直的というより、要件定義の時点で「何が確定していて、何が確定していないか」の線引きが曖昧なまま契約に進んでいることに起因するケースが多くあります。線引きの構造が見えると、追加費用が発生する場面をある程度予測できるようになります。

この記事では、仕様変更が追加費用になる境界線がどこにあるのか、なぜその境界がトラブルの火種になりやすいのかを整理し、事前に確認しておきたい観点を紹介します。

なぜ「ちょっとした変更」が追加費用になるのか

要件定義書は、開発会社が見積もりと契約範囲を決めるための土台になります。ここに書かれていることが「契約の中身」であり、書かれていないことは基本的に契約の外側です。現場責任者が「ちょっとした変更」と感じるものの多くは、実は要件定義書に明記されていなかった部分への追加要望であり、開発会社から見れば契約外の新しい作業ということになります。

問題は、要件定義書を読んだだけでは「何が書かれていないか」に気づきにくいことです。書かれている項目は目に入りますが、書かれていない項目は存在自体が見えないため、現場が「当然含まれているはず」と思い込んだまま進んでしまいます。この思い込みのズレが、後になって追加費用という形で表面化します。ここは、次に要件定義書を受け取ったときに「書かれていないことは何か」という視点で読み直すと、あらかじめ気づけることが多い部分です。

仕様変更と追加要望、境界線はどこにあるか

境界線を整理するときに役立つのが、「決まっていたことを直す」のか「決まっていなかったことを新しく決める」のかという分け方です。

• 仕様変更：要件定義書に記載済みの内容を、後から違う内容に変更するもの。例えば「入力項目をA形式からB形式に変える」など
• 追加要望：要件定義書に記載がなかった機能や動作を、新たに求めるもの。例えば「もともと想定していなかった一覧のエクスポート機能」など

どちらも現場の感覚では地続きの「ちょっとした変更」に見えますが、開発側の作業としては全く別物です。仕様変更は既存の設計・実装をやり直す手戻り作業になり、追加要望はゼロから設計・実装を積み増す作業になります。どちらも契約時の見積もりには含まれていないため、追加費用の対象になりやすいというわけです。

仕様変更

追加要望

境界線が曖昧なまま進むとどうなるか

要件定義の段階でこの境界線があいまいなまま契約が進むと、開発が進行してから「これは追加費用です」「いや、最初から含まれている前提だった」という水掛け論が起きやすくなります。特に、要件定義書の記述が「一式」「基本機能一式」のような大枠の表現にとどまっている場合、何が含まれ何が含まれないのかを双方が別々に解釈したまま契約してしまうことがあります。見積書の表記については見積書の「一式」表記が不安を生む理由と読み方でも扱っていますが、範囲の曖昧さは要件定義の段階から始まっていることがほとんどです。

こうした水掛け論は、単に気まずいだけでなく、追加費用の交渉に時間を取られてスケジュールが後ろ倒しになる、現場と開発会社の信頼関係がぎくしゃくするといった副作用も伴います。金額の話より前に、範囲の話がずれていることが多いという点は、実務上意識しておきたいところです。

事前に確認しておきたい観点

境界線のトラブルを完全になくすことは難しいものの、契約前にいくつかの点を確認しておくことで、後からの驚きを減らすことはできます。

• 要件定義書に「含まれないもの」の記載があるか：含まれるものだけでなく、対象外とする範囲が明記されているかを確認する
• 変更管理のルールが契約書や合意文書にあるか：仕様変更が発生した場合の見積もり・承認フローがあらかじめ決まっているかを確認する
• 曖昧な表現がないか：「柔軟に対応」「基本一式」のような幅のある表現が残っていないか、契約前に読み直す

これらは開発会社に「面倒な発注者」だと思われることを心配して聞きにくいと感じるかもしれませんが、むしろ境界線を先に確認しておくことは双方にとって手戻りを減らす行為であり、発注する側が意識しておきたいところです。

まとめ

• 「ちょっとした変更」が追加費用になるのは、要件定義書に書かれていない部分への要望が契約外として扱われるためです
• 仕様変更（決まっていたことを直す）と追加要望（決まっていなかったことを新しく決める）は、開発側の作業としては別物として扱われます
• 契約前に「含まれないものの記載」「変更管理のルール」「曖昧な表現の有無」を確認しておくと、後からの追加費用トラブルを減らしやすくなります