元エンジニアPMのプロダクトマネージャーお役立ち情報

スタートアップから大規模プロダクトまで担当している元エンジニアの筆者が、事業開発・プロダクトマネジメントに役立つ情報を発信します

【ジュニアPM向け】プロダクトフェーズ別PRD(プロダクト要求仕様書)の書き方

プロダクトマネージャーにとって切り離せない業務の1つがPRD(Product Requirements Document)になります。先輩のPMからこの企画のPRDを書いておいて!みたいな依頼を受けて何を書けば良いのか困った方もいらっしゃると思います。

筆者はスタートアップから成熟したプロダクトまで、色んな場面でPRDを作成してきました。今日はジュニアPM向けにPRDの書き方・ポイントを説明していこうと思います。

そもそもPRD(Product Requirements Document)とは

PRDは、製品やサービスを開発するために必要なすべての情報を含んだ文書です。

日本語ではプロダクト要求書・製品要求仕様書と呼ばれたりもします。PRDには、製品やサービスの目的、要件、機能、デザイン、ユーザーのニーズなどが含まれます。PRDは、開発チームのみならず、製品管理、マーケティング、財務、法務、顧客サポートなどの部署とのコミュニケーションに役立たせるために書くものだったりします。

 

PRDの陥りがちな罠

PRDで何を書けばよいのか?

実際にPRDを書く際どんな内容を書けばよいのでしょうか。プロダクトマネージャーで有名な及川さんが書いている記事にPRDに何を書けばいいのか?が書かれていますが、手厚いPRD、一番最初に書くものとしてはハードルが高いものかなと思っています。

tannomizuki.hatenablog.com

  1. 概要

  2. 背景

  3. プロダクト・プリンシプル(プロダクト原則)

  4. スコープ

  5. 対象ユーザー

  6. ユースケース

  7. 市場分析

  8. 競合分析

  9. 機能要求

  10. UX要求

  11. システム要求

  12. セキュリティ要件

  13. プライバシー要件

  14. パフォーマンス要件

  15. リリーススケジュール・マイルストーン

  16. マーケティング計画

PRDの書き方はプロダクトフェーズやメンバーによって変わる

PRDの重要な目標はプロダクト開発メンバー全体に”誰向けに何をなぜ作るのか”を適切に伝えることです。

もちろん上記の内容すべてを網羅して記載できることが望ましいですが、プロダクト開発メンバーの数やステークホルダーに合わせて内容量に差があっても問題ないと筆者は考えます。

 

プロダクト立ち上げフェーズのPRD

主にスタートアップや、組織内での事業立ち上げがこのフェーズに該当します。

この場合大事なのは、誰向けに何を作るのかと、どこまでのスコープを指すかを明記するのが重要です。ありがちなPRDの失敗点としては機能が大量に盛り込まれてしまっておりリリースまで数年かかるレベルのものを書いてしまうこと。顧客にどんな価値を提供するのか、それはミニマムな機能だとどこまでなのか?(Must Haveはなにか?)を意識して書くと良いです。

個人的には如何の内容が盛り込まれていれば問題ないと考えます。もちろんUXをどうするかのイメージやシステムとしてどこまでを求めるか?が書かれているとベストではありますが、UXはプロトタイプして変わっていくので初期段階で作り込む必要がすくない。(手戻りが多い)、システム要求が高すぎてもリリースしたらトラフィックが想定より少ないなどが存分にあり得るためです。

  • なぜ作るのか(市場動向・背景
  • ターゲット(ペルソナレベル、マーケット)
  • 何を作るのか
  • どこまで今回作り込むのか

プロダクトリリース後改善フェーズのPRD

このフェーズになると、ある程度市場などは見えてきていると思います。ここで大事なのは、今ターゲットに起きている課題と、ユースケース、そして何を作るか、どう届けるか?です。

リリースしたプロダクトを実際に触ったユーザーからこんな声が上がってきている、データとしてこの数字の伸びが弱い。直面している課題をプロダクト開発チームに適切にインプットし、何を作るかの方針をまとめられれば大丈夫です。ユースケースが想定よりも広がってきている場合や新しい体験を提供する場合は、その旨も明記しましょう。

  • なぜ作るのか(課題背景
    • 定量 / 定性それぞれあるとよし
  • ターゲットとユースケース
  • 何を作るのか
  • どう届けるのか

プロダクトリリース後、黙っていても中々ユーザーは付いてきません。ユーザーに対してその機能をどう見せるか?どう訴求するかもまとめておくことが重要です。機能先行で、ユーザーに機能が届いていないケース多々あります。

プロダクト安定期フェーズのPRD

この時期になると何を作るのかに加えてリリースした際の影響も気にする必要が出てきます。セキュリティやトラフィック上の問題はないのか?法務観点でのケアはクリアできているのか、ユーザーに不利益が生じないのか?徐々にPRDが手厚くなってきます。

  • なぜ作るのか
  • ターゲットとユースケース
  • 何を作るのか
  • セキュリティ・プライバシー・リーガルで何を気にするのか

まとめ

あくまで一例ではありますが、PRDの書き方・ポイントを簡単に説明してみました。もちろんプロダクトフェーズだけではなく、プロダクト開発チームのスキルセットにも依存します。例えばシステム設計もしっかり考えるエンジニアがいれば、そこの部分はおまかせして良いですし、UX体験などはデザイナーに委ねても大丈夫です。マーケティング担当がいれば、その領域はPMMにお任せしてしまっても良いと思います。

PRDの項目すべてを完璧に書けるプロダクトマネージャーは極少数ですので、頼れるところは頼りなぜ、何を、誰に作るのか?を大事にするのが大切かなと思います。参考にしてみてください。