Devに伝わる要件定義のコツ No.2
はじめに
こんばんは〜
ひょっとこです。
今週も折り返し地点まで来ましたね。
来週は３連休となるので、今週を乗り切って楽しい３連休を過ごしましょう！！
さて、昨日の続きでDevサイドに伝わる要件定義のコツをまとめていこうかなと思います。
昨日は以下の、１と２について記事を投稿しましたので今日は残りの２つについて記事にまとめていこうと思います。
要件定義の４箇条
ユーザーの利用シーンを想像しながら論拠・根拠を詰めていく。業務パターンや条件を図や表を用いて可視化して表現する。要件定義をしながら具体的なサービス全体像を可視化してみる。
要件の記載内容はYes/Noで判断できるようにまとめていく。
要件定義のコツ
可視化することで解像度の確認をする。
3. 要件定義をしながら具体的なサービス全体像を可視化してみる。
はい、３つ目のコツとしてはサービスの全体像を要件定義をしながら可視化してみることです。
私は、Miroでサービスイン〜サービスアウトまでの全体像を可視化して整理するようにしています。
というのも、可視化することによるメリットが２つあると考えているからです。
１つ目のメリットとしては、解像度の低い部分の洗い出すことです。
可視化していく中で表現できない部分とは、自分が理解していないから表現できない部分になります。
なので、自分が描けて可視化できる部分（理解している部分）、描けなくて可視化できない部分（理解していない部分）を把握することで解像度の低い部分を自分が理解する手助けになります。
２つ目のメリットとしては、可視化することでDevサイドにも説明しやすくなることです。
サービスの全体像を可視化しておくことで、言葉で説明するよりもDevサイドが理解しやすくなります。
可視化することで相手に伝わっていない部分がわかりやすくなりますし、相手からどこの部分が理解できていないかのフィードバックを得やすくなります。
可視化することは慣れるまで難しいと思います。
私は、師匠がA4用紙１枚に手書きしながらサービスの全体像を整理しているのを真似てできるようになりました。
今は色々なツールがあるので、やり方を工夫しながら試してみてください。
ちなみに、最近の私は、Miroというツールを使って全体像の可視化をすることが多いです。
使いやすいツールなので、興味がある方は無料で試してみてください。
アバウトな記載はNG→Yes or Noで判断できるように記載しろ！！
4. 要件の記載内容はYes/Noで判断できるようにまとめていく。
４つ目はYes or Noで判断できるような要件を定義することです。
プログラムを書いたことがある人はわかると思うのですが、システムを構築するためには、基本的に特定条件に対してYes or Noで判断できる必要があります。
要件定義の記載が抽象的だと、設計をする際にDevサイドがシステムにどう判断させればいいかがわからず困ってしまう事態に陥ります（苦笑）
そうするとDevサイドから怒涛の質問がきてしまうので大変です。
質問が多発するということは、それだけコミュニケーションコストがかかるので、スケジュール遅延の要因になりやすいので、要件定義をする段階からYes or Noが判断できる記載をするように心がけましょう！！
要件定義をする際には、次の工程である設計ができる状態とはどういう状態なのかを理解して進めると、Devサイドに伝わる要件定義ができると思いますよ。
おわりに
この２日間、要件定義の４箇条を説明してきましたがいかがだったでしょうか？
私がエンジニア時代に、これをやってくれると楽なんだけどな〜と感じたポイントや、企画の仕事をしていて気をつけているポイントを記事にまとめてみました。
少しでも多くの企画担当者、上流工程担当者がDevサイドに伝わる要件定義ができて欲しいと思っています。
また、良いサービスを作るためには、Biz、Devの立場に関係なく相手の立場を理解する必要があると考えておりますので、一人でも多くの方が相手の立場を理解したコミュニケーションを取れるようになることを祈っております。
記事を読んで参考になった、役に立ったという方がおりましたら、コメントをいただけますと幸いです。
本日はここまで、次の記事でまたお会いしましょう！！
この記事が気に入ったらサポートをしてみませんか？