プロダクトマネージャーの7つ道具「PRD」が曖昧すぎるので言葉の定義から見直してみた
📚これは何か
プロダクト開発の現場でよく使われるPRD（プロダクト要求仕様書）について、言葉の定義から見直すことで、PRDとは一体何か、どうすればPRDが実践に耐えうるものになるのか、ということについて書かれたnoteです。
💡こんな方におすすめの記事
・PRDがそもそもわからない/PRDを書いたことがない人
・PRDを書いても、上手く活用できず悩んでいる人
・プロダクトマネージャーに興味がある人
みなさん、こんにちは。
Voicyでプロダクトマネージャー（以下、PdM）をしているとくちゃん（@PdMtokuchan）です。
昨今、PdM界隈では、様々なフレームワークや文書テンプレートなどが無料で公開されていて、”それっぽい何か”が誰でも簡単に作れる状態にあります。
しかし、きれいなテンプレートに当てはめて文書を作成しても、なぜかうまくいかない...そんな状況にこれまでたくさん遭遇してきました。
今回は、プロダクト要求仕様書｜Product Requirements Document（以下、PRD）について、言葉の定義から整理をして、どうすれば実践に耐えうる文書を作ることができるのか、考えてみたいと思います。
PRDとは何か
まずはPRDの辞書的な言葉の定義として、IT用語辞典を参照します。
PRD 【Product Requirements Document】 製品要求仕様書 / プロダクト要求仕様書
PRDとは、製品の開発を始めるにあたり、どのような製品を作るのかを定義した文書のこと。製品開発プロジェクトの責任者（プロダクトマネージャなど）によって作成され、基本方針として関係者間で共有される。
要素分解すると
製品開発プロジェクトの責任者（プロダクトマネージャなど）によって作成され
どのような製品を作るのかを定義した文書
基本方針として関係者間で共有される
つまり、
PRDの定義ver1.0
PdMが書いた / 関係者と共有されている / どのようなプロダクトを作るか定義した文書
がPRDということですね、シンプル。
まずは、これをベースにPRDを深掘りします。
PRD導入の背景
私がVoicyに入社したのは2023年5月ですが、その時点で仕様について書かれた文書がなかったわけではありません。ただ、Confluenceや、asana、slack、Figmaなど様々な場所にプロダクトに関する情報が散らばっていて、どれが最新の情報か判断することが難しい状況にありました。
この状況、私も過去に何度か経験したことがあり、前節のPRDの定義にもう一つ要素を追加する必要があるなということで、以下PRD定義を更新して、チームに導入することを検討し始めました。
PRDの定義ver1.1
PdMが書いた / 関係者と共有されている / どのようなプロダクトを作るか定義した / たった一つの文書
なんか良さそう。
では次節、この4要素を満たしたPRDとは一体何か、について。
要素1「PdMが書いた」とは
PdMが書いた、とはなんだろうか。
「はい、じゃあPdMさん、PRD書いてくださいね」で終わりな気もするけれど。一応ちゃんと考えてみましょうか。
まず、「書く」とは一体何か、ですね。デジタル大辞泉を参照してみました。
か・く【書く／描く／▽画く】
１ （書く）文字や符号をしるす。「持ち物に名前を―・く」
２ （書く）文章を作る。著す。また、著作する。「日記を―・く」「本を―・く」
何だが気になるワードが出てきました、「著」
精選版 日本国語大辞典ではこのように説明されています。
しる・し【著】
① はっきりしている。他からきわだっている。明白である。いちじるしい。
少し見えてきた気がしますね、つまり
明白な文字や符号を記すことが「書く」ということで、その明白さにPdMが責任を持つことが「PdMが書いた」ということ、と言えそうです。
これ、解釈を広げると、書く人は必ずしもPdMである必要はない、と私は考えていて。
例えば、開発を進める中で、ある項目について加筆修正する必要性が出たときに、いちいちチームメンバーからPdMに伝達してPdMが更新するのは伝言ゲームになりやすいし、面倒ですよね。
なので、書かれた内容をPdMが把握し、その明白さに責任を持てるのであれば、PRDはPdMが書いてもチームメンバーが書いてもよいのです。
弊社も開発進行時にチームメンバーがPRDを更新するときは、slackでPdMに共有し、その内容を都度確認し受け取るようにしています。
「PdMが書いた」のまとめ
PRDの明白さにPdMが責任を持つことが「PdMが書いた」ということ
PRDに書かれた内容をPdMが把握し、その明白さに責任を持てるのであれば、PdMが書いてもチームメンバーが書いてもよい
「PdMが書いた」のアンチパターン
PdM以外の誰かが追記した内容をPdMがキャッチアップできていない
曖昧な表現で読み手によって理解が変わってしまう内容になっている
要素2「関係者と共有されている」とは
「関係者」と「共有」をそれぞれ整理してみます。
「関係者」はそこまで難しく考えず、「そのプロダクトに関係する人」と捉えて差し支えないかと思います。ただし、関係者の中でも共有するレベルの違いがあることに注意が必要です。
ここで、プロジェクトマネジメントに関する知識を体系的にまとめた参考書「PMBOK」で言及されているステークホルダーマネジメントのマトリクスを参照してみましょう。
関係者のタイプは以下の4象限に整理できそうです。
ステークホルダマネジメントが気になる方は、出典を参照してください。
開発時に注意すべきは、関心度の高い第1,4象限の関係者でしょう。
例えば、スクラムチームのメンバーは第4象限の「常に情報を伝える人」にあたります。どんなに小さな変更点や決定事項でも、余計な不安や衝突を避けるため、なるべく早くこまめに共有する必要があります。
また、直属の上司や事業部長などは第1象限の「注意深くマネジメントする人」にあたります。彼らには、複数のプロジェクトを同時進行しているケースが多く、普段から時間がありません。なので、適切な情報量と適切なタイミングで共有する必要があります。ここは一番難しく繊細なコミュニケーションが求められますが、個人的には少し過剰と思われるくらい日々細かく共有しておいた方がスムーズなのではないか、と考えています。
では「共有」とは一体何を意味しているのか。
デジタル大辞泉ではこのように定義されています。
一つの物を二人以上が共同で持つこと。
私は、この定義がPRDを曖昧にし、運用が上手くいかなくなる原因の一つではないか、と考えています。
例えば、notionで書いたPRDのURLをスクラムメンバーにslackで送ったら、それは共有と言えるのでしょうか。たしかに言葉の定義上は、そのURLを受け取った時点で「共同で持っている」ように見えます。しかし、日々大量のチャットが飛び交うslackで文書のURLを共有されても、見過ごしてしまったり、読んでもよくわらかないままブラウザを閉じてしまった経験はないでしょうか。
そう考えると、共有ではなく「同期」の方が意味としてはしっくりくる気がしています。
作動の時間を一致させること。内容や情報を一致させること。シンクロナイズさせること。
つまり「関係者とPdMが持っている情報を一致させること」が、本当は大事なのではないでしょうか。
そう考えると、slackでURLを送るだけでは不十分な気がしますね。弊社では、日々slackベースでの共有だけでなく、週に一度、PRDの差分を共有する時間を設けています。同じ文書を何度も何度も繰り返し読み合わせ、疑問に感じることを質疑応答していくことで、初めてPRDの内容が「同期」されると考えています。
ということで、PRDの定義もここでアップデートしましょう。
PRDの定義ver1.2
PdMが書いた / 関係者と同期されている / どのようなプロダクトを作るか定義した / たった一つの文書
「関係者と同期されている」のまとめ
関係者には関心度軸と権力軸でわかれた4タイプの属性があり、それぞれ適切な伝え方が異なる
単に情報を共有するだけではなく、関係者と持っている情報を一致させる必要がある
「関係者と同期されている」のアンチパターン
slackでPRDのURLだけ共有されていて、関係者と同期できていない
関係者と日々同期をしておらず、現場から不満や疑心暗鬼な気持ちが生まれている
要素3「どのようなプロダクトを作るか定義した」とは
ここは多くのテンプレートや考え方が共有されており、参考になる情報が多いパートです。その分、手段に振り回されやすく、注意が必要なところでもあります。
まずは、世に公開されているPRDのテンプレートからいくつかピックアップし、使われている項目を整理してみました。
参考にしたPRDテンプレートや記事
Notion (ノーション) – Notion's PRD - テンプレートギャラリー
プロダクトマネージャーに訊く #9：Increments及川さん - 小さなごちそう
How to Write a Painless Product Requirements Document | by UXPin | Medium
PRDで検索して上位でヒットした情報を3つ整理しただけでも、これだけ項目にばらつきがある状態です。各社、自分たちに適したPRDを模索して調整しているんだろうなと推察します。それよりNotionのそぎ落とし具合にはちょっとびっくりしますね...
これらの項目をベースに、今のチームに何が必要なのか再検討した結果、私のチームでは以下の項目で整理をしました。
いくつか項目を追加/削除して、全部で13項目のPRDになりました。他社が使っている項目も、どれも大切だよなあと思いつつ、"今の"チームにおいて重要なものは何かな？と考えて、整理をしています。
既存の項目は参考記事にお任せするとして、追加した赤字部分について、内容と目的を説明します。
定性・定量根拠
このプロダクトを開発する根拠を記述する項目です。
チームメンバーだけでなく、他部署のメンバーからも「なぜこのプロダクトを、今作る必要があるのか」といった根拠を定性・定量の両面から示すことで、成功確度とメンバーの納得感を醸成することが目的です。
ユーザストーリー
ユーザストーリーを記述する項目です。ここではアジャイルコーチで説明されているユーザストーリーの定義を参照しました。
「私がAなら、Bしたい。なぜならCだから。」ユーザストーリーにしてユーザを記述することで、このプロダクトは誰のために存在し、それはなぜ必要とされているのか簡単に記述することで、できるだけ簡単に対象ユーザのイメージを持つことが目的です。
期待するアウトカム
このプロダクトで期待されるアウトカム、ヒットするKPIを記述する項目です。
このプロダクトが具体的に全社で追っているどのKPIにヒットするのか明文化することで、チームメンバー全員でKPIを意識したプロダクト開発をすることが目的です。
モニタリング
このプロダクトをリリースしたあとに、何をモニタリングするか記述する項目です。
何をどんな目的でモニタリングするのか明文化することで、データチームとの連携をスムーズにし、認識のずれをなくすことが目的です。また、期待するアウトカムで設定したKPIが正しく計測できるかどうか、ここで振り返ります。
受け入れ条件
このプロダクトが何を持って完成したかの条件を記述する項目です。一般的にはバックログアイテムごとに記載をするケースが多いと思いますが、今回のチームではPRD単位で受け入れ条件をまとめて整理することにしました。
何を持って完成したかの条件を設定することで、このプロダクトにおけるユーザストーリーが満たされているか確認することが目的です。
やらないこと
このプロダクトを開発する上で、やらないことを記述する項目です。
やらないことを明文化することで、余計なことにマインドシェアを割かずゴールに集中しやすい状況をつくることが目的です。例えば、アプリとWebの両方提供しているサービスが、今回の開発ではWebはやらないのに、「Webはやらない」ということを明言しないことで、「Webの体験設計も考えとかなきゃか？」「Webも考慮した仕様を考えとくか」と、エンジニアやデザイナーのマインドシェアを余分に奪ってしまう可能性があります。
プロジェクトメンバー
このプロダクトを開発する上で、関係者を記述する項目です。
関係者を明文化することで、コミュニケーションを円滑にすることが目的です。開発するメンバーはある程度固定された人になりますが、BizDevやCSなど、開発以外の関係者はプロダクトによって様々です。「関係者と共有されている」の節でも解説した通り、関係者のタイプによってコミュニケーションの方法も少し変える必要があるため、PRDに明記しておくとよいでしょう。
Q&A
PRDの内容について、関係者内で発生したQ&Aを記述する項目です。
関係者の中で生まれる疑問とそれに対する回答を可視化することで、同じQ&Aのやりとりが発生する頻度を減らすことが目的です。slackや議事録など、PRDの外で発生したQ&AはURLを貼り付けておくとよいでしょう。
以上です。
このPRDで運用し始めてまだ2ヶ月ですが、実践していく中で調整が必要なものもありそうだなあと思っています。うーん、難しい。
「どのようなプロダクトを作るか定義した」のまとめ
PRDは各社フォーマットがバラバラである
自社に適応可能な項目をピックアップし、必要あれば項目を追加して、自社にフィットするPRDを作ると良さそう
とはいえ、チームやプロダクトの状態によっても変わりそうなので、PRD自体も変化していくことを許容すると良さそう
「どのようなプロダクトを作るか定義した」のアンチパターン
とりあえず他社が公開しているPRDをそのまま使う
チームやプロダクトの状態・フェーズが変化してもPRDをアップデートしない
要素4「たった一つの文書」とは
ついにここまできました。ちょっと長かったな。
文書については、もういいですよね。飛ばします。
ここでは「たった一つ」について考えてみましょう。
これは、辞書から引用するまでもなく、「ただ一つであること」という意味です。当たり前すぎる話ですが、あるプロダクトについて書かれたPRDが複数あってはいけません。
ありそうなアンチパターンとしては、「PRD_ログイン機能_v2」みたいに、ファイルを複製することでバージョン管理を行うパターンでしょうか。さすがにそこまでお粗末な運用をしているところはないと思いますが…
もう一つ、ありえそうなアンチパターンとして「PRDとしてはファイルは1つだけど、そのプロダクトに関する情報が散らばっていて、どこにあるかわからない」という問題があります。例えば、Figmaで作ったデザインファイル、スプレッドシートで作ったユーザセグメントに関する集計データ、などなど。機能に関する情報というのは様々なアプリケーションで作成されることが一般的かと思います。
これらの情報も含めてプロダクト開発を行うのであれば、PRDにもそれらの情報もまとめてリンクしておくことが重要、と言えそうですね。それではPRDの定義も、ここでアップデートしましょう。
PRDの定義ver1.3
PdMが書いた / 関係者と同期されている / どのようなプロダクトを作るか定義した / プロダクトに関する情報が集約された、たった一つの文書
「たった一つの文書」のまとめ
PRDが複数あってはいけない
プロダクトに関する情報はすべてPRDにまとめておくと良い
「たった一つの文書」のアンチパターン
PRDのバージョン管理をファイル複製で行い、PRDが複数存在している
PRD以外のプロダクトに関する情報が散らばっており、PRDを見ただけでその情報に辿り着く手がかりがない
振り返り
おさらいします。
言葉の定義から見直した結果、PRDとは、以下と再定義しました。
PdMが書いた / 関係者と同期されている / どのようなプロダクトを作るか定義した / プロダクトに関する情報が集約された、たった一つの文書
各要素をまとめると、以下になります。
「PdMが書いた」のまとめ
PRDの明白さにPdMが責任を持つことが「PdMが書いた」ということ
PRDに書かれた内容をPdMが把握し、その明白さに責任を持てるのであれば、PdMが書いてもチームメンバーが書いてもよい
「関係者と同期されている」のまとめ
関係者には関心度軸と権力軸でわかれた4タイプの属性があり、それぞれ適切な伝え方が異なる
単に情報を共有するだけではなく、関係者と持っている情報を一致させる必要がある
「どのようなプロダクトを作るか定義した」のまとめ
PRDは各社フォーマットがバラバラである
自社に適応可能な項目をピックアップし、必要あれば項目を追加して、自社にフィットするPRDを作ると良さそう
とはいえ、チームやプロダクトの状態によっても変わりそうなので、PRD自体も変化していくことを許容すると良さそう
「たった一つの文書」のまとめ
PRDが複数あってはいけない
プロダクトに関する情報はすべてPRDにまとめておくと良い
いかがでしたでしょうか。
PRDを言葉の定義から見直していくことで、PRDとは一体何なのか、理解が深まった気がします。また、既存の定義では不十分であったり、自分たちのチームには合わないかもしれない、といった発見もありましたね。
普段何気なく使っている言葉やフレームワークなど、見直していく作業は簡単なことではありませんが、一つ一つ振り返り、改善していくことで、より良い仕事に繋がっていくのではないでしょうか。
チームメンバーにフィードバックをお願いしてみた
最後に、独りよがりなPRDになってはいけないと思い、チームメンバーにもフィードバックをお願いしてみました。参考になる意見をいただけたので、早速PRDのアップデートに役立てていきたいと思います。
良い点
定量も定性も観点抑えられていて、開発者としてはやることや何を対象とした施策なのかが明瞭に落とし込まれていると思います。
PRDいいと思います！みんなで作ってる感じがする。
とてもよい。なんのために作るのか書かれているし、Figmaなどのリンクもまとまっていて見やすい。
いつ変更したのかの履歴も残ってるのはいい。
一個にまとまってるのがいい
改善点
自戒なのですが、PRDの読み込みが足りないなと感じています。
自分ごととしてディスカッションできればなと思う反面、直近やることが色々あるうちは学びや知見を蓄積する時期と捉えて、徐々にWhatの部分でも活発な意見交換できればなと思います。
既存機能に新たに機能を追加する場合は、今は既存機能のPRDがないので、事前に作りたい
PRDの加筆or削除があったときに、その差分がパッとわかるとより良いと思う。
フィードバックをくれたみんな、ありがとう！
@entaku_0818 / @numaMyk / @saicologic
Voicyは仲間を探しています
Voicyでは全職種で仲間を募集しています。
採用情報は以下のページに一通りまとまっているのと、
個人的には「声の求人票」がおすすめです。文字通り、"社員の声"で求人内容について解説していて、Voicy社員の雰囲気も伝わるかなと思います。
その他、気になることがあれば、私とくちゃんのTwitter（@PdMtokuchan）までご連絡ください。今回のPRDの話や、プロダクトマネージャーの話など、なんでもウェルカムです👍
それでは👋
この記事が気に入ったらサポートをしてみませんか？