アマゾンのワーナー・ヴォゲルスCTOがまだ引退できない理由

Amazon(アマゾン)のWerner Vogels(ワーナー・ヴォゲルス)氏がCTOに就任してから16年という月日が経つが、御年63歳の同氏の頭に引退の文字はまだない。「まだまだやるべきことがたくさんあります」。先にラスベガスで開催された同社の年次カンファレンス「re:Invent」で私が行ったインタビューで同氏はそう話す。「今自分たちがやっているすべてのことに夢中になっています。夢のような仕事ですね」。IT予算のうちクラウドに使われている割合がまだ少ないことを指摘し「テクノロジー面ではさらに多くのことが計画されているので、私はどこにも行きませんよ」と同氏は意気込んでいる。

re:Inventを開催することにより、対面式カンファレンスの復活という大きな賭けに出たAmazon。同イベントには通常6万人以上の参加者が参加し、1週間にわたってラスベガス・ストリップが占拠される。2021年の参加者数は約2万7000人となったが、それでもこの人数は新型コロナウイルスの蔓延前の平常時のイベントとしても最大級の技術カンファレンスである。

長年AWSのCEOを務めてきたAndy Jassy(アンディ・ジャシー)氏がJeff Bezos(ジェフ・ベゾス)氏率いるAmazonのリテール部門のCEOに就任したことにより、Adam Selipsky(アダム・セリプスキー)氏がAWSの指揮を執るようになったが、今回のカンファレンスは同氏をトップに迎えて以来初のイベントとなった。セリプスキー氏は今回のイベントで、一部の人間に期待されていたようなAWSの大きな戦略変更を発表することはなかったのだが、それもそのはず、ヴォゲルス氏によると、新しいリーダーシップ下ではまだ大きな変化が何も起きていないのだという。

関連記事:アマゾンのベゾス氏が退任、新CEOにAWSトップのアンディ・ジャシーが就任

「もちろんアダムのことは知っていましたよ。彼はAWSの2年目、あるいは1年目に参加してくれました。その後はご存知のようにTableau(タブロー)に行ってしいましたが、また戻ってきてくれました。彼はこのビジネスを熟知していますから、とてもすばらしいことです」とヴォゲルス氏は話しており、またセリプスキー氏がTableauのCEOに就任する前から、セリプスキー氏とジャシー氏が長い間緊密に協力し合っていたことにも言及した。「ただ継続的に取り組んでいるのみです。私たちを取り巻く世界は当然変化しており、彼が対応しなければならないことはたくさんあると思いますし、AWSについても同様です。我々のビジネスは、現在の栄光に満足してゆっくり座っていられるようなものではありません。革新を続け、自らも革新していかなければならないビジネスなのです」。

画像クレジット:AWS

基調講演の中で、AWSには現在何百種類ものサービスが存在すると言及したヴォゲルス氏。その理由はどんどん欲しがるお客のせいだと言って笑いをとったが、実際のところ同社がどのサービスを進めるのかを判断するのが年々難しくなっており、これは現実的な問題にもなっている。AWSはフレームワークではなくプリミティブを構築することを信条としているとヴォゲルス氏はいうが「しかしそれだけではなく、過去数年間に見られたように、私たちにはより多くのソリューションを構築し、顧客のためにより多くのパッケージ化されたものを構築するチャンスがあると思います。AWSには組み立てなどを得意とするビルダー面もまだ多くありますが、データレイクを必要としているお客様もかなりの割合でいらっしゃいます」。その中には、同社のマネージドサーバーレスデータ統合サービスであるAWS Glueのようなプリミティブを利用して、他のソリューションを構築するAWSの内部顧客も含まれている(もちろん、これらの内部チームからのフィードバックサイクルは非常に迅速である)。

すべてのサービスにおいてユーザーは常にあらゆる新機能を求めているが、同社の開発チームのロードマップはそれに付随している。AWSはしばしば、顧客がサービスをどのように利用しているかに基づいてロードマップを変更するのだとヴォゲルス氏はいう。例えばAWSのNoSQLキーバリューデータベースであるDynamoDBの場合、開発チームは顧客がセカンダリインデックスを必要としていることを知っていたものの「顧客がこれらのデータベースをどのように使い始めるのかを正確に理解するために、あえてインデックスを使わずにサービスを開始することにしました。セカンダリインデックスはすでにロードマップに入っていましたが、実際にはお客様はセカンダリインデックスよりもセルレベル、ロウレベルのセキュリティを求めていました。お客様次第でロードマップを変更することで、より健全なアプローチができるのだと思います」。

クラウドへの移行というテクニカルな部分だけでなく、それにまつわるあらゆることに頭を悩ませている伝統的な大企業も、同社にとってのもう1つの顧客層だとヴォゲルス氏は説明する。そのための組織体制をどのように構築するか、というところでAWSのパートナーネットワークの出番となるわけだが、最近ではこうした企業文化的な変化についてもAWSに直接依頼されるケースが増えているという。

2019年11月7日、ポルトガル・リスボンのAltice Arenaで開催されたWeb Summit 2019の最終日、MoneyConfステージに登場したAmazonのCTO、ワーナー・ヴォゲルス氏(画像クレジット:Harry Murphy/Sportsfile、Web Summit用、Getty Images)

5年前、クラウドへの移行が進んだ主な要因は、開発者の生産性向上とハードウェア所有からの脱却だった。「最近となっては一番の理由はセキュリティです」とヴォゲルス氏は指摘する。「多くの企業、特に大企業は自分たちで自分たちを守ることが不可能だということに気づき始めています。企業がそこまで投資することができなくても、AWSが作って差し上げることは可能です。そのためセキュリティがクラウドへの移行の大きな原動力となっているのです」。

数年前までは企業がクラウドのセキュリティを懸念し、それが理由でクラウド移行をためらっていたことを考えるとかなりの進歩である。それはほぼ「FUD」が原因だとヴォゲルス氏はいう。「Fear(恐れ)、Uncertainty(不確実性)、Doubt(疑念)を意味するFUDです。競合他社はより良い製品を作る努力をする代わりに、嘘の情報を流して恐怖や不確実性を煽ることを好むことがあります。標準的なIT企業は皆、本屋でサーバーを買うなんて頭がおかしいんじゃないかと思っていたのでしょうが、蓋を開けてみたら、誰もが本屋からサーバーを買いたかったのです。人々はAmazonが初めからテクノロジー企業であることに気づいていなかったのです」。

画像クレジット:AWS

ヴォゲルス氏自身も入社前はAWSに対して非常に原始的な見解を持っていたという。学者であった同氏が初めて講演に招かれたとき、同氏はAmazonのことをよく知らなかったという。実際、サービス開始当初はエンジニアの採用が最大の課題の1つだったと同氏は振り返る。「しかし裏側を覗いてみると、Amazonでは分散システムの教科書に載っているようなことが、それもこれまでに見たことのないようなスケールで起きていることに気づいたのです」。

クラウドのセキュリティに関しても、初期の頃は同じような誤解があったという。また、ヴォゲルス氏自身がAmazonの規模について抱いていたような純粋な誤解の他に、別の種類の誤解もあったという。それが「競合他社に対する悪意ある誤解」だ。「今ではとても良いパートナーとなっている当時の競合他社の1社は、以前実際に営業会議で『誰がAmazonからサーバーを買いたいというんだ。まったく馬鹿げている、心配する必要はない』と言っていました。今では状況が違います」。

大企業のCIOやCTOなどの意思決定者と話をしていると、高度なクラウド環境の醍醐味を最大限に活用するためにマルチクラウドにしたいという話がよく出てくる。AWSをはじめとする大手クラウドベンダーは現在、これを実現するために自社の技術を使って競合他社のクラウド上でコンテナやサービスを実行・管理できる何らかのサービスを提供しているが、実際にはこれをしっかり実現できている企業は多くない。実際にはこれでは最低共通項に固定されてしまうという声を聞くことが多く、ヴォゲルス氏も同じことを感じている。

「もし私が大企業のCIOであれば、部下に全部見てみるように指示するでしょうね。私が話をするようなお客様がマルチクラウドに本当に興味があるのであれば、使いたいと思うクラウドの特出した機能が何であるかを調べるべきなのです。開発者にさらに3つ、4つのクラウドに透過的に取り組めとはいうべきではありません。最低共通項に落ち着いてしまうからです。結局クラウドをデータセンターとして利用することになり、せっかくのメリットが失われてしまうのです」。

他のサービスを評価するときと同様に、お客様は出口戦略を持ちたいと考えていると同氏は主張する。実際には単一のクラウドプロバイダーを利用しつつ、必要に応じて他のクラウドに簡単に移行できるようなシステムを構築するということだ。

多くの企業にとってクラウドへの移行とは、いまだ既存のサービスを持ち上げて移行することを意味している。しかし最近では新しい開発パターンにも目が向けられるようになっている。基調講演の中でヴォゲルス氏はサーバーレスのパターンを使うことを特に強調していたが、実際に今後はそれがデフォルトのようになるべきだと考えている。私がこの点について質問すると「ゼロから構築するのであればそれが賢明ですね」と回答した同氏。その上で現在のコンピュートプラットフォームには、インスタンス、コンテナ、サーバーレスの3種類があることも指摘する。SAPシステムであればおそらくEC2上の専用インスタンスへの移行が一般的で、また小さなブロックに分解できる自社ツールなら、コンテナやKubernetesに適している。そしてまったく新しいサービスには、サーバーレスが適しているということだ。

「おもしろいことに、AWSのサーバーレスプラットフォームのLambdaを発表したとき、当時は若い起業家やデジタル系の人間が喜ぶのだろうと思っていました。しかし結果的には、Lambdaの最大のユーザーは大企業だったのです」。ヴォゲルス氏はこれはサーバーレスによって企業がコストをよりコントロールできるようになったからではないかと推測している。

また、サービスがアイドル状態の間はリソースを消費しないサーバーレスでは、持続可能性の確保が見込めるのだと同氏は指摘する。AWSは先週、ヴォゲルス氏が基調講演で発表したように、サステナビリティを自社のフレームワークの6番目の柱に指定している。AWSはクラウドの持続可能性のための共有責任モデルを信じており、2025年までに100%再生可能エネルギーで運営することを計画している。しかし同時に、クラウドを最も効率的に利用する方法を考えるのはユーザー次第なのである。

画像クレジット:AWS

「私はお客様にも何ができるかを考えてもらうよう、呼びかけています。技術的なことだけではなく、例えば少しでも軽いウェブサイトに変更するのはどうでしょう。画像の容量を5メガバイトではなく、50キロバイトにするのは無理ですか?このようなことです。アプリケーションの設計やウェブサイトの設計において、実際に使用するリソースが少なくて済むようなことを意識してみたら良いのです」。ある意味、エンジニアの常識に反する考え方ではあるが、何を最適化するかが問題なのだと同氏は考えている。多少のレイテンシーはコンバージョン率を下げるかもしれないが、持続可能性の目標を達成するには効果的なのである。

「2、3年後にはより多くの開発が行われるでしょうし、もちろんパフォーマンスを測定するためのツールも必要になるでしょう」。しかし、何を最適化したいかを決めるのはお客様自身であると同氏はいう。「お客様が何をすべきかを指示するつもりはありません。ゲートキーパーなど必要ないからです。人はどんな方法でもイノベーションを起こすことができるはずですが、自分で意識する必要があるのです」。

今後の展望として、ヴォゲルス氏が精力的に取り組んでいる技術の1つが量子コンピューティングである。2021年初め、AWSは超伝導量子ビットに賭けて、独自の量子ハードウェアの構築を開始すると発表した。現時点では、IonQ、Rigetti、D-Waveなどの主要な量子プレイヤーと提携し、それらのハードウェアやサービスをBraketのサービスで利用できるようにしている。しかし、GoogleやMicrosoftと同様に、AWSも古典的なチップと同じく、独自の量子ハードウェアを構築したいと考えているのである。

「ハードウェアとソフトウェアが互いに歩調を合わせている分野の1つだと思います。ハードウェアの改善がソフトウェアの改善を生み、ソフトウェアの改善がハードウェアの改善につながります。例えば、量子に関するソフトウェアツールは、古典的な計算を行うためのソフトウェアツールには到底及ばないと思いますが、そのためにはアプリケーションの構築を始める必要があります。Amazon Braketを使ってお客様は調査を始めることができるのです。どのようなアルゴリズムを使っているのか?そのためのソフトウェア開発はどうしているのか?それをどうやって追跡するのか?そのための運用はどうするのか?といったことです。ハードウェアにも影響を与えるような、解明すべきことがたくさんあります。3年後の私たちがどうなっているかとても楽しみです」。

どうやら世界的なロックダウンが再度起こらない限り、re:Invent 2024の最終日にはヴォゲルス氏がステージに立ち、AWSの量子コンピューターの最新の改良点や、会場に訪れた開発者たちがそれを最大限に活用する方法について話すことになるのだろう。

画像クレジット:Noah Berger/Getty Images for Amazon Web Services / Getty Images

原文へ

(文:Frederic Lardinois、翻訳:Dragonfly)


Amazonベストセラー

返信を残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

CAPTCHA