要求定義で使えるフレームワーク

2024年6月12日 19:22

はじめまして、uemmmyと申します。
半年ほど前からウォンテッドリー株式会社でプロダクトマネージャーとして働いています。前職まではUIデザイナーとしてスタートアップ企業に勤めていました。
今回はPdM1年目の私が要求定義の際に活用しているフレームワークを紹介したいと思います。

はじめに

この記事の概要

質の高い要求定義を行うために便利なフレームワークの紹介

誰に読んでもらいたい

プロダクト開発に関わる人
新人プロダクトマネージャー
困った時の自分

どう役に立つのか

ズレやモレの少ない要求定義が出来るようになる
要求の質が上がることで施策の質が上がる

要求定義とは？

一言でいうと"ユーザーの課題解決に必要な体験を定義すること"だと考えています。
ユーザーの課題（Why）を把握し、解決に必要な体験（What）を書き出したものであり、具体的な解決策（How）を検討していくための重要な指標となるものを要求定義と言います。

ウォンテッドリーではプロジェクトを始める際にプロダクト要求定義書（PRD）に背景や機能仕様と共に明記しています。

プロダクト要求定義書（PRD）については、あきさんがわかりやすいnoteを書いているのであわせてどうぞ。

要求定義は難しい

要求定義で重要なのは解決策・機能ではなく解決に必要な体験を書いていくということです。
例えば「xxxのボタンを作る」ではなく「xxxに遷移できるようにする」と書きます。

要件定義と異なり具体的な機能を書くわけではないので、課題に対しての深い理解とユーザーに寄り添った視点が必要となります。
ここが不足しているとユーザーの課題と解決策がズレてしまったり、本当に必要な要求が書かれていないといったモレが発生しやすくなります。

経験のあるつよつよPdMの場合はアイデアの時点でズレモレの少ない要求定義ができるといった場合もありますが、新人の俺たちは黙って先人の知恵(フレームワーク)に頼っていきましょう。

要求定義に便利なフレームワーク

私が要求定義の質を上げていくために使っているフレームワークを3つご紹介します。細かいやり方はここでは割愛するので各項目の最後に掲載している参考記事を見たり、ググったり、ChatGPTにたずねてみてください。

9コマシナリオ

9コマシナリオは、ユーザーの課題解決までの体験を9つのコマに分けて、マンガ風に表現することでユーザーの行動やインタラクションを簡潔に把握するためのフレームワークです。

おすすめの利用シーン
課題に対して、まずは草案を考えていく時に便利です。イラストを用いることで視覚的に理解しやすく、アイデアの段階では気づけなかった悩みと体験のズレに気付くことができます。
また、テキストや口頭での説明だけだとよくよく発生する、チーム内での認識の齟齬が本当になくなります。

作り方のコツ
9コマが大変、、って人はまず4コマで作ってみるがおすすめです。私はいらすとやフル活用でサクっと作っています。
あとは具体的な機能は書かないようにして、セリフや感情ベースにしていくとHowを考える際に引っ張られづらくなるのでおすすめです。

参考にした記事

ユーザーストーリーマップ

ユーザーストーリーマップは、ユーザーの課題解決までの体験を時系列で並べて、それぞれに必要な機能や要件を視覚的に把握するためのフレームワークです。

おすすめの利用シーン
要求を書き出してみたけど、過不足がないか心配な時に活用しています。
ユーザー行動に沿って必要な体験を書き出すことで、見落とした体験がないかどうかを視覚的に把握することができます。また、細かいタスクを書き出し優先順位をつけていくことで問題解決に必要な最小限の要求がわかるので便利です。

作り方のコツ
ストーリーの流れを粒度気にせずに細かすぎるほどにまずは書いてみることで、見落とした体験を拾いやすくなるのでおすすめです。細か過ぎた場合は作った後に外せば大丈夫です。
上手く作れるとバックボーン（ストーリーの骨格）の箇所を書き出すだけで要求定義になります。

参考にした記事

サービスブループリント

サービスブループリントは、ユーザーの課題解決までの行動とインタラクションを可視化し、UIで見える部分から内部プロセスまで詳細に把握できるフレームワークです。

おすすめの利用シーン
「なんだか仕様が複雑になりそうだな、、」と思った時に活用しています。
ユーザーストーリーマップ同様にユーザー行動を書き出すことで、全体の体験を視覚的に把握することができます。また、早い段階でエンジニアに共有しておくことで、技術的な懸念などを事前に相談できるので、致命的な手戻りなどを防ぐことができます。

作り方のコツ
ある程度要求定義を書き出したあとに使いやすいフレームワークなので、9コマシナリオとあわせて作成するのがおすすめです。単体で書くと要件によってしまいやすくなるので気をつけてください。
あと、いろんな記事を見ているとフロントステージ・バックステージの定義が曖昧だったりしますが、プロダクト開発であれば「UI上に見えるもの・見えないもの」くらいの定義で進めていいと思います。

参考にした記事

おわりに

紹介したフレームワークの活用方法に関しては、かなり独自の解釈が入っている気はしますが、「質の高い要求定義ができれば何でもいいんだよ！」というくらいのお気持ちで書いてみました。

個人的にフレームワークって最初作るまでがハードルだと思っていて、この記事でハードルを出来るだけ下げて「試しに小さく作ってみよう」と誰かに思ってもらえたら嬉しいです。

ちなみにですが、こういったフレームワークを作成する際はmiroを活用しています。miroでもFigmaでもいいのでとにかく簡単に！楽に！図形が描けるツールを使ってください。フレームワーク作成のハードル出来るだけ下げていきましょう。

最後まで読んでいただきありがとうございました！

この記事が気に入ったらサポートをしてみませんか？