このテンプレートを使用してください
ほとんどのPRDは読まれません。しかし、優れたPRDプレゼンテーションなら見られます。Trupeerなら、無料のPRDプレゼンテンプレートから始めて、ブランドガイドラインでカスタマイズし、ステークホルダーの理解を素早く揃える動画ウォークスルーとしてPRDを変換することで、PMのコミュニケーションにかかる時間を何時間も節約できます。
PRDプレゼンテーションとは何か、PRDとはどう違うのか？
プロダクト要件ドキュメント（PRD）は、何を、誰のために、そして「完了」とみなすために何が真である必要があるのかを定めます。これは、それを作るチーム向けに書かれ、詳細であり、プレゼンされるのではなく読まれます。
一方、PRDプレゼンテーションは別の成果物で、別の役割があります。プロダクトレビュー、ステアリンググループ、またはエグゼクティブフォーラムで意思決定を得るために持っていく、少数のスライドです。そして、ドキュメントの内容のほとんどを含めるべきではありません。
それらを混同するのが、よくある失敗です。デッキはページ番号付きのドキュメントになり、会議はページごとのウォークスルーになり、会議が本来作るはずだった意思決定が行われません。
必要なのがドキュメントそのものなら、こちらのリーンPRDテンプレートで構造をカバーしています。どの要件を制約すべきか、どれをチームに委ねるかも含めて説明します。このページでは、他の人の前で行う20分を扱います。
部屋はあなたの要件を評価できない
プロダクトレビュー会議について、誰も言わないことがあります。
部屋にいる人たち、つまりエグゼクティブ、商業面のリーダー、部門の責任者は、要件14が正しく指定されているかを判断できません。顧客と話していない、サポートチケットを読んでいない、システムを知らない。そして、他の5つの項目と一緒に並べられた枠で、初めてその資料を見るのです。
それは彼らへの批判ではありません。委任とはそういうことです。彼らがやらなくて済むように、あなたにその作業を頼んだのです。
しかし、31個の要件を見せられた部屋は、何かには反応します。レビューとはそういうものだからです。そして反応するのは、本当に評価できる範囲のことです。プロダクト名、チャートの色、顧客が本当にそれを望んでいるか、リリース日、そしてエクスポートはCSVかXLSXか。
だから、要件だらけのデッキは、要件そのものの精査を生みません。要件の隣にあるあらゆるものの精査を生みます。権威をもって提示され、さらに「自分が貢献した」と感じて、その貢献が尊重されることを期待する人たちによって。
デッキの役割は、部屋が判断できることだけを提示することです。
Trupeerでこのテンプレートをカスタマイズする方法
ステップ1：テンプレートセクションを開く
メインナビゲーションからテンプレートセクションへ移動します。
ステップ2：テンプレートを選択して開く
作業したい任意のテンプレートをクリックして開きます。
ステップ3：テンプレートビューを展開する
必要に応じて、テンプレートビューを展開し、レイアウトと詳細をはっきり確認します。
ステップ4：テンプレートを編集する
編集をクリックして、選択したテンプレートの変更を開始します。
エディター内で、次のことができます：
新しいセクションを追加
書式ルールを定義または更新
ロゴを追加し、その位置および関連設定を調整
ステップ5：カスタマイズしたテンプレートを保存する
必要な変更をすべて行ったら、保存をクリックして更新されたテンプレートを自分のものとして保存します。
ステップ6：プレビューしてテンプレートを微調整する
カスタマイズしたテンプレートがどのように見えるか確認したいときは、プレビューを開きます。
プレビュー画面から、必要に応じて直接調整を続けることができ、テンプレートが希望どおりに表示されることを確認できます。
PRDプレゼンテーションテンプレートでできること：
執筆にかかる時間を節約：プロダクトコミュニケーション用に構成された空白ページをスキップできます。
ステークホルダーの理解を素早く揃える：エグゼクティブとエンジニアが必要とする内容を内蔵セクションでカバー。
ブランドに沿った見た目を維持：Trupeerのブランドキットでロゴ、フォント、カラーを適用します。
より良い意思決定を促進：密度の高いPRDを、誰もが理解できる動画ウォークスルーに変換します。
プロダクト間で標準化：すべてのPRDレビューで同じテンプレートを使用します。
グローバルチームに対応：1クリックでPRDを65以上の言語に翻訳します。
プロダクトレビューの場で実際に決められること
部屋が決められること | 部屋が決められないこと | それが属する場所 |
|---|---|---|
そもそも今やるかどうか | 要件14が正しく指定されているかどうか | チームがレビューするPRD |
同じ人材をめぐって競合する他の仕事と比べて、どの順位か | どの技術アプローチが正しいか | エンジニアリング（チームとともに） |
金銭と時間の両面で、どれくらいのコストが許されるか | エラーメッセージの文言が適切かどうか | この会議の範囲ではない |
作るのではなく買うかどうか | データモデルがそれを支えられるかどうか | 技術設計レビュー |
2つの良いものが衝突するとき、どのトレードオフを受け入れるか | 受け入れ基準がテスト可能かどうか | チームとQA |
リスクプロファイルが許容できるかどうか | エクスポートファイルの形式 | チーム（そしてすでに委任されている） |
左の列だけをもとにデッキを作りましょう。各スライドはそこにある何かに対応している必要があります。そこに対応していないスライドは文脈であり、会議ではなく事前読みに属します。
トレードオフの行は、プロダクトマネージャーが使いすぎない領域です。エグゼクティブは、結果が異なる2つの選択肢の間を選ぶことに本当に長けており、レビューが生み出せる最大の価値です。必然性として装った1つの推奨ではなく、彼らに2つの本物の選択肢を持ってきてください。
意思決定につながる「6スライド」のPRDプレゼンテーション
スライド1：必要な意思決定。 日付付きの1文。「5月4日から、エンジニアリング9週間のコストで、レポーティングモジュールを構築することについて承認を求めています。」議題でも、タイトルスライドでもありません。最初に、誰も他のことについて意見を形成する前に、依頼（ask）を提示します。
スライド2：数字で示す課題。 何が起きているのか、どれくらいの頻度か、そしてコストはいくらか。最大でも1つのチャート。これが依頼を正当化し、証拠が置かれる唯一のスライドです。
スライド3：提案内容。 1段落、必要なら1つの画像。機能一覧ではありません。部屋は中身ではなく、その「形」を理解する必要があります。
スライド4：トレードオフと、却下したもの。 2〜3個の本物の選択肢。採用しなかった選択肢と、その理由も含めます。会議を開く価値を生むのがこのスライドで、ほとんどのデッキが省略しているものです。
スライド5：必要なもの。 人、時間、お金、そしてそれらの人が代わりにやらないこと。機会費用の行が、簡単な「はい」を本当の意思決定に変えます。
スライド6：やらないこと。 この部屋の人たちがこれまでに求めてきたことも含めて、明確に書きます。名前を挙げることで、会議で追加されるのを防げます。
6スライド、15分。そして詳細を知りたい人のために、PRDは48時間前に配布します。
無料のPRDプレゼンテーションテンプレート：コピーすべきスライド
ここからコピー。
タイトルと意思決定。 プロダクトまたは機能名。発表者。日付。必要な意思決定を、日付とコストを含む1つの完全な文として記載。
課題。 観察内容、頻度、コストまたは機会費用。裏付けとなる図1つと、その出典。
提案。 今は存在しないものとして、誰かがチーム外でも繰り返せるように書いた1段落。
トレードオフ。 2〜3行：選択肢、採用したオプション、却下したオプション、各々の結果。
コストとコミットメント。 エンジニアリングの時間、関与する他の機能、お金、そして置き換えられる作業。
範囲外。 これは意図的に含めないもの。出席者が以前に求めたものを含めて、何でも列挙します。
付録（提示しない）。 成功指標、依存関係、リスク、タイムラインの詳細。必要なら依頼に応じて利用可能で、会議では取り上げません。
事前読みにするもの。 PRD本体。少なくとも48時間前に送付し、どの意思決定を求めるのかを示すメモを添えます。
ここまでコピー。機能させるためのルール：提示されるスライドのどこにも、どの要件も登場させないこと。誰かが尋ねたら、「それはドキュメントにある」と答えればよい。そしてそれは良い答えです。
61件のコメントはあるが意思決定がないレビュー
Kirkwall Systemsは、約350人規模のB2Bソフトウェア企業で、四半期ごとにプロダクトレビューを実施していました。プロダクトマネージャーが、新しいレポーティングモジュールのPRDを、34スライドのデッキとして持ち込みました。実質的には、ページ番号付きのドキュメントでした。
部屋には、最高経営責任者、財務責任者、営業の責任者、エンジニアリング、カスタマーサクセスの責任者、そしてエンジニアリングリード2名がいました。75分。
誰かがその後コメントを記録しました。合計61件の質問とコメントです。
そのうち9件は、部屋が決められることに関するものでした。今すぐ作るかどうか、他の2つの取り組みと比べた順位、既存ツールを買うべきかどうか、そして許されるコストはいくらか。
残り52件は、決められないことでした。プロダクト名。モックアップされたチャートの色。顧客が本当にそれを望むかどうかを、根拠のないまま両方向に主張していること。個別の要件の文言。そして、エクスポートをCSVにするかXLSXにするかについての12分間の議論。これは会議で最も長い単一項目であり、PRDはそれをチームの判断として明確にマークしていました。
意思決定は行われませんでした。記録されたアクションは、プロダクトマネージャーが修正して持ち帰る、というものでした。
その3週間後の2回目のレビューでは、28スライド版を使いました。誰も見積もっていなかった範囲追加が2件あり、部屋で合意されて承認されました。
最初のレビューから作業開始までの遅れは6週間でした。見積もられていなかった追加2件は、ビルドにさらに見積もりで5週間を加えることになりました。元々9週間の範囲だった機能は、最初のレビューから納品まで約20週間かかりました。
変更はプロセス変更ではなく、デッキの標準化でした。6スライド、意思決定は最初に、要件は提示しない、PRDは48時間前の事前読みにして配布。
その後の4四半期にわたり、新しい形式で19件のPRDレビューが実施されました。会議の中央値は75分から34分へ短縮。部屋で実際に意思決定が行われた割合は、約40％から89％へ増加しました。そして、会議中に見積もられていない範囲追加が平均1.8件/レビューから3件に1件未満へ減りました。
要件が良くなったわけではありません。問題ではなかったのです。
デッキではなく、PRD本体に入れるべきものは？
デッキが意図的に省くもの、つまり大部分の実質的な内容です。
受け入れ基準。あなたとエンジニアが、それが満たされたかどうかを独立して合意できるように記述します。制約された要件。それぞれに「なぜその形でなければならないのか」の理由を添えます。明確にチームへ委任された領域。範囲外リストを全文で。担当者と日付付きの未解決の質問。そしてリリース後に確認する指標。
私たちのリーンPRDテンプレートでは、この構造を詳細にカバーしています。チームが必ずやるべきことと、チームが決めてよいことを分けるタグ付けの考え方、そしてコストを過剰に指定すると節約できる以上に増えてしまう理由まで含めています。
2つのドキュメントの関係は、はっきり言っておく価値があります。PRDはチームとの契約です。デッキはビジネスへの依頼書です。読者が違い、寿命が違い、詳細度も違います。そして共有すべき唯一の内容は、課題の説明と提案段落です。
プロダクト要件ドキュメント（PRD）の書き方：ステップバイステップ
まず受け入れ基準を書きます。つまり、この先出荷された後に「真になること」で、今は「真ではないこと」を1文で説明します。それが成立しないなら、作業は指定できる状態ではありません。
次に「なぜ今なのか」を2〜3文で書きます。チームが、あなたが決して目にしないであろう100個の小さなトレードオフを作るために使うのが、それだからです。
フィルタせず、すべての要件を列挙し、そのうえで各要件について「答えを本当に気にしているか」を判断します。最初のドラフトでは、著者が実際に意見を持っている以上に、はるかに多くを制約してしまうことがほとんどです。
制約された要件には、すべて理由を付けます。「いつもそうしているから」という理由になるものは、制約ではなく習慣です。
「やらないこと」リストは、まだ人々が何を求めているのかを覚えているうちに書きます。
そして、制約されたリストをエンジニアのように読んでください。なぜそうするのかを尋ねたくなるのに、ドキュメントが答えていない箇所は、理由を追加するか、その行を削除します。
PRD（およびそのプレゼン）を使わないための方法
ステータス更新として。 テーブル上に意思決定がないPRDレビューは、意見が付いた進捗報告になってしまい、会議がないよりも悪い状態になります。
チームと話す代わりとして。 エンジニアが要件を見るのがレビューで初めてだとしたら、そのレビューは場違いであり、相手も違います。
説得のためのドキュメントとして。 承認を取り付けるために書かれたPRDは、不確実性を隠します。チームが本当に見たいのは、まさにそこです。
承認で凍結する。 未解決の質問はビルド中に答えられます。そして変更できないドキュメントは、誰も参照しないドキュメントになります。
規制対応や、安全性に関わる重要なビルドの仕様書として。 規制当局、安全ケース、契約上の義務が支配する領域では、PRDではなく、トレーサビリティを備えた完全な仕様が必要です。実装の詳細を委任することは、まさにできないことです。
ページごとに提示する。 上で長く説明したとおりで、6つのうち最もよくあるものです。
PRDを書く／提示する際のよくあるミス
依頼（ask）より先に文脈を提示することで、何を求められているのかを部屋が理解する前に意見が形成されてしまいます。
1つの選択肢を唯一のもののように提示し、部屋が本来得意なこと（判断）を行う余地を奪ってしまう。
本当に重要な要件を34番目に埋め込み、「あると嬉しい」扱いにしてしまう。
意思決定の会議にモックアップを持ち込む。議題に何があっても、議論を確実に消費してしまいます。
機会費用を省略して、承認が「無料」に感じられるようにしてしまう。
部屋の人が以前に求めていた範囲外の項目を名前で挙げない。これは、その場で追加するよう促すことになります。
そして、会議で追加された範囲をコストに反映せずに受け入れる。これが、9週間の機能を20週間のものに変えてしまうやり方です。
Google Docs、Word、ConfluenceのPRDテンプレート
Google Docsは、PRDが議論されることになる場合に適しています。コメントのスレッドが議論の場になるからです。弱点は、意思決定が誰も読まない「解決済みコメント」に行き着いてしまうことです。解決する前に、ドキュメントが変わった内容を要件の「理由」フィールドにコピーしてください。
Confluenceは、エンジニアリング組織で最も一般的な置き場所で、標準のPRDテンプレートも従来型です。本文をより軽い構造に置き換えるのは問題なく機能し、ステータスとオーナーのページプロパティは残しておく価値があります。
Wordは、PRDが正式な承認パックの一部になる組織に適しています。番号付き要件や相互参照をうまく扱えます。
Notionは、要件をデータベースとして扱いたい場合にうまく機能します。制約されたタグまたは委任されたタグがプロパティになり、四半期をまたいでフィルタや集計ができます。
プレゼン自体は、組織が普段使っているものを何でも使い、6スライドに収めてください。重要なのは、要件がデッキに残るかどうかであり、ツールそのものではありません。
Word、Excel、PDFでPRDテンプレートを入手できますか？
PRDはWordまたはGoogle Docsです。番号付きリストが入った文章で、コメントされます。
Excelは、1つのPRDではなく、複数の機能にまたがる要件レジスター用です。機能、要件、制約または委任、理由、そしてビルド中に再交渉されたかどうか。最後の列は、誰かの行動を確実に変える唯一のPRD指標です。
PDFは、意思決定記録に添付する版、または社外で共有する版です。未解決の質問が閉じた後に1回だけエクスポートします。
PowerPointまたはSlidesはプレゼン用で、6スライドです。PRDは埋め込まず、事前読みにして送ります。レビューに参加できないステークホルダー向けには、デッキをプレゼンテーションから動画のツールに通して録画を共有してください。デッキがパートナーや取締役会などの外部の聴衆に向けられる場合は、ブランドキットによって、誰もテンプレートを作り直さなくても一貫性を保てます。
意思決定の後に、作ったものをどう見せるか
PRDは作業開始の日には読まれなくなり、会議の翌週にはプレゼンは忘れられます。ループを閉じる成果物として誰も作らないのが、実際に作られたものの短いデモです。承認した人たちと、これからそれをサポートまたは販売しなければならないすべての人のために。
Trupeer AIなら、それを安価に実現できます。誰が作ったかに関係なく、完成した機能を1回だけ記録し、その出力は「書かれたウォークスルー」、リリースノート用の「動画」、そして自社のナレッジベース用の「ドキュメント」になります。さらに、私たちのナレッジベース記事テンプレートがカバーするように、その1回の記録は、レビューグループ、サポートチーム、そして顧客向け記事にも使えます。
記録する。ブランド化する。翻訳する。Trupeerする。
次のレビューも改善されます。直近で承認された機能が実際にどうなったかを2分で記録したものは、「これからどうなるか」についてのどんなスライドよりも、プロダクトレビューの冒頭で説得力があります。技術ドキュメンテーションでは、作られたものの社内記録を扱います。セットアップ手順はドキュメントテンプレートのセットアップガイドにあります。
よくある質問
Wordで無料のPRDテンプレートはありますか？
ドキュメント構造は、私たちのリーンPRDテンプレートでカバーされており、WordまたはGoogle Docsにそのまま貼り付けられます。このページのプレゼン構造は6スライドです。ゲート付きのダウンロードも、どちらにもフォームもありません。
Google Docs用のPRDテンプレートはありますか？
構造をGoogle Docにコピーし、テンプレートとしてチームドライブに保存してください。Google Docsが特に良いのは、PRDがコメントで議論されるためです。ただし注意点として、スレッドで決まったことは、スレッドが解決される前にドキュメントへ書き込む必要があります。
Excelにプロダクト要件ドキュメントのテンプレートはありますか？
Excelは、単一のPRDではなく、複数の機能にまたがる要件レジスターに適しています。機能、要件、制約されているか／委任されているか、理由、そしてビルド中に再交渉されたかどうかの列があります。最後の列を四半期ごとに見直すと、どのプロダクトマネージャーが過剰に指定しているかが分かります。
PDFでPRDの例やサンプルはありますか？
公開されている例は見つけやすく、内容よりもセクションの順序の参考として読む価値があります。なぜなら、実際のPRDにある要件はどれも1つのプロダクトに属するからです。より役立つのは、最近出荷した機能を1つ選び、それについて6スライドのデッキを振り返りとして書くことです。そうすると、意思決定が明確に書かれていなかったことが多くの場合わかります。
AIのPRDツールは使う価値がありますか？
最初のドラフトなら、はい。機能と最新のツールを説明すれば、忘れていたかもしれないセクションを含む構造化されたドキュメントが返ってきます。できないのは、あなたが本当に気にしている要件を決めることです。これは、あなただけが持っている知識に依存するためです。放っておくと、自信満々に過剰指定されたドキュメントが生成されます。これは避けるべき失敗パターンです。
PRDプレゼンテーションは何枚のスライドにすべきですか？
6枚です。約15分で提示し、付録は通しで見せません。長いデッキほどコメントが増え、意思決定が減ります。これは、上の実例が示している関係です。ガバナンスで固定フォーマットが求められている場合は、続く内容に関係なく、意思決定は最初のスライドに置いてください。
誰がPRDをプレゼンすべきですか？
それを書いたプロダクトマネージャーです。エンジニアリングリードは同席しますが、プレゼンはしません。トレードオフのスライドではエンジニアが部屋にいることが重要です。「もっと速くできるか」という問いへの信頼できる答えは、二次情報よりも彼らから得られるからです。
PRDと要件ドキュメントの違いは何ですか？
PRDはプロダクト向けです。何を作るのか、誰のために作るのか、そして「完了」とは何を意味するのか。ビジネス要件ドキュメントはそれより前に位置し、ビジネス上の課題と、どんな解決策でも達成すべきことを、ビルドの意思決定が行われる前に説明します。技術仕様はさらに後に位置し、どうやって作るのかを説明します。必要なものが別なのに、片方を探してしまうことはよくあり、その結果、間違った高度（レベル感）のドキュメントが作られます。
