戦略領域へのクラウド活用　イノベーションを起こす使い方（2）

イノベーションのための技術

　ここで紹介する技術の大半は、従来的な社内システムをクラウドに移行する場合には「不要」か、あるいは「先進的すぎて使えない」とされてきたものである。筆者自身、クラウド移行を検討中のユーザー企業に対するコンサルテーションの途上で、「これらの機能や特性は使わないので無視していい」と言い切ったことすらある。既存システムでは出番の少ない技術なのだ。しかし、イノベーションの基盤として「使い甲斐のある」機能が豊富にあるのは事実だ。今回は、その観点から説明していく。

　ところで、しばしば、このようなアプローチに強い違和感を訴える人（まれに技術者）がいることは残念だ。たとえば、次のようなスタンスを強く持っている方だ。

　これに対し、本章における筆者の態度は真逆である。

　これは、もう、価値観の問題なので、どちらが正しいとか優れているという議論をする気はないが、それにしても前者の態度は寂しい。世の中の発展（ビジネスの質的拡大）にはまったく寄与する気がないようだ。「自分の担当は上流なので（ビジネス要件が大事）」というつもりなのだろうが、しょせんは安全圏にいるご用聞き（要件ヒアリング屋）なのだろう。ひところ、IT系のイベントで「エンプラ＝オワコン」（エンタープライズ系の技術者は時代遅れで役に立たない）といわれたが、その典型と言える。

道具が変われば、結果も変わる（量の変化は質の変化を伴う）

　たとえが悪いかもしれないが、子どもが生まれて初めて自転車を買ってもらったら、世界が広がったと思うだろう。今まで行かなかった場所に行くようになるだろう。大人が初めてバイクやクルマを手に入れても同様のことが起きるはずだ。その前後では、ライフスタイルすら変化することがある。移動技術の変化により、単純に（量的に）移動速度が速くなるだけではないはずで、量の変化は質の変化を伴うのだ。「行く先は今までと変わらない」などという人とは、正直、あまりかかわりたくない気すら覚える。

　せっかくクラウドという革新的なテクノロジーが誰でも手に入れられるようになったのだ。これを使って「あれもやろう」「これもやりたい」と思って欲しい。

　さて、本章の狙いとして、それぞれの技術について「活用できるイメージ」を持ってもらうことが重要だと考えている。したがって、それぞれの特徴やメリットを解説していき、個々の技術の詳細には触れていないし、また、厳密なテクニカルタームも用いていないので、ご容赦いただきたい。

　なお、技術の大半は、AWSのサービス名をベースに紹介する。ほかのクラウドでも同様の機能があるが、AWSが最も多機能で、かつ、「こなれて」いるからだ。より深掘りするための情報がインターネットに平易に見つかるということもある。AWS以外では、Microsoft Azure、Google（Google Cloud Platform）の一部の機能を紹介していく。

DWHの古い常識

　Redshiftが登場する以前の常識では、DWH装置は巨大な装置であり、速度やデータ容量も非常に高度な水準のものが求められるので、クラウドで提供されるものとは考えられていなかった。DWHひとつで物理的にラック1個以上のサイズがあり、堅牢なデータルームやデータセンターに鎮座している姿が一般的だった。価格も数千万〜数億円、年間保守費も同様に高価だった。増設は大変な作業で、費用もかかる。運用も楽とは言えない（データ容量が大きいので定期的なバックアップ取得が大変など）というシロモノである。調達するのも依頼してから数カ月というのが普通であった。

Redshiftの実装

　Redshiftは、多数のノード（仮想サーバー）でクラスタを組み、並列処理でデータベース処理を行う。ノードの数に比例してデータ容量が増え、並列度が増え、処理速度は一定に保たれるという格好だ。ここでもクラウドらしいスケーラブルな特性が現れている。さすがに、ノードの追加はオンデマンドというわけにはいかない。追加自体はオンデマンドで行われるのだが、そのノードにデータを効率よく配分する処理に時間がかかり、データ容量によっては数時間〜1日弱かかることもある。それでも物理的なモノの増設より平易かつ短時間であることは間違いない。

Redshiftの魅力

　スケーラビリティはRedshiftの魅力ではない。利用者の圧倒的な支持を受けているのは、Redshiftの価格、マネージドサービス、そして、オンデマンド性だ。

マイクロソフトのクラウド型DWH

　Redshiftの競合と目されているのが、Microsoft Azureの「Azure SQL Data Warehouse」である。本書執筆時点で、まだ発表から日が浅く（発表は2015年4月）まだ事例の情報がないのと、解説ドキュメントが充実しておらず、基本的な性能（最大容量など）すらはっきりしない。これから情報が充実していくことを楽しみにしたい。ここで着目すべきは、わざわざマイクロソフトがAWSの（Redshiftの）後塵を拝しながらも「クラウド型DWH」に参入してきたという点だ。当該市場が急拡大することが見込まれる強力な証拠だと筆者は考えている。現状では「クラウド型DWHを活用する」といわれても違和感を覚える人も多いと思うが、いずれ、当たり前になっていくことが予想される（図3）。

図3 DWHもクラウド型へ

■■事例：あきんどスシロー■■

　この事例は、著名なビジネス系TV番組でも取り上げられたので、ご記憶の方も多いのではないだろうか。あきんどスシローは、全国約370店舗を構える寿司のレストランチェーンである。報道ではITをフル活用した店舗オペレーションの抜本的改革が話題になった。

失敗から学ぶ発想

　前節のRedshiftの項で「あきんどスシロー」の例を挙げた。巨大DWHの「お試し価格」は、約10万円だったそうだ。お試しの結果として、失敗（データ活用できない）となったとしても、金額はこの程度で済む。オンプレミスでDWHを導入する費用（数千万円〜数億円）に比べれば、たかが知れている。だからこそ、同社はこの「試み」にGOサインを出したのだ。

　クラウドネイティブなシステム（およびビジネス）は、前人未到のシステム（およびビジネス）でもある。すべての事例で100％の成功が保証されているわけではない。いや、むしろ失敗する確率のほうが高いといってもよいだろう。従来であれば、失敗＝「大けが」だったかもしれないが、クラウド時代にあっては、失敗＝「経費処理できるモノ」となった。失敗によって得られる知見やノウハウを考えれば、失敗＝「勉強代」といってもよいだろう。10件トライして1件当たるなら、確率は高いほうかもしれない。

　この辺りの発想の転換は、日本の企業においては非常に遅れているという感触がある。企業規模に限らず、失敗＝「大けが」というセンスが一般的なようだ。筆者のところにも、「新ビジネス」の相談が持ち込まれることがあるが、事業プランが1つしかなく、失敗がまったく許容されていない。

多産多死を許容する

　クラウドを活用することでコストの問題は緩和されそうだが、事業プランの乏しさと、失敗に対する狭量さはいかんともしがたい。失敗するくらいなら始めないほうがマシだと言い出すケースもあり、およそ「失敗から学ぶ」という発想はない。硬直した思考では、時代の流れに取り残されてしまうだろう。せっかく技術が進歩し、クラウドによって新事業の参入と撤退が容易になり、世の中が大きく変わろうとしているのである。「失敗のコストが下がった」という潮流はおおいに活用すべきだ。

　これについて面白い図があるのでご紹介しよう（図4）。AWSがイベントなどで頻繁に流す動画のワンシーン（を筆者が図化したもの）である。図の右からベルトコンベアで「事業アイデア」が続々と流れてくる。中央の「試行」で事業アイデアが実行に移される。事業に失敗すれば廃棄（左下のゴミ箱）。事業がうまく回れば、そのまま継続（左上のベルトコンベア）という絵である。

図4 失敗のコスト低減

　動画では、右からアイデアがどんどん流れてくるので、それを見た瞬間は「そんなに事業アイデアなんて出てくるものではないだろう」と思ったものだが、この動画が言おうとしていることは、もちろんそういうことではない。失敗のコストが下がったので、事業アイデアをどんどん出し、それらの失敗を許容しやすくなった、ということだ。そして事業アイデアの数が多ければ成功が得られる確率も上がる。クラウドを活用して果敢に挑戦しようというメッセージである。

　「多数の失敗なんて縁起でもない」と思われるかもしれないが、失敗から学ぶことは多い。「多産多死」の許容はイノベーションを推進する好業績企業の必要条件だという調査報告もある^※1。クラウドで低コストに（安全に）失敗できる環境が整ったのだ。おおいに活用したい。