続いて、こちらの判例を見ていただきたい。
あるシステム開発ベンダーが図書教材販売会社の入金照合処理のシステムを開発して納入したが、図書教材販売会社は、システムに以下の不具合が存在することなどを理由に費用を支払わず、ベンダーが支払い請求の訴訟を提起した。
不具合
こうしたシステムの開発に携わったことのある読者であれば想像できるだろうが、これらはいずれも数日で修正可能な軽微な不具合である。
裁判所が下した判断は以下の通りである。
不具合を解消するのには、約2週間程度を要することが認められ、比較的容易に修復可能な不具合といえることから、前記不具合をもって本件システムについての契約を解除することはできないものといえる。
これらの不具合は、軽微ではあるが正常系業務に係るものであり、放置すれば、それこそ契約の目的を達成できなくなる恐れもある。それでも裁判所は、比較的容易に修正できる軽微な不具合は、損害賠償の対象とはしないとしている。
ただし前回お話ししたように、このような軽微な不具合であっても、できるだけ早期に修正するか代替策の提案を行う姿勢がベンダーに求められる。これはベンダーに課せられた専門家としての義務である。
今度は欠陥の数についてである。こちらの判例を見ていただきたい。
ある出版社がベンダーに新基幹システムの開発を委託したが、納入されたシステムには数多くの不具合があったため、出版社は開発個別契約を解除し、債務不履行または瑕疵担保責任に基づく損害賠償請求として、ベンダーに合計約14億円の支払いを求めた。
この裁判ではシステムの完成が認められた。そのためベンダーは約束した仕事を一応行ったということになり、「債務不履行」ではなく「瑕疵担保責任」が争われた。
裁判所の判断は、以下のようなものであった。
一般にコンピューターソフトのプログラムには不具合・障害があり得るもので、完成、納入後に不具合・障害が一定程度発生した場合でも、その指摘を受けた後、遅滞なく補修ができるならば、瑕疵とはいえない。
しかし、その不具合・障害が軽微とは言い難いものである上に、その数が多く、しかも順次発現してシステムの稼働に支障が生ずるような場合には、システムに欠陥(瑕疵)があるといわなければならない。
この判決では、欠陥の「数」がポイントになっている。もちろん「欠陥が幾つ以上あったら瑕疵と考える」という基準があるわけではない。欠陥の内容と数からして、システムの不具合が容易に解消され、契約の目的を果たす状態になるかが判断の材料となる。現実的な判断と言えよう。
2回にわたって、システムの不具合による損害賠償について考察した。前回取り上げた「早期の修補」と「代替提案」、今回の「契約の目的との関係」と「不具合の程度と数」。結局のところ裁判所は、「システムの内容」よりも、「ユーザーの業務がつつがなく行える状態を維持し、改善できているか」を大きな判断材料としていると思われる。不具合が発生したとき、ベンダーが果たすべき専門家責任は、システムにより実現するユーザーの業務に照らして検討されるべきである。
東京地方裁判所 民事調停委員(IT事件担当) 兼 IT専門委員 東京高等裁判所 IT専門委員
NECソフトで金融業向け情報システムおよびネットワークシステムの開発・運用に従事した後、日本アイ・ビー・エムでシステム開発・運用の品質向上を中心に、多くのITベンダーおよびITユーザー企業に対するプロセス改善コンサルティング業務を行う。
2007年、世界的にも季少な存在であり、日本国内にも数十名しかいない、IT事件担当の民事調停委員に推薦され着任。現在に至るまで数多くのIT紛争事件の解決に寄与する。
「IT専門調停委員」が教える モメないプロジェクト管理77の鉄則
細川義洋著 日本実業出版社 2160円(税込み)
提案見積り、要件定義、契約、プロジェクト体制、プロジェクト計画と管理、各種開発方式から保守に至るまで、PMが悩み、かつトラブルになりやすい77のトピックを厳選し、現実的なアドバイスを贈る。
細川義洋著 日本実業出版社 2160円(税込み)
約7割が失敗するといわれるコンピューターシステムの開発プロジェクト。その最悪の結末であるIT訴訟の事例を参考に、ベンダーvsユーザーのトラブル解決策を、IT案件専門の美人弁護士「塔子」が伝授する。
Copyright © ITmedia, Inc. All Rights Reserved.