PRD のススメ ~ メンバーや関係者とのスレ違いを減らそう

自分のアイデアにメンバーが納得・共感してない…
営業メンバーが売上視点しかない施策を提案してくる…
開発メンバーが売上の重要性をわかってくれない…

プロダクト開発の過程では、スレ違いは多く発生します。
エンジニア、デザイナー、セールス、マーケティング… など、異なる職能の人が集まって議論すれば、なおさらです。

今回の記事では、関係者の視点を揃えやすくなる「要求定義書」のフォーマットを紹介します。

はじめに

▼ これは何か
プロダクト開発は「要求定義書（PRD）」を作るとスムーズってことが書かれた記事。
Wantedly Advent Calendar 2023 のいち記事

▼ 誰のために書かれているか
・プロダクト開発に関わる人
・プロダクトマネージャー
・施策立案する人

▼ どう役に立つか
・メンバーと視点が揃い議論がスムーズになる
・成果に繋がるポイントが明確になって施策の質があがる

要求定義書（PRD）とは

プロダクト開発する際に、プロジェクトの目的や提供したい体験、機能仕様などを記載した文書のこと。略して PRD（Product Requirements Document）と呼ばれる

仕様書との違い
「作り方」だけではく「プロジェクトの目的」や「顧客の課題」などを丁寧に書く点が異なります。PRD は、指示書 ではなく チームに方針を示す羅針盤です

いつ作成するのか
プロジェクトを企画するときに作ります。最初はデザインや機能仕様が未確定なので、プロジェクト目的や顧客課題を中心に記載します。PRD 草案をメンバーや関係者に共有し、kick off。プロジェクトを進行しつつ、デザインや仕様を明確化し、PRD を更新していきます。PRD は関係者全員でコツコツ更新していきましょう。

サンプル

PRD にはいくつかのフォーマットがあります
たとえば、こんな書き方があります

How to Write a Painless Product Requirements Document

ぼくが使ってるフォーマット

全部書くと長くなるので、重要な箇所を抜粋して記載します。
大きく「Biz - UX - Dev」の 3 つのセクションを大事にしています

1. Biz - 事業的な背景や目的

事業的な背景に関するセクション
収益構造や競争優位性などをもとに、なぜこの施策に取り組むべきなのかを記載します。

事業的な背景
例. マッチングアプリ
いいね数が YoY で n% 減少している
n% 以上減少すると xxx なリスクが高まるので対策が必要。

施策のゴール
以下 3 点を記載します
・目的：いいね数を増やす
・目標：いいね数を n% 向上させる
・締切：202x年xx月末まで

ひと言メモ
KPI ツリーやグロースサイクルなど図解を添えて説明すると、事業構造に詳しくないメンバーにも、より伝わりやすくなります。また、根拠となるデータがあると議論がスムーズになります。

2. UX - 誰の何を解決するのか

ユーザー体験に関するセクション
このセクションの解像度が荒いとデザインや仕様検討の際、優先度が曖昧になり、議論が発散的になります。しっかり整理することをオススメします。

顧客価値
誰のどんな課題を解消するのか整理して記載します

例. マッチングアプリ
対象：まだ「いいね」をしたことがない人
目的：相性の良い人とマッチングする
場面：「いいね」する相手を探す
悩み：返信が来ない不安で「いいね」しない
解決：プロフィール作成のコツを教える
価値：ミスマッチの減少

要求
顧客価値の実現に必要な体験を書き出します
「xxx が 〜〜〜 できるようにする」のような形式で書くとスムーズ

ひと言メモ
要求の書き方はユーザーストーリーマッピングが参考になります。
miro にテンプレがあるので、よく使ってます。

3. Dev - どう解決するのか

解決アプローチと実現可能性に関するセクション
前述の Biz&UX セクションで明確にした目的を満たすためには、どのような手段が最適なのかを関係者で議論し、決めていきます

デザインコンセプト
ペーパープロトタイプやワイヤーフレームを作る前にデザインのコンセプトを記載します。認知工学を参考に「認知・感情・行動」の 3 領域でユーザーにどのような変化を起こすのか？を明確にします。
少し長くなるので、ここは別記事で書きます。

プロトタイプ
前述のコンセプトを反映したプロトタイプを作成します。
最初のプロトタイプは、ペーパープロトタイプなど荒いものが多いです。
施策を進めるなかで、デザインが決まってきたら、都度 PRD のプロトタイプを更新していきます。

機能仕様
対象ユーザー、データベース、インターフェース、非機能要件など仕様を細かく記載します。PRD 作成時はざっくりした仕様のみ記載し、施策を進めるなかで詳細化していきます。

集計仕様
デザインがある程度決まった後に、本施策の成果を、どのように振り返るのかを記載します。具体的には、想定してる集計表やグラフ、集計に利用する SQL クエリなどを記載します。
これをやらないとリリース後に「集計できないKPIがあったよ…成果がわからないよ…」など、振り返りがしづらくなることも。

おわりに

まとめるとこんな感じ

要求定義書（PRD）とは

プロジェクト目的、実現したい体験、機能仕様などを記した文書。
PRD は指示書ではなく チームに方針を示す羅針盤。
メンバー全員でコツコツ磨き上げましょう

PRD に書くべき 3 視点

この 3 つの視点を入れておけば議論がスムーズになる
・Biz - 事業的な背景や目的
・UX - 誰の何を解決するのか
・Dev - どう実現するのか

おわりのおわりに

プロダクトマネジメントに興味のある方は、以下の記事もオススメです。
ぜひ、読んでみてください🖐️

それでは、最後まで読んでいただいてありがとうございました！

この記事が役に立ったぞ！という方へ
いいね・シェア をもらえると、嬉しいです！
note は、自分のために書いてますが、誰かの役に立つとモチベーションになります

今後もコツコツ記事書こうかなって思ってるので、興味をもってくれた方はフォローもお願いします！

Twitter もやってるので、よろしくです〜

おわり！