[レポート] Amazon のイノベーションのカルチャー /Amazon’s culture of innovation #reinvent #INO102

Amazon や AWS でのイノベーションがどのようなビジョンからもたらされているのかについてのセッションレポートです。
2022.12.05

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

こんにちは!Classmethod Canada オペレーションチームの Funa です。
今回は初の re:Invent で初参加のセッションだった「Amazon’s culture of innovation (INO102)」についてレポートします。

セッション概要

登壇者:Giulia Rossi, Principal Digital Innovation Lead, AWS

Amazon’s approach to innovation has remained consistent since the company first launched—start with the customer and work backwards. In this session, learn about Amazon’s peculiar culture and how Amazon innovates through four distinct, yet interdependent, elements: culture, mechanisms, architecture, and organization. Dive deep on each topic and learn more about practical applications, including Leadership Principles, working backwards, two-pizza teams, the PRFAQ doc, and why it’s always Day 1 at Amazon and AWS.

日本語化したものはこちらです。

Amazon のイノベーションへのアプローチは、会社が最初に立ち上げられたときから一貫しており、顧客から始めて、逆方向に作業を進めています。 このセッションでは、Amazon の独特の文化と、文化、メカニズム、アーキテクチャ、および組織という 4 つの異なる、しかし相互に依存する要素を通じて、Amazon がどのようにイノベーションを行っているかについて学びます。 各トピックを深く掘り下げ、リーダーシップの原則、逆方向の作業、2 枚のピザのチーム、PRFAQ ドキュメント、Amazon と AWS で常に Day 1 である理由など、実際のアプリケーションについて詳しく学びます。

セッション動画

セッション内容

どんな企業においてもビジネスモデルの存在は不可欠です。ただ、ビジネスモデルにおいて「核」となる不動のものを持たないとどこかでブレが生じてしまいます。

例えば、ライバル企業がこの分野を抑えているから、この技術が今は流行りだから...といった視点でビジネスモデルを作ると、ライバル企業が別分野に転換したときや技術の革新が行われた際に指針を失います。

では、Amazon や AWS の サービスやプロダクトの基幹となっているメカニズムは何でしょうか?それは創業当時から Day 1 メンタリティ です。

Day 1 メンタリティを 3 つの主なポイントに分けると以下のようになります。

  1. Customer obsessed (顧客志向)
  2. High quality, high-velocity decision (ハイクオリティで素早い意志決定)
  3. Experimental and disruptive(従来的な運用方法から脱して大胆なアクションを起こす)

それぞれについて説明していきます。

1. Customer obsessed (顧客志向)

Amazon が 1 番に掲げているミッションは「最も顧客中心の会社であること」です。 全ての Amazon の従業員は「顧客にとってベストなのは何なのか?」を考えて物事を決めることが定められています。

Working backwards

Amazon が顧客志向でいるための主なメカニズムの1つに Working backwardsがあります。

Working backwards

これは会社がどのような人材やリソースを持っている/時間やリソースが限られているからこのプロダクトを作って顧客に売ろう、ではなく、顧客にニーズがあるからプロダクトを作ってみるところから出発して、試行錯誤を重ねてビジネスモデルを修正していこうという考え方です。

このメカニズムをもとに Amazon はしつこいほどに継続して顧客の長期間のニーズを把握してビジネスモデルの改良を行っています。では長期間のニーズを絞り込むためにはどうするか?それは顧客への共感を持って深く知り込む(どのようなライフスタイルか、朝起きてから寝るまでどのように1日を過ごしているかなど)ことで生活を改善できる可能性があるポイントがあるかを探ることです。

Amazon が Eコマース、AWS、デバイス、ストリーミングなどたくさんのサービスを生み出しているのは長期間のニーズに対応するためです。

成長サイクル

顧客の長期間のニーズを理解したら、自分のプロダクトとポジションを差別化するであろう 3 つの要素を把握してそれをもとに成長サイクルを作り上げます。 wheel

Amazon の場合は以下の3つです。

  1. Price (価格)
  2. Selection (品揃え)
  3. Convenience (便利さ)

Amazon はカスタマーエクスペリエンスの最適化に集中することで顧客の満足度を高め、リピート利用する顧客を増やします。大勢の顧客の流入は売り手にとって魅力的なため、売り手が多く流入します。そこで発生するのが品揃えの向上です。この流れが生まれるとマーケットが成長するため、Amazon は低価格でのサービスの提供が可能となります。

これは AWS にも同様に当てはまります。AWS は 2006 年から 119 回の低価格化を実現し、200 以上のサービスを提供し、約 10 万のパートナーをもつに至っています。

2. High quality, high-velocity decision (ハイクオリティで素早い意志決定)

Amazon には顧客志向であり続けることを支える 16 のリーダーシップの原則があります。これは成長を続けていて、流動性のある Amazon での「共通言語」であり、同僚との認識の不一致を防ぎ、より素早いアクションを取るための方法です。

Invent and Simplify

16 のリーダーシップの原則の 1つに「Invent and Simplify」があります。これはまずは顧客に愛される最小限の機能を持たせた最初のプロダクトを出して顧客のフィードバックを待ち、そこから改良していくという考え方です。

例えば Kindle は現在の姿からかけ離れた、最適なカスタマーエクスペリエンスとは程遠い形でリリースされました。しかし、Amazon は「世界中のどこからでも 60 秒で本にアクセスできる」というビジョンが正しいことを素早く検証するために巨額の金を投じずにこれをマーケットに出す必要がありました。

Kindle がマーケットから良い製品だと認識されたため、顧客からのフィードバックをもとにチームは改良および改善を進めました。そしてこのセッションの 2 週間前には第 15 版の Kindle をリリースするまでにスケールしています。

Bias for Action

Bias for Action」は 必要なデータが 70% 揃ったら即座に決断を下そうという考え方です。なぜ 70% なのかというと、30% ではデータ不足によって顧客に愛されない、ただ利用可能なだけのプロダクトやサービスが生まれるリスクがあり、90% では機会損失や分析過剰につながるリスクがあるためです。

先に説明した Kindle はスケールして成功した例ですが、Amazon にはスケールしなかった場合は失敗を受け入れて立ち戻るというマインドがあります。それは新製品の開発に対してお金をかけていないこと、発明と失敗は切り離せない双子のようなものという認識があるために成り立っています。

Amazon Fire phone は Amazon が失敗から多くのことを学ぶ機会となったプロダクトの一つです。Fire phone の継続開発は終了となりましたが、この製品を開発していたチームは声やハードウェア、顧客はどのように声とハードウェアで交流したいのかに関する情報を蓄積できました。そしてローンチの 6 カ月後に Fire phone のコアチームは Alexa のチームに異動することになりました。このように失敗を受け入れて立ち戻ることで最終的には顧客の長期間のニーズを満たすことに成功しているのです。

3. Experimental and disruptive(従来的な運用方法から脱して大胆なアクションを起こす)

Working backwards を徹底するために、 Amazon ではプロダクトやサービスをローンチするまでの新プロセスを考案しました。

プレスリリース

そのうちの 1 つが部署の垣根を越えたチームを構成して何をビルドするか、なぜビルドする必要があるのかが簡潔に書かれた「プレスリリース」を製品を作り始める前に必ず完成させることです。

これはコードを書いた後に顧客のニーズと外れていたことが判明してプロダクトの開発が中止になるといった従来のプロセスから外れるため、エンジニアの貴重な時間が非効率に消費されることを防ぎます。また、全部署で同意のもとでプロダクトがリリースされるため、従来よりも速いスピードで承認が得られるだけでなく、より信頼性の高いプロダクトを世に送り出すことができます。

FAQ とビジュアル

また、プレスリリースだけではなく、「FAQ」と「ビジュアル」も同チームで作成されます。

FAQ はチーム間での質疑応答により製品の詳細まで踏み込むことを実現するために作成します。簡潔にまとめる必要があるプレスリリースとは異なり、こちらは 5・6 ページに渡り、どんなテクノロジーが必要か、どんな特徴を組み込む必要があるか、ビルドするのにパートナーが必要かなど具体的な内容にまで深く掘り下げます。

ビジュアルは製品がリリースされたことで顧客が得られるカスタマーエクスペリエンスのイメージとして描かれます。

プレスリリース、FAQ そしてビジュアル - この 3 つのツールを使用することで Amazon は顧客に寄り添ったプロダクトやサービスの作成を進めているのです。

2 つのピザチーム

Amazon は先に説明した部署の垣根を越えたチームを「2 つのピザチーム」と呼んでいます。2 つのピザチームは 7-10 人で 2 枚のピザをシェアしながらプレスリリースと FAQ 、ビジュアルを書き上げます。

2 つのピザチーム

ここでは各々がそれぞれの観点から意見を持ち寄って顧客志向を第一に責任を持って取り組みます。また、プロダクトがスケールすればビルドを行う際のコアチームになるため、ただのブレインストーミングではなくモチベーションをもって参加できます。一人の間違いはチームの間違いとしてオーナーシップをもって取り組むことが求められるのです。

感想

昔に大学で経営系の学科を卒業したので、「マーケティングを学ぶ」や「リーン・スタートアップ」でこのこと書いてあったな...みたいな思い出しが度々発生して懐かしい気持ちになりました。

Amazon のような世界的な大企業が顧客志向を維持するために実際に活用しているメカニズムを実例付きで知れて良かったです。また、2 つのピザチームは耳にしたことがあったものの、内部向けのプレスリリースを書くという取り組みをしているのは知らなかったので、ゴールから立ち戻っていくという発想に驚きました。非常に面白いセッションでした。