クラウドコンピューティングという言葉は人によってやや解釈が異なる。プライベートクラウドの構築に着手する前に、クラウドコンピューティングに対する自社の目標を現実的に把握する必要がある。

　多くの企業は、データセンター統合やコスト削減など、仮想化による目標を実現した後、物理ハードウェアとの対比でプライベートクラウドインフラを目指す。また、自社のITプロセスの一環として標準化や自動化を利用し、仮想化を次のレベルへと進めようと考える企業もある。

　だが、組織的な変更に取り組み、困難な「人的問題」に対処する準備が整っている企業はほとんどない。人的問題とは、従来のIT部門が抱えるサイロ化、サービスの重複、セキュリティ、管理などを指す。通常、こうした問題は技術的なものではない。どちらかといえば、組織の境界や長期戦略の領域に関係する。

　また、クラウドという言葉についても幾つか考え方の違いが続いている。共通するのは、プライベートクラウドが完全に仮想化に基づいていることだ。ただ、通常、仮想化がプライベートクラウド導入に大きな役割を果たすとしても、プライベートクラウドには重複する多くのサービスを置き換える共有インフラの意味もある。

　プライベートクラウドを構築する土台となる技術基盤に取り組む前に、自社の目標を技術面からも、組織的な面からも慎重に定義する。

2. 構築の過程に現実的な想定をする

　繰り返しになるが、ITチームがプロセスを解体して作り直し、日常業務の自動化や標準化を進めるにつれて、クラウドの構築過程に想定される技術的課題は減少していくが、人的課題は増えていく。

　強引でユーザーのニーズに対応しようとしないIT部門は、自社自体や自社の仕事を見直すには適していない。同様に、仕事の多いIT部門は、技術的なメリットを有していても、クラウドサービスを調査する時間が足りない可能性がある。クラウドコンピューティングに重点を置くことにより生じる他の仕事の遅れについての苦情に直面する場合は、管理部門がIT部門の仕事に適切な優先順位を付け、IT部門をバックアップすることが重要になる。

　最後に、人事部門などの管理部門が全てのレベルでクラウドへの移行をサポートする必要がある。IT部門自体の再編に伴い、企業の全ての側面で遅れが見られるだけでなく、自動化の対象となるタスクに関係する職務を主な仕事にする作業者が自身の価値低下を恐れ、プロセスを不確定にすることがある。人的問題の計画を立て、プロセスの最初から貴重な従業員とのコミュニケーションを取る。こうした努力は、より関心がある生産性の高い作業へと従業員を向かわせることを目標に行う。

3. 企業のワークロードとサービスを把握する

　自社が利用するサービスを把握しなければ、プライベートクラウドの構築は難しい。そこで重要になるのがドキュメントだ。ドキュメントがなければ、システム同士の関係を解いたり、サービスレベルアグリーメントを追跡するのは難しくなる。こうした状況は全て、チームを誤った前提に導く。また、ユーザーのニーズに合った新しいプライベートクラウドサービスを確実に構築するためにも、そうしたニーズをドキュメントにすることが重要になる。重複するサービスを一元化する場合は特にこうしたドキュメントが必要だ。

　ドキュメントは標準化にもつながる。ニーズや設計要件を全て考慮していない標準は即座に例外事項が生じるためだ。共有インフラとクラウドベースのアプリケーションに向けて移行中は、パフォーマンスの情報も重要になる。1年以上にわたって追跡したパフォーマンスの履歴データは、収集単位が細かくなるほど、容量のニーズやシステムの規模を判断するのに役立つ。

4. 仮想化に向かう

　プライベートクラウドは仮想化に基づく必要はない。だが、仮想化は共通モデルになる。一般に、仮想化は企業内の特定の知識や行動の原動力になる。そして、そうした知識や行動自体がプライベートクラウドに役立つ。例えば、ほとんどの仮想化ソフトウェアは一元管理型のストレージを必要とする。そうした一元管理型のストレージは、プライベートクラウドインフラのビルディングブロックになる。

　同様に、仮想化は通常データセンターネットワークに大きな影響を与える。少なくとも、トラフィックパターンを静的なものから動的なものに変える。クラウドベースの共有コンピューティングに向かうことでこの傾向が引き継がれ、ネットワークへの依存度が高まる。その結果、必要な帯域幅が広がる。仮想化の結果として仮想化、ストレージ、ネットワークの各管理者の間で始まった会話は、クラウドに進化するにつれて重要になる。リモートオフィスやモバイルユーザーへのサービスの提供を計画している場合は特に当てはまる。

5. 標準化と自動化を両立させる

　多くの企業では、自動化がプライベートクラウド構築の主なきっかけの1つになる。ただし、標準化していなければ自動化は極めて困難だ。例えば、OSやサーバのビルドを標準化すれば、ファイルの場所、ファイルシステムの規模、認証メカニズムについて想定できる。こうした想定を基に、Webサーバ、アプリケーションサーバ、ファイアウォールの規則など、アプリケーションソフトウェアやミドルウェアをインストールするスクリプトを作成できる。

　標準化を実践したことがなければ、その実現は難しくなる可能性がある。だが、時間の節約は膨大なものになる。

　OS、OSのバージョン、ビルドプロセスの標準化を行っていない企業について考えてみる。各サーバは異なっていて、全ての操作に特別な注意が必要になる。ソフトウェアのインストールやパッチの適用はそれぞれタイミングが異なる。各ホストに違いがあるため、成功率は安定しない。こうした状況は、通常2つの結果につながる。まず、従業員が日常の仕事をこなすのに多くの時間を費やすことになる。そのため、こうした仕事の多くが省略される。例えばセキュリティの脆弱（ぜいじゃく）性に対するパッチの適用などは、適用が難しく、いつリリースされるか予測できないため、省かれる可能性がある。OSを1つか2つに標準化し、ビルドプロセスやアプリケーション導入プロセスを自動化すれば、IT部門の生産性は大幅に向上する。

　環境の多くを自動化した後は、セルフサービスポータルやサービスカタログを提供できる。100％セルフサービス型にできるとは考えられない。だが、ワークフローのあるプロセスの多くは自動化できる。プロセスとの対話が必要になるのは、承認プロセスだけだ。自動化すれば、IT部門は、最善のサポート方法やアプリケーション／サービスの監視など、もっと重要な問題に専念できるようになる。自動化により、アプリケーションの管理者や開発者には、ビルドの基盤となる、一貫性があり反復可能なプラットフォームも提供される。つまり、IT運用スタッフは、有益で反復可能な手続きを作成して、インシデントを処理し、システムの警告を監視できる。各サーバが1回限りの例外になることはなくなる。こうした自動化は、警告への自動応答につながるかもしれない。

先に進める

　本稿で取り上げたステップは、プライベートクラウドインフラ構築の始まりにすぎない。このプロセスを続けるには、IT部門はチャージバックやショーバックなどの手続きを導入することも必要になる。こうした手続きでは、業務部門が準備し利用するITリソースについて業務部門が責任を持つようにする。また、プライベートクラウドを慎重に監視し、エンドユーザーやCIOが新たな方向性に満足していること確認することも重要だ。