誰が障害を復旧するのか

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

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

　一方，GoogleやAmazonのデータセンターを利用する場合，緊急連絡先には米国（あるいは日本）の窓口の電話番号やメール・アドレスが記載されるだろう。だが，障害時，上記のように関連する担当者が顔を突き合わせて対策を議論するというシチュエーションは考えにくい。何しろ，システムは“雲の中”にあるのだ。しかも，ユーザー企業は，それが米国コロラド州にあるのかアイスランドにあるのかも分からない。日経コンピュータによれば，Googleのデータセンターは世界36カ所にあり，100万台を超えるのサーバーが稼働している（関連記事：「「ゲイツ後」の世界」）。また，Microsoftの場合，運用担当者1人が担当するサーバーは5000台に上る（関連記事：「Microsoftが自社の「クラウド」を説明，ラックから「コンテナ」に移行」）。一つ一つのシステムに対する手厚いサポートは期待する方が無理というものだ。

　障害時にどのような対応がなされるかは，SLA（サービスレベル契約）によるであろう。クラウドの世界では，コンシューマ用途と同じく，ベンダーが提示するSLAを受け入れるかどうかという契約になる。そして，そのSLAは今のところ，ミッションクリティカルな基幹システムに耐えられるレベルにはない（関連記事：「システム障害で実態が明らかに，Web 2.0企業を支えるAmazonのクラウド・サービス」）。

エンジニアはどう確保するのか

　開発にも壁がある。リレーショナル・データベース製品がシェアを争ってしのぎを削っていたころ，メーカー担当者が最も腐心したのは技術者の確保である。Oracle Databaseの牙城を崩すために，マイクロソフトや日本IBMはOracleのエンジニア向けに比較用の冊子を作成するなどしてアピールしていたものだ。

　クラウド・コンピューティングのいくつかには独自技術が使われている。Google App Engineに使われているデータベース「BigTable」はRDBMSですらない。SQLならぬGQLという独自のクエリー言語を利用する。これまでのデータベースの設計や運用，チューニングの技術がどれだけ役に立つか分からない。新たな技術者を確保できない製品やサービスが普及することはない。

C/SやWeb時代のノウハウが通用しない

　ホスト時代からクライアント/サーバー（C/S）システム，さらにWebシステムに移行したとき，開発・運用の現場は大いに混乱した。ホスト時代に培ったシステム開発・運用技術が引き継がれず（引き継がれたとしても通用せず），失敗プロジェクトが続出した。システム開発・運用技術とは，開発プロセスの定義，各種ドキュメントの作成，プロジェクト・マネジメントの方法，といったものだ。

　2000年前後に公開されたITベンダーの決算資料を見れば，相次ぐ赤字プロジェクトが収益を圧迫したことが分かる。赤字に陥ったITベンダーの理由の大半は「大型開発案件の失敗」であった。ITベンダーは，そこから数年かけて，C/SシステムやWebシステムを問題なく開発・運用するためのノウハウを積み上げてきた。今，有力ベンダーは開発プロセスや標準ドキュメントを体系化して整備しており，一時期ほど赤字プロジェクトが続出するという状況ではなくなっている（関連記事：「様変わりした開発の現場の悩み」）。

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