つまづくポイントはここにあった、デスクトップ仮想化「方式別」に見る導入運用のポイント：IT導入完全ガイド（2/4 ページ）

[土肥正弘，ドキュメント工房]

ここで失敗する、SBC方式の落とし穴

　まず大きいのがユーザーの自由度が制約されること。自分でアプリケーションが導入できないことや機能拡張制限で不満が出ることがある。これにはユーザーにセキュリティ面での改善効果やTCO上のメリットを理解してもらう施策が必要になるだろう。

　最も怖いのが、運用を始めてから重要なアプリケーションの非互換や外部デバイスへの非対応が発見されることだ。一般的なオフィス用パッケージならほぼ問題ないが、特定業務用のアプリケーション（パッケージでも自社開発ソフトでも）ではサーバOSやマルチセッションに対応しない場合がある。

　現在はかつてほど非互換の問題は少ないようだが、例えばIPアドレスやホスト名でクライアントを識別するようなアプリケーションでは問題が起きる。導入前にアプリケーションの棚卸をし、使用する外部デバイスが正常に動作するか否かの確認も行う必要がある。可能な限り、事前に実機での検証を綿密に実施することが勧められる。

　これには相応の時間とコストがかかり、システムコストと構築期間に上積みされることは理解しておくべきだ。実際にこれがネックになり、SBC方式を断念、仮想PC方式を導入した事例もある。ただしアセスメント時点でPCに導入したエージェントモジュールからCPU、メモリ、アプリケーション情報を取得してレポートを作成、移行先のRFPに反映させるツールやサービスもあるので、一定のコストや期間の削減は可能だ。

　なお、ネットワーク接続が前提になることもモバイル利用では重大なデメリットになることがある。またスマートデバイスでは画面サイズの問題からデスクトップ画面そのままでは利用しにくいこともよく指摘される。ただし、仮想化ツール側の機能でデバイスごとにプレゼンテーションを変えることも一部可能だ。またデスクトップ配信とアプリケーション配信を併用するなどの工夫で解決することもできるだろう。

　また、大規模運用では複数サーバで負荷分散を行うのが普通なので、ユーザーは毎回別のサーバに接続することになる。そこで「移動ユーザープロファイル」を利用して、ユーザーが加えた（例えば壁紙などの）変更が引き継がれるようにしておく必要がある。

　ただし、キャッシュもその中に含まれることに注意がいる。Outlookのローカルキャッシュ、ブラウザのキャッシュなどを引き継ぐ設定だと、作業終了時にそれをサーバ側に書き込み、次の起動時に読み込むので、多数のユーザーが行うと毎日数GBといったデータが特定時間にネットワークを流れることになる。もちろんこれはあまり好ましくない。キャッシュは保存しない設定のほうがお勧めだ。

コラム：マートデバイス上の仮想デスクトップでもマウスが使える

　スマートデバイスで仮想デスクトップを利用する場合に、画面サイズの問題とともに悩ましいのがiOSマシンではマウス操作ができないことだ。PCに慣れたユーザーは範囲指定やテキストなどのドラッグ＆ドロップをタッチ操作で行うのが大変なストレスになる。その解消のために、物理マウスをスマートデバイスにペアリングしたり、画面上にマウスの画像を映し出したりして操作性のギャップを解消、軽減するツールも出てきた（図1）。キーボードとのペアリングと併用して、少なくともタブレットではPCに近い操作性が実現可能になっている。

図1　仮想デスクトップで利用できるマウスの例