2年超も仕様が確定しないのは、ベンダーの責任か？：「訴えてやる！」の前に読む IT訴訟 徹底解説（10）（1/2 ページ）

システム設計書を提出しても、プロトタイプを作成しても、どうしても仕様を確定させてくれないユーザー。この契約、解除しても大丈夫？

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

連載目次

要件定義は定番中の定番

　本連載ではこれまで、システム開発における契約、検収、プロジェクト管理などについて数々のIT紛争の事例を紹介し、そこから得られる知見を述べてきた。しかし実際のところ、IT紛争の争点として数が最も多いのは、上述したような問題ではない。そもそも、どのようなシステムを作るかをユーザーとベンダーが理解し共有する要件定義に関する紛争こそが、IT訴訟のいわば定番であり、おそらく数も最も多いと考えられる。

　システム化対象となる業務の流れや、その入出力を定める「業務要件定義」、システム自体の入出力や演算などを定める「機能要件定義」、そして処理速度や操作性、セキュリティなどを定める「非機能要件定義」、いずれもユーザーの頭の中で漠としているイメージの「網羅性」「正確性」「整合性」「十分性」などを考慮しながら、誰が見ても同じ理解ができる文書に落とし込む、という非常に困難な作業である。

　そのユーザーの要望が、人によって、あるいは時期によって変化してしまう恐れもあることから、そこに不備が発生して争いが起こることが多いのは、むしろ当然のことといってもよいくらいである。システム導入プロジェクトの最終盤になって、「頼んだはずの機能を具備していない」「操作性や速度に問題があって使用に耐えない」とのクレームがユーザーから上げられた、あるいはユーザーとして上げた経験を持つ読者も少なくないことと思う。

　そこで今回から数回にわたって、システムの要件定義に係る紛争の紹介と考察をしていく。初回はまず「要件定義に係る役割分担を、裁判所がどのように考えているか」を、判例を元に紹介する。

　要件定義に関する紛争は、結局のところユーザーとベンダーの役割分担の問題ともいえる。「この要件は、そもそも誰が調査し、誰が決定すべきだったのか」「抜けていた要件を見逃してしまったのはユーザーとベンダーのどちらに責があるのか」、お互いが本来果たすべき役割を全うしたのかが争いの本質となる。まずは判例を見てみよう。

要件定義の役割分担について判断した例

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

　ある人材派遣業者（以下 ユーザー）から業務システムの開発を受託したITベンダー（以下 ベンダー）がソフトウェアの仕様を記載したシステム設計書を提出したが、ユーザーはその内容が不十分であるとして記名押印を拒絶し、仕様が確定しなかった。その後ベンダーは仕様書の修正やプロトタイプの作成などを行い、ユーザーに仕様の確定を何度も願い出たが、ユーザーはこれに合意せず、約2年間にわたり仕様の確定ができない状態が続いた。

　結局ベンダーは、ユーザーが仕様確定を拒否し、また契約時に想定していなかった機能追加に対する費用の支払いを拒んだことを信義則に違反するものであるとして、契約を解除し、契約金額などを返却した。

　ところがユーザーは、これはベンダーの債務不履行であると反論し、システムの完成を前提として支出した費用などの損害賠償（約1億2千万円）を請求する訴訟を提起した。

　数年にわたり仕様（要件）の確定を拒否し続け、機能の追加を要求しするが費用は払わないというのだから、随分と身勝手なユーザーに見える。逆にベンダーはユーザーの要望に応えるために何度も仕様を作り直しており、要件確定をしやすくするためにプロトタイプの作成まで行っている。さらにベンダーはユーザーからの機能追加要求に対して費用の請求していることから、第3回で説明した「ベンダーのプロジェクト管理責任」を、ある程度果たしていたと考えられる。

　裁判所の判断はどうだったのだろうか？ 次ページで見ていただこう。