ユースケースとは何か、そして、書き方メモ
なぜ書いたか
「ユースケース書いて」と言われたときに即座に手を動かせなかったことがあり、ユースケースについて言語化したいと思ったため
後述の通り、決まったルールは無さそうなので、この記事を読んだ方からフィードバック(間違いへのツッコミ含む)をいただけるとより理解が増しそうだと思ったため
ユースケースの定義
ユースケース（Use Case）は、ソフトウェア工学やシステム工学で
システム（あるいはシステムのシステム）の機能要求を含む振舞を把握するための技法である。各ユースケースは、何らかの目的・目標/機能に関する台本（シナリオ）での主体（アクター(actor)）と呼ぶ利用者（ユーザ）とシステムのやりとりを描いている。
あるゴールを達成するために、システムとその利用者の間でどのようなやり取りが起こるのかを記載したまとまりがユースケースとなる
ユースケースの意義
ユースケースの存在意義は、要求と機能を結びつけることにある
ユースケースが無いと、要求と機能のミスマッチが起き、以下のようなことに陥る
要求のない(≒つくる必要のない)機能がうまれる
つくろうとしている機能では、要求を満たせない
また、ユースケースがあることで、開発スコープを決める際に明瞭な取捨選択が可能となる
要求と機能がセットになっている状態であれば、要求の重要度順に機能の必須順位をつけることができるので、「この機能は後回しにしてよいのか？」という問いをシャープに答えることができる
ユースケースの書き方、粒度
ユースケースの書き方や粒度に決まったルールはなく、その時々の状況に応じて使い分ける
注意点
主語を明確にすること
代替フローや例外フローを想定することが難しいが、IPAの資料(PDF)にある①5W2Hによる確認、②ドメインエキスパートへのヒアリングが有効そう
①5W2Hによる確認
変数となり得る観点を事前にもっておくことがポイント
②ドメインエキスパートへのヒアリング
イレギュラーケースをどれだけヒアリングできるかがポイント
おわりに
ユースケースの目的や何を満たす必要があるか、について概観を掴むことができた
ユースケースは、プロダクトづくりを前に進めるための重要な叩き台だ
ユースケースを正しく記述し、適切に優先度を評価できることが、担当プロダクトの立ち上がりスピードやグロース度合いに直結すると思った
特にtoB SaaSのプロダクトマネージャーにとっては不可欠であり、実践するためのドキュメントライティング力やドメインエキスパートからのヒアリング力がスキルの1つとして求められるのだと思う