新規_システム開発に関する訴訟手続の方法は？ポイントを弁護士がわかりやすく解説

システム開発終了に関する主な訴訟類型

システム開発の終了には、主に次の3パターンが考えられます。

1. 不完全履行型
2. 途中頓挫型
3. 自己都合終了型

はじめに、それぞれの類型について解説します。

不完全履行型

不完全履行型とは、ベンダーによる不完全履行（納品物が不完全であることや、納品物が契約内容に適合していないこと）を理由として、ユーザーが契約を解除する類型です。
このケースでは、ユーザーがベンダーに対して報酬の支払いを拒否することなどでトラブルが生じます。

途中頓挫型

途中頓挫型とは、ベンダーがユーザーに対して納期までに成果物を納品できなかった類型です。
この場合は、納品できなかった原因がユーザーにあるかベンダーにあるかなどが争点となります。

自己都合終了型

自己都合終了型とは、ユーザーの都合でシステム開発が不要となる類型です。
この類型では、報酬請求や損害賠償請求など、清算処理が争点となります。

主張と立証のポイント：不完全履行型

ここからは、それぞれの類型について訴訟に発展した場合の主張と立証のポイント解説介します。
はじめに解説するのは、不完全履行型の場合の主張と立証のポイントです。

ベンダーがユーザーに対して報酬を請求する場合

納品されたシステムが不完全であると考え、ユーザーが報酬の支払いを拒否することがあります。
一方、ベンダーとしては契約に適合する完成品を納品したと考える場合、ユーザーに対して報酬の支払いを請求します。

この場合、ベンダーは仕事を完成させて納品したことを主張することとなります。
仕事を完成させて納品している旨は、次の事項などから立証します。

1. 成果物であるシステムが仕様書の要件を満たしていること
2. 検収されているか、契約書の規定に従って検収合格とみなされていること

ただし、たとえ検収に合格していなくても、ユーザーが合理的な理由のないままに検収を拒否しているなどの事情があれば、納品したとして報酬請求が認められる可能性があります。
反対に、検収合格証などが出されていても、形式的に出されたにすぎない場合は、未完成であると判断される可能性もあります。

ベンダーが追加の開発報酬を請求する場合

システム開発では、日々追加の作業や修正が生じることがあります。
これによって追加での開発が必要となった場合、ベンダーはその分の報酬を請求したいことでしょう。

追加の開発を請求する場合、原則としてベンダーは追加開発や報酬追加の合意があった旨を立証することとなります。

とはいえ、追加や修正が頻繁に発生する場合、追加開発に関する合意書面をその都度交わさないことも少なくないようです。
その場合は、商法の報酬請求権の規定を根拠として、報酬請求を検討します。

商法による報酬請求権の内容は、次のとおりです（商法512条）。

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

ユーザーが報酬の支払いを拒否する場合

納品されたシステムが未完成であったり契約内容に適合していなかったりする場合、ユーザーは報酬の支払いを拒否することとなります。
この場合において、ユーザーが主に主張・立証すべき内容はそれぞれ次のとおりです。

合意した機能が実装されていない場合

合意した機能が実装されていない場合、主に主張・立証すべき内容は次のとおりです。

1. ベンダーとユーザー間で、その機能を実装する旨の合意があったこと
2. その機能が実装されていないこと

システムに重大な傷害や不具合がある場合

システムに重大な障害や不具合がある場合、ユーザーが主に主張・立証すべき内容は次のとおりです。

1. 重大な障害や不具合が生じていること
2. その障害や不具合により、契約の目的が達成できないこと
3. その障害や不具合が、契約の目的や社会通念に照らして軽微とは言えないこと

ユーザーがベンダーに損害賠償請求をする場合

納品されたシステムが契約不適合である場合、ユーザーは契約を解除して、これにより生じた損害の賠償を請求することがあります。
民法415条にもとづく損害賠償請求をする場合、ユーザーは、ベンダーが契約の本旨に沿った履行（契約内容に適したシステムの納品）をしていないことを立証することとなります。

ただし、債務不履行となった原因が債務者側にない場合（民法上の表現では、「契約その他の債務の発生原因及び取引上の社会通念に照らして債務者の責めに帰することができない事由によるものであるとき」）は、債務不履行による損害賠償請求はできません。
そのため、ベンダーとしては、契約不適合が生じた原因（帰責事由）がユーザー側にあることの主張と立証を試みることとなります。

主張と立証のポイント：途中頓挫型（原状回復請求をする場合）

途中頓挫型による紛争では、ユーザーが原状回復請求をする場合と、損害賠償請求をする場合があります。
ここでは、ユーザーが原状回復請求をする場合におけるポイントを解説します。

原状回復請求による請求内容

システムが納期までに納品されない場合や、システムの納品が事実上不可能となった場合、契約を解除したうえで原状回復を請求することとなります。
原状回復請求により、ユーザーは前払いした開発委託料の返還を求めることが一般的です。

また、開発委託料はやり取りされた金額をそのまま返還するのではなく、原則として受領時からの利息を付して返還しなければなりません（民法545条2項）。

帰責事由の立証責任はどちらが負うか

改正前の民法では、ユーザーが契約を解除するには、ベンダーの帰責事由が必要でした。

一方、改正後民法では、解除について帰責事由は要件とされていません（同541条）。
ただし、改正後民法には次の規定があります（同543条）。

• 債務の不履行が債権者の責めに帰すべき事由によるものであるときは、債権者は、前2条の規定による契約の解除をすることができない。

そのため、改正後においては、ユーザーに帰責事由があることを、契約解除を免れたいベンダーが主張・立証することとなります。
一方、ユーザーはユーザーに帰責事由がないこと（すなわち、ベンダーに帰責事由があることや、ベンダーとユーザーのいずれの責めにも帰することができない事由があること）の主張・立証を試みます。

ユーザーに協力義務違反がある場合の原状回復請求の可否

システム開発は、進行のためにユーザーの協力が必要となることが少なくありません。
中には、ユーザーが適切な協力義務を果たさないことが一因となり、履行遅滞に陥る場合もあるでしょう。

このような場合にまで、ユーザーに原状回復請求（委託料全額の返還）を認めることが酷といえます。
そのため、信義則を根拠として、原状回復請求が制限される可能性があります。

多段階契約解除の考え方

システム開発が大がかりである場合などには、多段階契約方式をとることがあります。
多段階契約方式とは、システム開発の工程を複数に分け、その工程ごとに契約の締結や代金の支払いをする方式です。

この場合、たとえば全5段階の工程のうち2段階目までは問題なく進行し報酬も支払い済であり、3段階目で債務不履行が生じて解除を検討するという場合もあるでしょう。

このようなケースにおいて、ユーザーとしては2段階目までだけの開発では不足であるため、1段階目と2段階目を含めてすべての契約を解除したいと考えることが一般的です。
一方、ベンダーとしては、すでに完了した1段階目と2段階目の解除（原状回復）までは避けたいと考えます。

このような多段階契約方式の解除の場合、その多段階での契約が全体を通して1個の契約と判断できるか否かによって結論が変わるものと考えられます。
すなわち、便宜上多段階に分けているものの、実態としては全体で1つの契約なのであれば、3段階目で問題が生じた場合に、1段階目と2段階目も含めての原状回復が認められる可能性があるということです。

一方、全体を1個の契約と判断できない場合、3段階目の解除は、1段階目と2段階目の契約には影響しません。

一般的には、あえて多段階方式での契約を選択している以上、全体で1個の契約ではないと判断される可能性が高いでしょう。
また、いずれであっても、後続する工程（4段階目と5段階目）の解除は認められる可能性が高いものと思われます。

多段階方式の解除では特に慎重な検討が必要であるため、早い段階から弁護士へご相談ください。

主張と立証のポイント：途中頓挫型（損害賠償請求をする場合）

システム開発の途中頓挫についてベンダーに帰責事由がある場合、債務不履行や不法行為に基づく損害賠償請求をする場合があります。
ここでは、損害賠償請求をしようとする場合における主張と立証のポイントを解説します。

主な損害賠償項目

損害賠償請求をしようとする場合、損害賠償の候補となる項目を挙げなければなりません。
途中頓挫の場合、損害賠償の候補となる主な項目は次のとおりです。

• 頓挫したシステム開発のために、ベンダーに支払った前払費用
• 頓挫したシステム開発のために要した社内の人件費や、外注した業務委託費用
• 開発を頓挫したシステムのために購入し、他に転用ができない機器やソフトウェアの代金
• 開発を頓挫したシステムの導入に備えて実施した研修費
• 旧システムから開発を頓挫した新システムに移行した場合における、運用保守費用の差額
• 逸失利益

なお、必ずしもこれらのすべてについて損害賠償請求が認容されるとは限りません。
損害賠償請求をする際は、具体的な状況や立証の可否などにより、請求する項目を検討することとなります。

ベンダーは損益相殺によって損害賠償請額を減額できる？

開発を頓挫したシステムが、成果物として客観的な価値を有する場合があります。
このような場合、ベンダーが負うべき損害賠償請求額から、ユーザーが得た利益（成果物の客観的な価値）を控除できる可能性があります。

ただし、このような損益相殺が認められるか否かは、納品したシステムが他のプロジェクトで流用されているか否かなど個別事情によって判断されます。
お困りの際は、弁護士へご相談ください。

責任制限条項の考え方

ベンダーとユーザーとで取り交わすシステム開発契約書に、責任制限条項が設けられていることがあります。
責任制限条項とは、損害賠償請求の上限額を定める規定です。

このような責任制限条項は、原則として有効です。
ただし、故意や重過失による損害である場合は、責任制限条項の有効性が問題となる可能性が高くなります。

実際には、責任制限条項の適用範囲について、故意と重過失による場合を除く旨の規定を置くことも多いでしょう。
そのため、責任制限条項がある場合は、ベンダーによる重過失の有無が争点となりやすくなります。

主張と立証のポイント：自己都合終了型

最後に、自己都合終了型の場合における主張と立証のポイントを解説します。

ベンダーが主張・立証すべき内容

ベンダーには問題がないにも関わらず、ユーザーによる自己都合でシステム開発が終了した場合、ベンダーは次の費用を請求できることが一般的です。

1. 終了時点までに履行が終了した部分に対応する出来高
2. 未了部分について発生した費用

そのため、ベンダーはこれらの費用を算定して立証することとなります。
なお、これは経産省のモデル契約を活用している前提であり、契約書の内容によっては請求範囲などが異なる可能性があります。

出来高の計算と立証の方法

システム開発契約が終了した時点までに対応する出来高を、正確に算定することは困難です。
なぜなら、出来高の算定は建築工事の請負契約に準じて行うことが想定されるものの、システムは目に見えず、建築工事を比較して進捗状況の把握が難しいためです。
また、大規模なシステム開発では下請に再委託していることも多く、下請による履行部分も含めての立証は現実的ではないでしょう。

そのため、自己都合終了に備えてベンダーは適宜進捗状況を把握したうえでユーザーに対して文書で通知しておくなど、進捗状況に関する齟齬が生じないための対策が必要です。

損害賠償の主張と立証の方法

自己都合終了型の場合においてベンダーがユーザーに対して請求するのは、先ほど解説したように原則として次の2つの金額です。

1. 終了時点までに履行が終了した部分に対応する出来高
2. 未了部分について発生した費用

このうち、「1」の部分について立証が成功した場合は、「2」の部分を別途請求することとなります。
「2」の部分は、請求書など経理上の書類から立証できることが多いでしょう。

ただし、1つ上で解説したとおり、出来高の立証が困難な場合もあります。
その場合は、「1」と「2」を併せて損害賠償請求することも1つの方法です。

いずれの方法が有利であるかは状況によって異なります。
弁護士へ相談したうえでご検討ください。

まとめ

システム開発プロジェクトの終了について、紛争が生じた場合の訴訟における主張や立証のポイントを解説しました。

訴訟において主張や立証をすべきポイントは、システム開発が終了した原因などによって異なります。
請求したい事項によっても主張・立証すべきポイントが異なるため、まずは請求したい内容を絞り込んだうえで、主張・立証すべき点を検討すべきです。

紛争が生じてお困りの際や、将来の紛争に備えて契約内容を検討したい際は、弁護士へご相談ください。