検収後にシステムの不具合が発覚した場合の対応策とは

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

しかし現実問題、テスト工程及び検収の合格時には発見できなかったようなバグや不具合が、その後の運用フェーズなどで発覚するということは実際に十分起こりえます。一度納品を受け付けてしまった場合、法律上どのようなことを求めることができるのでしょうか。

検収合格後やテスト工程後にもバグは残っていて不思議ではない　

技術的な観点からいうならば、ベンダー側の各種テスト工程の完了・ユーザー側の検収の合格の後に、様々なバグや不具合が発覚するということは決して珍しいことではありません。ユーザーが検収の工程で行うことは通常、画面上から確認しうる入出力のチェックが中心となることでしょう。しかし、ITシステムは、ユーザー側から確認できる画面上の外観以上に、背後のデータベースや、各種の計算・制御を司るプログラムの部分で、複雑に細やかな構造を有している場合が多いものです。それゆえ、ユーザー目線での画面上の入出力のチェックから調べられることには元から限界があるのです。したがって、チェックでその後の運用フェーズで起こりうるすべての不具合の可能性を網羅的に検証し尽くすのはむしろ現実的ではありません。

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

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

債務自体は履行済みという扱いを受けるのが通常　

ではこうしたトラブルが実際に発覚した場合、どのように対処すればよいのでしょうか。法律的な順序に沿って整理していきます。

まず、事後的にであれ、様々なバグや不具合が発覚したのであれば、ユーザー側からは、業務をこれまで依頼してきたベンダーに対し、何らかの責任を追及したいと考えることでしょう。しかし、通常、もうすでに納品が完了し、検収まで合格しているのであれば、債務不履行に基づく責任の追及は困難となっている場合が多数です。

そもそもシステム開発における契約は、なにか特殊な取り決めが用意されていない限り、プログラムの実装に関する規定は民法上の請負契約の規定が及んでくるものです。請負契約がどういったものであるかについては、以下の記事で詳細に説明を行なっています。

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

ここでは、過去の裁判例において、請負契約における「仕事の完成」が、システム開発の文脈に即して言うなら、開発工程の全工程の終了を意味するものであることを解説しています。そして、開発工程が全部終了した後におけるバグ・不具合などの問題は、請負契約における瑕疵担保責任の問題となることを説明しています。

話をまとめると、一度納品を受け付け、検収の合格まで完了しているとなれば、債務そのものはすでに履行されていることを前提として、その後の品質保証の問題、すなわち瑕疵担保責任の追及の可否が問題となるのが通常ということです。

瑕疵担保責任に基づく責任追及を行う道筋

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

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

バグや不具合が事後で発覚し、それが法律上の「瑕疵」であるとして何らかの保障を求める際には、バグや不具合の深刻さが問題となってきます。法律上の瑕疵の問題は、そもそも

1. バグや不具合といえるものであっても軽微なものにすぎず、法律上の「瑕疵」とはいえない場合
2. 法律上の「瑕疵」には該当するが、契約の目的の達成自体は可能である場合
3. 法律上の「瑕疵」に該当し、かつ契約の目的の達成自体も可能でない場合

の3パターンに分かれます。瑕疵担保責任に基づく責任追及の可否を分けているのが、1と2の境目で、瑕疵担保責任に基づいて契約の解除を行うことの可否を分けているのが2と3の境目となります。

第634条

1.仕事の目的物に瑕疵があるときは、注文者は、請負人に対し、相当の期間を定めて、その瑕疵の修補を請求することができる。ただし、瑕疵が重要でない場合において、その修補に過分の費用を要するときは、この限りでない。

2.注文者は、瑕疵の修補に代えて、又はその修補とともに、損害賠償の請求をすることができる。この場合においては、第533条の規定を準用する

第635条

仕事の目的物に瑕疵があり、そのために契約をした目的を達することができないときは、注文者は、契約の解除をすることができる。ただし、建物その他の土地の工作物については、この限りでない。

なお、こうした「瑕疵」の段階的な区別に関しては、以下の記事で詳細に解説を行なっています。

次にベンダーに要求すべき事柄を明確にする

また次に、相手方になにを要求すべきなのかを明確にする必要があります。もし契約の解除を行いたい場合には、それが瑕疵であることだけを立証するのでは足りず、それが「契約の目的を達することができない」といえるほどのものである必要があります。ここでいう「目的」の判断にあたっては、システム開発プロジェクト発足当初に行われた会議の議事録や、仕様書の記載事項などが重要な手がかりとされます。検収合格後にもバグや不具合が事後的に発覚するような事態もありうるため、開発プロジェクトが終了後も各種ドキュメントの保管は徹底しておくべきでしょう。

なお、解除以外には、瑕疵担保責任の内容として求めうるものには、損害賠償請求や瑕疵修補請求などがあります。

その他の注意点

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

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

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

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

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

実装してきた機能や仕様にバグや不具合があるような場合と、そもそも必要な備わっていないような場合では、議論は異なってきます。もし必要な機能がひととおり揃っていないような場合であれば、そもそも請負契約における「仕事の完成」が認められず、債務の履行を認められない可能性もあります。

また、そうした必要な機能や仕様を備えられていないとしても、要件定義の段階でユーザー側が適切な情報提供を行なってこなかった結果なのであれば、そもそも契約内容の一部とみること自体が不適当であると評価すべき場合もありうるでしょう。

まとめ

プロジェクトの工程のなかで生じた問題は、プロジェクトの進行中に発覚する場合もあれば、運用段階などで事後で発覚する場合もあります。無事に全部の工程を終えたとしても必ずしも安心できないというシステム開発プロジェクトの特徴は、「瑕疵担保責任」という制度にこそ象徴されるものであるように思われます。システム開発プロジェクト終了後のことまで見据えた文書管理の徹底をはかるとともに、こうした一連の流れを把握しておくことが重要だと考えられます。