クラウド・コンピューティングの活用はあらゆる業界で進んでおり、従来のITコストの削減という守りから、コールセンターの自動化や機械学習による省力化などビジネス変革へと活用の中心がシフトしつつあります。本セッションでは、クラウドを活用して成功したビジネス事例を紹介し、また自社でクラウド活用を立ち上げる際に活用できる情報、そしてクラウド活用を広げてビジネス変革を推進する段階的なプロセスについてご説明いたします。
|
アマゾン ウェブ サービス ジャパン株式会社 |
われわれAmazonのビジョンは、「地球上でもっともお客様を大切にする企業であること」です。お客様を大切にすることは、多くの企業様でも同じだと思いますが、Amazonの場合、さらに踏み込み、お客様が何をしたいかを考えて、そのために動くことをカルチャーにしています。Amazonのグループ企業であるAWSも同じカルチャーを受け継いでいます。
Amazonグループの文化に「Working Backwards」というものがあります。「全ては、お客様を起点に考え、お客様体験を徹底的に固める」という意味です。具体的に言うと、まずサービスやソリューションを作るのではなく、お客様が求めているであろうプレスリリースを書くところから始めます。次に、お客様が質問するであろうFAQを作ります。その次にお客様体験（ペルソナ）を定義し、架空のお客様に対してどんなサービスを提供するのか、マニュアルを作成します。ここまでできてようやく社内レビューを行い、良いサービスだねと評価されて初めて開発に取り掛かります。
こういうサービスが売れそうだからとか、ライバル企業が出しているからではなく、常にお客様起点で発想することが、Amazonの大事にしていることです。
以下は、Amazon創業者のジェフ・ベゾスが考えたビジネスモデルです。
まず、顧客体験が起点となります。お客様起点で考えることで顧客が増え、売り手が増える。すると品揃えが増え、顧客体験が向上する。このサイクルがぐるぐる回って成長する。成長すれば規模の経済で、コストが下がります。それを会社の利益に還元するのではなく、低価格化・利便性向上などお客様に還元していく。それがまた顧客体験向上につながる。これがAmazonのビジネスモデルです。
Amazonドットコムは、もとは書籍を売るショッピングサイトでした。その後、プライムビデオや、リコメンド（おすすめ情報の提案）など、様々な機能を付加していきました。そのうち機能追加の速度が速すぎるため、従来のアーキテクチャーでは、機能追加に時間もコストもかかるようになり、いわば、情報システムが新規サービス提供の足かせになってしまいました。
そこで、ジェフ・ベゾスの指示により、機能ごとにアプリケーションを分割し、すべての機能をAPI（アプリケーション・プログラミング・インターフェース）経由で連携するアーキテクチャーに変更しました。すると、機能追加もサービス提供も今までより速い速度で行うことができるようになりました。その過程で誕生した様々なITサービスがベースとなって、AWSが誕生しました。
ITリソースを、必要な時に必要なだけ従量課金で利用できるのがAWSの提供するサービスです。使ったら使った分だけ料金を支払う、電気料金と同じ考え方です。
AWSは、最初のビジネスモデルで示したように、お客様が増えれば増えるほど、規模の経済でコストが下がり、その分をお客様に還元してきました。たとえば、これまで76回の値下げを行いました。また、CPUやストレージの性能が向上し、同じサービスでも同じ価格でその質が向上しています。
オンプレミスのサービスであれば、知らないうちにどんどん料金が下がったり性能が上がっていくということはありませんが、クラウドの場合はそれが期待できます。それが大きな魅力の1つかと思います。
クラウドに移行するメリットは、大きくは以下の5点です。順を追って説明しましょう。
ビジネスは非常に速いスピードで動いています。そのようなときは、速いスピードでトライアルを繰り返せることが重要です。ITが足かせになってはいけません。
従来のオンプレミスの環境では、データセンターの確保、ハードウエア調達、ケーブル配線、OSインストールなどで数カ月かかります。これに対しAWSを使っていただくと、クリックひとつで、ビジネスをスタートできます。これに加え、うまくいかなかったから止めようとなったときも、削除ボタンを押すだけで利用停止が可能です。オンプレミスの環境ではそうはいきません。
仮想サーバーが必要な場合、AmazonEC2というサービスをご利用いただくこともできます。これは、数分で起動し1秒ごとの従量課金で利用可能な仮想サーバーです。
サーバーのキャパシティ予測には限界があります。たとえばECサイトを立ち上げる際、どのくらいのサーバー必要か、やってみなければわかりません。しかし、オンプレミスの場合はある程度の容量を想定して導入しなければなりません。普段は想定内で収まっていても、ひとたびキャンペーンを打つと不足する、逆に常に想定以下で、ロスが出てしまうといった不具合が発生します。なかなか適正化は難しいものです。
しかしAWSは、実際の利用に追従してキャパシティを増やしたり減らしたりできます。
キャパシティの伸縮の方式は２つあります。1つは、CPUのサイズを増減する方式(スケールアップ/ダウン)、もう一つは、サーバーの数を増減（スケールアウト/イン）させる方式です。
こうすることによって、キャパシティの弾力性が実現でき、コストも最低化できます。
現在、AWSには200以上のサービスがあります。これらのサービスの90％はお客様の「こういう機能がほしい、追加したい」という声を受けて開発されました。これらを自由に組み合わせることで、お客様のニーズに合ったシステムを短期間で構築することができます。
現在AWSは25の国と地域に拠点があり、81カ所にデータセンターを持っています。
日本では、東京と大阪にそれぞれ複数のデータセンター群があります。
各データセンターは、物理的に100キロ以上離れたところにあり、地盤、川の氾濫リスクや電機の供給経路等を考慮して、1か所で何かインシデントがあっても他は影響がないところを選定しています。高い耐障害性を備えているので安心してご利用いただけます。
AWS責任共有モデル
AWSにとって、セキュリティは最優先事項です。当社では責任共有モデルという考え方を取り入れています。その意味するところを下図に示しています。
図の下半分は、AWSのセキュリティに対する責任の範囲を示しています。上半分は、お客様の責任範囲です。AWSが管理するのは、あくまでもクラウド環境の基盤のみで、クラウド内のデータ自体についてはお客様が管理することになっています。AWSはお客様のデータを見ることはできません。これをAWS責任共有モデルと呼んでいます。
セキュリティの方針
AWSは、CSA、ISO、SOCなど主要な規制・標準・ベストプラクティスに準拠していますので、安心してご利用いただけます。AWSのお客様は第3者機関の監査を受けたレポートをAWSの管理コンソールからリクエストしてダウンロードすることができます。
Amazonは、数年間にわたり大規模なデータセンターを構築しています。その重要な特性は以下のとおりです。
① 場所の秘匿
② 周囲の厳重な制御
③ 物理アクセスの厳密なコントロール
④ 2要素認証を2回以上でアクセス
これを徹底しており、すべてのアクセスはロギングされ、チェックされています。物理アクセス可能な従業員は論理権限にアクセス不可となっています。
株式会社 あきんどスシロー様からは、「40億ものデータをクラウドに転送し3日後には分析が可能になった。費用も10万円程度と、安価にトライアルを行うことができた」「BIツールが豊富」「信頼性と安定性があり、サポート体制も整っていた」など評価をいただいています。
※詳しくは、AWSのウェブサイト（導入事例：株式会社 あきんどスシロー）をご覧ください。
Amazon Connectを活用いただいた事例です。Amazon Connectは、コールセンターをオールインワン・従量課金で提供するサービスです。
東京電力エナジーパートナー様は、コールセンター業務を行っていますが、お問合せ電話が「つながりにくい」「保留が多い」「対応時間が長い」という課題がありました。人員を増やすと、それに伴い固定電話などの機器も必要となるため簡単ではありません。Amazon Connectは、固定の電話が不要で、パソコンとヘッドセットさえあれば、何人でも利用できます。また、AIサービスなど他社サービスも組み合わせ、ある程度、機械で要件を聞きとってからオペレータに情報を送ることで、処理時間を大幅に削減できました。将来的には、通話内容を含む問合せログを分析し、ニーズを深掘りし販売領域展開に活用する考えです。
AWS のマイクロサービスアーキテクチャを活用し、3,300 万人が利用するQRコード決済サービスを3カ月でリリースした事例です。
当初はオンプレミスも検討されていましたが、時間と手間を短縮したい、また高いセキュリティも確保したいということから、AWSを導入いただきました。
PayPay様は、コアの決済部分はAmazonS3、データベースではAmazon Aurora、Amazon Dynamo DBを使っていただいています。また、マネージドサービスを活用いただくことで、運用コストの軽減につながっています。
マネージドサービスは、数クリックで構築可能で、バックアップやバッチの適用、フェイルオーバーが自動で行われます。従来はこれらをお客様が行っていましたが、これが不要となります。最近人気の高まっているサービスです。
※詳しくは、AWSのウェブサイト（導入事例：PayPay株式会社）をご覧ください。
クラウド化は次の４つのプロセスがあります。これを、我々はクラウドジャーニーとよんでいます。
プロジェクトフェーズでは、ごく限られたシステムでクラウドを試して効果を検証する。ファウンデーションフェーズでは、推進組織が立ち上がり、そこが先頭となってクラウド移行を推進。マイグレーションフェーズでは長期利用に向けての準備。リインベンションフェーズでは、クラウドがデフォルトの選択肢となり、クラウドの最適化が進みます。
クラウドへの移行を進める際に、ご理解いただきたいのは、既存資産のクラウド移行と、クラウドネイティブなイノベーションとでは、価値の現れにタイムラグがあるということです。
クラウドネイティブのイノベーションに比べて、既存資産のクラウド化は、効果が現れるまでに時間がかかります。このことを念頭において進めるとよいかと思います。
クラウドジャーニーのポイント
以下は、課題と解決策を示したものです。ポイントは、「まずやってみて実体験を得る。完璧を求めず小さく始めて大きく育てる」ことです。
また、推進組織を立上げ、そこが中心となって進めると上手くいくケースが多いです。
そして、社内の組織構造や業務プロセスを見直し、それに合わせてクラウド最適化すること。トップダウンで行うことが成功のポイントです。
クラウド推進組織が何をするか、活動例を以下に示しました。
ロードマップの策定、自社のクラウド基盤の構築、個別案件対応、ガイドライン策定、社内教育等、様々なタスクがありますが、自分自身のスキル向上も必要です。
スキル向上については、AWS認定制度がありますので、これを目安にしていただくといいかもしれません。日経×TECHが実施した「いる資格、いらない資格 2019決定版 / 取得したい資格」のアンケートでは、AWS認定各種が1位となっています。
DXには、小さな失敗を前提にトライアルを繰り返すことが重要
最後に、なぜトライアルと失敗が重要かについてお話ししたいと思います。以下は、Amazonから株主に向けた手紙の抜粋です。
「失敗と発明は切り離せないものだ。発明のためには実験が必要だが、何が正解かやる前からわかっているものを実験とはいわない」ということが書かれています。
Amazonはかつて、スマートフォン業界に参入して大失敗したことがあります。しかし、その失敗は、後のアレクサほかIT家電に引き継がれています。
これからDXに取り組む場合、失敗は不可避です。ある程度の失敗を前提として繰り返しトライアルすることが重要です。その際、短期間で立上げられ、不用になればすぐ止められるAWSは、お客様がより多くのチャレンジを行う助けとなるサービスかと考えております。
関連コンテンツのご紹介
