Free Image on Pixabay
ビジネスでのプロダクト開発についてです。
開発に責任を持つプロダクトマネージャー (PM) と、開発にあたって必要になる製品要求仕様書 (Product Requirements Document: PRD) について書いています。
エントリー内容です。
- プロダクトマネージャーの役割
- 製品要求仕様書 (PRD) 。PRD に書くこと
- PRD はあくまで手段
プロダクトマネージャーの役割
プロダクトマネージャー (PM) とは一言で言えば、｢開発するプロダクトを定義し、開発を主導する人｣ です。
そのために PM に求められるのは、以下があります。
- 決められる
- 関係者と合意形成をする
- 市場を見極める。ユーザーと対話をする
それぞれについて補足します。
[PM の役割 1] 決められる
開発するプロダクトを定義するためには、決められるかどうかが問われます。
決めるためには、｢やらないこと｣ を明確にする必要があります。何をやって、何をやらないかの判断軸があるかです。そして、判断軸に沿って関係者からの開発要求に時には No を言えるかどうかです。
PM には決断力が求められます。
[PM の役割 2] 関係者と合意形成をする
PM は社内では関係者とのハブになる役割を担います。
関係者とは、開発エンジニアやデザイナー、営業 (新規顧客開拓担当 (BD) も含む) 、マーケティング、広報 (PR) 、場合によっては経営陣です。
開発するプロダクトの関係者が多岐に渡っても、関係者と対話によって合意形成をし、どんな目的で何を開発するかの定義を決めます。
[PM の役割 3] 市場を見極める。ユーザーと対話をする
開発するプロダクトを定義するためには、そのプロダクトに市場性があるかどうかを見極める力が問われます。
開発前や初期の段階では、創ろうとしているプロダクトはまだ形になっていません。存在していないプロダクトであっても必要なのは、想定する市場規模、競合、ターゲットユーザーの理解です。
開発プロセスの中で、プロトタイプ (試作品) をユーザーに使ってもらい、積極的にフィードバックを得ます。ユーザーからの声や、使っている最中の振る舞いや声にならない表情などの間接的なフィードバックも捉えるようにします。
得られたフィードバックは開発メンバーと共有し、自分たちにとっての意味合いを見い出し、開発に活かします。
製品要求仕様書 (PRD)
開発するプロダクトの情報を社内で共有するために欠かせないものが、PRD です。
PRD とは
PRD とは Product Requirements Document の略で、日本語にすれば製品要求仕様書です。
PRD は、開発するプロダクトの定義を書面に落とし込んだものです。プロダクトに関する情報は、PRD に一元化されます。
なぜ PRD は必要なのか
PRD の役割を一言で言えば、開発関係者でプロダクトの前提や認識を合わせ、意思疎通をするためです。
直接関わる開発メンバーだけではなく、社内関係者で開発するプロダクトの情報を共有し、認識に齟齬が起きないようにします。共有する範囲は、先ほどの関係者として挙げた、開発エンジニアやデザイナー、営業･BD 、マーケティング･PR 、経営陣などです。
PRD に書くこと
PRD の役割は、プロダクトの開発背景や前提、認識をそろえることです。PRD に書かれるのは、エンジニアに向けた開発仕様だけではなく、前提から書き込みます。
大きくは、以下の3つのフレームで構成されます (なお、ここでご紹介する内容はあくまで私が業務で書いている PRD についてで、人によって･会社によって異なります) 。
- Why: なぜ開発するのか
- What: 何を開発するのか (狭義の定義)
- How: 開発をどうやって実現するのか
以下、それぞれについて補足します。
[PRD の内容 1] Why: なぜ開発するのか
開発するプロダクトの目的や意義、背景です。そもそもなぜ開発をするのかです。
私がよく使うのは、以下の4つのフレームで開発する目的を整理します。
- ターゲットユーザー：プロダクトのユーザーは誰か。どんな人が使いたいと思うか、使ってもらいたい人は誰か
- 問題設定：そのユーザーが抱えている問題は何か。彼ら･彼女らが気づいていない潜在的な問題であっても、解決したいと思う問題は何か
- ソリューション：その問題に対して自分たちはどうやって解決するか (プロダクトがどのように解決するか)
- 提供価値：ソリューションが提供されれば、ユーザーの視点から見ればどのような価値があるのか
2つめと3つめの問題設定とソリューションに関連して、｢なぜ今か｣ を明確にします。プロダクトを世に出すタイミングとして、早すぎず遅すぎない、今が適切な時かどうかです。
また、ソリューションの部分では、自分たちの優位性は何かを書いておきます。他社では簡単には真似できなく、自分たちが持つソリューションの源泉は何かです。
[PRD の内容 2] What: 何を開発するのか
開発するプロダクトは何かを明確にします。具体的には以下の項目からです。
- プロダクトの完成イメージ (UI デザインモックアップなど)
- 機能
- 必要なリソース (インポートデータなど)
- 前提条件や想定リスク
4つめの前提条件では、プロダクトを開発するにあたって何が所与になっているのかです。開発が計画通りに進まない場合は、何かの前提が間違っていたことになります。
あらかじめ前提条件を明確にし、開発は何に依存しているのかを書いておきます。
同じ観点から、想定リスクを挙げておきます。リスクとは具体的には、戦略リスク、市場環境リスク、運用リスク (プロダクトが導入された際のビジネスフローにおいて) 、法務リスク、財務リスクです。
[PRD の内容 3] How: 開発をどうやって実現するのか
開発をどのように進めるかも PRD には書いておきます。ただし、How の詳細は別のドキュメントに分けます。
PRD 作成の責任者は PM であることに対して、スプリントをどう走らせるかの詳細の開発方針を決めるのは開発エンジニアリードです。PRD は、実際に開発の手を動かすエンジニアに渡され、エンジニア側で PRD の内容を受けて開発計画を立てます。
PRD で書く項目は以下です。
- ゴール設定
- ゴールを達成したかどうかを測定する KPI 設定
- KPI 測定に必要なイベントログ定義
- 開発のスケジュール
- 他の資料のリンク (例: UX フロー、モックなど)
PRD はあくまで手段
PRD は、コミュニケーションドキュメントです。開発するプロダクトの最新情報が一元化され、関係者の認識を合わせるものです。
注意したいのは、PRD はあくまで手段だということです。目的は、ユーザーに愛されるプロダクトを開発することです。ユーザーの問題を解決し、価値を提供するプロダクトを創り出すことです。
手段の目的化が起こらないよう、注意が必要です。
まとめ
最後に、今回のまとめです。
- プロダクトマネージャーの役割：決められること、関係者と合意形成ができること、市場を見極めユーザーと対話ができること
- PRD に書くこと：製品要求仕様書 (PRD) は開発関係者でプロダクトの前提や認識を合わせ、意思疎通をする。PRD に書くことは以下
- Why: なぜ開発するのか
- What: 何を開発するのか
- How: 開発をどうやって実現するのか
- 手段と目的：PRD はあくまで手段。目的はユーザーに愛されるプロダクトを開発すること。ユーザーの問題を解決し、価値を提供するプロダクトを創り出すこと