ひとことで言うと#
「何が作れるか」ではなく「顧客にとって最高の体験は何か」から逆算してプロダクトを設計するAmazonの手法。開発を始める前にプレスリリースとFAQを書くことで、「本当に顧客が喜ぶものか?」を早期に検証する。
押さえておきたい用語#
- PR/FAQ(Press Release / FAQ)
- 架空のプレスリリースと想定質問集を事前に書くことで顧客体験を具体化するAmazon式の企画文書のこと。ワーキングバックワーズの中核ツール。
- 顧客起点(Customer Obsession)
- 技術や競合ではなく顧客のニーズを出発点にする思考原則のこと。Amazonの14のリーダーシップ原則の筆頭に位置する。
- 逆算思考(Working Backwards)
- 「完成した未来」を先に描き、そこから現在に向かって必要な要素を逆順に設計する思考法を指す。
- 内部FAQ(Internal FAQ)
- 技術的実現性・開発期間・収益モデル・撤退基準など、社内の関係者から出る想定質問への回答集のこと。ここで答えられない箇所が追加調査ポイント。
ワーキングバックワーズの全体像#
こんな悩みに効く#
- 技術ありきで企画してしまい、顧客のニーズとズレる
- 企画段階で曖昧なまま開発に入り、後から方向転換が増える
- チーム内で「このプロダクトは誰のためのものか」の認識がバラバラ
基本の使い方#
最初に**「誰のためのプロダクトか」**を具体的に定義する。
書くべきこと:
- 誰が顧客か: 属性、役割、状況(「従業員50〜200人のIT企業の人事マネージャー」)
- 何に困っているか: 現在の課題やペインポイント
- 今どう対処しているか: 既存の代替手段とその不満
Amazonのルール: 「全員」はターゲットではない。最初に喜ぶ1人の顧客像を鮮明に描く。
プロダクトが完成し、世の中に発表する時の架空のプレスリリースを書く。
プレスリリースの構成:
- 見出し: 顧客が注目するキャッチコピー
- サブ見出し: 誰のための、どんなプロダクトか1文で
- 課題の提示: 顧客が今抱えている問題
- 解決策の説明: このプロダクトがどう解決するか
- 顧客の引用コメント: 使った顧客がどう感じるか(架空)
- 始め方: どうやって使い始めるか
- CTA: 今すぐ始めるための行動
鉄則: 技術用語を使わない。顧客が読んで理解できる言葉で書く。A4で1枚以内。
プレスリリースに対して想定される質問と回答を書く。
2種類のFAQ:
- 外部FAQ(顧客向け): 「既存の〇〇とどう違うの?」「いくらかかるの?」「データは安全?」
- 内部FAQ(社内向け): 「どれくらいの開発期間が必要?」「技術的に実現可能?」「収益モデルは?」「撤退基準は?」
FAQで苦しい質問に答えられなければ、その企画はまだ不十分。書けないFAQがある箇所が、追加調査・検討が必要なポイント。
詳しい書き方はPR/FAQ(Amazon式)フレームワークを参照。
プレスリリースとFAQをチームや関係者でレビューする。
レビューのチェックポイント:
- 顧客視点: 「この発表を見た顧客は本当にワクワクするか?」
- 差別化: 「既存の代替手段と比べて、明確に優れている点はあるか?」
- 実現可能性: 「書いた理想を実際に実現できるか?」
- ビジネス性: 「これで十分な収益が見込めるか?」
Amazonではプレスリリースが5回以上書き直されることも珍しくない。簡潔で顧客の心に刺さる文章になるまで磨く。全員が「これなら欲しい」と思えたらGo。
具体例#
スタートアップが新しい社内コミュニケーションツールを企画する際にワーキングバックワーズを実施。
プレスリリース(架空):
「探す時間ゼロ」の社内コミュニケーションツール、TeamFlow発表
リモートワーク時代に「あの情報どこだっけ?」をなくすツール
リモートワークが定着した今、チームメンバーは1日平均45分を「過去の議論やファイルを探す」ことに費やしています。SlackもNotionも便利ですが、情報が分散するほど「どこに何があるか」がわからなくなります。
TeamFlowは、Slack・Notion・Google Driveの情報を横断検索し、AIが「あなたが今探しているのはこれですね」と提案します。
「TeamFlowを入れてから、新入社員の立ち上がりが2倍速くなりました。質問する前に答えが見つかるんです」—— 株式会社X 人事マネージャー
今すぐ無料でチームに導入できます。teamflow.example.com
FAQで発覚した課題:
- Q: 「セキュリティは大丈夫?」→ A: 答えられない → セキュリティ設計が未検討だと判明
- Q: 「Slackの検索と何が違う?」→ A: 曖昧 → 差別化ポイントを再検討
結果: プレスリリース3回の書き直しを経て、「検索」ではなく「AIが自動的に関連情報をサジェストする」にピボット。開発を始める前に方向修正ができ、推定3ヶ月分の開発コストを節約した。
顧客管理SaaS(契約社数150社)で「AIによる商談成約予測機能」の追加を検討。エンジニアチームはすぐ開発に着手したがったが、PMがワーキングバックワーズを提案。
プレスリリース(架空):
「この商談、決まりますか?」に数字で答えるAI予測機能リリース
営業マネージャーの「勘と経験」に頼らない商談管理を実現
SalesBoardに蓄積された過去2年分の商談データをAIが学習。進行中の商談ごとに「成約確率」をリアルタイムで表示します。確率が低い商談には「次にこのアクションを取ると確率が上がる」をAIが提案。
「90%以上の商談に集中し、50%以下は早めにクローズする判断ができるようになりました」—— 営業マネージャーC氏
FAQでの発見:
| 質問 | 答えられたか | アクション |
|---|---|---|
| 予測精度はどれくらい? | × | データサイエンスチームに検証依頼 |
| 最低何件のデータが必要? | × | 閾値を検証してからPR書き直し |
| 既存のSFAとどう違う? | △ | 差別化ポイントを顧客インタビューで検証 |
| 価格はいくら? | ○ | 月額+3,000円/ユーザーのアドオン |
結果: 予測精度の検証に2週間かけたところ、データ量が少ないクライアント(全体の40%)ではまともな精度が出ないことが判明。PRを「データ量300件以上のクライアント向けβ版」に修正し、段階リリースに方針変更。FAQなしで開発していたら全クライアントに一斉展開して炎上していた。
創業60年の味噌メーカー(従業員25名)。ECサイトでの直販を始めたいが、何を訴求すべきかわからない。社長とマーケ担当2名でワーキングバックワーズを実施。
プレスリリース(架空、初稿):
「60年の伝統製法で作る天然醸造味噌をご自宅に」
レビューでの指摘: 「伝統製法」は作り手視点であって顧客視点ではない。顧客は「自分にとって何が嬉しいか」を知りたい。
プレスリリース(3回目の書き直し):
「毎朝の味噌汁が、料亭の一杯に変わる」定期便スタート
スーパーの味噌では出せない深い旨みを、月1回ご自宅に
「味噌なんてどれも同じ」と思っていませんか?天然醸造で1年以上寝かせた味噌は、市販品の3倍のアミノ酸を含み、出汁を入れなくても深い旨みが出ます。忙しい朝でも、お湯を注ぐだけで「今日の味噌汁、いつもと違うね」と言われる一杯に。
初回限定: 3種お試しセット980円(送料無料)
FAQ(外部):
- Q: 市販の味噌と何が違う? → A: 熟成期間が6倍、アミノ酸含有量3倍。具体的な数字で差別化
- Q: 賞味期限は? → A: 未開封6ヶ月、開封後は冷蔵で3ヶ月
結果: この PR/FAQ をそのままランディングページのコピーに転用。初月の注文が目標の150%(230件)を達成。社長は「伝統製法を語りたかったが、顧客は味噌汁の味の変化が欲しかったのだと気づいた」とコメント。
やりがちな失敗パターン#
- 技術的にできることを先に書いてしまう — 「AIで〇〇を実現」ではなく「顧客が〇〇できるようになる」と書く。技術は手段であり、顧客体験が主語
- プレスリリースを形式的に書いて終わる — 書くことが目的ではなく、書く過程で「本当に顧客が欲しいものか?」を検証することが目的。苦しくなるまで深掘りする
- 一人で書いて一人で決める — チームでレビューしないと、個人の思い込みが排除できない。最低3人で議論して磨き上げる
- FAQの「答えられない質問」をスルーする — 答えられない質問こそ最大の発見。そこに追加調査が必要な論点が隠れている。書けないFAQを全部リストアップし、1つずつ潰してからGo判断する
企業での実践例 — Amazon#
ワーキングバックワーズはAmazon社内で2004年頃から定着したプロダクト企画手法で、「開発を始める前に、まずプレスリリースとFAQを書く」というルールが全社に適用されている。ジェフ・ベゾスが掲げた「Customer Obsession(顧客への執着)」というリーダーシップ原則を、企画プロセスに組み込んだ仕組みがPR/FAQである。
代表的な実例がAmazon Kindleだ。Kindle開発チームは実機の設計に入る前に、「いつでもどこでも60秒以内に本が読める」という架空のプレスリリースを書き、想定される顧客の質問(「バッテリーはどのくらい持つの?」「何冊入るの?」)に事前に回答する文書を作成した。このPR/FAQの過程で「書店で本を買う体験をどう超えるか」が具体的に言語化され、Whispernet(3G通信による即時ダウンロード)というコア機能が企画段階で確定した。AWSも同様に、社内エンジニアを「顧客」としたPR/FAQから始まっている。元Amazon副社長のコリン・ブライアーは著書『Working Backwards』の中で「PR/FAQを5回以上書き直すことは珍しくない。苦しい質問に答えられないなら、その企画はまだ不十分だということだ」と記している。
まとめ#
ワーキングバックワーズは「完成した未来から逆算する」思考法。プレスリリースを書くことで、顧客が本当に喜ぶ体験を言語化し、曖昧さを排除する。コードを1行も書く前に、チーム全員が「これは作る価値がある」と確信できるまで磨き上げよう。