ユーザー検収後に発覚したシステム不具合を補修をめぐる争いで、裁判所が1724万円の支払いを命じたのは、ユーザー、ベンダーどちらだったのか?
今回は「稼働後に検出した不具合を理由に、ユーザーがいったんは検収したシステムの支払いを拒んだ事件」と、そこから得られる知見を解説しよう。
請負契約によるシステム開発において、検収まで行った発注者が受注者との契約を解除し費用の支払いを拒むという例は、ユーザーとベンダーがシステムの完成をめぐって争うことの多いIT業界においても決して多いことではない。
しかし、この判決は、システム導入の目的と要件の関係やその検証、および導入後のベンダーの不具合対応などについて、多くの論点を提供してくれる。今後に役立つ知見を残してくれるものであることから、今回の題材として取り上げることとした。
請負契約において、ベンダーが「ユーザーと交わした約束をしっかりと果たした」と言えるためには、プロジェクトの開始前、実施中、そしてシステム完成後にどのような点に留意し、どのような活動をすべきなのか、ご自身の経験にも照らし合わせて考えていただきたい。
まずは、東京地方裁判所で平成14年4月22日に出された判決から、事件の概要について述べた部分の要約を示す。
原告:システム開発会社(以下 原告ベンダー)
被告:石材の加工・販売会社(以下 被告ユーザー)
被告ユーザーから自社の販売管理システムの開発を一括請負で受注した原告ベンダーは、請負契約に基づいてシステム全体開発・納品し検収も受けた。しかし被告ユーザーがシステムを稼働させると、処理速度が遅いなど多数の不具合が発覚し、被告ユーザーは原告ベンダーに補修を求めた。ところが原告ベンダーが不具合自体を認めず、補修を行わなかったため、被告ユーザーが請負代金支払いを拒絶し、原告ベンダーは、請負代金の支払いを求めて訴訟を提起した。
補足すると、本件システムの導入目的は「販売管理および経営管理の迅速化ならびに合理化を図ること」であり、処理速度が遅いことは本件システム導入の意義を失う恐れもある重大事であった。このことは原告ベンダーも自ら提案書に書き込んでいることから十分に承知していたと考えられる。
しかし一方で、このように重大な仕様が要件として定義されておらず、被告ユーザーの行った検収も、この点について十分に検証をした上でのことではなかったことも事件の原因となった。
Copyright © ITmedia, Inc. All Rights Reserved.