委託を受けて開発したシステムをユーザに納入し，請求書も送付しました。しかしユーザは，「処理が遅い」「使い勝手が悪い」「一部の機能が実装されていない」などと言って報酬を支払ってくれません。ユーザの指摘事項は，いずれも軽微なもので，すぐに対応できるものか，あるいはもともと仕様として合意されていないものばかりです。ユーザへの対応をどのようにすべきでしょうか。

システムが完成している場合には，ユーザに対して報酬の支払いを求めることができます。
ただし，納品物に「瑕疵」がある場合，ベンダはこれを修補したり，損害を賠償したりする必要があります。「瑕疵」の意味について，裁判例では，システムには不具合が避けられないものであるから，すぐに修補できるものであったり，代替措置を講じることができるものは，「瑕疵」にはあたらないとされています。なお，仕様として定められていない場合であっても，一般常識に照らして著しく品質を欠くものについては，「瑕疵」と評価されることもあり得ます。

（ａ）システムの未完成と瑕疵

ベンダからユーザにシステムが納入された後，システムがユーザの期待する品質を満たしていない場合，ユーザがベンダに対して「システムは未完成である」「システムに瑕疵がある」などと述べ，報酬の支払いを拒絶することがあります。システムの「未完成」と「瑕疵」は混同されがちですが，法律上は区別されています。

システムの「瑕疵」は，システムが完成してはじめて問題になります。システムの完成については，「システムの完成とは？」で述べたとおりです。システムが完成してユーザに引き渡されれば，ベンダはユーザに対して報酬を請求することができるようになります。システムに不具合（瑕疵）があるとしても，システムの完成が否定されるものではないため，ユーザは，単に「不具合がある」と述べるだけでは，代金の支払いを拒むことはできません（東京地裁平成14年4月22日判決など）。

（ｂ）システムの瑕疵とは

システムに「瑕疵」があるかどうかは，基本的には合意された仕様と実際のシステムの仕様とが一致するかどうかで判断されます。ただし，仕様に定められていない不具合であっても，一般常識に照らして著しく品質を欠くものについては，「瑕疵」と評価されることもありますので，注意が必要です。

さらに，システムの「瑕疵」について，前掲東京地裁平成14年判決は次のように述べています。

情報処理システムの開発に当たっては、作成したプログラムに不具合が生じることは不可避であり、プログラムに関する不具合は、納品及び検収等の過程における補修が当然に予定されているものというべきである。
このような情報処理システム開発の特殊性に照らすと、（中略）注文者から不具合が発生したとの指摘を受けた後、請負人が遅滞なく補修を終えるか、注文者と協議した上で相当な代替措置を講じたと認められるときは、システムの瑕疵には当たらない 。

つまり，すべての不具合が「瑕疵」になるのではなく，遅滞なく補修できず，かつ代替措置も講じられない不具合が「瑕疵」とされています。
このような基準がとられるため，過去の裁判例の多くではユーザによる瑕疵の主張は退けられていますが，瑕疵の主張が認められた例もあります。例えば，前掲東京地裁平成14年判決では，在庫照会の検索処理に30分以上の時間がかかり，システム内容を変更した後の朝に数十分起動時間を要するといった不具合が「瑕疵」にあたるとしています。

（ｃ）瑕疵があるとどうなるか

システムに瑕疵があった場合，ベンダはシステムを修補し，損害賠償を支払う義務を負います。
他方，ユーザによる契約の解除については，システムに瑕疵があったとしても常に認められるものではありません。民法635条本文では，請負の目的物に瑕疵があり，これによって「契約をした目的が達成することができないとき」に限り，契約を解除することができるとされています。

仕事の目的物に瑕疵があり、そのために契約をした目的を達することができないときは、注文者は、契約の解除をすることができる（民法635条本文）。

要するに瑕疵の中でもさらに重大な瑕疵があるといった事情がなければ，契約を解除することはできません。どの程度の瑕疵であれば「契約をした目的を達することができない」といえるかは，瑕疵によるユーザの業務の影響度はもちろんのこと，提案書などの契約締結に至る経緯なども重要視されるでしょう。前掲東京地裁平成14年判決は，在庫照会の検索処理に30分以上の時間がかかる等の不具合を「瑕疵」にあたるとするのみならず，「契約の目的を達することができない」場合にあたるとして，ユーザによる解除の主張を認めています。
契約が解除された場合，ベンダはユーザに対して報酬を請求することができなくなります。

（弁護士　高岡晃士　H29.2.28）