前回は、要求と要件の違いは「主語」で、それぞれを考えるときには視点を切り替える必要があることを書いた。
今回はそれを踏まえて要件定義のやり方を書いてみたい。
要求の深掘り
開発はお客さんから「〜〜がしたい」とか「〜〜機能がほしい」とか言われてスタートすることが多いと思う。 ただ、このときそのまま「〜〜できるようにする」とか「〜〜機能を追加する」のように要件にしてしまうのは避けた方がいい。
これにはいくつか理由がある。
まず、本当にほしいものとズレている可能性があるということ。 「顧客が本当に必要だったもの」の風刺画にあるように、本当に必要なものをちゃんと分析して自分で規定することはとても難しい。 もちろん、それはお客さんではなくこちらで考えても難しいことなんだけど。 ただ、お客さんと会話して深掘りしたりモックを見せたりすることで、「思ってたのと違った」というのを早めに潰しておけるならそれに越したことはない。
そして、要求は深掘りしてより深い要求として理解した方が、その要求を満たせる手段の幅も広がるというのがある。 「ドリルの穴理論」の話にあるように、「ドリルがほしい」というレベルの要求の理解だと、それを満たす手段は「ドリルを売る」としかならない。 けど、「なんでドリルがほしいんだろう？」というのを深掘りして「壁に穴を空けたい」という要求が分かれば、「ドリルを売る」以外にも「ドリルを貸し出す」「人を派遣して穴を空ける」などの手段も考えられる。 さらに深掘りして「どうして壁に穴を空けたいんだろう？」というのを聞いてみたら「壁に絵画を飾りたいから」という要求が分かったりするかもしれない。 もうそうなると本当に必要だったのは壁の穴ですらない可能性も出てくる。
あと割とあるのが、単なる思いつきだったという話。 そういった思いつきをそのまま作って提供すると、作ったけど結局使われないままということがよくある。 それでもお金がもらえるならいいんじゃない？という意見もありそうだけど、実は落とし穴がある。 それは作った機能は使われてなくてもメンテし続けないといけないということ。 そうやって使われないゴミ機能が増えてしまうと、他の機能を追加するときの足枷になるし、やる価値のないバグ修正やテストで工数が膨れ上がることになる。
そんな感じで、要求の深掘りは重要。
そして、要求の深掘りをするときに重要なのが、顧客視点になるということ。 要求は主語が「顧客」なので、自分が開発者であることは一旦忘れて、顧客の立場になって、どうして〜〜したいのか、〜〜機能がほしいのかということを深掘っていく。
このとき、とくに意識したいのが「顧客が困っていること」。 困っていることを解消するのはすごく価値が高いというのがまずあるし、困ってることは明確なのでそれを解消するのは要求としてズレにくいというのもある。
逆に「あれば嬉しいこと」は難しくて、実際に作ってみても意外と使われないことも多い。 なくても別に困らない機能って、よほどの嬉しさがないと使わないんよね。
要件の検討
こうして顧客の要求を分析したら、それを満たすための要件を検討する。
ここからは顧客視点で考えていたのを一転させ、開発者視点で考えていくことになる。 顧客の要求を満たせるような手段を開発者として考えて、妥当な点を見つけていく。
この妥当な点というのは、「やりたいこと」と「できること」の均衡点。
「やりたいこと」は顧客が要求するもので、顧客視点では当然最大限満たされることが望ましい。 けど、開発ではそれを完全に満たすことは難しい。 技術的に実現可能かどうかがまずあるし、可能だとしてもコストがとてもかかってしまって現実的ではない場合もある。 なので開発者視点では「できること」に限りが出てくる。 そこで、「やりたいこと」ーー上（顧客）からの力学と、「できること」ーー下（開発者）からの力学とで綱引きが発生して、コストや納期なども踏まえてその綱引きが均衡する点が要件として定義されることになる。
そんな感じで「開発者が」やること、満たすべき条件を要件としてまとめる。 これはその開発でのスコープになる。
気をつけたいのは、これはソフトウェアの要件ではなく、開発の要件ということ。 すなわち、開発で作るソフトウェアの差分についての要件を書くことになる。 なので、「新規に〜〜機能を作る」「従来機能を〜〜に変更する」（場合によっては「〜〜機能を廃止する」）といったもののが要件となる。
ちなみに、ここでは主に機能要件を挙げてるけど、他にも性能やリソースなどの非機能要件もあるので、それらも必要に応じて定義することになる。
「やらないこと」の記録の重要性
あと、要件定義では「やること」だけではなく、「やらないこと」とその理由も実は書いておいた方がいい。
これは、「やること」は実際に開発が進むので明確に残るのに対し、「やらないこと」は開発が行われないので、文書に残しておかないとそもそも検討のテーブルに上がってたのかどうかすら分からなくなってしまうから。
あとになって「現状こうしてるけど、なんでこうしなかったんだろう？」みたいな疑問が浮かぶことはよくあるんだけど、やらなかった理由が文書として残っていれば、その疑問をすぐに解消できる。 そもそも検討のテーブルに上がってなかった（開発当時よりあとに出てきた手法とかだとよくある）のであれば、その方法を新しく検討してみる価値はあるだろうし、検討のテーブルに上がってはいたけど明確な理由があって採用されなかったというのであれば、それを知らずに再検討してやっぱり使えないとなる無駄を避けることができる。 あるいは、上記の力学の都合で採用されなかったり改善が先延ばしになっている場合もあるので、それであれば優先度に応じてその方法に切り替える開発を行うことも考えられる。
そんな感じで、どうしてやらなかったのかの理由はちゃんと書いておいた方がいい。
今日はここまで！
