そもそも企業のICT利用におけるコストにはどのような要素が含まれているのだろうか？　コストとは、会計的には“利益を獲得するために要した経費”の総体を指す。だが、コストの概念を会計的にのみ捉えていては総体としてのICT利用効率を把握できないため、経済学でいう時間費用、埋没費用、機会費用の総体として把握する必要がある。

　前回の記事「“オレオレクラウド”にはこりごり、クラウドの本質を知る」で解説したように、NISTの定義に基づくクラウド（以下、クラウド）は、これまで埋没費用となりがちだったICT関連投資を、Rapid elasticityとMeasured Serviceの要件を課すことによって時間費用として計測可能にした。また、定量的に観測可能な機会費用の範囲を広げたところにも特徴がある。つまり、NIST定義に基づくクラウド利用は、従来埋没費用化していたコストを“見える化”し、さらに想像の域を越えなかった機会費用をも“見える化”する効果があるといえる。

オンプレミスでのサーバ運用コストを試算する

　では、クラウドではどのような費用が“見える化”されるのか？　まずはオンプレミスでのサーバ運用コストがどのような構成になっているのかを見て行こう。オンプレミスでのサーバのTCOについてはIDCやガートナー ジャパン、ヴイエムウェアなどが算定方法を発表している。ここでは入手しやすいヴイエムウェアの資料（参考：投資対効果を最大化させるVMware のTCO 削減ソリューション）をベースに話を進める。

　ヴイエムウェアが公開している資料に基づいて筆者が単純に積み上げ式の試算をしたところ、2CPUのサーバを5年間運用した場合、1年間当たりのサーバ運用コストは、サーバ償却費1300ドル、保守契約975ドル、電力・冷却費650ドル、データセンター（DC）費718ドル、プロビジョニング人件費671ドル、運用管理人件費3773ドルで、年間合計8087ドルとなった。資料のデータ採録は2007年なので、搭載されているCPUは2GHz程度の4コア製品であったと推定できる。すると、Xeon 1GHz程度の仮想マシン（VM）の換算で8台のVMが切り出せる勘定になる（ここではハイパーバイザーが消費する資源などについては考慮しない）。つまり、甘めに見積もって平均的なオンプレミスサーバでのXeon 1GHz相当のVMに関して1時間当たりのTCOは、0.11ドル程度になる計算だ（図1）。

図1　年間TCO＝8087ドル、単純時間当たりのTCO＝年間TCO／365日／24時間／8VM＝0.115ドル、実質時間当たりのTCO＝単純時間当たりのTCO／稼働率、ピーク負荷全処理時時間当たりのTCO＝0.115ドル／10.5％＝1.09ドル

オンプレミスサーバ運用コストの75％は埋没費用

　上記のオンプレミスサーバでの資産に対し、クラウド業界トップシェアAmazon Web Services（AWS）の米国スタンダード料金におけるXeon 1GHz程度の能力を持つインスタンス利用料は、2006年8月25日のβ版発表時点（参考：Amazon Web Services Blog）で、1時間当たり0.10ドル（2011年9月時点のLinux／UNIX料金は1時間当たり0.085ドル）となっており、時間当たり計算能力に関してオンプレミスとクラウドのコストレンジは当初から同等であったといえる。

　オンプレミスとクラウドは単位能力当たりの費用が同等であるのに、コストダウンは実現できるのか？（※）

（※）AWSを比較に挙げた理由は、ヴイエムウェアの資料に対応する時期のIaaSであることと、Jack of all Cloudの調査「State of the Cloud － January 2011」に基づくトップシェア事業者である点から。

　通常、オンプレミスサーバシステムを構築・運用する際、企業はそのシステム負荷のピークに合わせて設備量を決定する。適応業務や業態によってさまざまに見える負荷分布だが、実はポアソン分布しているので、負荷の大きさ順に並べると負荷強度の分布は冪乗則（べき乗則）に従っていることが分かる。冪乗則は統計モデルの1つであり、地震の震度と発生頻度や金融市場の暴落など、さまざまな現象が冪乗則に従って分布していることが知られている。筆者は、自然な企業活動の繁閑もまた冪乗則に従っており、その企業活動を支えるシステムも当然に企業活動の繁閑に合わせて負荷が変動するので、リアルタイム処理が主流になっていくほどシステムの負荷分布は冪乗則に従う形になっていくと考えている。

　本稿で冪乗則の詳細については解説しないが、筆者は冪乗則に従う負荷分布を持つシステムかつ負荷のピークを処理可能なように容量設計されたシステムの場合、システム処理能力の稼働率は平均10％程度しか活用されていないのが実態だろうと試算した。ちなみに、筆者の試算では1カ月に1回程度の頻度で発生する負荷集中を見捨てる容量設計を行った場合でも25％程度の処理能力しか活用されていない、となった（図2）。

図2　

　要するに、オンプレミスサーバでのXeon 1GHz相当のVMに関して1時間当たりの稼働率を加味したTCOは甘く見積もっても0.45ドル程度となってしまい、オンプレミスサーバ運用コストの75％は埋没費用化しているという結論が導き出せるのだ。

　もちろん、くどいようだが平均稼働率向上のために需要分散などさまざまなテクニックを活用している高度なシステム（＝サービス系）の例は除外して考えるが、筆者の経験上からもさほど実態と乖離した試算値ではないと考えている。なお、筆者としては将来的には稼働率分布データのメトリックス整備がなされ自社のシステムパフォーマンスが業界のどの程度の位置にあるのかを企業が客観的に把握できるようになるべきと考えている。

消えない俗説「クラウド利用は高くつく」の本質

　話を元に戻すと、オンプレミスシステムに対して、Rapid elasticityとMeasured Serviceの2要件によってキャパシティープランニングからの解放を実現したクラウドの利点は、機会費用と埋没費用のトレードオフから（完全ではないにしろ）企業を解放する点だといえる。ところが、いまだに「クラウド利用は高くつく」、という俗説がなくならない。なぜか？

　前回の記事で指摘したような“オレオレクラウド”に引っ掛かってしまったというケースはご愁傷様としか言いようがない。だが、NISTの定義に基づくクラウドを利用した場合でも、先に述べた通り現行運用しているオンプレミスシステムの時間当たりのTCOを上回る利用単価のサービスを契約すれば、従来より費用は高くなる。また、負荷に合わせてシステム規模を柔軟に変更できる、つまりスケールアウト性の高いシステムデザインを施さなければクラウドが装備するRapid elasticityとMeasured Serviceの2機能による計算資源などの動的割り当て・解除のメリットは享受できない。

　また、スケールアウト性を確保するためのオーバーヘッドが、これまで見逃していた機会を新たに獲得することによってもたらされる利潤を上回ってしまうような小規模なシステムの場合も同様だ。

　もちろん、従前運用していたオンプレミスシステムの償却が終わる前にクラウドでシステムの並行運用を始めればクラウド分のコストは追加費用になるし、商用ライセンスソフトウェアを利用している場合、オンプレミスシステムで運用していたソフトウェア資産を無償でクラウドに移行できるとは限らない（追加費用が必要なケースがある）。他にもさまざまな要件を考慮し、現状把握をしっかり行いながら、適切なサービス選定を行わなければ効果的なクラウド移行が実現できず、「クラウド利用は高くつく」と嘆息することになりかねない。

　スケールアウト性の高いデザインでコストパフォーマンスの高いクラウド利用を実現するには、現状把握が重要となる。移行先クラウドが自社のあらゆるニーズに応えてくれるならさほど神経質になる必要もないだろうが、各種業法などの制約がある業種もある。まずは、EA（Enterprise Architecture）などの手法を利用してクラウド移行可能な範囲の割り出しなどを行う必要があるだろう。さらに、スケールアウト性の高いシステムデザインを行うためには、SOA（Service Oriented Architecture）の考え方に基づくモジュール分割などを行うことになり、さらに各モジュールのスケールアウト配置を実装していく手順になるだろう。これら一連の設計手順を踏むに当たって筆者は、データモデルとそのガバナンスを軸に据えると見落としが少なくなると考えている。ともあれ、今回のスコープはコストとガバナンスなので実装系の詳細についての記述は別の機会に譲ることにしたい。

クラウドガバナンスとは

　さて、ここまで来てようやくシリーズタイトルのガバナンスについて紹介（実はここからがまだ長いのだが）できる準備ができた。クラウドはRapid elasticityとMeasured Serviceの2要件によって、機会費用と埋没費用のトレードオフから企業を解放してくれそうだが、どうも実用上考慮しておかなければならない要素が多々ありそうだ。どこに地雷が埋まっているか分からないのではリスクが高くてクラウド利用に踏み切れない、という懸念は筆者も十分理解できる。こういった懸念を払拭するためにクラウドガバナンスは存在する、と言ってもいいだろう。

　クラウドガバナンスの実体はITガバナンスであり、ITガバナンスの基礎はコーポレートガバナンスにある。では、いわゆるコーポレートガバナンスとはいかなるものなのか？　もともとは1960年代の米国で企業倫理などの文脈で利用されるようになった用語が転じ、企業不祥事を防止するための方法論といった意味が付加された。1990年代以降、先進各国の注目を受けて、1999年に経済協力開発機構（OECD）がコーポレートガバナンスの原則を制定したという経緯がある。「OECD コーポレート・ガバナンス原則」（2004年改訂版が執筆時点で最新）では、株主の権利の保護、全ての株主の公正な取り扱い、利害関係者の権利の認識と、コーポレートガバナンスへの参加、情報開示と透明性の確保、取締役会の責任が定義されている。米国のSOX法制定や日本の会社法、金融商品取引法の制定、IFRS導入の流れなど、ICT関連業界でもなじみ深い一連のキーワードの根源にコーポレートガバナンスの強化という底流があるので、個々の問題を切り離さず全体として見通す視点で臨みたい。

　このコーポレートガバナンス実現、強化を図るに当たって、ICT側面にスコープしたものがITガバナンスということができる。ITガバナンスの国際標準としては既に「ISO/IEC 38500:2008」が発行されていて、

• Responsibility＝責任
• Strategy＝戦略
• Acquisition＝調達
• Performance＝パフォーマンス
• Conformance＝適合
• Human Behavior＝人間的行動

という6つの原則について、Evaluate（評価）、Direct（指示）、Monitor（観測）を行うことを要求している。ただし、ISO/IEC 38500:2008は原則を示すにとどまり、実務上要求される詳細な管理基準は明示していない。そこで、ISO/IEC 38500:2008の策定メンバーとしても参加しISACAの発行しているCOBIT、Risk IT、Val IT（これらはCOBIT5として統合される予定）といったフォーラムスタンダードを利用するか、ISO 9000s（QMS）、ISO/IEC 20000s（ITSMS）、ISO/IEC 27000s（ISMS）、BS25999（BCMS）といったデジュールスタンダード（BS25999のみ英国規格）を利用して明確化を図る必要がある。これらの規格の関係は前段のISO/IEC 38500が要求、後段の諸規格が要求分析と基本設計に当たると考えると分かりやすい。

　実は後段の諸規格はパラメータが与えられていないので詳細設計とまではいえない。適切なパラメータは時代によって変化するが故だろうと筆者は理解している。ちなみにクレジットカード不正使用などによる被害防止や被害発生時の補償範囲の基準を定めることにスコープしているフォーラムスタンダードであるPCI DSSは詳細なパラメータを定めているので使い勝手が良い。次回以降、デジュールスタンダードを中心にPCI DSSなどを絡めて説明する。

　さて、先に述べたようにクラウドもまたICTを利用したシステムであるので、そのガバナンスを実現するには上述した各種ITガバナンス標準に従うことになる。これらの諸標準が取り扱う範囲は相当に幅広いため、手っ取り早く当面の中心的課題であるオンプレミスからクラウドへの移行に当たって事業者選定の指針と目的を限定するなら、CSA（Cloud Security Alliance）が公開している「Security Guidance for Critical Areas of Focus in Cloud Computing v2.1」（執筆時点でv3が公開レビュー中）を利用するのもよいだろう。ただし、事業者選定した後、選定したクラウド上で自身のシステムを構築するに当たって利用者自身もITガバナンスを実現しなければならないのだから、ITガバナンスの諸標準について学んでおいて損はないと考える。

　付け加えておくと、先ごろNISTが新たに発表した「NIST Cloud Computing Reference Architecture」や同「Standards Roadmap」が指摘するように、クラウド利用の一般化によって普及が想定されるユースケースは従来の企業によるICT利用と比較して、格段に“開かれた”ものとなることが予想される。“開かれ”、相互に接続された将来のクラウド利用における留意点を洗い出すためにはユースケースの定義が不可欠だ。このユースケースの整理、分類などは現在もTM ForumやDMTFなどで活発に行われているので今後の動向に注目しつつ解説していきたい。

川田大輔（かわだ だいすけ）

Cloud Architect、クラウド設計屋。18年に渡り大手ソフトウェア／ハードウェアメーカーでのマーケティング、ITベンチャーでの事業開発、技術開発、技術投資業務を経験し、2009年より現職。技術からマーケティングまで包括したICT関連事業の立ち上げを専門にしている。近作はNIST準拠のOSS Cloud Architecture、copse。

本稿での記述内容は個人の見解であり、その責任は全て筆者個人に帰するもので、所属する組織を代表する意見ではありません。