Comments
Description
Transcript
オンデマンド サービス
オンデマンド サービス クラウド サービス カタログおよび セルフサービス ポータルによる IT サービスへの オンデマンド アクセスの実現 VMware ホワイトペーパー オンデマンド サービス 目次 はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 オンデマンド サービスおよびクラウド活用能力モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 従来の IT または高度に仮想化された IT との違い . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 ハイブリッド クラウド方式の価値 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 ビジネスへの影響 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 効率性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 俊敏性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 信頼性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 プロセスの設計および実装 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 手順 1： ニーズおよび準備の評価 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 手順 2： ソリューションの設計およびロードマップの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . 10 手順 3： サービス カタログおよびセルフサービス ポータルの開発およびテスト . . . . . . . . . 12 手順 4： ソリューション全体の起動および展開 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 組織に関する考慮事項 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 クラウド テナント運用部門 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 IT ビジネス管理に関する考慮事項 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 クラウドに対応した IT 財務管理機能の構築 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 KPI によるパフォーマンスの管理および成功の監視 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 テクノロジー / ツールに関する考慮事項 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 サービス カタログ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 セルフ サービス ポータル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 クラウド サービス モデルおよびシーケンス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 主な成功要因 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 ビジネスおよび IT 部門の経営幹部との調整 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 変革におけるユーザーおよび IT 担当者の連携. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 成功の早期実現と可視化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 ビジネス ユーザーおよび IT 部門のトレーニングへの投資 . . . . . . . . . . . . . . . . . . . . . . . . . . 21 次のステップ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 前提条件の確立 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 必要となる変更レベルの判別 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 変更に対応するための組織の準備 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 IT の変革に VMware を使用する理由 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 VMware ホワイト ペーパー / 2 オンデマンド サービス はじめに 今日の IT 部門には、プライベートまたはハイブリッド クラウドを導入し、ビジネス ユーザーに対するサービス プロバイダになることを求めるプレッシャーがますます強くのしかかっています。多くの場合、この変化を後押しす る要因となるのは、企業の IT の外部に出て、外部のクラウド ベンダーから直接 IT サービスを受けるビジネス ユー ザー数が増加していることです。ビジネスに大きな変革をもたらすための方法としてクラウドを評価する IT 企業も あります。経緯はどうあれ、クラウドへの移行を開始した企業は、効率性、俊敏性、および信頼性に関するメリット をすでに実感しています。 VMware には、実装環境でお客様と共同作業した豊富な経験があります。この経験から、効率性、俊敏性、および信 頼性というクラウドのメリットを引き出すために重要な 5 つの機能を特定しました。 • オンデマンド サービス： サービスの標準化と階層型の SLA を実現し、ライフサイクル全体にわたって管理され、 セルフサービス ポータル経由でのエンド ユーザーによるアクセスが可能なサービス カタログ • プロビジョニングおよび導入の自動化： インフラストラクチャ、プラットフォーム、エンド ユーザー向けのコン ピューティング サービスのプロビジョニング、リリース、および展開を自動化 • プロアクティブなインシデントおよび問題管理： イベントの監視とフィルタリング、インシデントの自動解決、 および問題の診断 • クラウドのセキュリティ、コンプライアンス、およびリスク管理： ポリシー対応のアプリケーションおよびセキュ リティ、監査、リスク管理プロセスの自動化を実現するセキュリティ、コンプライアンス、およびリスク管理の ポリシーを標準構成に組み込み • クラウドの IT 財務管理： 自動測定ツールおよび課金ツールを使用した IT コストの透過性、およびサービス単位の 使用率に基づく「ショーバック」または「チャージバック」 このホワイト ペーパーでは、オンデマンド サービス、特に、IT を最前線で支えるクラウド サービス カタログと セルフサービス ポータルのビジネス バリュー、実装方法、および成功に必要な要因について説明します。プロビジョ ニングと導入の自動化、オンデマンド サービスのバックエンド機能の詳細については、2012 年に発行された VMware ホワイト ペーパー『Automated Provisioning and Deployment』（英語）を参照してください。 VMware ホワイト ペーパー / 3 オンデマンド サービス 概要 プライベートまたはハイブリッド クラウドを通じて IT as a service（サービスとしての IT）を提供すると、ビジネス ユーザーは現在のビジネス課題に対応するために必要な、動的に拡張可能なリソースにアクセスできるようになりま す。外部クラウド プロバイダは、使用可能なサービスおよび価格をお客様に提示します。それと同じように、社内 IT 部門は、利用可能なサービス カタログや直感的なセルフサービス ポータルを、クラウド サービスのフロントエンド として作成および提供する必要があります。 IT 部門が効率性、俊敏性、および信頼性を通してビジネスの戦略的目標の実現に貢献し、推進するには、オンデマンド サービスが不可欠です。クラウド コンピューティングを使用すると、企業が IT サービスを利用および提供する方法 を変革することで、これらの需要への対応が可能になります。手動で、時間がかかり、ミスの発生しやすいプロセス や制御方法の代わりに、自動化された、直接アクセス可能なリソースが使用されます。このため、IT のメンテナンス 作業からリソースを解放し、競争力のある差別化を導入および確立する、より戦略的なアクティビティにリソースを 移行できます。つまり、クラウドとは変革することであり、オンデマンド サービスは実現に不可欠な要素です。IT 部門が事後対応型のプロバイダから積極的なサービス ブローカー、最終的にビジネスの戦略的パートナーへと転換す る際に、オンデマンド サービスを使用すると、効率性、俊敏性、および信頼性を高めることができます。 オンデマンド サービスは対話式の手動プロセスから、自動化されたセルフサービス方式のリソース配置に移行するこ とで、効率性を向上させます。俊敏性の向上は、ビジネス ニーズの識別から必須 IT リソースの配信までに生じる遅 延やサイクル時間を短縮することで実現されます。信頼性は、一連のサービスおよびツールの標準化を進め、IT 部門 と企業間のサービスレベル契約を適切に定義および履行することで実現されます。 このホワイト ペーパーでは、オンデマンド サービスを正常に実装するための「方法」を検討します。4 つのステップ からなるロードマップでは、企業が手順に従って実行する必要がある主な決定事項について説明し、対応するオプション やトレードオフの枠組みを作成します。最後に、オンデマンド サービスを実装するためのプロセス、組織、およびツール で必要となる、主な成功要因と変化について説明します。 VMware ホワイト ペーパー / 4 オンデマンド サービス 背景 オンデマンド サービスは、クラウドの主要機能の 1 つとして、サービス カタログとセルフサービス ポータルを統合 します。これによって、ビジネス ユーザーは標準化された一連のサービスおよびオプションにオンデマンドでアクセス できるようになります。サービス カタログでは、ビジネス ユーザーが使用可能な定義済みのサービスおよびオプション がメニュー形式で表示されます。セルフサービス ポータルは、ユーザーがオンデマンド リソースをプロビジョニング して導入できるようになっています。 オンデマンド サービスおよびクラウド活用能力モデル VMware はグローバル企業やサービス プロバイダと仕事をする中で、クラウド コンピューティングを採用した IT 企業と、その能力にはさまざまなパターンがあることを突きとめました。VMware はこの調査に基づいて、クラウド 活用能力モデルを確立しました。このモデルを使用すると、IT 部門はテクノロジーとアーキテクチャ、組織モデル、 運用プロセス、および財務測定の成長や進化に対応したビジネス チャンスを特定できます。このクラウド活用能力 モデルは、IT 部門が既存のシステム、チーム、およびリソースの優れたメリットを活かし、サードパーティのクラウド 資産やプロバイダを採用し、さらにセキュリティ、管理、およびパフォーマンスに関する IT 標準をこの新しい IT モデルに拡張するための方法を提供します。クラウド活用能力モデルを使用することにより、お客様は既存システム を維持するだけでリソースが枯渇する状況から、IT が明確な戦略的ビジネス パートナーとなる環境に移行できます。 さらに、ビジネス目標に合わせて調整された、これらの目標をサポートする新しいサービスおよび機能を使用できる ようになります。 クラウドの他の多くの特長と同様に、オンデマンド サービスにはさまざまなレベルの機能があります。オンデマンド サービスを実装するメリットは、企業が実現を望んでいる機能レベルに応じて異なります（図 1）。 図 1： クラウド活用能力モデル • 標準化： この最も基本的なレベルでは、IT 部門に最小限のサービス カタログまたは複数の異なるカタログの設定 を行います。ビジネス ユーザーはサービス カタログの内容をカスタマイズまたは調整するよう要求することがあ ります。そのため、セルフサービス ポータルの効率性が低下し、サービスを提供するための IT 部門の作業は大幅 に増大します。 • サービス ブローカー： 次の機能レベルでは、企業はビジネスに影響を与えるパブリックおよびプライベート クラ ウド サービスに対応した単一のサービス カタログを確立します。さらに、これらのサービスのサブセットを使用し、 社内の IT 関連のお客様を対象としたセルフサービス ポータルを通して、プロビジョニングや基本的な管理を実行 できます。 VMware ホワイト ペーパー / 5 オンデマンド サービス • 戦略的パートナー： 最高のレベルでは、IT 部門が業務部門にとっての真のパートナーへと移行します。IT 部門お よび業務部門は、サービス カタログの管理責任を共有します。また、ビジネス要件を満たす最適なサービスを判別 する際に、コスト、サービス品質、およびリスクのトレードオフを共同で評価し、ニーズの変化に合わせてカタログ を継続的に更新します。外部クラウド プロバイダからビジネス クリティカル サービスおよび最善のサービスが取 り込まれるように、サービス カタログが拡張されます。また、ビジネス ユーザーに対応するようにセルフサービス 機能が拡張されます。 従来の IT または高度に仮想化された IT との違い オンデマンド サービスは、ほとんどの IT 部門にとって新しいフロントエンドとなります。通常、仮想環境における 仮想マシンの最初の調達プロセスには、物理インフラストラクチャに適用されるのと同じモデルが使用されます。この 方法は有効ですが、サービスを提供する最も効率的なメカニズムではありません。このプロセスを変更しない限り、 クラウドのメリットを最大限に活かすことはできません。図 2 に、この現状から目的の最終状態までの IT フロント エンドの進化を論理的に表します。 図 2： IT フロント エンドの進化 ハイブリッド クラウド方式の価値 ハイブリッド クラウドはパブリックおよびプライベート クラウドの混在環境と相互作用することができます。IT 部 門は社内需要が生じる前に社内キャパシティを構築しなくても、オンデマンドでサービスを提供できるようになりま す。また、この需要に対する IT 部門の理解度が高まるとともに、ビジネス ユーザーは目的のリソースにアクセスし、 組織内では直接使用できないコストのかかるモデルを、頻繁に利用できるようになります。たとえば、パブリック クラウド サービスには通常「使用した分のみを支払う」利用モデルおよび「スポット」利用モデルを使用できますが、 社内の IT リソースに同じレベルの柔軟性を設定することはできません。 可変式の利用モデルを使用すると、革新的ソリューションおよび革新的方式をビジネスに採用する場合の障壁が低く なり、組織の俊敏性が向上します。ビジネス価値を高めるには、新しいプロジェクトのリスクを軽減して、社内 IT の制約が原因で企業が差別化やその他の競争上の利点を失う可能性を小さくします。 IT 部門が長期にわたって需要や最適な利用モデルについて詳細に調査することにより、社内クラウド環境から同様な サービスを提供する計画を立てられるようになります。 VMware ホワイト ペーパー / 6 オンデマンド サービス ビジネスへの影響 効率性 日常的な要求への対応から IT 担当者を解放 現在 IT 担当者は、業務時間の大部分を日常業務に費やしており、サービス要求に関連する手作業を行うこともあり ます。オンデマンド環境では、ビジネス ユーザーが IT 担当者からサービス要求に対する支援を受ける必要はほとんど、 またはまったくありません。サービス カタログには、ユーザーがセルフサービス ポータルを通して選択可能な定義 済みのサービスの説明が示されています。このため、要件の特異性と実現可能性について IT 部門と要求者の間で議 論する必要がなくなります。コンサルティング的な方法が適している場合は、この方法を使用することもできます。 VMware が IT サポート チケットのサンプル データの分析に基づいて行った予測では、要求の 90 ∼ 95 パーセント をセルフサービス アクセスを通してサービス カタログに送信できます。 この方法を使用すると、双方の作業効率が上がります。ユーザーは作業に追われている多忙な IT 担当者の時間を予 約しなくても、自分で制御できます。一方、IT 管理者は各担当者に価値の高いアクティビティを割り当て直すことが できます。当社が観測した結果、完全に開発されたオンデマンド サービスの機能を使用すると、要求対応プロセスに おけるこれらの非効率性が解消され、IT 担当者の作業時間全体の 5 ∼ 10 パーセントを解放することができます。 標準サービス / 構成の採用の増加 利用可能なサービスを事前に定義すると、設計への投資の活用、テクノロジー基準の引き上げ、サポート コストの削 減、サービス デリバリの一貫性の向上、および IT 資産の使用率の改善を実現できます。定義済みサービスを使用す ると、プロビジョニング時間を短縮でき、適切に価格設定されている場合はカスタム構成よりも費用対効果が高くな るため、ユーザーの利用が促進されます。肝心なことは、実現までの時間を短縮し、IT リソースを日常業務から革新 的な作業に転換することです。 俊敏性 ビジネス ニーズへの応答時間の短縮 サービス カタログおよびセルフサービス ポータルに、プロビジョニングおよび導入の自動化を組み合わせると、IT サポート チームはプロビジョニング サイクルから効率的に抜け出すことができます。ビジネス ユーザーは必要に応 じてサービスを利用し、市場の変化に対応する能力を向上させることができます。オンデマンド サービスを拡張する と、プラットフォームのキャパシティやパフォーマンスに関するタスクが効率化されます。IT 担当者が個々の要求に 対応できるようにはなりません。 ビジネス サイクルを使用した柔軟な拡張または縮小 オンデマンド サービスを使用すると、社内専用の IT リソース（プライベート クラウドなど）を含めたり、企業の外 部（ハイブリッド クラウドなど）に拡張して、パブリック クラウド サービス プロバイダが提供するスケーラビリティ や機能を利用したりできます。ハイブリッド方式では、必要なキャパシティを使用して、社内または社外イベントに よるトラフィック急増を管理できます。また IT 設計者は、予測される需要の効果的な処理と、予測外のピークに合 わせたサービス プロバイダのリソース利用を実現するプラットフォームを構築できます。 新しいクラウド サービスによる実験 ハイブリッド方式を使用すると、IT 部門は「構築して機能を実現する」モデルを利用しなくても、オンデマンド サー ビスを実現できます。たとえば、ビジネス ユーザーがパブリック クラウド プロバイダのオンデマンド サービスに アクセスする一方で、IT 部門はプライベート クラウドで同じサービスを提供する場合の需要、アーキテクチャ、 および財務モデルについて評価することが可能です。「使用した分のみを支払う」モデルは外部クラウド サービス プロバイダと共同でテストできます。これにより、IT 部門は同様のサービスを社内で提供する場合に必要な財務管理 システムの実装時間を節約できます。 VMware ホワイト ペーパー / 7 オンデマンド サービス 信頼性 一貫性の高い予測可能なサービス デリバリ 一貫性の高い定義済みサービスを使用すると、IT 部門が予測どおりにサービスを提供できるというビジネス信頼性が 高まります。この一貫性は、サービス定義に対するモジュラー型アプローチによって実現されます。企業は社内また は社外で使用する新しい機能を計画できます。また、プロセスをゼロから開始して仕様を作成するのではなく、標準 化されたサービスの「構成要素」を使用して IT サポート設計を構築することが可能です。それぞれの構成要素は、一 定のコンピューティング能力、メモリ、ストレージ、およびネットワーク帯域幅で構成されています。構成内容を変 更するには、可用性、パフォーマンス、復元性、およびセキュリティのさまざまな構成をサービス レベルに合わせて 組み合わせます。Web サービス、データベース階層、ロード バランシングなどのさらに複雑な機能も、オンデマンド サービスとして定義できます。 ユーザーはシンプルかつ明確に定義された要素に基づいて、さらに一貫性の高い、予測可能な使用環境を実現可能で す。厳密なテスト、評価、カタログおよびポータルの基盤となる加算処理によって、予測可能性がさらに向上します。 セルフサービス ポータルから注文するだけで、信頼性の高い拡張を行うことができます。ユーザーは基盤となるテク ノロジーや、リソースを提供するキャパシティについて心配する必要はありません。この予測可能性があるため、 ビジネス ユーザーはビジネス ニーズに合った最適な SLA を選択して、財務コストを削減し、サービス階層を下げる ことができます。 管理性およびポリシー適用の拡張 IT 部門はカタログおよびポータルを通してリソース導入を管理するためのポリシーを定義し、予算の制約、セキュリ ティ要件、およびリソース機能を取り入れることができます。この管理機能は元の割り当てに適用したり、需要が増 大した場合にリソースのスケーラビリティを管理するために使用したりできます。社内リソースと社外リソースのい ずれを利用するかは関係しません。これらの制限は経営上の判断で行ったり、最小限のパフォーマンス要件や財務面 での最大許容度に関連付けたりすることができます。この制限は、統合リスク管理およびコンプライアンスに基づいて 設定されることがあります。たとえば、社内ポリシーまたは社外規制が原因で、特定のワークロードをプライベート クラウド リソースに制限する場合です。いずれの場合も、提供メカニズムはユーザーからは見えません。制限はシス テムに組み込まれ、一貫した方法で適用されます。 VMware ホワイト ペーパー / 8 オンデマンド サービス プロセスの設計および実装 各組織がオンデマンド サービスを提供するまでの行程は、企業の目標やリソースに合わせて独自に調整する必要があ ります。それと同時に、VMware はさまざまな部門またはビジネス規模にまたがって採用されている一連の共通方式 を識別しました（図 3）。 図 3： オンデマンド サービスの設計および実装方式 手順 1： ニーズおよび準備の評価 この最初の手順では、IT 部門および業務部門の上級管理職から承認を取得し、サービス カタログおよびセルフサー ビス ポータルの要件を収集して、サービスに対する需要の予測や必要なキャパシティとソーシング方式を計画し、実 装するためのビジネス プランを作成します。 IT 部門および業務部門の上級管理職からの承認の取得 管理職の承認を得ることは、オンデマンド サービスを完全に導入するプロセスで最初に行う手順です。IT リソース へのアクセス方式を標準化されたセルフサービス方式に転換するには、ビジネス ユーザーおよび IT 部門からの変更が 必要になります。また、必要な転換を実現するには、考え方や行動の面で管理職のサポートが必要です。イニシアティブ は、関連する経営幹部、および IT 部門と業務部門の双方の代表者が指定した調査チームによる承認および指示を受 ける必要があります。 サービス カタログおよびセルフサービス ポータルの要件の収集 次に、調査チームはニーズおよび準備に関する評価を行なって、サービス カタログおよびセルフサービス ポータル の要件を示す必要があります。聞き取り調査、行動の観察、および広範な調査を通して、エンドユーザーの情報を収 集します。例をいくつか示します。 • ポータルは、さまざまなデバイス、プラットフォーム、およびブラウザとの互換性が必要です。 • ユーザーは複合仮想マシンと似た標準化されたサービス ブロックを使用する「混在」方式を使用して自由度を高め、 コンピューティング、メモリ、およびストレージの組み合わせを独自に設計することを好む場合があります。 • ハイブリッド環境の場合、ワークロードによっては、セキュリティおよび管理要件が原因で、パブリック クラウド リソースをこれらのワークロードに使用できない場合があります。 VMware ホワイト ペーパー / 9 オンデマンド サービス レポートの要件は、組織の財務、コンプライアンス、および監査部門から取得する必要があります。要件には、 Governance, Risk management, and Compliance（GRC）ソフトウェアまたはツールとポータルの相互作用に関 するニーズも含まれます。管理およびポリシー要件は、最初から組み込む必要があります。そうすることで、 「後付け」 によるスケジュールの遅れ、予算コストの増大、および適用漏れを回避できます。 需要の予測およびキャパシティとソーシング方式の計画 主なユーザー グループは需要に対する予測を作成し、オンデマンド サービスがキャパシティ プランニングおよび デリバリ要件に与える影響について理解する必要があります。社内クラウド リソースについて確認する必要がありま す。特に確認が必要なのは、スケーラビリティ、ニーズ、およびパブリック クラウド リソースをベースライン キャ パシティや増大時のキャパシティに使用できるかどうかです。予測およびキャパシティ プランニング プロセスは、 セルフサービス ポータル自体だけでなく、 サービス カタログに含めるリソース タイプごとに適用する必要があります。 実装のためのビジネス プランの作成 ユーザー要件、技術要件、および財務要件が判明している場合は、ビジネス プランを作成し、上級管理者と連携し、 公式な承認を受けて、CIO のロードマップおよび予算計画に組み込む必要があります。 手順 2： ソリューションの設計およびロードマップの作成 サービス カタログおよびセルフサービス ポータルは、要件収集作業およびビジネス プランに基づいて設計する必要が あります。設計には新しいシステムおよびプラットフォームに対するニーズ、およびステージングされた展開プランを 取り入れる必要があります。組織が完全なソリューションを構築する場合は、特定のユーザー グループおよびリソース タイプを優先する必要があります。 オンデマンド サービスを実装する 2 番目の手順は、サービス カタログのサービスの定義、セルフサービス ポータル ユーザー インターフェイスの設計、ツールおよびベンダーの選択、レガシー システムの将来像の設定、およびソリュー ション設計の検査と計画の仕上げなどです。 サービス カタログのサービスの定義 サービス カタログの主な設計要素は、次のとおりです。 • 細分化： サービス カタログには少なくとも、デフォルトのサービス構成で定義された、ユーザー リソースのため のユーザーレベル「コンテナ」を用意する必要があります。このコンテナは、特定のワークロード向けの仮想デー タセンターにさらに分割できます。用意されたコンテナは「パブリック」カタログ内の組織全体で使用できるよう にすることも、特定の部門（または特定のユーザー）にアクセス権を限定することもできます。 • サービスの範囲： 多くの組織が、多様なビジネス要件に対応するために必要なサービスをサービス カタログ内に保 持することと、利用および維持しやすいサービス カタログを保持することの、適切なバランスに苦闘しています。 原則として、カタログの標準サービスはビジネス ユーザーのニーズの 80 % に対応する必要があります。ビジネス 要件の残りの 20 % は標準サービスでは対応されません。その 80 % は既存のカタログ コンポーネントを独自に 組み合わせて対応することが必要です。残りの 20 %（合計要求数の約 4 %）に対応するには、サービス カタログ 以外の、真のカスタム ソリューションが必要になります。 • カタログ サービスに関するオプション： カタログにはサービスごとに複数のオプションを含めることもできます。 一般的なオプションには、サイジング、プロビジョニング メカニズム（たとえば、事前にプロビジョニングされた リソース プールと異なり、ユーザーが呼び出さないかぎり、リソースはプロビジョニングされない）、および事前 構成されたソフトウェア パッケージがあります（プラットフォームとして事前構成されている場合と異なり、イン フラストラクチャ サービスはワークロードに関してスタンドアローンであり、かつ依存しないと表示されることが ある）。 VMware ホワイト ペーパー / 10 オンデマンド サービス • サービス レベル： SLA はサービス カタログ内で定義および実装し、ポータルを通してユーザーに提供する必要が あります。一般的なメトリックには RTO（目標復旧時間）、RPO（目標復旧ポイント）、およびインシデント応答時 間などがあり、サービス カタログ内の各サービスに適用できます。開始時に、これらのサービス レベルに、仮想 化されていない IT リソースのサービス レベルを反映することが可能です。クラウド環境が成熟している場合は、 採用対象を新しい要素（仮想データセンター境界を越えたワークロードの可搬性など）に転換することができます。 SLA は可能なかぎり、社内および社外リソースに共通する方法で定義する必要があります。 • テクノロジー サービス： テクノロジー サービスはエンドユーザーに直接提供されません。ユーザーに提示されて いるカタログ条件が、IT 関連のリソース要件に変換されます。テクノロジー サービスには自動化要件、物理リソー スのセットをユーザー要求に適用する場合に使用する仕様、および特定のユーザーとリソースに適用できるポリ シー要件（セキュリティ、可用性など）があります。サービス定義では、必要に応じてメトリックの関係を適用す る必要もあります（たとえば、コンピューティングまたはストレージのレベルによっては、最小限のメモリが必要）。 • 価格設定： サービスの価格設定は IT 財務管理システムが行い、提供されるサービスのコストを反映します。価格 はベースライン リソース（ストレージ、コンピューティングなど）、ベースライン リソースに関するオプション、 および選択した SLA 階層に関連付けられます。価格設定は、標準サービスの採用を推進するためのきっかけとし て使用する必要があります。1 セルフサービス ポータルのユーザー インターフェイスの設計 ビジネス ユーザーがオンデマンド サービスのメリットを実現するには、従来のサービス要求プロセスではなく、 セルフサービス ポータルを介して要求を送信する必要があります。したがって、セルフサービス ポータルが直感的で、 操作しやすいことが重要になります。フロントエンド ポータルのインターフェイスを開発する場合は、ユーザーによ るサービスの操作方法および登録方法に特に注意を払います。ポータルでは、ビジネス ニーズを IT リソースに明確 に変換できる必要があります。また、ポータルは IT リソースを取得する他の社内方式よりも優れていて、外部クラ ウド プロバイダから直接サービスを取得する方式と同等の必要があります。 オンデマンド サービスのソリューション設計チームは、聞き取り調査、行動観察、および広範な調査を通して、ビジ ネス ユーザーのフィードバックを収集することに多大な投資が必要です。また、セルフサービス ポータルの設計を プロトタイプ化し、何度も繰り返し使用し、継続的に改良して操作性を向上させる必要があります。 ツールおよびベンダーの選択およびレガシー システムの将来像の設定 目的のソリューションを有効化して提供するツールおよびベンダーは、機能、財務とセキュリティ、管理、および コンプライアンスの各要件への対応に基づいて選択します。必要に応じて、標準の購入プロセスおよびベンダー評価 プロセスに従います。また、既存のソリューションを評価して、ニーズに合わせて継続使用が調整されていることを 確認します。 ソリューション設計の検査および計画の仕上げ 準備の評価に基づいて、社内のマーケティングおよびコミュニケーション プランを作成し、すべての関係者に対応し ます。最初に行う手順の 1 つは、設計および実装計画自体を基準に適合させることです。透過性が高まると、方式の 調整レベルが向上し、新しいソリューションの使用方法に関するトレーニング プロセスを開始できるようになります。 実装前の最終手順として、上級管理者から設計およびロードマップの仕上げと承認を受けます。この作業には、元の 予算やスケジュールの調整が含まれます。 1 サービスのコストおよび価格設定に関する考慮事項の詳細については、2012 年に発行された VMware ホワイト ペーパー『IT Financial Management for Cloud』（英語）を参照してください。 VMware ホワイト ペーパー / 11 オンデマンド サービス 手順 3：サービス カタログおよびセルフサービス ポータルの開発およびテスト 自動化エンジンおよびボリューム テストの導入 サービス カタログの定義は完了しています。IT 部門はサービス カタログをセルフサービス ポータルのバックエンド に組み込み、自動化エンジンおよびボリュームとポリシーの管理を導入する必要があります。大量の呼び出しを行っ て自動化エンジンに負荷をかけ、セルフサービス ポータルの使用率が急増した場合も対応できるだけのキャパシティ があることを確認します。 ソリューションのテストおよびフィードバックの取り込み 初期導入時に、企業の機能やアプリケーションを含む、初期のユーザーおよびリソースを使用したユーザー テストを 実行する必要があります。既存の品質保証プロセスが適している場合は、使用できます。ユーザー（および IT）から のフィードバックを、設計および修正後の環境に取り込む必要があります。初期段階のサービス向上に役立つことに 前向きなユーザーを確保できるように、初期ユーザーは自発的な自己申告方式で識別することができます。 品質管理システムおよびメトリック レポートの実装 初期導入のテストが終了したら、継続的な品質管理システムおよびメトリック レポートを使用して、SLA コンプラ イアンスを適切に設定します。SLA コンプライアンスは、オンデマンド サービス プラットフォームを長期間管理す る場合に不可欠です。メトリックには、ユーザーが直接経験するものもあれば（オンライン サービス ポータルの遅延 など）、より詳細なシステム パフォーマンスもあります（拡張性の高いコンピューティング デリバリや仮想コン ピューティング オーケストレーションなど）。品質管理を行うと、直接提供されるサービスが向上し、ベースライン 方式と比較した向上度が継続的に記録されます。この作業と並行して、前述の同じメトリックを従来のサービス要求 プロセス（チケット送信、SLA コンプライアンスなど）に適用し、ソリューション全体の投資対効果を強化します。 手順 4： ソリューション全体の起動および展開 一貫した成功実績の提供 オンデマンド サービスを長期間活用するには、初回起動に成功することが不可欠です。移行するには、異なる方式で IT サービスの要求およびアクセスを行う必要がありますが、最初の印象が後々まで残ります。実装は極めて慎重に行 う必要があります。最初のカタログ サービスは、ユーザーが理解しやすい最もシンプルなものにしてください（CPU、 メモリなど）。最初のユーザー / お客様グループには、IT の直接プロビジョニングに最も満足しているグループを選 択し（社内 IT チーム、開発者チームなど）、予測可能性が最も高いリソース需要を使用します。カタログ全体の「大 がかりな」起動に耐えることができれば、ユーザー全員がソリューションに負荷をかける前に、欠点の解決が可能です。 最初に、従来型の手動 IT プロセスを通して実行されるサービス カタログおよびセルフサービス ポータルを作成し、 この機能が成熟するとともに自動プロビジョニングに次第に移行すると、移行が簡単になる可能性があります。 コンプライアンスの視認性および保証の実現 社内メトリック、標準、および代替手段に対するパフォーマンス測定は、業界ベンチマークと比較して補足する必要 があります。管理およびコンプライアンス要件に合わせて調整できるよう、該当する社内グループ（監査など）には 十分な視認性を提供します。 VMware ホワイト ペーパー / 12 オンデマンド サービス 継続的な改良および改善のための機能の確立 継続的な監視のレポートを行うには、フィードバックを行い、システムを継続的に強化および改善するためのプロセス を確立する必要があります。ビジネス ユーザーや IT マネージャが継続的に関与して確認し、変化する組織要件に合 わせて調整のうえ、オンデマンド サービスのパフォーマンスを測定する必要があります。特定の定量的メトリックを 使用して、セルフサービス ポータルおよびサポート対象サービス カタログを追跡し、パフォーマンス評価のガイド とします。これらのメトリックは複数の最上位グループに分類できます。たとえば、オンデマンド サービスによって プロビジョニングされた IT サービスのシェア、サービス デリバリのソース（パブリック クラウドやプライベート クラウドなど）、リソース定義 SLA（コンピューティング、ストレージなど）、補足 SLA（可用性、プロビジョニン グの改良など）、およびユーザー使用環境などがあります。 VMware ホワイト ペーパー / 13 オンデマンド サービス 組織に関する考慮事項 オンデマンド サービスに移行するには、組織を大幅に変更する必要があります。その前提として、IT の役割をサー ビス プロバイダおよびブローカーへと大きく転換します。最も重要な変更は、クラウド インフラストラクチャ運用 CoE（中核的拠点）およびクラウド テナント運用という 2 つの部門横断的な部署を確立することです。 クラウド インフラストラクチャ運用 CoE（中核的拠点） CoE は、クラウド イニシアチブを正常に推進するために必要なすべての組織リソースのアクティビティを調整します。 CoE ではビジネス分析と技術専門家が協力して、クラウド インフラストラクチャ運用管理の効果を一貫した方法で 測定、説明、および改善します（図 4）。 図 4： クラウド インフラストラクチャ運用 CoE（中核的拠点） クラウド インフラストラクチャ運用 CoE に属するこれらの職務の専門家は、特にオンデマンド サービスを担当し ます。2 サービス ポートフォリオ マネージャ • 許可および拒否の基準を含むクラウド サービス ポートフォリオ ポリシーの作成と維持 • ポートフォリオ全体に追加する必要があるサービスを判別し、IT 戦略に合わせてサービス戦略を調整するために使 用されるクラウド サービス戦略を開発するには、クラウド サービスのポートフォリオを管理し、IT 管理部門と連 携します。 • クラウド ユーザー マネージャや、サービス デスク経由で送られた要求などの他のソースから収集された需要に関 する情報に基づいて、有効なクラウド サービスをプロアクティブに識別します。 サービス カタログ マネージャ • クラウド サービス カタログの管理、およびカタログ内のすべての情報が正確かつ最新であることの確認 • ユーザー セルフサービス カタログ ポータル情報の維持 2 クラウド インフラストラクチャ運用 CoE のメンバーの担当業務の詳細については、2012 年に VMware が発行したホワイト ペーパー 『Organizing for Cloud Operations』（英語）を参照してください。 VMware ホワイト ペーパー / 14 オンデマンド サービス サービス設計者 • クラウド サービス ポートフォリオに特定のクラウド サービスを含めることを決定したあとに、クラウド サービス の所有者が指定した要件に基づいてクラウド サービスを定義します。これには、クラウド ビジネスの要件を、 クラウド サービスの設計に使用できる技術要件に変換する作業が含まれます。 サービス開発者 • クラウド サービスの技術要件を理解するためにクラウド サービス設計者と共同で作業します。 • カスタム アプリケーションまたはサード パーティ製アプリケーションを必要に応じてクラウド サービスに取り込 むために、アプリケーション開発チームと共同で作業します。 • 新しいクラウド サービス コンポーネントを開発して設計に取り入れるか、既存のクラウド サービス コンポーネント から設計図を作成して、自動プロビジョニングを実現します。 • クラウド サービスを製品化してリリースします。 • クラウド サービスの設計に関するドキュメントを作成して、維持します。 • サービス監視を定義するために、クラウド サービス アナリストおよびアプリケーション開発チームと共同で作業 します。 • クラウド サービスにセキュリティ、運用、およびチャージバック測定機能が組み込まれていることを確認するため に、クラウド セキュリティ アナリストおよびアプリケーション開発チームと共同で作業します。 • オンライン ユーザー向けのセルフサービス カタログ機能をカスタマイズして、維持します。 サービス アナリスト • サービス キャパシティの予測を行い、維持します。 • サービスのキャパシティおよびリソース管理を毎日行います。 • 新規または拡張サービス キャパシティに対する要求を行います。 • サービスのパフォーマンス、可用性、使用率、およびその他の運用分析メトリックを監視して、分析します。 サービス管理者 • サービスを管理、開発、および運用するためにクラウド テナント運用部門が使用するツールを管理します。 • お客様のクラウド環境を管理します。 VMware ホワイト ペーパー / 15 オンデマンド サービス クラウド テナント運用部門 オンデマンド サービスは、IT グループを事後対応型の問題解決者から、事前対応型のサービス ブローカーに抜本的 に転換することです。インフラストラクチャおよびアプリケーションにはクラウド（プライベート、ハイブリッド、 およびパブリック）を通してアクセスします。個々に分離した従来型のサービス デリバリとは別物になります。この ように依存性を意図的に排除することによって、相互認識や透過性が損なわれることがあってはなりません。所有者 はサービスレベルに対するニーズおよび影響について理解する必要があります。IT マネージャは、短期間のサービス 管理、および長期間の需要管理とプラットフォーム プランニングに役立てるため、アプリケーション所有者とエンド ユーザーの両方からのユーザー フィードバックを収集します。 この問題に対する革新的アプローチの 1 つは、テナント運用グループを作成することです。このグループは IT 運用 担当者とアプリケーション開発者および所有者の間に配置され、主にサービスを担当します。IT 部門内のすべての グループと連携してサービス レベルを維持し、関係者にプロセスやテクノロジーの微調整が必要であることを示す フィードバックを送信します。 クラウド テナント運用部門は、クラウド サービスの管理、開発、および提供の中心です。サービス管理、サービス 設計と開発、サービス運用、およびプロビジョニングを管理します（図 5）。 図 5： クラウド テナント運用部門 テナント運用部門 / 顧客サポート グループの主な役割は、次のとおりです。 • 社内顧客へのマーケティング • 新しいテナントのトレーニングと採用 • サービス カタログから標準サービスを選択できるようにビジネス ユーザーをサポート • ビジネス部門が予算を作成し、プロジェクトの優先順位を設定する場合のプロジェクト評価のサポートおよび促進 • チャージバックの伝達および課金問題の解決 • 主要インシデントや再発する問題のエスカレーション先として機能 • 新しいサービス要件を含む、サービス カタログを改善するためのフィードバックの取得 • テナントからのサービス需要予測の収集 VMware ホワイト ペーパー / 16 オンデマンド サービス IT ビジネス管理に関する考慮事項 クラウドに対応した IT 財務管理機能の構築 サービス ポータルで提供される価格およびコスト情報は、財務管理システムによって決定されます。サービス カタ ログで使用するリソース（ハードウェアとソフトウェア）は、慎重にリストを作成し、追跡する必要があります。 監視対象には、物理と仮想の両方のレベルで、アクティブな使用中のリソースおよびアイドル状態のリソースを含め ます。IT 財務管理システムで採用される方法には、シンプルな平均コスト方法を使用したり（たとえば、在庫の存続 期間、データ センター間の運用コストの違いは無視）、特定のリソースに基づいて追跡や価格設定を行ったりできます。 ポータルで提供される価格には、さまざまなサービス レベルを反映する必要があります。各サービス カタログのサー ビスの詳細な構成要素リストを使用して、リソースをコストに密接に関連付けると、より高度なサービス レベルの提 供コストがユーザー価格に関連付けられます。ビジネス ユーザーは価格レベルを使用することにより、使用可能な最 高のサービス レベルを常に要求しなくても、自身にとって重要性の高いリソースを判別できます。たとえば、 「99.9 %」 の可用性を実現することは IT 部門にとって負担が大きいため、ビジネス ユーザーのコストの増加につながります。 価格には供給コストを反映する必要がありますが、オンデマンド サービス内で観察された「市場動向」を使用すると、 需要の見積りや予測を行い、IT 部門のキャパシティ プランニングや予算プロセスに取り込むことができます。ハイ ブリッド環境の場合、ほぼ水平的な要求にはパブリック クラウド リソースを通して対応し、次の拡張フェーズで プライベート クラウド リソースに置き換えることができます。 KPI によるパフォーマンスの管理および成功の監視 オンデマンド サービスのパフォーマンスは、具体的な定量的測定を行って測定する必要があります。最初のターゲット はトップダウンで定義できますが、継続的な問題はアクティブ学習方式として定義する必要があります。該当する メトリックには次のものがあります。 • IT 利用のシェア： これらのメトリックは、オンデマンド サービスの初期実装時または展開時に特に重要です。 ビジネス ユーザー コミュニティへの取り込みや、それに対応して発生する IT 部門による提供を追跡します。メト リックの例は、ポータルとその他のチャネル（電話、対面、その他のチケット システムなど）を介して送信される IT 要求の割合や、標準サービスとポータル内のカスタマイズ済みサービス、およびポータル以外のカスタマイズ済 みサービスを介して実行される要求の割合です。 • デリバリのソーシング： サービスのタイプ（インフラストラクチャ、プラットフォームなど）およびサブタイプ （コンピューティング、ストレージなど）ごとに、各チャネルで供給される割合を追跡します。基本的には、社内 プロビジョニング（プライベート クラウド経由など）と社外（パブリック クラウド経由など）に分類します。詳細 なメトリックを使用する場合は、特定のソース（データセンター A、データセンター B、社外プロバイダ A、社外 プロバイダ B など）と、時間経過に伴う変化を設定できます。たとえば、ワークロードによっては、シンプルな コンピューティング リソースやストレージ リソースのみが必要な場合があります。これらは本来、テスト フェーズ および開発フェーズ中に、最低限の共通項となるパブリック クラウドプロバイダを通して提供されていました。 あとで、アプリケーションがお客様環境に導入されたときに、新規のオンライン社内クラウド リソースに同じワー クロードが取り入れられ、セキュリティや管理機能が向上しました。 • コア リソース SLA： カタログを通して提供されるリソース タイプごとに、パフォーマンスのベースライン測定が 行われます。最もシンプルな場合は、ユーザーが 50 GB のストレージを要求したときに、50 GB のストレージが 割り当てられて使用可能になります。これは必ずしも、ストレージ要求があるたびに別の未使用キャパシティ ブロック が使用されるというわけではありません。ユーザー（またはアプリケーション）が追加ストレージを要求すると、 キャパシティはオンデマンドで使用可能になります。このメトリックでの成功がオンデマンド サービスの基盤です。 失敗した場合は、直ちに修正する必要があります。 VMware ホワイト ペーパー / 17 オンデマンド サービス • 補足 SLA： サービス レベル アグリーメントの測定も「要求に応じて計算する」基本的な測定の枠内には収まりま せん。コンピューティング リソースの信頼性や連続稼動時間、ネットワーク リソースの遅延とスループット、 およびストレージ リソースのシーク タイムと持続性を含める必要があります。これらの SLA は価格に密接に関連 付けられています。レベルが高いほど、ビジネス ユーザーのコストは上昇し、提供するための IT コストが反映さ れます。 • ユーザーの使用環境： 目標およびシステムから報告されるメトリックは、ユーザーの主観的な現状認識に基づいて 補足します。このためには、調査と聞き取り調査を組み合わせるか、テナント運用グループと連携します。この調 査を行うと、ポータルのユーザー インターフェイスの向上、最も一般的なユーザー ニーズに合わせたサービスの カスタマイズ（標準化）、ポータルやその他のチャネル経由のプロビジョニング、または社内や社外リソースの選択 をユーザーが行う根拠の把握が可能になります。 VMware ホワイト ペーパー / 18 オンデマンド サービス テクノロジー / ツールに関する考慮事項 サービス カタログおよびサービス ポータルは、オンデマンド サービスの供給管理の中心となります（図 6）。 図 6： クラウド論理コンポーネント モデル サービスのプロビジョニングは、シンプルな製品から開始し、それを構成要素とする複雑な製品に拡大します。最初に、 オプション間でインターフェイスが一貫している、いくつかの標準サイズのサービスの中から選択します。サービス カタログおよびポータルの信頼できる機能、安定した価格、および信用できるデリバリ時間という特長によって、 ビジネス ユーザーは IT を実際に活用できるようになります。 サービス カタログ サービス カタログはビジネス ユーザーが使用可能なすべてのサービス（社内および社外）を、適切な詳細レベルで定 義します。サービス カタログの目的は、お客様が使用できる、明確に定義されたサービス セットを提供することです。 理想的なのは、サービス カタログを「総合窓口」で提供し、必要なサービスを最小限の作業や手動操作で選択できる ようにすることです。カタログを最新の状態に保ち、使用可能なサービスのタイプおよび規模を反映させる必要があ ります。一方、基盤となるテクノロジーの詳細は、デフォルトでカタログに表示されていません。このようにユーザー には不透明な部分があることにより、IT 部門はプライベートおよびパブリック クラウドのリソースから要求に応じ た最善の組み合わせを柔軟に提供できます。ビジネス ユーザーには、シンプルなリソースの選択肢と、適切に定義さ れた SLA が表示されます。多様なサーバ ハードウェア、オペレーティング システム、およびその他のインフラスト ラクチャ コンポーネントを評価および理解しなくても、ビジネス ニーズに基づいて選択が可能です。 VMware ホワイト ペーパー / 19 オンデマンド サービス セルフ サービス ポータル セルフサービス ポータルはビジネス ユーザーがカタログおよび付属サービスにアクセスするための入り口です。ユー ザーはカタログのオプションを確認し、必要に応じて機能や SLA の詳細を掘り下げて表示できます。ユーザーは導 入するサービスをカートに入れて、必要に応じて選択内容を追加または削除します。要求が送信され、適切な管理（ポ リシー、承認など）を経て、自動的にプロビジョニングされます。IT 担当者が手動で操作する必要はありません。ポー タルにはセルフサービスという性質があるため、明確さ、使いやすさ、および予測管理を行うには、ユーザー インター フェイスについて十分に検討する必要があります。 カタログおよびポータルに関する管理は、慎重に設計する必要があります。承認プロセスが不必要にビジネス ユーザー の妨げとなる場合、オンデマンド サービスのメリットは少なくなってしまいます。また、必要な財務管理、セキュリ ティ ポリシー、およびリソース制約を厳密に解釈する必要があります。強力かつ明確なルールがあると、柔軟性およ び境界内の独立性が最大化されると同時に、オンデマンド サービスが範囲外または制御対象外になることがなくなり ます。 クラウド サービス モデルおよびシーケンス オンデマンド サービスを使用すると、ビジネス部門は IT 部門のサービスを簡単に利用できます。たとえば、カタログ の IaaS（サービスとしてのインフラストラクチャ）セクションは、仮想マシンベース サービスを選択して入力し、 指定されたパフォーマンス、可用性、およびセキュリティ特性をそれぞれ含む特定のリソース タイプ（CPU、メモリ、 ストレージなど）を使用して定義することが可能です。仮想マシン サービスのコストは、これらのタイプと属性、 および仮想マシンのユーザー利用に基づいて定義されます。 IaaS（サービスとしてのインフラストラクチャ）は、オンデマンド サービスに適した入門用サービスです。IaaS サー ビスの簡潔性および均一性を使用すると、IT 部門はプライベートとパブリックの両方のクラウド オプションを提供 できます。これは、社外リソースを推奨する場合を含めて、開発需要を追跡し、お客様の好みを理解する場合に最適 な方法です。 インフラストラクチャ サービスが成熟している場合は、パブリックおよびプライベート ソースのプラットフォーム およびソフトウェア サービスを使用して補足できます。基本インフラストラクチャからアプリケーションまでのすべ てのサービスを、包括的なクラウド サービス カタログに統合できます。 VMware ホワイト ペーパー / 20 オンデマンド サービス 主な成功要因 ビジネスおよび IT 部門の経営幹部との調整 オンデマンド サービスの実装を成功させるには、管理職の協力体制が不可欠です。特に、CIO は使用可能なリソース およびチャネルのタイプに関するビジネス リーダーの予測を管理および設定し、オンデマンド サービスの設計およ び提供についてコラボレーションの準備をする必要があります。管理職は最上位の目標に合わせた調整も行う必要が あります。オンデマンド サービスを採用する一般的な目的は、ビジネスに対するコストの透過性を高めること（特に 最低限のリソースの場合）、IT のプロビジョニングの複雑さを緩和すること、リソースをソースに関係なく提供でき るようにすること、および社内 IT コストと社外ベンダー価格を直接比較できるようにすることです。 変革におけるユーザーおよび IT 担当者の連携 オンデマンド サービスはすべてのビジネス ユーザーに関係します。変革するには、設計から実装まで企業全体が関 与し、利害関係者が協力する必要があります。透過性は、特にプランニング時に不可欠です。提案された移行に関す る詳細なロードマップを作成すると、安心レベルが高まり、IT 部門は完全実装前にユーザーからのフィードバックに 対応することができます。 ビジネス ユーザーは IT の利用方法を変革する時期に直面していますが、IT 担当者も重要な変化に対処する可能性が あります。一般には、クラウド コンピューティング（特にオンデマンド サービス）によって効率化されると、IT 部 門はより日常的なタスクに追われたり、担当者のレベルが低下すると見なされることがあります。IT の責任者は、再 配置や再トレーニングを含む予測および移行計画について、担当者と明確に話しあう必要があります。組織は IT 部 門の価値が継続することを示すメッセージを送る必要があります。 成功の早期実現と可視化 オンデマンド サービスへの転換は、IT リソースの提供方法や利用方法を大幅に変革することです。重要な変更と同 様に、ビジネス ユーザーおよび IT プロバイダの最初の使用環境によって、プロジェクト全体の方向性が良くなるこ とも悪くなることもあります。プロジェクトをテスト グループで使用開始することで、企業全体への展開という重要 な局面に入る前に、ユーザーおよび IT 部門の両方が経験を積んで学習できます。テストでは、社内で開発されたポー タルを採用し、これを主に社外で提供されるリソースのフロントエンドに使用することにより、「使用した分のみを 支払う」方式の実践が可能です。インフラストラクチャは、複雑なプラットフォームやソフトウェア サービスと比較 して、よりカタログに統合される可能性の高いサービスです。初期の展開内容は、テクノロジーの理解度に応じて選 択できます。初期サービスを慎重に選択することで、サービスの提供や測定の簡素化が可能です。初期段階でこのよ うな環境を使用することにより、IT 部門の運用成熟度が増し、プログラムの成功記録を確認できるようになります。 ビジネス ユーザーおよび IT 部門のトレーニングへの投資 ビジネス ユーザーおよび IT 担当者は双方向コミュニケーション プロセスの一環として、最初からアクティブに連携 する必要があります。単なる聞き手や調査への回答者にならないようにします。 • ビジネス ユーザー： ビジネス ユーザーは受動的な参加者ではありません。成功するための第一歩は、調査、聞き 取り、および契約グループを組み合わせたユーザー支援活動を行うことです。ただし、そこに留まってはなりません。 ユーザーは提供する必要がある要素や、ビジネス リスクが拡大する要因について、IT 部門に積極的に情報を提供 する必要があります。ビジネス ユーザーは権限委譲を直接求めると同時に、基盤となる複雑なテクノロジーの利用 を中止できます。 VMware ホワイト ペーパー / 21 オンデマンド サービス • ビジネス リーダー： オンデマンド サービスにはビジネス リーダーに対する透過性および管理を向上させる機能が ありますが、提供されるツールおよびメリットの使用方法についてリーダーはトレーニングを受ける必要がありま す。トレーニングを受けた場合のみ、リーダーは提供される管理機能を活用できるようになります。たとえば、財 務またはパフォーマンスの「境界」を利用して、グループまたは個人単位で IT リソースの使用率を制御できます。 ビジネス リーダーはサービス カタログおよびポータルの管理を行い、要求が満たされていることを確認すると同 時に、IT によるこれらのリソースの提供方法に依存しない状況を継続する必要があります。 • IT 担当者： IT グループとして、一般的な（特定の）お客様のニーズを把握し、サービス コストについて詳細に理 解し、代替プロバイダに対してサービスをベンチマークし、社内ユーザーのトレーニングを行います。最も基本的 な部分では、新規ユーザーが追加された場合にサービス カタログの使用を組み込み、パワー ユーザー（開発者や管 理者など）には高度なモジュールを割り当てます。自動プロビジョニングとの完全な連携が実現していない場合、 IT 担当者はユーザーの使用環境と SLA、および手動方式でこれらに対応する方法について理解する必要があり ます。 • IT リーダー： IT リーダーには、サービス カタログに含まれている情報（ユーザー要求、リソースのパフォーマンス など）を社内および社外リソースを管理するためのガイドとして使用し、キャパシティ プランニングを基本的な使 用事例として使用する能力が必要です。また、カタログおよびサービス ポータルの有効な価値を探し、企業へのサー ビス提供を改善し、供給、需要、および提供に関する相互の透過性を高めて、IT リソースの効率性、俊敏性、およ び信頼性を向上させる必要があります。 VMware ホワイト ペーパー / 22 オンデマンド サービス 次のステップ オンデマンド サービスは、組織のクラウド導入に合わせて拡張できます。企業が導入したクラウドが最初は一部のワー クロードのみを対象にしていた場合、サービス カタログをこのサービス セットに限定できます。また、IT 部門は プライベート クラウドを構築しながら、社外クラウド サービスを使用してクラウド サービス カタログを補足するこ とが可能です。 方法に関係なく、組織がオンデマンド サービスの実装を決定した場合は、いくつかの手順を実行する必要があります。 前提条件の確立 オンデマンド サービスを実装する前に、ニーズおよび準備について評価を行い、各機能（クラウドの自動プロビジョ ニングや導入、IT 財務管理など）の現在の能力レベル、および新しいソリューションに対する組織の需要を評価する 必要があります。現在のクラウド ソリューションの規模を、特に既存のプライベート クラウドのキャパシティや、 社外リソースに対して予測されるニーズに関して評価する必要があります。 必要となる変更レベルの判別 設計およびエンジニアリング フェーズは、ビジネスおよび組織のロードマップを使用して並行して進める必要があり ます。テクノロジー以外の変更は、IT 担当者と IT 以外の担当者に対して、詳細に対応する必要があります。最初の テスト配置は、初期のサービス カタログのサービスおよびセルフサービス ポータルのテスト ベッド グループとして 選択および使用します。 変更に対応するための組織の準備 最後に、システムの基本情報（イントラネットの場所、提供するサービスなど） 、および関心や需要を喚起するメリット や利点を伝えるための、社内のメッセージングおよびコミュニケーション プランを設定します。これは、トップダウン （経営幹部からのコミュニケーションや通知など）およびボトムアップ（テスト ユーザー グループからの意見など） の両方が必要です。 VMware ホワイト ペーパー / 23 オンデマンド サービス IT の変革に VMware を使用する理由 クラウドへの移行は、現在多くの企業にとって既定の路線ですが、先行きは明確でないことがあります。自社のイン フラストラクチャの現状はどうでしょうか。先へ進むにはどのようにしたらいいでしょうか。クラウドを実装するた めに適したテクノロジーは何でしょうか。最も重要なのは、目標達成を誰がサポートしてくれるかということです。 VMware は最も大規模で優れたパブリックおよびプライベート クラウドを世界中に構築してきました。現在、 VMware はこの経験を活かして、ユーザーがクラウド コンピューティングのメリットを最大に引き出すために必要 な一連のソフトウェア製品およびサービスを含む、完全なソリューションを販売しています。このソフトウェアと専 門知識は VMware とそのパートナーによるグローバル エコシステムに独自のものであり、あらゆる業界の、あらゆ る規模のお客様に、サービスとトレーニングを通して提供されています。 VMware クラウド ソリューションの詳細については、www.vmware.com/cloud（英語）を参照してください。 ヴイエムウェア株式会社 〒 105-0013 東京都港区浜松町 1-30-5 浜松町スクエア 13F www.vmware.com/jp Copyright © 2012 VMware, Inc. All rights reserved. 本製品は、米国および国際的な著作権法および知的財産法によって保護されています。VMware の製品は、http://www.vmware.com/go/patents のリストに表示 されている 1 つまたは複数の特許の対象です。VMware は、米国およびその他の地域における VMware, Inc. の登録商標または商標です。他のすべての名称ならびに製品についての商標は、それぞれの所有者の商標または 登録商標です。アイテム No.： VMW_12Q3_WP_On-Demand-Services_0812_Version 1.0