Satはじめにシステム開発などの現場では、作業を進めていくにつれて、頻繁に仕様変更をしますよね。大規模なシステム開発になればなるほど、作業段階での仕様変更やそれに伴う作業量は増加していきます。仕様変更に際して問題となるのは、費用面です。仕様変更に伴い発生する追加費用について、予め当事者間で契約していれば、問題はあまり起きません。他方で、システム開発あるあるで、ベンダがクライアントの意向を確認することなく、独断で仕様変更をして、追加費用を請求することがよくあります。このように、ベンダがクライアントとの間で明示的な合意なく仕様変更をした場合にも、ベンダは、報酬を請求できるのでしょうか?目次1、追加費用でトラブルになるケースとは2、契約なき追加費用は請求できないのが原則3、契約がない場合でも追加費用を請求できる例外とは?(1)商法512条に基づく「相当な報酬請求」(2)裁判例に基づく報酬請求4、未然にトラブルを防止する方法(1)綿密な要件定義(2)綿密なコミュニケーション(3)契約書を整備する(4)多段階契約にする5、まとめ1、追加費用でトラブルになるケースとはシステム開発の現場では、プロジェクトが進行するにつれて、当初の想定とは違った機能が必要になり、それに伴う仕様変更が頻繁に生じます。仕様変更が生じるたびに、いちいち追加で見積もりを提示し、契約書を作り直すのは、正直面倒です。そのため、ベンダは、クライアントとの信頼関係を前提に、契約書を巻きなおすことなく、追加作業をしてしまうのが実情です。信頼関係が築けている間はこの運用でもよいのですが、何らかの行き違いによって信頼関係が崩れたときには、追加費用についてトラブルになります。ベンダとしては、もはや取引をすることもないと考えて、無遠慮に追加費用を含めた費用全額を請求します。他方、クライアントとしても、ここぞとばかりに「仕様変更に合意していない」という原則論を持ち出して、追加費用はもちろん、当初の費用すら払おうとしません。最初は、裁判外で交渉するのですが、それでも決着がつかない場合に、しびれを切らしたベンダが訴訟を起こすことでトラブルが深刻化します。2、契約なき追加費用は請求できないのが原則このように、ベンダ・クライアント間で追加費用の契約書を作らなかった場合、ベンダは、クライアントに対して、追加費用の請求ができるのでしょうか?結論からいますと、原則として、追加費用の請求はできません。法律の世界には、契約自由の原則という考え方があります。これは、人が権利を取得したり義務を負うのは、あくまでもその旨を明確に契約した場合に限定される、という原則です。裏を返すと、契約をしない限り、人は、原則として、法的に他人に対して何かを求めたり、義務付けたりできないということです。この原則があるため、ベンダがたとえ仕様変更に伴ない追加作業をしたとしても、追加費用を支払う旨を契約書に明記しない限り、クライアントに追加費用の請求ができないことになります。報酬を請求できないのでしょうか?実は、以下の2つのケースでは、たとえ契約書に報酬の記載がない場合でも、追加報酬の支払いを請求できます。(1)商法512条に基づく「相当な報酬請求」ビジネスの基礎的な部分を取り締まる法律である「商法」には、以下のように規定されています。第512条(報酬請求権)商人がその営業の範囲内において他人のために行為をしたときは、相当な報酬を請求することができる。これは、商売人が他人のためにボランティアで動くことはなく、必ず見返りを期待して動くはず、というビジネスの実態を反映したものです。そのため、企業がクライアントのために活動した場合には、たとえ契約がなかったとしても、「相当な報酬」を請求できることにしたのです。これは、システム開発の追加費用についてもあてはまります。そのため、システム開発の現場では、明確な合意がなかったとしても、商法512条に基づいて、「相当な報酬」をクライアントに請求できることになります。具体的にいくらの報酬を請求できるのでしょうか?ここでポイントとなるのは、「相当な報酬」の解釈です。判例では、「相当な報酬」について、開発期間、プログラム数やステップ数あたりの単価を計算し、それに開発期間やプログラム数などを掛け算して算出した額を、「追加費用の額」としています。このように、システム開発においても、ベンダが無償で追加作業をするはずはないとの考えのもとに、裁判所は、商法512条に基づき、増加した追加作業分の報酬請求を認めています。追加作業をしさえすれば、どんなケースでも追加作業分の報酬請求が認められるわけではありません。追加作業には別途費用が発生することを文書(メールを含む。)で示していること事前に取り決めた仕様変更する場合の約束事(例:クライアントにお伺いを立てるなど。)をベンダが破っていないことが必要です。クライアントとしては、自分が全くあずかり知らないところで勝手に仕様変更をされて、それで「追加作業をしたからカネを払ってくれ」と言われても有難迷惑だからです。「仕様変更する場合には追加費用が発生する」旨が契約書に書かれていない場合でも、仕様変更のルールが記載されているケースでは、当然、ベンダとしてはそのルールを守るべきだからです。この2つの最低限のルールを守って入れば、ベンダは、独断で追加作業をすすめたとしても、追加費用の請求ができます。反対に、クライアントが作業途中でどんどんとオプション的な発注をして作業内容が大きく変わっていったとしても、「文書(メールも含む。)で追加費用がかかることを提示」されていないケースでは、追加報酬の支払いを拒否するという可能性も出てくるのです。契約当事者双方の利益を守り、紛争を避けるためにも、上記1・2は、必要な条件と言えます。裁判例によれば、契約書に記載がない場合であっても、一定の条件をみたせば、ベンダはクライアントに対して、追加報酬を請求できるとされています。当初182本であったプログラム数が、最終的に414本まで増加したという大幅な仕様変更があった場合に、追加費用の請求が認められるか、という事案(東京地判平成17年4月22日)このケースでは、見積書に「作業着手後の機能追加,変更等により工数に大幅な変動が生じた場合は別途相談させていただきます」と書かれており、この点の解釈が問題となりました。当初ベンダ側が受注した業務内容と金額が明確になっていること当初依頼された業務の範囲を超過して稼働したことが明確になっていることという条件を満たしている場合には、契約書に記載がない場合であっても、ベンダからの追加費用の請求ができるとし、実際に、追加費用の支払いを認めています。4、未然にトラブルを防止する方法これまでは、契約書に記載がない場合でも報酬が認められる場合を解説してきました。仕様変更が珍しくないシステム開発の契約では、システムの仕様ではなく、クライアントの「こんなシステムにしたい」という要望を予めキチンと決めておくことが大事です。このように、「あなたが欲しい商品は、これです!」という形でクライアントの要望を定義する作業を「要件定義」といいます。追加費用に関しては、そもそも、開発に着手する前の時点で、要件定義をしっかりしていれば、仕様変更は起きないのです。この要件定義の作業をルーズにして開発を進めていくからこそ、「当初の予定とは違ったから仕様を変更する」といったことが起きるのです。そのため、システムの仕様ばかりに気をとられず、開発に着手する前の段階で、要件定義をきちんとすることがトラブルの予防につながります。(2)綿密なコミュニケーション要件定義を基準に契約や開発準備をスムーズに進めるためには、クライアントとベンダの綿密なコミュニケーションがポイントとなります。「このアイコンは画面のこの位置がいい」「ここはロックしてほしい」なというような細かい内容まで、クライアントの要望をしっかりと把握しておく必要があります。綿密な打ち合わせをすることで、システム開発には「いわなくても解るだろう」という概念は通用しない事をクライアントにも認識してもらうこともできます。コミュニケーションの時間やコストを惜しまずにしっかりと綿密な打ち合わせをすることがトラブルを未然に回避することになります。(3)契約書を整備する要件定義やコミュニケーションも大切ですが、そのやりとり文書化した書面があるのが一番です。仕様変更に伴う追加の費用が発生すること契約のタイプが請負契約なのか、準委任契約なのかをきちんと記載しておくことがポイントになります。「請負契約」とは、ベンダの裁量で仕事を遂行し、システムなどの成果物を完成させる義務を負う契約をいいます。請負契約では、仕事の完成が目的ですから、依頼を受けたシステムをキチンと完成させて、納品する義務まで負います。その結果、バグのないシステムを納品しない限り、報酬を払ってもらえません。その意味で、請負契約は大型契約になるほど、ベンダのリスクが高い契約形態といえます。一定の行為・事務をすることをベンダに委託する契約のことをいいます。準委任契約では、仕事の完成義務はなく、たんに、依頼された事務を処理すれば足ります。そのため、システムを完成したかどうかに関係なく、報酬を受けとることができます。ITの現場でよく利用される「SES契約」では、「時間あたり〇〇円」という形で報酬額が決められることが多いため、準委任契約に分類できます。このように、契約タイプによって、ベンダに課せされる義務の内容や報酬をもらえる条件が違ってくるため、いずれの契約形態なのかをきちんと契約書上でわかるように書いておきましょう。?税務リスク回避の方法を解説」をお読みください。(4)多段階契約にするこのように、請負契約と準委任契約は、それぞれ違うタイプの契約です。ところが、実は、複雑な作業になりやすいシステム開発では、このふたつの契約タイプが合体した契約をすることがあります。システムを作り上げるまでのプロセスは、1要件定義→2システムの設計→3開発→4運用テスト→5完成といった段階をたどります。プロセスの各段階に応じて、それぞれの作業内容にあった契約形態を選択していく手法を「多段階契約」といいます。そもそも、システム開発のような大規模で複雑な作業が予想される場合に、まだ設計にも至っていない開発計画について、包括的にひとつの契約(これを「一括請負契約」といいます。)でまとめてしまうことに無理があるのです。請負契約ではそのリスクのほとんどをベンダが負担する事になりますし、反対に、準委任契約では柔軟性があり、ベンダには都合がよい反面、クライアントにはリスクです。このように、契約のタイプごとに、メリット・デメリットがあることから、作業の内容やステージに応じて、クライアントとベンダ両方にとって利益になる契約形態を選択していくことが、トラブル防止には有益です。そのため、システム開発の現場では、多段階契約の形で開発ををすするのがベターです。5、まとめこれまでの解説をまとめますと、以下のようになります。ベンダは、契約自由の原則により、契約書に書かれていない限り、クライアントに対して、追加費用の請求をすることはできない。この原則には、2つの例外がある。1商法512条に基づく「相当な報酬」の請求2裁判例に基づく請求いずれの例外も、無条件に認められるわけではなく、一定の条件をクリアする必要がある。裁判例に基づく請求については、1当初受注した業務内容と金額が明確になっていること、2依頼された業務の範囲を超過して稼働したことが明確になっていることが必要。システム開発に伴う仕様変更は、珍しい事ではなく、むしろ普通のこと。そのため、「あるわけない」と考えるのではなくむしろ「仕様変更は当然あるもの」と考えておくべき。トラブルを未然に防止するためには、以下のポイントを守ることが大事。法律の悩みを迅速に解決します。スタートアップ、IT、先端技術の法律相談なら私たちにお任せください!豊富な契約書雛形もご用意していますので、IT企業に関わらずお気軽にお問い合わせください。