あなたの会社では、プレスリリースをいつ作成するでしょうか
多くの企業が、当然のプロセスとして「商品を開発し、販売計画が立ってから」作成するだろう。しかし、Amazonは違う。この“逆順”の発想には、新規事業を考える上で参考になる点が多い。
株式会社シフト・ビジョンが探る、イノベーションのヒント。今回焦点を当てるのは、Amazonが実践する「プレスリリース先行」という独自のアプローチである。
「作ってから売る」ことが常識とされる中、なぜ彼らは「完成前にプレスリリースを書き上げる」という手法をとるのか。背景には、「良いものを作ったのに売れない」という、多くの企業が抱える問題がある。
「開発主導」か、「顧客価値の逆算」か
新規事業が市場で立ち行かなくなる理由は何か。 一つの大きな理由として考えられるのが、機能開発が先行しすぎて、「誰のための商品なのか」が後回しになるケースではないだろうか。
一般的なプロセスでは、企画を立ち上げ、機能を詰め、開発へと突き進む。そしてリリースが目前に迫って初めて、「これをどう市場にアピールするか」を考え始める。だが、この時点ではすでに「何を作るか」は固定化されている。結果として、「そもそもなぜこのプロダクトが存在すべきなのか」という存在意義が問われないまま、市場へと投下されてしまうケースもある。
本質を問うプロセス「Working Backwards」
そこでAmazonは、発想の順番自体を変えた。同社を象徴する「Working Backwards（逆算思考）」と呼ばれる手法である。
彼らのプロダクト開発は、要件定義でも仕様設計でもなく、「プレスリリースを執筆すること」から始まる。
開発が進行するにつれ、作り手は往々にして「自分たちが作りたいもの」や「技術的に可能なもの」へと視野を狭め、いつの間にか「顧客が本当に求めていたもの」から乖離していく。Amazonは、このズレが起きにくい進め方を採用している。
まずプレスリリースを書き、想定されるFAQを網羅し、顧客体験をビジュアルとして描き出す。Amazonでは、開発そのものより、「顧客にどんな価値を届けるのか」を先に固めることが重視されている。
そこでは、「誰の、いかなる課題を解決するのか」「既存の代替手段と何が違うのか」「顧客の日常をどう変革するのか」といった本質的な要素が問われる。さらに、価格の妥当性、実現可能性、競合優位性など、あらゆる角度からの厳しい反論に耐えうる解答を用意しなければならない。
このプロセスの本質は、これらすべての重い問いに対する決着を、「コードを一行も書く前」につけてしまう点にある。ここで説明しきれないアイデアは、まだ整理不足と見なされることもある。
なぜ「書くこと」がイノベーションを生むのか
この進め方には、いくつか大きな利点がある。第一に、莫大なサンクコスト（埋没費用）が発生する前に、撤退という高度な意思決定が可能になる点である。プロジェクトは一度動き出すと、「ここまで投資したのだから」という心理が働き、容易には止まらない。しかし、プレスリリースを執筆しただけの段階であれば、比較的低コストで方向転換できる。
第二に、思考の解像度が高まる点である。会議では魅力的に聞こえる企画でも、文章にすると急に弱く見えることがある。 主語が曖昧だったり、価値がぼやけたりするからだ。 実際に書いてみると、企画の弱さに気づくことも多い。
競合ではなく「顧客」を起点にする文化へ
なぜ、ここまで手間をかけて「逆」から考えるのか。それは、社内に「顧客中心主義（Customer Obsession）」を徹底させるためである。理念をスローガンとして掲げるのではなく、業務プロセスとして顧客視点を強制する。こうした積み重ねが、企業文化につながっていく。
多くの企業は、競合他社が新しい機能を出せば、それに対抗しようとする。競合の動向や技術トレンドはもちろん重要である。しかし、それらはあくまで補助的な情報に過ぎない。最終的な判断基準は、「顧客にとって意味があるかどうか」である。
AmazonのWorking Backwardsは、競合の動向を一度シャットアウトし、「顧客が何を望んでいるか」という一点に思考を強制的に集中させる。「顧客の喜び」を最初に文章化してしまうため、開発の途中で「競合が似たようなものを出したから、こっちの機能を追加しよう」といったブレが生じにくくなる。
この前提が共有されることで、組織の意思決定はシンプルになる。「顧客に価値があるか」が判断基準になりやすい。
実務への落とし込み｜小さく試す（中堅企業の実践ケース）
この手法は大企業の専売特許ではなく、むしろ、リソースが限られている企業ほど有効である。導入にあたって重要なのは、完璧を目指さないことだ。まずは一つの案件で、仮のプレスリリースを書き、そこから想定される質問を10個程度洗い出したうえで、チーム内でレビューする。
シフト・ビジョンでは、このAmazonのイノベーション手法から得たヒントを、実際の企業課題に適用するアプローチを提唱している。例えば、この「書くプロセス」を開発の最上流に導入した場合、プロジェクトの軌道がどのように修正され得るのか。2つのシミュレーションを勘案した。
シミュレーション1：機能追加から「サービス化」へ転換する産業機械メーカー（B2B） ある中堅の機械メーカーが、競合に対抗するため「最新のIoTセンサーを搭載した高機能モデル」の開発を計画しているとしよう。ここで、開発の前にプレスリリースを書くプロセスを導入してみる。すると、訴求すべき顧客のメリットが「データが画面で見られる」というありきたりな表現に留まってしまうことに気づくはずだ。 そこで「顧客は本当にただデータを見たいのか？」と問い直すことで、工場長が真に求めているのは「機械が突然止まらないこと」だという核心に行き着く。その結果、企画は単なる「IoT搭載機の販売」から、「ダウンタイムをゼロにする24時間の予知保全サービス」へと見直され、提供価値そのものを見直すきっかけになる。
シミュレーション2：作り手の「こだわり」を捨てる食品メーカー（B2C） 地方の老舗食品メーカーが、新規にD2C（直販）の定期便サービスを立ち上げるケースを想定してみよう。一般的な企画会議では、往々にして「伝統の製法」や「システム構築の予算」ばかりが議論されがちだ。しかし、ここで「顧客が思わず誰かに話したくなるプレスリリース」を先に書くよう要求されたらどうなるだろうか。 作り手の歴史を語るだけでは、顧客が毎月お金を払う理由にはならないという残酷な事実が浮き彫りになる。そこから「働く親の夕食準備を毎日20分短縮する、完全調理済みのパーソナライズ惣菜」といった顧客起点の価値へと再定義され、ターゲットもパッケージングも一から設計し直すという企画の方向性が大きく変わることもある。
これらの例が示すように、このプロセスを一度回すだけでも、アイデアの質は明確に変わる。特に重要なのは、「文章にできるか」を一つの基準にしている。書けないのであれば、それはまだ考え切れていないということである。
未来の顧客に向けた「一枚の文書」から始まる
イノベーションの領域では「早く試して、早く失敗する（Fail fast）」ことの重要性が説かれるが、実際のプロダクト開発における失敗の代償は決して小さくない。
だからこそ、コードを一行も書かず、プロトタイプすら作らず、まずは一枚の文章で、アイデアを検証する。
Amazonという巨大企業のシステムを、そのまま模倣する必要はない。取り入れられるのは、「未来の顧客が熱狂する姿を、真っ先に言語化する」という哲学である。
コメント