2005年にGoogle Map/Google Earthが公開されたとき，コンシューマ・ユーザーはその斬新なUI（ユーザー・インタフェース）に衝撃を受けた。Ajaxをはじめとするリッチ・クライアント技術を使ったWebサイトや企業情報システムが続々登場してきた。しかし，その裏でサーバーの方もすごいことになっていた。

　検索やECサイトなどのサービスを提供するために，GoogleやAmazon，Microsoftでは，数十万台単位のサーバーを運用するデータセンターを作り上げていた（関連記事：「「ゲイツ後」の世界」）。各社はメモリーやプロセスの分散技術やシステムの管理技術を駆使して，けた違いの数のサーバーを運用している。そのインフラをサービスとして公開し，誰もが様々なアプリケーションやミドルウエアを載せられるようにした。これがクラウド・コンピューティングの実体である。

　よく「鶏が先か卵が先か」という議論があるが，クラウドの場合は鶏（サービス）が先で，卵（インフラ）が後であることがはっきりしている。だから，クラウドには「箱（インフラ）だけ作って中身（サービス）はどうするの？」というジレンマはない。それだけに，彼らの語るクラウド・コンピューティングにはリアリティがある。

　最近のGartnerの調査によれば，世界のサーバー出荷台数は2008年第2四半期に前年同期比で12.2％増え，売上高は同5.7％増加した。増加要因として挙げられているものの一つが「Webデータ・センターの増築」だという（関連記事：「2008年Q2の世界サーバー市場は5.7％増収，x86サーバーの買替需要が貢献」）。ユーザー企業がサーバーを購入して自らが運用する時代から，データセンターがサーバーを購入してユーザー企業がそれを利用する時代に移りつつあることは間違いない。

　ただ，このクラウド・コンピューティング。調べれば調べるほど分からないことが出てくる。どういうコンセプトでどういう製品・サービスが登場してきたのかは少しずつ分かってきた。だが，それを利用してシステムを開発・運用する現場の姿をイメージできないのだ。

　ここ数年のうちに，クラウド・コンピューティングは企業情報システムのインフラとして欠かせない選択肢になってくるだろう。ミッションクリティカルなシステムも乗ってくるかもしれない。そのとき，ユーザー企業は多くの課題を抱えるに違いない。どんな課題があるのか，思い付くまま並べてみる。

データは移せるのか

　システムにリプレースがあるように，サービスのリプレースもある。A社のSaaSからB社のSaaSにリプレースする場合，A社のSaaSに蓄積されたマスター/トランザクション・データをB社のSaaSに移行しなければならない。その際，どういう形式でデータを出力できるのか，どうやってデータを運搬するのか。セキュリティはどうやって確保するのか。その作業を誰がやるのか。そもそもマスター/トランザクション・データのすべてを丸ごと抜き出すといったことが可能なのか。

　それらをクリアした上で，システムの切り替えがまた難しそうだ。ミッションクリティカルな基幹システムの場合，新旧システムの切り替えはそれだけで一つのプロジェクトである。少なくとも2～3回，多ければ10回近いリハーサルを経て，切り替え当日に臨むものである（関連記事：「最後の難関 システム移行」）。途中で何が起きてもすぐに対応できるように，担当者はシステムに物理的に張り付いて作業をする。

　これに対して，クラウドには物理的なロケーションの概念がない。すべてネット経由で済ますのが原則である。途中で予期せぬ事態が起きたときに，復旧を図るのか，切り戻すのか。何を根拠にそれを判断するのか。社内にサーバーを置いている場合や，国内のデータセンターにアウトソーシングしている場合とは，違った方法を考える必要があるだろう。