今回は「稼働後に検出した不具合を理由に、ユーザーがいったんは検収したシステムの支払いを拒んだ事件」と、そこから得られる知見を解説しよう。
請負契約によるシステム開発において、検収まで行った発注者が受注者との契約を解除し費用の支払いを拒むという例は、ユーザーとベンダーがシステムの完成をめぐって争うことの多いIT業界においても決して多いことではない。
しかし、この判決は、システム導入の目的と要件の関係やその検証、および導入後のベンダーの不具合対応などについて、多くの論点を提供してくれる。今後に役立つ知見を残してくれるものであることから、今回の題材として取り上げることとした。
請負契約において、ベンダーが「ユーザーと交わした約束をしっかりと果たした」と言えるためには、プロジェクトの開始前、実施中、そしてシステム完成後にどのような点に留意し、どのような活動をすべきなのか、ご自身の経験にも照らし合わせて考えていただきたい。
まずは、東京地方裁判所で平成14年4月22日に出された判決から、事件の概要について述べた部分の要約を示す。
原告:システム開発会社(以下 原告ベンダー)
被告:石材の加工・販売会社(以下 被告ユーザー)
被告ユーザーから自社の販売管理システムの開発を一括請負で受注した原告ベンダーは、請負契約に基づいてシステム全体開発・納品し検収も受けた。しかし被告ユーザーがシステムを稼働させると、処理速度が遅いなど多数の不具合が発覚し、被告ユーザーは原告ベンダーに補修を求めた。ところが原告ベンダーが不具合自体を認めず、補修を行わなかったため、被告ユーザーが請負代金支払いを拒絶し、原告ベンダーは、請負代金の支払いを求めて訴訟を提起した。
補足すると、本件システムの導入目的は「販売管理および経営管理の迅速化ならびに合理化を図ること」であり、処理速度が遅いことは本件システム導入の意義を失う恐れもある重大事であった。このことは原告ベンダーも自ら提案書に書き込んでいることから十分に承知していたと考えられる。
しかし一方で、このように重大な仕様が要件として定義されておらず、被告ユーザーの行った検収も、この点について十分に検証をした上でのことではなかったことも事件の原因となった。
「検収をしたのだから、当然に費用は払われるべきである」という原告ベンダーの訴えに対して、被告ユーザーの行った反論は、「このシステムには重大な不具合があり、完成しているとはいえない。原告ユーザーは約束した仕事をしなかったので、契約は解除し、費用は払わず、前払金の返還も求める他、システムが完成しなかったことによって被った損害の賠償も請求する」というものであった。
私はまず、判決文の主文を飛ばして、双方の主張だけを読んだ。その時点では正直なところ、被告ユーザーの言い分には無理がないだろうかと思わざるを得なかった。
いくら重大な欠陥が導入後に検出されたとしても、原告ユーザーは、システム開発に必要な活動である要件定義・設計・開発・テストを一応は完了させており、被告ユーザーはこれを受け入れて検収もしている。システムは曲がりなりにも動いているのだから、仮にそれが、業務に耐え得ないものであったとしても、「システムが完成していない」つまり「債務不履行だ」として契約を解除するのは、いかにも強引な印象を受けたのだ。被告ベンダーの非を問うならむしろ、「システムは完成したが欠陥が多過ぎる」と瑕疵(かし)担保責任を訴える方が常識的ではないかと考えた。
債務不履行と瑕疵担保責任は、それによって、発注者であるユーザーから受注者であるベンダーに支払われる金額に大きな差が出てくる場合が多い。債務不履行の場合、「約束した仕事をしなかった」という考えなので、契約が解除された場合、ユーザー側が費用を支払う義務はなくなることが多い。
一方、瑕疵担保責任の場合は、あくまで債務は履行されており、契約も有効のままである。従って、受注者であるベンダーには、瑕疵を補修するための費用が求められることになるが、当初、約束された金額自体は有効である。現実的には、開発費用から補修費用を差し引いた金額が支払われる場合が多い(実際の裁判では、これに加えてシステムの不具合により生じた損害賠償についても論じられるが、債務不履行の場合も瑕疵担保責任の場合も同じなので省略する)。
「全く使えないシステムを作られたんだから、金なんか払わない」と考える被告ユーザーの気持ちも分からないではないが、なんといっても、システムは動作しており、検収もしてしまっている。下手をすれば、「債務不履行の主張には理由がない」とされ、全面的な敗訴となる危険もあるのではと考えたのだ。
ところが、判決は私の予想を覆すものだった。
Copyright© 2014 ITmedia, Inc. All Rights Reserved.