システム開発で追加費用を請求できる場合とは？３つのポイントを解説

はじめに

システム開発などの現場では、作業を進めていくにつれて、頻繁に仕様変更をしますよね。 特に大規模なシステム開発になればなるほど、作業段階での仕様変更やそれに伴う作業量は増加していきます。 仕様変更に際して問題となるのは、費用面です。 仕様変更に伴い発生する追加費用について、予め当事者間で契約していれば、問題はあまり起きません。 他方で、システム開発あるあるで、ベンダがクライアントの意向を確認することなく、独断で仕様変更をして、追加費用を請求することがよくあります。 このように、ベンダがクライアントとの間で明示的な合意なく仕様変更をした場合にも、ベンダは、報酬を請求できるのでしょうか？

１　追加費用でトラブルになるケースとは

システム開発の現場では、プロジェクトが進行するにつれて、当初の想定とは違った機能が必要になり、それに伴う仕様変更が頻繁に生じます。 しかし、仕様変更が生じるたびに、いちいち追加で見積もりを提示し、契約書を作り直すのは、正直面倒です。 そのため、ベンダは、クライアントとの信頼関係を前提に、契約書を巻きなおすことなく、追加作業をしてしまうのが実情です。 信頼関係が築けている間はこの運用でもよいのですが、何らかの行き違いによって信頼関係が崩れたときには、追加費用についてトラブルになります。 ベンダとしては、もはや取引をすることもないと考えて、無遠慮に追加費用を含めた費用全額を請求します。 他方、クライアントとしても、ここぞとばかりに「仕様変更に合意していない」という原則論を持ち出して、追加費用はもちろん、当初の費用すら払おうとしません。 最初は、裁判外で交渉するのですが、それでも決着がつかない場合に、しびれを切らしたベンダが訴訟を起こすことでトラブルが深刻化します。

２　契約なき追加費用は請求できないのが原則

このように、ベンダ・クライアント間で追加費用の契約書を作らなかった場合、ベンダは、クライアントに対して、追加費用の請求ができるのでしょうか？ 結論からいますと、原則として、追加費用の請求はできません。 法律の世界には、契約自由の原則という考え方があります。 これは、人が権利を取得したり義務を負うのは、あくまでもその旨を明確に契約した場合に限定される、という原則です。裏を返すと、契約をしない限り、人は、原則として、法的に他人に対して何かを求めたり、義務付けたりできないということです。 この原則があるため、ベンダがたとえ仕様変更に伴ない追加作業をしたとしても、追加費用を支払う旨を契約書に明記しない限り、クライアントに追加費用の請求ができないことになります。

３　契約がない場合でも追加費用を請求できる例外とは？

では、契約書に報酬に関する記載がない場合には、一切、追加作業分の報酬を請求できないのでしょうか？ 実は、以下の2つのケースでは、たとえ契約書に報酬の記載がない場合でも、追加報酬の支払いを請求できます。

（１）商法512条に基づく「相当な報酬請求」

ビジネスの基礎的な部分を取り締まる法律である「商法」には、以下のように規定されています。

第512条（報酬請求権） 商人がその営業の範囲内において他人のために行為をしたときは、相当な報酬を請求することができる。

これは、商売人が他人のためにボランティアで動くことはなく、必ず見返りを期待して動くはず、というビジネスの実態を反映したものです。 そのため、企業がクライアントのために活動した場合には、たとえ契約がなかったとしても、「相当な報酬」を請求できることにしたのです。 これは、システム開発の追加費用についてもあてはまります。 そのため、システム開発の現場では、明確な合意がなかったとしても、商法512条に基づいて、「相当な報酬」をクライアントに請求できることになります。 では、具体的にいくらの報酬を請求できるのでしょうか？ ここでポイントとなるのは、「相当な報酬」の解釈です。 判例では、「相当な報酬」について、開発期間、プログラム数やステップ数あたりの単価を計算し、それに開発期間やプログラム数などを掛け算して算出した額を、「追加費用の額」としています。 このように、システム開発においても、ベンダが無償で追加作業をするはずはないとの考えのもとに、裁判所は、商法512条に基づき、増加した追加作業分の報酬請求を認めています。 もっとも、追加作業をしさえすれば、どんなケースでも追加作業分の報酬請求が認められるわけではありません。 追加作業分の報酬請求をするためには、最低限、あらかじめ、

1. 追加作業には別途費用が発生することを文書（メールを含む。）で示していること
2. 事前に取り決めた仕様変更する場合の約束事（例：クライアントにお伺いを立てるなど。）をベンダが破っていないこと

が必要です。 なぜなら、クライアントとしては、自分が全くあずかり知らないところで勝手に仕様変更をされて、それで「追加作業をしたからカネを払ってくれ」と言われても有難迷惑だからです。 また、「仕様変更する場合には追加費用が発生する」旨が契約書に書かれていない場合でも、仕様変更のルールが記載されているケースでは、当然、ベンダとしてはそのルールを守るべきだからです。 この２つの最低限のルールを守って入れば、ベンダは、独断で追加作業をすすめたとしても、追加費用の請求ができます。 反対に、クライアントが作業途中でどんどんとオプション的な発注をして作業内容が大きく変わっていったとしても、「文書（メールも含む。）で追加費用がかかることを提示」されていないケースでは、追加報酬の支払いを拒否するという可能性も出てくるのです。 契約当事者双方の利益を守り、紛争を避けるためにも、上記①・②は、必要な条件と言えます。

（２）裁判例に基づく報酬請求

裁判例によれば、契約書に記載がない場合であっても、一定の条件をみたせば、ベンダはクライアントに対して、追加報酬を請求できるとされています。 【裁判例の事案】 当初182本であったプログラム数が、最終的に414本まで増加したという大幅な仕様変更があった場合に、追加費用の請求が認められるか、という事案(東京地判平成17年4月22日) このケースでは、見積書に「作業着手後の機能追加，変更等により工数に大幅な変動が生じた場合は別途相談させていただきます」と書かれており、この点の解釈が問題となりました。 裁判所は、見積書の記載について、契約書の法的効力は同じではないとしつつ、

1. 当初ベンダ側が受注した業務内容と金額が明確になっていること
2. 当初依頼された業務の範囲を超過して稼働したことが明確になっていること

という条件を満たしている場合には、契約書に記載がない場合であっても、ベンダからの追加費用の請求ができるとし、実際に、追加費用の支払いを認めています。

４　未然にトラブルを防止する方法

これまでは、契約書に記載がない場合でも報酬が認められる場合を解説してきました。 では、未然にこういったトラブルを防止する方法はないのでしょうか？

（１）綿密な要件定義

仕様変更が珍しくないシステム開発の契約では、システムの仕様ではなく、クライアントの「こんなシステムにしたい」という要望を予めキチンと決めておくことが大事です。 このように、「あなたが欲しい商品は、これです！」という形でクライアントの要望を定義する作業を「要件定義」といいます。 追加費用に関しては、そもそも、開発に着手する前の時点で、要件定義をしっかりしていれば、仕様変更は起きないのです。 この要件定義の作業をルーズにして開発を進めていくからこそ、「当初の予定とは違ったから仕様を変更する」といったことが起きるのです。 そのため、システムの仕様ばかりに気をとられず、開発に着手する前の段階で、要件定義をきちんとすることがトラブルの予防につながります。

（２）綿密なコミュニケーション

要件定義を基準に契約や開発準備をスムーズに進めるためには、クライアントとベンダの綿密なコミュニケーションがポイントとなります。 例えば「このアイコンは画面のこの位置がいい」「ここはロックしてほしい」なというような細かい内容まで、クライアントの要望をしっかりと把握しておく必要があります。 綿密な打ち合わせをすることで、システム開発には「いわなくても解るだろう」という概念は通用しない事をクライアントにも認識してもらうこともできます。 コミュニケーションの時間やコストを惜しまずにしっかりと綿密な打ち合わせをすることがトラブルを未然に回避することになります。

（３）契約書を整備する

要件定義やコミュニケーションも大切ですが、そのやりとり文書化した書面があるのが一番です。 システム開発の契約書には、

1. 仕様変更に伴う追加の費用が発生すること
2. 契約のタイプが請負契約なのか、準委任契約なのか

をきちんと記載しておくことがポイントになります。 「請負契約」とは、ベンダの裁量で仕事を遂行し、システムなどの成果物を完成させる義務を負う契約をいいます。 請負契約では、仕事の完成が目的ですから、依頼を受けたシステムをキチンと完成させて、納品する義務まで負います。 その結果、バグのないシステムを納品しない限り、報酬を払ってもらえません。 その意味で、請負契約は大型契約になるほど、ベンダのリスクが高い契約形態といえます。 「準委任契約」とは、 一定の行為・事務をすることをベンダに委託する契約のことをいいます。 準委任契約では、仕事の完成義務はなく、たんに、依頼された事務を処理すれば足ります。 そのため、システムを完成したかどうかに関係なく、報酬を受けとることができます。 ＩＴの現場でよく利用される「ＳＥＳ契約」では、「時間あたり〇〇円」という形で報酬額が決められることが多いため、準委任契約に分類できます。 このように、契約タイプによって、ベンダに課せされる義務の内容や報酬をもらえる条件が違ってくるため、いずれの契約形態なのかをきちんと契約書上でわかるように書いておきましょう。 なお、ＳＥＳ契約の法的な性質や契約タイプ別のメリット・デメリットを詳しく知りたい方については、「SES契約は労働者派遣（偽装請負）？違法にならないための５つのポイント」や「SES契約は税務上、委任・雇用・請負？税務リスク回避の方法を解説」をお読みください。

（４）多段階契約にする

このように、請負契約と準委任契約は、それぞれ違うタイプの契約です。 ところが、実は、複雑な作業になりやすいシステム開発では、このふたつの契約タイプが合体した契約をすることがあります。 システムを作り上げるまでのプロセスは、①要件定義→②システムの設計→③開発→④運用テスト→⑤完成といった段階をたどります。 プロセスの各段階に応じて、それぞれの作業内容にあった契約形態を選択していく手法を「多段階契約」といいます。 そもそも、システム開発のような大規模で複雑な作業が予想される場合に、まだ設計にも至っていない開発計画について、包括的にひとつの契約（これを「一括請負契約」といいます。）でまとめてしまうことに無理があるのです。 請負契約ではそのリスクのほとんどをベンダが負担する事になりますし、反対に、準委任契約では柔軟性があり、ベンダには都合がよい反面、クライアントにはリスクです。 このように、契約のタイプごとに、メリット・デメリットがあることから、作業の内容やステージに応じて、クライアントとベンダ両方にとって利益になる契約形態を選択していくことが、トラブル防止には有益です。 そのため、システム開発の現場では、多段階契約の形で開発ををすするのがベターです。

５　まとめ

これまでの解説をまとめますと、以下のようになります。

• • ベンダは、契約自由の原則により、契約書に書かれていない限り、クライアントに対して、追加費用の請求をすることはできない。
  • ただ、この原則には、2つの例外がある。

①商法512条に基づく「相当な報酬」の請求 ②裁判例に基づく請求

• • いずれの例外も、無条件に認められるわけではなく、一定の条件をクリアする必要がある。
  • 特に、裁判例に基づく請求については、

①当初受注した業務内容と金額が明確になっていること、 ②依頼された業務の範囲を超過して稼働したことが明確になっていることが必要。

• • システム開発に伴う仕様変更は、珍しい事ではなく、むしろ普通のこと。そのため、「あるわけない」と考えるのではなくむしろ「仕様変更は当然あるもの」と考えておくべき。
  • トラブルを未然に防止するためには、以下のポイントを守ることが大事。

①要件定義をきちんとする ②コミュニケーションをたくさんとる ③契約のタイプが請負なのか準委任なのかを明確にする ④多段階契約にする