バグ，欠陥，瑕疵に関する一般論と，システム開発紛争に関する審理状況を伺い知ることができる事例。
事案の概要
昭和63年12月20日，運送業であるユーザＸと，開発ベンダＹとの間で，IBM AS/400を使用した基幹システム（車両管理，受発注管理など）の開発導入の合意がなされた。Ｙは，同日，開発業務をＺに再委託した。
平成2年2月より本件システムはテスト稼働し，Ｘは，Ｙに対し，約9000万円が支払われた。しかし，Ｘは，本件システムには多数の不具合があるとして，修補を求めたが，Ｚらはこれを補修しなかったとして，委託契約を解除し，約2億7000万円の損害賠償を求めた。
ここで取り上げる争点
- 本件システムにおける不具合の存在及びそれがプログラムの欠陥に基づくものといえるか
裁判所の判断
この事件も，他のシステム開発紛争と同様に，瑕疵に関する事実上の損点が多数存在し，審理が困難を極めたことが以下の判示からうかがえる。
Ｘが指摘した本件システムの不具合は，多数個所に上るものであり（６０か所以上），これらについてＸはプログラムの欠陥によって生じる現象であると主張し，Ｚらはこれを争っている。
そうである以上，そのすべてが事実上の争点となるものである。
（略）現実に本件システムを用いた業務が行われていないことから，本件システムを稼働させた場合にどのような不具合が起こるかを裁判所が認定するには困難が伴い（略），審理の見通しを立てることが困難であった。
(略）平成４年８月２０日に提起され，平成８年１２月１７日に口頭弁論が終結されるまでに，３２回の口頭弁論期日が持たれたが（略），最後の２回を除く３０回の口頭弁論期日は，争点に関する議論及び争点の整理にあてられたことになる。特に平成６年４月２５日の第１３回口頭弁論期日以降，裁判所において次回までの目標を定めた上で，裁判所外でＸをＺの代理人及び担当者が中心となって，本件システム稼働上の不具合の存否を当事者間で検証する作業が行われた。厳しく対立し，多岐にわたっていた争点の整理のために，Ｘ，Ｙ，Ｚの三者が協働して裁判所外で右のような検証作業を行ったことは，争点整理の方法として極めて異例である。
こういうことが「裁判所の判断」の箇所に書かれることは珍しい。
さらに，裁判所の訴訟指揮と当事者の協力を讃えるような判示が続く。
これらの作業を通じて，これまで，ＸとＺとの間で大きく対立していた主張のうち，本件システム稼働上の問題点の認識と，それがどのような作業を経れば解決されうるのかの認識については一致が見られるに至り，争点は，（略）プログラムの欠陥と判断されるべきものかという点に絞られることとなり，コンピュータプログラムについて専門の知識を有しない裁判官であっても判断が可能な程度にまで争点の整理がなされ，後は健全な常識に基づく判断を残すのみとなり，審理の見通しが明瞭に立つこととなった。
この争点整理の経過については，裁判所の助言のもととはいえ，主張において厳しく対立する当事者が協働して作業手順の協議をし，協働して問題点の検証作業を実施し，その結果，右のような争点整理の結果が生まれたものであり，争点整理において専門知識を必要とする事件に関する一つの先駆的試みといえよう。
右当事者間の本件検証実験及び原因解明作業は実質二年余りにわたって行われ，特に，平成６年７月から８月までの二カ月にわたる作業は，裁判所が夏季休廷期間中であるにもかかわらず，ＸとＺの代理人及び担当者が中心となって，夏季の休みも返上して，連日，協議して行われたものであることを記しておきたい。
（略）
その結果としての前記作業に基づく解明度は，極めて高いものであったといえる。
こうなると，これが判決文なのかどうかわからなくなる。
コンピュータソフトウェアにおけるバグ，不具合に関する一般論が展開される。
いわゆるオーダーメイドのコンピューターソフトのプログラムで，本件システムにおいて予定されているような作業を処理するためのものであれば，人手によって創造される演算処理が膨大なものとなり，人の注意力には限界があることから，総ステップ数に対比すると確率的には極めて低い率といえるが，プログラムにバグが生じることは避けられず，その中には，通常の開発体制におけるチェックでは補修しきれず，検収後システムを本稼働させる中で初めて発現するバグもあり得るのである。（略）顧客としては，（略）構築しようとするシステムの規模及び内容によっては，一定のバグの混入も承知してかからなければならないものといえる。
コンピューターソフトのプログラムには右のとおりバグが存在することがあり得るものであるから，コンピューターシステムの構築後検収を終え，本稼働体制となった後に，プログラムにいわゆるバグがあることが発見された場合においても，プログラム納入者が不具合発生の指摘を受けた後，遅滞なく補修を終え，又はユーザーとの協議の上相当と認める代替措置を講じたときは，右バグの存在をもってプログラムの欠陥（瑕疵）と評価することはできないものというべきである。これに対して，バグといえども，システムの機能に軽微とはいえない支障を生じさせる上，遅滞なく補修することができないものであり，又はその数が著しく多く，しかも順次発現してシステムの稼働に支障が生じるような場合には，プログラムに欠陥（瑕疵）があるものといわなければならない。
つまり，法的意味での「瑕疵」とは，遅滞なく修補できず，代替措置も講じられないものに限定されるということである（この判断は，後の同種の裁判例でも踏襲されており，この分野において共通する判断だといえる。）。
その結果，Ｘの指摘する不具合は，すべて「瑕疵」とは認定されず，Ｘの委託契約の解除に基づく損害賠償請求は認められなかった。
若干のコメント
本文中にも書いたように，裁判所は本件の審理に随分と苦労したことが伺えます。ただ，この事件は15年近く前に審理されていたものであって，最近の東京地裁では，この種の事例の取り扱いが増えてきて，特に調停部に回された場合には，効率的に争点・証拠の整理が行われるようになったと感じられます。したがって，代理人弁護士が依頼者に「裁判所はコンピュータのことがわからない素人だから・・」と説明するのは，間違いではないものの，審理が長期化するのは裁判所のせいだけではないと考えられます。
また，本件で争点となった「瑕疵」については，ユーザは，瑕疵を原因として契約を解除しているのであって，その解除の可否という観点から審理がなされている点に注意する必要があります。法的意味での瑕疵に当たらないからといって，ベンダが修補しなくてもよいというわけではなく，現に本件ではＺが修補しています。
ユーザとしては，バグを発見すれば，丁寧にベンダに対して修補を求め，その数が夥しく，次から次へと生じて出口が見えない，という状況を作り出すまでは契約の解除は認められないということに留意すべきでしょう。
