このテンプレートを使用してください
モダンなプロダクトチームはスピードが命。だからこそ、実態に合ったPRDが必要です。Trupeerなら、無料のリーンPRDテンプレートから始めて、ブランドガイドラインでカスタマイズし、リーンPRDを動画ウォークスルーに変換することで、部門横断のチームを素早く足並みそろえられます。
リーンPRDとは？通常のPRDと何が違うの？
プロダクト要件書（PRD）は、何を作るのか、誰のために作るのか、そして「完了」と言えるために何が満たされる必要があるのかを定めます。リーンPRDも同じ役割を、10ページではなく1〜2ページで果たします。しかも、課題の細部まで把握していて、その詳細を任せられるだけの距離感があるチーム向けです。
よくある説明は「リーンPRDは短い」というものです。しかしそれは定義ではなく症状であり、それを追いかけると質の悪いドキュメントになります。PRDは、重要だった部分も重要でなかった部分も同じように削れば短くできてしまうからです。
役に立つ定義は「権限（オーソリティ）」にあります。PRDは、チームに課す制約の集合です。リーンPRDは、正しい結果を得るために必要な最小限の制約を置き、チームがどこを判断するのかを明確に示します。だから短いのです。従来のPRDを埋めている大半は、実は誰も意見を持っていない仕様だからです。
PRDは、チームから引き出す「意思決定のリスト」
PRDのどんな要件を読んでも、「それは何をしているのか？」と問いかけてください。そこに書かれた一つひとつが、実際に作るときに本来その判断をしていた人から選択肢を取り除くからです。
必要な削除もあります。たとえば、ファイルの処理に20分かかるせいでクローズしたラップトップでもインポートが生き残る必要があるなら、チームはそれを知る必要がありますが、それはチームの判断ではありません。
ほとんどはそうではありません。マッピング画面での列の順序、エラーメッセージの文言、バリデーションがアップロード前か後か――これらがPRDに入ってしまうのは、テンプレートにそのためのセクションがあり、空欄だと不親切に見えるからです。どれも、チームが疑問なく従う制約になるか、交渉して外すかのどちらかです。従えばプロダクトが悪くなる可能性があり、交渉すれば数日かかります。
そこでリーンPRDは、各行が入る前に1つの質問をします。チームがどちらの選択肢を選んだとしても、私は同じくらい満足できるか？もし「はい」なら書かないでください。「それはチームのものだ」と書きます。この質問がドキュメントを短くする理由であり、短さは目標ではなく副産物です。
Trupeerでこのテンプレートをカスタマイズする方法
ステップ1：テンプレートセクションを開く
メインナビゲーションからテンプレートセクションへ移動します。
ステップ2：テンプレートを選択して開く
作業したい任意のテンプレートをクリックして開きます。
ステップ3：テンプレート表示を展開する
必要に応じて、テンプレート表示を展開し、レイアウトと詳細をはっきり確認します。
ステップ4：テンプレートを編集する
編集をクリックして、選択したテンプレートの変更を開始します。
エディター内で、次のことができます：
新しいセクションを追加
書式ルールを定義または更新
ロゴを追加し、位置や関連設定を調整
ステップ5：カスタマイズしたテンプレートを保存する
必要な変更をすべて行ったら、保存をクリックして更新済みのテンプレートを自分のものとして保存します。
ステップ6：プレビューしてテンプレートを微調整する
カスタマイズしたテンプレートがどのように表示されるか確認したいときは、プレビューを開きます。
プレビュー画面から、必要に応じて直接調整を続けることができ、テンプレートが希望どおりに表示されることを確認できます。
リーンPRDテンプレートでできること：
執筆の時間を節約： 20ページの形式を、集中した1ページのリーン構造にスキップ。
チームをより早く足並みそろえる： 内蔵された課題・仮説セクションが、プロダクトの明確さを強制します。
ブランドに沿った見た目を維持： Trupeerのブランドキットでロゴ、フォント、カラーを適用。
素早く反復： 仕様が進化するにつれてPRDを更新し、動画を再生成。
チーム間で標準化： すべてのプロダクト施策に同じテンプレートを使用。
グローバルなプロダクトチームへ： クリック1つでリーンPRDを65+言語に翻訳。
すべての要件に「制約」または「チームの判断」をタグ付けする方法
すべての行に2つのタグ。例外なし。
制約。 このやり方でなければならない理由があり、ここに書くのはなぜそうする必要があるのかです。理由は任意ではなく、制約が生き残るための部分です。理由のある制約は、状況が変われば知的に異議を唱えられます。理由のない制約は、後になって誰も触れようとしない「伝承」になります。
チームの判断。 到達すべき結果は説明しました。そこに至る方法はあなたたちのものです。私の意見が欲しいなら聞いてください。そしてそれを意見として扱ってください。
比率は何かを教えてくれます。最初の下書きは制約が強めに出がちで、各行に理由を追加すると多くが崩れます。正直な理由は「テンプレートにそう書いてあったから」ということが多いからです。
タグを正直に保つためのルールは2つです。「プロダクト全体との整合性のため」という理由で制約するなら、具体的に何と整合しているのかを名指ししてください。そして「チームの判断」行は約束です。ビルド中にそれを覆したらドキュメントが壊れてしまうので、次のものは信じてもらえません。
委任を安全にする「受け入れ（Acceptance）行」
「どうやって」を渡せるのは、「何を」を正確に定めている場合だけです。それがトレードオフであり、受け入れ行がその代価を支払う場所です。
1文で書きます。出荷後に真実になることを、今は真実ではない形で説明し、あなたとエンジニアがそれが起きたかどうかをそれぞれ独立して判断できるように書きます。ビジネス上の成果である指標目標はここではありません。別の場所に属します。書かないようにしたい「機能の一覧」でもありません。
良い例：顧客が最大5万行のファイルをアップロードし、ブラウザを閉じても、戻ってきたときにインポートが正しく完了している。
悪い例：バルクインポート体験を改善する。
受け入れ行は、文脈や要件の前、いちばん上に置きます。書けないなら、そのドキュメントを書く準備ができていません。次の正直なステップは下書きではなく会話です。
無料のリーンPRDテンプレート：コピーすべき「1.5ページ」
ここからコピー。
受け入れ行。 上記と同じく1文。
なぜ今。 2〜3文。なぜこの四半期にやる価値があるのか、次の年ではなく今なのは何が起きているからか。このセクションは削られがちですが、削るべきではありません。チームが、あなたが決して目にしない100個の小さなトレードオフを成立させるために使うものだからです。
対象。 ユーザーを最も狭く正確に説明し、だいたい何人いるか。ここに数字があると、過剰な設計（オーバーエンジニアリング）が大幅に減ります。
制約付き要件。 番号付き。各項目は1文＋理由。15未満を目標に。30あるなら、その多くは「チームの判断」に見せかけたものです。
チームの判断。 明示的に指定しない領域を短く列挙します。指定しない領域を名指しすることが重要なのは、未記載の領域は委任ではなく見落としに読まれるからです。
作らない。 スコープ外として、かつ議論になり得るほど具体的に名指しされた要望。誰も異議を唱えない「作らない」リストは、実質的に何も仕事をしていないのと同じです。
未解決の質問。 各項目に名前と日付を付けます。担当者のいない質問は、答えられないまま放置され、やがてブロッカーになります。
どうやって分かるか。 リリース後に、いつ、何を見れば判断できるのか。1〜2個で十分。ダッシュボードではありません。
ここまでコピー。記入済みのバージョンが2ページを超える場合は、まず制約リストを見てください。膨らみの原因はいつもそこにあります。
バルクインポート機能のための、記入済みリーンPRD例
受け入れ行。 顧客管理者はCSVから最大5万件の顧客レコードをインポートでき、インポート中にブラウザを閉じても、戻ったときに正しく完了していることを確認できる。
なぜ今。 私たちの上位5社のうち3社が今四半期に競合から移行しており、それぞれ12,000〜40,000件のレコードを持っています。現在は、いずれも500件ずつ貼り付けるか、ファイルを送ってもらい手作業で対応していますが、先月はサポートチームが11日かかりました。
対象。 オンボーディング時のアカウント管理者。四半期あたり約40名で、そのほとんどはこれをちょうど1回だけ実施します。
制約付き要件。
インポートはブラウザを閉じても生き残る必要がある。これほどのサイズのファイルは処理に20分以上かかり、ラップトップはスリープするため。
バリデーションに失敗した行は、通過した行をブロックしてはならない。現在は1つの不正な行があると、顧客の実行全体が失敗してしまうため。
顧客は、失敗した行のファイルを理由付きでダウンロードできる必要がある。そうすれば、私たちの助けなしに顧客自身が修正できるから。
重複検出はメールアドレスで行う必要がある。これは、プロダクト全体が顧客を識別する方法に合わせるため。
インポートは、最初の10件のマッピング済み行の画面プレビューなしでは開始できない。最も多いサポート問い合わせは、後から判明する「マッピング列の誤り」だから。
チームの判断。 マッピング画面のレイアウト、エラーメッセージの文言、進捗表示、バリデーションが実行される場所、50,000行を超える場合のファイルサイズ上限、インポート間でマッピングが記憶されるかどうか。
作らない。 予約または定期的なインポート。SalesforceまたはHubSpotから直接のインポート。インポート中のレコード編集。これら3つはすべて要望があり、いずれも別々の作業です。
未解決の質問。 顧客のセッションが期限切れになった場合、進行中のインポートはどうなるか。担当：Priya、3月14日まで。
どうやって分かるか。 サポートが対応する手動インポートが、四半期末までに月1件未満まで減る。
制約付き要件5つ、明示的に委任された領域6つ。これで1ページです。
3スプリントではなく5スプリントかかったPRD
約90名のB2Bソフトウェア企業であるHalbrookが、上記の機能を作りました。最初の試みでは標準テンプレートを使い、番号付き要件が41個で、9ページになりました。
そこには、マッピング画面での列の順序、6つのエラーメッセージの文言、10メガバイトのファイル上限、バリデーションはクライアント側で実行すること、モーダルのレイアウト、進捗バーはパーセンテージを表示することが書かれていました。
3スプリントで見積もったのに、5スプリントかかりました。
振り返りで差が追跡されました。41個の要件のうち6つは、ビルド中に再交渉され、それぞれが往復で半日〜3日かかりました。チームが別の実装を選ぶのに十分な理由があったからです。
最悪だったのはクライアント側バリデーションでした。チームは、数千行を超える場合はサーバー側処理が必要だと分かっており、最初のスプリントでそれを提起しました。ドキュメントを変更するまで9日かかりました。PMが休暇中で、署名済みのPRDにある番号付き要件を誰も覆せないと感じていたためです。
その後に聞くと、PMはその6つのうち5つについて意見を持っていなかったと言いました。テンプレートにユーザーインターフェースのセクションがあり、そこを空にするのは雑に見えると感じて残してしまっていたからです。
PMが本当に気にしていた要件――インポートがブラウザを閉じても生き残ること――は、リストの34番目にあり、「あると嬉しい」扱いで読まれていました。それなしで出荷され、2か月後に追加されました。追加コストは、追加スプリント相当の規模でした。
次の機能では、このページの形式を使いました。1.5ページで、制約付き要件は11個（それぞれ理由付き）。チームの判断として印を付けた領域は6つ、受け入れ行は1つ。3スプリント見積もりで3つで納品され、要件の再交渉はありませんでした。
ただ、1つだけ設計上の判断が彼女のところに戻ってきました。チームが「チームの判断」と印を付けたものの、実は受け入れ行に影響することが分かったのです。形式が生み出そうとしているのは、まさにその会話です。
1時間以内にリーンPRDを書く方法
まず受け入れ行を書き、そこに時間の大半を（必要以上に）使ってください。下流は、それが存在すればすべて簡単になります。もしそれが出てこないなら、それ自体が情報です。
次に「作らない」リストを書きます。人々が何を求めていたかをまだ覚えているうちに。後から、そのものの形にあなたが引き込まれてしまうと、書くのはずっと難しくなります。
その後、タグ付けなしで、思いつく限りの要件を10分間リストアップしてください。途中で絞り込まないでください。
次にタグ付けします。各項目について、「なぜそのやり方でなければならないのか」の理由を書いてください。「それがいつものやり方だから」や、そもそも理由が出てこないものは、チームの判断に移します。このステップで、リストは通常半分になります。
最後に、今やる理由と対象は、すでに分かっていることから書きます。各2分。
そして、エンジニアになったつもりで制約リストを読み直してください。「なぜ？」と聞きたくなるのに、ドキュメントが答えていない箇所は、理由を追加するか、その行を落とします。
リーンPRDテンプレートを使うときのよくあるミス
ミス | そう見える | 代わりにやること |
|---|---|---|
デフォルトで指定してしまう | テンプレートの各セクションがすべて埋まっている | どちらでも同じくらい満足できるかを問い直す |
理由のない制約 | 番号付き要件だが根拠がない | 理由を追加するか、チームの判断に移す |
重要なものを埋もれさせる | 34番の重要な要件がある | 受け入れ行に入れるべき |
空の「作らない」リスト | "Future considerations: none" | 人々が求めていたがあなたが断ったものを名指しする |
チームの判断を覆す | PMがビルド中に実装を却下する | 受け入れるか、タグが間違っていたと認めてそう言う |
間違った仕事にリーンを使う | 規制対象、安全性に重大な影響がある、または契約上のビルド | サインオフ付きの完全な仕様書を使う |
契約として扱う | ドキュメントが署名され、凍結されている | バージョン管理し、何が変わりなぜ変わったかを記録する |
最後の2つは、もう少し掘り下げる価値があります。作業が規制当局、安全ケース、指定された成果物を伴う顧客との契約、またはアクセシビリティやデータ保護の義務によって管理されている場合、リーンPRDは不適切な手段です。必要なのは、完全な仕様、義務へのトレーサビリティ、そしてそれに責任を負う人によるレビューです。どうやってを委任することは、まさに「どうやって」が監査対象になっているときにできないことです。
PRDとBRD、仕様書、ユーザーストーリーの違い
ビジネス要件書（BRD）はPRDの上位に位置します。ビジネス上の課題と、解決策が商業的に達成すべきことを説明します。通常は、何を作るかのプロダクト判断がまだ下されていない段階です。ビジネス要件書のサンプルを探しているなら、それは別の成果物であり、別の段階に属します。
技術仕様書はその下にあります。何をどう作るかを説明し、エンジニアリングが作成します。彼らのために書くというより、彼らが書くものです。リーンPRDは、このスペースの大半を意図的に空けます。これを担っているのが「チームの判断」タグです。
ユーザーストーリーは、それらよりもさらに小さいものです。1つのストーリーは作業の一断片です。PRDは、複数のストーリーを含む作業全体をカバーし、受け入れ行は、それらのストーリーが総合的に到達すべきものを示します。
組織が1つ持っているプロダクト仕様書（プロダクト仕様ドキュメント）は、「あるべき姿」よりも「実際に作られたもの」の説明に近いものです。リリース後も維持され、PRDは維持されません。
Confluence、Notion、Google DocsのリーンPRDテンプレート
Confluenceは最も一般的な置き場所で、標準のPRDテンプレートは従来型です。目標、背景、前提、ユーザーストーリー、要件、未解決の質問といったセクションがあります。これを上記の構造に置き換えても問題ありません。また、ステータスとオーナーのページプロパティは残しておく価値があります。
Notionは、制約付き要件をデータベースとして扱いたい場合により適しています。タグがプロパティになり、フィルタで絞り込めるためです。さらに、四半期全体の比率が数えなくても見えるようになります。
Google Docsは、議論されることが前提のドキュメントに最速です。議論が起きるのはコメントスレッドだからです。弱点は、議論が「解決済みのコメント」という誰も読まない場所に残ってしまうことです。そのため、スレッドを解決する前に、ドキュメントを変えた決定を要件の理由へ書き写してください。
どれを使うにせよ、形式が重要なのは「タグがレビュー会議を生き残るかどうか」の方であり、それ以外ははるかに重要度が低いです。
Word、Excel、PDFでリーンPRDテンプレートは使えますか？
WordまたはGoogle Docsは、ドキュメント自体に適しています。上記の構造をそのまま貼り付ければ、調整は不要です。PRDは「文章＋リスト」なので、ここに置くべきです。
Excelは、単一のPRDではなく、複数の機能にまたがる要件レジスターに向いています。機能、要件、制約またはチームの判断、理由、そしてビルド中に再交渉されたかどうかの列を用意します。最後の列は、私が見た中で唯一「誰かの行動を変えた」PRD指標です。
PDFは、意思決定に紐づけて添付する場合や、社外で共有する場合に適しています。オープンな質問セクションはその場で回答されることを想定しているため、作業版は編集可能なままにしておいてください。
リーンPRDのためのAI PRDジェネレーターは使う価値がありますか？
記憶（リコール）に関する部分には、確かに本当に役立ちます。良いジェネレーターなら、機能の説明を与えると、あなたが忘れていたかもしれないセクションを含む構造化された下書きを生成し、妥当な出発点になります。
ただし、できないのはタグ付けです。理由は「どちらでも同じくらい満足できるか？」という問いが本質であり、それを知っているのはあなただけだからです。放っておくと、ジェネレーターは自信満々に指定されたドキュメントを作ります。なぜなら、それが学習データから見える「それっぽさ」をそのまま出力するからです。これはまさに、このページが扱っている失敗です。
実用的な使い方は、長いバージョンを生成してから、タグの質問で切り詰めることです。ゼロから書くより速く、判断は本来あるべき場所に残ります。
PRDを「実際に出荷されたもの」とつなげ続ける方法
PRDは、作業が始まった日から読まれなくなり、その後更新されることもありません。これは問題ありません。問題なのは、その後受け入れ行がチーム外の誰にも届かないことです。
必要としているのは、チケットを受け取るサポート担当者と、何が変わったかを知る必要がある顧客です。どちらも通常は1行の変更履歴エントリを受け取りますが、スプリントを費やした「再開可能なインポート」の詳細は誰も受け取りません。
Trupeer AIは、そのギャップを低コストで埋めます。作った人が完成した機能を1回記録すると、書面のウォークスルー、リリースノート用の動画、そして自社のブランドでのナレッジベース用ドキュメントが手に入ります。顧客向けバージョンの構造は、ナレッジベース記事テンプレートに用意しています。
記録する。ブランド化する。翻訳する。Trupeerする。
実際に作られたものの社内記録としては、技術ドキュメントがカバーし、セットアップ手順はドキュメントテンプレートのセットアップガイドにあります。
よくある質問
Wordで無料のリーンPRDテンプレートはありますか？
上記の構造はそのままWordまたはGoogle Docsに貼り付けられ、再フォーマットは不要です。ゲート付きのダウンロードがないため、あなたとテンプレートの間にフォームもありません。記入済みのバージョンはチームの社内フォーマットとして保管してください。価値は、セクションそのものよりも、すべてのPRDが同じ見た目になることから生まれるためです。
PDFで無料のリーンPRDテンプレートはありますか？
ドキュメントをチーム外で共有する場合や、意思決定記録に添付する場合は、自分でエクスポートしてください。オープンな質問がまだ開いている間は編集可能なままにしておきます。質問が答えられる前に凍結されたPRDは、従われるというより無視されがちだからです。
Excelで無料のリーンPRDテンプレートはありますか？
Excelは、単一のPRDではなく、機能横断の要件レジスターに向いています。機能、要件、制約またはチームの判断、理由、そしてビルド中に再交渉されたかどうか。最後の列を四半期ごとにレビューするのが、どのPMが過剰に仕様化しているかを最も早く見つける方法です。
Google Docs用のPRDテンプレートはありますか？
上記の構造をGoogle Docにコピーして、チームドライブ内でテンプレートとして保存してください。このドキュメントに関しては、議論がコメントで行われるためGoogle Docsは適しています。ただし、コメントスレッドで到達した決定は、スレッドを解決する前に要件の理由へ書き込む必要がある、という注意点があります。
最適なPRDテンプレートはどれですか？
エンジニアが振り返りの最中ではなく、着手する前に読むものです。要件に理由があるかどうか、そしてドキュメントが「チームがどこを判断するのか」を示しているかどうかの方が、10セクションのテンプレートかどうかよりはるかに重要です。根拠欄のない10セクションのテンプレートは、どれほど完成度が高く見えても、誰も信頼しないドキュメントを生みます。
PDFでビジネス要件書のサンプルはどこで見つけられますか？
BRDは、より早い段階で作る別のドキュメントです。ビジネス上の課題と、解決策が達成すべきことを説明します。通常は、プロダクトの意思決定が行われる前です。BRDが必要なときにPRDを探すことはよくあり、PRDは「ビルドの意思決定がすでに取られている」前提なので、混乱やフラストレーションにつながります。
リーンPRDはどれくらいの長さが適切ですか？
1〜2ページで、制約付き要件は15未満。長くなると、仕様が再び入り込んでしまうことが多く、テストは「制約付きの各行に理由を追加できるか」です。それを通過して残ったものが、実際のドキュメントです。
リーンPRDは誰が書くべきですか？
プロダクトマネージャーが書き、受け入れ行は成果に責任を負う人と合意します。そして制約リストは、回覧する前にシニアエンジニアがレビューします。このレビューで、不要な制約の多くが見つかり、所要時間は約20分です。
