「聖火台のあるオリンピック競技場」の作り方:「訴えてやる!」の前に読む IT訴訟 徹底解説(25)(2/3 ページ)
東京高等裁判所 IT専門委員の細川義洋氏が、IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回は「聖火台のないオリンピック競技場」を題材に、システム開発における抜け漏れのない要件定義手法を解説する。
主要な要件欠落のためにシステム導入に失敗した裁判
まず、判例を見ていただこう。主要な要件が欠落していたために、出来上がったシステムが使い物にならなかったトラブルをめぐる裁判だ。
東京地裁 平成16年12月22日判決より抜粋して要約
ある流通業者(以下 ユーザー)が、ベンダーに販売管理システムの開発を委託したが、開発が遅延し、さらに業務に重大な影響を及ぼす不具合があったため、システムを本稼働をさせられなかった(正式には納入もされなかった)
このためユーザーは、「システム開発請負契約の目的が達成できない」として契約を解除し、損害賠償として約4100万円を請求したが、ベンダーは「不具合はユーザーの要件定義が抜けていたことによるものだ」とこれに応じず、訴訟となった。
「業務に重大な影響を及ぼす不具合」には、下記のようなものがあった。
1 入荷引当処理に関する性能問題
このシステムは、販売する商品を仕入れて入荷したときに、未処理の注文票に割り当てる処理(いわゆる「引き当て」)を行う。この処理速度が遅く、300件の入荷情報の処理に44分を要した。また、その間、他端末で受注登録ができなかった。
2 排他制御の問題
商品マスターの変更画面を開くと、商品マスターを利用するプログラムが全て止まってしまった。
ユーザーの業務は大量の入荷と注文があるので、300件程度の引き当ては数分以内に終わらないと仕事にならない(「1」)。商品マスターは頻繁に参照するため、変更画面を開くたびに使えないようでは、やはり仕事にならない(「2」)。
いずれも、オリンピック競技場でいえば「聖火台」に当たるような、基本的な要件が満たされていなかったということだ。システムの受け入れをユーザーが拒んだのも致し方ない。
これに対してベンダーは、「入荷処理の性能」や「排他制御」について「ユーザーから要件の提示がなかった」と抗弁した。システムの要件提示はユーザーの役割であり、これが示されていない以上、ベンダーが債務を履行していないことにはならない、つまり、ベンダーに損害賠償をする義務はないという論だ。
今回は、紛争の責任がどちらにあるのかを詳しく論じるつもりはない。この訴訟で裁判所は、「たとえ明示的に示されていなくても、業務上、当然に必要とされる機能、性能については、要件として解釈されるべきであり、それを具備していない、今回のシステムには瑕疵がある」と述べて、ベンダーに厳しい判決を出した(こうした裁判所の考え方は、「定形外業務も自主的に調べるのがベンダーの努めです」を参考にしてほしい)。
問題は、こうした「要件の抜け漏れ」をどのように防ぐかだ。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- 定形外業務も自主的に調べるのがベンダーの努めです
契約内容に盛り込まれていない「オペレーターがデータベースを直接操作する機能」が実装されていないと支払いを拒否されたベンダーが起こした裁判を解説する - 美人弁護士 有栖川塔子のIT事件簿:そもそも要件定義って何なのよ
ITシステムの要件定義では、対象業務のフローや入出力を決める「業務要件」とシステムが持つべき機能を定める「機能要件」、システムの速度や容量、使い勝手やセキュリティなどを定義する「非機能要件」について、ユーザーとベンダで徹底的に議論することが大切です - 業務要件のモレを無くすためにマークすべき人とは?
ユーザーから要件をヒアリングするときには、単に業務プロセスを確認するだけでなく、オペレーターの振る舞いや属性に着目すると、思わぬ発見があるものです