こんにちは。Citrixコンサルタントの田中です。

旧来のオンプレミスCitrix Virtual Apps and Desktops環境、またはCitrix Workspaceを導入する現場では、計画段階からカットオーバーまでの長い道程の中で、成功を阻む様々な障壁があります。そこで、プロジェクトの各段階での失敗例や陥りやすい罠を、具体的な事例を元にシリーズで解説します。

※本記事は、過去に弊社ホームページに掲載されていた記事を元に、加筆・修正したものです。

Citrix Virtual Apps and Desktops環境
Citrix Workspace環境

Citrix環境導入の理想と現実

データセンター内にDelivery ControllerなどのCitrix Virtual Apps and Desktops管理コンポーネントを構築し、ユーザー数分の仮想PCを用意して、VDA(Virtual Desktop Agent)をインストールすれば、即、仮想デスクトップ環境を実現できるのでしょうか。またはCitrix Workspaceの場合、管理コンポーネントの構築に関わる負担は大部分が軽減されますが、サブスクリプションを契約して、クライアントアプリケーションであるCitrix Workspace appをクライアント端末にインストールすれば、即、Citrix Workspaceの導入を実現できるのでしょうか。答えはノーです。Citrix環境に対するニーズは、組織の上層部、利用するユーザーおよびセキュリティ部門など、部門により異なります。それを無視してIT部門などの特定部門だけで環境構築をしようとすると、必ずと言って良いほど失敗します。どのような環境がユーザーから必要とされているか、現状の問題点は何か、Citrix環境を導入する上で組織が何を期待しているか、また何がリスクとなり得るか、それらを見極め、適切にデザインすることが何よりも重要です。

第一回：陥りがちな失敗パターン「”計画”の現実」

 無計画に構築したCitrix環境は、多くの場合、当初の理想とは遠く離れたものになってしまいます。何が原因でそのような結果になってしまうのか、そもそもなぜ無計画にスタートしてしまうのか、具体例を挙げて説明します。

ケース１「短い期限」

状況

Citrix環境の全社導入することを決めたものの具体的に何をしたら良いかわからない。従って、タスクボリュームが予測出来ない。さらに現在の使用状況を把握できていない。その状態でいつまでに実現するかを決めざるを得ない。この場合、必ずと言っていいほど実際に必要とされるよりも短い期限が提示されます。

結果

ユーザーが現在どのようにPCやモバイルデバイスを使用していて、どのようなニーズがあるか把握していないため、組織にとって本当に望ましいCitrix環境の実現方式が決められません。Citrix環境を導入した経験やノウハウも無いため、導入により顕在化する問題を推測できません。期間が短いため、順序立てて方式の検討を行うこともできません。

組織にとって最適な構成を見極めることができないため、全てのユーザーニーズを満たし得るが、オーバースペック且つオーバーコストな構成（図Aを参照。ユーザーカバー率のみを重視すると、一人あたりの導入コストは上がります。）か、または、全てのユーザーニーズを満たすことができない中途半端な構成を採用してしまいます。（図Bを参照。導入コストのみに注視した場合、ユーザーカバー率は犠牲になり、不満足なユーザーに我慢を強いることになります。）

図A 図B

ケース２「まずハードウェア構成」

状況

この事例は、特に仮想デスクトップ/仮想アプリケーション環境の導入に当てはまります。ハードウェア構成は物販コストの算出、予算取りおよび調達スケジュールに直結するため、比較的早めに検討されます。この場合、精緻なサイジングは行われず、ユーザー数などから機械的に算出した数値に頼らざるを得ません。

また、ハードウェア構成決定の際、ベンダーからサイジング情報が提供され、全体の構成が描かれますが、ハードウェアの最新機能に過度の期待がかけられてしまうことが多くあります。ベンダーから提供されるサイジング情報は特定のテクノロジーを前提とした過去の事例にもとづいていることも多いです。仮想デスクトップ/仮想アプリケーション環境に対する要件は各社様々であるためそのまま鵜呑みにすることはできません。

なお、Citrix Workspaceの場合、リソースロケーション以外の管理コンポーネントはハードウェア構成に依存せずに導入可能ですが、リソースロケーションに対するオーバースペックな構成がコストに直結することに変わりはなく、計画を精緻化するに越したことはありません。

結果

かけたコストに反して、本当にユーザーニーズに合う構成とはかけ離れたサイジング前提となってしまいます。それにより予算超過した場合は、後から要件が発覚し、より付加価値のあるテクノロジーを採用するにしてもリソースの確保が困難になります。

ケース3「根拠なきプロジェクト予算」

状況

ユーザーのニーズや利用状況を把握できておらず、ゴールが不明確なまま全体の予算だけが先に決まってしまうケースです。ライセンスやインフラストラクチャーを先に決めてしまって、それらの機器の総台数からインストール費用を算出した場合などが当てはまります。

Citrix環境の導入では、導入するユーザーの対象範囲が広ければ広いほど、当初は予想もしなかったユーザー要件が噴出します。後から判明するユーザー要件は小手先で対応できないことも多いです。

結果

カバーし切れなかったユーザー要件に対し、後手に回り対応しなければならず、これは少なからずプロジェクトスケジュールに影響します。最悪の場合、導入対象範囲の縮小やカットオーバーの延期が必要になります。今回導入を見送った対象については、再度予算を確保し、プロジェクトを発足し、設計・サイジング・導入・構築・テストなど一連の作業を再度実施する必要があります。また、何とか想定内のコスト・スケジュール内で収めたとしても、無理にカットオーバーしてしまうとユーザーが不満を抱えたまま使用することになります。

ケース4「PoC（Proof of Concept）の実施なき導入」

状況

Citrix環境の導入にあたって、プロジェクトの期間、予算やスケジュールが既に決められた状態でプロジェクトが始まってしまい、本来実施することが推奨されるProof of Concept（PoC、概念実証）が計画に入っておらず未実施のまま、設計がスタートしてしまうことがよくあります。

PoCを実施することで、計画段階の構想が自社の環境で本当に実現することが可能なのかどうか、技術・ユーザー利便性、セキュリティなどの観点で検証することで、プロジェクトの後工程におけるリスクを減少させる事が可能になります。特にクラウド環境を利用する上ではオンプレミス環境よりも不確定要素が多く、実施が不可欠と言っても過言ではありません。例えば、Citrix WorkspaceでリソースロケーションもAzureなどのIaaSを利用する場合、大掛かりな設計工程を経ずにPoCを繰り返し、最終構成に落とし込むようなアプローチも可能であり、このような場合PoCはより重要な意味を持ちます。

結果

PoCを実施することなくプロジェクトを進めた結果、後になってユーザー部門や上層部から新たな要件を求められたり、反発を受けたりします。プロジェクトの後期における仕様変更は莫大な労力と予算が必要になり、結果としてプロジェクト自体が頓挫してしまうような状況に陥ってしまう場合があります。

いかがでしたでしょうか。ここに挙げている事例は、様々な失敗事例のほんの一握りに過ぎませんが、プロジェクト成功のために、ほんの少しでもお役に立てれれば幸いです。

Citrixコンサルティングサービスでは、計画段階での支援や、具体的なPoC環境の設計・構築作業を支援させて頂くことが可能です。詳しくは、コンサルティングサービス部までご相談ください。

次回は、計画段階でのベストプラクティスをご紹介します。