システム開発契約成立時におけるトラブルとその防止方法

1. システム開発契約の概要

一般的に、システム開発は、①要件定義の確定、②基本設計の構築、③実際の開発、④システムテストという4つの工程に即して進行します。これらの工程のそれぞれについて、民法上の請負契約(民法632条(※1))または準委任契約(656条(※2))のいずれかとして解釈され、当事者の義務や責任が判断されます。

民法上の請負契約とされた場合と準委任契約とされた場合とでは、以下のとおり、当事者の義務や解除の範囲が異なってきます。

請負契約 準委任契約
委託する内容 仕事の完成 事務の処理
責任 納期遅延の場合の債務不履行責任

不具合がある場合の瑕疵担保責任 等

善良なる管理者の注意を払っていない場合の債務不履行責任
受託者の義務 仕事を完成させる義務 善良なる管理者の注意をもって事務の処理を行う義務
解除 解除の効力は遡及する

注文者からの一方的解除も可能

(損害賠償責任あり)

解除の効力は遡及しない

双方からの解除可能

(損害賠償責任あり)

報酬請求権 要件として仕事の完成と引渡しが求められる 仕事の完成は必ずしも要件とはならない

このうち、①要件定義の確定と④システムテストは準委任契約、②基本設計の構築と③実際の開発は請負契約と解釈されるのが一般的です。

※1 民法632条
「請負は、当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約することによって、その効力を生ずる。」
※2  民法656条
「この節の規定は、法律行為でない事務の委託について準用する。」

そして、以上の図のように、業務全体を束ねる形で基本契約を締結することが多いといえます。基本契約とは、各個別契約に共通する条項をまとめる基本的な条項を定めたものです。

2. 途中で頓挫した場合、費用はどうなるのか?

以上のような4つの主要工程が滞りなく進行して業務が完了すれば問題はないのですが、途中の段階で頓挫した場合には、頓挫するまでに実施した業務に関する報酬や費用をどう精算すべきか、争いになることがあります。

通常、プロジェクト開始時点では未確定となっている事項が多いですから、初期段階から一括請負方式の契約を締結したと解釈することは非現実的であると考えられます。そのため、ベンダー側が、一括請負方式ではないと主張して、途中までの報酬を請求することも可能です。

しかし、これに対して、ユーザー側からは、プロジェクト全体が一体の請負契約であるとして、完成されていない以上は報酬の一切を支払わないなどと、支払いを拒まれることがあります。

このようなトラブルを防止するためには、ベンダー側としては、①要件定義の確定などの初期段階では準委任契約方式で契約を締結し、その後、要件定義がすべて決まったら、②システム設計、③開発、④システムテストの各段階に分けて、請負方式の契約を締結することが重要です。

その際、ベンダーは、ユーザーに対し、(1)開発スケジュール、規模、スコープの全体像が見通せるところで、全体の費用や契約内容が確定すること、(2)契約内容の確定時期をスケジュールに盛り込むことを伝えるべきかと思います。

実際、経産省がウェブサイトにあるモデル契約書でも、工程別分割発注をすることを前提にしています。(http://www.meti.go.jp/policy/it_policy/keiyaku/)。これは、ウォーターフォールモデルを想定しており、対等な交渉力を有するIT事業者と民間大手企業を想定してのものではありますが、マルチベンダ形態、工程別分割発注に対応しています。

このように、工程別に分割して発注する方式で契約を締結していれば、プロジェクトが途中で頓挫したとしても、すでに完了した工程についてはその報酬を請求できる可能性が高まります。ベンダー側にとっては有利な結果となりますので、ベンダー側の方は是非個別発注方式での契約を検討してみてください。

3. 契約書を交わしていない場合にはどうなるか?

(1)契約の成立

契約書を取り交わした場合は、当然、契約が成立していると認められますが、契約書を取り交わしていない場合、ユーザー側から「契約が成立していないのだから、ユーザーはベンダーに対して代金を支払う義務は生じないのではないか」と主張されることがあります。

例えば、A社の営業マンa氏が、B社のb課長と新販売システム構築に関する商談を行っていたところ、b課長は「A社に頼む見込みだから、チーム編成と作業準備にかかってくれ」とお願いしたという事例で考えて見ましょう。A社は早速従業員ほか、協力会社も含めてメンバーを集め、B社に「契約書案」を提出した上で、作業準備に取り掛かりましたが、契約書は署名・捺印されていません。6週間後に、b課長からa氏に「結局予算が下りず、会社から待ったがかかった。申し訳ない。」と伝えたところ、a氏は「要件定義はほぼ終わっている。成果物を提出するので代金を払ってください。」と揉めることになりました。

この場合、要件定義の確定について準委任契約が成立していれば、「委託者による解除」だといえるため、損害賠償としての作業分の報酬相当額を請求できそうではあります。準委任契約の場合、「当事者の一方が相手方に不利な時期に委任の解除をしたときは、その当事者の一方は、相手方の損害を賠償しなければならない。」(民法651条2項)からです。

このように、b課長の「口頭での依頼」と、「契約書(案)」だけでは、契約成立が認められないとされて、無償の営業活動と評価されて終わってしまうおそれがあるので、契約が成立しているか否かが大きな争点となることがあるのです。

(2)契約の成立についての裁判例

ここで、システム開発業務について契約が成立しているか否かが争点となった裁判の事案を紹介しますと、以下のようなものがあります。

名古屋地裁平成16年1月28日判決では、①ベンダーの提出した提案書が必ずしもユーザーの業務内容を十分検討した具体的なものではなかったこと、②ユーザーが採用通知を出しているとしても、交渉の相手方を絞り込んだという意味を有するにとどまること、③カスタマイズの有無等仕様確認を経てからカスタマイズの範囲や費用の合意が取れた段階で契約が成立することが予定されていた、という点を根拠に、裁判所は契約の成立を否定しました。

その他の否定例としては、東京地裁平成20年9月30日判決と東京地裁平成19年11月30日判決等があります。否定例である東京地裁平成20年9月30日判決では、正式には上層部の決裁が必要であったことは双方了解しており、契約書も案文のやり取りにとどまっていたことから、契約は成立していないとしています。さらに東京地裁平成19年11月30日判決では、前半フェーズでは書面による注文があったが、後半フェーズで書面がなかった等により、後半フェーズについては契約が成立していないとしています。

このように、企業間取引において、契約書が取り交わされていない場合、訴訟等では契約成立が容易に認められにくい傾向にあります。定型的な低額の取引ではなく、個別的な高額の取引の場合、契約書案をわたすということは、サインして初めて契約が成立するということが合意されていたと判断されます。契約書のやり取りをしながら、サインに至っていないのであれば契約の成立は認めにくいということです。

他方で、開発業務全体についての契約が成立したと認定せずに、業務の一部についての契約を肯定する例もあります。その裁判例である東京地裁平成21年9月4日判決は、システム開発総額の見積書が提示されたものの、開発範囲はパッケージが備える機能とユーザー企業の業務の「適合部分(fit)」および「かい離部分(gap)」を調べる作業であるFit&Gapの結果によって決まるなどの記載に照らすと、開発契約は成立していないが、パッケージライセンス契約と要件定義にかかる契約は成立していると判示しています。

4. 契約が成立していないと何も請求できないのか?

(1)契約締結上の過失による損害賠償請求の可能性

3で見たように、契約書が締結されていない場合、ベンダーは契約に基づく報酬やキャンセルに伴う賠償請求をできないのが原則です。

しかし、契約が成立していなければ例外なくベンダーが泣き寝入りなのかといわれれば、そうではありません。契約が成立していなくとも、ベンダーはユーザーに対して契約締結上の過失に基づく損害賠償請求をできる可能性があります。

(2)契約締結上の過失とは

契約締結上の過失とは、民法1条2項より導かれるもので、契約成立過程における一方当事者の故意または過失によって、相手方が損害を被った場合には、一定の要件を満たせば、何らかの責任を肯定すべきという法理です。民法1条2項は、契約は、当事者が相互に信頼しあって締結し、契約関係にある当事者は相互に相手方の信頼に応えるように誠実に行動しなければならないことを定め、信義誠実の原則(信義則)による義務が発生することを示しています。契約における信義則上の義務の一つとして、契約締結上の注意義務があり、契約当事者は、無効な契約締結のすることのないようにする注意義務をいいます。この注意義務を怠って契約の相手方に不測の損害を与えた場合は、契約締結上の過失責任が問題になります。

契約締結上の過失が認められる要件としては、①契約締結交渉の成熟度が高いこと、②信義則違反と評価される帰責性があることです。

①の成熟度の評価にあたっては、代金等の契約の主要部分の合意状況や契約書等の書面提示の状況、内金等のやり取りの有無を見ることとなります。②については、信頼を発生させる行為とその信頼を裏切る行為があること、具体的には、契約締結を妨げる事情を知っていたのに相手方にこれを伝えないまま交渉を継続したことや、相手方の準備行為を援助したりして契約締結の意思があるかのように誤信させること、相手方に重大な事実誤認があることを知りながらそれを放置したこと、曖昧な態度を取り続けて交渉を一方的に引き延ばしたこと、契約締結の直前に新たな条件を持ち出したこと、等の事情があれば、信義則違反と評価されると考えられます。

契約締結上の過失が認められた場合、契約締結のための調査費用や履行のための準備費用等、有効でない契約を有効と信じることによって発生する信頼利益の賠償をする必要があります。

(3)契約締結上の過失についての裁判例

システム開発業務に関して、契約締結上の過失が問題となった事例としては、以下の裁判例があります。

東京高裁平成21年5月27日判決は、契約締結可能性がなくなったにもかかわらず、作業を続行させた場合には信義則違反となるとし、契約締結可能性が失われた以降の工数相当額を認容しました。同判決では、当初、ユーザーはむしろ自社でシステム開発をする方向に動いておりベンダーとの契約締結が確実なものなどとは到底いえないものであったにもかかわらず、ユーザー担当者は、ベンダー担当者に契約締結が確実なものと誤信させる言動をし、かつ、ベンダーが近い将来作業に入ることを十分認識しながらそれをそのままにしていた、ないしはむしろそれを求めるかのごとき言動をしていたという事案です。裁判所は、ユーザーは社内の状況等から契約成立が確実とはいえないことを告げ、ベンダーが納期を守るためあらかじめ作業に入ることをさせないようにする注意義務を負っていたとして義務の内容を特定しています。そして、このようなユーザー担当者の言動は、契約締結に向けて交渉をしていた者としての信義に違反するものといわなければならないとして、上記②の帰責性の要件を認定しています。これは、代金等の契約の主要部分の合意状況について判断しているものと考えられます。①の要件については、ベンダーが近い将来作業に入ることを十分認識できた状況であったことから、契約締結交渉が成熟していたと判断しているものといえます。

その他、契約締結上の過失を肯定した例として、東京地判平成20年7月29日判決があります。肯定例である東京地判平成20年7月29日判決では、他のベンダーも提案に加わったが形式的なものであるなどと説明して設計業務の一部を実施させていたことから、ユーザーには契約準備段階における信義則違反があると判断されています。

他方、契約締結上の過失を否定した例として、東京地判平成17年3月28日判決があります。否定例である東京地判平成17年3月28日判決では、ユーザーは発注の意思を明確にしておらず、見積額が上昇したことに納得せずに提案を拒否したことなどの事情の下では、ユーザーに信義則上の注意義務違反はないと示されています。

(4)過失相殺による減額の可能性

契約締結上の過失により損害賠償の請求が可能であったとしても、過失相殺の理論により、認容額が減額されることはあります。過失相殺とは、民法722条2項(※3)により、損害賠償の請求者の過失の程度に応じて,損害賠償額を減額するというものです。

東京地裁平成19年11月30日判決では、基本契約が締結され、その後第1フェーズの発注・作業が完了し、第2フェーズが開始したが、正式な発注書は交付されず、親会社の承認がえられなかったとして、1ヶ月後に中止となった事案で、ベンダーも損害拡大を防ぐ対応を取るべきだったとして、請求額の3割を過失相殺として減額して、請求を認容しました。

※3 民法722条2項
被害者に過失があったときは,裁判所は,これを考慮して,損害賠償の額を定めることができる。

5. 契約締結に関する紛争を予防するためにはどうしたらよいのか?

(1)ベンダーの立場から

①正式な契約書を取り交わす前や発注書を受領する前に作業に着手しない

契約書が取り交わされていない場合には、契約成立が容易に認められにくい傾向にありますので、書面がない段階での作業着手は極力さけるべきです。

②無償で行う業務の範囲と有償で行う業務の範囲を明確に伝える。

③内示書を発行してもらう

正式な契約書を取り交わす前や発注書を発行してもらう前に作業の着手をすることは極力避けるべきですが、何らかの事情で契約書を取り交わす前にベンダーが作業着手しなければならないのであれば、内示書を発行してもらうことをおすすめします。

内示書とは、正式な注文書を発行するまでのつなぎとして発行される非公式な文書です。

内示書があれば、ユーザーに破棄されたとしても、契約締結上の過失が認められやすいと考えられます。また、期間経過について条項があれば、一日あたり単価や進捗状況によって報酬を請求できる可能性も生じます。

そして、内示書には、本契約が不成立だった場合の精算に関する事項を記入しておいた方がよいでしょう。

④提案書を送る

とはいえ、内示書すら発行してもらえないケースもあるでしょう。その場合には、「概算見積 総額3億円」というように提案書を提出していることもあります。提案書を送付しておくと、内容・プロセス次第では、契約が成立したものと扱われることがあります。

東京地裁平成16年3月10日判決は、ベンダーが契約締結に先立ち電算システム提案書を提出してその内容に基づくシステム開発を提案したことを理由に、契約が締結されたものと判示しました。

(2)ユーザーの立場から

①内部決裁が必要であることを伝える。
契約書が作成されていない場合でも、契約締結上の過失に基づく損害賠償請求をされる可能性もありますので、社内の意思決定が完了していない場合にベンダーに対して明確にその意思を伝え、曖昧にしないことが重要です。

②決裁に時間をかけない。
意思決定に時間がかかると、ベンダーの先行着手分について費用が発生し得る危険性が高まります。

③スケジュール案の内容
全体の費用や契約内容が確定するのが先になるのであれば、たとえば「●月●日までに費用及び内容確定、●月●日までに契約書完成」などとして、契約内容の確定時期や契約書完成時期をスケジュールに盛り込むと良いでしょう。
契約書完成日よりも前に、契約書完成日以降のスケジュール案を作成するのであれば、その起点は、契約書完成時点とした方がよいでしょう。たとえば、契約書がいつ完成するかが不明の場合には、「契約書完成時より●日以内に要件定義確定」などとスケジュールを立案としてください。

ベンダーの立場から ユーザーの立場から
  • 書面がない段階での作業着手は極力避ける
  • 有償の作業、そうでない作業の区別は、明確に伝える
  • 担当者ベースでも、内示書を提示してもらう
  • 内示書には、できれば、契約不成立時の清算条項を設けたい(期間経過、投下工数に応じた清算等)
  • 社内の意思決定が完了していない場合、ベンダーに対し、明確にその意思を伝え、曖昧にしない
  • 意思決定に時間がかかるときは、先行着手分について費用が発生し得ることについて覚悟する
  • スケジュールの起点は契約書完成時点とする

まずは弁護士事務所へお気軽にご相談ください!

  • さいたま大宮 048-662-8066 対応時間.9:00~21:00
  • 上野御徒町 03-5826-8911 対応時間.9:00~21:00

法律相談は、すべて当事務所にお越しいただいた上で実施いたします。
電話での法律相談やメールでの法律相談はいたしかねますので、あらかじめご了承ください。
また、初回の法律相談のお申し込みは、すべて、お電話またはご相談申込フォームからお願いいたします。

ページ先頭へ