フレームワーク活用ガイドひとことで言うと#
新しいプロダクトや機能を企画する時に、**完成後に出す架空のプレスリリース（PR）と想定質問集（FAQ）**を先に書くAmazonの手法。パワーポイントではなくナラティブ（文章）で思考を強制することで、曖昧さを徹底的に排除する。
押さえておきたい用語#
- ナラティブ（Narrative）
- 箇条書きやスライドではなく完全な文章で考えを記述する形式のこと。Amazonではパワーポイント禁止で、すべてナラティブ形式のドキュメントで議論する。
- ワーキングバックワーズ（Working Backwards）
- 完成した未来の顧客体験から逆算して企画を練るAmazonの思考法のこと。PR/FAQはこの手法の中核ツール。
- 外部FAQ
- 顧客やユーザーから想定される質問に答えるセクションのこと。「既存の〇〇と何が違うの？」「いくらかかるの？」などが典型。
- 内部FAQ
- 経営層や開発チームから想定される質問に答えるセクションのこと。技術的実現性、収益モデル、撤退基準など、より厳しい質問を含む。
PR/FAQの全体像#
こんな悩みに効く#
- 企画書がスライドの箇条書きばかりで、深い議論ができない
- 「何が嬉しいのか」が関係者にうまく伝わらない
- 企画段階で見落としが多く、開発中に問題が噴出する
基本の使い方#
以下の構成で架空のプレスリリースを書く。
構成:
- 見出し（Headline）: 顧客の目を引く一文
- サブ見出し: 誰が、何を得られるか
- 日付と場所: 架空のリリース日
- 導入段落: 何を発表するのか概要
- 課題段落: 顧客が今抱えている問題
- 解決策段落: このプロダクトがどう解決するか
- 責任者の引用: なぜこれを作るのか（ビジョン）
- 顧客の引用: 使った顧客の声（架空）
- 始め方: すぐに使い始める手順
書き方のルール:
- 顧客が読む文章として書く。技術用語禁止
- 定量的な表現を入れる。「大幅に改善」ではなく「50%削減」
- A4で1枚以内。長くなるのは焦点が絞れていない証拠
顧客やユーザーから想定される質問に答える。
典型的な質問:
- 「既存の〇〇と何が違うの？」
- 「いくらかかるの？ 無料プランはある？」
- 「自分のデータは安全？」
- 「使い始めるのに何が必要？ 既存ツールとの連携は？」
- 「サポートはどうなっている？」
書けない質問があったら、それは未検討の領域。FAQを書くことで企画の穴が明らかになる。
最低5〜10個の質問に対して、具体的に回答を書く。
経営層や開発チームから想定される質問に答える。
典型的な質問:
- 「市場規模はどれくらい？ TAM/SAM/SOMは？」
- 「開発にどれくらいの期間とリソースが必要？」
- 「技術的な実現可能性は？ 最大のリスクは？」
- 「収益モデルは？ いつ黒字化する？」
- 「失敗した場合の撤退基準は？」
- 「競合が同じものを作ったらどう差別化する？」
内部FAQは外部FAQよりも厳しい質問を含める。ここで答えに詰まるなら、企画として不十分。
Amazonでは内部FAQだけで5〜10ページになることもある。
書いたPR/FAQを6ページ以内の文書としてまとめ、レビューミーティングを開催。
Amazonスタイルのレビュー:
- 全員が**黙読（15〜20分）**する。事前配布はしない
- 読了後に質問・フィードバックを出す
- 筆者が回答し、議論する
- 文書を修正して再レビュー（必要に応じて複数回）
判断基準:
- プレスリリースを読んで「自分がこの顧客なら欲しい」と思えるか？
- FAQで答えに窮する質問がないか？
- 全員が「これは作る価値がある」と確信できるか？
Go判定が出たら、PR/FAQが開発の北極星になる。迷った時はプレスリリースに立ち返る。
具体例#
経費精算アプリチームが「レシート自動読み取り機能」の企画でPR/FAQを作成。
プレスリリース:
もうレシートの手入力は不要。ExpenseApp、AI自動読み取り機能をリリース
スマホで撮影するだけ。金額・日付・店舗名を99%の精度で自動入力
2026年4月1日 — ExpenseAppは本日、レシートのAI自動読み取り機能をリリースしました。経費精算の最大の苦痛である「レシート情報の手入力」が不要になります。
調査によると、ビジネスパーソンは月平均45分をレシートの手入力に費やしています。入力ミスによる差し戻しも月2〜3回発生し、経理部門の負荷にもなっています。
新機能では、レシートを撮影するだけで金額・日付・店舗名・カテゴリが自動入力されます。精度は99%。修正が必要な場合も1タップで編集可能です。
「手入力の時間がゼロになったのが嬉しい。月末の精算が5分で終わるようになりました」—— 利用企業 営業部 田中さん
内部FAQで発覚した課題:
- Q: 「手書きレシートの読み取り精度は？」→ A: 未検証 → 手書き対応の技術調査が必要と判明
- Q: 「海外レシート（多言語）は対応可能？」→ A: 初期リリースでは日本語のみ → スコープを明確に限定
- Q: 「OCRの処理コストはユーザーあたりいくら？」→ A: 試算で月額50円/人 → 料金プランに影響なしと確認
PR/FAQのレビューを2回実施した結果、初期リリースは「印刷レシートの日本語読み取り」にスコープを絞り、手書き・多言語はPhase 2に明確に分離。開発前にスコープが確定し、2ヶ月でリリース完了。
従業員420名の物流企業が「配送効率を上げるドライバー向けアプリ」を企画。
プレスリリース:
1日の配送件数が平均15%増。LogiDrive、AIルート最適化アプリをリリース
ドライバーの勘と経験に頼っていたルート選定をAIがサポート
配送ドライバーは毎朝30〜45分かけてルートを手動で組んでいます。交通状況や荷物の優先度を考慮するため、ベテランでも最適解にたどり着けないことが多い状況です。LogiDriveは、配送先・荷物サイズ・交通予測・時間指定を考慮して最適ルートを3秒で算出します。
「朝のルート組みが3秒になった。しかも自分で考えていたルートより効率がいい」—— ドライバー歴12年 佐藤さん
FAQで発覚した課題と対策:
| FAQ質問 | 回答 | 発覚した課題 |
|---|---|---|
| ベテランドライバーは使ってくれるか？ | 答えに窮した | 変更管理の計画が必要 |
| オフライン環境でも動くか？ | 未検討 | 地下駐車場での利用を想定してなかった |
| 既存の配車システムとの連携は？ | APIなし | 連携開発に追加3ヶ月必要 |
PR/FAQにより3つの重大リスクが開発前に判明。特に「ベテランドライバーの抵抗」は技術ではなく組織の問題であり、PR/FAQなしでは開発後に初めて気づいていた。パイロット導入として5名のドライバーで1ヶ月検証を先行し、成果データで全社展開の合意を形成するプランに変更した。
年間観光客数180万人の温泉地の観光協会が、紙のクーポン冊子に代わるデジタル周遊パスを企画。
プレスリリース:
スマホひとつで温泉街を丸ごと楽しめる。「○○温泉デジタル周遊パス」登場
1日2,500円で温泉5施設＋飲食店12店舗＋体験3プランが利用し放題
これまで観光客は各施設で個別に料金を払い、クーポン冊子は使い忘れが72%でした。デジタル周遊パスなら、スマホのQRコードを見せるだけ。利用できる施設がマップ上に表示され、混雑状況もリアルタイムでわかります。
外部FAQ（観光客向け）:
- Q: 「スマホがない高齢者は？」→ A: 紙のカードタイプも併売（NFC対応）
- Q: 「当日でも買える？」→ A: 現地のコンビニまたは駅の観光案内所で即購入可能
内部FAQ（観光協会向け）:
- Q: 「参加施設への精算はどうする？」→ A: 利用データに基づいて月末一括精算 → 精算システムの開発が必要と判明
- Q: 「個人情報の管理は？」→ A: 未検討 → プライバシーポリシーの策定が必須
- Q: 「パスの適正価格は？」→ A: 各施設の平均単価合計の40%が目安 → 施設側の手取りシミュレーションが必要
PR/FAQにより「精算システム」「プライバシーポリシー」「施設側の収益シミュレーション」の3つが開発前に特定され、企画期間は延びたが手戻りゼロで3ヶ月後にリリース。初月で4,200枚が売れ、観光客1人あたりの域内消費額が1,800円から3,400円に増加した。
やりがちな失敗パターン#
- 箇条書きやスライド形式で書く — PR/FAQの本質は「文章で思考を強制する」こと。箇条書きだと論理の飛躍が隠れる。**完全な文章（ナラティブ）**で書くからこそ曖昧さが排除される
- 都合の良いFAQしか書かない — 簡単に答えられる質問だけ並べるのは自己満足。最も答えにくい質問をあえて書き、そこに向き合うことが価値
- 書いた後にレビューしない — 一人で書いて一人で納得しても、思い込みは排除できない。最低3人の多角的な視点でレビューする
- プレスリリースが技術寄りになる — 「最新のAI技術を搭載」ではなく「レシートの手入力が不要になる」と書く。主語は常に技術ではなく顧客体験
まとめ#
PR/FAQは「プレスリリースが書けるレベルまで企画を具体化する」手法。顧客が喜ぶ姿を文章で描き、想定される質問にすべて答える。書けない部分が企画の穴。開発を始める前にこの穴をふさぐことで、手戻りのないプロダクト開発が実現する。