失敗1：クラウドだと思ったら、クラウドではなかった

　最初に亦賀氏は、「クラウドコンピューティングが世の中に登場して6年経過したが、いまだに混乱が収まっていない」とクラウドがきちんと理解されていないことを指摘。それを踏まえ、まず「クラウドだと思ったら、クラウドではなかった」という、クラウドがきちんと認識されていない問題を挙げた。

　「現在のクラウド市場には、本物のクラウドと偽クラウドが混在している。それが本物のクラウドかどうか、分かりにくかったらすし屋に例えて考えると分かりやすい」とユニークな判別方法を紹介した。

　この判別方法は、すし屋には銀座の高級店のような松、高級店ではないがある程度、注文ができる店舗の竹、一定のメニューが流れるだけで顧客の注文を聞かない回転ずしの梅と3ランクあり、これをクラウドに置き換えて例えるもの。

　本物のクラウドは事前にメニューが示される標準サービスのみで、自動化によって低コストを実現している。すし屋でいえば梅の回転ずしに当たり、「Amazon Web Services」（AWS）がこの典型例だ。

　それに対しメニューはなく、顧客の注文を受けて構築を行う銀座の高級すし店型クラウドは、「クラウドではなくアウトソーシング」だと指摘する。

　さらに、「現在は社外に置かれたシステムが全てクラウドと呼ばれている。クラウドを利用したいのであれば、目利きの力で見極めて選択するしかない」と選択者自身が力を付けるしかないと指摘する。

　推奨対策としては、

1. 本物と偽を同じものとして扱わない
2. プロバイダー選択は容易ではない。まずはプロバイダーがクラウドの本質であるスケールビジネス、テクノロジーによるサービスなどを理解しているのかを見抜く
3. 安易に近場のシステムインテグレーター（SIer）に頼まない

という3つを挙げている。

失敗2：ベンダーにクラウドの見積もりを頼んだらコストが高かった

　失敗2として挙げたのは、「ベンダーにクラウドの見積もりを頼んだらコストが高かった」という例。失敗1で紹介した本物のクラウドと偽クラウドが混在していることから起こる問題だ。

　亦賀氏は、「通常のシステム構築では、要件を多く出せばそれだけ工数が掛かる。これはクラウドでも同じ」と指摘する。クラウドの場合、サービスのインフラ（IaaS）と割り切って利用すればコスト安が実現できる。

　しかし、これまでのシステム構築同様、「要件を頼んでいるうちに料金が高くなる。まさに銀座の高級すし店に当たる松レベルとなってしまう。コストを下げたかったら、あるものをそのまま使う。もしくは要件レベルを下げる。要件レベルを下げることができない案件ならば、クラウドは必ずしもベストな選択ではない」とクラウド以外を選択することの方が得策の場合もある。

失敗3：クラウドベンダーにRFPを出したら断られてしまった

　失敗3は、「AWSなどにRFP（提案依頼書）を出したら断られてしまった」という問題。「回転ずしにRFPを出すのはおかしい。クラウドは標準サービスであり、自社要件をぶつけるのは、回転ずし屋やファストファッションブランドにオーダーメイドができないのかを発注するようなもの」。そもそもそうした発注をすべき相手ではないことを認識していないところから起こると述べる。

　標準サービスを提供するAWSのようなクラウド事業者に対しては、RFPは出さない。SIerや個別の運用案件に対してはRFPを出す。「何でもRFPを出せばよいということではない」というのが亦賀氏の主張だ。

失敗4：クラウド導入後、10年使う計画を立てている

　失敗4は、「クラウド導入後、10年使う計画を立てている」という例。「これだけ変化が激しいご時世で、10年使い続ける計画というのは疑問を感じる。長く使い続けるにしても5年が限度ではないか」と長期利用を想定するユーザーに対し、亦賀氏の見方は厳しい。

　ただし、これはユーザーを誤解させるベンダー側のアピールにも問題があり、「確かに広告を見ると、クラウドで10年使い続けることができる、安くなるとアピールしている。経営者が、それができるのではと期待してしまうは分かる」。

　だが、「10年使い続けるというのは、ミッションクリティカル業務でのクラウド利用を想定しているのかもしれないが、ミッションクリティカル業務とクラウドは切り離して考えるべき」と、現段階ではクラウドをミッションクリティカル業務に利用すべきではないと指摘する。

　その上でクラウドに関しては、導入するクラウド／導入したクラウドは3年程度で見直す。よく言われるクラウドファーストとは、クラウドを早く導入することではなく、変化対応型のサービスを前提に、業務などの変更も視野に入れてクラウド導入検討することだ。「絶対に業務を変えない」という発想は、時代の流れにはそぐわないため、変化前提で業務も含めて見直すことを推奨している。

　「昔は回転ずしという選択肢はなかった。今は回転ずしという選択肢ができた。そこで業務案件は回転ずしを利用してはいけないのか考えるべき。いつまでも銀座の高級すし店のような要件定義を細かく発注するままでいいのか？　もちろん、銀座のすし店のようなスタイルが悪いというわけではない。例えば銀行の勘定系システムは、松のさらにその上の特上レベル。これは特上レベルのままである必要がある。しかし、基幹業務の代表格である『SAP ERP』でさえSLA（サービスレベル保証） 99.999％を保証しているわけではない。全業務システムに99.999％のSLAを求めると、その企業の競争力は失われる」

失敗5：プライベートクラウドの構築に2年かけようとしている

　失敗5は、「プライベートクラウドの構築に2年かけようとしている」という例。

　「プライベートクラウドの構築期間はせいぜい1年程度。主要ハードウェアベンダーは、垂直統合製品をラインアップに持っているので、それを利用すれば3カ月で構築できる」とプライベートクラウドといえど、構築期間は以前よりも大幅に短縮している事実を挙げる。

　松レベルの案件であれば2年かかるものもあるが、リファレンスアーキテクチャ、統合システム、発注するユーザー側の割り切りによって1年から半年で構築できることが普通。「それを超える提案がベンダーから挙がってきた場合には、おかしいと考えるべきだ」と説明している。

失敗6：そのプライベートクラウドは、サーバ仮想化共通基盤であった

　失敗6は、「そのプライベートクラウドは、サーバ仮想化共通基盤であった」という例。

　確かにユーザー側はプライベートクラウドと称しているものの、実際には仮想化にとどまっていたという例はよく耳にする。それに対して亦賀氏は、「クラウドと仮想化は似て非なるモノであることをきちんと認識すべき」と指摘する。

　では仮想化ではなく、本物のプライベートクラウドとはどんなものかを理解できない場合は、「分からない場合は、取りあえずAWSを使ってみるべき。インターネットが登場したときも、パソコン通信とどこが違うのかという人がいたが、机上の議論で理解できないものは試してみることだ。試すこともせずに、分からないと言っていてもそれ以上は進まない」と試すことを勧めている。

　きちんと定義すれば、仮想化とは下位レイヤーの特性、振る舞いを隠蔽する仕組みであり、クラウドは必要なときに、必要なサービスを早く、安く、より満足いく形で提供する仕組みとなる。それを踏まえれば、クラウドと仮想化は異なる概念であると理解できる。クラウドを構築するのであれば、提供されるサービスを規定し、そのために必要なテクノロジーを洗い出し実装することを推奨している。

失敗7：プライベートクラウドを作ったが、使ってもらえなかった

　失敗7は、「プライベートクラウドを作ったが、使ってもらえなかった」という例。

　「社内向けプライベートクラウドといえど、単に作っただけで利用者が使うものではない。社内でのマーケティング、プロモーションは必須」。社内向けといっても、特徴やメリットをユーザーに対して訴えていくべきだとする。

　最近では、現場主導でAWSを導入している企業もあり、「プライベートクラウドがAWSと比較される」ケースも出てきている。これに対し、AWSとの違い、メリットといった点をユーザー側にきちんと伝える。例えばAWSの場合、見かけの価格は安いが全てセルフサービス。対してプライベートクラウドは見かけの価格は高くなりがちだが、何かトラブルが起こったらすぐに情報システム部門が対応するといった人間系サービスが付随し、実はユーザーにとっては利用しやすい環境が整っている。コストも人間系を含めると、実はプライベートクラウドの方が適切なコストというケースも多い。

　インフラ部分、人間系サービスを明確に示し、社内ユーザーにとってどんなメリットがもたらされることになるのか、口コミではなくプロモーション活動を行って訴求していくことを推奨している。

失敗8：そのハイブリッドクラウドは「ファイル転送」であった

　失敗8は、「そのハイブリッドクラウドは『ファイル転送』であった」という例。

　3年前に、「ハイブリッドクラウドを既に実践している」と主張するユーザーがいたが、実はそれはファイル転送を行っていたにすぎなかったという例があったという。ファイル転送はサービスではなく機能だが、ハイブリッドクラウドはプライベートとパブリック、パブリックとパブリックなどが、ユーザーから見て統合された1つのサービスを指す。

　「ハイブリッドクラウドについては議論先行で、慌てて取り組む必要はない。逆に理想を描きすぎると、過度な期待だけが膨らんでしまうことも。現段階でのハイブリッドクラウドは議論先行で、概念でしかない部分がある」と急いで飛びつく必要はないとした。

失敗9：クラウドは思ったよりも、もうからなかった

　失敗9はユーザー側ではなくベンダー側の失敗例で、「クラウドは思ったよりも、もうからなかった」という例。

　これはそもそも、「ユーザー側はクラウドによるコスト削減を期待しており、そのユーザーに導入するクラウドがもうかるという話はもとより存在しない」と、ユーザー側がコスト削減を期待している以上、ベンダーにとっても利益がそれほど出ないのは当然という意見だ。

　亦賀氏はこの現実を踏まえ、「ベンダー側は標準サービスをきちんと規定しなければならない。クラウドはスケールビジネスであり、数を売ってナンボの世界。数を売るためにはマーケティングの仕組みが必要」と従来のシステムインテグレーションの非スケールビジネスからの脱却が必要だと提案する。

　その上で、ベンダー側はクラウドをスケールビジネスという観点で捉え直し、戦略を見直し、ユーザー側はそのベンダーが本物のクラウドをビジネスとすることに積極的なのかをあらためて確認することを推奨する。

失敗10：何となくクラウドを選ぼうとしている

　失敗10は「何となくクラウドを選ぼうとしている」という例。

　「これからはクラウドが当たり前」という声に引き寄せられ、何が良くなるのかを考えないまま、何となくクラウドを選択するというケースだ。戦略的にクラウドを導入するために、クラウドの本質の理解、継続的にインフラについてコスト、スピードなどの何かが良くなるように進化させるという観点を持つ必要がある。

　「全てがクラウドに適しているわけではなく、適材適所で、銀座の高級すし店のメニューが必要な場合もある。クラウドを導入すれば何が良くなるのかをきちんと考えるべき」

　そもそもクラウド以前に、ビジネスとしてインフラの何を良くすべきなのかについてよく考えることを推奨する。そのために、まず評価指標＝メトリクス（ビジネスパラメーター）を洗い出す。この評価座標を経営者に示すことがCIOとして仕事をする人には必須になると亦賀氏は指摘する。

クラウド導入を失敗する5つの原因

　この10個の例を踏まえ、「なぜ失敗するのか？」を顧みると、次の5つの原因に集約される。

1. 安易なクラウド導入（流行、何となく理解）
2. 絶対こうだという思い込み
3. これまでのやり方を踏襲
4. 自社、自分が世界の中心
5. 偽クラウドの存在

　これに対するガートナーからの提言は次の通りだ。

• 安易にクラウド導入を進めない
• クラウドコンピューティングとは何かをあらためて理解する
• 本物と偽物のクラウドを区別する
• 近場のSIerに安易に依頼しない
• 要件（業務・運用・システム）を見直すと良くなることはないかを検討する
• 業務の棚卸しと仕分けを行い、梅クラスを多く出す
• 本物のクラウド（梅）を「割り切って」使う
• メトリクス（ビジネスパラメーター）を洗い出し、継続的に改善ができるようにする
• ベンダーは、何でも簡単に「もうけられる」とは考えない

　亦賀氏は、「消化不良のままで議論を重ねても成功はない。力強い戦略を立案・推進するために全て再考し、来週からは是非戦略的展開を行ってもらいたい」と締めくくった。