要件定義って何？
IT業界では、要件定義という言葉がよく利用されます。個人的に要件定義という言葉は、利用される割に曖昧な言葉なので、いろいろな誤解を与えているなと感じています。ということで、今回はソフトウェアを作る最初のフェーズである要件定義について話をしたいと思います。
よいソフトウェア製品を作るにあたって、何が重要なのかというと、
- ユーザの真なるニーズを把握する（要求の仮説を立てる）
- そのニーズを満たす正しい解決策を考案する（仕様を定める）
という２点に尽きる、と私は思っています。
いくら優れた技術を用いても、素晴らしいユーザインターフェースを提供しても、これらを見誤ったソフトウェア製品が成功する確率は極めて低いと言わざるを得ません。そしてこれらを突き詰めることこそが、まさに要件定義フェーズで行うことです。そして、要件定義にまつわる曖昧さというのは、この要求と仕様という異なる性質の二つの要素が要件定義という一つの言葉に含まれてしまっているところから来ていると思います。
ちなみに、要件定義という言葉はSI業界のみで利用されている印象を与えますが、ゲームであれ、Webサービスであれ、組み込みであれ、ユーザのニーズを把握し、解決策を考案するという点で共通しているため、この話はソフトウェア開発全般に当てはまる話だと思います。
では要求と仕様の違いは何なのでしょうか？
要求というのは、いうならばユーザがそのソフトウェアに期待している価値であり、すなわち目的です。その中には、ソフトウェアを通じてどういう状態を実現したいかという抽象的なレベルから、ソフトウェアの利用を通じて得られる具体的な体験（ユーザエクスペリエンス）まで含まれています。ユーザの多くは期待を表現することができないため、要求は制作側が分析を行い仮説を立てる場合がほとんどです。
最終的に、何を(Why)、なぜ(Why)解決すべきなのかが、要求として明らかになっている必要があります。
一方、仕様というのは、洗い出された多数の解決策の中から選択された最善の方法であり、すなわち手段です。それには、機能、画面の構成、ユーザインターフェースなどが含まれています。つまりいかに（How）解決するかが仕様という形でまとまっている必要があります。
なぜわざわざこんな整理をしたのかというと、背景として２つの課題意識があります。１つは、経験豊富なプロジェクトマネージャでも、要件定義をしているうちに目的を決めているのか手段を決めているのかを混同しまっているケースが
よく見られるため、そうならないように要件定義の整理の枠組みを提示したかったという点。もう１つは、特に受託開発のソフトウェアハウスが、最終的に仕様レベルで合意を行えばその責任はお客様に移転されるという点をふまえて、要件定義フェーズで要求の整理をしなかったり、要求から仕様に落とし込む努力を怠り仕様の品質が低くなることが多い点の２点です。
要件定義は、このように分解しても実際にはかなり難しい作業なのですが、よいソフトウェア製品を作るために重要なフェーズなので、正しい理解に基づいて取り組む必要があると思います。
