ダイセーロジスティック対丸紅ほか事件第一審判決
東京平成4年(ワ)第14387号侵害賠償等請求事件，同平成5年(ワ)第16569号売買代金等請求事件
判 決
平成４年事件原告及び平成５年事件被告 ダイセーロジスティック株式会社
右代表者代表取締役 田 中 定 由
右訴訟代理人弁護士 渡 辺 修
同 吉 沢 貞 男
同 山 西 克 彦
同 冨 田 武 夫
同 伊 藤 昌 毅
同 峰 隆 之平成４年事件被告 丸紅株式会社
右代表者代表取締役 龍 野 富 雄
右訴訟代理人弁護士 杉 浦 正 健
同 鈴 木 輝 雄
同 上 拾 石 哲 郎
右訴訟復代理人弁護士 鈴 木 真
同 和 田 元 久
同 堀 西 俊 光平成４年事件被告補助参加人及び平成５年事件原告
エヌエスアンドアイ・システムサービス株式会社
右代表者代表取締役 野 本 昭 継
右訴訟代理人弁護士 梶 谷 玄
同 梶 谷 剛
同 岡 正 晶
同 武 田 裕 二
同 和 智 洋 子
主 文
一 平成4年事件について
平成4年事件原告の請求を棄却する。
二 平成5年事件について
平成5年事件被告は平成5年事件原告に対し，金1146万6372円及びこれに対する内金87万5500円に対しては平成2年9月1日から，内金61万8000円に対しては平成3年5月1日から，内金997万2872円に対しては平成3年11月1日から，それぞれ支払済みまで年6分の割合による金員を支払え。
三 訴訟費用及び仮執行の宣言について
１ 訴訟費用は，平成4年事件及び平成5年事件を通して，平成4年事件原告及び平成5年事件被告の負担とする。
２ この判決の第二項は，仮に執行することができる。
事 実 及 び 理 由
第一 請求の趣旨
一 平成4年事件について
平成4年事件被告は平成4年事件原告に対し，金2億7211万7629円及びこれに対する平成4年9月4日から支払済みまで年6分の割合による金員を支払え。
二 平成5年事件について
主文第二項同旨。
第二 事案の概要（以下，平成4年事件原告及び平成5年事件被告を「原告」と，平成4年事件被告を「被告」と，平成4年事件被告補助参加人及び平成5年事件原告を「補助参加人」と略称する）
（平成4年事件について）
一 判断の基礎となる事実
１ 当事者
原告は，貨物自動車運送業等を営む株式会社であり，被告は各種物品の 輸出入及び販売業等を営む株式会社，補助参加人はコンピューター・ソフトウェアの開発業等を営む株式会社である。
２ 本件委託契約の締結
(一) 原告と被告は，昭和63年12月20日，原告が使用する運送システム（以下「本件システム」という）関連ソフト，給与計算ソフト，財務会計ソフトの各ソフトウエアを開発導入するため，原告が日本IBM株式会社製AS/400コンピューターシステムを導入することについて合意した。
(二) 右合意に基づき，同年12月27日，原告と被告との間で，右各ソフトウエア開発の委託契約が締結された（このうち，本件システム関連ソフトウエアに関する契約を「本件委託契約」という）。被告は，右同日，原告向け右各ソフトウエアの開発を，補助参加人に対して再委託した。
本件システムは平成2年2月からテスト稼働を開始し，原告は被告に対する右委託代金を含む右各ソフトウエア開発委託代金を，オリックス株式会社への支払委託の方式により支払った。原告がオリックス株式会社へ支払った代金及び手数料は，本件システム関連ソフトについて6865万8000円（代金5438万4000円，手数料1427万4000円），財務会計ソフト等について1984万8000円（代金1637万7000円，手数料347万1000円）である。オリックス株式会社は，本件システム関連ソフトの代金については平成2年10月31日に，財務会計ソフト等の代金については平成元年11月30日に，被告に支払った。
３ 本件システムの概要
原告は，現在約230台の車両を保有して貨物の運送業を営んでいるが，被告の製作に係る本件システムは，原告の業務の中で枢要部分を占める運送部門について，受発注処理，請求支払処理，売上管理，仕入管理，車両管理，乗務員管理，安全管理，作業管理の各業務の情報処理をコンピューター化することにより，運送管理業務の簡略化，運送管理レベルの向上，事務量の軽減，タイムリーな情報の提供を図ろうとするものである。
本件システムの具体的操作手順は，大略，以下のとおりである。まず会社が荷主から注文を受けると，配車係が配車表を手書きで起票する。コンピューター入力担当者は，右配車表をもとにコンピューターに荷主，発地名，着地名，積込日，運賃等の受注入力を行い，次に，入力した注文につき，運搬を担当する車両番号，乗務員名等の配車情報の入力を行う。出荷・納品作業を行った後は， 運送の結果を運転日報として入力し，全てのチェックが完了すれば，日次更新処理を実行する。これにより，入カデータがコンピューター内の配車表ファイル，売上ファイル，傭車売上ファイル，運行実績ファイル等に反映され，これらの情報が必要に応じて売上元帳，乗務員元帳，車両元帳，売上元帳といった各元帳や各種帳票の形で出力され，経営情報として管理されることになる。毎月の締切前には各荷主ごとに請求締日更新処理をして，各荷主分の請求明細書を出力して送付し，本社において荷主からの入金を確認して全ての事務処理が終了する。
（以上の事実は，当事者間に争いのない事実及び弁論の全趣旨により認めることができる。）
二 原告の主張
１ 本件システムのプログラムの完成不能
本件システムには，以下に述べるとおり重大な不具合が多数あり，予定された機能を全く発揮していない。これは本件システムのプログラムに欠陥があるためであり，右プログラムは，原告における業務使用に到底耐えうるものとはいえず，本件システムを導入した契約の目的が達成されていないことは明白である。
(一) 月次更新処理の不具合
(1) 月次更新処理とは，様々な処理の所要時間を短縮するためにシステム内の不要データを削除するプログラムであり，本件システムにおける右プログラムは，古いデータを削除するための「更新処理」と削除されたスペースを再度データが書き込める状態にするための「再編成処理」の２つの部分から成り立っている。ところが，本件システムにおいて，月次更新処理を行うと，「再編成処理」を除く「更新処理」だけで9～10時間という常識では考えられない時間がかかり，会社業務の妨げとなり，事実上同処理を行うことが不可能である。
(2) 被告及び補助参加人（以下「補助参加人ら」という）は右現象を，原告が毎月行うべき月次更新処理を怠り，本件システム内に不要データを蓄積させたために発生したものであると主張するが，原告は，毎月の月次更新処理を欠かしたことは一度もない。本件システムに不要データが蓄積されているのは，月次フアイル更新プログラムにループ現象を生ずる重大な欠陥が存在し，右ループ現象の発生により不要データが削除されなかったからである。
原告は，平成2年10月3日に，月次更新時にプログラムの異常終了が起きること（月次更新が正常に終了しないこと）を補助参加人に対し報告したが，補助参加人は平成4年1月13日に至るまでプログラムを修正しなかった。そして，この間にループ現象によりシステム内に蓄積された不要データは，現在でも除去されずに残っており，状態は全く改善されていない。したがって，月次更新処理に時間がかかるのは，ループ現象により，不要データが削除されずに蓄積されたことによるものであり，プログラムの欠陥というべきである。
(二) 運賃修正の不具合
(1) 会社の運送業務においては，一旦コンピューターに入力し日次更新処理をした運賃を事後的に修正変更することが必要な場合がある。しかし，本件システムのプログラムにおいては，運賃を修正入力し，修正結果を日次更新，月次更新，請求締日更新をしても，その修正結果が売上元帳等に正しく計上されない。その結果，取引先に出す請求書の内容が誤ったものになるばかりか，これらのトランザグションファイルに保存されているデータを加工して作成される帳票類も不正確なものとなり，経営管理資料としては使用不可能な代物となってしまう。
(2) また，本件訴訟提起後，当事者の合意に基づいて，本件システムに存する不具合の存否を確認することを目的として行われた検証実験（以下「本件検証実験」という）の結果によれば，運賃に関し，右に述べた以外にも不具合が存在することが判明した。
すなわち，車両番号及び乗務員が同一で複数の定期便データの場合，本件システムのプログラムでは運行番号が １つにならないため，売上元帳，売上日計／累計表，売上月報，仕入元帳，仕入日計／累計表，仕入月報，車両元帳，車両月報，乗務員元帳，乗務員月報の各帳票上，運行回数に齟齬が生じ，結果として １運行あたりの売上げ，粗利益，経費の計算結果が正しくならない。また，車両元帳，車両別日計／累計表，車両月報，乗務員元帳，乗務員日計／累計表，乗務員月報の各帳票において，架空の運転日報を入力しないと売上高，運賃収入，高速料が正しく計上されない。
(三) 運行キャンセルの不能
(1) 会社の運送業務においては，一旦注文を受けた件につき，事後その注文がキャンセルされる場合があり，この場合においては，注文をキャンセル扱いにするため，既に入力されているデータを消去する必要がある。
しかし，本件システムにおいては，プログラムの欠陥により，運行キャンセルを行うため 配車データ及び受注データの取消処理を行い，これを各データの関連ファイルに反映させるため日次更新処理を行い，請求支払関係の帳票打ち出しのため請求締日更新を行っても，売上元帳等にはキャンセルされたデータが残ったままになる。この結果，これらの帳票類が経営管理資料として使用不可能な代物となってしまうばかりか，取引先に出す請求書にはキャンセルされたはずの請求が記載されることとなり，過大請求となってしまう。
(2) 補助参加人らは，本件システムの右不具合が発見できなかったのは，原告が不具合の箇所を具体的に指摘しなかったからであり，具体的な指摘がない場合に不具合が残るのはユーザーである原告の責任であるから，右不具合の存在は本件委託契約の解除事由ないし不法行為になりえないと主張する。
しかし，ソフトウエアの開発においては，プログラマーがプログラムの単体テストを行い，サブＳＥが担当のサブシステムをテストし，さらにシステムエンジニア（もしくはプロジェクトリーダー）がシステム全体のテストを実施するという，納品前の何重ものチェックが施されるのが通常であり，その過程でプログラムの不整合はクリアされるべきものとされている。補助参加人らの主張のように，納品後実際に使用していく過程で，ユーザーの指摘に基づいてプログラム上の不整合を発見修正していくことなど契約上予定されていない。コンピュータープログラムにつき専門的知識を有しないユーザーが，不具合の具体的かつ適切な指摘を行うなどという高度の義務を負担とすると解することは到底不可能である。
加えて，原告は，右不具合について従前から改善を申し入れている。すなわち，平成2年11月15日に，原告が運行キャンセル処理を行った際，請求明細書にキャンセルとなった受注がそのまま計上され，請求金額が過大となって出力されるという不具合が発生したため，原告は，同日，補助参加人に対し「システム異常報告書兼処置連絡票」（以下「報告書」という）をもって詳しい報告を行った。これに対して補助参加人は，プログラムの修正を行う旨約束したものの，この約束を実行することができず，右不具合は放置されたままとなった。また，平成4年1月14日に開かれた会議の席上，原告は改めて補助参加人に対して右不具合の発生を指摘するとともに，その改善を申し入れたが，補助参加人はその原因箇所と対応策を見出すことができず，結局，本件システム全体についての再設計・再製作を実施したい旨申し入れてきたのである。したがって，右不具合が解除事由たる債務不履行ないしは不法行為にあたることは明らかである。
(四) 荷主変更の不能
(1) 会社の運送業務においては，原告が注文を受けて荷物を運んだ後になって，運送賃の請求先を当初の発注元の荷主から他の荷主に振り替えてほしい旨の要請を受けることがある。この場合においては，既に入力されている旧荷主のデータを新規荷主に変更する必要がある。ところが，本件システムにおいては，プログラムの欠陥により，荷主変更を行うため配車データ及び受注データの取消処理を行い，新荷主のデータで再度受注入力を行い，次に配車の入力をして実行キーを押すと，異常終了メッセージが表示されてしまい，処理が完結できない。その結果，配車表リスト，売上元帳他各種帳票に変更結果が正しく反映されないこととなり，特に請求書においては，このまま発送すれば旧荷主に対する過大請求，新規荷主に対する過小請求となってしまう。
(2) 原告は，以下のとおり荷主変更の不具合について，補助参加人に発生を報告し，その補修を求めてきたが，補助参加人はこれを補修できなかった。すなわち，平成2年7月2日，荷主変更処理を行ったところ異常終了メッセージが表示されるという不具合が発生したため，原告は同5日にこれを補助参加人に報告した。これに対し補助参加人は，当初は現象が確認できないため報告を待つなどと主張していたが，その後右現象を確認し，調査を開始したものの，効果的な対策を講じることができなかった。また，その後も原告は補修を要求し，補助参加人は平成3年8月14日に，修正プログラムを納入したが，別の不具合が発生したため右修正プログラムを除去せざるを得なかった。そして以後，右不具合は補修されることなく放置された。
(五) 車両変更の不具合
(1) 会社の運送業務においては，注文を受けて一旦配車手配をした後，担当車両が変更になったため，受注及び配車データの入力処理及び日次更新処理終了後に担当車両の変更処理をする必要が生じることがある。しかし，本件システムにおいては，プログラムの欠陥により，車両変更を行うため配車データ及び受注データの取消処理を行い，再度削除した受注データと全く同しデータを入力し，変更すべき配車データを入力し，日次更新処理をして請求締日処理をしても，売上元帳等の帳票類に変更結果が正しく反映されない。
保有する車両ごとの走行距離や注油量等を正確に把握することは，随時適切な車両の管理を実施し，効果的な運送を行ううえでの基礎資料を提供するものとして重要なものであるが，このように不正確なものでは資料として使用に耐えない。また，請求書等には旧データが残存するとともに新規データも計上されてしまうため，内容的に過大請求となってしまうし，乗務員元帳等には乗務員の正確な運転回数が表示されないため，乗務員の給与計算につき歩合給を導入している原告においては，乗務員の給与も不正確なものとなってしまう。
② 補助参加人らは，右現象について，受注データの取消処理という不必要な操作を行なった原告の操作ミスによるものであると主張する。しかし，補助参加人らの主張する操作手順のとおり車両変更を行なうと，配車割付データの取消処理の際にループ現象が発生するという別の不具合が出てくるのであり，この場合には，そもそも何らの帳票の打ち出しすらできずに終わってしまうのである。右(1)主張の操作手順は，ループ現象を避けるためにやむを得ずにとった操作手順なのであり，この点を解決することなく，原告の操作手順に問題があるとする補助参加人らの主張は失当である。
(3) また，本件検証実験の結果によれば，本件システムには，右に述べたもの以外にも，車両変更に関連して以下のような不具合が存在することが判明した。
① 「配車割付エントリー２」画面での新規人力時，１運行複数受注データを入力すると，複数運行番号が付き １運行とならない。また，１運行複数受注の場合，「営業日報エントリー１」画面で運行番号に対してデータ削除をし，同一運行番号で再度入力しようとすると，エラーとなり入力できない。そしてその結果，一部帳票で運転日報項目（走行km，作業時間等）や運行回数が正しく表示されない。さらに一運行複数受注の場合，一部帳票において売上金額が正しく集計されない。
② 売上元帳において荷主別明細データに他の荷主データが混入し，また，入るべき明細データが反映されない。一部帳票において，当該荷主と関係のない明細データが出力され，かつ，荷主コードと荷主名が食い違っている。一部帳票において修正をしていない売上金額が違う金額となって出力される。請求明細一覧表で出力されている明細データの集計が違う（当月取引金額，消費税，請求合計）。かつ，修正した明細データが出力から抜けている。出力されている当月取引金額，消費税，請求合計がどの様に計算されたものかわからない数字になっている。請求明細一覧表で同一受注番号の明細データが重複出力される。売上一覧表で，荷主ごとの取引金額・消費税・請求合計が，請求明細一覧表と違う金額で出力される。また，荷主ごとの当該締後売上げ・当月締前売上げ・売上合計・前月締後請求の集計結果が正しく集計出力されない。請求明細書で，受注単位で金額が違うものと合計請求金額で違うものが出力されてくる。
(4) そして原告は，車両変更の不具合について，再三にわたって補助参加人に補修を要請したにもかかわらず，補助参加人はこれを解消することができなかった。すなわち，平成2年12月5日，営業日報エントリーで車両変更や乗務員変更に関する修正データを入力した結果，車両管理，乗務員管理に関する帳票の全てに修正データが反映されないという問題が生じ，原告は同日，報告書をもって不具合の発生を補助参加人に伝えたが，車両変更処理の不具合は修正されることなく存続した。また，平成3年2月8日，配車表リスト上のデータと傭車情報エントリー画面上のデータが整合せす，また，不整合となっているデータを変更処理しようとしてもできないという不具合が発生し，原告は同日，報告書をもって右不具合の発生を補助参加人に連絡したが，補助参加人は何らの対応もとらなかった。
(六) 乗務員変更の不具合
(1) 会社の運送業務においては，注文を受けて，一旦配車手配をした後，担当乗務員が変更になったため，受注及び配車データの入力処理及び日次更新処理後に担当乗務員の変更処理を行う必要が生じることがある。しかし本件システムにおいては，乗務員変更を行うため配車データを修正し，変更されたデータをファイル登録するため日次更新処理を行い，さらに帳票打出しのため請求締日更新処理をしても，車両元帳や乗務員元帳等の帳票類に変更結果が正しく反映されない。
乗務員変更に関するデータは，運行の実態を正確に把握するために必要であることはもちろんであるが，加えて，原告においては乗務員の給与計算について歩合給を採っているので，乗務員変更が各帳票に正確に反映されないのでは，乗務員の給与計算も誤ったものとなってしまう。
(2) 補助参加人らは，右現象について，営業日報ファイルのデータ修正の操作が欠落している原告の操作ミスによるものであると主張する。しかし，補助参加人らが主張するように営業日報画面を呼び出して処理を行った場合，確かに乗務員データの変更処理は可能となるものの，今度は，車両月報，乗務員月報といった車両元帳ファイル関係のプログラムに存すると見られる欠陥により，右帳票類に記載される「注油量」の項目に異常（乗務員変更を1回実施するごとに「注油量」が勝手に2倍になってしまうというもの）が発生する。すなわち補助参加人らの処理手順に従うと，「注油量」のデータが不正確となり，原告では各運送車両で給油を受けた軽油の使用量が正確に管理できず，原価計算が実際上不可能になるという別の重大な問題が生じることになるのである。
原告は，右現象発生後，直ちに補助参加人に対し本件システムの異常発生を報告したが，補助参加人は原因を特定できず全く状況は改善されなかった。
(3) また，本件検証実験の結果によれば，本件システムには，右に述べたもの以外にも，乗務員変更に関連して以下のような不具合が存在することが判明した。
すなわち，配車リストにおいて運行番号・受注番号が重複した明細データが出力され，合計欄は重複金額を加算している。また，車両元帳で乗務員変更で削除したデータが出力されている。そのため総合計にもその数字が加算され正しくない。車両別日計／累計表で，乗務員変更で削除したデータの売上金額が明細に加算されて出てくる。車両月報で，乗務員変更で削除したデータの売上金額が明細に加算されて出てくる。そのため総合計にも加算され正しくない。
そして，原告は以下のとおり，報告書をもって乗務員変更の不具合の発生を補助参加人に対して報告した。すなわち，平成2年7月26日，乗務員変更処理を行った上で配車表リストを出力したところ，車両番号及び乗務員名が重複して出力され，また乗務員氏名を変更しようとしても出来ないという不具合が発生し，原告は翌27日，右不具合の発生を補助参加人に報告した。また，平成2年7月27日，配車割付エントリー２において処理を行っていたところ，運行番号（乗務員コードの変更）不変という現象が発生したため，原告は同月30日に，右不具合の発生を補助参加人に報告した。さらに，平成2年7月31日には，配車表上，2日間にわた り配車データが重複するという不具合が発生し，原告は8月3日，右不具合の発生を補助参加人に報告した。しかし，その後も乗務員変更については配車表リストに誤ったデータが出力されるという不具合が解消されなかった。
(七) その他の不具合
さらに本件検証実験の準備手続（マスター登録，臨時プログラムのインストール手続）においては，右に述べた以外にも，原告としてもそれまで認識できなかった諸々の不具合が存在することが判明した。
(1) 「地区コードテーブル照会」で最大66回のロールアップを２度繰り返した後のメイン画面への戻りで異常終了した。
(2) 「地区コードテーブル照会」でロールアップが66画面までで，残りのデータがあっても見ることができない。
(3) 「地区名マスター保守」で削除フラグが立っていると，新規登録ができない。また「傭車情報エントリー」の車両番号に対しても，削除フラグが立っていると，新規登録ができない。
(4) 「固定明細エントリー」の発地名及び着地名のコードが数字であるのに，数字以外のアルファベットやカナ文字の入力が可能となっている。そして数字以外のものを入力したファイルを更新すると，数字以外のものも数字で表示してしまう。「傭車情報エントリー」の空車地区コードについても同様である。
２ 被告の責任原因
(一) 本件委託契約の解除に基づく損害賠償責任
(1) 原告は本件システムの不具合について，補助参加人らに対して改善を求め，補助参加人らはプログラムの補修作業を続けていたが，平成4年3月13日，被告は補助参加人を通して，プログラムには補修不可能な構造的欠陥があり，新規に設計製作し直す以外に，プログラムを完成させることは不可能である旨表明するに至った。そこで平成4年6月23日，原告は被告に対し，本件委託契約を解除する旨通知した。
(2) 本件委託契約の解除により，原告は以下のとおりの損害を被った。
① 前記一２（二）の運送システムプログラムの代金及び支払委託手数料 6865万8000円
② コンピューター本体及び周辺機器のリース料金 1億3762万2360円
原告は，本件システム導入のために，コンピューター本体及びその周辺機器について，日本海外リース抹式会社及びオリックス株式会社との間で，左記のとおりリース契約を締結した。しかし，右コンピューター機器類は主として本件システムのプログラムを 運用するために導入されたものであり，経理システムプログラムを運用するだけであれば，このようなコンピューター機器類を導入する必要はなかった。
記
Ⅰ 昭和63年12月29日契約
リース元 日本海外リース株式会社
リース物件 AS/400コンピューター本体
リース期間 平成元年3月から60か月
リース料金 総額6108万円
Ⅱ 平成元年11月1日契約
リース元 オリックス株式会社
リース物件 コンピューター周辺機器
リース期間 平成元年11月から60か月
リース料金 総額3011万5140円
Ⅲ 平成元年12月29日契約
リース元 オリックス株式会社
リース物件 コンピューター周辺機器
リース期間 平成2年1月から60か月
リース料金 総額4642万7220円
③ 本件システム運用のための人件費 2691万5999円
本件システム導入に際し，原告は被告から本件システム稼働開始以降の運用については，原告において独自の運用要員を必要とするとの指示を受けていた。原告は右指示に基づき社員5名を右業務に専従させた。本件システムが一部稼働を開始した平成2年10月から本件委託契約が解除された平成4年6月までの間，これらの社員に対して支払った人件費の総額は合計金2691万5999円である。
④ 本件システム運用のための通信回線費 2973万7908円
本件システムは，互いに遠く離れた原告の本支店間でリアルタイムな情報の交換共有を行うことをその内容とするものであり，各本店支店に設置されたコンピューター間のデータ交換については，各機器をNTTの専用通信回線に接続し，同回線を利用してネットワークを構築するとの仕様になっていた。原告はNTTとの間で計12回線の契約を結び，使用料金は月額合計104万3672円（ 消費税込み）とされた。平成2年4月から本件委託契約が解除された平成4年6月までの間，原告がNTTに対して支払った通信回線使用料は，合計金2973万7908円である。
⑤ 本件システム運用のための保守料金918万3362円
本件システム導入にあたっては，以下の保守料（いずれも消費税込み）が必要とされており，原告は平成2年4月から本件委託契約が解除された平成4年6月までの間，本件システムの保守を委託した日本アイ・ビー・エム株式会社に対し，保守料金として合計金918万3362円を支払った。
Ⅰ AS400システム装置他保守料金 11万5863円（月額）
Ⅱ アナリシス・モデム装置保守科金 18万1095円（右同）
Ⅲ ネットワーク監視遠隔サポート料金 8万2400円（右同）
Ⅳ 5327印刷装置保守料金 27万2950円（年額）
Ⅴ 5394遠隔制御装置保守料金 54万8372円（右同）
(3) よって，原告は被告に対し，本件委託契約の解除に基づく損害賠償請求として2億7211万7629円及びこれに対する訴状送達の日の翌日である平成4年9月4日から支払済みまで商事法定利 率年6分の割合による遅延損害金の支払を求める。
(二) 不法行為に基づく損害賠償責任
(1) 被告は，原告が導入するコンピューターシステムの開発を担当する者として，その開発に当たっては，正しい論理に基づいたプログラムを設計，製作し，これを原告に納品しなければならないにもかかわらずこれを怠り，また，納品前に十分なプログラム単体テスト，結合テスト，納品前テストを実施して，欠陥箇所の発見と補修を行う義務があるにもかかわらずこれを怠り，さらに，納品後本件システムにプログラムを原因とすると思われる不具合が発見された場合には，すみやかに不具合を生じさせた原因を特定し，プログラムの補修を行う義務を負っていたにもかかわらずこれを怠った結果，これを原因とする不具合のため原告において本件システムを稼働し得ないという事態を生じさせ，もって原告に対し，前記(一)(2)記載と同額の損害を与えたものである。
(2) よって，原告は被告に対し，不法行為に基づく損害賠償請求として2億722万7629円及びこれに対する不法行為の日の後である平成4年9月4日から支払済みまで商事法定利率年6分の割合による遅延損害金の支払を求める。
三 補助参加人らの主張
１ 本件システムのプログラムの完成不能について
本件システムのプログラムは完成しており，当事者間で合意された仕様所定の機能を有している。本件システムのプログラムに，解除事由たる債務不履行ないし不法行為にあたるような欠陥は存在しない。
(一) 月次更新処理の不具合について
(1) 原告は，本件システムの月次更新処理には，常識では考えられない時間がかかり使用に耐えないと主張するが，原告主張の右現象は，原告の使用方法が正しくないことによって発生したものであると推測される。
すなわち，本件システムにおいては，原告との合意に基づいて，月次更新時に月次更新した月の3か月前の月に該当するデータを削除するシステムになっている。月次更新処理は，その文字のとおり，毎月行うべき作業であり，きちんと毎月処理が行なわれていればコンピューターには最大4か月分までのデータが保有された状態となる。この状態であれば，「更新処理」が3時間程度，「再編成処理」が4時間半程度で処理が終わり，月次更新処理に要する時間は合計で7～8時間である。そして月次更新処理とは，そもそも締切日作業終了後の夜間に行うことが予定されているものであるから，右の程度の時間で終了するのであればシステムの不具合とはいえない。原告は月次更新の「更新処理」だけで9～10時間かかると主張するが，これは原告が月次更新処理を毎月きちんと行わずに，本件システムが前提としているデータ保有月数以上の月数のデータを保有した状態で月次更新処理をしようとしたためであると推測される。したがって，右現象は原告の使用方法が正しくないことによるものであって，本件システムのプログラムの欠陥ではない。
(2) 原告は，本件システム内の不要データが月次更新のループ現象によって蓄積されたと主張するが，そのようなことはありえない。
すなわち，ループ現象とはプログラムの同じ部分で繰り返しが起きてしまい作業が終了しなくなってしまう現象であり，これを終了させるためにはプログラムを強制的にキャンセルするしかない。ループ現象はこのようにはっきりした形で発生するのであって，発生すればユーザーである原告が認識しないことはあり得ない。ところが，補助参加人が原告から初めてループ現象の報告を受けたのは平成3年12月6日であるから，それ以前に，ループ現象は発生していなかったはずである。原告は平成2年10月3日にループ現象の指摘をしたかのような主張をしているが，原告が右同日に補助参加人に指摘したのは異常終了についてであり，異常終了はループ現象とは全く異なる現象である。そして補助参加人は，平成4年1月13日にはループ現象を改善しているのだから，ループ現象によって不要データが蓄積されたということはありえない。不要データが蓄積したのは，原告が月次更新処理を怠っていたためと推測される。
また，原告が月次更新処理を怠ったことにより不要データが蓄積されている場合でも，不要データは，原告が月次更新処理を怠っていた時点まで遡って順次現在までの月次更新処理を行えば，何時でも除去することができる。そして原告は，過去の不要データの除去方法を十分に承知している。したがって，不要データさえ除去すれば通常の状態になるのであるから，本件システムのプログラムに欠陥がないことは明らかである。
(二) 運賃修正の不具合について
(1) 原告は，運賃修正を行っても修正結果が売上元帳等に正しく反映されないと主張するが，原告主張の右現象は，運賃の修正後に日次更新処理を行わずに請求書発行などを行った原告の操作ミスにより発生したものと推測される。
本件システムは，受注を受け，運送して入力したデータは日次更新処理をすることにより売上元帳等に計上されるシステムとなっており，一旦日次更新処理をした後は，運賃のデータは受注のファイルだけでなく，売上元帳等のファイルにも書き込まれている状態になっている。したがって運賃の修正をする場合には，受注ファイルのデータを修正しただけでは，売上元帳等のファイルのデータは修正前のままなのであって，売上元帳等のファイルのデータを修正するには，修正された受注データを再度売上元帳等のファイルに書き込む処理，すなわち日次更新処理を行うことが必要である。ところが，本件訴訟における原告の当初の主張によれば，原告は運賃修正の際の処理手順として，運賃を修正後直ちに月次更新処理及び請求締日更新処理を行っているのであり，日次更新処理を行っていない。原告はその後「日次更新処理を行った」として主張を補充訂正したが，原告主張の現象の原因としては，日次更新処理を怠ったという操作ミス以外は見当たらない。
したがって，右現象は原告の操作ミスによるものであると推測されるのであって，本件システムのプログラムに欠陥はない。
(2) 原告は，車両番号及び乗務員番号が同一である複数の定期便データの場合，運行番号が １つにならないため，売上元帳等において運行回数に齟齬が生じ，その結果一運行あたりの売上げ等が正しくならないと主張するが，原告主張の右現象はそもそも不具合ではない。
すなわち，車両番号及び乗務員番号が同一である複数の定期便データについて運行番号を １つにするか複数にするかは「定期便テーブル」で登録して決定することになっているのであり，本件検証実験においては，運行番号を１つにするよう登録されていなかった結果，複数の運行番号が採番されたに過ぎないものである。したがって，原告が運行番号を １つになるようにしたいのであれば「定期便テーブルメンテナンス」でそのように修正すればよいのであるから，右現象は本件システムのプログラムの欠陥とはいえない。
また，原告は右の場合において車両元帳等に架空の運転日報を入力しないと売上高等が正しく計上されないと主張するが，運行番号が複数ある場合に，複数の運転日報の入力が必要であることは当然であって，「架空」との主張はあたらない。
(三) 運行キャンセルの不能について
(1) 本件システムに，運行キャンセルを行ってもキャンセル結果が売上元帳等に正しく反映されないという不具合が存在することは認める。
補助参加人が右不具合の原因を調査したところ，その原因はプログラム上のデータの取消順序の単純な並べ方の不整合（いわゆるバグ）であり，半日から1日程度で補修可能なものであることが判明した。実際に右バグは，本件検証実験後の原因解明作業において，補修が行われた。
(2) ソフトウエアの開発においては，実際に使用してみないと発見できないプログラムの不整合がある程度残ることは，避けられない。したがって，ソフトウエア開発委託契約においては，検収に先立つ移行テストでユーザーに実務に則した操作でソフトウエアを稼働してもらい，ユーザーからの指摘を待って，プログラム上のバグを発見修正していくことが予定されている。また，本件システムのプログラムのような大規模なソフトウエアでは，全てのバグをチェックしきることは事実上不可能であり，検収後本番稼働の段階でも，システム稼働上の不具合の指摘があれば，その時点で原因を解明しバグを発見して修正することは通常行われている。
ユーザーから指摘のあったバグについては，開発担当者が不具合の原因を解明しプログラムを修正することになる。しかし，ユーザーが不具合として主張しなければ開発担当者としてはそれを認識することはできないし，主張があいまいであれば原因解明は不可能なのであって，この部分の作業はユーザーが主として責任を負うものである。本件システムのプログラムは原告向けのオーダーメイドのソフトウエアであり，原告はこれを１年半以上も本番稼働させてきたのであるから，本件システムに不具合が発生した場合，原告がその内容について具体的かつ適切な指摘をするのは容易であったはずである。以上のようなソフトウエア開発委託契約の特殊性に照らせば，原告がシステム稼働上の不具合について具体的かつ適切な指摘をしなかったことにより，バグが残った場合には，その責任はむしろユーザーである原告にあるというべきである。
(3) これを，右バグについて考えると，右バグは半日から1日程度で補修可能なものであるから，本件システムを使用する経過で原告から具体的かつ適切な指摘があれば，容易に原因を解明し，補修できたものである。しかし，本件訴訟に至るまで，原告から右不具合について具体的な指摘がなされたことは一度もなかったため，補助参加人がこれに対応することはできなかった。したがって，右不具合が修正されなかったのは，ユーザーである原告の責任であって，右不具合が本件委託契約の解除事由たる債務不履行ないし不法行為になりうるものではない。
(四) 荷主変更の不能について
本件システムに，荷主変更を行なうと異常終了が発生し，処理が完結できないという不具合が存在することは認める。
補助参加人が右不具合の原因を解明したところ，原因は運行番号の採番処理を落とした単純なバグであることが約2時間半で判明した。そして本件検証実験後の原因解明作業において補助参加人が実際に補修を行った結果，荷主変更を行っても異常終了せずに処理が終了し，帳票類に正確にデータが反映されることが確認された。
したがって，右不具合についても補助参加人において，具体的に本件システム稼働上の不具合の内容が確認されれば，容易に原因を解明し補修することが可能であったものである。しかし右不具合については，平成3年7月30日に原告から「取消して再度同じ配車をすると異常終了する」という類似のクレームがあったものの，同年9月30日に補助参加人が原告のコンピューターで再現テストを行ったところ，具体的現象が再現しなかった。そこで当面様子を見ることになっていたが，本件訴訟まで同様のクレームはなく，補助参加人らとしては対応のしようがなかったという経偉がある。以上の経緯に照らせば，右不具合についても，本件委託契約の解除事由たる債務不履行ないし不法行為となりうるものではない。
(五) 車両変更の不具合について
(1) 原告は，本件システムには，車両変更を行っても変更結果が各帳票に正しく反映されないという不具合が存在すると主張するが，原告主張の右現象は，原告の操作ミスにより発生したものである。
すなわち，車両の変更は，受注内容を変更するものではなく，配車内容を変更するものであるから，配車割付のデータを取消処理すれば足りるものであり，それ以前の受注データを取り消す必要はない。ところが，原告の主張によれば，原告は車両変更の処理手順として，受注のデータまで取消処理している。このような不要な操作を行ったために，車両元帳等に正確なデータが反映されなくなったものである。正しい処理手順は，①配車データの削除，②新しい配車データの入力，③営業日報ファイルの修正，④日次更新処理，⑤請求締日処理の順であり，右操作手順において車両変更を行えば，変更結果は正しく反映される。
したがって，右現象は原告の操作ミスにより発生したものであって，本件システムのプログラムの欠陥ではない。
(2) 原告は，右(1)で補助参加人らが主張する処理手順で車両変更を行うと，配車割付データの取消処理の際にループ現象が発生すると主張するが，右の処理手順で車両変更を行なってもループ現象は発生しない。右現象が発生するとすれば，それは原告の操作ミスによるものである。
(3) 原告が前記二１(五)(3)で主張するとおり，本件システムに， １運行複数受注の車両変更に関連して，売上元帳上荷主別の明細データに他の荷主データが入り込む，また，入るべき明細データが反映されず出てこない等の不具合が存在することは認める。
補助参加人において，右不具合の原因解明作業を行ったところ，これら複数の不具合の原因が，結局２つのバグに収束されるものであることが1日程度で判明した。これら２つのバグは，プログラム製作上の運行番号の採番処理ルートの選択ミスと荷主のセット方法のミスという単純なものであり，容易に補修できるものである。実際，補助参加人は，本件検証実験後の原因解明作業において，1日程度でこれを補修した。
右不具合はいずれも１運行複数受注のケースでのみ発生するもので， １運行で１つの受注を行うケースでは発生しない。右不具合についても１運行複数受注のケースで発生したということを含む具体的かつ適切な指摘があれば，補助参加人らとしては，右のとおり，容易にその原因を解明でき補修することができたものである。しかし，原告からこれまでにこのような指摘がなされたことがなかったため，補助参加人は右バグを補修することができなかった。したがって，これらのバグも，本件委託契約の解除事由たる債務不履行ないし不法行為となりうるものではない。
(六) 乗務員変更の不具合について
(1) 原告は，乗務員変更を行っても変更結果が各帳票類に正しく反映されないと主張するが，原告主張の右現象は，原告の操作ミスにより発生したものである。
すなわち，乗務員のデータは，配車割付ファイル及び営業日報ファイルに入力されるものであるので，これを修正するときは，配車割付ファイルデータを修正した後，営業日報ファイルのデータを修正する操作をしなければならない。営業日報ファイルのデータは，配車割付ファイルのデータを修正した後，メインメニュー画面で営業日報画面を呼び出すことにより，自動的に修正されるシステムになっている。このように正しい操作手順で乗務員変更を行えば，変更結果は正しく反映される。
ところが，原告の主張によれば，原告は乗務員変更の処理手順として，配車割付ファイルのデータを修正した後，営業日報画面を呼び出さずに，いきなり日次更新処理を行っている。したがって，右現象は原告の操作ミスにより発生したものと推測されるのであって，本件システムのプログラムに欠陥はない。
(2) 本件システムに，乗務員変更を行うと車両月報等に記載される「注油量」の項目に異常が発生するという不具合が存在することは認める。
補助参加人が右不具合の原因を調査した結果，日次更新処理プログラムの中の注油量の処理の部分にバグが存在することが判明し，補助参加人は本件検証実験後の原因解明作業において，右バグを補修した。
したがって，右バグについても，原告からある程度具体的かつ適切な指摘がなされていれば，容易に原因を解明し補修することが可能であったものである。しかし，本件訴訟提起以前に，原告が本訴で行ったような具体的かつ適切な指摘を行ったことはなかったので，補助参加人としては対応のしようがなかった。よって，右不具合も本件委託契約の解除事宙たる債務不履行ないし不法行為となりうるものではない。
(3) 原告が前記二１(六)(3)で主張するとおり，本件システムに， １運行複数受注の乗務員変更に関連して，配車表リストにおいて運行番号，受注番号が重複した明細データが出力され，また，合計欄では重複金額が加算されている等の不具合が存在することは認める。
補助参加人において，右不具合の原因解明作業を行った結果，これら複数の不具合の原因が，結局２つのバグに収束されるものであることが半日程度で解明された。これらのバグはプログラム製作上，キー項目（データを並び替えたり，分類して集計する場合に条件として使用する項目）に運行番号が漏れていたということと，削除命令がひとつ抜けていたというそれぞれ単純なミスに過ぎず，容易に補修できるものである。実際，補助参加人は本件検証実験後の原因解明作業において，１日程度で右バグを補修した。
右不具合は，いずれも１運行複数受注のケースでのみ発生したものであり， １運行で１つの受注を行なうケースには発生しない。したがって右不具合についても１運行複数受注のケースで発生したということを含む具体的かつ適切な指摘があれば，補助参加人としては右のとおり，容易にその原因を解明でき補修することができたものである。しかし，原告からこれまでにこのような指摘がなされたことがなかったため，補助参加人はバグを補修することができなかった。したがって，右不具合も，本件委託契約の解除事由たる債務不履行ないし不法行為となりうるものではない。
(七) その他の不具合について
(1) 原告が前記二１(七)(1)で主張するとおり，本件システムにおいて，「地区コードテーブル照会」で最大66回のロールアップを2度繰り返した後のメイン画面への戻りで異常終了するという現象が存在することは認める。
しかし，右現象は本件検証実験において通常業務では行わない作業を行ったため発現した現象であり，実務上支障のあるものではない。かつ，指摘があれば修正はごく簡単である。したがって，右現象は本件システムのプログラムの欠陥に基づくものではない。
(2) 原告が前記二１(七)(2)ないし(4)で主張するとおり，本件システムにおいて，「地区コードテーブル照会」でロールアップが66画面までで，残りのデータがあっても見ることができない等の現象が存在することは認めるが，右各現象については，現状の本件システムがこのような仕様になっていることは何ら不合理なことではなく，実務上も支障が生ずるようなものではない。したがって，右各現象は本件システムのプログラムの欠陥に基づくものではない。
(3) また，原告も認めるとおり，原告は右各現象の発生をこれまで認識していなかったのであって，したがって原告から被告らに対しこれらの現象についてクレーム申立てがなされたことはない。原告から申立てがない以上，補助参加人らとしては具体的に対応できなかったものであり，右現象は本件委託契約の解除事由たる債務不履行ないし不法行為となりうるものではない。
２ 被告の責任原因について
(一) 本件委託契約の解除に基づく損害賠償責任について
右１のとおり，本件システムのプログラムに7つのバグがあったことは認めるが，右バグはいずれも，ユーザーである原告から具体的かつ 適切な指摘がなかったために修正されなかったものであり，その責任はむしろユーザーである原告にあるというべきである。よって，これらバグが残っていることをもって，本件委託契約の解除事由とはなしえず，原告の契約解除は効力を有しない。
原告の損害は，否認ないし争う。
(二) 不法行為に基づく損害賠償責任について
争う。
四 争 点
１ 本件システム稼働上の不具合の存在及びそれが存在する場合，その原因がプログラムの欠陥に基づくものといえるか。
２ 原告の損害額
（平成5年事件について）
一 補助参加人の主張
１ 補助参加人は平成2年5月29日，原告かち，経理システムソフトウエアについての出力帳仕様変更を金87万5500円（消責税込み）で請け負い，平成2年7月31日までに完成させて納入した。代金の支払期日は平成2年8月31日と定められた。
２ 補助参加人は平成2年12月5日，原告から，経理システムソフトウエアについての機能追加を金61万8000円（消費税込み）で請け負い，平成3年3月1日までに完成させて納入した。代金の支払期日は平成3年4月30日と定められた。
３ 補助参加人は平成3年3月23日，原告との間で，磁気ディスク装置（品番9332-600）他を金896万1000円（ 消費税込み）で販売する旨の売買契約を締結し，平成3年5月16日に納入した。代金の支払期日は平成3年10月31日と定められた。
４ 補助参加人は平成3年6月4日，原告との間で，PS/55一式を金101万1872円（ 消費税込み）で販売する旨の売買契約を締結し，平成3年6月18日に納入した。代金の支払期日は平成3年10月31日と定められた。
５ よって補助参加人は原告に対し，右１項の請負契約に基づき，請負代金87万5500円及びこれに対する支払期日の翌日である平成2年9月1日から支払済みまで商事法定利率年6分の割合による遅延損害金の支払を，右２項の請負契約に基づき，請負代金61万8000円及びこれに対する支払期日の翌日である平成3年5月1日から支払済みまで商事法定利率年6分の割合による遅延損害金の支払を，右３及び４項の売買契約に基づき売買代金997万2872円及びこれに対する支払期日の翌日である平成3年11月1日から支払済みまで商事法定利率年6分の割合による遅延損害金の支払を求める。
二 原告の主張
１ 原告と補助参加人の間で各請負契約及び売買契約（以下「本件請負等契約」という）が締結されたことは認める。
２ 本件請負等契約に至る経緯
本件請負等契約のうち，前記一１の経理システムソフトウエアに関する出力帳仕様変更及び前記一２の同 システムソフトウエアの機能追加は，本件システムに存する多数の不具合から生じていた，本件システムの全体にわたる不備を補うために必要となったものであるが，これらは基本設計の範囲を超えるという補助参加人の説明から，新規に請負契約の締結となったものである。
また，前記一３の磁気ディスク装置他については，本件システムの月次更新処理に要する時間が常識はずれの長時間となるとの不具合が問題となっていた平成3年3月ころ，右不具合を解消するためにどうしても必要であるとの補助参加人の提言により購入したものである。
原告は，右各契約の目的である出力帳仕様変更，機能追加，磁気ディスク装置他の増設により，本件システムの正常稼働が可能であるとの補助参加人の言を信用して，これらの契約に応じたのである。
前記一４のパーソナルコンピュータの購入については，本件システムに存在する不具合により同 システムが正常に稼働しないため，情報システム部において，同システムが正常稼働を開始するまでの代替的方策としてパーソナルコンピュータを使用して，運送管理業務を代行したものである。
３ 原告の支払義務の不存在
(一) 本件請負等契約の錯誤無効
前記２のとおり，原告は本件請負等契約の締結により本件システムの正常稼働が可能であるとの補助参加人の言を信用して，各契約に応じたものであり，契約に際しては動機に重大な錯誤が存したものである。そして右錯誤は補助参加人においても十分承知していたのであるから，各契約は錯誤により無効である。
(二) 支払条件の未成就
本件請負等契約については，一応の支払期限として前記一記載のとおりの各月日が定められていたが，右に述べたとおり，本件システムには多数の不具合が存しており全く使用できない状態にあり，しかもこれらは一向に改善されない状況にあったため，原告は補助参加人に対し，本件システムの不具合が解消され，正常に使用できる状況になるまではその支払を留保する旨通告し，補助参加人はこれを了承した。
しかるにその後も本件システムの全体にわたる不具合は一向に解消されず，最終的には，本件システムの開発担当者である補助参加人から原告に対し，平成4年3月13日付けで本件システムは補修不能であり，再設計・再製作する以外に方策はない旨の通知が為されるに至ったため，原告としてはやむなく，同年6月23日，被告との間で締結していた本件委託契約を全て解除し，さらに被告に対し本件訴訟を提起したものである。
したがって，本件請負等契約が仮に有効であるとしても，本件システムの不具合の解消と正常な稼働開始という条件が成就されていないのであるから，原告に具体的な支払義務は生じていない。
(三) 本件請負等契約の解除
本件請負等契約は，本件システムが正常に機能することを前提とするところ，その一連の不具合のために，全く機能を発揮し得ずに，本件委託契約は解除された。したがって，本件請負等契約は，その前提を失ったことになり，当然のことながら契約は解除されるべきこととなる。
原告は平成8年12月17日，本件訴訟の口頭弁論期日において，本件請負等契約を解除する旨の意思表示をなした。
三 争 点
補助参加人と原告との間で締結された各請負契約及び売買契約について，次のいずれかの主張が認められるかどうか。
ｌ 各契約が錯誤により無効かどうか。
２ 各契約に基づく支払義務につき本件システムの正常稼働を条件とする旨の合意があり，右条件が成就していないかどうか。
３ 各契約の解除は有効かどうか。
第三 争点に対する判断
一 本件事件の特殊性と争点整理の経過
1 本件事件のうちの主たるものである平成4年事件は，運送部門のコンピューターシステムの開発を被告に委託した原告が，右システム関連ソフトウエアのプログラムに欠陥があり，委託契約の目的を達成できないとして右委託契約を解除する旨の意思表示をし，被告に対して損害賠償を請求した事件であり，実質的には，被告から右プログラム作成業務の委託を受けた補助参加人と原告の間のプログラムの瑕疵の有無をめぐる争いとなったものである。原告は本件システムには多数の不具合があり使用に耐えないが，それはプログラムの欠陥に基づくものであると主張し，補助参加人は原告主張の不具合は原告の操作ミスによるものか，又はプログラム作成上の単なるバグにすぎないものであり，プログラムに欠陥はないと主張した。
ここで原告が指摘した本件システムの不具合は，多数箇所に上るものであり（後の確認作業においては60項目以上となった），これらについて原告はプログラムの欠陥によって生じる現象であると主張し，補助参加人らはこれを争っている。そうである以上，そのすべてが事実上の争点となるものである。しかも，プログラムに欠陥があるかどうかの前提となる本件システム稼働上の右不具合の存否自体についても，補助参加人らの認めるところとはならなかったが，原告から本件委託契約の解除の意思表示がなされ，現実に本件システムを用いた業務が行われていないことから，本件システムを稼働させた場合にどのような不具合が起こるかを裁判所が認定するのに困難が伴い（人証の取調べによって本件システムの不具合の存否自体を認定することは，それに争いがある以上，極めて困難なことである），審理の見通しを立てることが困難であった。
２ 平成4年事件は，平成4年8月20日に提起され，平成8年12月17日に口頭弁論が終結されるまでに32回の口頭弁論期日が持たれた（その間の平成7年12月12日から平成8年1月10日までの間には3回の和解期日も持たれた）が，右１のような本件事件の争点の特殊性から，32回の口頭弁論期日のうち，証人尋問にあてられた最後の2回を除く30回の口頭弁論期日は，争点に関する議論及び争点の整理にあてられたことになる。
特に平成6年4月25日の第13回口頭弁論期日以降，裁判所において次回までの目標を定めた上で，裁判所外で原告と補助参加人の代理人及び担当者が中心となって，本件システム稼働上の不具合の存否を当事者間で検証する作業が行われた。厳しく対立し，多岐にわたっていた争点の整理のために，原告，被告，補助参加人の三者が協働して裁判所外で右のような検証作業を行ったことは，争点整理の方法としては極めて異例である。この作業を通して，次のように，当事者間に本件本件システムの不具合に関する共通した認識ができ，それがプログラムの欠陥に基づくものといえるかどうかの判断のみが残されることになり，裁判所が判断する対象が明瞭になったものである。
すなわち，原告と補助参加人の代理人及び担当者が中心となって，平成6年4月から7月にかけて，本件システム稼働上の不具合の存否を検証するための作業手順の打合せがなされ，共同で作成されたオペレーション手順書に基づき，同年7月15日から同年8月23日まで，裁判所外で，原告及び補助参加人の代理人及び担当者が中心となって，本件検証実験が行われた。右検証実験の結果は，実験記録として，３者共通の書面にまとめられた（ 証拠＜省略＞）。右関係者は，右検調実験において確認された本件システム稼働上の問題点について，原因解明作業を行うことを合意し，協議を重ねて原因解明作業実行計画書を作成した。この計画書に基づき，平成7年6月19日から同年7月21日まで，原告及び補助参加人の代理人及び担当者が中心となって，各問題点について原因解明作業が行われた。右作業後，３者は，原告本社において，本件検証実験の結果確認された本件システム稼働上の問題点の解明作業が終了したことを確認した。
３ これらの作業を通して，これまで，原告と補助参加人の間で大きく対立していた主張のうち，本件システム稼働上の問題点の認識と，それがどのような作業を経れば解決されうるのかの認識については一致が見られるに至り，争点は，右のような作業により解決されうる問題点があることが，本件システム関連ソフトウエアのプログラムの欠陥と判断されるべきものかどうかという点に絞られることとなり，コンピュータープログラムの専門の知識を有しない裁判官であっても判断が可能な程度にまで争点の整理がなされ，後は健全な常識に基づく判断を残すのみとなり，審理の見通しが明瞭に立つこととなった。この争点整理の経過につい ては，裁判所の助言のもととはいえ，主張において厳しく対立する当事者が協働して作業手順の協議をし，協働して問題点の検証作業を実施し，その結果，右のような争点整理の結果が生まれたものであり，争点整理において専門知識を必要とする事件に関する １つの先駆的試みといえよう。右当事者間の本件検証実験及び原因解明作業は実質2年余にわたって行われ，特に，平成6年7月から8月までの2か月にわたる作業は，裁判所が夏季休廷期間中であるにもかかわらず，原告と補助参加人の代理人及び担当者が中心となって，夏季の休みも返上して，連日，協働して行われたものであることを記しておきたい。
本件事件の審理方法の選択肢としては，鑑定人を選任して本件システム稼働上の問題点の解明にあたってもらうことも考えられたが，その人選及び当事者に納得のいく鑑定人の作業手順をどのように計画するかをめぐって困難があり，前記のような作業が選択されたものである。その結果としての前記作業に基づく争点の解明度は，極めて高いものであったといえる。当裁判所としては，以上のような原告と補助参加人の代理人及び担当者を中心とする関係者の努力の結果を 踏まえた上で，争点について判断を示すこととしたい。
二 平成4年事件について
原告の指摘する本件システムの各不具合について，それが存在するかどうか，及び存在する場合，それがプログラムの欠陥に基づくものであるかどうかを検討する。
１ 月次更新処理の不具合について
(一) 丙第20号証及び弁論の全趣旨によれば，月次更新処理とは様々な処理の所要時間を短縮するためにシステム内の不要データを削除するプログラムであること，本件システムでは当事者間の合意により月次更新時に月次更新した月の3か月前の月に該当するデータを削除するシステムになっていること，したがって毎月正常に月次更新処理がなされていればシステム内のデータ量は最大でも4か月分となるはずであること，月次更新処理は毎月末の業務終了後に実施されることが予定されており 翌日の就業開始時までに処理が終了していればシステムとして問題ないことが認められる。
そして，甲第29号証によれば，本件検証実験実施当時における本件システムのディスク使用率は85・57％であったこと，右使用率の下で月次更新処理を行ったところ，18時間9分もの時間がかかったこと，ディスク内にあるデータの一部を削除する臨時のプログラムを実行して，システム内のデータ量を本来の定量である4か月分にまで削除した結果，ディスク使用率は55・21％となったこと，右使用率の下で月次更新処理を行ったところ，6時間30分で処理が終了したことが認められる。
以上の認定事実によれば，本件検証実験においては，本件システムでは，月次更新処理を行うのに予定以上の長時間を要していたことが認められるが，右現象は，プログラムの欠陥を直接の原因とするものではなく，システム内に本来の定量以上の不要データが蓄積されていたことによるものであると認められる。
(二) 原告は，本件システム内に不要データが蓄積されたのは，月次更新プログラムのループ現象によりデータが削除されなかったためであるから，現在，月次更新処理に多大な時間がかかるのは，プログラムの欠陥であると主張する。これに対し，補助参加人らは月次更新処理にループ現象が存在したことは認めるものの，平成3年12月6日に原告から初めて指摘を受けた後，平成4年1月13日にはループ箇所のプログラムを修正したのであるから，長期間のループ現象により不要データが蓄積したことはありえないと主張する。
そこで，いつの時点から月次更新のループ現象が発生していたのかを検討するに，原告は本件システムが一部稼働を開始した平成2年10月からループ現象は既に発生していたと主張する。しかし，ループ現象とは，プログラムの同じ部分で繰り返しが起きてしまい作業が終了しなくなる現象であり，ユーザーに明確に認識できる形で発生するものであるから，月次更新処理時にループ現象が発生していながら，原告がその旨を補助参加人に知らせないとは考えにくいが，関係各証拠を検討しても，原告が平成3年12月6日より前に右報告をしたことを認めるに足りる証拠はない。原告は平成2年10月13日にループ現象の発生を報告したと主張するが，丙第1号証によれば，原告が右同日報告したのは，ループ現象ではなく月次更新処理の異常終了についてであることが認められるから，原告の右主張は採用することができない。以上によれば，ループ現象が平成2年10月から既に発生していたとの事実は，これを認めるに足りる証拠がないものといわなければならない。
したがって，長期間のループ現象により本件システムに不要データが蓄積されたとの事実を認めることはできず，これによって本件システムの月次更新処理に不具合が生じたとする原告の右主張は理由がない。
２ 運賃修正の不具合について
(一) 原告は，本件システムには，運賃修正を行ってもその正しい結果が売上元帳等に反映されないという不具合が存在すると主張する。
しかし，甲第29号証によれば，本件検証実験において，運賃修正を行ったところ，修正結果が各帳票類に正確に反映されたことが認められ，原告主張の右現象の発生を認めるに足りる証拠はない。したがって，本件システムに運賃修正に関する不具合が存在するとの原告の右主張は理由がない。
(二) 原告は，本件検証実験を行った結果，本件システムでは車両番号及び乗務員が同一で複数の定期便データの場合，運行番号が1つにならないため，売上元帳等においては運行回数に齟齬が生じ結果として1運行あたりの売上等の計算結果が正しくならず，また，車両元帳等においては架空の運転日報を入力しないと売上高等が正しく計上されないという不具合が確認されたと主張する。
しかし丙第4号証の1，2によれば，本件システムにおいては，車両番号及び乗務員が同一で複数の定期便データの場合に運行番号を1つにするか複数にするかは，「定期便テーブルの登録」によりコントロールできるようになっていることが認められ，原告が1運行番号を希望する場合には「定期便テーブルの登録」でその旨の設定をすれば右のような問題は生じないのであるから，原告主張の右現象をもって，本件システムの不具合ということはできない。甲第29号証には，「当社側では「定期便テーブルの登録」によってコントロールすることはできないと認識している」との原告の認識が記載されているが，原告の右認識を裏付けるに足りる客観的資料は提出されていないから，これを採用することはできない。よって原告の右主張は理由がない。
３ 運行キャンセル不能の不具合について
(一) 本件システムにおいて，前記第二の二１(三)(1)のとおり，運行キャンセルを行ってもキャンセル結果が売上元帳等に正しく反映されないという不具合があることは当事者間に争いがない。そして，丙第5号証及び弁論の全趣旨によれば，右不具合の原因は，プログラム上のデータの取消順序の単純な並び方の不整合であり，半日から1日程度で補修可能であることが認められる。
右認定のプログラムの不備の内容に照らせば，本件システムの右不具合はプログラム上のいわゆるバグが原因であったものと認められる。本件システムの内容，プログラムの全体規模，プログラムが右システムのためのオーダーメイドされたソフトウエアであり，多数の顧客が実際に運用することによりテスト済みの既成のソフトウエアを利用したものではないことに照らせば，本件システムのプログラムに右のようなバグが生ずることは避けることができないものであるということができ，その補修は，プログラム製作者と本件システムの利用者との共同作業によってなされるほかないものといえる。バグの中には，本件システムの試験稼働期間中に発生するものもあり，それは一般に検収までの間に補修されるのであるが，バグの内容によっては，検収後，システムを本稼働させる中で発見されるものもある。右バグを原因とする不具合は，後に認定するとおり，検収後に発見されたものである。
原告はソフトウエア開発においては検収（納品）前に何重ものシステムのプログラムのチェックを行うものであり，検収後，実際に使用していく過程でユーザーの指摘に基づいてプログラムの不整合を発見修正していくことなど契約上予定されていないと主張する。確かに，一般の物品に関する売買契約ないし請負契約に基づく納品の場合には，原告主張のとおりであるが，いわゆるオーダーメイドのコンピューターソフトのプログラムで，本件システムにおいて予定されているような作業を処理するためのものであれば，人手によって創造される演算指示が膨大なものとなり，人の注意力には限界があることから，総ステップ数に対比すると確率的には極めて低い率といえるが，プログラムにバグが生じることは避けられず，その中には，通常の開発態勢におけるチェックでは補修しきれず，検収後システムを本稼働させる中で初めて発現するバグもありうるのである。多数の顧客が実際に 運用することによりテスト済みの既成のソフトウエアを利用し，又はこれを若千手直ししてコンピューターを稼働させる場合には，そのような可能性が極めて低くなるが，顧客としては，そのような既成ソフトのない分野についてコンピューター化による事務の合理化を図る必要がある場合には，構築しようとするシステムの規模及び内容によっては，一定のバグの混入も承知してかからなければならないものといえる。
(二) コンピューターソフトのプログラムには右のとおりバグが存在することがありうるものであるから，コンピューターシステムの構築後検収を終え，本稼働態勢となった後に ，プログラムにいわゆるバグがあることが発見された場合においても，プログラム納入者が不具合発生の指摘を受けた後，遅滞なく補修を終え，又はユーザーと協議の上相当と認める代替措置を講じたときは，右バグの存在をもってプログラムの欠陥（瑕疵）と評価することはできないものというべきである 。これに対して，バグといえども，システムの機能に軽微とはいえない支障を生じさせる上，遅滞なく補修することができないものであり，又はその数が著しく多く，しかも順次発現してシステムの稼働に支障が生じるような場合には，プログラムに欠陥（瑕疵）があるものといわなければならない。以下 ，この観点から本件について見てみることとする。
(三) 原告が右バグに係る運行キャンセル不能の不具合を指摘した時期について検討する。
原告は，平成4年1月14日に開かれた会議の席上で補助参加人に対し，右不具合を指摘したと主張する。原告の右主張が認められるならば，補助参加人がその修正に着手したのは本件訴訟の提起後であるから，右の遅滞なく補修を終えたとはいえず，単なるバグであると軽視することはできないこととなる。そこで証拠関係について検討してみると，補助参加人のシステム本部担当部長である証人高良和郎は，右時点で原告から補助参加人に対し，そのような指摘があったことを否定しており，他に原告の右主張事実を認めるに足りる証拠はない。
また原告は，平成2年11月15日に，報告書（証拠＜省略＞）をもって，右不具合を補助参加人に対し指摘したと主張する。しかし，証人高良の証言及び丙第22号証を合わせ考えると，右報告書のクレームは，請求締日処理後の「請求関係データ」の追加登録・削除が出来ないというものであり，運行キャンセルの不能とは異なる事項であるとの見方をすることができ，右報告書の当該記載及び添付資料を子細に検討しても，右報告書が，本件訴訟で確認された運行キャンセル不能の不具合を指摘したものであると直ちに理解することはできない。したがって，右報告書が原告の右主張の適切な裏付け証拠になっているとはいえず，他にこれを認めるに足りる証拠はない。
もっとも，証人柏倉俊示は，原告の当時の情報システム部長として，補助参加人に対し平成4年1月14日の会議に先立つ平成3年9月20日ころ，運行キャンセルの不能を指摘した旨供述する。そこで，証人柏倉の右証言を真実と認めるに足る裏付け証拠があるかを検討するに，同証人は，補助参加人担当者が原告から聴取した問題点をメモした丙第10号証の2には「（変更や取消で）おかしくなる項目」として「売上高」との記載があり，右記載は，運行キャンセルの不能により各種帳票上において売上高が過大請求となることを指しているのだから，原告が右不具合の指摘をしていたことは明らかであると供述する。しかし，丙第10号証の2の右記載及びこれに対する回答として補助参加人が作成した丙第10号証の3（「運送システムの問題点に関する調査結果報告」）を子細に検討しても，右記載が運行キャンセルの不能について指摘したものであると直ちに理解することはできず，右記載が同証人の右証言の適切な裏付け証拠になっているとは言い難い。そして，他に証人柏倉の右証言を裏付けるに足 りる証拠は存在しないから，原告が平成3年9月20日ころに右不具合を指摘したとの事実も認めることができない。
そして，他に原告が本件訴訟提起前に運行キャンセルの不能の不具合について補助参加人に指摘したことを認めるに足りる証拠はない。
(四) 右認定事実と丙第5号証及び弁論の全趣旨によれば，補助参加人は本件訴え提起後の本件システム稼働上の不具合の存否の検討作業の中で，運行キャンセル不能の不具合の発生の事実を知り，その原因が前記のようをプログラム上のバグであることを解明し，本件検証実験後の原因解明作業の中で，半日ないし１日程度の作業により補修を終えたことが認められ，この事実に，本件システムが原告の業務の用に供されていないものであることを合わせ考えると，補助参加人による右補修作業に不相応な遅滞があったものということはできない。
(五) したがって，右バグの存在をもってプログラムの欠陥と認めることはできないから，運行キャンセルの不能の不具合をプログラムの欠陥であるとする原告の主張は理由がない。
４ 荷主変更の不能の不具合について
(一) 本件システムにおいて，前記第二の二１(四)(1)のとおり，荷主変更を行なうと異常終了し処理が完了しないという不具合のあることは当事者間に争いがない。そして，丙第5号証及び弁論の全趣旨によれば，右不具合の原因は，プログラム製作過程において運行番号の採番処理を落としたための不整合によるものであることが点検の数時間後に判明し，補助参加人は本件検証実験後の原因解明作業の中で，遅滞なく右プログラムの不整合を補修し，荷主変更の不具合は解消されたことが認められる。
右プログラムの不備の内容に照らせば，本件システムの右不具合は，プログラム上のバグが原因であったものと認められ，右認定のとおり，補助参加人は右不具合を認識した後，遅滞なく補修を終えたのであるから，右バグの存在をもってプログラムに欠陥があったものということはできない。
(二) 甲第44号証，丙第10号証の1，2及び証人高良の証言によれば，原告が荷主変更時の異常終了を補助参加人に指摘した経過については，以下のとおり認められる。
平成2年7月2日，原告は，荷主変更を行うと異常終了メッセージが表示されることを確認し，同5日に右不具合を補助参加人に報告した。これに対し，補助参加人は調査を行ったが，現象が再現しなかったため，「再現不可。再度発生時に詳しい手順を御説明下さい」と原告に連絡し，報告待ちとした。平成3年8月ころ，原告は再び，右不具合を補助参加人に指摘し，これを受けて補助参加人は同年9月30日に再現テストを行ったが，現象は再現しなかった。そこで，補助参加人は現象が発生したときの具体的な操作手順・発生状況について調べるように原告に依頼し，当面様子を見ることにしたが，その後原告から同様の指摘はなかった。
以上の経過に照らせば，原告による不具合の指摘に対する補助参加人の対処が適正を欠くものであったということはできない。なお，原告は，平成2年7月の指摘の後，補助参加人は右不具合の現象を確認しながら原因を解明できなかったと主張するが，証人高良は右事実を否定しており，他に原告の右主張事実を認めるに足りる証拠はない。
(三) したがって，荷主変更の不能の不具合をプログラムの欠陥であるとする原告の主張は理由がない。
５ 車両変更の不具合について
(一) 原告は，本件システムには，被告らが前記第二の三１(五)(1)で主張する操作手順で車両変更を行なうと配車割付データの取消処理の際にループ現象が発生するという不具合があり，右ループ現象を避けるために原告が前記第二の二１(五)(1)で主張する操作手順で車両変更を行なうと，変更 結果が売上元帳等の帳票類に正しく反映されないという不具合があると主張する。
しかし甲第29号証によれば，本件検証実験において，被告らが前記第二の三１(五)(1)で主張する操作手順で車両変更を行なったところ，配車割付データの取消処理の際にループ現象は発生せず，変更結果が帳票類に正しく反映されたことが認められ，原告主張の右現象の発生を認めるに足りる証拠はない。したがって，本件システムに右不具合が存在するとの原告の主張は理由がない。
(二) 本件検証実検の結果，本件システムに，前記第二の二１(五)(3)のとおり， １運行複数受注の車両変更に関連して，売上元帳上荷主別の明細データに他の荷主データが入り込む，また，入るべき明細データが反映されず出てこない等の不具合が存在することが確認されたことは，当事者間に争いがない。そして，丙第5号証及び弁論の全趣旨によれば，右不具合の原因はプログラム製作上の運行番号の採番処理ルートの選択ミスと荷主のセット方法のミスという単純な不整合によるものであることが1日程度で判明したこと，補助参加人は本件検証実験後の原因解明作業の中で，遅滞なく右プログラムの不整合を補修し，車両変更時の右不具合は解消されたことが認められる。
右プログラムの不備の内容に照らせば，本件システムの右不具合は，プログラムのバグが原因であったものと認められ，右認定のとおり，補助参加人は右不具合の指摘を受けた後，遅滞なく補修を終えたのであるから，右バグの存在をもってプログラムに欠陥があったものということはできない。
(三) 原告は，平成2年12月5日及び同3年2月8日に，報告書（ 証拠＜省略＞）をもって，車両変更の不具合を補助参加人に対して報告したと主張する。しかし，証人高良の証言及び丙第22号証を合わせ考えると，平成2年12月５日の指摘は車両変更に関するものではなく新規入力に関するものであり，平成3年2月8日の指摘は「傭車情報エントリー」に関するもので本件検証実験で確認されたバグとは全く関係のないものであるとの見方をすることができ，右報告書の当該記載及び添付資料を子細に検討しても，右報告書が，本件訴訟で確認された車両変更の不具合を指摘したものであると直ちに理解することはできない。したがって，右報告書の記載が原告の右主張事実の 裏付け証拠となっているということはできず，他にこれを認めるに足りる証拠はない。
また，証人柏倉は平成3年9月20日ころ補助参加人に右不具合の指摘をしたと供述する。これに対し，証人高良は原告からそのような指摘を受けたことは一度もない旨供述している。そこで，証人柏倉の右証言を真実と認めるべき裏付け証拠が存在するかを検討するに，同証人は，原告が平成3年9月17日に補助参加人に提出した書面（丙第10号証の1「運送システムに関する問題点・案件」）に記載されている「営業日報で変更や取消などをすると，乗務員月報や車輌月報の数字が正しく出ない」との指摘は，車両変更の右不具合の指摘を含むものであると供述する。しかし，丙第10号証の1の右文言並びにこれに関連して補助参加人が作成した丙第10号証の2及び3の記載内容を子細に検討しても，右記載が車両変更の右不具合を指摘したものであるとは直ちに理解することはできず，右書面が同証人の適切な裏付け証拠になっているとは言い難い。また，右柏倉の供述に沿った原告の主張は，本件検証実験終了後に初めてなされたものである。
したがって，原告が本訴提起前に車両変更の不具合を補助参加人に指摘したとの事実は，これを認めるに足りる証拠がないものというべきである。
６ 乗務員変更の不具合について
(一) 本件システムに，前記第二の二１(六)(2)のとおり，乗務員変更を行なうと変更するごとに注油量が自動的に2倍になるという不具合が存在することは，当事者間に争いがない。そして，丙第5号証及び弁論の全趣旨によれば，右不具合の原因はプログラム上の１カ所の単純な命令ミスによるものであることが短時間で判明し，補助参加人は本件検証実験後の原因解明作業の中で速やかに右プログラムの補修を行い，右不具合は解消したことが認められる。
右プログラムの不備の内容に照らせば，本件システムの右不具合は，プログラム上のバグが原因であったものと認められ，右認定のとおり，補助参加人は右不具合を認識した後，遅滞なく補修を終えたのであるから，右バグの存在をもってプログラムに欠陥があったものということはできない。
(二) 証人柏倉は平成3年9月20日ころ補助参加人に右不具合を指摘したと供述する。これに対し証人高良は，原告から右不具合の報告を受けたことは一度もない旨供述している。そこで，証人柏倉の右証言を真実と認めるべき裏付け証拠が存在するかを検討するに，同証人は，原告が平成3年9月17日に補助参加人に提出した書面（丙第10号証の1「運送システムに関する問題点・案件」）に記載されている「営業日報で変更や取消などをすると，乗務員月報や車輌月報の数字が正しく出ない」との指摘は，乗務員変更の不具合の指摘を含むものであると供述する。しかし，丙第10号証の1の右文言並びにこれに関連して補助参加人が作成した丙第10号証の2及び3の記載内容を子細に検討しても，右記載が乗務員変更の不具合を指摘したものであるとは直ちに理解することはできず，右書面が右証言の適切な裏付け証拠になっているとは言い難い。
そして他に証人柏倉の右証言を裏付けるに足りる証拠は提出されていないから，原告が本訴提起前に乗務員変更の不具合を補助参加人に指摘したとの事実を認めるに足りる証拠はないものといわなければならない。
(三) 本件検証実験の結果，本件システムに，前記第二の二１(六)(3)のとおり， １運行複数受注の乗務員変更に関連して，配車表リストにおいて運行番号や受注番号が重複した明細データが出力され，また合計欄では重複金額が加算されている等の不具合が存在することが確認されたことは，当事者間に争いがない。そして，丙第5号証及び弁論の全趣旨によれば，右不具合の原因は，プログラム製作上，キー項目に運行番号が漏れていたというミスと削除命令がひとつ抜けていたというミスという単純な不整合によるものであることが判明し，補助参加人は本件検証実験後の原因解明作業の中で，1日程度でプログラムの右不整合を補修し，右不具合は解消されたことが認められる。
右プログラムの不備の内容に照らせば，本件システムの右不具合は，プログラム上のバグが原因であったものと認められ，右認定のとおり，補助参加人は右不具合を認識した後，遅滞なく補修を終えたのであるから，右バグの存在をもってプログラムに欠陥があったものということはできない。
(四) 原告は，平成2年7月27日，同月30日及び8月3日に，乗務員変更の不具合を，報告書（ 証拠＜省略＞）をもって補助参加人に報告したと主張する。しかし，証人高良の証言及び丙第22号証を合わせ考えると，これらのクレームはいずれも本件検証実験で確認されたバグとは関係のないものであるとの見方をすることができ，報告書の当該記載及び添付資料を子細に検討しても，右報告書が，本件訴訟で確認された乗務員変更の不具合を指摘したものであると直ちに理解することはできない。したがって，右報告書が原告の右主張事実の裏付け証拠となっているとはいえず，他にこれを認めるに足りる証拠はない。
また，証人柏倉は平成3年9月20日ころ補助参加人に対し右不具合を指摘したと供述する。これに対し証人高良は，原告から右不具合の報告を受けたことは一度もない旨供述している。そこで，証人柏倉の右証言を真実と認めるべき裏付け証拠が存在するかを検討するに，丙第10号証の1が同証人の右証言の適切な裏付け証拠たり得ないことは前記(一)(2)②のとおりであり，関係各証拠を精査しても，他に右証言を裏付けるに足りる証拠は提出されていない。また，右柏倉の供述に 沿った原告の主張は，本件検証実験終了後において初めてなされたものである。
したがって，原告が本訴提起前に乗務員変更時の不具合を補助参加人に指摘したとの事実を認めるに足りる証拠はないものというべきである。
７ その他の不具合について
(一)甲第29号証によれば，本件検証実験を行った結果，本件システムでは，「地区コードテーブル照会」で最大66回のロールアップを2度繰り返した後のメイン画面への戻りで異常終了するという現象が確認されたことが認められ，原告は右現象をもって，本件システムの欠陥であると主張する。
しかし，丙第5号証によれば，右現象は本件検証実験において，通常の業務においては行わない作業を行なったために発生した現象であることが認められ，原告の通常の業務において右現象が発生することはないと考えられるから，右現象の存在をもって本件システムの欠陥ということはできない。したがって，原告の右主張は理由がない。
(二) 甲第29号証によれば，本件検証実験を行った結果，本件システムでは，「地区コードテーブル照会」でロールアップが66画面までで，残りのデータがあっても見ることができないという現象が確認されたことが認められ，原告は右現象をもって本件 システムの欠陥であると主張する。
しかし，丙第4号証の1によれば，「地区コードテーブル照会」とは，照会者が求めている特定の地区コード・地区名等を，登録されている地区コード・地区名等から探し出すためのプログラムであること，その使用方法としては，照会者がこのあたりだろうと思う数字又は仮名文字をセットして，その数字又は仮名文字を起点にして登録データを昇順に画面を呼び出すものであること，1画面には15データを呼び出すことができ，したがって本件「地区コードテーブル照会」におけるロールアップの回数は，通常数回で足りることが認められる。
以上の事実によれば，本件「地区コードテーブル照会」におけるロールアップの回数が66画面までとなっていることで業務上支障が出ることは通常考えられず，また，登録されている全てのデータを見たいのであれば，「地区名マスター一覧表」のリストを利用すればよいのだから，右現象をもって，本件システムの欠陥であるということはできない。したがって，原告の右主張は理由がない。
(三) 甲第29号証によれば，本件検証実験を行った結果，本件システムでは，「地区名マスター保守」で削除フラグが立っていると新規登録ができないという現象が確認されたことが認められ，原告は右現象をもって本件システムの欠陥であると主張する。
そこで検討するに，丙第4号証の1及び2によれば，本件システムでは「地区名マスター保守」でのデータの削除処理は仮削除であり，実際の削除は月次更新時に行なわれる仕様になっていること，したがって月次更新で削除された後には同一コードで新規登録ができることとなっていること，原告は平成2年7月19日に右現象を異常内容として補助参加人に報告し，補助参加人から，右現象は本件システムのプログラムの仕様に基づくものでエラーではなく特に仕様変更はしない旨の回答を受けたこと，その後原告が同様の指摘をしたことはないことが認められる。
以上の事実によれば，原告主張の現象は，本件システムのプログラムの仕様に基づくものでプログラムの不整合によるものではなく，しかも，仕様変更をしないことについては原告との間で既に了解が得られていることが認められるのであるから，右現象をもって，本件システムのプログラムの欠陥であるということはできない。したがって，原告の右主張は理由がない。
(四) 甲第29号証によれば，本件検証実験を行った結果，本件システムでは，「傭車情報エントリー」の車両番号に対して，削除フラグが立っていると新規登録ができないという現象が確認されたことが認められ，原告は右現象をもって本件システムのプログラムの欠陥であると主張する。
そこで検討するに，丙第4号証の2によれば，本件システムでは，既に車両番号が登録済みである時はその車両番号の下１桁を変えて新規登録する仕様になっていること，車両番号は陸運局登録番号４桁プラス下１桁で構成しており，下１桁の変更により陸運局登録番号を変えることなく新規登録ができる設計になっていること，本件検証実験以前に原告がこの点に関する指摘を補助参加人に行ったことはないことが認められる。
以上の認定事実によれば，原告主張の右現象は本件システムのプログラムの仕様に基づくものでプログラムの不整合によるものではなく，しかも，右現象が存在することで原告の通常業務に支障が生じていたとは考えられないのであるから，右現象をもって本件システムのプログラムの欠陥であるということはできない。したがって，原告の右主張は理由がない。
(五) 甲第29号証によれば，本件検証実験を行った結果，本件システムでは，「固定明細エントリー」の発地名及び着地名のコードや「傭車情報エントリー」の空車地区コードについて，数字以外のアルファベットやカナ文字の入力が可能となっており，数字以外のものを入力したファイルを更新すると，数字に変換してしまうという現象が確認されたことが認められ，原告は右現象をもって本件システムのプログラムの欠陥であると主張する。
しかし，丙第4号証の2によれば，コードの入力については数字入力であることが操作マニュアルによって説明・指導されていることが認められるのであり，このような場合に，数字以外の入力に対するエラーチェック等の機能を設けていないことが，当然にプログラムの欠陥であるということはできない。また，関係各証拠を検討しても，原告と被告の間で本件システムのプログラムにエラーチェック等の機能を設ける旨の合意があったことを認めるに足りる証拠はない。よって，右現象をもって，本件システムのプログラムの欠陥であるということはできず，原告の右主張は理由がない。
(六) 甲第13号証によれば，補助参加人は平成4年3月13日に本件システムのプログラムの再設計・再製作を申し入れたことが認められ，原告は右事実をもって，補助参加人が本件システムのプログラムに補修不可能な構造的欠陥があることを自認していた旨主張する（平成6年1月20日付け原告準備書面9，10頁）。しかし，証人高良は，右申し入れをしたのは，原告の強硬姿勢からしてプログラムの補修を申し出られる状況になかったからである旨証言しているのであり，右証言の信用性を否定するに足りる証拠は提出されていないから，再設計・再製作の申し入れをもって，補助参加人がプログラムに補修不可能な構造的欠陥があることを自認した証拠であるということはできない。
８ まとめ
以上のとおり，本件システムのプログラムに欠陥があるとの原告の主張を認めるに足りる証拠はないから，右主張事実の存在を前提とする原告の本件委託契約の解除に基づく損害賠償請求ないし不法行為に基づく損害賠償請求は理由がない。
三 平成5年事件について
１ 本件請負等契約が錯誤により無効かどうか。
(一) 経理システムソフトウエアに関する出力帳仕様変更及び同システムソフトウエアの機能追加の請負契約について
原告は，右各請負契約は，契約を締結すれば本件システムの正常稼働が可能であるとの補助参加人の説明を信じて締結に応じたものであるから，右各契約は動機に錯誤があり無効であると主張する。
しかし，丙第16及び第17号証によれば，右出力帳仕様変更の内容は，総勘定元帳及び補助元帳のデザイン変更，合計残高試算表の管理項目の追加並びに複合仕訳の場合の相手科目の出力であること，右機能追加の内容は，株式会社ダイセー５２のシステム環境を整備するものであることが認められ，以上の契約内容に照らせば，右各契約が本件システムの正常稼働を目的とするものでないことは明らかであるから，補助参加人が右契約を締結するに際して，原告が主張するような説明をしたとは考えがたい。また，関係各証拠を検討しても，補助参加人がこのような説明をしたことを認めるに足りる証拠はない。
したがって，右各請負契約締結にあたって原告に動機の錯誤があったとの事実を認めることはできず，原告の右主張は理由がない。
(二) 磁気ディスク装置他及びPS/55の売買契約について
原告は，磁気ディスク装置他の売買契約は，補助参加人から，月次更新処理に長時間を要するとの不具合を解消するためには磁気ディスク装置が必要であるとの説明を受けて締結したものであり，動機に錯誤があるから右契約は無効であると主張する。そして証人柏倉も，甲第35号証（陳述書）においてこれと同旨の供述をしている。しかし証人高良は，磁気ディスクは，本件システムの本番稼働に伴いデータ量も稼働回数も著しく増加したことから，システムの容量等を増強させるために設置したものであり，月次更新処理の不具合とは関係がない旨供述しているのであって，関係各証拠を検討しても，証人柏倉の右供述を裏付け，証人高良の右供述の信用性を否定するに足りる証拠は提出されていない。よって，補助参加人が右売買契約の締結に際して原告が主張するような説明をしたとの事実を認めるに足りる証拠はなく，右売買契約締結に際して原告に動機の錯誤があったとの事実を認めることはできない。
また，PS/55の売買契約についても，原告に動機の錯誤があったとの事実を認めるに足りる証拠はない。
２ 本件請負等契約の支払義務につき本件システムの正常稼働を条件とする旨の合意があり，右条件が未成就であるかどうか。
原告は，補助参加人に対し，本件システムの不具合が解消され正常に使用できる状況になるまでは本件請負等契約の支払を留保する旨の通告をし，補助参加人もこれを了承した旨主張する。しかし，関係各証拠を検討しても，原告の右主張事実を認めるに足りる証拠は提出されておらず，本件請負等契約の代金支払義務について原告主張のような条件が付されたことを認めることはできない。したがって，支払義務の条件が成就していないとの原告の主張は理由がない。
３ 本件請負等契約の解除の効力
原告は，本件請負等契約は本件システムが正常に稼働することを前提とするところ，本件システムは不具合のため全く機能を発揮せず，本件委託契約は解除されたのだから，前提を失った本件請負等契約は当然解除されるべきであると主張する。しかし，前記二のとおり，本件システムに不具合が存在することは被告の債務不履行とはいえず，本件委託契約の解除は効力を有しないものであるから，本件委託契約が解除されたことを前提とする原告の右主張は採用することができない。したがって，この点に関する原告の主張は理由がない。
四 結 論
以上によれば，平成4年事件原告の請求は理由がないから棄却することとし，平成5年事件原告の請求は理由があるからこれを認容し，申立てにより主文第2項につき仮執行の宣言を付することとして，主文のとおり判決する。
裁 判 長 裁 判 官 園 尾 隆 司
裁 判 官 永 井 秀 明
裁 判 官 渡 邉 千 恵 子
Copyright (C) 1998-2001 Takato Natsui, All rights reserved.
Published on the Web : Apr/04/1998
Error Corrected : Jun/13/2001