Application Compatibility: Planning Your Application Compatibility Project

[アーティクル]
08/25/2016

アプリケーションの互換性

アプリケーション互換性プロジェクトを計画する

Chris Jackson</b>

概要:

構想と範囲を定義する
チームを結成する
プロジェクトにおける 3 つの重要な段階
修正方法

私は仕事で世界中を回り、Windows の最新バージョンへの移行を行っている顧客に対応しています。このような顧客がよく直面する最も大きな問題は、アプリケーションの互換性です。アプリケーションの互換性に関する疑問として挙げられるのは、解決のためのコストがどれくらいかかるか、解決までにどれくらいの期間が必要であるか、何を知る必要があるのか、このプロセスの完了までにかかる期間が長すぎる場合、どのようにして期間を短縮すればよいかです。

アプリケーション互換性プロジェクトは、ソフトウェア開発プロジェクトに似ています。コストと期間の見積もりは、状況に応じてその都度修正されます。これまで顧客がアプリケーション数に基づいて期間とコストの見積もりを提示するのを見てきましたが、この方式で算出できる最も適切な見積もりは平均値です。多くの場合、平均値は算出された値に近くなりますが、実際にはほとんどの顧客がその期間とコストでプロジェクトを完了することはありません。ほとんどの組織は、平均よりも著しく良い結果か、がっかりするほど悪い結果に終わります。

では、どのようにしてアプリケーション互換性プロジェクトの計画段階に取り組めばよいかと言うと、コストの見積もりを早めに作成し、その見積もりを状況に応じて修正し、計画段階全体を通じてこの見積もりを最小限に抑えます。この記事では、プロセスに変更を加える必要が生じないように、私が対応した中で最も大きな成功を収めた顧客が取り入れたヒントとテクニックを紹介します。特に、アプリケーションをテストするエンドユーザーや、アプリケーションに優先順位を付けるビジネスオーナーなど、プロセスに直接関与しない参加者の生産性を最大限に高めることを目指します。

構想と範囲を定義する: Windows

アプリケーションの互換性に取り組む場合、なかなか作業が進まない可能性があります。いくつかのミッションクリティカルな Visual Basic 3.0 アプリケーションが正しく動作せず、ソースコードもない場合、挫折しそうになるでしょう。そんなときに必要なのは、やる気を起こさせるようなスローガンや、確固たる戦略上の決断を下すうえでの指針となる重要な目標です。

たとえば、管理者権限を必要とするアプリケーションの修正に取り組んでいて、Windows をアップグレードすることの主要な目的が、標準ユーザーとしてシステムを実行できるようにすることである場合、RunAsAdmin shim の適用はあまり良い調整方法ではありません。また、主要な目的が、より簡単に情報を検索、整理、および使用することで、正しく動作しないアプリケーションを修正する方法が、それらを "新しく買い替える" ことである場合、購入する製品の情報視覚化機能とシェル統合機能について検討するでしょう。

構想を書き留めたら、次は範囲を定義します。何割かのデスクトップを標準ユーザーに移行することが構想に含まれている場合は、その割合を定義します。当然のことのように思えるかもしれませんが、これは見過ごされることの多い作業です。この作業を行うかどうかは、成功と密接に関係します。

構想と範囲を定義する: アプリケーション管理

オペレーティングシステムを移行する時期は、アプリケーション管理の目標を設定するのに最適なタイミングです。企業内のあらゆるアプリケーションに触れることになるこの時期ほど、アプリケーションポートフォリオの管理方法を検討するのに適したタイミングはないでしょう。

次の 2 つの観点から、アプリケーション管理の目標を見直します。

敏捷性競争上の優位点として、どれくらい迅速に技術の変化に対応していますか。どれくらいテスト用ソフトウェアを使いこなして、リスクと運用までの期間を最小限に抑えていますか。どれくらいアプリケーションのライフサイクルを適切に管理していますか。現在使用しているソフトウェアによって解決されているビジネス上の問題を把握していますか、またそれがソフトウェアを使用した最適な解決策ですか。ソフトウェアは、慎重かつ戦略的に使用しましょう。
生産性ユーザーの生産性を最大限に高めていますか。一貫して高い質が維持された、馴染みのある最新のソフトウェアエクスペリエンスを提供していますか。生産性とヘルプデスクのコストを管理するための品質基準を持っていますか。ユーザーは共通のソフトウェアプラットフォームを使用して共同作業を行うことができますか。ソフトウェアを活用して、ビジネスの生産性を向上させましょう。

ほとんどの顧客への対応時に見られる、アプリケーション管理に関する唯一にして最大の課題は、アプリケーションの氾濫です。組織によっては、100,000 種類近くのソフトウェアを所有しています。これほどまでの数になると、まったく手に負えません。考えてみてください。50 人から成るチームを雇い、各アプリケーションのテストを 1 時間で完了できたとしても、すべてのテストを完了するのに丸 1 年かかります。アプリケーション互換性プロジェクトは規模調整プロジェクトと言うこともでき、最大の目的の 1 つは規模を最小限に抑えることです。

最大の問題が何であるかにかかわらず、その状況をどのように改善するかを書き留めます。おそらく、今回のプロジェクトで 100,000 種類のアプリケーションを 500 種類まで減らすことはできません。また、ボタンが大きすぎて両手でなければ押すことができないような古い VB6 アプリケーションをすべて除外することもできません。それでも、目標を設定し、それらを構想に盛り込み、定義した範囲内で数値化する必要があります。

チームを結成する

構想と範囲を定義したら、作業を担当するチームを結成します。重要な役割を次に示します (1 人が複数の役割を担当してもかまいません)。

プロジェクトマネージャ多くの分野と組織にまたがって構成されるチームをまとめます。
ビジネス調整リードビジネスアプリケーションの所有者からアプリケーションの優先順位に関するデータを入手し、ユーザー受け入れテストを行う場所を決定してそのテストの調整作業を行い、パイロットユーザーと交渉を行います (多くの場合、プロジェクトマネージャがこの役割を務めます)。
テクニカルリード開発者と協力してトレーニングが不足している箇所を明確にし、デバッグ担当者と協力して互換性に関する複雑な問題を解決します。
ラボマネージャ座り心地の良い椅子と、テストに使用する最新の OS イメージを、チームとユーザーベースに提供します。
アプリケーション調査チームサードパーティ製のソフトウェアの現在のサポート状況を確認します (多くの場合、この役割は外部に委託します)。
テストチームユーザーテストの前にインストールテストとスモークテストを実施して、基本的な互換性を確認します (多くの場合、この役割は外部に委託します)。
調整チームテスト中に確認された互換性の問題を解決します。
パッケージ作成チームテストの完了後、インストールパッケージを作成します (多くの場合、この役割は外部に委託します)。

すべてのチームメンバが、お互いに密接な連携を図るだけでなく、オペレーティングシステムの移行作業に関与している他のすべてのメンバとも一体となって作業を行う必要があります。たとえば、最新のイメージ、グループポリシー、および構成を共有できるようにします。

構想と範囲を定義し、チームの構成を明確にしたら、作業の計画に取り掛かります。このプロセスは、次の 3 つの段階に分かれます。

収集何を持っているか (現在の状態)
分析何を求めるか (目的の状態)
テストと調整何が正しく動作するか

収集

作業を計画する前に、どのようなソフトウェアを所有しているか、つまり現在の状態を把握する必要があります。使用するソフトウェア管理ツールが高度であるほど、現在の状態を細かく把握できます。ソフトウェア管理ツールから生成したアプリケーションインベントリがある場合は、それを使用します。インベントリがない場合は、マイクロソフトの Application Compatibility Toolkit (ACT) を使用して、優れたインベントリを作成できます。どのツールを使用するかは問題ではありません。問題は、そのツールによって、このプロセスを進めていく中で生じる疑問を解決するために必要なデータがすべて提供されるかです。インベントリを構築するうえで知っておいた方がよいことを次に示します。

部門または組織ユーザーはどの部門または組織に属していますか。この情報を基に、特定のソフトウェアがどのようなビジネス上の問題を解決するかを確認することによって、優先順位を付けたり、不要なソフトウェアを特定したりできます。この情報は、コンピュータ名や IP サブネットを使用するなど、さまざまな方法で収集できます。
役割ユーザーの役割は何ですか。この情報を基にソフトウェアの用途を確認することによって、優先順位を把握したり、不要なソフトウェアを特定したりできます。通常このデータは、Active Directory 内など、なんらかの形で電子化されていない限り、入手することは困難です。
使用状況どれくらいのユーザーがそのソフトウェアをインストールしていますか。その中でも、どれくらいのユーザーがそのソフトウェアを使用しているかがわかれば、さらに良いでしょう。だれもインストールしていない場合や、インストールしてもまったく使用していない場合は、より簡単にそのアプリケーションを除外できます。

続いて、アプリケーションのテスト担当者にとって役立つ次のデータを用意します。

OS と更新プログラムのレベル問題が発生したときに、テスト担当者が正常な場合とそうでない場合を比較できるように、ソフトウェアが正しく動作する (と思われる) ユーザー構成の詳細を把握する必要があります。
対象分野の専門家テストで実際のユーザーシナリオの代表例を示すには、実際のユーザーが必要です。SME を特定していない場合は、使用状況に関するデータが候補者の特定に役立つことがあります。
インストールされている他のアプリケーションアプリケーションの問題は、アプリケーション間の競合が原因で発生する場合があるので、そのようなアプリケーションを特定できるようにする必要があります。

最後に、実際の展開をサポートするために、ソフトウェアインベントリ内のデータが必要になります。役割ごとに展開を行う (補足記事「役割ごとに展開する」に、この方法をお勧めする理由が記載されています) 場合、役割ごとにアプリケーションにタグを付けると、優先的にテストするアプリケーションを識別するのに役立ちます。同様に、部門や地域ごとに展開を行う場合は、展開先のユーザーが使用するアプリケーションからテストを開始します。

現在の状態を完全に把握できましたか。それは良かったです、では次のセクションに進みましょう。把握できていない場合は、別のツールを使用してこの作業を完了してください。

アプリケーション互換性プロジェクト用のビジネスケースを作成するために、生の数値データを早めに取得することが必要になる場合があります。マイクロソフトから提供されている、エージェントを使用しないツールである Microsoft Assessment and Planning Toolkit を使用すると、いくつかの大まかな数値を取得できます。通常このツールは、プロジェクト全体を通して使用するには不十分ですが、どれくらいの投資を行えばよいかがわかるような情報は提供されます。

役割ごとに展開する

私が対応した中で最も大きな成功を収めた顧客は、Windows Vista を役割ごとに展開しました。この方法は、タスクワーカーの役割が構造化されている場合、特に効果的です。役割には、他の区別しやすい区分に比べ、ソフトウェアの使用状況という点で最も高い共通性があります。まずは、コールセンターなどの、構造化されたタスクワーカーの役割から取り掛かります。このグループで使用するアプリケーションの数は比較的少なく、おそらく 10 数種類です。これらのアプリケーションをすべてテストしたら、この役割への展開を行う準備は完了です。経営陣に成果を誇らしげに報告したら、次の役割に移ります。成功によってチームの士気は高まり、経営陣も進捗を目で確認できるので満足します。また、チームは少数のアプリケーションへの対応に慣れてから、インフォメーションワーカーなど、多くのソフトウェアを使用する役割に取り組むことができます。

詳細なデータを入手するには、エージェントが必要です。アプリケーションはさまざまな方法でインストールされる (MSI、xcopy、setup.exe など) ので、インベントリの収集は簡単な作業ではありません。検出する必要があるのは、組織内で使用されているすべての重要なアプリケーションです。リッチクライアントアプリケーションはほとんどのツールによって検出されますが、Web アプリケーション、ActiveX コントロール、および Microsoft Office アプリケーションについてはどうでしょうか。私の知る限り、すべてのアプリケーションを検出できるツールはまだ存在しません。

アプリケーションインベントリがない場合は、Application Compatibility Toolkit (ACT) を使用して、組織内の重要なデスクトップアプリケーションを検出することをお勧めします。このツールでは、サポート声明に準拠したアプリケーションとバージョンが提供されます。

余談ですが、ここで ACT とそのインベントリについて、1 つの誤解を解きたいと思います。その誤解とは、互換性エバリュエータがテストの代わりになるという考えです。収集するデータの量を決定するときは、そのデータの収集にかかるコストとデータの価値を比較検討します。互換性エバリュエータを使用する場合でも、テストは行う必要があります。その理由は、エバリュエータが (運用環境で実行できるように) パフォーマンスを重視していて、考えられるすべての問題を検出することを明確な目的としているわけではないからです (すべての問題の検出を可能にしていたら、その検出処理が原因で、ユーザーのパフォーマンスは大幅に低下していたでしょう)。

互換性エバリュエータは、廃止された機能 (GINA などのオペレーティングシステムから削除された機能) を効率的に報告します。Internet Explorer 互換性エバリュエータはすばらしい機能を提供しますが、Internet Explorer 7 以降でしか実行できません (また、テストの前に展開を行う可能性は低いので、このエバリュエータの使用範囲はラボのコンピュータやパイロットコンピュータに限定されます)。UAC エバリュエータは、ファイルとレジストリの仮想化によって自動的に解決されない問題をほとんど検出しないので、標準ユーザーとして実行したときに新たに発生するバグを大まかに予測するためのプログラムと考えた方がよいでしょう。つまり、このエバリュエータが検出する互換性のバグは、どれも対処する必要のあるバグですが、検出範囲が限定されているので、問題がアプリケーション全体に及んでいるかどうか、およびその問題がどれくらい深刻であるかを予測するという点では、それほど役立ちません。

このようなデータの価値を、コストと比較検討します。高度なソフトウェア展開システムが用意されていれば、より簡単に、低コストでエージェントを展開できます。また、データの収集をサポートするために使用するサーバーの価格や、データの収集にかかる時間も確認する必要があります。各ログの処理に平均で 17 秒かかる場合、1,000 台のコンピュータであれば、3 日でデータを収集し、8 時間ごとにアップロードを行い、そのデータを 2 日足らずで処理できます。ただし、企業で 200,000 台のコンピュータを所有している場合は、すべてのコンピュータから 30 日かけてデータを収集し、8 時間ごとにアップロードを行い、そのデータの処理が完了するまで 10 年近く待機する必要があります。

いずれにせよ、インベントリを収集する場合は、一部のコンピュータからのみ互換性に関するデータを収集するようにし、際限なく投資を行うことは避けた方がよいでしょう。これまでにも、このデータの収集に関して見積もられるコストが非常に高くなることがよくありました。

分析

現在の状態がわかったら、次は何を求めるか、つまり目標とするインベントリの状態を明確にします。この作業では、企業と IT 部門が協力し、さまざまな難しい選択を行う必要があります。その結果、このプロセスは図 1 のような順序で行われることが非常に多くなります。このような方法では、不要なものに多額の資金を費やした後でなければ、必要なものがわかりません。

図 1 賢明でないアプリケーション分析 (正しく動作するものが必要でないこともあります)

アプリケーションが正しく動作するかどうかに基づいて、必要なアプリケーションを決定することの問題点は、偶然正しく動作したという理由だけで不要なアプリケーションを残したり (サポートしたり)、多額の資金を費やして調査したアプリケーションを除外する結果になることです。

まず目標を明確にし、ビジネス価値を高めることが確認されたアプリケーションの調査とテストにのみ資金を費やした方がよいでしょう。

アプリケーション分析プロセスの生産性を高めるには、明確な目標を設定し、それに対する進捗を確認することをお勧めします。次のような目標を設定するとよいでしょう。

アプリケーションの最大数サポートするアプリケーションの数について、明確な目標を設定します。
アプリケーション管理の許容範囲ビジネスの優先順位とユーザー数に基づいて、"管理対象" のアプリケーションと判断するための許容レベルを設定します。
管理レベル分散型の組織では、アプリケーション管理に関する組織全体の目標を設定し、各事業部がそれぞれのビジネス内容に合わせて、自主的にこのガイダンスを実装できるようにします。
市販ソフトウェアのバージョン管理に関する基準すべてのソフトウェアの最新バージョンを常に購入すると、コストが非常に高くなる可能性がありますが、それと同時に、非常に古いソフトウェアが残る危険性も生じます。ビジネス上重要なアプリケーションについては、基準を n (現在のバージョン) または n-1 (前のバージョン) に設定することを検討してください。
サポートするプラットフォームサポートするプラットフォームを限定することによって、作業の複雑さを軽減できます。適切な状態で実行する必要がない (最新のプラットフォームとの互換性を確保するためだけに新しいバージョンを作成する必要がない) アプリケーションがある場合、それらをすべてアップグレードすると、作業の規模が非常に大きくなり、コストもかかります。
アプリケーションの優先順位に関する目標 "ビジネス上重要である" ことの意味は、ユーザーによって大きく異なります。目標を割合で示すか、この意味がはっきりとわかるような客観的基準を設定することをお勧めします。

このような目標を踏まえて、次はビジネスに携わっているユーザー、つまり特定のソフトウェアを使用する理由とその方法を知っているユーザーの協力を求めます。小規模の組織では、これは一対一の作業になる場合があります。大規模の組織では、SharePoint ポータルを使用してデータを収集し、分析プロセスに使用できます。環境を単純化することも必要ですが、"連邦法に準拠するために、この税務ソフトウェアの 7 つ前までのバージョンの動作を維持する必要がある" などのデータも入手する必要があります。

ここで 1 つ重要なのは、直接チームに関与しないユーザーのスケジュールに合わせて作業を行うことです。通常、ビジネスオーナーがチームへの協力に対してすぐに見返りを求めることはほとんどまたはまったくありません。

アプリケーションに関する既知の情報を収集するにはどうすればよいでしょうか。市販ソフトウェアに関する情報は、Windows Compatibility Center で公開されていますが、このサイトのデータと組織のソフトウェア一覧を照合する必要があります。Application Compatibility Toolkit 5.5 を使用すると、この照合を自動的に行うことができます。

この早めかつ頻繁に除外するという原則は、全体を通して適用されます。アプリケーションを 30 秒で除外できる高価なリソースは、不要であるかどうかを調査するのに 1 時間かかる安価なリソースよりもコストがかかりません。明らかに不要なアプリケーションを除外した後、ビジネスオーナーからデータを収集し、そのデータを参考に引き続き使用することを決定したアプリケーションのみを調査します。アプリケーションの調査は、図 2 のような方法で行うことをお勧めします。

図 2 コストのかからない早めの段階にアプリケーションを絞り込む

この原則はどれくらい効果的に機能するのでしょうか。ある顧客は、54 台の異なるコンピュータから、約 1,200 種類のアプリケーションを含むインベントリを作成しました。昼休みの間に、その顧客のビジネスルールに従って、明らかに不要なアプリケーションを除外しました。この時間で、アプリケーションを 450 種類まで絞り込むことができました。もう少し時間があれば、さらに絞り込むことができたかもしれません。1 時間で 700 種類を超える不要なアプリケーションを除外することによって、コストを大幅に節約できました。

これで、目的の状態に基づいてコストの見積もりを修正できるようになります。また、この見積もりと共に、市販ソフトウェアの互換性の状態に関する既知の情報を提供したり、静的分析ツールを使用して、正常に動作すると思われるアプリケーションと、問題が発生すると思われるアプリケーションを把握することもできます。

テスト

次に、テストプロセスの担当者を決定する必要があります。チームに関する考慮事項は次のとおりです。

内部チームの構成いくつかの役割 (テスト担当者、デバッグ担当者、開発チーム、ユーザー、ビジネスオーナーなど) をまとめることができるように、チームを内部で指揮する有能なプロジェクトマネージャと技術スタッフを選出します。
協力を要請するパートナー多くの組織は、パートナーにこのプロセスの支援を要請します。各パートナーにどの分野での協力 (特定のスキルの強化、スタッフの増員、工場式の方法など) を依頼するのが適切であるか、およびビジネス機能のテストで、それらのパートナーをどのようにユーザーと統合するかを検討します。

また、使用するテクノロジを計画する必要があります。検討する必要があるテクノロジを次に示します。

仮想マシン復元ディスク機能とスナップショット機能を使用すると、大幅に時間を節約できます (たとえば、永続的にマシンの状態に悪影響を与える "初回実行時" のバグによって時間が無駄になることはありません)。
ターミナルサービス/リモートアシスタンスユーザーテストに非常に役立つ機能です。テスト担当者はこれらの機能を使用して、すばやく簡単に Windows Vista コンピュータにアクセスできます。リモートアシスタンスは、バグの再現と調査にも役立ちます。
パイロットコンピュータアプリケーションをテストする代わりに、強化された新しいデスクトップにいち早くアクセスできることによって、ユーザーの意欲が大幅に高まる可能性があります。

次は、テストプロセスの詳細を計画します。図 3 は、ワークフローの骨組みを示しています。

図 3 アプリケーションのテストプロセス

ユーザーに協力を要請する前に、できる限りの手段を講じて、明らかになっている問題をすべて解決します。気乗りしないユーザーを説得してようやくラボに来てもらったにもかかわらず、インストーラが原因でテストが中止になるほど腹立たしいことはありません。

同様に、修正するつもりがない機能をテスト担当者がテストすることのないようにしてください。サポートが必要な場合は、サポートされているバージョンのみをテストします。

修正

テストを効率化するには、修正を考慮してテストを行う必要があります。問題のあるアプリケーションのデバッグは、そのアプリケーションがどの修正カテゴリに分類されるかを特定できるまで行います。そのカテゴリがわかったら、デバッグを終了します。

もちろん、これを行うには、検討されているカテゴリと、どのような状況でそのカテゴリに分類すればよいかをテスト担当者が把握している必要があります。このため、修正に関する戦略を明確に定義する必要があります。ほとんどの組織が検討する修正方法は、次のとおりです。

新しく入手する。この方法は成功率が非常に高く、製造元のサポートも提供されます (アプリケーションによってはこのことが重要になります)。この方法には開発または調達コストがかかるので、費用は最も高くなる傾向があります。通常、この方法は資金的な余裕がある場合に使用します。
shim を適用する。これはコストを節約できる方法です。オペレーティングシステムを呼び出す前の部分で、その呼び出しに変更を加えることによって、アプリケーションの動作をサポートします。この修正は、ソースコードにアクセスしたり、アプリケーションに変更を加えたりすることなく行うことができます。この方法を使用すると、追加で発生する (shim データベースの) 管理オーバーヘッドを最小限に抑えつつ、ある程度の数のアプリケーションを修正できます。短所は、ほとんどの製造元で、shim を適用したアプリケーションがサポートされないことです。また、shim を使用しても修正できないアプリケーションがあります。通常は、アプリケーションの製造元が倒産したとき、そのソフトウェアがサポートを必要とするほど戦略的に重要でないか、単純にいつか購入しようと考えている場合に、shim の適用を検討することがほとんどです。
ポリシーを変更する。特定の機能が原因で多くのアプリケーションが正しく動作しなくなった場合は、その機能を無効にすることをお勧めします。この方法の長所は、shim を使用する場合と同様、ソースコードを変更したり、ソースコードにアクセスする必要がないことです。短所も同様で、サポートが提供されないことと、修正できないアプリケーションがあることです。この方法は、Web アプリケーションの修正方法として検討されることがあります。Web アプリケーションの修正には、shim を使用できません。一時的な解決策として、いくつかのセキュリティ機能を個別に制御し、無効にできます。一般的に選択されるのは、ローカルイントラネットゾーンの保護モードを無効にすることです (Internet Explorer 8 では既定で無効になっています)。ただし、システムの既定のセキュリティを変更するときは、その影響を十分に考慮する必要があります。たとえば、UAC を無効にすると、OS を移行することのビジネス価値がなくなってしまう可能性があります。
アプリケーションを仮想化する。アプリケーションの互換性に関する問題の解決策として、アプリケーションの仮想化を使用することに関しては、さまざまな情報が飛び交っています。以前に耳にしたのは、この方法はアプリケーションを基盤となる OS から完全に分離するので、絶対に信頼できる欠点のない解決策であるという情報です。現在ではこの情報が間違っていると断言できます。ファイルとレジストリの呼び出しを例外とすれば、アプリケーションは基盤となる OS を呼び出すので、ファイルシステムとレジストリ以外で発生する互換性の問題は、依然として解決されません。この方法は、アプリケーション間で競合が発生した場合には有効ですが、アプリケーションと OS との間で競合が発生した場合にも使用できる汎用的な解決策ではありません。サポート状況は不明ですが、おそらくあまり好ましい状況ではありません。企業によっては、OS 上でネイティブに実行されるソフトウェアはサポートしても、アプリケーションを仮想化した場合はそのソフトウェアをサポートしない場合があるからです。顧客がこの解決策を使用する典型的なシナリオとして挙げられるのは、ファイルシステムとレジストリに関する問題が発生した場合、コアの読み込み時に発生する別のアプリケーションとの競合が原因で問題が発生した場合、および顧客が仮想化されたアプリケーションを使用した展開を好み、幸運にもそれによって互換性の問題を解決できる場合です。
コンピュータを仮想化し、ターミナルサービスを使用する。コンピュータの仮想化は、強引な方法です。ご存じのとおり、この方法は成功します。なぜなら、仮想化されたコンピュータをローカルコンピュータ上またはサーバー上のどちらで実行する場合でも、OS の以前のバージョンが実行基盤になるからです。仮想化されたコンピュータは、実際にはサポートされているオペレーティングシステム上で実行されるので、このシナリオはほぼ必ずサポートされます。ただし、"コンピュータを完全に仮想化し、今すぐ移行して、問題は後から解決しよう" という意見が出た場合、私はより慎重になる傾向があります。その理由は、管理するオペレーティングシステムの数がユーザー数の 2 倍になる可能性があり、それによって管理オーバーヘッドが発生するからです。ローカルで仮想化を使用する場合は、2 つのオペレーティングシステムを同時に実行できるだけのリソース (特にメモリ) を備えたコンピュータが必要です。現段階では、優れたユーザーエクスペリエンスが提供されない場合もあります。画面に 2 つの [スタート] ボタンが表示されたら、ほとんどのユーザーは混乱してしまいます (ただし、この状況を改善する方法がマイクロソフトとパートナーの両方から提供されています)。顧客のほとんどは、アプリケーションの問題に対処する最後の手段としてこの方法を使用する傾向があります (実際は、多くの顧客がテスト期間のしきい値を設定しています。修正チームは、一定期間内に問題を解決できなかった場合、永遠に完了しない可能性があるテストを続けるのではなく、テストを終了してアプリケーションを以前の OS 環境に配置します)。
除外する。この選択肢を忘れないでください。ビジネス価値の低いアプリケーションや不要なソフトウェアは、修正する価値がない場合もあります。その場合は、これらを除外します。

まとめ

この記事では、互換性プロジェクトの計画に関する最も重要ないくつかの考慮事項について説明しました。私はこの計画を、確かな 1 つのまとまりとして完成させる (プロジェクトが実際に開始される前に、完全なプロジェクト計画を作成する) だけでなく、1 つの段階が完了するたびに、顧客と次の段階について話し合いました。重要なのは、最終的に時間と資金を節約できるように、各段階で何ができるかを理解することです。

このプロセスでは技術者としての腕前も試されますが、アプリケーション互換性プロジェクトにおける最大の課題は、大量のアプリケーションを管理すること、および協力に対する見返りがないユーザーの意欲を高めることです。ここで紹介したヒントやガイドラインが皆さんのお役に立てば幸いです。

Chris Jackson は、Windows Application Experience SWAT チームのテクニカルリードです。Chris は、世界中の企業顧客に対して、それらの企業がアプリケーションの互換性に関して抱える問題の調査とその調整作業をサポートするだけでなく、業界の多くのイベントで、Windows アプリケーションの互換性に関する教育トレーニングを行っています。blogs.msdn.com/cjacks から彼に連絡を取ることができます。

目次

その他のリソース