プレスリリース駆動開発とは — コードより先に「発表文」を書くAmazon発の開発手法

グラレコ

まずはこの1枚に、記事全体の要点をまとめました。「逆から作る」という発想、PR/FAQの構成、レビューで使う5つの質問、日本での実践例までを描いています。詳細はこれから順に見ていきます。

🗞️ はじめに

プレスリリース駆動開発（Press Release Driven Development）は、プロダクトや機能を作り始める前に、完成したと仮定してプレスリリースを書いてしまう開発手法です。Amazonが社内で実践している「Working Backwards（ワーキング・バックワーズ）」というプロセスの中核で、PR/FAQ（プレスリリースとFAQ）という文書を書くことから企画が始まります。

コードも仕様書もまだ何もない段階で、「本日、〇〇をリリースしました。これにより顧客は〜」という架空の発表文を書きます。ちょっと不思議なやり方に見えますが、Kindle や AWS など、2004年以降のAmazonの主要プロダクトの多くがこのプロセスを通って生まれたとされています。

この記事では、次のことを紹介します。

• プレスリリース駆動開発（Working Backwards / PR-FAQ）の考え方と生まれた背景
• PR/FAQ の具体的な書き方テンプレートと、レビューの回し方
• 日本企業での実践例（スプリントにプレスリリースを組み込む運用）
• README駆動開発などの類似手法との違いと、AI時代ならではの活用のしかた
• 明日から小さく試すための導入ステップ

対象読者は、プロダクト開発やチーム開発に関わるエンジニア・PMの方です。「頑張って作ったのに、思ったほど使われなかった」という経験が一度でもある方には、特に刺さる内容だと思います。

🔄 プレスリリース駆動開発とは

普通の開発は「作ってから発表する」

まず、一般的な開発の流れを整理します。多くのプロジェクトは、アイデアから始まって、要件定義 → 設計 → 実装 → テストと進み、最後にリリースと発表があります。

以下の図は、この一般的な流れを示したものです。

プレスリリース（顧客向けの発表文）を書くのは一番最後です。この順番自体は自然なのですが、1つ問題があります。「顧客にどんな価値があるのか」を言語化するのが最後になるため、作り終えてから「あれ、これって誰が喜ぶんだっけ……」と気づくことがあるんですね。実装に数ヶ月かけた後でこれに気づくのは、かなりつらいものがあります。

Working Backwards は「発表文から逆走する」

Working Backwards は、この順番を文字どおり逆にします。以下の図がその流れです。

最初に書くのは、ローンチ日の視点で書かれた架空のプレスリリースです。まだ存在しないプロダクトについて、「どんな顧客の、どんな課題を、どう解決するのか」を発表文の形式で具体的に書きます。そこから逆方向に、FAQ、顧客体験の定義、マニュアルと、実装に近い文書へ降りていきます。

この順番にする理由は、Amazon CTO（2006年当時）のWerner Vogels氏の言葉がいちばん端的です。氏は2006年のブログ記事で、プレスリリースから始めることで「世界からこのプロダクトがどう見えるかが明確になる（自分たちにどう見えるかではなく）」と説明しています。

作り手は、どうしても「実現したい技術」や「作りたい機能」から発想しがちです（私も含めて、エンジニアは特にそうだと思います）。プレスリリースという形式は、書き手を強制的に顧客の側へ立たせる装置なんですね。

「書けないアイデア」を早期に落とすフィルター

もう1つの重要な役割が、アイデアの選別フィルターです。

Amazonでプロダクト責任者を務めたIan McAllister氏は、この手法についてこう言い切っています。

If the press release is hard to write, then the product is probably going to suck.
（プレスリリースが書きにくいなら、そのプロダクトはたぶんダメだ）

魅力的なプレスリリースが書けないアイデアは、顧客価値が曖昧だということです。それを実装前に、紙の上で発見できます。McAllister氏はさらに「プレスリリースの反復は、プロダクトの反復よりずっと安くて速い」とも述べています。数時間で書ける文書を10回書き直すのと、数ヶ月かけたプロダクトを作り直すのとでは、コストが文字どおり桁違いです。

📜 生まれた背景 — 2004年のAmazon

プレスリリース駆動開発は、思いつきで生まれたわけではありません。書籍『Working Backwards』（Colin Bryar・Bill Carr著、邦訳『アマゾンの最強の働き方』）によると、Working Backwardsのプロセスは2004〜2005年ごろのAmazon社内で、試行錯誤の末に確立されました。

当時のAmazonも、最初は普通のやり方で新規事業を検討していました。SWOT分析や市場規模の調査、損益計算のシミュレーションといった手法です。しかし、こうした「会社側の都合」を積み上げる分析では、顧客にとって本当に価値があるものかどうかを判断できなかったそうです。その反省から、「顧客体験の定義から始めて、そこから逆向きに考える」プロセスへと転換していきました。

このプロセスの効果を語るうえでよく引き合いに出されるのがAWSです。Jeff Bezos氏とAndy Jassy氏がWebサービスを重要な新技術と位置づけたのは2004年ですが、S3とEC2がローンチされたのは2006年でした。この間、PR/FAQの作り込みに1年以上を費やしたとされています。じっくり文書を磨いてから作り始めたサービスが、その後20年にわたってクラウド市場を牽引しているわけで、「書く時間」への投資としてはかなりのリターンだったと言えそうです。

最初に公開されたのは4つの文書

Working Backwardsが社外に紹介された最初期の資料が、先ほども触れたWerner Vogels氏の2006年11月のブログ記事「Working Backwards」です。そこでは、実装を始める前に書く文書として次の4つが挙げられています。

以下の図は、この4文書の流れを示したものです。

ポイントは、4つとも「顧客が読む（読みうる）文書」だということです。設計書やアーキテクチャ図といった内部文書ではなく、顧客に見える面をすべて先に書き切ってから、中身を作り始めます。Vogels氏はこのアプローチを、各サービスチームを「大企業の壁の中の小さなスタートアップ」として扱う思想の一部だと説明しています。

📝 PR/FAQの書き方

ここからは、実際にPR/FAQをどう書くかを見ていきます。PR/FAQは大きく「プレスリリース本体（1ページ程度）」と「FAQ（複数ページ）」の2部構成です。

全体の構造を図にすると、次のようになります。

この図のとおり、プレスリリースは「見出しから引用まで」の決まった流れで書き、FAQは読み手によって外部向けと内部向けに分かれます。

プレスリリース本体：9項目テンプレート

書き方のテンプレートとして最も広く参照されているのが、Amazonでプロダクトを率いたIan McAllister氏がQ&AサイトのQuoraで共有したものです。9つの項目で構成されます。

#	項目	書くこと
1	見出し（Heading）	顧客に伝わる言葉でのプロダクト名
2	サブ見出し（Sub-Heading）	対象顧客と最大のベネフィットを一文で
3	サマリー（Summary）	続きを読まない人にも伝わる概要
4	課題（Problem）	解決する顧客の課題。顧客の視点で書く
5	解決（Solution）	プロダクトがどう鮮やかに解決するか
6	自社の引用（Quote from You)	責任者・スポークスパーソンのコメント
7	始め方（How to Get Started）	どれだけ簡単に使い始められるか
8	顧客の引用（Customer Quote）	架空の顧客が体験を語るコメント
9	締めとCTA（Closing and Call to Action）	まとめと、読者への次のアクション

面白いのは8番です。まだ存在しない顧客の、まだ存在しない体験談を書きます。「この機能のおかげで毎週3時間の作業がなくなりました」のようなセリフを具体的に書けるかどうかで、顧客像の解像度が試されます。ここがふわっとしか書けないときは、たいてい顧客のこともふわっとしか分かっていません。

長さの鉄則：1.5ページを超えたら長すぎる

McAllister氏はテンプレートと合わせて、長さについても明確な基準を示しています。

• プレスリリースが1.5ページを超えたら長すぎる。1段落は3〜4文に
• 「Cut out the fat. Don't make it into a spec.（贅肉を削れ。仕様書にするな）」

プレスリリースはあくまで「顧客に伝わるか」を検証する文書なので、機能を網羅する必要はありません。むしろ書きたい機能を全部盛り込みたくなったら、それは焦点が定まっていないサインです。

課題と解決の段落には「型」がある

書籍『Working Backwards』の著者らが運営するサイトでは、解決の段落について次のような型が紹介されています。

今日、この課題を持つ顧客は x, y, z といった製品を使っている。それらは〜という点で課題を解決しきれていない。本製品は、これらの満たされていないニーズに次のように応える。

この型が優れているのは、「現状の代替手段」への言及を強制するところです。顧客には必ず現状のやり方があります（手作業かもしれませんし、Excelかもしれません）。それに触れずに書いたプレスリリースは、「乗り換える理由」の検証をスキップしてしまっているわけです。

架空の例：社内ツールのプレスリリース

イメージをつかむために、架空の例を1つ載せます。社内のデプロイ作業を自動化するツールを企画したと仮定した、ミニ版プレスリリースです。

# Deploy Butler — レビュー承認からデプロイ完了まで、人の手をゼロに

## 承認済みPRの手動デプロイ作業に毎週2時間かけている開発チーム向けの、
## デプロイ自動実行サービス

2026年10月1日 — 開発基盤チームは本日、Deploy Butler の提供を開始しました。
承認済みのPRを検知して、ステージング検証から本番デプロイまでを自動で実行します。

**課題**: これまで各チームは、PRが承認されるたびにデプロイ手順書を開き、
6ステップの手作業を実施していました。作業自体は単純ですが、
週あたり平均2時間を消費し、手順ミスによる切り戻しも月2回発生していました。

**解決**: Deploy Butler は承認をトリガーに全ステップを自動実行します。
進捗はSlackに通知され、異常時は自動でロールバックします。

**利用者の声（想定）**: 「金曜夕方のデプロイ当番がなくなりました。
手順書のことはもう思い出せません」（プロダクトチームのエンジニア）

**始め方**: リポジトリに deploy-butler.yml を1ファイル置くだけです。

このくらいの分量でも、「誰の・どんな課題を・どう解決するのか」「導入は簡単か」が一望できます。逆に、この形式で書こうとして手が止まる箇所（利用者の声が思いつかない、課題の数値が書けない等）が、企画の弱点そのものです。

FAQは「外部」と「内部」の2種類

プレスリリースが夢を語る文書だとすると、FAQは現実と向き合う文書です。2種類に分かれます。

種類	想定読者	質問の例
🌍 外部FAQ	顧客・メディア	価格は？ どう動作する？ サポートは？ どこで使える？
🏢 内部FAQ	社内ステークホルダー	コストは見合う？ 技術的リスクは？ 成功指標は？ 競合との差は？ 法務・運用面の課題は？

内部FAQには、財務・マーケティング・オペレーション・法務など各部門から飛んできそうな厳しい質問を、先回りして書いておきます。「都合の悪い質問こそ先に書く」のがコツで、ここで手を抜くとレビュー会議でそのまま突っ込まれます（そして書き直しになります）。

🔍 レビューの回し方

PR/FAQは一人で書いて終わりの文書ではなく、レビューと書き直しを何度も繰り返して磨いていく文書です。Amazonでの育て方には特徴的な型があります。

初稿は数時間、磨くのは数ヶ月

初稿はプロダクトマネージャーが一人で、数日ではなく数時間で書くとされています。そこからレビューの輪を段階的に広げていきます。

以下の図は、PR/FAQが磨かれていく典型的な流れです。

点線がすべて初稿に戻っているのがポイントです。各段階で容赦なくフィードバックが入り、書き直しが発生します。Amazonの成功したプロダクトの多くは、PR/FAQが固まるまでに数ヶ月かかったとされています。それだけ書き直しても、プロダクトを作り直すよりは圧倒的に安い、という割り切りです。

会議の最初の15〜20分は「黙読」

レビュー会議の進め方も独特です。

1. 文書を事前に共有しておく
2. 会議の冒頭15〜20分は全員で黙読し、コメントを書き込む
3. 残りの約40分で、順番に、あるいはページごとに議論する

プレゼンではなく黙読から始めるのは、話のうまさではなく文書そのものを評価するためです。会議の姿勢としては「売り込みではなく真実の探求」「決定ではなく改善」が掲げられています。書き手を論破する場ではなく、アイデアを一緒に強くする場だ、という設計ですね。

判定に使う「5つの質問」

レビューで文書を評価する観点として、5つの質問が知られています。正確には、出典ではこれに「TAM（市場規模）と投資回収は十分か」「解決すべき制約は何か」の2項目を加えた7項目が挙げられていますが、顧客価値の検証という意味での中核は次の5つです。

以下の図は、この5つの質問をチェックフローとして表したものです。

個人的に、いちばん厳しくて重要なのは4番だと思います。「あったら便利」と「行動を変えてまで使う」の間には深い谷があります。顧客には現状のやり方があり、乗り換えにはコストがかかります。その谷を越えるだけの価値をプレスリリースで語れているか、が問われます。

🇯🇵 日本での実践例：スプリント運用型

ここまではAmazonの「企画の意思決定」としてのプレスリリース駆動開発を見てきました。一方、日本では少し違うアレンジの実践例が公開されています。LayerXのエンジニアブログで紹介された、スプリントにプレスリリース執筆を組み込む運用です。

月曜に書いて、金曜に検査する

LayerXのデータチームでは、1週間スプリントの中でこう運用しています。

以下の図は、その1週間の流れです。

書くのは「今週や今月に開発する機能・改善」についてのプレスリリースです。AWSの「What's New」ブログ（新機能を顧客価値ベースで短く紹介する記事群）をモデルにしていて、文書の構成は次の4点とされています。

• 新機能によってできるようになったこと
• いままでどうだったか
• 顧客にとっての価値
• 使い始めるためのドキュメントリンク

効果としては、①顧客へのメッセージを明文化することで開発目的の解像度が上がる（使われるものづくり）、②チーム内の認識統一と実装の動機づけ、③月報など外部発信の素材が自然に貯まる、の3点が挙げられています。なお、記事の時点で「3週間の試行段階」と明記されており、確立された定番手法というよりは、公開されている挑戦の記録として読むのがフェアです。

Amazon式とスプリント型は「別物」と考えたほうがよい

同じ「プレスリリース駆動開発」という言葉でも、この2つは目的もタイミングも異なります。混ぜると混乱するので、表で整理しておきます。

観点	🅰️ Amazon式（PR/FAQ）	🅱️ スプリント型（LayerX式）
書くタイミング	作るかどうかを決める前	作ることが決まった後、スプリント計画時
主な目的	アイデアの検証・選別	チームの目線合わせ・動機づけ・発信
分量	PR約1ページ + FAQ複数ページ	短い発表文（What's New風）
レビュー	数ヶ月かけて何度も書き直す	週次のスプリントレビューで検査
落とす機能	ある（書けない企画は中止）	基本はない（作る前提の運用）
向いている場面	新規プロダクト・大きな投資判断	継続的な機能開発・社内向け開発

Amazon式は「作らない」という結論を出すための重い仕組み、スプリント型は「作るものの価値を見失わない」ための軽い仕組み、と言えます。どちらが正しいというものではなく、投資の大きさに応じて使い分けるのが実用的です。

⚖️ 「先に書く」系手法との違い

「コードより先に文書を書く」というアイデア自体は、プレスリリース駆動開発の専売特許ではありません。似た発想の手法と比較しておくと、位置づけがはっきりします。

以下の図は、「先に書く」系の3手法を、書く文書と想定読者で整理したものです。

表でも比較します。

手法	先に書くもの	想定読者	検証できること
README駆動開発	README（使い方）	コードを使う開発者	API・インターフェースの使いやすさ
ドキュメント駆動開発	仕様・ドキュメント全般	開発者・利用者	仕様の明確さ・一貫性
プレスリリース駆動開発	発表文 + FAQ	顧客・世の中	顧客価値そのもの

README駆動開発は、GitHubの共同創業者Tom Preston-Werner氏が2010年に提唱した手法で、「コードより先にREADMEを書く」ことでインターフェースの設計を先に固めます。発想はよく似ていますが、視点の高さが違います。README駆動開発が検証するのは「この関数は使いやすいか」で、プレスリリース駆動開発が検証するのは「そもそもこれは世の中に必要か」です。

つまり、この3つは競合ではなくレイヤーの違いです。プレスリリースで「作る価値」を確かめ、READMEで「使いやすさ」を確かめてから実装する、という重ね掛けも普通に成立します（さすがに文書が多すぎて息切れしそうなので、規模に応じてですが）。

🤖 AI時代のプレスリリース駆動開発

2026年現在の視点で、もう1つ考えておきたいことがあります。LLMの登場で、「もっともらしいプレスリリースを書くこと」自体は一瞬でできるようになりました。では、PR/FAQのドラフトをAIに書かせるのはアリなのでしょうか。

結論から言うと、丸投げはナシ、壁打ちはアリだと考えています。

思い出したいのは、この手法の検証機能が「書く苦しみ」に宿っているという点です。「利用者の声が思いつかない」「課題を数値で書けない」という手の止まり方こそが、企画の穴を教えてくれるシグナルでした。AIに丸投げすると、どんなに空っぽな企画でも流暢なプレスリリースが出てきてしまい、このシグナルが消えます。McAllister氏の「書きにくいプレスリリースの製品はたぶんダメ」という判定条件が、そもそも成立しなくなるわけです。

一方で、書く過程を補助する使い方はかなり相性が良いです。以下の図は、PR/FAQのプロセスの中でAIが役に立つ場面を整理したものです。

この図のポイントは、本文を書く主体は常に人間側にあることです。AIが担うのは3つの脇役です。

• 壁打ち相手: 「この顧客は具体的に誰？」「その課題は年間何時間の損失？」のように、解像度を上げる質問をさせる
• 意地悪な質問役: 内部FAQに載せるべき厳しい質問（コスト、リスク、競合、法務）を大量に出させる。人間は自分の企画に甘い質問をしがちなので、ここはAIの遠慮のなさが活きます
• 模擬レビュアー: 書き上げたPR/FAQを5つの質問で採点させ、人間のレビュー会議に出す前の素振りにする

とくに2つ目はおすすめです。試しに自分の企画に対して「Amazonの内部FAQレビューで飛んできそうな質問を20個挙げて」と頼んでみると、目を逸らしていた質問が何個か必ず混ざっています（そして大抵、いちばん答えたくない質問がいちばん重要です）。

💡 明日から試すには

最後に、この手法を自分のチームで小さく試す方法を考えます。いきなり「今日からAmazon式のPR/FAQで意思決定します」と宣言するのはハードルが高いので、段階を踏むのがおすすめです。

以下の図は、導入のステップ案です。

ステップ1: まず一人で、次の提案をプレスリリース形式で書く

最初のステップに承認は要りません。次に何か機能を提案する機会があったら、提案資料の冒頭に、McAllister氏の9項目を簡略化した次の3ブロックを書いてみてください。

• 課題: 誰が、いま、どう困っているか（できれば数値付きで）
• 解決: この機能で何ができるようになるか
• 利用者の声（想定）: 使った人が言いそうなセリフを1つ

所要時間は30分もかからないと思います。それでも、「利用者の声」がどうしても書けない提案が一定数あることに気づくはずです。その気づきだけで、この手法の元は取れます。

注意点：うまくいかないパターン

一方で、この手法には知られた落とし穴もあります。

⚠️ 落とし穴	対策
書くことが目的化する	プレスリリースは検証の道具。「書けたから作る」ではなく5つの質問で判定する
文章力・仮説構築力への依存が大きい	高い文章力と仮説構築力が要る手法なので、最初はレビューで補い合う前提で始める
基盤系・社内向けでは顧客が見えにくい	「利用者＝社内の開発者」と置いて書く。LayerXの例はまさにこのケース
全機能に適用して息切れする	投資判断が必要な大きめの企画に絞る。小さな改善はスプリント型の短い発表文で十分

特に1つ目は本末転倒になりやすいポイントです。美しいプレスリリースを書くことがゴールではなく、書く過程で顧客価値の穴を見つけることがゴールです。すらすら書けてしまったときほど、5つの質問（特に「顧客は行動を変えてまで使うか？」）に戻って疑うくらいでちょうどいいと思います。

❓ よくある疑問

最後に、この手法を紹介したときによく出てくる疑問に、FAQ形式で答えておきます（PR/FAQの記事なので、締めもFAQでいきます）。

Q1. アジャイル開発と矛盾しませんか？ 先に文書を固めるのはウォーターフォールでは？

役割が違うので併用できます。PR/FAQが決めるのは「何を・誰のために作るか」で、アジャイルが扱うのは「どう作り進めるか」です。実際、PR/FAQで方向を固めたあとの開発をスクラムで回すことに何の矛盾もありません。むしろ北極星となる文書があるぶん、スプリントごとの優先順位判断がぶれにくくなります。ウォーターフォールとの違いは、固めるのが「仕様」ではなく「顧客価値」である点です。仕様は開発中に変わってかまいません。

Q2. 書いたプレスリリースは、実際のリリース時に公開するのですか？

Amazon式のPR/FAQは社内文書で、そのまま公開するものではありません。ただし、リリース時の実際の発表文やドキュメントの下書きとして流用できることは多いです。LayerXのスプリント型のように、書いた発表文を月報や社内発信にそのまま使う運用もあります。

Q3. 個人開発でも意味がありますか？ レビューしてくれる人がいないのですが

意味はあると思います。個人開発こそ「作りたいものを作ってしまって誰にも使われない」が起きやすい領域なので、着手前に30分のプレスリリース執筆を挟む価値は大きいです。レビュアーがいない問題は、前のセクションで紹介したようにAIを模擬レビュアーにすることである程度補えます。

Q4. 書いた後に、開発中に内容が変わってしまったら？

変わって問題ありません。PR/FAQは一度書いたら凍結する契約書ではなく、学びに応じて更新する生きた文書です。大事なのは、変わったときに「この変更後でも、顧客は行動を変えてまで使うか？」を問い直すことです。文書を更新せずに実装だけが変わっていくと、せっかくの北極星が現在地とずれた星になってしまいます。

Q5. 全部の開発タスクでやるべきですか？

やらないほうがいいです。フルセットのPR/FAQは、投資判断が必要な大きめの企画のための重い道具です。バグ修正や小さな改善にまで課すと、確実に形骸化します。目安として、「数週間以上の開発工数がかかる」「作らないという選択肢がありうる」ものに絞るのが現実的だと思います。

🎁 まとめ

プレスリリース駆動開発について、Amazonでの原型から日本での実践例までを紹介しました。

• Working Backwardsは顧客体験の定義から逆向きに作るプロセスで、その最初の成果物がPR/FAQ
• プレスリリースは1.5ページ以内。書きにくいプレスリリースは、プロダクトの危険信号
• レビューは黙読から始め、5つの質問で判定する。文書の反復はプロダクトの反復より桁違いに安い
• 日本ではスプリントに組み込む軽量版の実践例もある。Amazon式とは目的が違うので使い分ける

いろいろ書きましたが、この記事から1つだけ持ち帰るなら、「次の企画の前に、30分だけ架空の発表文を書いてみる」をおすすめします。書けたら企画の解像度が上がりますし、書けなかったらそれは数ヶ月の実装が始まる前に見つかった、いちばん安い失敗です。どちらに転んでも得しかありません。

参考

• Working Backwards — All Things Distributed（Werner Vogels, 2006）
• The Amazon Working Backwards PR/FAQ Process — workingbackwards.com
• Product management at Amazon – What is it like?（Ian McAllister氏のQuora回答の転載）
• Amazon Product Management, Working Backwards — Brendan Sterne
• プレスリリース駆動開発のすゝめ — LayerX エンジニアブログ
• Working Backwards: How to Write an Amazon PR/FAQ — koji.so
• Readme Driven Development — Tom Preston-Werner
• 書籍: Colin Bryar, Bill Carr『Working Backwards』（邦訳『アマゾンの最強の働き方』）