納入されたシステムについて，不具合があると主張して契約の解除するというユーザの主張が，受け入れられなかった事例。
事案の概要
スーパーマーケットの原告Ｘは，システム開発会社Ｙに対し，ハンドヘルド端末等を利用した商品の仕入，買掛，支払管理システムの開発を委託した。Ｙは，開発して納入し，Ｘ側にて二度の運用テストを経たものの，使用に耐えないとして契約を解除し，既払いの6000万円について返還を求めた（Ｘは，主位的には民法635条（瑕疵担保責任）に基づく解除，予備的には，民法541条（債務不履行）に基づく解除および，ヒアリング等を十分に行うべき善管注意義務違反に基づく損害賠償（民法415条）を主張している。）。
Ｘの主張する瑕疵には，
- 商品コード桁数が多く，オーダーブックが厚くなり，発注対象商品の検索に手間取るほか，ハンドヘルド端末(HHT)の使い勝手が悪い点
- HHTに誤入力すると，本部のシステムが停止する点
- システム停止後に再起動すると大量のログリストが出力される点
- 伝票を画面で確認する際，一枚の伝票が一画面に表示されず，確認しにくい点
- プリンタが頻繁に紙詰まりする点
- 発注集計表の追加・修正を一件ずつ行わなければならず，一括入力できない点
- 数量の入力方法が煩雑である点
が挙げられている。
ここで取り上げる争点
上記の点が瑕疵といえるか
裁判所の判断
「瑕疵」とは何かという一般論には特に触れず，上記の点について個別に判断した。
まず，1の点について，
HHTの画面およびジャーナル上商品名が表示されないこと，八桁の商品コードとすることが，システムの構築に当たって予定されていたのであり，Ｘ自身これを認識した上でその使用に合意したのであるから，上記仕様自体が本件システムの瑕疵であるとはいえない。
と，要するに「それは仕様です」という判断である。また，商品を探すのに手間取って，運用テストでは作業時間がかかったという点については「不慣れ」が原因であって，本件システム自体の問題ではないとされた。
次に，2の点について，
（システムが停止すること）は，売上報告が会計処理に直結するものであり，誤ったデータがそのまま蓄積され，これを前提とした作業が先に進んで行ってしまうことのないようにシステム自体に持たされた機能であること，このような設定がなされていることについては予めＸに説明されていたこと，日付の誤入力があってもシステムを停止させないように設定することも可能であること
から，瑕疵と認められないとされた。これも「それは仕様です」という判断である。
大量のログリストが出ること及びそれを見てもオペレータが対応できないという3の点について，
システムの夜間の運転状況を確認するために，ログリストが発行されるように設定されていること自体は，合理性を欠くものとはいえず，さらに，ログリストを発行しないように設定することも可能であるというのであるから，上記の点をもって本件システムの瑕疵と認めることはできない。また，エラーの原因を突き止め，これを修正する作業はシステム管理者が行うのが一般的であるから，システム管理者と同等の知識を有しない者においてこれらの作業を行うことができないからといって，これがシステムの瑕疵に当たるともいえない。
とされた。
伝票が画面で確認しづらいという4の点については，帳票類の確認は画面上ではなく，紙にプリントアウトして行うことが予定されていたとして瑕疵ではないとされている。
プリンタの紙詰まりという5の点については，その頻度，態様に照らして瑕疵とまではいえないとされている。
発注集計表の追加，修正が一括で行えないという6の点については，Ｙから提示された基本設計書どおりに開発されており，その説明も行われていたということで，瑕疵ではないとされている。
数値入力の方法が煩雑であるという7の点とは，これは，数値入力フィールドにデフォルトで”0.00”と書かれていたから，たとえば，""2000""と入力しようとすると，0.00の小数点の位置にカーソルを合わせないとうまく入力できないといった点を指摘したものである。この点について，裁判所は，
入力作業としてはやや煩雑である感が否めないが，これゆえに，本件システムが使用に耐えないものであるとまでは認められない。
と判断している。そのほか，タブキーでフィールドにうまく合わせられないという点なども，使用に耐えないものではなく，瑕疵ではないとしている。
そして，Ｘが指摘した不具合についてはいずれも瑕疵には当たらないとした。
さらに，Ｘは，発注業務を行うのに時間がかかりすぎるということが構造的欠陥であるとして，契約の目的を達することができない瑕疵であるという主張も行っている。この点については，
Ｙは，コンピューターソフトウェアの開発，販売，コンサルティング等の専門企業であり，システムを構築するについては，顧客であるＸから，その業務の内容等必要な事項を聴取し，その結果に基づいて，Ｘのシステム導入目的に適うシステムを構築すべき義務を本件請負契約に基づき負うものと解されるが，他方，Ｘも，一つの企業体として事業を営み，その事業のためにシステムを導入する以上，自己の業務の内容等Ｙがシステムを構築するについて必要とする事項について，正確な情報をＹに提供すべき信義則上の義務を負うものと解される。
という一般論を述べ，時間がかかりすぎたのは，ユーザＸの情報の伝え方が不正確であったからであるとして，本件システムの瑕疵にはあたらないとした。
結局，Ｘの主張はいずれも排斥されている。
若干のコメント
本件でユーザが具体的に指摘した欠陥は，いずれも，合意されていた仕様の範囲内であるか，明確に合意されていた事項ではないとしても，使用に耐えないレベルではないという判断をしています。
特に7点目のような話は，メインフレーム系からブラウザ系への移行の場合，使い勝手が低下することが多く，ユーザからクレームがつきやすいところです。しかしながら，仕様で合意していない限り，使い勝手の部分で「瑕疵」の主張は困難でしょう。
本件では，結果としてユーザ側の主張をすべて退けていますが，ユーザへの配慮のためか，少々蛇足のような判示をしているように見受けられるところがあります。たとえば，上記で引用したように，
Ｙは，コンピューターソフトウェアの開発，販売，コンサルティング等の専門企業であり，システムを構築するについては，顧客であるＸから，その業務の内容等必要な事項を聴取し，その結果に基づいて，Ｘのシステム導入目的に適うシステムを構築すべき義務を本件請負契約に基づき負うものと解される
システム開発請負契約から，直ちに「システム導入目的に適うシステムを構築すべき義務」がベンダに生ずるとすれば，これは大きな負担であり，一般にそこまでの義務が生じるのには疑問です*1。
さらに，
なお，本件システムに法律上の瑕疵がないとしても，Ｙには，Ｘの業務の改善に役立つものとして本件システムの導入を提案したコンピュータシステム構築の請負人として，運用テストの結果に基づいて，本件システムの運用フローや仕様をよりＸの業務に適合するように改善を図る契約上の義務が全くなかったとまではいえないかもしれないが，このような改善を行うためには，（略）ＹとＸとの間で協議が行われることが不可欠である。
この部分の裁判所の意味するところはわかりにくい。前段からすると，ベンダとしては，「（ユーザの）業務に適合するように改善を図る契約上の義務」が「全くなかったとはいえないかもしれない」といっているので，あるのかないのか，はっきりしないですが，書面上明確に合意されていないにもかかわらず，そのような義務までも認めるのは，いき過ぎだと思われます。
*1:もちろん，ベンダとして，そのようなマインドで開発することが求められていることは言うまでもないですが，法的義務といえるかどうかは微妙です。
