AmazonCTOとの対話：アマゾン内部からのストーリー、インサイト、秘話

2023.06.30

共有先

TechFlow厳選深潮セレクト

AmazonCTOとの対話：アマゾン内部からのストーリー、インサイト、秘話

急速に成長する企業になりたいのであれば、従来の企業のようにしてはいけない。

2023.06.30 - 13:06:47

AmazonCTOYC

Web3業界の深掘り報道に専念し潮流を洞察

急速に成長する企業になりたいのであれば、従来の企業のようにしてはいけない。

編集：TechFlow

注：本記事は「TechFlow創業講座中国語ノート」シリーズに収録（毎日更新、本稿は同シリーズ最終話）。YC講座の中国語版を収集・整理することを目指しており、第25話はアマゾン最高技術責任者（CTO）Werner Vogels氏によるオンライン講義『技術とスタートアップに関する経験と洞察』である。

アマゾン入社前

アマゾンに入社する前、私は学者であり、コーネル大学で10年間の大規模分散システムに関する研究に従事していました。それ以前、典型的なコンピュータ科学者ではありませんでした。28歳になってようやく真剣に学問の道に進む決意をしました。それまでは病院で放射線治療技師として働き、オランダ癌研究所の患者に放射線治療を提供していました。ある日突然、身の回りの人々が次々と亡くなる現実に耐えられなくなり、全く異なる分野で働くことを決めました。コンピュータ科学は良い選択肢に思えました。

当時は1980年代半ばで、コンピュータ科学は今ほど普及していませんでした。しかし、結果的に私はこの分野に才能があることがわかりました。興味を持った以上、深く学ぶことにしました。博士号を取得後、ポルトガルの研究機関で数年働いた後、コーネル大学から招聘されました。

コーネル在籍中、研究活動以外にも、HPのような大手企業や他のいくつかの会社からの相談を受けたり、さまざまな会議に参加していました。あるとき、アマゾンから私が研究していたテーマについて紹介してほしいという依頼がありました。当初は驚きと戸惑いがありましたが、「本当に？　行くべきなのだろうか？」と思いました。

当時、ウェブブラウジングとデータベースはどれほど困難な課題だったでしょうか？　しかし実際に取り組み始めると、これが極めて大きな技術的挑戦であることに気づきました。アマゾンは単なる小売業ではなく、かつて見たこともない規模で運営されるテクノロジー企業でした。私の知る限り、他の相談先企業とは比較にならないほどのスケールです。分散システムの研究者の視点から見ても、彼らが直面する課題は驚異的でした。

アマゾンから職のオファーを受けたとき、私は迷わず受け入れました。

アマゾンの巨大な運用規模と技術的リード

多くの分散システム研究者は、大手企業がいかなる規模で運営しなければならないかを理解していると思います。インターネット企業やデジタル企業が成功するためには、巨大なスケールでの運営が必要不可欠です。

2004年に私がアマゾンに加わった時点を振り返ると、その規模での運用は比較的容易に思えるかもしれません。しかし、だからといって特定のポジションやインフラに甘んじることはできません。クラウド技術などの分野で多くの取り組みを行い、それらがもたらす利点を最大限に活用できるようにしました。

2004年のアマゾンは、実践を通じて一定の規模を達成しましたが、拡張可能な組織や企業の構築方法を説明する書籍やガイドラインは存在しませんでした。そのため、アマゾンは技術の応用、発展、運用規模において、5〜10年先を行っていたと考えます。これは急成長を志す企業にとって特に重要です。

急速な成長を遂げる企業になりたいなら、伝統的な企業と同じやり方はできません。伝統企業はしばしば「イノベーションのジレンマ」に陥り、一度成功すると動きが非常に鈍くなります。

持続的に急速に成長する企業をどう構築するかは、まったく別の物語です。ビジネスを慎重にバランスさせる必要があります。例えば、技術的負債を創出することや、繰り返し発生する事象を容認することは、効率性を最優先とする伝統企業では不可能です。

アマゾンでは、スピード、迅速なイノベーション、長期的な実験パイプラインが最も重要です。そのため、繰り返し発生する事象をある程度容認し、技術的負債を許容しても、それを返済する意思があれば問題ないと考えています。

そのため、伝統的なMBAの教科書には、アマゾンが行っているような妥協の記述はほとんど見つかりません。多くの場合、アマゾンは自ら技術、プロセス、ビジネスプロセスを開発してきました。もちろん、ジェフ・ベゾスのように未来の姿や現代社会のあり方を真に理解するビジョナリーなリーダーの存在も重要でした。

成長を実現する鍵

アマゾンはすでに規模で大きな成功を収めていますが、さらなる成長を実現するには新たな課題があります。次の成長段階へ進むためには、より厳密に思考し行動する必要があります。

一例としてパフォーマンスの問題があります。パフォーマンスをどのように測定するか？　どのようなインフラストラクチャが必要か？　真のデータ駆動型企業となり、データに基づいた意思決定を行うには、まずデータを保有し、測定データの評価と解釈の文化を築く必要があります。

たとえば、ページ読み込み時間がわずか1.2秒遅れただけでも、顧客体験に悪影響を及ぼします。これは顧客体験の50％が劣化することを意味し、状況の深刻さを理解する必要があります。工学的には、99％や99.9％の制御精度がさらに重要になります。そして、99％レベルの工学的原則を真正に掌握する仕組みを構築し、それをビジネス判断と結びつける必要があります。

2004年当時、私たちの信頼性は相当高かったと思います。特定の地域（SEA）のデータセンターを使用しなければならないなどのルールがあり、SEAデータセンターで行った操作はすべて他のデータセンターに複製されなければなりませんでした。これにより、あるデータセンターが故障しても顧客に影響が出ないようになっていました。

顧客は多少の遅延を受けるかもしれませんが、機能そのものは維持されます。こうしたルールの管理には非常に長けていましたが、ある日、データセンターの接続を切断して何が起こるか試してみることにしました。ネットワークを少し調整すれば、あるデータセンターを他から隔離できます。

しかし実際には、紙面上では完璧に見えるものも、実際には期待通りにはうまくいきませんでした。初回の試行時には、手動のデータベースフェイルオーバーなど多くの手作業プロセスが残っていました。私たちはその年を通して何度も予行演習を重ねました。3回目や4回目の実施時には、ほぼ人為的介入なしに自動化された運用が可能になるまでに至りました。これはシステムの高可用性とフォールトトレランスを確保するために極めて重要です。

私たちの取り組みの中では、データ分析とインサイトの発展にも力を入れています。アマゾンは膨大なデータを保有していますが、そこから価値ある知見を得ることは大きな課題です。顧客行動、市場動向、ビジネスチャンスを理解するため、強力なデータ分析ツールとモデルの構築に尽力しています。このようなデータ主導のアプローチにより、より良い意思決定が可能となり、パーソナライズされた製品やサービスを提供できます。

また、ユーザーエクスペリエンスの改善にも注力しています。買い物プロセスにおけるユーザーのニーズや好みを深く調査し、デザインの最適化、インターフェースの改善、パーソナライズされたレコメンデーションなどを通じてUXを向上させています。シンプルで直感的、シームレスなショッピング体験を追求し、顧客の期待に応え、忠誠心を獲得することを目指しています。

CTOの役割の変化

技術ベンダーとなった後、CTOの役割は変化します。

私はブログ記事でこの問題について述べました。CTOには4つの異なるタイプの役割があると考えています：

第一に、企業内インフラ管理を担当する企業型CTO。CIOに報告し、大量のインフラストラクチャを管理します。
第二に、若い企業によく見られる技術共同創業者型CTO。技術的ビジョンを持つ人物ですが、この役割にはリスクがあります。エンジニアリングチームのマネジメントなど多くの業務が含まれるため、必ずしもその人物が得意とは限りません。この点については後ほど詳しく触れます。
第三に、大思想家型CTO。イノベーションを推進します。AT&Tやルーセントのように、次世代技術の研究・実験を行うCTOまたはCTOオフィスを設置するケースです。
第四に、外部向け技術専門家型CTO。他社の技術ベンダーとして、顧客との深い技術的対話を担います。顧客が製品をどのように使っているかを理解し、より深いパターンや顧客の痛点を探ります。この役割は自社技術だけでなく、全体像を重視します。

これらの役割は、技術中心よりも顧客中心であることに注意が必要です。顧客のフィードバックを会社に持ち帰り、どのような新機能や製品を開発すべきか、あるいはどのプロセスを変更すべきかを検討することが重要です。

したがって、技術ベンダーとしてのCTOの役割は、より強い顧客志向を持ち、技術そのものに留まらないのです。

アマゾン特有の文化

アマゾンが私の最初の本格的な職場だったため、長い間他の企業もアマゾンと似た職場文化を持っていると思っていましたが、実際にはそうではありませんでした。

アマゾンには独特の文化があり、急速に成長する企業にとっては非常に効果的です。チームが可能な限り独立することを奨励し、組織の階層や構造を削減します。彼らにとってヒエラルキーは不自然なものとされています。

自己組織化されたチームを求め、本当に独立して働き、製品を所有したいと考える人材を採用します。若い企業には特にこの姿勢が求められ、追随者や単なるコーダーではない人材が必要です。

アマゾンには「顧客中心主義」「所有権」「深掘り」など14のリーダーシップ原則があり、これらが文化形成を推進しています。

アマゾンの採用面接では、主に文化的適合性が重視されます。文化に合わない従業員は小さなチームに大きな混乱をもたらすためです。アマゾンは通常10〜12人程度の小規模チームを高く評価しており、各メンバーが自分のタスクを明確に理解しています。

企業の成長とともに、CTOの役割も変化します。初期にはすべての技術関連事項を担当しますが、次第にチームマネジメントやエンジニアが要求される技術・製品を確実に提供できるようにすることに焦点を当てていきます。

VP of Engineeringと比べて、CTOは正しい技術の構築や適切なツールの使用といった技術面にさらに注力します。

アマゾンはどのように成長したのか？

アマゾン内部では一連の変化が起きました。スタートアップのように見える独立したチームを作り、それぞれが独自の目標とイノベーション計画を持っていました。しかし過去には、急速な成長のためにアーキテクチャの原則を無視し、バックエンドのデータベースインフラが脆弱になり、さらに拡張できなくなってしまいました。

効率低下を解決するため、サービス指向アーキテクチャ（SOA）に移行し、システムを独立した機能ブロック、つまりマイクロサービスに分割しました。

しかし、チームが増えるにつれ、各サービスが独自のデータベースを管理する必要があり、コミュニケーションは増えてもイノベーションは減少しました。

状況を改善するため、共有プラットフォームサービスを構築し、仮想化技術とAPIを使ってサーバーを管理しました。まずは社内でこれらの技術を開発し、その後Amazon S3やEC2として外部に製品化しました。これにより、ストレージと計算能力がプログラマブルかつ拡張可能になり、企業にとって非常にコスト効率が良くなりました。

アマゾンの目標は、インターネット規模のストレージと計算能力を実現し、あらゆる種類の企業にサービスを提供することです。

イノベーションの道

アマゾンのイノベーションは二つのレベルに分けられます：

第一にチームレベルのイノベーション。各チームが来年のイノベーション計画を立て、独立してタスクを完了します。たとえば、リコメンドエンジンを改良して返品率を下げるなどです。ロードマップの策定、新しいデータソースの取得、顧客との新たなインタラクション方法の模索などを担当します。
第二に、多額の資本投資を要するイノベーション。KindleやAmazon Primeなどが該当します。こうしたプロジェクトには巨額の資金が必要です。アマゾンは、イノベーションプロジェクトが成功する可能性があり、企業の貸借対照表に大きな影響を与える場合にのみ、大規模な資本投資を行うというルールを設けています。

アマゾンは、技術発展初期に下した決定の多くが賢明であったことに気づいており、規模が拡大するにつれてアーキテクチャを再検討し、変化に対応できるソフトウェアを開発しなければならないことを認識しています。これには、ストレージエンジンなどの技術的課題に対処するため、複数のアーキテクチャやバージョンの使用が含まれます。

また、他の企業と同様に、アマゾンも技術的スケーリングに加えて、販売、ソリューションアーキテクチャ、テクニカルカスタマーマネージャー、カスタマーサポートなど技術以外の要素を解決する必要があることに気づいています。これらは成功した企業を構築するために不可欠です。

新サービスの立ち上げ方法

すべてのチームが顧客と緊密に連携することを望んでいます。なぜなら、私たちが提供する機能やサービスの約95％は、顧客の直接的なニーズに応えるためです。当初構築した最初のサービスは、基本的なITインフラ、ストレージ、計算、データベース、ネットワーク、セキュリティなど、顧客のあらゆる期待をほぼ満たしていました。

しかし時間の経過とともに、顧客はさまざまな追加ニーズを提示しました。分析機能、クラウド技術、モバイル開発、そして現在のブロックチェーンなど、これらを使いながら管理したくないという要望です。そのため、顧客が正しい特徴やツールを構築できるように支援することが非常に重要になりました。

新しい製品やサービスをリリースする際、最小限の機能セット（MVP）で立ち上げるという強い文化があります。しかし、これはビジネスに必要な技術を構築するための出発点にすぎません。薄っぺらいものをリリースするのではなく、安定性と信頼性を確保しなければなりません。その後、顧客と共に他の機能のニーズを探ります。

製品の初期段階では、顧客が他のどのような機能を必要とするか常にわかっているわけではありません。たとえばDynamoDBをリリースした当初、顧客がセカンダリインデックスを望んでいるとは知りませんでした。最初は提供していませんでしたが、明らかに顧客が必要としていることがわかりました。最小機能セットでサービスを開始し、顧客の製品の使い方を観察しながら、段階的に新機能やサービスを追加していきます。

たとえばLambdaをリリースしたとき、サーバーレス環境として開発を簡素化し、コードを書いてS3にデプロイするだけでよく、サーバー管理などの煩雑さから解放されました。実際に使った分だけ支払い、アイドルタイムなどの心配は不要です。

この方法は開発プロセスを変えました。顧客の製品の使い方を観察できます。すぐにX線デバッグ環境のような手法で反復するようになり、ステップ関数を使ってより複雑なアプリケーションを構築し始めました。顧客の使用習慣を観察することでニーズを理解し、たとえばDynamoDBでは、セカンダリデータセンターよりも補助インデックスの方が顧客にとって重要だと気づきました。

基本的に、顧客が私たちのロードマップを再定義し、彼らにとって最も重要な機能を提供し始めました。これは極めて重要な部分です。MVPのように見えても、それをMVPと見なしてはいけません。人々はその上にビジネスを構築し、依存するからです。そのため、製品の周囲に異なる文化的構造が形成されます。

昨年、1400もの新機能・新サービスをリリースしました。チーム数が増えるにつれ、この数字は当然さらに増加します。AWSでも同じ構造を使用しており、各チームが特定の顧客グループと協力し、そのニーズに基づいてロードマップを構築しています。サービスが増えれば増えるほど、ロードマップも増えていきます。

しかし、これは急速に進む環境であり、ソフトウェアの構築方法は大きく変わりました。もし私たちが顧客にどのようにソフトウェアを開発すべきかを指示できるなら、おそらく今でも5年前や10年前と同じ方法で開発しているでしょう。逆に、顧客と密接に協力し、彼らに私たちのイノベーションエンジンを駆動してもらい、2020年や2025年からのソフトウェア開発方法を生み出す必要があります。

したがって、顧客のために意思決定を行うのではなく、密接に協力し、彼らにイノベーションエンジンを駆動してもらう必要があります。顧客が製品をどのように使うかを密接に観察し、フィードバックに基づいて継続的に反復・改善していく必要があります。

総じて、Amazon Web Services（AWS）はチームレベルと資本投資という二つのレベルでイノベーションを進めています。顧客と密接に協力し、そのニーズを理解し、使用習慣を観察することで、顧客の求める機能とサービスを提供できます。同時に、AWSは新たな製品、サービス、機能の研究開発とリリースに多額の資本を投入し、変化する市場ニーズに対応しています。

このイノベーション手法により、AWSは顧客と緊密な関係を維持し、安定的で信頼性が高く、顧客の期待に合致したソリューションを提供できます。最小機能セットでのリリース戦略と継続的反復により、AWSは顧客のニーズに迅速に対応し、より高度な機能とサービスを継続的に提供できます。

アマゾンのイノベーションの道は、常に進化し続けるプロセスであり、常に顧客中心に据えられています。顧客ニーズの深層的理解、使用習慣の観察、継続的な研究開発投資を通じて、AWSは技術とビジネスの前進を不断に推進し、卓越したクラウドコンピューティングソリューションを顧客に提供し続けています。

顧客主導の製品開発

私たちはどこにいても、顧客から始まるか、アマゾン内部から始まります。テクノロジー企業として、顧客にとって本当に重要なものを開発することに非常に注力しています。ヘビーテック企業ではありますが、エンジニアリング設計とエンジニア自身もリスクを負っています。

注目するのは技術ではなく、製品です。顧客に対して何ができるかを知りたいのです。驚異的な技術の構築に尽力していますが、それが唯一の原動力ではありません。顧客の問題を解決することに関心があります。

顧客への注力を維持するため、「逆方向作業（Working Backwards）」と呼ばれるプロセスを採用しています。まず、私たちが構築しようとしているものを、簡潔明瞭に記述したプレスリリースを作成します。次に、20個の一般的な質問を含むドキュメントを準備し、簡単な言葉でそれらに答えます。より複雑な場合は、この2つの文書を完全に内容が明確になるまで何度も修正します。

次に、ユーザーエクスペリエンス（UX）ドキュメントを作成し、顧客が製品をどのように使い、製品とどのように相互作用するかを詳細に記述します。ユーザーマニュアル、用語集などの関連文書も作成します。

最後に、私たちが行おうとしていることを正確に記述した4つの文書が完成します。

アマゾンとして、私たちは常にこの原則を守っています。請求額は約束した内容を超えない。バージョン2の機能をバージョン1に勝手に追加しない。約束した機能の構築に集中し、それだけに注力します。この方法は、顧客ニーズ、製品体験、技術などについて考えるための強固な枠組みを提供します。

アマゾンの会議では、スライドやプレゼンテーションを使いません。「6ページのメモ」と呼ばれる文書があり、会議開始の30分前に全員で黙読します。このメモは非常に重要で、誰もが議論内容を明確に理解できることを保証します。

物語を書くのは難しいため、協力とフィードバックを奨励しています。特性、製品、ビジネス領域を明確に記述できるまで、何度でも修正・改善します。30分の読了後、会議室にいる全員が同じ土俵に立っており、高品質な議論が可能になります。

要するに、私たちは独自の文化とプロセスを持ち、常に顧客の問題解決に注力し、卓越した製品とサービスを提供し続けています。

コンテナ技術

ますます多くの企業がコンテナ技術を飛び越えようとしています。特にマイクロサービス環境の発展を追い求める中で、コンテナ技術はコンポーネントのスケールアップ・ダウンが容易なため流行しました。多くの企業がモノリシック構造からコンテナ分解を始め、特にサーバーレス環境を中心とした開発に注力しています。

しかし、Fargateの登場以前には、コンテナ技術の利用にはいくつかの問題がありました。複数の可用性ゾーンで複数のコンテナを実行する必要があり、それらを仮想マシンにマッピングしなければなりませんでした。したがって、コンテナは優れた開発選択肢ですが、その運用・管理には依然として多大な労力が必要でした。このプロセスを簡素化するため、Fargateというソリューションを提供しています。これは基本的に基盤の仮想マシン管理をすべて排除し、コンテナを投入するだけで実行できるようにします。

将来、より複雑なサーバーレス環境を構築する能力を中心に、ますます多くのツール、サポートプラットフォーム、インフラストラクチャが開発されると考えます。他のサービスとのより良い統合が今後の方向性の一つとなるでしょう。

*TechFlow注：Fargateはアマゾンウェブサービス（Amazon Web Services、AWS）が提供するコンピューティングサービスで、サーバーレス（serverless）型のコンピューティングエンジンです。Fargateにより、開発者はコンテナ化されたアプリケーションを簡単に管理・デプロイでき、基盤インフラやサーバーの管理を気にする必要がなくなります。

コンテナ技術は仮想化技術の一種で、アプリケーションとその依存関係を独立した移植可能なコンテナにパッケージングし、アプリケーションの迅速な展開と移植性を実現します。コンテナエンジン（Dockerなど）を使用してコンテナの作成・管理・実行を行い、異なるコンピューティング環境でも一貫した動作を保証します。コンテナ化技術は現代のアプリ開発・展開で広く使われており、柔軟性、スケーラビリティ、ポータビリティを大幅に向上させます。

顧客の保護

しかし、セキュリティ問題が今後注目の的になると私は考えます。今後5年間、CEO、CTO、エンジニアを問わず、全員がセキュリティを最優先課題とすべきです。技術専門家として、デジタルビジネスの指導者として、毎週発生する大規模なデータ漏洩事件に対して恥ずかしく、怒りを感じるべきです。顧客データの保護は私たちの責任です。顧客を守らなければ、ビジネスそのものが成り立ちません。

レンタカー利用時やその他の消費サービスで収集したデータをどう保護すべきかを考え始める必要があります。セキュリティはデフォルトで備わっているべきです。たとえば、継続的インテグレーション・継続的デプロイ（CI/CD）パイプラインの中でセキュリティイベントをトリガーし、新しいオープンソースライブラリの追加時にレビューと評価を行うようにします。

開発パイプライン自体も安全でなければならず、脆弱性テストのための各種自動化ツールを備える必要があります。特に医療や金融分野では、さまざまな規制や監督要件を遵守する必要があります。

5年以内に、私たち全員がセキュリティ問題に対して高い意識を持ち、顧客保護を最優先にすべきだと願っています。アマゾンでは、知的資本であれ金融資本であれ、顧客保護が常に最優先の投資領域です。