見出し画像

PRD (プロダクト要件仕様書)の書き方解説 #わたしのPRD

kaz｜ハヤカワカズキ

こんにちは、外資系IT企業でプロダクトマネージャーをしていますハヤカワです。

先日このようなツイートしたら多くの方に反応いただけたので簡単に解説したいと思います！

前提は

Why: プロダクトの価値や作る目的をチームに伝えて意見を得るため
Who/How: PMとエンジニアリングチーム間で共有する
When: 会社、チームとしてプロダクト全体のビジョンが決まっていて、これから具体的な製品のMVPを作るとき
What: v1となる製品の初期のspec (製品仕様)を示すPRD

では早速どうやって作るか見ていきます

画像1

大きく10コのコンポーネントに分かれています。それぞれ解説していきます。

1. 主な達成すべきジョブ

ジョブ理論大好きPMなので、プロダクトをなぜ作るのか？を説明するときにはジョブ理論を使ってみます。ジョブ理論が何か分からない方は以下を参考にしてみてください

ここでは、重要で、メインとなる、我々が解決したい主要なジョブをストーリー形式で記載します。

ストーリー形式とは、When(状況), I want to (動機), So I can (期待される成果)の3つからなる記述方法です。

When: いつ、どのようなコンテキストの話なのか？
I want to: 何をモチベーションとして、何をしたいのか？
so I can: 期待される結果、アウトカムとして何ができればいいのか？

たとえば、

When: とても好きな写真に出会ったときに
I want to: 共感していることを相手に示したい
so I can: なので、写真を投稿した人に対してリアクションを贈りたい

これは、InstagramのLike機能を簡単に表現したものです。InstagramにLike機能をつけるべきだという、PRDの始まりを簡単に書くとこのようになるのではないでしょうか？

もちろん、ジョブ理論は必ず「顧客の声」から生まれるべきなので、PMだからといって一人で一生懸命考えたり、チームを集めてブレストするだけではダメです。しっかり顧客と会って、話して、その上で顧客が抱いているジョブが何かを見極めて、上記のような書き方をします。

2. ジョブパフォーマー (ペルソナ)

上記のジョブを実際に抱えている人がどういう人物であるかを書きます。わかりやすくペルソナと書きましたが、一般的なペルソナアプローチのように、年齢、性別、仕事、思っていること、普段見ていること、など抽象的な書き方ではなく、具体的に上記のジョブを抱えている人がどういう人なのかをユーザーインタビューや顧客調査を経たうえで、その人達を説明するための情報を記載します。

[ジョブA]を持っている人であれば、一般社員だろうが、役員クラスだろうが、地域や言語、文化、性別、生活がどうかとかは関係ないんですね。そのジョブを抱えている人は誰なのか？を具体的に示します。

3. 期待されるアウトカム

上記のジョブが達成された際に、ジョブパフォーマーが求めている結果、成果、アウトカム、価値はなんなのかを記します。ここでは、Desired Outcomと呼ばれているジョブの記述法に従って書いてみます。

Desired Outcomeの記述法: 〇〇の時 (状況)にXX (対象)の△△ (指標)を[最大 or 最小]にしたい

たとえば、さきほどのInstagramのLike機能であれば、

 ・好きな写真を見つけたときに、共感を示すために掛かる時間を最小にしたい (写真のダブルタップによるLike)
・共感を示したときに、共感が伝わったと感じられる感情を最大にしたい
(Likeしたときのエフェクト, Like数のカウントによる貢献の可視化)
・写真を投稿したときに、共感が得られたという感情を最大にしたい
(Like数の積み上げ、通知)

このように、「いつ、何を、どういう指標で、どうしたいのか？」を書きます。

指標というのは、時間や、お金など量で示せるものや、感情や状態など定性的なものでもOKです。ただし、のちのプロダクトの成功を測るときにも使えるので、計測可能なものであることが重要です。

最近はLike数を非表示にする動きなのがあるので、上記のアウトカムが本当にユーザーが求めているか？という議論は置いておきます。あくまでもLike機能を実装する上での、期待されるアウトカムは何なのか？を考えてみました。ちなみに、 ()で書いたのは対応するソリューションをわかりやすく書いただけであり、PRDのこのセクションでは書く必要はありません。

4. どんな問題を解決すべきなのか？
5. どうやってその問題を解くのか？

ここはまとめてしまいますが、わかりやすく、文章でそれぞれ書く必要があります。だいたい、１５秒くらいで説明できる量、1分くらいで説明できる量、それぞれあると良いかなーと思います。いわゆるエレベーターピッチに使える長さですね。簡潔に明瞭に、具体的に書く必要があると思います。

6. 何を作って届けるのか？
7. ユーザーストーリー

ここからは、ソリューションの話になります。ここまではどちらかというと、 Problem Spaceと呼ばれる、問題解決のための話で、ここからがSolution Spaceと呼ばれる、具体的な製品やサービス、機能や手段、解決策の話になります。

「何を作って届けるのか？」というところも、4,5と同様にわかりやすい文章で書くのがいいと思います。簡単な説明と、2,3コの箇条書きがあるといいかもです。

ユーザーストーリーは、これは会社や開発の仕方によって大きく変わってくるので一概には言えないと思います。

私の場合は、最低限以下のようなものをリストにまとめます。

説明、仕様概要、優先度、チーム依存、指標、日付

チーム依存は、Team Dependencyと呼ばれるもので、大きな会社だと、1つのスクラムチームだけでは完結せず複数チームと、合わせながら開発する必要があるので、PRD段階でわかっている他のチームとの依存する機能や、チーム名を記載して、コミュニケーション取れる状態にしておきます。

指標は、Desired Outcomeでも記載したような計測可能な、その機能が成功したかどうかを客観的に測ることのできるものを記載します。逆にこれを明確にしておけば、製品開発する際にその指標を取るための、ロジックを開発に埋め込むことができます。あとになって、取りたかった指標なのに取れないとか、無駄な指標をトラッキングするためにエンジニアリングリソースを使う必要はありません。

8. 顧客調査

ここまで、あたかもPMが一人で考え抜いて作りました！感がありますが、やはりここに行き着くために多くの顧客と会話しているということが重要です。なぜこのような考えに私が至ったのかを、客観的かつデータで示す必要があると思います。

なので、ここで実際に話した顧客がどういう人で、何を望んでいて、困っているのか、を詳細に記したり、場合によってはユーザーインタビューの内容やその分析結果をリンクするといいと思います。

この問題の定義ってこれでいいんだっけ？と悩んだり、ソリューションって他にあるんじゃないの？と意見が別れたり、ぶつかったり、わからなくなった時に、みんなが共通して戻ってくれる唯一無二の絶対的な情報ソースとして、顧客調査のデータが必要になります。ここに立ち戻って、改めて議論を重ねて、PRDを完成させていきます。

9. 競合分析

顧客調査と似たような役割で、競合他社または類似サービスの情報も載せておきます。これは、必須ではないですが、後述するモックアップと同様に、実際にすでに現実にものがあれば、会チームとの会話もスムーズになると思います。ただし、注意としてはこれを全面に出してしまうと、同じようなものを作るのだと勘違いされたり、先入観がはいってしまったり、逆に敵対して意味もなく違う機能を付け加えようとしてしまいます。あくまでも参考情報として入れておくことにしておきます。

10. v1の制限とv2に向けたアイデア

ここまで資料を読むと、チームの人たちは、「あれ？これだけ？」とか「別の観点があるんじゃない？」とか色々質問が出てきます。もちろん、何日も何週間もかけて練り上げたPRDですので、もうすでに想定済のことも多いと思います。なので、「事前にここまではわかっているんですよ」というのを伝えるための、v1の制限とv2に向けたアイデアも記載しておきます。

そして、なぜこの制限を許容しているのか？なぜその機能をv2に持っていくべきなのかというのも、優先順位づけの観点で記載しておきます。

無駄な議論やもったいない方向性にいかないためのガードレールの役割だと思います。

補足①Q&A

さて、以上がTwitterで投稿した #わたしのPRD の全容です。ここまで読むと、あれこれだけ？と思う方も多いと思います。しかし、このPRDの目的はあくまでもチームの意見をもらい、より良いPRDを作るためのものです。

そこで、PRDの最後のセクションに、Q&Aの内容を記載するスペースを用意しておきます。このスペースを用意することで、チームからの意見を拾い上げたいという姿勢を示すことと、チームの人もコメントしていいんだという気持ちになってくれるので、意見が出やすくなります (というか、そうなることを願っています)

補足②モックアップ

次に、ここまでほぼテキストだけで記載してきました。ものによってはモックアップを用意して、簡単なビジュアルで表現したものも必要なケースがあると思います。その場合は画像等を追加していいと思います。

ただし、注意としては、やはり視覚情報は記憶に残りやすいので、見た目で議論をしないこと、先入観をあたえないこと、が大事だと思います。あくまでも、PMの役割は、「何をなぜ作るのか？」なので、「どう作るのか？」や「どういうデザインでどういう見た目か？」というのは、エンジニアやデザイナーに任せるべきです。なので、個人的には9割はテキストでいいと思います。

補足③技術的な要件

技術的な要件も同じ理由で、エンジニアに任せたほうが遥かに良いものができると思います。なので、このPRDをもって、エンジニアチームと会話をしながら、技術的な要件を記載していきます。

さいごに

以上が、 #わたしのPRD と題した個人的に今だったらこう書くかなーというPRDです。いろいろなパターンがあると思うので、これらの要素を参考にしていただいて、ぜひご自身のPRDを書いてみてください。そしてフィードバックや相談もお待ちしてます！👋

そして、 #わたしのPRD このハッシュタグで書いていただけるととても嬉しいです笑
(ハードル高そうに見えてしまうかもですが、ラフな内容でも良いので他の方のPRDを見てみたいです！🙏)




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