もしもシステムの欠陥により多額の損害賠償を求められたら：「訴えてやる！」の前に読む IT訴訟徹底解説（8）（2/2 ページ）

» 2014年11月04日 18時00分公開

　裁判所は判決の中で、以下のように述べている。

【裁判所の判断】（東京地裁平成22年1月22日判決より抜粋して要約～続き）

　情報処理システムの開発に当たっては、作成したプログラムに不具合が生じることは不可避であり、プログラムに関する不具合は、本番稼働前後の検収などの過程における補修が当然に予定されているものというべきである。

　このような情報処理システム開発の特殊性に照らすと、システム開発の途中で発生したシステムの不具合は直ちにシステムの瑕疵には当たるものではなく、システムの納品がされ本番稼働した後においても、注文者から不具合が発生したとの指摘を受けた後、請負人が遅滞なく補修を終えるか又は注文者と協議した上で相当な代替措置を講じたと認められるときは、システムの瑕疵には当たらないものと解する。

　ご覧の通り、裁判所はベンダーに損害賠償の義務があるかを、「遅滞なく補修を終えたか」「代替措置を講じたか」で判断している。欠陥は不可避なのだから、それによる被害を最小限にとどめるために下請けベンダーがしかるべき活動をしたか、が問題だというわけだ。

　裁判では、この原則に従ってシステムの問題点を吟味した。その結果、情報漏えいやデータの消失については、補修や代替措置を行うこと自体できないことから、下請けベンダーの責は免れないとした。

　しかし正常系を含むシステム自体の欠陥については、その多くが瑕疵であるとは認定されず、損害賠償の対象にはならなかった。その結果、下請けベンダーの損害賠償額は大幅に減じられ、請求された賠償金23億円に対して、認められたのは6億円強であった（情報漏えいやデータ消失も含めて、実際に発生した損害額からみれば、かなり下請けベンダーに有利な判断であったと考えるべきであろう）。

　下請けベンダーのメンバーは、ユーザーである大学から欠陥の指摘を受けたとき、遅滞なく補修作業を行っており、大学と話し合いで代替提案を行っている。裁判所はこの点を見て、「下請けベンダーが専門家として一定の責任を果たしている」と判断したのだ。

欠陥を指摘されたとき、ベンダーがなすべきこと

　この判決は、「欠陥が出ても、対応さえすればベンダーは損害賠償を問われない」と言っているわけではない。同じような事例でも、欠陥自体は軽微であるにもかかわらず、（あるいは軽微であるがために）補修や代替提案が大幅に遅れ、ユーザーから訴訟を提起され、ほぼ全ての損害を賠償することになったベンダーも少なくない（私の担当した事件でも、そうしたものがある）。

　その点も踏まえて、システムに欠陥が発覚した際にベンダーがなすべきことを整理してみよう。

初期調査と軽微な欠陥の洗い出し

　当然のことであるが、まずは現場に出向いての調査を迅速に行うことだ。そして、すぐに補修可能な欠陥については、その場で対応を完了させてしまう（もちろん、これにはユーザー側の承認も必要である）。

　大切なのは、いかに軽微な欠陥であっても、すぐに対応することだ。ベンダーによく見られる傾向として、簡単に補修できるものを後回しにするというものがあるが、技術的な難易度とユーザーの困窮度合は全く無関係である。

対応計画の策定

　初期調査の結果、さらなる調査が必要なもの、方法は分かるが対応に時間がかかると分かったものについては、簡単な対応計画を策定してユーザーと合意する。

　「調査・対応の仮スケジュール」「対応責任者」「ユーザーへの依頼事項」「報告・連絡方法」などについて、簡単でも書面にしてユーザーに提出しておくことだ。こうした活動こそが、裁判所の言う「ベンダーとしての責任の第一歩」ということになる。

代替提案の準備

　欠陥への対応として最も重要なのは、欠陥が収束しない場合に備えての代替提案を行うことだ。持ち帰ったはいいが欠陥の原因が分からない、ベンダーは精いっぱいやっているがプログラムの修復に時間がかかり、時間と損害の膨張にユーザーがいら立つ、といったことがよくある。

　少し乱暴な言い方だが、継続して調査・対応が必要なものについては、最初から対応がうまくいかないと仮定して、旧システムの運用や人手による作業などの代替提案を検討した方が合理的だ。

　技術者の中には、欠陥の補修による解決に固執し過ぎる人が少なくない。確かにそれも継続して行うべきだが、最優先事項はユーザーの業務の継続である。裁判所の判断も、そうした考えに基づいて行われているし、顧客満足度の点でも同じことがいえるはずである。大切なのは業務の継続であり、システムはその手段にすぎない。

　今回はシステムに欠陥が発見されたときのベンダーの対応について述べた。しかし文中でも述べたように、システムの欠陥について裁判所が示す切り口はこれだけではない。

　次回は、欠陥の重大さや内容について裁判所が下した判断について考えてみたい。

「「訴えてやる！」の前に読む IT訴訟徹底解説」バックナンバー

細川義洋

東京地方裁判所民事調停委員（IT事件担当）兼 IT専門委員　東京高等裁判所 IT専門委員

NECソフトで金融業向け情報システムおよびネットワークシステムの開発・運用に従事した後、日本アイ・ビー・エムでシステム開発・運用の品質向上を中心に、多くのITベンダーおよびITユーザー企業に対するプロセス改善コンサルティング業務を行う。

2007年、世界的にも季少な存在であり、日本国内にも数十名しかいない、IT事件担当の民事調停委員に推薦され着任。現在に至るまで数多くのIT紛争事件の解決に寄与する。

ITmedia オルタナティブブログ「IT紛争のあれこれ」

美人弁護士有栖川塔子のIT事件簿

書籍紹介

「IT専門調停委員」が教えるモメないプロジェクト管理77の鉄則

細川義洋著　日本実業出版社　2160円（税込み）

提案見積り、要件定義、契約、プロジェクト体制、プロジェクト計画と管理、各種開発方式から保守に至るまで、PMが悩み、かつトラブルになりやすい77のトピックを厳選し、現実的なアドバイスを贈る。

なぜ、システム開発は必ずモメるのか？

細川義洋著　日本実業出版社　2160円（税込み）

約7割が失敗するといわれるコンピューターシステムの開発プロジェクト。その最悪の結末であるIT訴訟の事例を参考に、ベンダーvsユーザーのトラブル解決策を、IT案件専門の美人弁護士「塔子」が伝授する。

「ジェイコム株誤発注事件」に見るシステムの瑕疵判断とその対応（前編）
東京高等裁判所 IT専門委員として数々のIT訴訟に携わってきた細川義洋氏が、実際のIT訴訟事例を例にとり、トラブルの予防策と対処法を解説する
「ジェイコム株誤発注事件」に見るシステムの瑕疵判断とその対応（後編）
ジェイコム株誤発注事件では、原告請求416億円を大幅に下回る107億円を損害賠償額として被告に請求する判決が下された。東京高等裁判所はどのような判断基準で判決に当たったのだろうか
ベンダーよ、シェルパの屍を越えていけ～　細川義洋×山本一郎「なぜ、システム開発は必ずモメるのか？」
リスペクトなきプロジェクトには死が待っている――山本一郎さん（やまもといちろう a.k.a.切込隊長）と、東京地方裁判所民事調停委員細川義洋さんによるDevelopers Summit 2014の最終セッションは、雪の寒さとは違う意味で会場を震え上がらせた。