AWSの「開発スピード」とは？ 同社がやらないサービスとは何か：AWS Summit Tokyo 2016

AWSは新サービス、新機能を高速に開発・提供していることを強調している。だが、イノベーションの数よりも重要なことがあるのではないか。例えばAWSがやらないサービスとは何なのか。本記事では、AWSのサービス展開戦略を探る。

[三木泉，＠IT]

　Amazon Web Services（AWS）は2016年6月初め、東京で開催したAWS Summit Tokyo 2016で、AWSサービスの豊富な機能について説明した。

　グローバルでの最新の発表として、2種の安価なEBSボリュームタイプの追加、SAP HANAなどインメモリデータベースに適したX1インスタンスの提供開始、企業データセンター内のアプリケーションを、依存関係と共に検出し、AWSの移行をしやすくするAWS Application Discovery Service、インド、米国、英国、中国における新リージョンの開設予定などを説明した。

　東京リージョンについての発表としては、AWS Certificate Managerが5月17日より利用可能になることをはじめ、Amazon RDSにおけるAmazon RDS for SQL ServerのマルチAZデプロイメントサポート、Amazon EC2 Container Serviceにおけるサービスオートスケーリング機能の導入、大量データをAWSに送付するためのアプライアンスAWS Import/Export Snowballなどの提供計画を示した。

AWSは既に豊富な機能を提供するようになっている。同社が何をやり、何をやらないのかは改めて注目される

　AWSは従来同様、AWS Summit Tokyo 2016でも、同社が年間約500以上のペースで「イノベーション（新サービスや新機能）」を提供していると強調した。だが、AWSはこうした数字を言い続ける必要があるのだろうか。例えばグーグルやマイクロソフトが、自社のクラウドサービスでAWSよりも多くの「イノベーション」を発表したと仮定したら、AWSよりも優れていることになるのだろうか。

　米TechTargetは、「AWS IoT puts Amazon in crowded market with foes new and old」と題する記事で、GEやIBM Watson IoTを引き合いに出し、「AWSは特定産業のニーズに応える取り組みに弱い」という趣旨のことを書いている。では、AWSはIoTでIBMのような産業別に特化した取り組みをし、これを「イノベーション」に含めるべきだろうか。答えは明らかにノーだ。

　AWSはどのような観点で新サービスや新機能をこれまで提供し、今後どう提供しようとしているか。自身で何をやり、何をやらないのか。本記事ではAWS Summit Tokyo 2016およびその他の取材から、これについて探る。

AWSはどのような考えで、サービスを提供しているのか

　AWSの新サービスや新機能の提供に見られる傾向は、次のように表現できる。

1.水平的に展開しやすいプロダクトを提供する

　筆者は以前、Amazon Web Services総責任者のAndy Jassy（アンディ・ジャシー）氏に「AWSは顧客中心主義というが、顧客ニーズにどう優先順位をつけるのか」と質問したことがある。同氏の答えは「最大多数の最大幸福」だった。

　AWSは大企業のリクエストに応えないわけではない。「特別に対応してもらった」という趣旨のことを話すユーザー企業もいる。だが、基本的にはその「特別対応」が、他の多数のユーザーにも利用できるような、広がりのあるものについて対応しているようだ。そしてその特別対応は、サービスのフォークではなく、標準機能として組み込まれる。

　AWSは、小売企業のビジネスモデルをITに持ち込んだことを強調していた時期がある。「既存の大企業のような高マージン体質ではない」と話していた。最近では、この言い方が正しくないことが判明している。AWS事業のマージンは期を追うごとに拡大しており、20数％に達している。これはもはや、「低マージンビジネス」とは呼べない。

　だが、サービスのさまざまな側面での標準化は、AWSの効率の基盤であり、これが変わることはないと考えられる。標準化した要素にいったん分解したITサービスを数多く売ること、これがAWSのビジネスモデルだ。その上で、IOPS課金やAPIコール数課金など、サービスに応じて多様な課金モデルを提供している。

　つまり、比較的少数の顧客だけが高い付加価値を感じるようなサービスは、基本的にAWSの守備範囲ではない。同社自身がこの種のサービスを提供することは考えにくい。

　上記のAWS IoTについていえば、AWSがテンプレート的なものを提供することは考えられても、直接産業別のソリューションを出すことはないだろう。

　上記の記事ではGEを引き合いに出しているが、GEはAWSの上で自社のノウハウを生かし、Predixというサービスを提供している。Cloud Foundryを間に挟んでいたとしても、AWSの大ユーザーであることに変わりはない。

2.最初から完成したプロダクトを出すわけではない

　AWSの「イノベーション」の数は、意地の悪い言い方をすれば「かさ上げ」されている。

　AWSが新サービスを出すとき、それは必ずしも完成形ではない。AWS Lambdaがいい例だが、ユースケースや機能を限定した形で最初のバージョンを提供し、その後、他の自社サービスとの連携を含めて段階的に拡張するケースがよく見られる。

　これは、最近のリーンな、継続インテグレーションに基づく開発スタイルを踏襲している点でもある。用途や機能を限定した形で最初のバージョンを出し、ユーザーのフィードバックを受けながら改善していく方式を積極的に活用している。

　こうした機能強化を「イノベーション」としてカウントするなら、その数は大幅に増えることになる。

　これを「かさ上げ」と呼ぶのは自由だが、多くのユーザーが、「自社にとって便利な改善を機動的かつ継続的に実施してくれる」という満足感を得やすいやり方だともいえる。

　各サービスにおける段階的な機能改善は、前述の通り、1社だけのニーズに応えたものではない。逆にそのことが積極的な価値を生むケースが出てくる。例えばNetflixのような企業が、自社サービスを進化させるためにAWSにリクエストした機能が実装されたとする。他のユーザーは、同じ機能を活用して、Netflixのサービスをまねしようとすることもできる。実際に完全なまねができるかどうかは別問題だが、「新機能が、用途と利用方法を比較的イメージしやすい形で提供される」といえるはずだ。

3.ユースケースの開拓につながりやすいプロダクトを優先する

　例えばセキュリティで、AWSが最近本格提供を開始したサービスに、Amazon Inspectorがある。これは、AWS上で動作する仮想インスタンス、OS、ネットワーク、アプリケーション構成を対象に、ユーザー組織のVPCにおける脆弱性のアセスメントができるサービスだ。

　一般企業の社内に存在する既存のアプリケーションをAWSに移行するシナリオを考えたとき、多くの企業IT担当者が不安に感じることの1つはセキュリティだ。

　AWSは、セキュリティ関連認証の取得に始まり、ログ管理機能、アイデンティティー管理、証明書管理など、さまざまなセキュリティ関連機能を提供してきた。

　Amazon Inspectorは、AWSが提供する数々のセキュリティ関連機能の中で、積極的にクラウド移行を促せるものの1つだと表現できる。Inspectorのような脆弱性チェック機能は、導入コスト、導入作業の複雑さなどから、オンプレミス環境には導入しにくい。オンプレミスに導入しにくいセキュリティ機能を、クラウドサービスなら比較的容易に、サービス形態で導入できるということなら、ある種の人々にとって「オンプレミスよりパブリッククラウドのほうが安全」というフレーズが、がぜん現実味を持って響くようになる。

　つまり、Amazon Inspectorは、AWSにとっては、単なるセキュリティ機能ではない。企業の既存ITのAWSへの移行というユースケースを広げる機能だと表現できる。

　もちろんAWS上では、他社のセキュリティ製品も活用できる。セキュリティを全てAWSに頼る必要はない。だが、AWSのサービスとして、「オンプレミスよりもセキュリティ面で安心」と思わせるものがあるかないかでは、大きな違いがある。

　エンタープライズでは、特に既存の高付加価値分野をターゲットとし、新しいやり方でコストや運用性に関するメリットを提供することを目的としたプロダクトが分かりやすい。

　具体的にはAmazon RedshiftとAmazon Auroraだ。Redshiftはデータウェアハウス、AuroraはOracle Databaseに焦点を当て、既存製品からの移行を促している。

　これらは、大幅なコスト削減というメリットを押し出し、既存の社内製品の代替選択肢となるという点で、AWSにとってはユースケースを大きく広げてくれるプロダクトだと考えられる。

4.AWSの他のサービスとの連携がしやすい形で提供する

　これもAWS Lambdaがいい例だ。Lambdaは、「サーバレスコンピューティング」とも呼ばれるようになった容易なアプリケーション構築手法を実現したサービスとして画期的だ。だが、基本的には他のAWSサービスにおけるイベントをトリガーとして、処理を実行するようになっている。「他のサービスとの連携がしやすい」どころか、AWSの他のサービスとの連携で成り立っている。

　AWSがある分野に関し、「自社のサービスとして出すか、他社がAWS上で提供するサービスに任せるか」を判断する際に影響を与える要素の1つとして、他のサービスとの連携による相乗効果を生み出しやすいか、あるいは他のサービスの利用を促進するか、といった点があるはずだ。

5.ソリューションよりも材料の提供を優先する

　上の項目にも関係するが、AWSにとってのソリューションは、AWSの複数サービスの組み合わせだ。AWSはあくまでも技術要素を提供する企業であり、この上にビジネスソリューションを構築するのは、ユーザー自身、付加価値サービス提供事業者、あるいはユーザー企業を支援するインテグレーターだ（米国などにシステムインテグレーターが存在しないというのは誤解だ。「システムインテグレーター」あるいは「ソリューションプロバイダー」といった名称で呼ばれている）。

　AWSの場合、ユーザー企業とインテグレーターの位置付けは、従来型のIT企業に比べると曖昧だ。基本的に、AWSのサービスに関する知識やノウハウをもっていさえすれば、あるいは使いながらノウハウを蓄積するつもりさえあれば、誰でも「ヒーロー」になり得る側面を持っている。

　多くのユーザー企業の担当者が、他社の事例をまねたり、ベストプラクティスを学んだりすることで、プロジェクトに主体的に関わっている。インテグレーターがAWSでつくった「ソリューション」を使うだけという利用方法を選択することも、もちろん可能だが、それだけではないところにAWSの魅力がある。

　関連して指摘できるのは、AWSがサービスごとの利用量に基づく複雑な課金システムを意図的に維持していることだ。サービスごとに課金され、課金体系もサービスによって異なるなど、非常に複雑だ。

　これについて、Jassy氏は、「サービスごとに別個の価格体系があるという件は、顧客と活発に議論したトピックだ。『何をどう使うかを制御するのは顧客だ』という考えに基づいている。料金も、使っただけ払ってもらうということだ。パッケージやバンドルを押し付けるようなことはしない。リソース利用に応じた料金についてはガラス張りでありたいと思っている」と語っている。

　「ソリューション」は、料金的なパッケージングやバンドルを指向する。現在のところ、そうしたことをやろうとしている兆候は、同社には見られない。

6.オープンソースのように、コミュニティーを広げられる形で提供する

　AWSは必ずしもオープンソースソフトウェアばかりを使っているわけではない。だが、オープンソースソフトウェアのユーザーコミュニティーのように、ユーザー同士が学び合える文化を醸成している。日本でユーザー会JAWS-UGの支部が文字通り津々浦々に存在することは、この吸引力の強さを物語っている。

　上記の通り、AWSでは誰もが「ヒーロー」に成り得るという側面を持っている。しかも、世界的な著名デジタルサービス企業が利用しているのと同じ基盤を知識次第で活用できる。そもそも、先進的なITサービス企業が使いたいと思うような機能を提供し、IT技術の活用という点でリーダーシップを発揮してきた点は重要だ。

　AWSが既存の「エンタープライズ的な」ニーズに手取り足取り応えることは今後も考えにくい。逆に、企業の社内システムについても、デジタルサービス企業と同様な考え方にITを移行していくべきという考え方をさらに広め、その先で待ちかまえている戦略をとっている。セキュリティだけは例外で、同社はさまざまなツールやフレームワークの提供を、ますます自社のセールスポイントにしていくだろう。これも、実際には必ずしも「エンタープライズニーズへの対応」だけではない。重要なアプリケーションやサービスの保護について、さまざまな選択肢を提供することが主眼になると考えられる。

Amazon.comとの新たな関係も期待できる？

　今後のAWSにおける新たなサービス展開例の1つとして、親会社アマゾンとの新たな形での連携があり得るのではないだろうか。AWSはIoTで、アマゾンのDash Buttonをベースとしたデバイス「AWS IoT Button」を、開発者向けに限定提供している。Dash Buttonとは、Wi-Fi接続する「ボタン」で、これを押すだけで、アマゾンから特定商品を購入できる。このDash Buttonを汎用的にプログラミングできるデバイスとして提供しているのがIoT Buttonだ（正確には、IoT Buttonのイベントを受けて実行する機能を、AWS上でプログラミングする）。

　では、家庭用の音声アシスタント／スピーカー／リモートコントロールなどとして人気が高まっている「Amazon Echo」が、IoTデバイスとして発展したらどうなるだろうか。Echoがこのまま普及を続けたと仮定した場合、これを活用して、サードパーティーがIoTサービスを追加的に提供できるような仕組みを作り出す可能性があるのではないか。

　関連して、アマゾン傘下のAnnapurna Labsの動きも注目される。同社はIoTあるいはコネクテッドホーム機器用のチップを、機器メーカー向けに提供開始している。このチップは、コンテナ環境を動かし、家庭用ルータ／ゲートウェイなどの機器の機能を柔軟に拡張できるようにするものと説明されている。こうしたチップを使って、エッジデバイスにアマゾン、あるいはサードパーティーがアマゾン／AWSとの連携の下に、オンデマンドで機能を投入できるような仕組みを考えているのではないだろうか。

　一方、マイクロソフトでいえばPower BI、PowerAppsのような、ビジネスユーザーが直接使うようなサービスの、AWSにとっての優先順位は分かりにくい。例えば、容易に使えるBIツールとして同社が提供を開始した「Amazon QuickSight」を、今後どこまで高速に機能強化していくかが、注目される。