トップ> コラム> 正しい " 要件定義 " のやり方 （その１）
正しい " 要件定義 " のやり方 （その１）
2008年06月09日
突然ですが、『要件定義』という言葉に皆さんはどんなイメージがありますか？
今回、『要件定義の仕方』の第１話（何話あるかはナイショ）は、私が思っている要件定義のイメージについてお話したいと思います。
「要件定義とは？」
うーん、名前から想像すれば "要件を定義する" ことなのでしょう。
「で要件ってなに？」
うーん、"そのシステム開発によって実現されるべきこと" ですかね？
お客さんから依頼された要件を定義する(書き残す)作業？
もしそうなら、そんなに難しい作業ではなさそうですが、本当にそうなんでしょうか？
要件定義のインプットとなるのはお客さんの要求であり、アウトプットはシステムの要件となります。
インプットであるお客さんの要求がこの "要件定義" で作成される要件定義書に正しく表されていないと、使われない無駄な機能が開発されてしまったりします。
ある調査ではシステムが実現する機能のうち、実際に使われない機能が４５％もあるそうです。
仮にお客さんの要求を完全に理解できたとしても、アウトプットであるシステムに求める要件を要件定義書に正しく表していないと、結果的にお客さんが求めているシステムは作られないでしょう。
「システム開発におけるバグ原因のうち、４割は仕様の勘違いや認識違い。」という話もあります。恐ろしい話ですね。
こう考えると顧客満足が得られるシステムとなるかは "要件定義" にかかっていると言っても言い過ぎではないと思います。
そのわりには "要件定義" はシステム開発全体からすると、あまり重要視されていないような気がします。
なぜでしょうか？
その原因の一つとして私はこの "要件定義" って名前がどうも今の時代に合っていないんじゃないかと思っています。
私がこの業界に入った頃は、「ペーパーレス」という言葉が流行っていた頃(年齢バレバレ？）で、その数年後には「ダウンサイジング」って言葉が流行っていましたが、この頃が "要件定義" って名前の作業がマッチしていた頃だと思います。
この頃のお客様が求めている要求は、「手作業からコンピュータ作業になって正しく早く処理させること」であったり、「それまで以上に運用コストを下げる」などが多かったと思います。
それらの要求はそのままシステム開発の要件として開発されていたと思います。
"要件定義" と言ってもさほど難しいことはなく、システム開発全体から考えてもそれほど重要視しなくても済んでいたと思います。
ですが、最近のお客さんを取り巻く環境はその頃とは大きく違います。社内向けも社外向けも一通りシステム化されています。
そして加速するＩＴの進化の中、業務を効率化させたコスト削減、ユーザへのサービス強化をするために何かしらのシステム開発が行われています。
システム開発の対象は手運用の業務やハードウェアでカバーするものではなく、既に昔の要件を実現したシステムであったりします。
そう考えると "そのシステム開発によって実現されるべきこと" を表すことは、昔と比べると難しくなっていると思います。そう思いません？
それなのに "要件定義" という作業を昔と同じ感覚でしていたら、結果的にまったく使われない機能がたくさんあるシステムができたり、勘違いされた実装がたくさんあるシステムができてしまうんでしょうね。
ではそうならないように "要件定義" はどうしていくのがいいのでしょうか？
次回はその辺について取り上げたいと思います。
