システム開発の見積り金額の事後増額は可能か
システム開発という仕事は、発注するユーザー側も、受注するベンダー側も大勢の人手を巻き込んで進んでいくものであるため、皆で足並みを揃えてプロジェクトを進行していくことは容易ではありません。計画性がきわめて重要な業務であることはいうまでもありませんが、同時に発注者であるユーザーが適切な情報をまとめて端的にベンダーに伝えきれるものかというと、実際そうではありません。開発工程がある程度進んだ段階で、事後で仕様の変更や、機能の追加を求められた場合、事前の見積り金額に上乗せした請求が可能となるのかどうかは、仕事を受ける側からしてみれば非常に気になるところでしょう。
こうした権利は法律上、どのような場合に認められるものなのでしょうか。またその追加開発・機能の修正にかかる報酬金額は、どのように決定していくものなのでしょうか。本記事では、こうした種々の疑問について整理を行います。
この記事の目次
そもそも追加開発・機能の修正といえるのはどんなときか
システム開発のプロジェクトで、仕事を受ける場合の契約型は通常請負契約もしくは準委任契約といったものです。これらの契約型はいずれの場合にしろ、仕事をうける側がやるべきこと（＝義務）と、それに付随する報酬（＝権利）が一対になって契約に示されることになります。したがって、その報酬額の前提となっている業務に含まれない業務が後から追加されたような場合には、追加開発・機能の修正であるということができます。また反対に、含まれるような場合に関しては、当初の仕様通り（＝従来の契約の枠内のもの）と扱われることになります。
なお、請負契約と準委任契約の違い等に関しては別記事で詳細に解説しています。
もっとも、画面上で表示されるフォントの微調整などまですべて予め仕様で定めないと、それらもすべて追加開発であるとまでいうならば、それはスムーズな商取引を著しく阻害することにもなりかねません。したがって、これらの仕様の詳細にかかわる議論まで踏まえると、実際問題一律な線引きを行うことは簡単ではありません。しかし一般的な指針を示すとするなら、
- 仕様が一度確定してから、さらなる追加機能を命じられた
- すでにプログラムの実装が終わってから、その修正を命じられた
といったような場合であれば、その主張は法律上も一定の妥当性が見込める可能性が高いということができます。
追加開発・機能の修正といえるかが争点となった裁判例
肯定例：基本設計の仕様を事後で変更した事例
以下の事例は、事後的に仕様の変更があったものです。
ソフトウエア開発は、①要件定義、②外部設計、③内部設計、④ソースプログラムの作成（プログラム設計、コーディング）、⑤各種試験（単体試験、組合せ試験、システム試験）の開発工程を経て進められるところ（中略）当初仕様（中略）を内部設計以降の作業によって実現することであり、これが、本件開発委託契約に基づく報酬請求権と対価関係に立つ業務の範囲であると解される。
大阪地裁平成１４年８月２９日判決
仕様変更の申出は、法的には、委託者による当初の契約に基づく業務範囲を超える新たな業務委託契約の申込みと解され、これに対して受託者が追加工事代金額を提示せず、追加代金額の合意がないまま追加委託に係る業務を完了した場合には、委託者と受託者の間で代金額の定めのない新たな請負契約が成立したものとして、相当の追加開発費支払義務が生じると解するのが相当である。
「対価関係」、「新たな契約」といったキーワードを抑えておくことが、本判決の理解の深める糸口となるでしょう。
またちなみに、上記の判決では、ほかにももう一つ、非常に興味深い点が示されました。それは、ボタンの配置や、文字の書体といったごく詳細な部分の微調整までは、ここでいう仕様変更には該当しないということです。該当箇所は以下の通りです。
もっとも、ソフトウエア開発においては、その性質上、外部設計の段階で画面に文字を表示する書体やボタンの配置などの詳細までが決定されるものではなく、詳細については、仕様確定後でも、当事者間の打合せによりある程度修正が加えられるのが通常であることに鑑みると、このような仕様の詳細化の要求までも仕様変更とすることは相当でないというべきである。
大阪地裁平成１４年８月２９日判決
判決文では、「仕様の詳細化」という興味深いワードが用いられました。
- すでに決まっていたはずのものを後から覆したという場合
- やりながら決めていけばいいものに関して、あえて決めずに進めていったという場合
では、法律上の扱いも異なって然るべきであるという考えを示したものとも言えるでしょう。
その他の肯定例
その他に、追加開発・機能の修正と認められた事案には、
- 当初の予定よりも納品したプログラムの本数が約倍に増えた事例（東京地裁17年4月22日判決）
- 作業期間が約三倍にのびた事例（東京地裁平成22年1月22日判決）
などがあります。このように整理してみると、作業期間の延長というものも、広義の追加開発として、一定の法的保護を受けられるようするという考え方が採用されていることがわかります。
「追加開発に関する合意や報酬増額」と「当初契約の成立」は別の問題
なお、これらの問題に関する重要なポイントですが、
- 「そもそも2企業間でシステム開発に関する契約（当初契約）が正式に成立したのか」という場面
- 「一旦正式に成立したシステム開発について、追加開発に関する契約が（も）追加で成立したのか」という場面
で、裁判所の判断基準は異なっています。端的に言うと、裁判所は、
- 1に関しては厳しい（契約書のない場面では契約成立をなかなか認めてくれない）傾向がある
- 2に関しては比較的甘い（追加開発に関する契約書がなくても、報酬増額などを柔軟に認めてくれる）傾向がある
といえます。1に関しては別記事で詳細に解説しています。
否定例：法律上は同様の委託内容のなかに含まれるものと扱われた事例
しかし一方で、報酬の増額が認められなかった裁判例もあります。下記に引用する判決文の事案では、システム開発の契約につき、一度業務委託契約が締結された後に業務の内容が変更されたことから、報酬の増額が認められるかが争われました。
本件の争点は、（１）本件契約において原告が受託した業務の内容は何か、（２）右受託業務について、原告及び被告間で規模を拡大し代金を増額する旨の合意が成立したか、（中略）、という点にある。（中略）
そもそも、本件契約は、その代金額をもって原告の受託業務（請負）に対する確定の対価とする旨合意した請負契約であり、受託業務に係るステップ数、単価等は、原告内部において請負代金額を算定する際の内部資料に過ぎず、ステップ数の増加等の事情は、請負代金とは全１無関係である。（中略）
前記認定のとおり、原告の受託業務が昭和六二年二月二五日に変更され、システム管理、請負工事費積算及びユーティリティの一部のみに限定され、その余は被告が担当することになったか、右変更後の原告の業務は当初の契約内六に従った開発業務の範囲内であることに変わりはなく、右業務に関する対価は、本件契約当初に確定代金として約定されている委託代金額ですべてカバーされているものである。
東京地裁平成７年６月１２日判決
当該判決においては、ベンダーに受託される業務の内容が変更されていたとしても、その開発内容は当初の契約内容の範囲内に収まるものであるとし、当初約束されていた報酬のなかでカバーされるべきものであると判断されました。
結局は、報酬額がどのような業務をやることを前提として決められたものなのかを考慮のうえで、そこに含まれない業務については、追加の報酬請求を認めていくというスタンスであるものと考えられます。
そして、そもそも報酬額がどのような業務を行うことの対価であったかは、必ずしも契約書のみならず、議事録なども証拠として判断されることになります。議事録の重要性に関しては下記記事にて詳細に解説しています。
追加開発・機能の修正における報酬額はどう決まるか
システム開発の現場において、一度確定したかにみえた仕様が後から変わるということは決して珍しいことではありません。こうしたことが起きるたびに、新たに書面の契約書を準備し、契約事務を進めるということは現実的ではないでしょう。追加・修正すべき事項について、再度その仕様内容を確定し直して、まとめて覚書などを締結できる場合はともかくとして、こうした手続きも行えぬままプロジェクトが頓挫したような場合にはどのように報酬金額を算定すればよいのでしょうか。
こうした場合に参考にすべき条文としては、以下に引用する商法512条があります（下線部は筆者が引いたものである。）。
商法512条：商人がその営業の範囲内において他人のために行為をしたときは、相当な報酬を請求することができる。
この条文における「相当な報酬」というのが、具体的場面に即して、結局いくらになるのかという点が問題になります。過去の裁判例をみるに、作業の工数や分量、あるいは期間に比例して、そのコストを負担すべきであるという考え方が採用されているように見受けられます。これはシステムの開発業務というものが、その性質上一種のサービス業であり、原価が基本的に人件費であることに起因するものであるからでしょう。
したがって、商法上の「相当な報酬」という文言の抽象度とは裏腹に、こういった文脈における追加報酬の金額の相場を見積もることは、そこまで難しい計算を要するわけではありません。以下に、いくつか裁判例を見てみることにしましょう。
ケース１：工数の増加に比例した追加報酬を認めた事例
本件仕様変更に基づく開発工数は、上記工数の合計である２５７．５人／日とみるのが相当であり、これを１人／日当たりの開発費用を本件開発委託契約と同じ３万２５００円（甲３では、単価は６５万円〔１人／月当たり〕であり、一月の稼働日数を２０日とすると、１人／日当たりの開発費用は３万２５００円となる。）として換算すると、本件仕様変更要求に基づく追加開発費用は、８３６万８７５０円とするのが相当である。
大阪地裁平成１４年８月２９日判決
「1人/日当たり」というのがキーワードです。追加報酬の計算根拠に、工数を用いていることを表しています。
ケース２：プログラムの本数に比例した追加報酬を認めた事例
本件における追加分を含めた相当額の報酬金額について検討すると，コンピューターシステムの開発の原価の大部分が技術者の人件費であり，その人件費は作成するプログラムの分量に概ね比例することにかんがみれば，当初の契約金額である２３２５万円を二次検収までに完了した２０６本のプログラム数で除し，このプログラム１本当たりの単価に三次検収を経たプログラム数４１４本を乗じた金額４６７２万５７２８円（２３，２５０，０００÷２０６×４１４＝４６，７２５，７２８）をもって相当と認める。
東京地裁平成１７年４月２２日判決
数字がたくさん出てきていますが、落ち着いて読めば難しい計算をやっているわけではないこともわかるでしょう。当初の契約内容をもとに、「一本当たりのプログラムの単価をいくらと見積もって話をしていたのか」を確認したうえで、「単価×数量」というシンプルな掛け算をしているにすぎません。
ケース３：期間の長さに比例した追加報酬を認めた事例
そして，甲３契約において原告の平成１７年１月から３月までの３か月間の期間における準委任としての作業の対価として，６０００万円が定められているところ，同年４月以降の作業には無償で行う作業が含まれている一方，前年同様，同年３月までの期間に比して新学期の開始により履修登録等のシステムが稼働される同年４月以降の作業量が増加したことが想定される。これらのことからすれば，上記３か月間の作業の対価として定められた６０００万円を基礎に，原告の平成１７年４月から９月の６か月間の作業に対する報酬は，１億２０００万円とすることが相当である。
東京地裁平成２２年１月２２日判決
上記判決は、延長した期間についても、シンプルな比例計算で追加報酬を計算していく旨を示しています。
まとめ
上記のようにいくつか裁判例を並べてみると、プログラマ・エンジニアの仕事の追加報酬というものの法律上の扱いについて、ある種の法則性・共通点も見えてくるように思われます。すなわち原則論としては、かけた工数・（納品したプログラムなどの）形式的な作業量・働いた時間や期間といったような、比較的客観性の高い指標に基づいて、なるべくシンプルに計算していこうとしている姿勢が見て取れるでしょう。
厳密な意味での手順化や、完璧な工数の見積りに現に失敗しているからこそ、こうした追加開発や機能の修正が発生しているということから考えれば、人手をつぎ込んだ分だけ、あるいはやった作業の形式的な分量だけ、かけた時間だけ、追加の報酬が発生するというのは、なんとも味も素っ気もない話に思えるかもしれません。しかし、あくまで受託者側の目線でいうならば、たとえ顧客の利益を優先しながらの業務の遂行を目指すにしても、こうした権利が法律上も認められる公算があるというのは、ある種の危機管理上の話としても意味のあることなのではないでしょうか。
