- 要件定義とは
- 設計とは
- 要件定義と設計のすみわけ
- 要件を定義して設計する=何をどのように作るかを決める
- 結論:要件定義は顧客とベンダで吟味して行われる領域で、そのあとにベンダが実現方法を任された部分が設計領域である
要件定義と設計の関係を整理する。
要件定義とは
要件定義は、ざっくり言うと、何を作るかを決める作業である。
設計とは
設計は、ざっくり言うと、どのように作るのかを決める作業である。
作るものを決めるという意味では同じだが、何を作る/どのように作る、という観点で、意味合いが異なっている。
要件定義と設計のすみわけ
要件定義工程と設計工程は、責務が異なるのだ。
要件定義は、Whatを決める工程であり、
設計は、Howを決める工程である。
とまあ、責務が異なるといえば、作業工程が完全に分断されるように思えるのだが、実際には、要件の定義が設計に影響を及ぼすことは多々ある。
要件を定義して設計する=何をどのように作るかを決める
例えば、「30分以内に顧客に障害通知をすること」という要件があったとする。この要件を満足する実現手段として、「メールによる連絡をする」という設計をしたとする。
メールによる連絡は、「どのように連絡するのか?」という問いに対する答えであり、設計である。しかしながら、上記の要件が「30分以内にメールで顧客に障害通知をすること」という要件となった場合、「メールによる連絡をする」という部分は要件になる。
そのため、Whatを決めるのが要件定義、Howを決めるのが設計、と杓子定規に解釈していると、しばしば、これは要件なのか?設計なのか?という混乱が生じうる。
結局のところ、要件定義側が「これは要件である」といえばHowにかかわる部分も要件であるし、要件と設計の間に厳密な境界線はないのである。そんなこといっても、設計作業は必要だし、すみわけを明確化したいとなった場合にどうすべきか?
ありきたりな考えだが、やはり顧客とベンダで会話をすべきだ。要件だからと言って、そのまま作ろうとするのも得策ではない。要件がよくない場合もありうるからだ。ベンダも要件を精査し、良くない部分については申し入れを行い、要件を変更してもらう。顧客側も、要件について、しっかりと吟味する。
そのようなすりあわせが行われたのちに、「手段はいろいろあると思うが、あとは任せる」となった部分が、設計領域なのである。そういうわけで、筆者としては、下記の考えがしっくり来ている。
結論:要件定義は顧客とベンダで吟味して行われる領域で、そのあとにベンダが実現方法を任された部分が設計領域である