第四回 システムの要件定義とは

EnterpriseZine / 2014年9月25日 0時0分

情報処理推進機構 ソフトウェアエンジニアリングセンター「アンケート調査報告 2005/6/29-7/1 SODECにおけるアンケートによる」より

 今回から何度かに分けて、コンピュータシステムの要件定義についてお話したいと思います。要件定義というのは、導入するシステムにどんな機能を持たせるか、どんな速度でどんな使い勝手にするかといったことを定義していく作業ですが、実はこれが、一般のユーザにとっては相当に難しい作業で、システムに持たせたい機能や性能をベンダにうまく伝えられず、出来上がったシステムを見て 「こんな筈じゃなかった」 とベンダ相手に大喧嘩をするプロジェクトが後を絶ちません。ユーザが「ここは、顧客の購買履歴のサマリを出してくれって頼んだぞ!」 と言えば、ベンダが 「えっ?購買履歴の一覧と聞きましたけど。」と答えたり、「この処理に一時間もかかっていたら仕事にならない。」と言えば、「時間のことなんか聞いてないですよ。」と反論したり。皆さんの周りでは、こんな会話が聞かれることがありませんか?あるいは、皆さん自身が、こうした台詞を吐いて嘆いたことはないでしょうか?

■システム開発失敗の大半は要件定義の問題

 実際のところ、コンピュータの機能や性能をもれなく矛盾なく整理して日本語で伝えるというのは、どこの会社でも苦労しているところで、以下のような調査結果も出ています。

 少し古いデータではありますが、システム開発の失敗のうち実に9割が要件定義に関するものだとする調査結果です。2008年に実施された日経BP社による調査では、システム開発の7割強が失敗に終わると言われていますので、両者を掛け合わせて考えると、システム開発は、6割以上が要件定義を原因として失敗しているということになります。つまり、システム開発を2度経験して、2度とも要件定義がすんなり終わったとすれば、それは東京六大学野球で東大が早稲田や慶応に2連勝するくらい、希有な例だということになります。(つまり大ラッキーというわけですね。)

 もちろん、この2つの調査は調査の対象や時期も違いますし、調査者も異なりますので、こんな単純な掛け算で何かを結論づけることはできませんが、「要件定義がうまくいかなくて、プロジェクトが失敗した」という話は、裁判所でも本当によく聞く話で、以下のような裁判を初めとして、それこそ星の数ほどの紛争やトラブルが起こっています。

 【要件定義の不備が原因となった裁判の例】

 (東京地方裁判所 平成17年4月22日判決)

 

 あるユーザが書籍在庫管理システムの刷新することを計画し、既存システムの機能に新機能を追加して要件定義を行ったが、既存システムの一部機能 (個別出版社対応機能)を明確に要件として定義していなかったため、ベンダは、この部分を作らなかった。

この記事に関連するニュース

トピックスRSS

ランキング