少なくともこれまでのところ、クラウドプロジェクトの失敗は十中八九、計画フェーズでの誤りに起因していると断言できる。順調なITプロジェクトは例外なく、費用対効果の最初の見積もりが正確だ。IT部門は決められた予算の中で、投資効果を確実に実現するためのステップを設定し、実行する必要がある。計画フェーズのどのステップでも誤りは発生し得るが、プライベートクラウドの場合、費用対効果の評価フェーズ中に問題が発生する率が最も高い（関連記事：プライベートクラウドの計画段階で注意すべきこと）。

　クラウドプロジェクトには、社内IT機能の運用コストの削減を狙ったプロジェクトと、社内ITでのホスティングが難しいアプリケーションのサポートを目的とするプロジェクトの2種類がある。一般的には、まず、クラウドプロジェクト（通常、3～5年間のプロジェクト）全体のコストが、現在の社内ITコストよりも低いことを証明する必要がある。また、この差額は、CFO（最高財務責任者）が期待する投資収益率（約25～35％）にかなう額でなければならない。

　さらに、業務上の効果（生産性の向上や売り上げ増）が、プライベートクラウドの導入コストに見合うことを証明する必要がある。ただし、これらを証明するために正確なデータを集めようとして、クラウドプロジェクトが失速することが多い。IT部門にとって最大のハードルは、やはりクラウドに掛かるコストだ。

　どのITプロジェクトにも必ず資本コストと運用コストがあり、この2つのコストはハードウェア、システムソフトウェアとミドルウェア、アプリケーションソフトウェア、ユーザーサポートから成る“スタック”全体に分散している。クラウドサービスによって、これらの全てのコストをなくすことは決してできないし（例えば、アプリケーションをクラウドで運用しようと、オンプレミスで運用しようと、ユーザーサポートは必要だ）、クラウドサービスによって解消できるのは、ほとんどの場合、ハードウェアやシステムといった下位層のみだ。クラウドサービスがクラウドスタックに与える影響を理解し、層ごとにクラウドのコストと内部のコストの両方を評価に含めることが重要だ。正確にコストを見積もることができるし、コスト面からプロジェクトの可否を判定するフレームワークにもなる。

プロジェクトへの支持を取り付ける

　クラウドプロジェクトの計画は、CFO以外の承認も必要だ。クラウドリソースを利用する全てのライン部門にも、プロジェクトを支持してもらわなければならない。クラウドプロジェクトの3分の2は、全ビジネス部門から支持を取り付けられなかったときに失敗している。計画フェーズ後で、クラウドプロジェクトが遅れる最大の理由は、ライン部門からの賛同が得られないことだ。

　全ての部門から賛同を得るには、まず運用面の承認を得る必要がある。そのためには、最初の計画フェーズではじき出した費用対効果の予想を含める必要がある。例えば、多くのIT管理者は、クラウドでもデータセンターで運用していたときと全く同じようにアプリケーションを実行できると思っているが、これは誤りだ。

　クラウドとデータセンターではアプリケーションの操作性に差が出る可能性があり、この差はエンドユーザーのストレスにならない程度でなければならない。ほとんどの場合、オンプレミスからクラウドに移行すると、応答時間が長くなるか、体験の品質（QoE）が落ちる。クラウドプロジェクトを頓挫させないためには、目標とするアプリケーションのQoEレベルを設定し、ライン部門に検証してもらおう。

試験運用から本稼働へ：クラウド運用の開始タイミング

　全てのライン部門からの支持を取り付け、各部門が期待するクラウドのパフォーマンスレベルを設定できたら、試験運用から本番運用へと切り替えることができる。この場合も、前のフェーズと同様に、関係各所の承認を受けることが重要だ。

　運用試験は、目標とするプロジェクトの費用対効果を実現するために想定したことが、実際に正しかったことを（少なくとも理屈では）証明するステップだ。これを実質的に証明できるのは、問題のアプリケーションを使用し、それに依存しているビジネス部門からのフィードバックだけだ。しかし、筆者が知っている限り、遅れが出ているクラウドプロジェクトの約半数は、実稼働フェーズに入る前に、全てのユーザーから意見を聞いていなかった。そのために運用上の問題が発生し、クラウドプロジェクトはテストステージと開発ステージに後退する羽目になっている。

　この事態を避けるには、展開計画を立てる際に、決められたコストの中でどのようにして目標が達成されるかを追跡してみることだ。その後、試験運用を行い、各目標が達成されていることを確認する。

　最も難しいのは、クラウドアプリケーションを“実際の規模”でテストすることだ。つまり、予測される運用環境のデータと同じ量のデータを使ってアプリケーションを実行する。このテストでは、負荷生成やテストデータ生成の他、要件フェーズ中に特定されていなければならなかった作業や、試験運用の計画を立てるときには無視できたテスト関連の作業を伴うことが多い。このようにテスト要件の見落としがあると、本番運用が開始されてはじめて、プロジェクトに影響するパフォーマンスの問題が表面化する。それに伴う遅れと問題解決に掛かる費用は、かなりの額になる可能性がある。

　“実際の規模”のテストを実施することで、見落としていたプロジェクトのコストの発見もできる。このような想定外のコストは、もっと前のフェーズで発見できた方がよいが（修正費を抑えられるため）、運用開始後に初めて請求書を受け取って分かるよりはましだ。

　一般に、クラウドを導入する企業は導入プロジェクトを始めるに当たり、クラウドについて社員が持つ知識を過大評価している。プロジェクトを開始する前に、全関係者（IT担当者、ビジネス部門、エンドユーザー）がクラウドについて十分なトレーニングを受けておくようにしたい。また、論理的にプライベートクラウドの導入プロジェクトを進め、全フェーズ（費用対効果の分析、目標設定、運用環境への移行）の詳細なステップを前もって計画し、関係各所の理解と承認を受けるようにしてほしい。