とはいえ、実際問題としてソフトウェアをバグなしでリリースすることは至難の業というか、事実上不可能です。コンピュータのソフトウェアというのは、何十万、何百万行に上る、わけのわからない記号や単語の集合体であり、普通の人間が、これを間違いなく書くことなど神業です。もしもユーザ企業が、納品されたソフトウェアに一つでもバグがあることを理由に検収を拒否したとしたら、世の中のITベンダの殆どが商売を投げ出さざるをえなくなるでしょう。
しかし、ユーザ側から考えれば、ソフトウェアのバグの為に業務が止まってしまったり、多額の損失が出たりするのは大問題です。コンピュータの不具合の為に百億を超える損失を出した事例もありますし、スペースシャトルの打ち上げが失敗して乗組員全員が死亡してしまった事故も、その原因のひとつにソフトウェアのバグが挙げられています。こうなると流石に、コンピュータのことだから少しくらいの不具合は仕方ないね、などとは言っていられません。
ソフトウェアにはバグがつきものなのだから仕方ないと考えざるを得ないケースと、そうは言っていられないというケースの両方が存在するわけです。
では、一体、どの程度のバグであれば、ベンダが責任を負うべきなのでしょうか。逆に、どの程度の迷惑を蒙れば、ユーザはベンダに賠償を請求できるのでしょうか。今回からは、その辺りについて裁判所が、どのようなポイントで判断をしているのかについてご紹介したいと思います。まずは、参考となる判例からご覧ください。
ソフトウェアの不具合による契約解除が争われた裁判の例
(東京高等裁判所 平成14年4月22日判決より抜粋・要約)
あるソフトウェアベンダ(以下 ベンダ)は、ユーザ企業(以下 ユーザ) の販売管理等全社システム開発を請け負った。プロジェクトは、納期こそ遅れたものの、一応、予定の作業を完遂し検収を受けることができ、システムは本番稼動に至ったが、稼働後に多数の不具合があることが発覚し、ユーザはこの修正を求めた。
一方、ベンダは開発の残代金約1億1000万円を請求したが、ユーザは不具合の残存を理由に、これを拒絶した。
この為ベンダは、支払いを求めて訴訟を提起したが、ユーザは逆に本契約を解除し、既払いの内金の返還請求と，損害賠償請求をベンダに対して行った。
※( ) 内は、筆者の加筆
この裁判では、システムにバグがあったこと自体は争いがありませんでした。ベンダもユーザから指摘された機能上、性能上の問題についてはその存在を全て認めているようです。争われたのは、システムの完成と損害賠償についてです。問題を少し整理してみましょう。
<< 問題の整理>>
1.システムは完成したのか。
バグつきのシステムは、果たして完成したと言ってよいものなのかどうか。
2. 本システムのバグは損害賠償請求の対象となる瑕疵か。
バグはバグとしても、このシステムの不具合はユーザが損害賠償請求をできるほど重要なものなのかどうか。
裁判では、こうしたことが問題となりました。まずは、1番目のシステムの完成についての判断を見てみましょう。このシステムは、一応開発を完了して検収も受けています。ただ、ユーザとしては、本稼働後に発覚したバグについては受入検査では検出できなかったものが多く、もし、これらの不具合が分かっているなら検収などしなかったと言っています。裁判所はこれについて、以下のように述べています。
不具合が残るシステムでも完成したと見なされるのか
(東京高等裁判所 平成14年4月22日判決より抜粋・要約) ＜つづき＞
請負人が仕事を完成させたか否かについては、仕事が当初の請負契約で予定していた最後の工程まで終えているか否かを基準として判断すべきであり、注文者は、請負人が仕事の最後の工程まで終え目的物を引き渡したときには、単に、仕事の目的物に瑕疵があるというだけの理由で請負代金の支払を拒むことはできない
ご覧の通り、裁判所はシステムの完成を予定していた工程を終えたか否かで判断しています。請負契約というのは、できあがった成果物に対して代金を払う契約なのですが、この場合は予定した工程が終わったからには成果物もできているという判断というわけです。このあたりは、完成したものの姿が見えづらいソフトウェアらしい考え方です。
システムが完成している以上、ベンダは債務を履行していることになり、支払いの拒絶や契約の解除は認められないということになります。ユーザの立場とすれば厳しい判決かもしれませんが、だからこそ工程の完了基準や受入テストの内容については、当初から慎重に検討すべきということでしょう。
