ユーザからシステムの開発を委託され，開発に着手したのですが，作業を進めるうちに，ユーザから当初聞いていた話とは大きく異なり，どんどん開発スコープが広がってしまいました。現場では，ユーザの要望どおりに開発していましたが，想定工数を大幅に超過しています。超過分の報酬を請求することはできないでしょうか。

明示的な仕様変更の合意がない限りは，ベンダからの追加報酬を請求することは容易ではありません。ユーザ，ベンダともに仕様変更を巡るトラブルを回避するためにも，契約書の段階で仕様変更，契約変更のプロセスを定め，そのルールに沿った運用をすることが望ましいです。

（ａ）トラブルの原因

システム開発業務は，開始の時点において全体が見えていないことが多く，作業の進捗とともに新たな問題が発覚したり，ユーザの事業環境が変更したりすることにより，仕様変更や開発スコープの変更が多く発生します。東京地裁平成15年5月8日判決は，やや極端な言い回しですが，「追加の費用が発生することはいわば常識であって，追加費用が発生しないソフトウェア開発などは稀有である」と言い切っています。

仕様変更や開発スコープを変更する必要が生じた場合に，ベンダがその都度，ユーザから追加報酬の合意をとっていればあまり問題は生じません。しかし，ベンダの現場担当者が納期を優先し，細かいことを気にしないまま仕様変更に応じた結果，後にユーザから追加報酬の支払いを拒絶されてトラブルに発展することは少なくありません。ユーザからみれば，ベンダの作業は当初の依頼の範囲に含まれていると考えており，仕様が変更されたという認識すらないこともよくあります。

（ｂ）仕様変更に伴う追加報酬請求の可否

ベンダの行った作業が，当初の合意において報酬支払の前提とされている業務の範囲内のものであれば，ベンダがユーザに対して追加請求をする余地はありません。例えば，単にベンダ側の工数見積の誤りがあり，想定以上に工数がかかってしまったような場合には，請負契約を前提とする限り，追加報酬を請求することはできません。

他方，当初の合意において報酬支払の前提とされている範囲を超える作業については，追加報酬の請求をする余地があります。ただし，報酬代金額を増加させるということは，契約を変更し，あるいは新規契約を締結するということになりますので，「契約書がないまま着手した場合」で述べた場合のように，契約が成立したと認められる場合でなければ報酬を請求することは難しいと考えられます。

（ｃ）追加報酬の請求が認められやすい場合

ベンダによる追加報酬の請求は，当初の合意における開発スコープ（逆にいえば，追加報酬の請求の対象となる業務の範囲）が明確であり，その業務の報酬算定の根拠も明確であるような場合に認められる可能性があります。契約の成立をめぐる問題と同じように，ユーザにおいて，ベンダの追加作業が有償であることを認識していることも重要です。

例えば，当初の合意においてシステムの機能数に基づいて報酬額が算定されている場合に，報酬算定の根拠となる機能数が増加し，そのことをユーザも認識してベンダに作業を任せていたようなときには，追加報酬の請求が認められる可能性があります（このような例として東京地裁平成17年4月22日判決）。

（ｄ）追加報酬の請求をめぐるトラブルを防ぐための方策

追加報酬の請求をめぐるトラブルを避けるためには，あらかじめ開発スコープや報酬算定の根拠を明確にしておく必要があります。例えば，契約書の別紙等に合意の内容を添付する方法が考えられます。契約締結段階では開発スコープを確定できないことが多いかもしれませんが，適宜合意ができた段階で開発対象をアップデートし，契約書と紐づけておくべきでしょう。
なお，ユーザとしては，機能数やプログラム本数といった事後的に分割・統合できるような基準を報酬算定の基礎とすることは避けるべきです。開発作業を進めるうちに機能数等が変更されて予想外に費用が膨らむなど，トラブルの原因になりかねません。

また，ユーザの認識を立証することは困難なので，契約書において，あらかじめ仕様変更プロセス，契約変更プロセスを定めておくべきです（例として，経産省モデル契約＜第一版＞第34条・第37条など）。現場においても，手続に沿った運用を励行し，手続が実践されない場合には追加作業をすべきではないでしょう。

これらの事前の対応のほか，実際に追加作業の要望があった場合の対応も重要です。例えば，変更管理票や課題管理一覧表などを作成して管理し，あるいは追加作業に関するやり取りを議事録等に残すなど，変更のプロセス・結果を証拠として残すべきでしょう。

（弁護士　高岡晃士　H29.2.28）