スタジアムから生まれるJAWS FESTA 2018伝説 第4回

テクノロジーの選択に必要な考え方をAWSエバが語る

AWSを利用すべきもう1つの理由は「メカニズム」の実装である

　11月3日に開催されたJAWS FESTA 2018の午後のキーノートを行なったのは、アマゾン ウェブ サービス ジャパン エバンジェリストの亀田治伸さん。サービス概要や設計思想までわかりやすく説明してくれる亀田さんがFESTA向けに選んだテーマは、いつもとちょっと違う「なぜクラウドなのか？」だった。

アマゾン ウェブ サービス ジャパン エバンジェリストの亀田治伸さん

「失敗しやすい」だけがクラウド導入の理由じゃない

　パナソニックスタジアム 吹田で開催されたクラウドユーザーのお祭り「JAWS FESTA 2018」。秋晴れの日差しでむしろ暑く感じた午前中の友岡さんの基調講演とうって変わり、スタンドが陰り始めた午後、昼食をとった参加者たちは午後の基調講演のためにバラバラと着席する。美しいグリーンをバックに登場した亀田さんは、まずAmazonとイノベーションについて語り始めた。

　AWSがEC事業を展開するAmazon.comの社内システムを起源としていることはよく知られている。Amazonグループ全体で見れば、無人ドローンを用いて荷物を配送する「Amazon Prime Air」や、在庫の棚をオペレーターの位置までロボットが移動させる「Amazon Robotics」など、さまざまな革新的な仕組みが導入されている。夢想したようなサービスを次々と現実化させていくAmazonについて、亀田さんは「テクノロジーを使ってイノベーションを起こす会社」と説明する。

イノベーションの典型例であるAmazon Robotics

　しかし、こうしたイノベーションを起こすにはさまざまな実験を行ない、失敗できる環境が必要になる。「多くの挑戦を育むカルチャーと失敗を適切なプロトコルに基づいて許す社内のシステム。この2つが成立しないと、成功は出てこない。これがAmazonの基本的な考え方」と亀田氏は語る。実際、株主向けのレターでジェフ・ベゾスCEOは「株主はわれわれの失敗の数をよく見てほしい。失敗がなければ、成功もない。失敗をしていないということは、挑戦をしていないということだ」と語ったという。

　そして、ITの分野で失敗と挑戦を重ねられるプラットフォームこそがAWSだ。「AWSは初期費用が無料であり、必要な時に必要な分だけITリソースをプロビジョニングすることができ、そのリソースを捨てれば課金が止まる。こういう特性を持っているので、結果を読みにくいITシステムに非常に適していると言えます」（亀田さん）。

　もちろん、ここはAWSユーザーたちが集まるJAWS FESTA。「こうした話はよく流通しているし、わかりやすいので、われわれも好んでこの話をします。でも、今日はちょっと違う話をしたいと思います」と語る亀田さん。「失敗を繰り返せるプラットフォーム」という観点とは別に、クラウドを使うべきもう1つの理由が今回のテーマ「メカニズム」である。

再帰的に、機械的に物事を回せる「メカニズム」とは？

　AWSのみならず、Amazonグループ全体に実装されるべきこの「メカニズム」とはなにか？　ベソスCEOは全社員ミーティングで「物事をよくしたいという意思が、つねに物事を改善させるわけではない」とコメントしている。人間がサービスを開発し、改善しようと努力する限り、不具合や問題は起こる。それを防ぐためには「再帰的に、機械的に、物事を回せる仕組みをメカニズムとして実装する必要がある」（亀田さん）という。

　メカニズムは「仕組み化」であり、「自動化」であり、おそらく「属人化」の真逆にある概念である。インプットに対して、連続的にアウトプットする仕組みを備える。アウトプットは付加価値を伴っており、なおかつ「べき等性」を担保しているので、人間と違ってつねに同じ結果が出てくる。メカニズムを実装するためには、AWSで提供されている最新のテクノロジーが使うことができる。

　たとえば、製造現場で用いられる「射出成形機」。金型に材料をはめ込めば、同じモノを何個も作れるという便利な代物だが、温度や材料の混合比率でアウトプットにぶれが生じてしまう。品質の悪化につながったり、生産数に差が出てくることもあるため、熟練工が横で作業をチェックする必要がある。こうした課題を解消するには、やはり製造ラインの監視や見える化が必要になる。加えて異常検知ができれば、熟練工が細かくチェックしなくても済むかもしれない。テクノロジーを使ってメカニズムを実装した一例だ。

　これは組織にも当てはまる。その一例がJAWS-UGだ。亀田さんは、「JAWS-UGは組織体として捉えると、非常に不思議な組織。独立した組織でありながらも、トップにリーダーが存在していない。みなさんが有機的に結合している」と語る。強力なリーダーがいなくても、毎年のように数千人規模のイベントを実現し、規模を拡大させ、きちんとロックスターを生み出している。「組織がメカニズム化されたいい例」と亀田さんは語る。

　もちろん、日々の業務においても同じことが言える。分析すべきデータが大量にあり、徹夜で作業する人とプログラムで瞬時に終わらせる人であれば、もちろん後者の方が必要な人材になる。「昔は長時間作業する人も『がんばり屋さん』という一定の評価は得ていた。でも、労働人口の減少や働き方改革の中、ただがんばることだけを美徳として褒める社会はもはや許されなくなった。少ない時間で大量のアウトプットを生成する仕組みを作れる人がこれから重宝されるのではないか」と亀田さんは語る。

Infrastracture as Codeによるメカニズムの実装

　初期費用が無料で使った分だけ支払う従量課金は、こうしたメカニズムの実装においても有利。そしてメカニズムの実装において、AWSが特に重視している点が、いわゆる多くのパブリッククラウドで基礎概念となっている「Infrastracture as Code」という考え方だ。

　Infrastracture as Codeで実現できることについて、亀田さんは「サーバーやストレージ、ネットワークなどのリソースをAPI経由でプロビジョニングできること」と定義する。API経由で利用できるということは、スクリプト化が可能ということであり、定義ファイルを作っておけば、誰でも同じアウトプットを出力できることを意味する。ITにおけるいわばメカニズムを実装できる仕組みだ。

　AWSもこのInfrastracture as Codeの上にクラウドコンピューティングを実装している。きわめて大規模なシステムを構築し、コストを極限まで切り詰め、共有リソースプールをユーザーに提供している。その上で、ストレージ、データベース、データ分析、機械学習、IoT、認証基盤、ロードバランサーなどさまざまなマネージドサービスが提供されている。汎用的な機能がサービス化されているため、ユーザーはそれらを用いることで開発や運用の効率を向上させることが可能になる。

　便利なクラウドサービスだが、インフラはもちろん、多くのシステムがAWSに依存すればアプリケーションがロックインされてしまうという意見もある。これまで話してきたメカニズムの実装に足かせをかけるものではないかいう懸念もある。「誤解を恐れずに言えば、これは一部イエスだったりします」と亀田さんは語るが、これを上回るメリットがAWSにはあるという。

　たとえば、基幹システムを前提としたSoR（System of Record）では、企業内でのデータを厳格に管理することが求められる。従来培ってきた運用手順やセキュリティポリシーを変えないことが重視されるので、クラウド移行した場合のメリットはおもに運用負荷の軽減で、大きなアーキテクチャの変更は考慮されない。「クラウド界隈では『リフト＆シフト』と呼ばれますが、とにかくいったんクラウドにシステムを移行し、節約できた運用コスト分を、次になにに使うか考えるということがよく行なわれます」（亀田さん）。

　その一方で、SoE（System of Engagement）は、スマホのアプリやWebのシステムなどで顧客主体で新しいコンセプトを連続的にぶつけていくシステムを指す。市場のニーズにいち早く応え、競合他社に打ち克つには、新しい機能をどんどん世に出していかなければならないので、開発のスピードが最優先事項になる。「この領域では、AWSにロックインされる懸念よりも、世の中のユーザーに面白いと思ってもらう方がはるかに重要になります。AWSではこうした領域に使ってもらえるマネージドサービスを数多く提供しています」と亀田さんは語る。