prd-writing

概要

PRD の作成とは、「Working Backwards」手法を用いて、戦略的なビジョンを実行可能なエンジニアリング要件に落とし込むプロセスです。技術仕様を確定する前に、顧客向けの説明文（プレスリリース）と包括的なリスク監査（FAQ）の作成を求めることで、明確さを担保します。

鉄則

NO PRD WITHOUT A CUSTOMER-FACING PRESS RELEASE DRAFT FIRST

顧客にとってのメリットを明確にする前に要件を書くと、「機能の肥大化」やエンジニアリングの取り組みの方向性のずれを招き、顧客ではなく技術上の問題を解決する製品につながります。

状態遷移図

digraph prd_writing_flow {
    "Strategy/Vision" [shape=doublecircle];
    "Step 1: Press Release (PR)" [shape=box];
    "Step 2: FAQ (Internal/External)" [shape=box];
    "Step 3: Narrative PRD" [shape=box];
    "Gate: Alignment Review" [shape=diamond];
    "Technical Spec Ready" [shape=doublecircle];

    "Strategy/Vision" -> "Step 1: Press Release (PR)";
    "Step 1: Press Release (PR)" -> "Step 2: FAQ (Internal/External)";
    "Step 2: FAQ (Internal/External)" -> "Step 3: Narrative PRD";
    "Step 3: Narrative PRD" -> "Gate: Alignment Review";
    "Gate: Alignment Review" -> "Step 1: Press Release (PR)" [label="benefits unclear"];
    "Gate: Alignment Review" -> "Step 2: FAQ (Internal/External)" [label="risks missing"];
    "Gate: Alignment Review" -> "Technical Spec Ready" [label="approved"];
}

このスキルを使用する場面

• 新製品や大規模な機能の開発を始めるとき。
• 既存の要件が断片的、または不明確なとき。
• 部門横断チーム（エンジニアリング、デザイン、マーケティング）を単一の信頼できる情報源に基づいて連携させるとき。
• 製品への投資やリソース配分の会議に備えるとき。

このスキルを使用しない場面

• 簡単なバグ修正や保守作業の場合。
• 目的が製品のリリースではなく学習である探索的な研究開発の場合。
• 問題がまだ定義されていない場合（代わりに problem-framing を使用してください）。

主なプロセス

ステップ 1：まずプレスリリース（PR）を書く

• 1ページのみ： 顧客向けの表現を使い、製品の価値を1ページにまとめます。（出典：Bryar、Working Backwards）
• 必須要素：
  • 見出し： 顧客に伝わる製品名を付けます。
  • サブ見出し： 対象顧客と、主なメリットを1つ示します。
  • 概要： 製品とそのメリットを1～2文で要約します。
  • 問題： 顧客が抱える問題を詳しく説明します（例：「Xするのは大変です……」）。
  • 解決策： 製品がその問題をどのように簡単に解決するかを説明します。
  • リーダーのコメント： これを優先する理由を説明する、あなたまたはリーダーのコメントを記載します。
  • 顧客のコメント： 顧客の生活や仕事への具体的な影響を説明する、想定上のコメントを記載します。
  • 行動喚起： 顧客が利用を開始する方法を示します。（出典：Bryar、Working Backwards）

ステップ 2：FAQ を作成する

• 外部向け FAQ： 顧客から寄せられる一般的な質問（価格、提供状況、互換性など）を5～10個想定し、回答します。（出典：Bryar、Working Backwards）
• 内部向け FAQ： 技術的な実現可能性、依存関係、ROI、リスクなど、関係者から寄せられる「厳しい」質問に答えます。（出典：Bryar、Working Backwards）

ステップ 3：PRD にピラミッド原則を適用する

• トップダウンの論理展開： まず「結論を先に述べる」（BLUF）形で始めます。結論や推奨事項を最初に示す必要があります。（出典：Minto、Pyramid Principle）
• MECE による構成： 要件のグループが相互に排他的であり、全体として網羅的であることを確認します。重複や漏れがないようにします。（出典：Minto、Pyramid Principle）
• 帰納的な推論： 主な要件を支えるデータや事実をその下にまとめ、内容を理解しやすくします。（出典：Minto、Pyramid Principle）

ステップ 4：「制約となる工程」を特定する

• 逆算による計画： 「制約となる工程」（構築に最も時間がかかる、最も慎重な対応が必要、または最も費用がかかる部分）を特定します。その日程から逆算して、提供のペースを設定します。（出典：Grove、High Output Management）
• 成果重視： PRD では、単なる 活動（機能）ではなく、成果（提供される価値）に焦点を当てます。（出典：Grove、High Output Management）

スキル間の呼び出し

必須のサブスキル：buyer-persona — 「顧客のコメント」に現実味を持たせます。 推奨サブスキル：stakeholder-review — 最終決定の前に PR/FAQ を厳しく検証します。 推奨サブスキル：memo-stress-tester — 最終的な PRD の説明の構成が堅固であることを確認します。

合理化の表

考え方	実情
「プロジェクトが小さすぎて、PR/FAQは必要ありません。」	小規模なプロジェクトでも、機能の肥大化は起こりやすいものです。スコープを厳守する唯一の方法がPR/FAQです。
「エンジニアリングチームは、何を作るべきかすでに把握しています。」	エンジニアリングチームが把握しているのは、どのように作るかです。PR/FAQは、なぜ作るのかについて認識をそろえます。
「PRを書くのは時間の無駄です。コードを書きましょう。」	コードを書き直すコストは、1ページの説明文を書き直すコストの10倍です。
「プレスリリースはローンチ時に書けばいいでしょう。」	ローンチ当日のPRはマーケティングですが、初日のPRは戦略ツールです。これを省略すれば、認識のずれは避けられません。

注意すべき兆候

次のような考えが浮かんだら、いったん止まりましょう。近道をしようとしています。

• 「PRが3ページもあります。」→ 価値をまだ十分に絞り込めていません。
• 「まず技術仕様から始めて、あとでPRを埋めます。」→ 顧客から逆算するのではなく、テクノロジーを起点に作っています。
• 「FAQに『難しい』質問がありません。」→ 後々プロジェクトを頓挫させる技術的リスクや組織的リスクを避けています。

診断チェックリスト

• 顧客向けの1ページのプレスリリースがありますか？
• PRには、具体的な成果を説明する顧客の引用が含まれていますか？
• 内部向けFAQでは、技術的負債と依存関係を扱っていますか？
• PRDは、ピラミッド原則を用いてトップダウンで構成されていますか？
• 実装における「制約となる工程」を特定していますか？

参考資料

• Bryar & Carr、Working Backwards、第5章 — PR/FAQの手法。
• Barbara Minto、The Pyramid Principle — MECEとトップダウンの構成。
• Andrew Grove、High Output Management、第1章および第3章 — 制約となる工程とマネジメントのレバレッジ。
• AmazonのPR/FAQ手法に関する記事。