検収後にシステムの不具合が発覚したら？契約不適合責任に基づく請求方法を解説

システム開発は一般的に、要件定義フェーズで決定された内容に沿ってプログラムの実装が進められ、最終的に仕様どおりの仕上がりになっているかをユーザー・ベンダー双方で確認し、検収をもって終了するものです。

しかし現実には、テスト工程や検収の時点では発見できなかったバグや不具合が、検収後の運用フェーズで発覚することは十分に起こりえます。検収後に不具合が判明した場合、法律上どのようなことを求めることができるのでしょうか。

結論から言えば、民法上の「契約不適合責任」に基づき、修補や損害賠償などを求める余地があります。ただし権利行使には期間の制限があるため、早めの対応が重要です。

検収後やテスト工程後にもバグ・不具合が残るのは珍しくない

技術的な観点からいうならば、ベンダー側の各種テスト工程の完了・ユーザー側の検収の後に、様々なバグや不具合が発覚するということは決して珍しいことではありません。ユーザーが検収の工程で行うことは通常、画面上から確認しうる入出力のチェックが中心となることでしょう。

しかし、ITシステムは、ユーザー側から確認できる画面上の外観以上に、背後のデータベースや、各種の計算・制御を司るプログラムの部分で、複雑に細やかな構造を有している場合が多いものです。日次や月次で自動的に実行されるバッチ処理の不具合や、特定の日付・条件でのみ生じる計算の誤りなどは、その典型例といえます。それゆえ、画面上の入出力のチェックだけで、その後の運用フェーズで起こりうるすべての不具合を網羅的に検証し尽くすのは、そもそも現実的ではありません。

以上のような事情は、開発業務を受け持つベンダー側の目線でみても、同様のことがいえます。実装されたプログラムにバグや不具合がないかを確認するのは単体テスト・結合テストといった「テスト工程」ですが、そこで本当にありとあらゆる可能性が検証し尽くせるかといえば、必ずしもそうではありません。開発したシステムが本格的に業務で活用されだして以降も、ベンダー側が予期していなかった操作が行われたり、あるいは大量のデータが実際に登録されるようになってきたり、複数のユーザーが同時にアクセスするようになってきたりするなかで、それでもなお支障なく動き続けるシステムを作ることは、本来優れた技術力を要するものです。

検収やテストといった段階において、ありとあらゆるバグや不具合を発見し尽くすことは現実的ではなく、実際に使い始めてから様々な問題が発覚する場合があるのがITシステムだという点を、まずは理解しておくべきでしょう。

納品・検収後の不具合は「契約不適合責任」の問題となる　

プログラムを実際に使い始めてからの不具合は、納品前と同じ形でベンダーに責任を追及することが難しくなる場合が多いのが現状です。ではこうしたトラブルが実際に発覚した場合、どのように対処すればよいのでしょうか。

まず、事後的にであれ、様々なバグや不具合が発覚したのであれば、ユーザー側からはベンダーに対し、何らかの責任を追及したいと考えることでしょう。しかし、通常、もうすでに納品が完了し、検収まで終えているのであれば、「仕事が完成していない」ことを理由とする責任の追及は困難となっている場合が多数です。

そもそもシステム開発における契約は、なにか特殊な取り決めが用意されていない限り、プログラムの実装に関する規定は民法上の請負契約の規定が及んでくるものです（工程によっては準委任契約とされる場合もあります）。請負契約がどういったものであるかについては、以下の記事で解説しています。

そして請負契約では、「仕事の完成」が、債務の履行要件となります。ここでいう「仕事の完成」が具体的になにを意味するのかについては、以下の記事で解説しています。

ここでは、過去の裁判例において、請負契約における「仕事の完成」が、システム開発の文脈に即して言うなら、開発工程の全工程の終了を意味するものであることを示しています（東京地判平成14年4月22日）。そして、開発工程が全部終了した後におけるバグ・不具合などの問題は、仕事が完成したこと自体は前提としつつ、引き渡された成果物が契約の内容に適合していないという「契約不適合責任」の問題として扱われることになります。

つまり、一度納品を受け入れ、検収まで完了しているとなれば、「仕事は完成した」という前提のもとで、成果物が契約の内容に適合しているかどうかが問題となるのが通常ということです。なお、契約不適合責任は債務不履行責任とは別枠の制度ではなく、その一類型と位置づけられています。契約不適合を理由とする損害賠償は民法415条、契約の解除は同法541条・542条という債務不履行の一般規定によることとされており（同法564条）、検収を終えているからといって、ベンダーに何も求められなくなるわけではありません。

契約不適合責任に基づきベンダーに責任追及を行う道筋

では、契約不適合責任に基づいてベンダーに対応を求める場合、なにをどのような順序で検討していけばよいのでしょうか。以下に確認していきましょう。

まずはバグや不具合の重大さ・深刻さの程度を確認する　

バグや不具合が事後的に発覚し、それを理由に何らかの対応を求める際には、その深刻さの程度が問題となってきます。パターンとしては

1. バグや不具合といえるものであっても、契約の内容に適合しないとまではいえない場合
2. 契約の内容に適合しないといえるが、その不適合の程度が軽微にとどまる場合
3. 契約の内容に適合せず、かつその程度も軽微とはいえない場合

の3つに分かれます。契約不適合責任に基づく責任追及の可否を分けているのが1と2の境目で、契約の解除まで行えるかどうかを分けているのが2と3の境目です。

このうち契約の解除は、相当の期間を定めて追完を求めても応じられない場合に可能となります。ただし、その不履行が軽微であるときは解除することができません（民法541条）。また、追完が不能である場合や、ベンダーが追完を明確に拒絶した場合などには、催告をせずに解除することもできます（同法542条）。

なお、「契約不適合責任」に関しては、以下の記事で詳細に解説しています。

次にベンダーに要求すべき事柄を明確（追完請求・損害賠償など）にする

また次に、相手方になにを要求すべきなのかを明確にする必要があります。ここで前提となるのが、「契約の内容」がどのようなものであったかという点です。現行法における責任追及の出発点は、成果物が客観的に不出来かどうかではなく、あくまで契約の内容に適合しているかどうかだからです。

そのため、システム開発プロジェクト発足当初に行われた会議の議事録や、要件定義書・仕様書の記載事項などが、極めて重要な手がかりとされます。検収後にもバグや不具合が事後的に発覚するような事態もありうるため、開発プロジェクトの終了後も、各種ドキュメントの保管は徹底しておくべきでしょう。

なお、解除以外に契約不適合責任の内容として求めうるものには、追完請求（バグの修補や再納品の請求。民法562条）、報酬減額請求（同法563条）、損害賠償請求（同法415条）があります。また、追完請求には相手方の帰責事由が不要である一方、損害賠償請求についてはベンダー側の帰責事由が必要とされる点にも注意が必要です。

検収後の不具合対応で押さえておきたい注意点

ここまでの内容を実際の対応に移していく際には、進め方の面でも押さえておきたい点があります。

契約の解除など、法律行為を行う場合には、やり方にも注意　

もし契約不適合責任の内容として、契約の解除を行う場合には、解除を行うための法律上の事務手続きのやり方の知識も合わせて身につけておくべきでしょう。契約解除の効果や、有効な意思表示のやり方、後にトラブルにならないような通知の行い方などについては、以下の記事で解説しています。

契約不適合を主張できる期間には制限がある

通知については期限にも注意が必要です。請負契約では、契約不適合を知った時から1年以内にその旨をベンダーへ通知しないと、追完請求・報酬減額請求・損害賠償請求・契約の解除のいずれもできなくなります（民法637条1項）。ここで求められるのは訴訟の提起ではなく「通知」ですが、後日の争いを避けるため、内容証明郵便など記録の残る方法によることが望ましいといえます。

なお、引渡しの時点でベンダーが不適合を知っていた場合や、重大な過失によって知らなかった場合には、この期間制限は適用されません（同条2項）。

裁判ではなく、交渉というかたちでの解決が望ましい　

こうした一連の法律論は、必ずしも裁判が起きた場合にのみ意味を持つものではありません。裁判による紛争解決は両当事者にとって非常に負担も大きいものです。むしろ、裁判にいたる前段階の交渉においてこそ、大いに役立てていくべき知見でもあります。

法律上の知見が、裁判以外の交渉においていかなる意義を持つものであるかについては、以下の記事にて解説を行なっています。

バグや不具合と、「機能の不足」は区別して考えるべき

実装してきた機能や仕様にバグや不具合があるような場合と、そもそも必要な機能が備わっていないような場合とでは、議論は異なってきます。もし必要な機能がひととおり揃っていないような場合であれば、そもそも請負契約における「仕事の完成」が認められず、契約不適合責任以前の問題として、報酬の支払い自体を争いうる場合もあります。

また、そうした必要な機能や仕様を備えられていないとしても、要件定義の段階でユーザー側が適切な情報提供を行なってこなかった結果なのであれば、そもそも契約内容の一部とみること自体が不適当であると評価すべき場合もありうるでしょう。これに関しては裁判例においても、ユーザー側は開発に協力すべき義務を負うとされています。実際の判例として、仕様をいったん確定させた後に大量の追加要望を出したことなどが協力義務違反にあたるとされ、ユーザー側に多額の賠償が命じられた事案も存在します（札幌高判平成29年8月31日）。

まとめ｜検収後に不具合が発覚したら早めの対応を

プロジェクトの工程のなかで生じた問題は、プロジェクトの進行中に発覚する場合もあれば、運用段階などで事後的に発覚する場合もあります。無事に全部の工程を終えたとしても必ずしも安心できないというシステム開発プロジェクトの特徴は、「契約不適合責任」という制度にこそ象徴されるものであるように思われます。

検収を終えた後であっても、成果物が契約の内容に適合していないのであれば、追完や報酬の減額、損害賠償、場合によっては契約の解除を求めることができます。もっとも、不適合を知った時から1年以内に通知をしなければ、これらを求められなくなってしまいます。プロジェクト終了後まで見据えた文書管理の徹底をはかるとともに、早い段階で対応に着手することが重要です。

「検収後にシステムの不具合が発覚した」「ベンダーが修正に応じてくれない」といった問題に直面した際は、IT法務の実務実績が豊富な弁護士へ早期にご相談ください。契約書やプロジェクトの進捗を精査し、リスクを最小限に抑えた最適解をご提案いたします。

当事務所による対策のご案内

モノリス法律事務所は、IT、特にインターネットと法律の両面に高い専門性を有する法律事務所です。当事務所では、東証上場企業からベンチャー企業まで、さまざまな案件に対する契約書の作成・レビューを行っております。契約書の作成・レビュー等については、下記記事をご参照ください。