こんなことも知らないんですか？ ベンダーって勉強不足ですね：「訴えてやる！」の前に読む IT訴訟 徹底解説（42）（1/3 ページ）

集団訴訟を管理するシステムを開発したベンダーが、要件になかった項目を“自主的に”追加しなかったからと弁護士に訴えられた。弁護士の常識vs.ベンダーの常識、勝つのはどっちだ！？

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

連載目次

　IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。前回は、その場しのぎで行った謝罪をたてに、損害賠償請求されたベンダーの話を取り上げた。

　今回は、ベンダーはどこまで業務知識を持つべきかを考える。

正しい要件定義のためには、ベンダーにも業務知識が必要

　要件定義工程は、システム開発の中で最もトラブルを生みやすい。いわば鬼門である。ユーザーの意図や目的、あるいは課題を十分に理解できないまま、ベンダーが開発を実施し、完成品に「あの機能がない」「この画面は違う」とユーザーからクレームが付く。揚げ句の果てに開発費用を減額されたり、全く支払ってもらえなかったりといったことは、たくさん存在する。

　実際、ITの知識豊富ではない人がユーザーの担当者になった場合、システムの要件を漏れなく、かつ正しく伝えることは困難だ。以前、この連載で紹介した旅行会社の航空チケット発券システムの裁判など、その最たるものだろう。

　「チケット発券業務には、遠隔地からデータベースを操作できる機能が必要なことはベンダーも当然知っているだろう」と思い込んだユーザーの担当者が、これを要件として明示せず、結果システムは機能不足で稼働できず、裁判で争うことになった、という話だ。

　このように「ユーザーにとっては常識だがベンダーにとっては非常識」という要件は珍しくない。

　この裁判では、「要件不備の責任の一端はベンダーにもある」との判決が出た。「ベンダーは、ユーザーの業務をよく学び、実際のオペレーションを理解した上で、ユーザーが作成する要件定義書の過不足をチェックしなければならない」という判断だ。なかなかに厳しい判決である。

　しかし、発券システムの遠隔操作は日常的に行われる作業なので、旅行会社のシステムを開発するのなら、頭に入れておくべきことではあった。仮に、それまでに旅行業システムの開発経験がなかったとしても、現システムの業務の流れを観察して理解していたら、遠隔操作の必要性を要件定義前に理解できたはずだ。

「いい加減にしてくれよ。こんなの常識だろう？」「ええ、あなたにとってはね。あなたの常識は、私には非常識なのよ」