一体どうすれば、システムの要件を正しく定義し、トラブルなくプロジェクトを進めていけるのでしょうか。残念ながら、「こういうことをちゃんとやっておけば大丈夫。」 という”銀の弾丸“は、まだ見当たっていません。沢山の人がモヤモヤっと考えるシステムや業務のあるべき姿を、妥当性、網羅性、整合性、正確性を保ったまま、誰もが正しく理解できる日本語で表すのは、事実上不可能と言っても良いのかもしれません。
しかしだからと言って、これをあきらめたら世界中のシステム開発が立ち行かなくなります。 ”銀の弾丸”とまではいかなくても、現状の開発を少しは”マシ”にする知恵や工夫といったものを様々なトラブルプロジェクトから探ることは可能ですし、続けていかなければならないでしょう。
というわけで、今回もIT訴訟の事例を反面教師にして、少しは”マシ”な要件定義を行うための知見を探っていきたいと思います。今回は、前回持ち出した判例をもとに、ベンダに業務知識を持たせることの重要性ついてお話したいと思います。
業務知識が足りないベンダが行なった開発
【要件定義の不足による裁判の例】
(東京地方裁判所 平成17年4月22日判決)
あるユーザが書籍在庫管理システムの刷新することを計画し、既存システムの機能に新機能を追加して要件定義を行ったが、既存システムの一部機能 (個別出版社対応機能)を明確に要件として定義していなかったため、システム完成後ベンダから追加費用を請求されたが、ユーザがこの支払いを拒み訴訟となった。
ベンダの ”個別出版社対応は追加要請分であり費用を支払うべき” と主張に対し、ユーザは”本件開発は既存システム機能の継承＋新機能追加であり、個別出版社対応も当然に行なわれるべきだ” と反論した。
補足をすると、このシステムは出版社が出した書籍の在庫を管理する目的で開発を行ったものです。幾つかの出版社の在庫を引き受けて倉庫に置いておき、注文があれば注文主に向けて配送をする業務を支援するシステムなのですが、このユーザが持つ既存システムには、個別の出版社 (ユーザから見てのお客様 ) に対応するプログラムがあったのです。(どのような機能を持つプログラムであったのかは、本論と無関係ですので割愛します。)
ところが、ユーザは、この”個別出版社対応機能”を新システムの要件として定義しなかったのです。機能が不要だったわけではありません。既存のシステムに含まれる機能は当然に開発してくれると考えたのです。書籍の在庫管理をする以上、個別の出版社に対応する機能が必要であることくらい当然にわかるだろうという考えだったようです。
しかし、ベンダは、要件として定義されていないこの機能を作ることはしませんでした。確かに既存システムに個別出版社対応機能があることはわかっていたと思いますが、要件として定義されていない以上、今回の開発では、それが不要だとの判断があったのでしょう。レストランで料理を頼んだとき “フォークやナイフが出てくるのは当然” と考えるユーザと ”マイ箸を持参したのかな？”
と考えるベンダの思い込みが、こうしたトラブルを生んだというわけです。
