システム開発取引で裁判沙汰、損害賠償請求を受けてしまう原因とは？

【ご相談内容】

最近、ニュース等でもシステム開発の失敗に起因する訴訟の話をよく耳にするようになりました。システム開発業を営む当社としても、他人事ではなく、何らかの対策を講じていきたいと考えています。

そこで、どのような原因で裁判沙汰になってしまうのか、裁判となった場合、システム開発特有の注意すべき点があるのか等について教えてください。

 

【回答】

システム開発取引において、裁判沙汰になってしまう究極的な原因は“お金”といっても過言ではありません。すなわち、ユーザは使い物にならないシステムである以上、報酬の返還を含む損害賠償をベンダに求める、一方、ベンダは適切に作業遂行した以上、約定通りの報酬支払いをユーザに求める、といった具合です。

ところで、システム開発取引を巡る紛争について多数の裁判例が存在するのですが、執筆者なりにそもそもの原因を分析すると、大雑把になりますが、①開発範囲・条件につき、ベンダとユーザの認識が異なる場合、②開発業務が途中で頓挫することで、費用の清算が問題となる場合、③システム引渡し後に不具合が発覚する場合に分類できるように思われます。

そこで、本記事では、上記3パターンにつき、裁判例などを引用しながらポイントを解説すると共に、ベンダとして注意するべき事項につき指摘を行います。

なお、システム開発取引において裁判沙汰になってしまう原因には、損害論に関する法的解釈（通常損害の範囲、責任制限条項の有効性、過失相殺の適用など）もあるのですが、この点については省略していること、ご容赦願います。

 

【解説】

1.システム開発取引で裁判沙汰となってしまう原因

システム開発取引で裁判沙汰になってしまう原因の多くは、開発業務の遂行に不満があることに由来します。そして、その不満内容は、大きく次の4つがあります。

・正式な契約締結前に開発が先行する場合

・開発範囲・条件につき、ベンダとユーザの認識が異なる場合

・開発業務が途中で頓挫することで、費用の清算が問題となる場合

・システム引渡し後に不具合が発覚する場合

 

以下では、「開発範囲・条件につき、ベンダとユーザの認識が異なる場合」、「開発業務が途中で頓挫することで、費用の清算が問題となる場合」、「システム引渡し後に不具合が発覚する場合」の3つについて解説を行います。

なお、「正式な契約締結前に開発が先行する場合」については、次の別記事をご参照ください。

 

（参考）

契約書を締結未了の相手とトラブルになった場合、損害賠償等の請求は可能か

 

2.開発範囲・条件につき、ベンダとユーザの認識が異なる場合

(1)実装する機能内容について認識の相違がある場合

ユーザが希望するシステムに実装したい機能内容と、ベンダが認識していたシステムの機能内容について齟齬が生じた場合、ユーザは不完全なシステムであると主張して支払いを拒絶する、ベンダはシステムを完成させた以上は支払いを求める、という対立が生じ裁判沙汰になってしまいます。

このような認識の齟齬が生じた場合、裁判所はどのように判断しているのでしょうか。

例えば、東京地方裁判所平成21年2月18日判決は、次のように述べています（原告はユーザ、被告はベンダです）。

 

原告は、本件契約の前後におけるレセプト業務の電子化についての厚生労働省の積極的推進の方針や省令の改正等をあげて、電子レセプトが今後のレセプト業務の主流となることが明らかであるとし、電子レセプト機能は必須の主要機能として開発導入することが契約当初から予定されていたと主張する。 しかし、電子レセプト機能を備えることが本件契約において予定されていたのであれば、その旨が本件契約書等に明記されるはずであるが、基本設計書にもそのような記載はなく、かえってバージョンアップにて対応と明記されているのであって、厚生労働省の方針やこれに基づく今後のレセプト業務の見通し等は当事者の合意があったことの根拠となるものではない。

 

上記裁判例では、ユーザが主張する機能について契約書に明記されていないこと、むしろユーザが主張する内容と矛盾する記載が基本設計書に明記されていることをもって、ユーザの主張を認めませんでした。

ごく当たり前の判断のように思われます。

 

では、契約書には明記されてはいないものの、ユーザが主張するような機能が別の資料に記載されている場合はどうなるのでしょうか。この点を検討するに当たり、例えば、東京地方裁判所平成22年7月22日判決を引用します（原告はユーザ、被告はベンダです）。

 

原告は、…原告と被告の間には、本件契約において、本件ソフトウェアの備えるべき機能をマッチング機能、シフト管理機能及び課金機能とする旨の合意があったと主張する。 そこで検討すると、…原告と被告は、本件契約を締結するまでの間に少なくとも6回の打合せを行っており、平成14年8月2日の打合せにおいて、原告は、被告に対し、本件ソフトウェアを「自動マッチング検索サイト」として開発するように指示しており…、同年9月3日の打合せにおいては、原告から、本件ソフトウェアの機能として「求職者の募集」のほかに「給与システム」「勤怠管理システム」「求職者評価システム」「シフト管理」等を追加するとの要求があったが…、同月5日の打合せにおいて、原告から、本件ソフトウェアの機能としては主に「高レベルマッチング」を売りにすることが再度表明され…、その後、原告と被告の間で本件契約が締結されたことが認められる…。 また、本件契約締結当時、被告は、原告からマッチング機能、シフト管理機能、勤怠評価機能、課金機能等を含めたい旨の要望があったことを理解していたが、原告から上記のとおり「高レベルマッチング」を売りにするとの発言があったことを踏まえて、本件ソフトウェアの大枠はマッチングサイトとして作成し、シフト管理機能、勤怠評価機能、課金機能等については本件契約の契約金額の範囲内に収まる程度のものとして開発することを想定していたことが認められる…。 かかる事実経過について、原告の技術担当者を務めていた××（以下「原告担当者」という。）は、本件ソフトウェアの仕様は本件契約締結までに固まらず、いまだ企画の段階にすぎなかったことを自認しており…、このことからすると、原告と被告の間に本件ソフトウェアの仕様に関する詳細かつ具体的な合意は形成されていなかったといわざるを得ないのであって、そうであれば、本件ソフトウェアの備えるべき仕様として、原告が希望するシフト管理機能、勤怠評価機能、課金機能などを含めることとする旨の合意があったとまでは認めるに足りないというべきである。 これに対して、原告は、上記打合せにおける説明及び配布資料等を通じて、被告が本件合意の内容を認識していたことは明らかであると主張し、その根拠として書証を提出する。しかし、上記各書証は、…原告担当者証言の内容に照らして、いずれも本件ソフトウェアの仕様について抽象的な提案をするものにすぎなかったと見るべきであるから、原告の上記主張を採用することはできない。

 

結論としては、ユーザが主張する機能は合意対象外であるとされました。

ベンダがユーザに対し、企画提案書をどの時点で提出したのかタイミングによっては結論が変わりうる可能性があるものの、やはり裁判所は契約書への明記を重要視していることが見て取れます。

したがって、ベンダ視点としては、どのような機能を実装するのか（逆に実装しないのか）、開発対象について具体的に契約書及びこれに付随する書類に明記することが、裁判沙汰を回避する対処法となります。

 

(2)開発条件の見直しについて認識の相違がある場合

システム開発を進めていく中で新たな問題点が発見される等の理由で、開発条件の見直しが必要となる場合があります。この場合、当然のことながら（締結済みの）契約書には明記されていないため、対処法が問題となります。

一例として東京地方裁判所平成22年5月21日判決を引用します。なお、契約書開発条件のうち、納期変更の合意に関する事例となります（原告はベンダ、被告はユーザです）。

 

この点、開発遅延を理由とするソフトウェア開発契約の解除は、注文者にとっても、発注のやり直し等による不都合が生じる場合が少なくないことから、注文者としては、開発が遅滞した状態にあったとしても、直ちに契約を解除することなく、暫定的に請負人に協力して開発を進めていかざるをえない。 そうすると、…注文者である被告が、納期直前に変更や追加を要望したり、遅延したスケジュールを前提として自己の作業を進めたりしたからといって、被告において、納期の延長を積極的に承諾する意思があったものと認めることはできない。むしろ、被告としては、…遅延についての責任の所在を明らかにするべく行動しているものであるから、…被告が納期の延長を承諾するか契約を解除するかの判断の前提として、原告に対して実現可能な納期の提示を促したものと解する外ない。 そして、被告が納期の延長を承諾したことを窺わせる事情は、他にも認められない。 以上の次第で、本件においては、原告の上記納期経過の原因が、被告の要求にあったとも、また、被告が納期の延長を承諾したとも認められないから、原告と被告とが、黙示にせよ納期延長の合意をしたとは認められない。

 

上記裁判例は、結論として納期変更の合意は認められないとしました。やはり裁判所は、別の合意書を締結するといった証拠を重要視していることが見て取れます。

もちろん、ケースバイケースの判断にならざるを得ないのですが、ベンダとしては、開発条件を変更したいのであれば、書面の締結を試みる、難しいようであればメールやチャット等の記録化されるものに残しておくといった対応が求められます。口頭による合意を裁判所に認めてもらうことはハードルが高いことを意識するべきです。

 

(3)追加開発に伴う追加報酬の有無について認識の相違がある場合

開発条件の変更のうち、追加開発の合意について、一例として東京地方裁判所平成25年12月19日判決を引用します。なお、原告はベンダ、被告はユーザとなります。

 

平成20年3月28日、要件定義及び主要な画面に関する画面構成書の内容が確定したが、その後も、被告は、ワイヤーフレーム（WEBページの大まかなコンテンツやレイアウトを示した構成図）を変更したり、動画を取り入れる等の変更を原告に要請した。 被告担当者からの変更要請については、変更を実施するのに必要と見積もられる工数（ある作業に要する作業量をいい、作業に携わる人数に作業に要する時間（月）を乗じて算出した工数を「人月」という。）を原告担当者が示し、被告は、それを踏まえて、変更を実施するか否かを決していた。原告の作成した変更管理表には、被告からの変更要請の内容ごとに、必要となる工数や、変更を実施するか否かの被告の判断が記載されており、かかる変更管理表は、被告の従業員にも交付されていた。 原告は、平成21年3月4日までに、別紙納品一覧（本件業務委託契約）及び別紙納品一覧（本件追加変更契約）記載のとおり、Eメールに添付する方法、共有ファイルサーバにアップロードする方法、本番環境にリリースする方法（本サイトを稼働させるために必要なプログラムや画像データ等をコンピュータ上に格納することにより納品する方法）並びにそれまでに提出した成果物及び追加の成果物が格納されたDVDを被告に交付する方法で、成果物を提出した。 原告は、別紙計算書…の各作業を行うのに先立ち、別紙計算書…の「合意額」欄記載の金額が記載された見積書を提出したところ、被告は特段異議を述べなかった。番号×の作業については、原告から、243万円の業務委託料が記載された見積書が提出されたのに対し、被告は、業務委託料を開発以降の工程に関するもののみに減額するよう求めるメールを送信し、その結果、同見積書に記載された開発及びテストの作業についての75万円と42万円（合計117万円）のみを業務委託料として支払うこととなった。 上記認定によれば、原告と被告との間で、本件業務委託契約で予定された範囲外の作業につき、原告が作業し、被告が別途業務委託料を支払う旨の合意が成立したと認められる。

 

上記裁判例は、追加開発とそれに伴う追加報酬について、契約書等の書面の取り交わしがあるわけではありません。

しかし、裁判所は追加開発とそれに伴う追加報酬の合意を認めました。

これは、ベンダが追加業務等を記載した変更管理表をユーザに提出し、ユーザも変更管理表を認識した上で、これをベースに協議が継続しており、変更管理表に記載された内容が当然の前提になっていたという経過があったからと考えられます。

事例判断と言えますが、ベンダが開発条件の変更を希望するのであれば、ユーザに記録が残る形式で提案することはもちろん、ユーザが当該変更内容を受入れたことを裏付ける行動履歴の証拠化が重要であることを示唆する裁判例と言えます。

3.開発業務が途中で頓挫することで、費用の清算が問題となる場合

(1)プロジェクトマネジメント義務、協力義務

何らかの事情で開発業務がストップし再開不可能となった場合、ベンダは開発不可能となった原因はユーザにあるとして報酬請求を行い、一方ユーザは開発不可能となった原因はベンダにあるとして報酬の支払拒絶及び既払いの報酬返還を行う、といった深刻な紛争となり裁判沙汰に至るケースが多いようです。

このどちらの当事者に原因があるのかを検討する上で、避けて通れない概念があります。

それは、ベンダが負担するプロジェクトマネジメント義務と、ユーザが負担する協力義務です。両義務の存在を初めて裁判所が明言したとされている裁判例が、東京地方裁判所平成16年3月10日判決となります（なお、原告はユーザ、被告はベンダとなります）。

 

＜プロジェクトマネジメント義務＞

被告は、納入期限までに本件電算システムを完成させるように、本件電算システム開発契約の契約書及び本件電算システム提案書において提示した開発手順や開発手法、作業工程等に従って開発作業を進めるとともに、常に進捗状況を管理し、開発作業を阻害する要因の発見に努め、これに適切に対処すべき義務を負うものと解すべきである。 そして、システム開発は注文者と打合せを重ねて、その意向を踏まえながら行うものであるから、被告は、注文者である原告国保のシステム開発へのかかわりについても、適切に管理し、システム開発について専門的知識を有しない原告によって開発作業を阻害する行為がされることのないよう原告に働きかける義務（以下、これらの義務を「プロジェクトマネジメント義務」という。）を負っていたというべきである。

 

＜協力義務＞

本件電算システム開発契約は、いわゆるオーダーメイドのシステム開発契約であるところ、このようなオーダーメイドのシステム開発契約では、受託者（ベンダ）のみではシステムを完成させることはできないのであって、委託者（ユーザ）が開発過程において、内部の意見調整を的確に行って見解を統一した上、どのような機能を要望するのかを明確に受託者に伝え、受託者とともに、要望する機能について検討して、最終的に機能を決定し、さらに、画面や帳票を決定し、成果物の検収をするなどの役割を分担することが必要である。このような役割を委託者である原告が分担していたことにかんがみれば、本件電算システムの開発は、原告と受託者である被告の共同作業というべき側面を有する。 （省略） したがって、原告は、本件電算システムの開発過程において、資料等の提供その他本件電算システム開発のために必要な協力を被告から求められた場合、これに応じて必要な協力を行うべき契約上の義務（以下「協力義務」という。）を負っていたというべきである。

 

なお、プロジェクトマネジメント義務及び協力義務は、システム開発契約の性質上、当然に導かれる義務であって、契約書に明記されていないから義務が発生しないという考え方は採用されていません。

もっとも、抽象的にプロジェクトマネジメント義務、協力義務があると主張したところで紛争解決に役立ちません。事案に応じて、プロジェクトマネジメント義務及び協力義務の具体的な内容を導き出すことが重要となります。そして、この具体的な内容を契約書に明記できるのであれば、できる限り明記するというのが裁判沙汰を防止する予防策となります。

 

(2)プロジェクトマネジメント義務の具体的内容

プロジェクトマネジメント義務については、その後の裁判例の積み重ねもあり、（事案に応じて）具体的な義務内容が拡大・変容している傾向があります。

すなわち、上記の、東京地方裁判所平成16年3月10日判決では、具体的な内容として

・納入期限までに本件電算システムを完成させるように、契約書や提案書において提示した開発手順や開発手法、作業工程等に従って開発作業を進めるとともに、常に進捗状況を管理し、開発作業を阻害する要因の発見に努め、これに適切に対処すべき義務

・ユーザによるシステム開発へのかかわりについても、適切に管理し、システム開発について専門的知識を有しないユーザによって開発作業を阻害する行為がされることのないようユーザに働きかける義務

とされました。

 

しかし、例えば、次のように説示する裁判例もあります。

・システム開発は必ずしも当初の想定どおり進むとは限らず、当初の想定とは異なる要因が生じる等の状況の変化が明らかとなり、想定していた開発費用、開発スコープ、開発期間等について相当程度の修正を要すること、更にはその修正内容がユーザの開発目的等に照らして許容限度を超える事態が生じることもあるから、ベンダとしては、そのような局面に応じて、ユーザのシステム開発に伴うメリット、リスク等を考慮し、適時適切に、開発状況の分析、開発計画の変更の要否とその内容、更には開発計画の中止の要否とその影響等についても説明することが求められる（東京高等裁判所平成25年9月26日判決）。

・ベンダは、ユーザにおける意思決定が必要な事項や解決すべき必要がある懸案事項等の発生の徴候が認められた場合には、それが本格的なものとなる前に、その予防や回避について具体的にユーザに対して注意喚起をすべきであるし、懸案事項等が発生した場合は、それに対する具体的な対応策及びその実行期限を示し、対応がされない場合に生ずる支障、複数の選択肢から一つを選択すべき場合には、対応策の容易性などそれらの利害得失等を示した上で、必要な時期までにユーザにおいて対応することができるように導き、また、ユーザがシステム機能の追加や変更の要求等をした場合、当該要求が委託料や納入期限、他の機能の内容等に影響を及ぼすときにはユーザに対して適時にその利害得失等を具体的に説明し、要求の撤回、追加の委託料の負担や納入期限の延期等をも含め適切な判断をすることができるように配慮すべき義務を負う（東京地方裁判所平成28年4月28日判決）。

 

システム開発の実情に応じて具体的な義務内容は変わり、プロジェクトマネジメント義務違反とならない一般論を示すことは難しいですが、最低でも、

・実現可能なシステムなのか、実現できるとしても莫大な費用負担とならないかの事前説明を行うこと、

・プロジェクト途中段階で業務遂行に支障が生じる事態が生じた場合、すぐにユーザへ情報提供し、選択肢を示したうえで判断を仰ぐこと

・ユーザによる業務改革が必要な事項（システムで実現できない事項）について十分にすり合わせを行うこと

などは、ベンダとして特に意識して対処したいところです。

 

(3)協力義務違反を指摘する場合の注意点

ベンダがユーザに協力義務違反を主張する場合は注意点があります。

それは、ユーザの協力義務は、ベンダからの働きかけに対して応じるという性質を有すること、すなわち、受動的な義務という位置づけになりやすいという点です。

例えば、ユーザが必要な情報を提供しなかったという事実から直ちに協力義務違反が成立するわけではなく、ベンダがプロジェクトマネジメント義務に基づき、必要な情報が不足していることを指摘しているにもかかわらず、ユーザが合理的理由もなく情報を提供しない場合に初めて協力義務違反が問題となり得ます。あるいは、ユーザが必要な意思決定をしないためプロジェクトが遅延したという事実から直ちに協力義務違反が成立するわけではなく、ベンダがプロジェクトマネジメント義務に基づき、適切な意思決定を行うよう働きかけたにもかかわらず、あえてユーザが判断を先延ばしにしたといった事情がある場合に初めて協力義務違反が問題となり得ます。

 

以上が原則的な考え方となるのですが、近時は協力義務の捉え方として、作為義務と不作為義務と表現している裁判例も現れています。

例えば、札幌高等裁判所平成29年8月31日判決は次のように述べています。なお、一審被告とはベンダ、一審原告とはユーザのことです。

 

システム開発はベンダである一審被告の努力のみによってなし得るものではなく、ユーザである一審原告の協力が必要不可欠であって、一審原告も、一審被告による本件システム開発に協力すべき義務を負う（一審原告も、一般論として上記のような協力義務を有していることは認めているところである。）。 そして、この協力義務は、本件契約上一審原告の責任とされていたもの（マスタの抽出作業など）を円滑に行うというような作為義務はもちろん、本件契約及び本件仕様凍結合意に反して大量の追加開発要望を出し、一審被告にその対応を強いることによって本件システム開発を妨害しないというような不作為義務も含まれているものというべきである。

 

上記裁判例のいう協力義務における作為義務及び不作為義務ですが、要は、

・ベンダから積極的に要請（役割分担の履行）があった以上、これに応じる作為義務

・ベンダより、ユーザの要求に対して消極的応答（仕様に変更に応じないこと）がなされている以上、無茶な要求をしない

と整理することができます。

このように考えると、ベンダによるプロジェクトマネジメント義務が履行されたことを前提に、上記裁判例も協力義務は受動的性格を念頭に置いているものと考えてよいと思われます。

 

4.システム引渡し後に不具合が発覚する場合

システム引渡し後に不具合が発覚した場合、契約不適合責任が問題となります。

契約不適合（旧民法でいうところの瑕疵）に該当するか否かは、ケースバイケースというほかないのですが、例えば、東京高等裁判所平成26年1月15日判決では、次のような事情を考慮しています。なお、控訴人はユーザ、被控訴人はベンダです。

 

被控訴人の認識においても、上記検収期間終了…時点で、本件新基幹システムの補修未了の不具合、障害は31件であり、その他に本件新基幹システムの補修未了の不具合、障害が29件（高1件、中6件、低22件）あって、その補修工数は合計93.4人日要するところ、期間の経過により発現数は減少しているものの、本件新基幹システムの障害・不具合が順次発現していたことに照らせば、同日の時点において、本件新基幹システムに今後どの程度の障害・不具合が生じ、その補修にどの程度掛かるのかについて明らかであったことを認めるに足りる証拠はなく、控訴人及び被控訴人は、同日の時点で、本件新基幹システムに、今後どの程度の障害・不具合が生じ、その補修にどの程度掛かるのかについて、その目途が立たない状態にあったものと認められるのである。 その上、控訴人の現行システムのホストコンピュータの保守期間が同年9月30日に満了するところ、同年8月31日の時点において、少なくとも品質担保対策にその準備期間1か月に加え5か月要し、現行システムとの並行稼働までには更に少なくとも５か月の導入支援期間を要する状態であったこと…からすると、仮に同年6月16日における被控訴人の作業の中断がなく、上記準備期間の1か月が不要であったとしても、なお、本件新基幹システムが検収され、現行システムとの並行稼働が可能となる状態になるのは、現行システムのホストコンピュータの保守期間満了から少なくとも半年以上経過した後になると認められるのである。 以上判示の各点を総合すれば、…本件新基幹システムは、その瑕疵のために上記検収期間終了時において検収が終了せず、その時期が上記予定よりも大幅に遅れている上、控訴人の現行ホストコンピュータの保守期間が満了後もなお長期間を要する状態になっていたものと認められるのであり、本件ソフトウェア開発個別契約は、本件新基幹システムの瑕疵のために、社会通念上、本件ソフトウェア開発個別契約をした目的を達することができないものと認められる。

 

あくまでも事例判断とはなりますが、上記裁判例は、

・検収期間満了時において、今後どの程度の障害・不具合が生じ、その補修にどの程度掛かるのかについて、その目途が立たない状態であったこと

・保守期間が満了してもなお検収が終了しないこと

・保守期間満了時から6ヶ月以上経過しないことには、現時点で把握できている不具合を解消できないこと

といった、今後もシステムが通常稼働するとは言い難いことを理由に契約不適合（瑕疵）があると認定しています。

 

バグを100％消滅させることは困難であるとはいえ、ベンダとしては、システムが通常稼働する見込みを合理的に説明できるのかが、契約不適合（瑕疵）の分水嶺になると認識しておいた方がよさそうです。

 

5.当事務所でサポートできること

当事務所は、システム開発を行うベンダの顧問弁護士を複数務めていることもあり、システム開発を巡る紛争について、一定頻度で関与しています。また、ベンダ側のみで対応するという方針を取っていないため、ユーザ側で対応することもしばしばあります。

したがって、システム開発を巡る紛争については、広い視野をもって対処できるものと自負しています。

システム開発を巡る紛争に上手に対応するには、証拠収集や分析を含めた事前準備はもちろんのこと、方針や戦略を含めた見通しを立てることが必要不可欠です。

当事務所は、複数のシステム開発を巡る紛争に対処した実績がありますので、経験や得られたノウハウ等を元にご対応することが可能です。システム開発を巡る紛争についてご相談がある場合、是非当事務所をご利用ください。

 

＜2023年6月執筆＞

※上記記載事項は弁護士湯原伸一の個人的見解をまとめたものです。今後の社会事情の変動や裁判所の判断などにより適宜見解を変更する場合がありますのでご注意下さい。