ディレクター、プロジェクトマネージャーのみなさん、要件定義やってますよね。要件定義って超大事ですよね。
でも、じゃあ「具体的に何からどうすればいいのか教えて」って言われると、意外と難しくないですか？
「そういえば俺はこういう風に考えて要件定義やってるな」っていう要件定義の基本構造を整理してまとめてみました。
そもそも「要件定義」とは？
つまり、要件定義とは、「プロジェクトを進める上で、実装すべき機能や満たすべき性能など、課題に対する解決策として欠くことのできない必要な条件を定める」こと。
具体的には、例えばwebサイトリニューアルのプロジェクトであれば、
機能要件
コンテンツ要件
デザイン要件
構造設計／情報設計
などの形で定義される。
「要件」を導き出すためには？
これらの「要件」は、課題に対する解決策なので、それを導くためには、そもそも「課題」が明らかになっていないといけない。
さらに、「課題」とは「現状（As-Is）」と「理想（To-Be）」とのギャップ（埋めるべき差）なので、課題を明らかにするためには、現状と理想像が明らかになっていないといけない。
つまり、要件定義の構造を図にするとこうなる。
混同しやすい「背景」「課題」「目的」
提案書やプロジェクトマネジメント計画書などで、「背景」「課題」「目的」を書こうとして、どこに何を書けばいいのか迷ったことがある人も多いかも知れないが、こうして構造化してみると以下のように説明できる。
背景：現状・理想・課題の関係性の説明
課題：現状と理想のギャップ（埋めるべき差）
目的：理想の状態を実現すること
そして、「課題」を解決するために満たす必要のある条件が、各種「要件」となる。
この構造を、クライアント含めプロジェクトメンバー全員が頭に置いておかないと、粒度がずれたり、話が噛み合わなかったり、いつの間にか手段が目的化してしまったり、認識相違やボタンの掛け違いが起きてしまう。
それを避けるために、初回のヒアリングなどの際には、以下の「要件定義キャンバス」を大きく貼り出して（描き出して）、ポストイットなどで随時メモをプロットしながら、「今の話はどこのことを指しているのか」の認識を合わせながら行うと安心。
考える順番
そもそも、「現状（As-Is）」「理想（To-Be）」「課題（Problem）」が明確になっている場合は、素直にその課題に対する解決策を考えればいいので、要件定義にはそんなに悩まないはず。
「何からすればいいのか分からない…」となるときは、「現状（As-Is）」か「理想（To-Be）」のどちらか（あるいは両方）が不明確な場合が多い。
「現状（As-Is）」が不明確な場合
クライアントが「なんとなくこうなりたいという理想像はあるけど、どうしていいのか分からない」という場合は、以下の順番で考えると良い。
1. 理想像を精緻化
2. 現状を把握
3. 課題の洗い出し
4. 課題解決に必要な要件の具体化
「理想（To-Be）」が不明確な場合
クライアントが「現状のままでは良くないことは分かっているけど、どうしたらいいのか分からない」という場合は、以下の順番で考えると良い。
1. 現状を把握
2. 課題の洗い出し
3. （課題が解決された状態としての）理想像を精緻化
4. 課題解決に必要な要件の具体化
じゃあ具体的に「理想像を精緻化」「課題の洗い出し」ってどうやるの？と言われると、それはもう本当にケースバイケース。
じっくりデザインリサーチした方がいいかもしれないし、ビジネスモデルキャンバスやカスタマージャーニーマップを描くのが有効かもしれないし、逆にシンプルに膝つき合わせてヒアリングする方がいいかも知れない。
むしろ、そういう手法やフレームワークなどの「手段」に囚われず、チームメンバーのキャラクターとかリテラシーとかも勘案した上で、それぞれの「目的」に対してどうするのが本当に最適かを常に考えることこそが要件定義プロセスの肝だと思う。
次回は、Webサイトだけでなくサービス領域にも比較的適用できそうな具体的手法をひとつ紹介します。
