ARR 0ドルから700億ドルへ：AWSのプロフィール

2002年、アマゾンはクラウド・インフラストラクチャ・アズ・ア・サービスというサイドビジネスを立ち上げました。それから20年後、アマゾンの年間売上は700億ドルを超えました。巨大なビジネスです。実際、AWSの多額の利益はアマゾン全体の50％以上を占めています。

アマゾンの至宝です。偉大なビジネスがひしめくコングロマリットの中で、最高の存在です。AWSの最初のリーダーの一人であるアンディ・ジャッシーは、今やアマゾンのCEOになりました。

だから、AWSは有名な話だと思うでしょう。そうではありません。この記事を書いている間に雑談した私の家族のほとんどは、AWSの名前すら聞いたことがありませんでした。

それに比べ、コカ・コーラの2021年の売上高は約400億ドルでした。AWSはコカ・コーラの2倍近い売上を達成する勢いですが、その陰に隠れています。売上40億ドルの小さなZoomでさえ、もっとよく知られています。

さらに、AWSの歴史について書かれていることは、滑稽なほど間違っています。テッククランチをはじめとするほとんどの主要メディアは、AWSはアンディ・ジャッシーの「インターネットOS」構想の後、2003年に始まったと書いており、サービス自体は2006年に開始されたとしています。

どちらの「事実」も完全に間違っています。Wayback Machineのようなサイトやキャッシュのような技術に助けられたインターネットのパンくずは、決して消えることはありません。AWSが最初にローンチしたのは2002年で、コリン・ブライヤーが率いていました。

年間売上高700億ドルを超えるビジネスにとって、会社の明確で正しい歴史がないのは不可解です。

しかし、だからこそ私はProduct Growthニュースレターを書き、今日最も重要なテクノロジー・ビジネスのプロダクトストーリーを伝えているのです。ストライプ、ペイプル、コインベース、カヤックで行ったように、AWSが業界を征服するために使用したプロダクトビジョン、戦略、ロードマップについて記録を正すつもりです。

今週は特に、ルチンとトップ・オブ・ザ・ラインのチームとのコラボレーションを紹介できることに興奮しています。彼らは、プロダクト主導の成長に関する最高のニュースレターを書いており、自身もセコイアから1500万ドルのシリーズAを調達したばかりです。AWSを分析するのにこれ以上のメンバーはいません。

我々はこの4ヶ月間、5,000億ドル以上の企業価値を持つであろうこの巨大企業の本当の歴史とプロダクトに関する教訓を得るために、深く掘り下げてきました。それでは、本題に入りましょう。

この記事は、「From 0 to $70B ARR: The AWS Profile」を著者の了承を得た上で翻訳したものです。

著者：Aakash Gupta
翻訳者：渡辺圭祐

教訓 1：強みをプロダクト化する

1998年、アマゾンはまだ若い会社でした。その4年前にスタートしたアマゾンは、飛躍的な成長を遂げました。しかし、そのような成長の渦の中で、同社は常に次の1年の計画を立てていました。先のことを考えるのは現実的ではありませんでした。

その結果、コードベースはほとんど混乱していました。ビデオストリーミングのような新機能を追加するためのコードベースの変更には、本来必要な時間よりもはるかに長い時間がかかりました。同社はエンジニアを増員していましたが、物事をより速く構築することはできませんでした。

このようなフラストレーションを痛感した事業部門のひとつが、アマゾンの新しいeコマースサービス（Merchant.comとして知られる予定）でした。サイト上のあらゆるものが単一のモノリスに構築されているため、開発をサポートするには無理がありました。

その結果、「分散コンピューティング宣言」という社内エンジニアリング文書が作成され、広く回覧されました。それは伝説となりました。そしてイニシアティブは勢いを増しました。APIはMerchant.comの開発環境をよりスムーズにするために機能しました。APIはスピードと難易度の両方の問題を解決するのに役立ちました。

具体的には、サービス・アーキテクチャは3つの重要な進化を遂げました：

マイクロサービス・アーキテクチャ・パターン
1対1のデータベースとマイクロサービスのマッピング
各チームが独立してリリースできるようにした

これらの進化は非常に劇的で価値あるものであったため、2000年までには会社全体がこれに取り組むようになりました。アマゾンは、十分に文書化された一連のAPIを備えた「サービス企業」に意識的にシフトしました。

アマゾンはこれらのAPIアクセスシステムを無駄なく効率的に構築しました。倹約を中核的価値観とするベゾスのリーダーシップの下で、これらの社内サービスは、代替オプションと比較してかなりのコスト優位性を持って構築されました。

社内チームのためにこのような優れたオプションを開発することに成功した同社は、外部マーケットをテストすることになりました。2002年3月、コリン・ブライヤーに率いられ、同社は最初のAWSプロダクトをリリースしました。これは、アフィリエイト・マーケターをターゲットにしたものでした。SDK（ソフトウェア開発キット）は、アマゾンのプロダクトカタログに関する広範なデータを照会することを可能にしました。

このプロダクトはすぐに成功を収めました。アフィリエイターだけでなく、開発者からの関心もすぐに集まりました。

この機能をリリースして文字通り数時間後、私たちは何か大きなものを掴み、私たちの実験が私たちの期待をはるかに超えるものになることを知りました。
コリン・ブライヤー

世界中の開発者が、新しいウェブサイトやアプリケーションを開発するためにウェブサービスを利用していました。あるサイトでは、カバーアートに関するクイズが出題されました。また、気まぐれなbaconizer.comは、アマゾンのカタログにある2つのプロダクトのつながりをマッピングしました。

AWSの最初の機能は、メディアサイト向けのリッチなサービスとなりました。

教訓 2：逆算せよ

アフィリエイト・サービスはヒットしましたが、そのプロダクトはすでに提供されていません。それはAWSの始まりの機能ではあったが、AWSをグロースさせる機能ではありませんでした。そのために、アマゾンのリーダーシップは、ベゾスの哲学の重要な信条に立ち戻る必要がありました。

逆算のプロセスは、基本的な洞察から始まります。顧客は常にそれ以上のものを求めています。ジェフが言うように、「顧客は美しく、素晴らしく、不満足です。」

逆算は、この不満の震源地から発せられます。まず、顧客の不満の場所を明確に定義します。次に、チームは顧客のために逆算して発明する。最後に、3つの核となる成果物を作成する：

プレスリリース – ペインポイントを解決するプロダクトを発表する。プロダクトが本当に売れるように説得力を持つまで、繰り返し作成する。
FAQ文書 – PRリリースに付随する補足文書で、社内関係者や潜在顧客からの予測可能な質問に答える。
カスタマーエクスペリエンスを視覚的に表現することで、イノベーションの終着点を明確にする。

AWSチームはこれら3つをリアルタイムで完成させました。その年の7月、チームはアマゾンの有名なプレスリリースの1つをリリースしました。これは、私たち外部のオブザーバーが見ることのできる、貴重なプロダクトの成果物のひとつです。

このプレスリリースの注目すべき点は、最初の2段落に、今後20年以上にわたるAWSのビジョンが凝縮されていることです：

本日、Amazon.com（Nasdaq: AMZN）は、開発者とウェブサイト所有者のために特別にデザインされた革新的なウェブソリューションとサービスを作成するためのプラットフォームである「Amazon.com Web Services」の最初のバージョンを開始しました。

開発者は、Amazon.com Web Services (www.amazon.com/webservices) を利用することで、Amazon.comのユニークな機能の数々をWebサイトに組み込むことができるアプリケーションやツールを無料で構築することができます。
プレスリリース

2002年当時、AWSチームはすでに逆算して動いていた証拠です。アフィリエイト機能は、開発者が自分のウェブサイトにアマゾンのユニークな機能を組み込むための、将来のプラットフォームの「最初のバージョン」に過ぎないと認識していたのです。

逆算は一見シンプルですが、明確さを強制し、単に作るために作ること（「ビルドトラップ」）を防ぐのに役立ちます。AWSにとって、チームの視野を実際の顧客のニーズ解決に絞ることができました。Inc. 誌は、逆算を「アマゾンの秘密兵器」とまで呼んでいます。

このワーキング・バックワード・プロセスの結果、初期のAWSプロダクトは2002年から2003年にかけて利用が伸び続け、同様のサービスに対するマーケットの需要が実証されました。アマゾン幹部は、分散コンピューティング・マニフェストとAWSの両方の成功に気づきました。

2003年にジェフ・ベゾスの自宅で行われたリトリートで、経営陣は自社のコアコンピタンスを特定するための演習を行いました。サービスとしてのインフラが特に高く評価されました。彼らは、アマゾンが信頼性が高く、スケーラブルで低コストのインフラを運用することに特に長けていることに気づきました。

そこで彼らは、本格的なAWSイニシアチブを構築するために、アフィリエイト機能にさらに投資することを決定しました。

教訓 3：レゴブロックを作る

本格的なAWSへの投資の一環として、ジェフは最も信頼できる幹部の一人であるアンディ・ジャッシーをプロジェクトに投入しました。アンディはこの仕事に慣れるにつれて、コンピュート、ストレージ、データベースにおける会社の強みをピンポイントで指摘しました。彼はまた、これらがウェブスケール・アプリケーションの3つの重要なビルディング・ブロックであると認識しました。

そのビジョンを明確にするために、彼はこれを「インターネットのためのオペレーティング・システム（OS）」と呼び始めました。これがAWSのプロダクトビジョンとなりました。ジャッシーは、ビジネスとエンジニアリングの混成チームを結成し、イニシアチブを開始しました。

2003年の間、チームの主な目的のひとつは、既存のユーザーから学ぶことでした。コリン・ブライヤーは、AWSの最初のローンチ前のこの時期を、エンジニアがコードを書かない実質18ヶ月間だったと表現しました。

その代わり、チームの目標はユーザーのニーズを深く理解することでした。アマゾンはデータのユーザーを対象としたカンファレンスを開催しました。8人が集まりました。しかし、そのうちの1人が、AWSのもう1人の重要な初期採用者となります：彼は現在もチーフ・エバンジェリストとして同社に在籍しています。

ジェフはAWSのニュースブログを立ち上げ、ほぼ毎日記事を書き続けています。彼は、アマゾン S3やAWSの機能をレゴブロックのように拡張する何千もの記事を書いてきました。これらの投稿は、社内外で、モダンなインターネットアプリケーションのためのビルディングブロックとしてのAWS機能の共通理解を構築するのに役立っています。

ユーザーリサーチと、ジャッシーが「10人の優秀な技術者と10人の優秀なプロダクトマネージャー」と表現するような基本的な技術的洞察により、チームは初期のプロダクトロードマップをレゴブロックで作成しました。

一方、2004年半ばまでに、5万人の開発者がオリジナルのアフィリエイト向けアマゾンSDKをダウンロードしました。100以上のアプリケーションが構築されました。

チームはSDKに続いて2つのベータサービスをリリースし、ウェブOSのビジョンを達成し始めました：アレクサ・ウェブ・インフォメーション・サービス（AWIS）とシンプル・キュー・サービス（SQS）です。AWISはプロダクトカタログの自然な進化でした。現在は終了しています。

SQSは現在も存在しています。SQSは、開発者がメッセージング・ミドルウェアを保守する必要なく、マイクロサービスをデカップリングしてスケールできるようにします。インターネットのOSレイヤーを構築する上で重要な役割を果たしました。

教訓 4：使用量に応じた価格

AWSのプロダクトは、2005年まで、ほとんどの部分が無料のベータ機能でした。その年の間に、チームは次のユーザーケースを理解することに集中し、それらの機能をベータ版から本格的なプロダクトへと卒業させました。

ウェブOS戦略の2つの至宝であるコンピュートとストレージは、秘密保持契約の下で顧客に提供されました。ベータ・テスターはこの2つを気に入りました。そこでジャッシーとチームは、優れたプロダクトと優れた価格モデルを組み合わせる必要があると考えました。

彼らは最終的に、使用量に基づいた価格を設定することに決めました。これが基本的な洞察となりました。使用量ベースで低価格のサービスを提供することで、AWSは最新のガレージ・スタートアップからフォーチュン500の大企業まで、あらゆる人に対応できるようになりました。

利用料金は最も民主的な価格モデルの一つでした。これは、最近ネットフリックスがユーザーに対して未使用のサブスクリプションをキャンセルするような顧客フレンドリーな動きを思い起こさせます。AWSを使い忘れても、請求書が届くことはありません。AWSから価値を見出せないのであれば、利用をやめればいいのです。

この価格モデルを最初に採用した象徴的な機能は、アマゾンのストレージプロダクトでした。2006年3月、アマゾンはシンプル・ストレージ・サービス（S3）をリリースしました。事実上無限に拡張可能で、安価で、オンラインで利用可能という、アマゾンの開発者が長年にわたって利用してきたタイプのストレージを、あらゆる開発者が利用できるようにするものでした。これは、ジャッシーのウェブOSに向けた第2のステップでした。

使用量に基づく価格設定について特に注目すべき点は、このサービスがスタートアップにとっていかに魅力的であったかということです。スタートアップの開発者がS3の機能をどのように説明したかは、傾聴に値します。S3は他のどのサービスよりもはるかに優れていました。

私たちがアクセスできるものには、S3が提供できるような機能に少しでも似たものは何もありませんでした。誰かがキャンディストアの鍵をくれたような気がしました。
2006年、スタートアップFilmmakerLiveでS3を利用したドン・アルバレス氏

大企業であれば、S3よりも安価なオンプレミスのストレージソリューションを社内で構築できることも多いです。しかし、スタートアップにとっては、データセンターを構築するための初期固定費は高すぎました。つまり、エアビーアンドビー、ピンタレスト、ストライプのような世代のスタートアップにとって、S3は明らかに優れた選択肢だったのです。

その年の後半、アマゾンはウェブOSの次に重要なコンポーネントであるコンピートを発表しました。Elastic Compute Cloud（EC2）は、S3からわずか4ヶ月後の8月にリリースされました。S3がどんな開発者にもアマゾンスタイルのストレージを提供したのに対し、EC2は事実上無限にスケーラブルで、安価で、オンラインで利用可能なコンピュートを提供しました。

基本的に、EC2アマゾンは、開発者がデータセンターで仮想コンピュータを借りることを可能にしました。これらのコンピューターで、開発者は自分のアプリケーションを実行することができます。1時間10セントで、「ウェブスケール」のアプリケーションを実行するためにコンピュータをスケールアップする簡単で比較的安価な方法でした。

オンラインで利用できることが重要で、そのデータは信頼性が高く、安全でもありました。当時、スタートアップがアマゾンと同じサービスを作ることはできたかもしれませんが、アマゾンの名前に支えられていなかったため、それほど成功しなかったでしょう。

S3と同様、EC2もほぼ瞬時にプロダクト・マーケット・フィットを証明しました。2つのプロダクトの成功の結果、同社は2006年に2,100万ドルの収益を計上することになりました。同社が長年にわたり多くの新プロダクトをリリースしてきたにもかかわらず、コンピュートとストレージは、その後10年以上にわたってアマゾンの収益の大半を占めることになりました。

教訓 5：積極的に長期的に考える

EC2とS3によって、アマゾンはサービスとしてのクラウド・インフラストラクチャマーケットを切り開きました。現金が流れ込んできました。アナリストは経営陣に営業利益率について質問攻めにしました。経営幹部は、反論しました。しかし社内では、アマゾンの利益率が高いことを知っていました。アマゾンはそのマージンをビジネスに再投資し続けました。

その一例が地理的な拡大でした。米国でEC2のフル・パブリック・ベータを開始したわずか数週間後、アマゾンはヨーロッパを追加しました。もしスタートアップが最初の数週間でヨーロッパに進出したとしましょう。失敗するように仕組まれていると笑うでしょう。しかし、AWSはそれを実行しました。長期的な視野に立ち、大きな投資をしました。そして成功しました。

これは長期的思考ではありません。これは積極的な長期的思考でした。次の数四半期のことだけを考えていたわけではありません。数十年先を見据えた投資だったのです。

アマゾンは非常に積極的に動くことを強く信じている。
クリス・ピンカム、2000年代前半のアマゾン・インフラストラクチャーのエンジニアリング責任者

その数カ月後、アマゾンは地理的な拡大に続き、またもや爆発的なプロダクト投入を行いました。コンピュートとストレージに続く、ウェブOSの次のコンポーネントはデータベースでした。アマゾンは、EC2とS3の上にHadoop（ハドゥープ）テクノロジーを使用したアマゾン SimpleDBを発表しました。

2006年から2007年にかけて、チームはウェブOSの重要な構成要素であると決定された3つのプロダクト、すなわちコンピュート、ストレージ、データベースのすべてを発表しました。アマゾンがこれほど短期間で幅広いサービスを立ち上げたのも、長期的な視野に立った積極的な姿勢の賜物です。

同社はまた、長期的な視野に立った価格設定も行いました。競合他社を「シャットアウト」するため、マージンは極限まで薄く抑えられていました。

2007年までには、開発者のウェブサイトはすでにAWSを恐ろしい「テッククランチ問題」の解決策として宣伝していました。あるスタートアップは、テッククランチに取り上げられると、100倍、あるいは1000倍のトラフィック負荷を経験することになります。しかし、オンプレミスのコンピュートとストレージ・システムでは、そのトラフィックをサポートすることができませんでした。サイトがクラッシュするのは、まさに訪問者が最も多いチームでした。

その結果、2008年にグーグルがAWSの真の競合となる最初のプロダクトをリリースした時、その評判はそれほど高くありませんでした。グーグルApp Engineの最初のプロダクトには、インフラだけでなく、ユーザー認証やメール送信のためのグーグルAPIのセットや、フル機能のローカル開発環境が含まれていました。

しかし、これらの機能はAWSの勢いを止めることはできませんでした。App Engineは1日の使用量の上限が低かったのです。ウェブスケールには対応できていませんでした。ゲームに2年近く遅れたことは、その結果を招きました。アマゾンは2008年に限定的なサービスを提供したグーグルを超えていました。その年、AWSはベータ版サービスから本サービスへの移行に忙殺されました。

グーグル・クラウドがベータサービスを開始したのと同じ年に、EC2はサービス・レベル・アグリーメント（SLA）付きのパブリック・リリースを開始しました。アマゾンは、コンピュート・サービスがいつでも99.95％のリクエストに対応できるという驚くべき約束をしました。これにより顧客は、最大規模のアプリケーションであってもAWS上で確実に実行できるという確信を得ました。App Engineがスタートアップをターゲットにしている間に、EC2は中堅企業を経て企業へと移行していきました。

2009年までに、この戦略は見事に成功しました。AWSがサクセスストーリーになることは明らかでした。ジェフは年次書簡の中で、このビジネスラインを大きく取り上げています：

私たちはアマゾン・ウェブ・サービスに心から投資しています。
ジェフ・ベゾス

しかし、AWSはこの事業から利益を搾り取るのではなく、現金を流し続けました。これは、いくつかの注目すべきプロダクトの発表で明らかになりました。

コンピュート・サービスを拡張するために、アマゾンは処理ツールをリリースしました。4月にはElastic MapReduce（EMR）を発表しました。EMRは膨大なデータを素早く処理することを容易にしました。そして5月には、コンピュートのスケーリングを容易にするプロダクト群をリリースしました。Elastic Load Balancing（ELB）、Auto Scaling、CloudWatchは、開発者が急成長や「テッククランチ問題」をよりうまく管理するのに役立ちました。

アマゾンはストレージ事業も軽視していませんでした。同月、アマゾンはImport/Expertサービスもリリースしました。これにより、ユーザーはS3にデータを取り込みやすくなりました。

アマゾンはコンピュートとストレージの大々的な立ち上げに続き、第3の事業としてネットワーキングを開始しました。8月、アマゾンはVirtual Private Cloud（VPC）を発表しました。VPCによって、顧客はEC2インスタンスを独自の分離されたネットワークに立ち上げることができます。これは劇的なヒットとなりました。

このようなプロダクト発表が相次ぐ中、2010年2月、ついにクラウドインフラマーケットにおける第3のビッグプレーヤーが登場しました： Microsoft Azureです。その時点で、AWSはすでに長い間先行していました。アジアに進出していたのです。なぜなら、AWSは積極的に長期的な視点に立っていたからです。

教訓 6：顧客と深く付き合う

グーグルやマイクロソフトのクラウド・チームが初期オファリングの準備に忙殺されている間、アマゾンは2010年に顧客のニーズについてより深く学ぶことに使いました。チームは、特に2つの重要な顧客との実践的な統合をサポートしました：ネットフリックス（今日の時価総額：850億ドル）とオートデスク（今日の時価総額：400億ドル）です。

AWSは、ネットフリックスとオートデスクのすべてのトラフィックをAWSに移行する方法を学ぶために働きました。それは、ネットフリックスとオートデスクのエンジニアリングチームと密接に関わるプロセスでした。これは、アマゾンのリーダーシップ原則である「カスタマー・オブセッション」の典型的な例でした。

深く付き合うことが功を奏しました。2010年末までに、ネットフリックスのトラフィックの大半はAWSによってサポートされるようになりました。当時のエンジニアリング担当副社長はこう書いています：

我々はクラウドコンピューティングが未来だと考えています。
ネットフリックスエンジニアリング担当副社長ジョン・チャンクッティ氏

AWSは、クラウドが未来であることを世界に証明することができました。その成功を生かすため、AWSはユースケースを広げました。

2010年には、Simple Notification Service（前述のグーグルメールAPIに対抗するため）、CloudFormation（宣言型Infrastructure as Codeツールの初期の例）、Route 53（API経由でアクセス可能なドメインネームシステム）など、一連のプロダクトが発表されました。

AWSがどのようにして何度も何度も正しい機能を選択したのかという質問に対して、ジャッシー氏はチームがどのようにプロダクトロードマップを構築したかを説明しました。90%は顧客と深く付き合うことから、10%は顧客に代わって発明することから。

多くの企業が顧客重視を謳っていますが、実際にそれを実践している企業はほとんどありません。私たちのロードマップと開発の90%は、顧客が重要だと述べることに基づいています。残りの10%は、顧客が言おうとしていることに耳を傾け、その間にある意味を読み取り、彼らのために革新しようとしています。
アンディ・ジャッシー

急成長しているウェブ2.0企業と多くの時間を過ごすことで、アマゾンは彼らのニーズに合ったプロダクトロードマップを作成することができました。

このことはアナリストの目にも明らかでした。ガートナーがクラウド・インフラストラクチャ・アズ・ア・サービスとウェブ・ホスティングのマジック・クアドラントを発表したとき、アマゾンはビジョンの完全性という点で最高位にランクされました。

当時の競合は主にウェブ・ホスティング・プロバイダーで、その多くはサービスとしてのインフラマーケットから撤退しています。AT&T、Rackspace、ベライゾン、これらはテクノロジーのDNAを持たないネットワーク・プロバイダーです。もうクワドラントでは見かけなくなりました。

アマゾンは競争の弱さを心配する代わりに、顧客にこだわることに集中しました。

実際、チームがその年に焦点を当てた3番目の顧客は、自分自身（アマゾンの小売事業）という極めて重要なものでした。信頼性、バックアップ、スケーリングなどです。これらの障害を解決するために機能を追加し、またもや成功しました。2010年末までに、アマゾンリテールはウェブサービスをAWSに完全に移行したと発表しました。

ネットフリックス、オートデスク、アマゾンリテールをAWSに移行した後、チームはセールスマシンのスイッチを入れる自信を得ました。

教訓 7：理想の顧客のために構築する

完全なクラウドSaaSを提供するためのすべてのコンポーネントが整ったことで、アマゾンは2011年から2015年にかけて、一流のセールス実行力をそのプレイブックに加えました。もちろん、同社は急速なペースでプロダクトを発表し続けましたが、この時期に最も注目すべきことは、より大規模な顧客を獲得するために、意図的かつ高価なアウトバウンドセールスを開始したことです。

しかし、ただ万人向けに作ったわけではありません。皆のために作ることは、誰のためにもなりません。

セールスにはICP（理想顧客像）という概念があります。アマゾンの顧客は、どの分野でも2位か3位のプレーヤーでした。彼らは、変革的なITを受け入れる可能性が最も高い人たちでした。一方、No.1のプレーヤーは、現在のソリューションに自信を持ち、基幹システムの根幹を引きちぎってアマゾンの手に渡すことを避けたいと考えている可能性がはるかに高いのです。

これにより、プロダクトチームと営業チームは、獲得したい3,500の指定アカウントに集中できるようになりました。そのためにAWSは軍隊を配備しました。ジャッシー氏がAWS re:Invent 2016で明らかにしたように、AWSはフィールドセールスとソリューションアーキテクチャチームに数千人を抱えていました。

AWSが営業チームを劇的に強化するようになった理由の1つは、競争でした。2013年までに、AzureはガートナーのInfrastructure as a Serviceにフォーカスした新しいクアドラントに登場しました。右下からスタートしたAzureは、2014年にはAWSのすぐ後ろにまで急浮上し、グーグル・クラウドも登場しました。それ以来、アマゾンが切り開いたマーケットに挑み続けているのが、この2社、そして遠く4番手に続くIBMです。

2012年から2015年にかけて、ガートナーは合計24の新規参入企業を分析しています。これらのプレーヤーが問題に資金を投じる一方で、AWSはすでに大規模な利益を上げていました。

教訓 8：新プロダクトのフライホイールを作る

2013年、VentureBeatは「Amazon’s ‘mountain of margin‘ in cloud services（アマゾンのクラウドサービスにおける「莫大な利益」）」という記事を掲載しました。それによると、同部門の粗利益率は80％を超えていました。

このマージンの多くは、10年前にチームが構想したオリジナルプロダクトの1つであるEC2がもたらしたものです。EC2がこのような多額のマージンを生み出すために用いた手法には、次の2つがあります：

プロダクトを廃止しないこと
将来の使用に対する予約の割引を顧客に許可すること

どちらもやや直感に反します。ほとんどの企業は古いプロダクトを非推奨とし、メンテナンスの複雑さを軽減しています。しかし、AWSは古いサーバーを大切に扱いました。オフラインにする代わりに、新しいマシンよりも安いコストで顧客に提供したのです。

将来の予約を許可することも、直感に反しますが有用です。クラウドをオンラインにするために必要なハードウェアの量を予測しやすくなるからです。そうすることで、コストをコントロールすることができます。つまり、顧客とAWSの双方にとってメリットがあります。

EC2以外にも、AWSの利益を大きく左右するのがデータ転送です。帯域幅のコストは下がり続けていますが、AWSはデータ転送料金を同じ価格で請求し続けています。

EC2、データ転送、その他の既存プロダクトから得たこの利益はすべて、チャレンジャー・プレーヤーが覇権を握るための新プロダクトに投入されました。2013年、アマゾンはストリーミング・データをリアルタイムで処理するKinesisをリリースしました。これによって、アナリストはデータが起こっているときにそれを見ることができるようになりました。

これは私のような元ゲーミングPMには必須です。フォートナイトのイベントがあったとき、何人のプレイヤーがオンラインになったかを知る必要がありました。このようなデータのニーズは重要ですが、計算コストがかかります。

AWSインフラストラクチャの上に構築されたこの種のアプリケーションは、それ自体で大きな請求書を鳴らし、インフラコストでも大きな請求書を鳴らすという利点があります。

同様に、2014年にAWSはAWS Lambdaでサーバーレスの概念を導入しました。Lambdaを利用する顧客は、EC2コストのほぼ2倍を支払うことになります。

これは、「AWS新プロダクトフライホイール」を生み出します。AWSは新プロダクトをリリースし、顧客がより多くのビジネス価値を生み出せるようにします。これにより、AWSのインフラプロダクトに対する需要が継続的に増加し、その結果、同社はさらに多くの新プロダクトの開発資金を確保できます。それぞれの活動が次の活動を生み出します。

フライホイールは、多額の利益を生み出すためにも機能します。規模が大きくなれば、すべてを再投資する必要はありません。2016年までには、AWSはアマゾンの総利益の原動力として十分に重要な存在となり、同社は年次報告書にAWSを記載するようになりました。

それ以来、アマゾンはAWSの驚異的な粗利益率を活用し、アマゾンの他の事業の原資となる営業利益率を高めています。AWSはコストセンターからプロフィットセンターへと変貌を遂げました。700億ドルという驚異的なARRで、営業利益率は約30％であり、さらに増加しています。

教訓 9：顧客のために成功を定義する

過去10年の終わり頃、マーケットにおけるAWSのリードは崩れ始めていました。IBM、グーグル、マイクロソフトなどがクラウド・コンピューティングに大きな賭けをし、それぞれのサービスを強化し始めました。

特にマイクロソフトは、このマーケットに多大な進出を果たしました。実際、マーケットアナリストのCloud Warsは、クラウド収益においてマイクロソフトがアマゾンを上回ると評価しています。

マイクロソフトが2019年に米軍の100億ドル規模のJEDI契約を獲得したことを受けて、AWSは営業人員を倍増すると発表しました。この営業戦略の転換は、戦争の叫びでした。

AWSの営業チームは、プロダクトの営業チームと同様に、顧客の目を通して成功を定義しました。実際、これはOBAM（Outcome-Based Account Management）として広く知られ、公表されている4段階のプロセスとして公式化されています：

探索：見込み客のデジタル戦略、外部要因、課題、機会に関する広範な調査に基づいて価値仮説を立案する。
関与：信頼と信用を獲得し、リードの適格性を確認し、最初の価値提案を提供する。顧客の成熟度は、組織構造、調達/法務の仕組みなどに基づいて評価される。
共感：組織文化、さらには個人的な意図、個人のコミュニケーションスタイルに基づき、各リードにオーダーメイドで適合するものを特定する。この段階は関係構築に重点を置いている。
支援：AWSリソースの役割と責任、アカウントのバリュープロポジションを具体化する。

OBAMは、プロダクトチームのワーキングベークワーズアプローチに非常に似ています。営業チームが顧客のために成功を定義することにかかっています。

そして、安っぽい名前にもかかわらず、それは非常にうまくいっています。

教訓 10：政府から必要とされるほど優秀になる

JEDI契約を失って以来（現在はキャンセルされている）、AWSは公共部門で驚異的な成長を遂げています。主な契約は以下の通り：

国家安全保障局との100億ドルの契約
CIAとの5億ドルの契約
NASAとの6500万ドルの契約

AWSは、ITソフトウェア調達の経験を持つ元政府高官を少なくとも66人雇用しています。これにより、AWSは調達プロセスにおいて優位に立つことができます。

元政府調達担当者は、「『提案依頼書』プロセスに関連する官僚主義に精通している」ため、アマゾンの契約獲得に役立っています。相手側にいたことのある人物は、RFP提案がどのように競争的に検討され、分析されるかを正確に知っています。私たちが優位に立てるのはそこです。
ハゼム・エルダクドキー、AWSのシニア・テクニカル・プログラム・マネージャー、元DOJ司法省副最高情報責任者

2021年、エコノミック・タイムズ紙は、「AWSの公共部門ビジネスでは、過去3年間、毎年従業員数が倍増している。AWSは今後数年間、大規模な成長を予測している。」と出版している。

AWSは政府から必要とされるほど優秀な企業となったのです。そして、それは米国政府だけではありません。AWSはオーストラリアからジンバブエまで、世界中の政府と大規模な契約を結んでいます。

要点

ある事業分野で大きな成功を収めた既存のテック企業が、新たな事業分野に進出するのは最近では本当に珍しいことです。アマゾンはAWSでそれを見事に実現しました。まさに新しいビジネスラインを切り開いたのです。アマゾンのプロダクト立ち上げとビジネス成長の真の歴史を学ぶことで、私たちは時代を超越した10のプロダクト成長の教訓を得ることができます。