こんにちは、シトリックス ・ システムズ ・ ジャパン の内林です。
私が所属する部署はコンサルティングサービス部といい、私もコンサルタントという肩書でお客様先にお伺いしています。

お客様のデスクトップ仮想化プロジェクトに参加し、マスタースケジュールを確認させていただく際に、お客様のマインドは環境構築に向いているのですが、要件定義や、業務の移行に関するタスクには目が向けられていないことがよくあります。

デスクトップ仮想化 のゴールは、単純にユーザーのデスクトップが仮想環境で稼働していることではなく、その上で業務を滞りなく遂行できるようにすることだと考えています。そういう意味では最終的なシステムの成功・失敗はユーザー業務の実現性で計るのがベストだと思っています。

今回ですが、そういう経験を踏まえまして、デスクトップ仮想化の試験に対する考え方を一般的なV字モデルに当てはめ見直してみたいと思います。

  • 一般的なV字モデル

V字モデルはデスクトップ仮想化という観点ではなく一般的なITプロジェクトでも広く用いられていると思いますが、デスクトップ仮想化に割り当てたときの流れと位置づけは以下のようになります。

1. 単体試験

コンポーネント単体での動作確認という位置づけです。デスクトップ仮想化にはいろんなコンポーネントから成り立っていますので、それを個別に機能確認していくステージです。

詳細設計書や設定値のパラメーターシートを元にテストケースを抽出していきます。

2. 結合試験

ネットワークやストレージなど各コンポーネント間連携・システム間連携などを確認するステージです。ユーザーからみたログインの流れなどシステムとしての正常性を確認していくための試験を行います。

基本設計書からテストケースを抽出していきます。

3.システムテスト

システムテストのテストケースは要件定義から洗い出し、ユーザーの業務が実現できているかを確認するのがゴールです。

要件定義書は、上流の分析(アセスメント)フェーズで作成されます。このフェーズでは新環境で新たに実現したい項目や現在のシステム・ビジネス課題をお聞きし、現在の 業務・環境を分析し、全体的な方向性を決めます。特に業務ユースケースが洗い出されているのが望ましいです。

例として、 「お客様先にリモート端末を持参してビデオを見せる」、「定型用紙に帳票印刷する」という形で、各業務が「○○する」という表現でリストアップされていると、「新環境でもリモート端末でお客様に伺った後、すぐにデモビデオを見せることができる」、「帳票印刷してきちんと枠内に印刷できる」という試験につなげられます。こういったヒアリングや取りまとめを行うのはとても重要なことだと考えます。

逆にいうと、業務主体の試験がないまま、ユーザーに引き渡してしまうと、ユーザーの不満・クレームにつながってしまい、システム提供側・利用者側双方にとって好ましくない結果となります。それを防ぐためには、要件定義の段階でなるべくユーザー側に対しても詳しくヒアリングを行い、このシステムテストのフェーズでユーザー側も納得のできる業務確認ができるのがベストだと考えます。

  • まとめ

デスクトップ仮想化のプロジェクトは、バックグラウンドの基盤構築に視点がおかれがちですが、必ずユーザーの業務のやり方が変わる側面を持ち、そこに強く注意を向ける必要があります。そのため、プロジェクトの成否はユーザー業務向けのシステムテストが大きなウェイトをしめます。

そのシステムテストのテストケースは要件定義および現状分析から抽出されますので、要件定義および現状分析が他の分野のプロジェクトにもまして重要です。「要件定義」や「現状分析」を重要なタスク、必要なスケジュールと位置づけできるかでプロジェクトの成否は大きく変わってくると考えます。


実際の要件定義や現状分析はどうやるのかといった相談を受けることもあります。大きなテーマなので、なかなかこういった場でご紹介するのは難しいですが、シトリックスでは具体的な要件定義・分析から設計シミュレーションを行うようなトレーニングを行っています。

CCE-Vという最上位資格の準備コースにもなっており、資格の取得を目指す方にもおすすめできる内容です。
興味がございましたら、こちらもご検討ください。

シトリックス ・ システムズ ・ ジャパン株式会社
コンサルタント 内林卓