不具合の数が幾つ以上だと、裁判で瑕疵と判断されるのか：「訴えてやる！」の前に読む IT訴訟 徹底解説（9）（1/2 ページ）

「欠陥の数が多過ぎる」とユーザーから14億円の損害賠償を請求されたベンダー。裁判所の判断は？ その根拠は？

[ITプロセスコンサルタント 細川義洋，＠IT]

連載目次

　前回に続いて、納入したシステムの不具合を瑕疵（かし・欠陥）と裁判所が判ずる材料がどのようなものであるかについて説明する。前回は、仮にシステムに不具合があっても、それをベンダーが早期に補修するか代替案を提示するなど、専門家として果たすべき責任を果たしていることが認められれば瑕疵とは判断されず、ユーザーの損害賠償も認められないという趣旨の判例について説明した。

　もちろん裁判所は、不具合にまつわる外的な要因だけを見て、損害賠償の対象となる瑕疵であるかを判断するわけではなく、不具合の内容もよく吟味している。今回は、裁判所が注目するポイントを説明しよう。

契約の目的に照らして判断した事例

　まずは、以下の判例を見ていただきたい。

【事件の概要】（東京地裁 平成16年12月22日判決より抜粋して要約）

　あるユーザー企業がベンダーに販売管理システムの開発を委託したが、納入されたシステムには以下に示すような不具合があった。ユーザー企業は契約の目的が達成できないとして契約を解除し、損害賠償としてベンダーに約4100万円を請求したが、ベンダー側はこれを拒んで訴訟となった。

主な不具合

• 移行データ300件を使用した一括在庫引当処理に44分を要して業務に耐えない。また、その間、他端末での受注登録もできない
• 排他制御に問題があり、商品マスター変更画面を開くとマスターを利用するプログラムが全て止まる

　このシステムは個別契約に基づいて一応納品はされていることから、「システムは完成した」と裁判所は判断している。その上で、「これらの不具合が瑕疵に当たり、損害賠償の対象となるか」が問題となった。

　裁判所は、以下のように判断している。

【裁判所の判断】（東京地裁 平成16年12月22日判決より）

移行データ300件を使用した一括在庫引当処理に44分を要する件について

　本件程度のシステムにおける一括在庫引当処理に要する時間は、せいぜい数分程度が一般的に要求される内容であったということができ、テストデータ300件ですら処理時間に44分も要するようなシステムは、およそ本件契約の内容に適合しないものというほかない。（中略）従って、本件システムにおける一括在庫引当処理の時間に関しては、同程度のシステムに通常要求される内容に適合せず（中略）瑕疵に該当するというほかない。

排他制御について

　数時間を要する一括在庫引当処理中には、一切、他の商品マスターを利用する処理ができず、また、一人でも商品マスターのメンテナンスを行っていればその間は全く一括在庫引当処理ができないことになり、（中略）本件システムが実際の業務において使用に耐えないことは明白であるから、およそ本件契約の内容に適合しないといわざるを得ず、（中略）契約の目的を達することができない重大な瑕疵に該当することが明らかである。

　実は、不具合として取り上げた「一括在庫引当処理の速度」も「排他制御」も要件として定義されていなかった。要件定義書だけを金科玉条とするなら、ベンダーが主張するように、これらの不具合は瑕疵には当たらないかもしれない。

　しかし裁判所は、「要件」によってではなく、そもそもの契約の「目的」に照らして、瑕疵の判断を行った。システムを導入することにより、「ユーザーがどのような業務を目指し」「どのようなメリットを享受しようとしているのか」、そこを重視しての判断といえる。

　裁判所による瑕疵の判断材料の一つは、不具合が契約の目的に影響するものであるか否かである。