不具合の数が幾つ以上だと、裁判で瑕疵と判断されるのか：「訴えてやる！」の前に読む IT訴訟 徹底解説（9）（2/2 ページ）

「欠陥の数が多過ぎる」とユーザーから14億円の損害賠償を請求されたベンダー。裁判所の判断は？ その根拠は？

[ITプロセスコンサルタント 細川義洋，＠IT]

不具合の程度に照らして瑕疵か否か判断した事例

　続いて、こちらの判例を見ていただきたい。

【事件の概要】（東京地裁 平成9年9月24日判決より抜粋して要約）

　あるシステム開発ベンダーが図書教材販売会社の入金照合処理のシステムを開発して納入したが、図書教材販売会社は、システムに以下の不具合が存在することなどを理由に費用を支払わず、ベンダーが支払い請求の訴訟を提起した。

不具合

• 伝票条件入力時に正当な日付を入力しても日付エラーとなる
• 入金伝票入力時に入金総額の誤入力をチェックする機能が存在しない
• 入力情報の訂正作業を行って数字を書き換えても再計算されない
• 入金伝票プルーフリストについて、意味不明の日付が表示される
• 得意先管理表について、得意先別の売上が合算されない
• 業務中断の操作を行っても、処理が続行される

　こうしたシステムの開発に携わったことのある読者であれば想像できるだろうが、これらはいずれも数日で修正可能な軽微な不具合である。

　裁判所が下した判断は以下の通りである。

【裁判所の判断】（東京地裁 平成9年9月24日判決より抜粋して要約）

　不具合を解消するのには、約2週間程度を要することが認められ、比較的容易に修復可能な不具合といえることから、前記不具合をもって本件システムについての契約を解除することはできないものといえる。

　これらの不具合は、軽微ではあるが正常系業務に係るものであり、放置すれば、それこそ契約の目的を達成できなくなる恐れもある。それでも裁判所は、比較的容易に修正できる軽微な不具合は、損害賠償の対象とはしないとしている。

　ただし前回お話ししたように、このような軽微な不具合であっても、できるだけ早期に修正するか代替策の提案を行う姿勢がベンダーに求められる。これはベンダーに課せられた専門家としての義務である。

欠陥の数に照らして瑕疵か否か判断した事例

　今度は欠陥の数についてである。こちらの判例を見ていただきたい。

【事件の概要】（東京高裁 平成26年1月15日判決より抜粋して要約）

　ある出版社がベンダーに新基幹システムの開発を委託したが、納入されたシステムには数多くの不具合があったため、出版社は開発個別契約を解除し、債務不履行または瑕疵担保責任に基づく損害賠償請求として、ベンダーに合計約14億円の支払いを求めた。

　この裁判ではシステムの完成が認められた。そのためベンダーは約束した仕事を一応行ったということになり、「債務不履行」ではなく「瑕疵担保責任」が争われた。

　裁判所の判断は、以下のようなものであった。

【裁判所の判断】（東京高裁 平成26年1月15日判決より抜粋して要約）

　一般にコンピューターソフトのプログラムには不具合・障害があり得るもので、完成、納入後に不具合・障害が一定程度発生した場合でも、その指摘を受けた後、遅滞なく補修ができるならば、瑕疵とはいえない。

　しかし、その不具合・障害が軽微とは言い難いものである上に、その数が多く、しかも順次発現してシステムの稼働に支障が生ずるような場合には、システムに欠陥（瑕疵）があるといわなければならない。

　この判決では、欠陥の「数」がポイントになっている。もちろん「欠陥が幾つ以上あったら瑕疵と考える」という基準があるわけではない。欠陥の内容と数からして、システムの不具合が容易に解消され、契約の目的を果たす状態になるかが判断の材料となる。現実的な判断と言えよう。

---

　2回にわたって、システムの不具合による損害賠償について考察した。前回取り上げた「早期の修補」と「代替提案」、今回の「契約の目的との関係」と「不具合の程度と数」。結局のところ裁判所は、「システムの内容」よりも、「ユーザーの業務がつつがなく行える状態を維持し、改善できているか」を大きな判断材料としていると思われる。不具合が発生したとき、ベンダーが果たすべき専門家責任は、システムにより実現するユーザーの業務に照らして検討されるべきである。

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

• ReactJSで作るはずだったのに、Laravelで作ったので訴えます
• IT訴訟解説筆者が考える「セクシー田中さんドラマ化」問題と破綻プロジェクトの共通点――原因と再発防止案は？
• 開発が遅延した上に、メンバーの体調不良までわが社のせいにするのか！
• 仕様書通りにシステムを作りました。使えなくても知りません
• 何でスキル不足のエンジニアをアサインしたからって訴えられるんですか
• ベンダー社員過労死の遠因はユーザー企業にもあるのか
• この契約は、請負でも準委任でもありません
• ファイアウォールの設定を、すり抜け放題にしました☆
• 準委任契約だけど、責任は取ってください
• たった1日連絡しなかっただけで契約解除ってどういうことですか!?
• 契約書にも民法にも書かれていませんが、「義務」なので履行してください
• ソフトは転売していません。マニュアルを販売しただけです
• 「パワハラされてリストラされたので、転職サイトに書き込んでやりました」の追い解説
• お前とは絶交だ！　契約も解除してやる！
• 顧客も社員も奪われて、わしゃもう死んでしまいたい
• 入館拒否や帰宅命令までしないと安全配慮義務違反になるんですね
• 江里口美咲＆細川義洋対談「ここがダメだよ、IT業界！」
• 業務をパッケージに合わせると言ったけど、めんどくさいからやっぱりやめた
• 取った資格は俺のもの、もらったお金も俺のもの
• パワハラされてリストラされたので、転職サイトに書き込んでやりました
• 同僚を引き連れて起業するなんて、この恩知らず！
• 基本設計書は納品前ですが、システム作っちゃいました
• 技術的に不可能でも、セキュリティ対策は万全にしろ！
• 業績の悪い社員を解雇して何が悪いんですか？
• 仕様は確認しないし、運用テストもしません　全部出来上がってから確認します
• 製造工程に入ってるけど、やっぱこの機能も追加してくださーい
• お任せしたのですから、契約の範囲外でも対応してください
• 従業員が作ったセキュリティホールの責任を会社が取るなんてナンセンスです
• 私が決めた要件通りにシステムを作ってもらいましたが、使えないので訴えます
• 悪いのはベンダー！　「わび状」という証拠もあります！
• 不合格通知をもらわなかったから、検収合格ですよね
• こんな裁量労働制は嫌だ！
• 何で仕様も教えてくれないんですか！
• こんなパッケージソフトいらない！　だって使えないんだもん！
• 私のふんどしで相撲を取らないでください
• やった分はお金ください。納品してないけど
• 代金を支払わないからシステムを引き上げるなんて、どういう了見だ！
• 「お任せください」ってカンバンに書いてあるじゃないか！
• あるエンジニアの死
• 「退職するなら、2000万円払ってね」は、本当に会社だけが悪かったのか
• 似たようなデータベース作ったからって、泥棒よばわりするのやめてもらえません？
• あなたの能力も態度も信用できません
• 退職するなら、2000万円払ってね
• 派遣は工程表を作っちゃダメなんですか!?
• 最後の不具合が除去されるまで、働き続けてもらいます
• リバースエンジニアリングしたけど、もうけてないから問題ないでしょう？
• 運用保守契約は永遠です
• うまくいってもいかなくても、お金はください
• 親会社の意向なので開発中止します。もちろんお金も払いません
• 丸投げしたんだから、頑張ってくださいよ（作業量は増えたけどね）

細川義洋

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

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

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

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

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

書籍紹介

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

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

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

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

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

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