Devに伝わる要件定義のコツ No.1
はじめに
こんばんは。
ひょっとこです。
今日は雪が降るくらいに寒く、家でガクブルしながら在宅ワークをしていました。
そして、今日のうちから明日も在宅することを心に誓っております（笑）
さて、企画職になってからDevサイドに企画したサービスの要件をお伝えしているのですが、元エンジニアから見たDevサイドが理解しやすい要件定義のコツをまとめていきたいと思います。
要件定義のコツ
企画職をしていてデザイナーさんやエンジニアさんに、うまく要件を伝えられずに困った経験がある方もいるのではないでしょうか？
私は元々、エンジニアだったのでこんな要件だと設計しづらいな、進められないなという実経験を持っているので、自分がやられて嫌なことを相手にしないように注意しながら要件定義をしています。
では、私が気をつけていること記載していきましょう。
要件定義の４箇条
ユーザーの利用シーンを想像しながら論拠・根拠を詰めていく。
業務パターンや条件を図や表を用いて可視化して表現する。
要件定義をしながら具体的なサービス全体像を可視化してみる。
要件の記載内容はYes/Noで判断できるようにまとめていく。
では、一つずつ説明していきましょう。
要件定義の段階から最終アウトプットを具体的に思い描く。
1. ユーザーの利用シーンを想像しながら論拠・根拠を詰めていく。
１つ目は、当たり前かもしれませんが、「ユーザーの利用シーンを想像しながら論拠・根拠を詰めていくです。」です。
ユーザーが抱えている問題、想定する利用シーン、定量的な根拠等を集めつつ要件に落とし込んでいくのですが、その際にエンジニアに説明できるように論拠・根拠を具体例を想像しながら要件に落としこむことが重要です。
Devサイドでは、企画が思い描いたサービスを具体的に実現することがメインの仕事となります。（保守とかもあるのですが、今回は割愛します。）
実際に要件を説明する際に、ユーザーが抱える問題と解消方法、マーケット、ターゲットユーザー、利用シーン…などなど、Devサイドに実現するサービスや機能の具体的なイメージを持ってもらう必要があります。
ですので、相手がイメージできるような具体例を論拠・根拠を持って説明できるように要件を定義していくのが理想です。
要件定義だからと言って、抽象的でいいかと考えてしまう人を結構な数見てきたのですが… 私の経験上では、そのような人が要件定義をすると炎上する可能性が非常に高いです。
要件を定義している段階から、具体的なイメージを構築してDevサイドに説明できるようにしていきましょう。
パターンや条件は抜け漏れなく図・表に可視化してまとめる
2. 業務パターンや条件を図や表を用いて可視化して表現する。
２つ目は、要件定義の段階で業務パターンや条件を抜け漏れなく洗い出して、可視化してまとめることです。
要件定義の段階でパターンや条件の整理ができていないと、Devサイドは設計に落とし込むことができません。
私はBEだったのでBEの観点から言うと、開発する時にケースごとにどのような処理をさせて、DBにデータをどう登録させていくかを検討する必要があぅたので、要件定義時のパターンや条件の整理はかなり重要になってきます。
図や表にしてまとめてもらえると、かなり嬉しかった記憶があるので自分もそれをやるようにしています。
何と言っても、図・表の方が理解しやすいですしね！！
特に抜け漏れなくが重要で、抜け漏れがあると手戻りが発生して今までやっていた作業をやり直す必要がでてきます。（下請けとして仕事をしていた時に、どれだけ残業をする羽目になったことやら…）
そのため、Devサイドに無駄な時間を使わせてしまうことになりますので、要件を定義する段階で抜け漏れがないように検討していきましょう。
俗にいうロジカルシンキングで、検討していくと良いと思いますよ。
後のフェーズで具体化していけばいいとか考えている人は、The Fool（愚か者）と、Devサイドから呼ばれる可能性があるので注意が必要です。
おわりに
いかがだったでしょうか。
長くなりそうだったので、残りの２箇条はNo.2 の記事で説明していこうと思います。
サービスの企画職はさまざまな部署と関わりを持ちつつ、サービスを実現させる必要があります。
そのため、Biz、Dev…色々な経験を積んでみた方が、いい企画職になれるのではと4ヶ月仕事をしながら感じています。
Devサイドに要件の説明をするのが苦手という人は、Devサイドが具体的にどのように仕事を進めていくのか、各フェーズにおけるアウトプット（成果物）はどのようなものがあるのかを頭に入れておくとコミュニケーションが楽になるので、試してみてください。
では、次の記事でまたお会いしましょう！！
この記事が気に入ったらサポートをしてみませんか？