Working Backwards の実践 - PR/FAQ の書き方と Amazon 流プロダクト開発プロセス

Working Backwards とは

Working Backwards は、Amazon が 2000 年代初頭に確立したプロダクト開発プロセスです。技術やビジネスの都合を起点にするのではなく、理想的な顧客体験を最初に定義し、そこから逆算して何を作るべきかを明確にします。Jeff Bezos のリーダーシップのもと、スケールしてもイノベーションの質を落とさないための仕組みとして生まれました。このプロセスの中核にあるのが PR/FAQ というドキュメントです。コードを 1 行も書く前に、製品が完成した時点で発表するプレスリリースと想定 FAQ を書くことで、顧客にとっての価値が本当にあるのかを検証します。

PR/FAQ の構成と書き方

PR (プレスリリース) は 6 つの要素で構成されます。(1) 見出し: 顧客にとっての価値を一文で表現する。(2) サブ見出し: ターゲット顧客と主要なベネフィットを補足する。(3) 課題段落: 顧客が現在直面している課題を具体的に記述する。(4) 解決策段落: この製品がその課題をどう解決するかを説明する。(5) 顧客の声: 架空の顧客による推薦コメントを記述し、顧客の視点で価値を表現する。(6) 利用開始方法: 顧客が今すぐ始めるための具体的なアクションを示す。FAQ は外部 FAQ と内部 FAQ の 2 部構成です。外部 FAQ は顧客視点の質問 (使い方、料金、制約、既存サービスとの違い) に回答します。内部 FAQ は社内のステークホルダー視点の質問 (技術的実現性、開発コスト、収益モデル、リスク) に回答します。

ナラティブ文化と 6-Pager との使い分け

Amazon では会議で PowerPoint を使わず、ナラティブ (文章) 形式のドキュメントを使用します。箇条書きのスライドでは論理の飛躍や曖昧さが隠れやすいのに対し、文章で書くことで著者は思考を深め、読者は論理の整合性を正確に評価できます。会議の冒頭で参加者全員がドキュメントを黙読する時間を設け、全員が同じ情報を持った状態で議論を始めます。PR/FAQ と 6-Pager は用途が異なります。PR/FAQ は新しいプロダクトやサービスの提案に使います。まだ存在しないものの価値を検証するためのドキュメントです。6-Pager は既存の課題分析、戦略提案、年間計画など、現状の理解と方針決定に使います。いずれも最大 6 ページという制約があり、本質的な情報に絞り込む訓練になります。

AWS サービスへの適用事例

AWS の主要サービスの多くが Working Backwards プロセスを経て開発されています。たとえば、S3 は「開発者がスケーラブルなストレージを API 一つで利用できる」という顧客体験から逆算して設計されました。Lambda は「サーバーを一切管理せずにコードを実行したい」という顧客の声から生まれました。このプロセスは新サービスだけでなく、既存サービスの機能追加にも適用されます。顧客から寄せられた要望を PR/FAQ の形で整理し、チーム内でレビューすることで、本当に顧客にとって価値のある機能かどうかを開発前に判断します。PR/FAQ が説得力を持たない提案は、技術的にどれほど興味深くても開発に進みません。

自社プロジェクトへの導入

Working Backwards は Amazon 固有のものではなく、どの組織でも導入できます。最初のステップは、次に開発する機能やサービスについて PR/FAQ を書いてみることです。見出しで顧客価値を一文にまとめられない場合、そのプロジェクトの目的が曖昧である可能性があります。課題段落で顧客の課題を具体的に記述できない場合、顧客理解が不足しています。FAQ で技術的実現性やコストに答えられない場合、検討が不十分です。PR/FAQ を書くこと自体が、プロジェクトの成否を左右する重要な思考プロセスになります。チーム全員で黙読しフィードバックする文化を定着させれば、開発着手後の手戻りを大幅に削減できます。

この分野について体系的に学びたい方は、関連書籍 (Amazon) も参考になります。