PRD(プロダクト要求仕様書)とは
製品ビジョンの共有に必要となり、密なコミュニケーションとチームに合ったドキュメントが必要となる
製品を作るために必要な全ての工数を記載する
また、プロジェクトの背景などもあれば記載し、複数名でも共有可能なものとする
最大の目的は、ユーザが製品をどのように利用するのかのストーリーを伝えることであり、技術的な詳細はあまり書かれない
Product Requirements Document : 製品要求仕様書
一言で表すなら、開発関係者でプロダクトの前提や認識を合わせ、意思疎通するためのもの
役割として大事な部分は認識を揃えること
大きくは
- Why: なぜ開発するのか
- What: 何を開発するのか
- How: 開発をどうやって実現するのか
Why: なぜ開発するのか
プロダクトの目的や意義、背景となり、そもそもなぜ開発をするのかを明確にする
- ターゲットユーザー
- プロダクトのユーザーは誰か
- どんな人が使いたいと思うか、使ってもらいたい人は誰か
- 問題設定
- そのユーザが抱えている問題は何か
- 気づいていない存在的な問題は何か
- ソリューション
- その問題に対して我々はどうやって解決するか
- 提供価値
- ソリューションが提供されれば、ユーザの視点から見てどのような価値があるのか
問題設定とソリューションに関連して、「なぜ今か」を明確にする
プロダクトを世に出すタイミングとして適切かどうか
また、ソリューションの部分では自分たちの優位性は何かを書いておく
他社では簡単に真似できず、自分たちが持つソリューションの源泉は何か
What: 何を開発するのか
開発するものを明確にする
- プロダクトの完成イメージ
- UI・デザインモックなど
- 機能
- 必要なリソース
- データなど
- 前提条件や想定リスク
前提条件ではプロダクトを開発するにあたり、何が所与になっているのか
開発が計画通りに進まない場合は、何かの前提が間違っていたこととなる
あらかじめ前提条件を明確にし、開発は何に依存しているのかを書いておく
同じ観点から想定リスクを挙げておく
リスクとは具体的には戦略リスク、市場環境リスク、運用リスク、法務リスク、財務リスクとなる
How: 開発をどうやって実現するのか
開発をどのように進めるかも書いておく
ただし、Howの詳細はドキュメントに分けておく
PRD作成の責任者はPMであることに対して、スプリントをどう走らせるかの詳細の開発方針を決めるのは開発リードエンジニアとなる
PRDは実際に手を動かすエンジニアに渡され、エンジニア側でPRDの内容を受けて開発計画を立てる
- ゴール設定
- ゴールを達成したかどうかを測定するKPI設定
- KPI測定に必要なイベントログ定義
- 開発のスケジュール
- 他の資料のリンク
- UXフロー、モックなど
PRDはあくまでも手段
PRDは、コミュニケーションドキュメントとなり、開発するプロダクトの最新情報が一元化され、開発者の認識を合わせるもの
注意したいのは、あくまでも手段だということで、目的はユーザの問題を解決し、価値を提供するプロダクトを創り出すこと
Discussion