クラウドの「？」

懸念はそのとおりと思います。
「だからやらない」ではなく、「どうやってやる」を考えていかなければ。

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

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

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

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

　障害発生時のオペレーションを構築するのも難しそうだ。一般的に，情報システム部門は，システム障害に備えて緊急時の連絡網を整備している。そこには，情報システム部門の担当者のほか，インテグレータ，製品/サービス・ベンダー，利用部門の責任者など関連する会社や担当者の連絡先が網羅されており，ミッションクリティカルなシステムではいつでも必要な担当者が駆けつけられる体制を敷いている。

　「バックアップのバッチ処理が途中で停止した」といった場合，テープ・カートリッジが劣化したのか，テープ装置が故障したのか，バックアップ・ソフトに不具合が生じたのか。障害の切り分けから復旧作業が始まる。そのため，運用担当者のほか，インテグレータ，ハードウエア/ソフトウエア・ベンダー，サービス・ベンダーの各担当者が顔を突き合わせて議論することになる。昨今，増床・新設が相次ぐ日本のデータセンターが首都圏をはじめ交通の便がよいところに集中しているのは，そのためだ。

　そして，今，またC/SやWeb時代のノウハウが通用しない時代が到来しようとしている。クラウドの時代に乗り出そうとするであれば，そこで使われる製品/サービスについての知識を集めることはもちろん必要だが，構築・運用技術の開発も不可欠である。