今回から何度かに分けて、コンピュータシステムの要件定義についてお話したいと思います。要件定義というのは、導入するシステムにどんな機能を持たせるか、どんな速度でどんな使い勝手にするかといったことを定義していく作業ですが、実はこれが、一般のユーザにとっては相当に難しい作業で、システムに持たせたい機能や性能をベンダにうまく伝えられず、出来上がったシステムを見て 「こんな筈じゃなかった」 とベンダ相手に大喧嘩をするプロジェクトが後を絶ちません。ユーザが「ここは、顧客の購買履歴のサマリを出してくれって頼んだぞ！」 と言えば、ベンダが 「えっ？購買履歴の一覧と聞きましたけど。」と答えたり、「この処理に一時間もかかっていたら仕事にならない。」と言えば、「時間のことなんか聞いてないですよ。」と反論したり。皆さんの周りでは、こんな会話が聞かれることがありませんか？あるいは、皆さん自身が、こうした台詞を吐いて嘆いたことはないでしょうか？
システム開発失敗の大半は要件定義の問題
実際のところ、コンピュータの機能や性能をもれなく矛盾なく整理して日本語で伝えるというのは、どこの会社でも苦労しているところで、以下のような調査結果も出ています。
「アンケート調査報告 2005/6/29-7/1 SODECにおけるアンケートによる」より
少し古いデータではありますが、システム開発の失敗のうち実に９割が要件定義に関するものだとする調査結果です。2008年に実施された日経BP社による調査では、システム開発の７割強が失敗に終わると言われていますので、両者を掛け合わせて考えると、システム開発は、６割以上が要件定義を原因として失敗しているということになります。つまり、システム開発を２度経験して、２度とも要件定義がすんなり終わったとすれば、それは東京六大学野球で東大が早稲田や慶応に２連勝するくらい、希有な例だということになります。(つまり大ラッキーというわけですね。)
もちろん、この２つの調査は調査の対象や時期も違いますし、調査者も異なりますので、こんな単純な掛け算で何かを結論づけることはできませんが、「要件定義がうまくいかなくて、プロジェクトが失敗した」という話は、裁判所でも本当によく聞く話で、以下のような裁判を初めとして、それこそ星の数ほどの紛争やトラブルが起こっています。
【要件定義の不備が原因となった裁判の例】
(東京地方裁判所 平成17年4月22日判決)
あるユーザが書籍在庫管理システムの刷新することを計画し、既存システムの機能に新機能を追加して要件定義を行ったが、既存システムの一部機能 (個別出版社対応機能)を明確に要件として定義していなかったため、ベンダは、この部分を作らなかった。
納入直前にこのことに気付いたユーザは、急遽ベンダに依頼してこの機能を追加し、システムは完成したが、完成後ベンダから追加費用を請求されたユーザは、この追加機能は、要件として定義しなくても既存システムの機能である以上当然に実装されるべきもので要件追加ではないとして、支払いを拒んだ。
これに対してベンダは、 “個別出版社対応は追加要請分であり費用を支払うべき” と主張して裁判となった。
この裁判の判決が、どのようなものであったか、そこから得られる知見がどのようなものであったかについては次回以降にご説明したいと思いますが、裁判にまで発展しなくとも、要件定義を巡るトラブルが本当に多いことは、私自身の経験に照らしても、(もしかしたら読者の皆さんの実感としても) うなずけるところかもしれません。
この記事は参考になりましたか？
- この記事の著者
-
細川義洋（ホソカワヨシヒロ）
ITプロセスコンサルタント東京地方裁判所 民事調停委員 IT専門委員1964年神奈川県横浜市生まれ。立教大学経済学部経済学科卒。大学を卒業後、日本電気ソフトウェア㈱ (現 NECソリューションイノベータ㈱)にて金融業向け情報システム及びネットワークシステムの開発・運用に従事した後、2005年より20...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか？
この記事をシェア
