ウォールドガーデンの功罪

　前回「クラウド事業者がサービスを中止する5つのケース」で紹介したVisaによるPCI DSS活用は成功しているウォールドガーデンの事例である。Visaの決済システムを利用してVisaのカード情報や取引情報を保管、処理、送信している全ての企業はAIS（Account Information Security）プログラムに参加しなければならず、AISの要件には前回紹介した厳密な実装要件を持つPCI DSSが含まれている（参考：AISプログラムとは？）。このハードルを乗り越えPCI DSS要件を満たし第三者認証を得ると世界200カ国以上で流通し、総取扱高5.9兆ドル、カード発行枚数19億枚に達するVisaの決済市場に参入することができる。しかも、前回紹介したクラウド業界団体CSA（Cloud Security Alliance）のCMM（Cloud Controls Matrix）が明らかにしたように、PCI DSSが定義しているセキュリティ要件は当代一流の内容となっており、Visa AISプログラム参加者はガバナンスモデルについて、かなりの部分で自ら定義する責任から解放されるのだ。実によくできたエコシステムといえる。さらにVisaは2011年6月には「PCI DSS v2 Virtualization Guidelines」も公開してクラウドでのPCI DSS利用も推進している。

　また、身近なところではAppleのiTunes StoreやGoogle Play、Facebookもそれぞれウォールドガーデンを形成し、それぞれの視点で閉じたエコシステムを形成する努力を続けている。これらの現在成功している／成功しようとしているウォールドガーデン群は、かつて一世を風靡したNTTドコモのiモードを徹底的にケーススタディした上で設計されている。これらのサービスがそろって特定キャリアによるベンダーロックインを排除するデザインを採用しているのは興味深い。iモードが、携帯電話サービスの差別化戦略の文脈から生まれてきたために、独立したコンテンツサービスとしてアンバンドルすることが許されず、NTTドコモ携帯電話サービスの契約者数以上に成長しえない制約を負っていたのに対し、これらの新世代ウォールドガーデンは複数のキャリアにまたがる、より大きなウォールドガーデンを形成することで限界市場規模をほぼインターネット利用者総数と一致させることに成立している。あるロックイン戦略が、よりくくりの粒度の大きなロックイン戦略の登場によって世代交代していく例証といえるだろう。ちなみにiモードのARPU（Average Revenue Per User：月間電気通信事業収入）推移は2010年3月期まではIR資料上iモード単独ARPUとして記載されていたが2010年4月以降は開示されていない。

　もちろん、クラウド事業者もウォールドガーデンを形成する努力をしている。米Amazon Web Servicesが次々と発表する独自機能も、米RackSpaceが中心となって推進しているOpenStackも、それぞれの競争戦略に基づくウォールドガーデン育成努力の一部だ。

ウォールドガーデンとの向き合い方

　筆者は市場の勃興期であるなら比較的小規模な利用者は、自らの目的とよく適合したウォールドガーデンを選び、参加したウォールドガーデン内での競争と協業の過程で形作られるネットワークが複雑に成長する機会を捉えるだけで十分なメリットを得ることができると考える。

　一方、中堅以上の規模の利用者となると話はそこまで単純化できない。生まれたばかりの赤子ならキッチンの流しだって広々としたバスタブに思えるだろうが、小学生がまねをすれば風邪をひく。まして大人なら体を押し込むことすらできないだろう。実は国内のクラウドに限っていうと、現在はこれと同じ状態だ。JEITA（電子情報技術産業協会）サーバ出荷統計とユーザー調査報告のデータを基に試算すると、2011年度末時点に国内で稼働しているIAサーバは180万台強と見込まれる（図1）。

図1　JEITAサーバ出荷統計、ユーザー調査報告書を基に筆者試算

　これに対して一説には国内でも最大といわれるAmazon Web Services（AWS）東京リージョンのサーバ台数はHuan Liu氏によると2万台と推定（ただし筆者はこのAWS東京のサーバ台数試算は過大と考えている）されているので、国内稼働サーバに占める台数シェアは実は1.1％にすぎない（参考：Huan Liu's Blog「Amazon data center size」）。もちろん導入年度が新しいAWSのサーバ（ここでは仮に2011年製としよう）によって現在国内で稼働している古参サーバを置き換えるわけだから、計算能力ベースで比較しなければ意味がない。IAサーバとしてのJEITA統計が整備され始めた2002年を起点として、その年に出荷されたサーバ計算能力はムーアの法則に従って増大していると仮定し総計算能力を算出すると、AWS東京リージョンは現在国内で稼働しているサーバ能力の1.96％を賄える程度の物理資源量を保有していると推測できた。この能力は2002年に国内で出荷された全IAサーバの計算能力の総和にほぼ匹敵する。とはいえ、現在国内に供給されている総計算能力の2％に満たないので、大規模な計算資源利用者の需要を全て即座に置き換えることができるわけではない。もちろんそんな受注があればクラウド事業者としてはうれしい悲鳴を上げたくなるかもしれないが、そんな無理をすればクラウドの本質的特徴であるResource poolingとRapid elasticity要件を満たすことができなくなってしまう。

　当然、受注が増えればクラウド事業者は設備を増強するし、IDCが予測する年間平均成長率41.2％に近い驚異的な速度で普及が進むだろう。ただし、出発点となる現在の国内計算資源に占めるクラウドの計算能力シェアは数％だ。過大な期待は禁物といえる。

ベンダーロックインの功罪

　冒頭でも説明したが、まさか最初から不幸になろうと思って取引を始める不合理な判断は、まっとうなコーポレートガバナンス体制を持つ組織では許されないので、利用者がベンダーと取引を開始する際はWin-Winの幸福な関係で始まる。しかし市場環境の変化など、ガバナンスモデルが示すさまざまなリスクが顕在化することによって、初めは幸福だった取引関係が時には急速に不幸な関係に変化していくことがある。また、特段大きなリスクの顕在化が起こらなかった場合でも、時間の経過がいや応なしにレガシー問題を迎え入れる。それまで取引してきたベンダーが利用者とともに手を携えてレガシー問題を乗り越えられればよいが、レガシー問題を乗り越える際にベンダーと利用者で方針の不一致が起きた場合、リスクが顕在化する。これは技術が進歩し続けている現代ではどうしても避けられない問題だ。

　自前で強力なITガバナンスを実行できる利用者であれば、自らの統治モデルに基づいて個々の問題を処理していけばよいだろう。しかしCIO職の設置を含む強力なITガバナンス体制を敷ける利用者はそう多くはない。ITガバナンス体制に不安のある利用者にとって最も手っ取り早い問題解決策は、ベンダーロックインするリスクを受け入れ、引き換えにウォールドガーデンによる保護を得ることになる。

　ただ、どんなに強力なウォールドガーデンの保護の下にあってもレガシー問題はいずれ起こるし、レガシー問題に直面する前に他のリスクが顕在化して、ベンダーロックインのくびきから抜け出さなければならなくなることもある。実は、ベンダーロックインに苦しむのは特定のウォールドガーデンのガバナンスモデルに過剰適応しているためだ。ウォールドガーデン中毒にならないためには、できる範囲からでも他の選択肢についての理解を深めたり、自身を保護しているウォールドガーデンの統治モデルを理解し、その制約が何なのかを意識し、賛否両論を常に把握し続ける努力が必要だ。その点、昨今盛んに行われている各種勉強会などは大変好ましい潮流と見ている。

　ところで、こういった将来リスクへの対応は問題が差し迫っていないだけに難しいが方法がないわけではない。先に市場のロックインパラダイムはステップバイステップでよりくくりが大きな粒度にシフトしていくことを説明した。これを反対側から見れば現在利用している、つまりロックインしているサービスを規定している定義より一段上の粒度の動向を観察していれば、数手先とまではいわないまでも次の次くらいまではある程度見通しを立てられる。よほど強力なデファクトスタンダード（事実上の標準）が電光石火で市場を支配した、といった場合でない限り標準策定状況の観察は先行指標として利用可能だ。

図2　　

　現在利用しているサービスが依拠しているスタンダードの上位粒度での標準化が活発になっているようなら、そのサービス分野にオープン化（実は次の粒度でのロックイン）の波が押し寄せてくる兆しといえる（図2）。

　予測はその性格上、個別の技術など対象が細かい粒度になればなるほど精度が落ちるため、あまり信を置くのは考え物ではあるが個別技術の成熟度予測も国内ならNEDO（新エネルギー・産業技術総合開発機構）が技術戦略マップとして公開しているし、一部翻訳もされている海外の予測としては米GartnerのHype Cyclesが有名だ。

　これまで本連載「クラウドガバナンス現在進行形」で紹介してきた各種標準化動向や今回紹介した技術開発動向予測などを参考にしつつ、現在利用しているウォールドガーデンのガバナンスモデルを第三者的視点で眺める習慣を付けるだけでも過剰適応を抑止する効果は期待できる。

クラウドのベンダーロックインを回避するための処方せん

　ここまで見てきたように、現時点での国内クラウド事業者の保有する計算資源量はまだまだ限られている状況でもあるし、ガバナンスモデルが要求するポータビリティ、相互運用性の確保、ひいては事業継続・災害対策の要求に対応し、ウォールドガーデンへの過剰適応も抑制したい。そこで有効な手法を4つ挙げておく。

1. オープンな技術の採用によってポータビリティを確保
2. 代替性の低いサービス採用は割り切りが必要
3. トレーサビリティを確保した上で複数の取引先へ分散発注
4. メトリクス情報の提供に消極的な事業者との取引を避ける

1．オープンな技術の採用によってポータビリティを確保

　OSS利用はベンダーロックインを回避する上で非常に有効な手法だ。いざとなればソースコードを自らメンテナンスすれば非常に長い期間にわたって利用継続できるし、開発者や利用者の多いOSSならベンダー切り替えも容易だ。

2．代替性の低いサービス採用は割り切りが必要

　非常に高度な機能や特殊な機能を提供するプロプライエタリ技術を採用する場合は、オープンな技術で代替できない範囲に絞って利用することでリスクを最小化できる。また、オープンな技術での代替性判定をあらかじめ行っておくことで、その技術がベンダーロックイン問題化した際の影響範囲を特定することもできる。

3．トレーサビリティを確保した上で複数の取引先へ分散発注

　クラウド調達におけるトレーサビリティ、すなわち追跡可能性の確保とは、取引先候補となるベンダーの取得している認証の取得範囲やその認証条件をSAS70や18号監査、ISAE3402報告形式で提供されるかを問うものだ。当然、そのベンダーが利用している二次ベンダーなどバリューチェーン全体にわたって透過的に報告を得る必要がある。こうして取引先のガバナンス体制について第三者認証を介した間接的な方法で確認した上で、同等条件を提供可能な複数のベンダーに分散して発注し、オープンな技術を利用することで代替性を確保することができる。

4．メトリクス情報の提供に消極的な事業者との取引を避ける

　メトリクス情報の提供に消極的な事業者の掲げるSLA条件は、検証可能性が担保されないので信頼に値しない。実は、良心的な事業者とそうでない事業者を見分ける一番確かなポイントがメトリクス情報の開示状況だ。もちろん事業者の立場に立つなら詳細なメトリクス情報の一般公開が進んでいない現状において、自社だけ突出した公開を行うのは競争上のリスクを伴う。将来的には電気通信事業における電気通信事業法に基づく電気通信役務通信量等状況報告（年報はTCAがテレコムデータブックとして公開している）のように公開が原則になるだろうが、当面はベンダーと個別にNDAを締結して開示を受けることになるだろう。

姿を現しつつある次世代クラウドと新たなロックインモデル

　第1回「“オレオレクラウド”にはこりごり、クラウドの本質を知る」で解説したNIST SP800-145に基づくクラウド定義に続いて、第5回「クラウドの応答性能とサポート品質を客観的に比較するには」で紹介したSP500-292によってクラウドのアクター構成が明らかになってきた。どうやらクラウドは、さまざまな事業者が複雑に連携してサービスを実現する世界になりそうだ、というところまではおぼろげながら見えてきた。

　2011年12月のクラウド座談会「2011年クラウド業界を振り返る　～IaaSの発展、混沌としたPaaS業界の行方」で筆者と同席した電通国際情報サービスの渥美俊英氏も2012年2月28日にCloud Day Tokyoのパネルディスカッションで述べているように、国内SIerによるクラウドブローカー化の取り組みも始まっているし、IDCフロンティアはRightScalのマルチクラウド管理機能を利用してハイブリッドクラウドに取り組んでいる。OSSでは筆者も参加している日本Cloud Foundryグループなどが活動を開始している。

　実際に動き始めたクラウド上でのバリューチェーン形成が進むと、同一のOSSパッケージを採用している、といった小さい粒度でポータビリティを確保する場合、早いタイミングでRapid elasticity提供が難しくなることが容易に予測できる。筆者が2011年夏まで本業の方で開発に携わっていたcopse projectはこの問題に解を与えるべくSOA（Service Oriented Architectur）に基づいたアーキテクチャモデルを採用しESB（※2）を実装していた。ところで、筆者はかねてクラウドインフラストラクチャ向けのSOA標準が必要だと考えていたのだが、2012年1月17日にUNIXの定義策定でも知られるThe Open Groupによって「Service Oriented Cloud Computing Infrastructure Framework」（SOCCI）が公開され衝撃を受けた（図3）。これほど早期に標準モデルとして整理され得ると考えていなかったからだ。本稿でSOCCIの詳細を解説するには紙幅が足りないので別の機会に譲ることとするが、SOCCIはNIST SP500-292を実装に落とし込む際の大変有効な指針となり得るし、筆者がこだわる“開かれ”、相互に接続された将来のクラウド利用実現に向けて重要な一歩となることだけ指摘しておきたい。

※2　ESB（Enterprise Service Bus）：SOAを実現する技術の1つ。標準仕様（copseではSOAP）に基づいて記述されたコンポーネント相互の接続を実現する論理バスで、ESB自体もコンポーネントの1つである。

図3　SOI and SOA RA Layer Mapping《クリックで拡大》

　The Open GroupによるSOCCI公開によって一段とIaaS層におけるベンダーロックインリスク低減シナリオに現実性が見えてきたが、当然、ハイブリッドクラウドやSOAクラウドが一般化した際に有効な新たなベンダーロックイン＝ウォールドガーデン形成を目指す動きも既にある。前回および今回解説したVisaの進めるPCI DSSもそうだが、Mobile World Congress 2012でキャリア決済を発表し、その翌週には米HomeDepotとの提携を発表するなど、このところ活発な活動を見せるeBay PayPalがそれだ（図4）。これらの旺盛なサービス開発を支えているのが2009年に公開されたPayPal XプラットフォームとAdaptive Payments APIだ。通信キャリアやデバイス、ネットからリアルまで、さまざまなウォールドガーデンを跨いだエコシステム＝ウォールドガーデン形成に精力的に取り組んでいるといえる。

図4　PayPal X発表時（PayPal Innovate X 2009）に公開された機能群構成ポスター

結局、クラウドガバナンスとは何なのか？

　今回を含めて7回にわたって見てきたように、クラウドもまたITシステムでありサービスである以上、単一ベンダーに頼っている限り、ほとんどの局面は従来通りのITガバナンスの枠組みで統治可能だ。しかし、NIST SP500-292が示し、筆者が本連載でしつこく繰り返してきたようにクラウドは“開かれ”、相互に接続された世界を志向している。ここに単一企業のガバナンスフレームワークのスコープを超える、本当の意味でのクラウドガバナンス整備の必要性がある。真のクラウドガバナンスの本質は、多くの事業者によって提供されるサービス化されたIT機能群バリューチェーンの統治を指す。言い換えるなら、複数のウォールドガーデンを跨ぐITサービス利用に必要なガバナンスの体系であり、ウォールドガーデンを運営する事業者や立地する国家など、関連するレイヤーを跨ぐ共同規制の枠組みでもあるといえる。この点、機会があればぜひ論じてみたい。

川田大輔（かわだ だいすけ）

Cloud Architect、クラウド設計士。18年にわたり大手ソフトウェア／ハードウェアメーカーでのマーケティング、ITベンチャーでの事業開発、技術開発、技術投資業務を経験し、2009年より現職。技術からマーケティングまで包括したICT関連事業の立ち上げを専門にしている。近作はNIST準拠のOSS Cloud Architecture、copse。

本稿での記述内容は個人の見解であり、その責任は全て筆者個人に帰するもので、所属する組織を代表する意見ではありません。