開発着手後の大幅な機能追加・増加があったとして，ベンダが開発契約で定められた報酬の額を大幅に超える追加報酬請求を行った事例。
事案の概要
システム開発会社Ｘは，書籍の管理・配送業Ｙから，書籍仕分システム，書籍在庫管理システムの開発を受託した。開発報酬としては，前者につき280万円，後者につき2325万円とされていた。そのほかに環境設定等の報酬も設定されていた。
Ｘは，上記2325万円は，182機能を予定とした見積であり，契約中に「作業着手後の機能追加，変更等により工数に大幅な変動が生じた場合は別途相談させていただきます。」との特約に基づいて，実際には414機能を完成させたとして，1本あたり12万7747円として，合計で5568万円余りを請求した。
Ｙは，追加開発に関する合意がないことや，開発業務が完了していないまま撤退したことなどを理由に争った。
ここで取り上げる争点
契約書で定めた金額以上の報酬請求が認められるか（Ｘに委託した業務の範囲はどこまでか）。
裁判所の判断
裁判所は，プログラム数が，当初は182本であったところ，414本まで増加したことを認定した（422本まで増加しているが，8本は未完成）。この増加した原因については，見積前提条件には「現行オフコンの業務範囲」となっていたところ，実際には個別の出版社向けに対応したプログラムが追加したところにあったと認定した。
なお，414本のプログラムは，一括で納入・検収されたものではなく，206本のプログラムが二次検収と呼ばれるタイミングまでに納入され，残りは，三次検収までに納入された。
そうした事情から，開発契約で予定されていた開発範囲は，現行オフコンの業務と，ＸＹ間で事前に合意されていた新機能に限られ，個別の出版社対応機能は含まれないとした。
そして，追加の報酬請求権については，
Ｘは，見積書に「作業着手後の機能追加，変更等により工数に大幅な変動が生じた場合は別途相談させていただきます」との記載があることを根拠に，増大したプログラムについて当事者間の報酬金の協議が整わなければ，ＸがＹに対して相当額の報酬請求をすることができると主張する。上記見積書は当事者間の契約文書ではないから，契約書の約定と同一の効力を有するものと評価するには問題がある。
として，見積書と契約書とは法的効力に差があるとしつつも，
しかし，そもそも見積書に上記の文言がないとしても，追加注文と評価される業務については，当事者間に相当の報酬を支払う旨の合意があるものと見るべきであるから，上記文言の有無にかかわらず，ＸはＹに対して，追加注文部分について相当額の報酬請求権を取得するものというべきである。
として，当初の業務範囲に含まれていない部分については追加報酬請求権が生ずるとした。
なお，追加報酬額については，414本のプログラムのうち，206本は当初の契約範囲に含まれていると認定したため，Ｘの請求額からは一部減額されることとなった。
若干のコメント
システム開発においては，本件のように追加開発部分の報酬請求が争いとなることがよくあります。現場は，ユーザもベンダも何とかして完成，稼働させようとするため，当初の契約範囲がどこまでだったのかよくわからなくなり，そのまま突っ走ってしまうことが多いようです。想定以上の工数負担に頭を悩ませるベンダが，あるタイミングで（多くの場合，無事に稼働させたタイミングで）ユーザに「実は・・追加報酬の件ですが・・」などと切り出すことになるでしょう。
本件からも明らかなように，もともとの契約で対象となっていた範囲が明確でないとベンダ側は追加請求することができません。ベンダは，当初の契約範囲，実際に開発した部分，超過部分の報酬額のすべてについて立証責任を負います。
本件では，見積書に「相談させていただきます」と書かれていたことは，特に重視されていません。こういった文言があれば安心ということはなく，結局は，契約範囲を明確にしておくことが重要になります。
また，本件を根拠に，一般的にベンダにとって仕様変更・追加が生じたら追加報酬が認められやすいと考えるのは危険です。本件は，いったん当初の契約範囲だった部分について検収が終了した後に，三次検収と呼ばれるタイミングで大量のプログラムを納入したケースであり，「当初の契約範囲」と「追加の範囲」が截然と区別しやすかったといえるからです。
むしろよくあるケースとしては，テストの過程で仕様変更か不具合か区別がつかない修正案件が大量に発生し，上位レベルで見た機能数としては特に変化はないものの，その内容が複雑化し，実際のステップ数，難易度が格段に高まったというケースではないでしょうか。ベンダからみれば，「最初から言ってくれれば，たいした工数もかからなかったはずなのに」となりますし，ユーザからみれば，「設計書からは何もわからないし，説明もなかった。できあがったものは，まったく使えなかった」ということになるでしょう。
こういった事態を防ぐには，変更管理手順を明確にし，かつ，その手順を踏むことを契約上の双方の義務にしておくことが考えられます。そうすると，管理のための工数が増加したり，柔軟性，迅速性が損なわれたりするという議論もありますが，それはPMスキルの問題だと思います。後に紛争になった場合の損失を考えれば，ユーザ，ベンダ双方にとって，事前に合意した範囲を意識することは必須だといえるでしょう。
