Microsoft Office: Office の互換性に関する数学
Office のアップグレードを検討している場合、簡単な数学が適切な互換性のテスト シナリオを決定するのに役立ちます。
Chris Jackson
"事実は動かないものである。我々の願い、気持ち、感情の命令がいかなるものであっても、事実と証拠の状態を変えることはできない" - John Adams
新しいバージョンの Office を、組織全体に展開することにしたとしましょう。実際に展開してからユーザーが日々の業務で使いこなせるようになるまで、どのくらいの時間がかかると考えたらよいでしょうか。平均的な組織では、12 ～ 18 か月ほどかかります。
この期間が長引く原因は、リスク管理です。展開作業を進めながら、ビジネスが中断されないようにする必要があります。作業が思うように進まないかもしれませんが、リスク管理を完全に排除して展開作業を進めることはできません。この相反する作業のバランスを取るには、どうすればよいでしょうか。
これらの問題をテクノロジで解決するのが一般的なアプローチです。IT 担当者は、データの存在自体がなんらかの方法でプロセスを促進するものであるかのように、ツールを使用してデータを収集しますが、データの量を増やしても、自然に生まれる不安は軽減されません。アップグレードによって、ミッション クリティカルなビジネスで障害が発生するおそれがあります。この場合、"障害のコストは無限大に等しい (可能性がある)" という方程式を当てはめることができます。
アップグレードを行う際には、変更に対する不安と何事によってもビジネスが中断されないという要求に対処する必要があります。古いバージョンの Office の仮想コピーを利用できる状態で維持すると、ドキュメントやアプリケーションで問題が発生したときに、すぐにこのセーフティ ネットを使用するようユーザーに指示して、生産性を回復できます。また、アプリケーションを修復して、アップグレードした環境に早急に戻すこともできます。
多くの人は決定の意味を考えることなく、ツール、プロセス、またはパートナーで障害が発生しないことを期待し、なんとしても障害を回避しようとします。障害のコストを "最悪" から "妥当で賢明" なレベルまで引き下げたら、決定の裏側で使用される数学を見てみましょう。この数学は、より的確な決定を下し、他人の要求を評価するのに役立ちます。
"障害のコスト x 障害が発生する可能性" が "テストにかかるコスト" より高額になる場合は、アプリケーションの互換性テストを実施するとよいでしょう。
一般的な公式と同様に、この数式については少し解説が必要です。互換性テストは、特別なものと見なされるべきではなく、大きな負担でもありません。リスク管理のための投資と考えてください。
これが、テストしていないドキュメントとアプリケーションについて、どのような意味をもたらすかというと、それらを無視してかまわないというわけではなく、事前テストを実施しないことを選択したというだけで、事後テストに投資することになります。ユーザーから問題が報告されたときに、問題を解決します (また、ユーザーが問題を報告しやすいようにする必要があります)。
とても重要なドキュメントがあるとしましょう。ただし、障害が発生しても、そのドキュメントによって、ビジネスで重大な中断が起こることはありません。ユーザーはヘルプ デスクに連絡し、アプリケーションの互換性に関する事後サポートを受けます。問題の解決にかかる平均的な時間は 30 分です。問題が重大で、仮想化テクノロジを使用して、すぐに生産性を確保する必要がある場合、この時間は平均よりも短くなります。
ドキュメントのエラーを調査をしているとしましょう。今回のアップグレードによる Office ドキュメントのエラー発生率は 5% であることがわかりました。ユーザーの 1 時間の価値が 250 ドルだと仮定すると、この障害のコストは 125 ドルを 5% で乗算した 6.25 ドルになります。事前テスト プロセスの償却コストが 6.25 ドルを少しでも上回る場合は、事前にドキュメントをテストする必要はまったくありません。
最初に行うのはインベントリか否か
"インベントリ、合理化、テスト、および修復" というプロセス フローは普及しています。組織は、正確なインベントリを行うために、試行錯誤していますが、インベントリを行う価値があると数学は示すでしょうか。
その答えは方程式に入れるものしだいですが、アプリケーションの検出方法の決定に数学を使用する価値はあります。"ドキュメント数 x 平均的なコスト x 問題の重要性を判断するのにかかる時間" が "高いコスト x ドキュメントの一覧作成にかかる時間" よりも低額になる場合は、完全なインベントリを実施すると良いでしょう。
1 つ目の変数は、通常作成するドキュメントの数です。この数は組織の性質によって、大きな標準偏差があります。次に、組織におけるドキュメントの重要性を判断するのに役立つリソースを特定する必要があります。
ドキュメントの合理化は少し困難になることがあります。アプリケーションと比較すると、明らかに不要なものは少ししかありません。ご使用の環境で判断を下す複雑さに応じて、ドキュメントやアプリケーションが必要かどうかを判断するのにかかると考えられる時間を割り当ててください。代替案は、高いコストで働いているビジネス ユーザーに重要なドキュメントを確認して、一定の時間をかけてその一覧を作成するように依頼することです。
組織に 50,000 人のユーザーがいて、各ユーザーが平均 500 個のドキュメントを作成してネットワーク上のどこかに格納していると仮定した場合、組織内には合計で 2,500 万個のドキュメントが存在することになります。合理化を担当するリソースの時間単価は 100 ドルで、各ドキュメントの調査に 5 分かかるとしましょう。
次に計算の結果を示します。
25,000,000 x 100 x 0.08 ? 300 x 8 x 100
200,000,000 >> 240,000
数学を使用すると、簡単に決断を下すことができます。完全なインベントリと合理化を行う場合は 2 億ドルかかりますが、この時点では効果があるかどうかもわかりません。代替案では、機会費用として数十万ドルを使い、手作業でドキュメントの一覧を作成するように依頼することになります。
Office の展開に関する合理化では、大数の法則は成立しません。ツールを使用することを検討している場合は、単にインベントリを実施するのではなく、自動化を行う必要があります。調査対象は、ツールでは推測するのが困難なビジネスへの影響です。代替案として、ファイルの更新日を利用することは可能ですが、完全な代わりにはなりません。より適切な代替案は、クライアント コンピューターの実際の使用状況を調査することです。
新しいバージョンの Office ではテレメトリ (遠隔測定) の機能が導入されています。この機能は Office に統合されており、ユーザーが使用しているドキュメントとアドインのデータをユーザーのコンピューターから収集します。また、古いバージョンの Office にもインストールできます。ドキュメントのインベントリを生成する際には、ユーザーの最近使用したファイルの一覧にあるドキュメントを重点的に調べます。この調査を行うことで、インベントリを "だれかが作成したドキュメントの一覧" から "ユーザーがいつも実際に使用しているドキュメントの一覧" に絞り込むことができます。
このアプローチを使用すると、実際にリスクが存在する可能性のある場所を示すテレメトリ データを収集して分析できるようになります。しかし、今日インベントリを収集する一番の方法は、単純にユーザーに一覧を提供してもらうことです。
ベンダーのサポートに関する声明
ベンダー調査は、特に Application Compatibility Factory (ACF) プログラムを利用してアプリケーションの互換性に関するプロセスで行います。調査の必要性は、特定のアプリケーションでベンダーのサポートが必要かどうかによって決まります。ベンダーのサポートが必要になる可能性が高ければ、ベンダー調査の実施は、ビジネス要件になります。
ベンダーが使用している多くのプロセスと一覧は、アプリケーションが移行先のプラットフォームでサポートされているかどうか、および現在もサポートされているかどうかを判断するのに役立ちます。ベンダーはサポート料金を設定しているので、アプリケーションが移行先のプラットフォームで使用できるかどうかのよい判断材料になります。
しかし、アプリケーションがサポートされているかどうか、および今後アプリケーションを実行するかどうかというビジネス上の問題の実際の答えになっていないので、しっかりと問題の答えを確認する必要があります。
ベンダーのサポート状況について時間をかけて調査する価値があるかどうかを判断する場合にも、数学を使用します。代替案は、自分で互換性の評価を行うことです。しかし、多くの人がアプリケーションのテスト コストと調査コストを比較するという間違った計算をしています。この間違った前提から、すべての計算結果を導き出すことは可能ですが、統計的に正しいアプローチではありません。
次に有効な方程式を示します。"アプリケーションあたりのテスト コスト x ("サポート声明が見つからないアプリケーションの割合" または "サポート声明がミッション クリティカルなアプリケーションの割合"） + アプリケーションあたりの調査コスト" が "アプリケーションあたりのテスト コスト" より低額になる場合は、ベンダー調査を実施するとよいでしょう。
この方程式にも数字を当てはめてみましょう。1 つのアプリケーションのテスト プロセスに 150 ドルかかり、ベンダー調査のプロセスには、アプリケーションあたり平均 15 ドルかかるとしましょう。組織ではアプリケーションの 12% にサポート声明があることを確認しました。そのうち 10% がミッション クリティカルなアプリケーションなので、テストを実施します。
150 x 89.2% + 15 ? 150
148.80 < 150
この結果から、ベンダー調査を実施するのが有効ですが、想像していたほど大きな効果はありません。結局のところ、ベンダー調査にかかるコストは、アプリケーション テストにかかるコストの 1 割で、アプリケーションあたり平均 1.20 ドルしかコストを削減できません。
もちろん、何か (特に規模) を削減するのはよいことですが、見込まれる効果があまりない場合は注意が必要です。エラーの発生率が高くない限り、大掛かりな対策を講じる必要はありません。上記の推計によると、サポート声明があるアプリケーションの割合が 10% 未満になると、調査コストの方が高くなります。直感に反するように思えますが、エラーの発生率が非常に低い場合、単価の低いオプションは、実際はあまり好ましくありません。
変換の問題
最新バージョンの Office には、大幅な機能強化が施されています。ドキュメントを作成および編集する新機能の多くは、最新のファイル形式を使用する必要があります。これらの新機能を特定のドキュメントで利用する場合は、ファイルを変換する必要があります。
すべてのドキュメントを調査して、新しいファイル形式にアップグレードする作業を行うかどうかということがよく問題になります。プロセスは簡単に見えます (事実、簡単です) し、この作業に役立つツールがあります。しかし、すべてのドキュメントが問題なくアップグレードされるわけではありません。アップグレードのコストには、アップグレードによってアプリケーション エラーが発生しないようにするリスク管理のコストが含まれます。以前のバージョンで利用できた "版の管理" 機能など、いくつかの機能が廃止されていたり、グラフの表示が変更されたり、古い拡張子のファイルへのリンクが切れたりする可能性があります。
もちろん、このデメリットはメリットにもなります。Office の新機能を使用するためのアップグレードを手動で行わないことによって、すべてのファイルをファイル サイズの小さな新しいファイル形式にするというメリットが得られます。この判断を下すために、ここでも変換作業によって好ましい投資収益率 (ROI) が得られるかどうかの数学が必要になります。"変換コスト + テスト コスト" が "ドライブ容量のコスト" より低額になる場合は、すべてのドキュメントを一括変換するとよいでしょう。
まず、コスト削減について見てみましょう。以前と同じ数字 (50,000 人のユーザーがいて、各ユーザーが 500 ドキュメントずつ保有している) であるという前提で、ファイルの平均サイズが 1 MB という条件を加えます。この条件では、11 TB のディスク容量のコストを削減できる可能性があります。全体像を把握するために、ディスク容量のコストを計算してみましょう。Matthew Komorowski が導いて、「A History of Storage Cost (ストレージ コストの歴史、英語)」で発表した公式を使用したところ、1 GB あたりのコストは 10 を "-0.2502 (西暦 - 1980) + 6.304" で累乗したものであることがわかりました。
この値はディスク メディアの価格のみに基づいて算出されています。この公式では、2012 年にはデータ格納用のハード ドライブを 1 GB あたり約 0.02 ドルで買えるという結果が出てていますが、Windows Azure のストレージ コストを使用して総コストを調整する必要があります。現在のストレージ コストは 1 TB あたり 128 ドルで、公式で導かれたコストのわずか 6.3 倍です。
公式を次のように修正して、予想されるストレージの総コストを調整します。1 GB あたりのコスト は 10 を "-0.2502 (西暦 - 1980) + 6.304" で累乗したものを 6.3 で乗算したものになります。
ドキュメントを平均 10 年間保存すると仮定すると、この公式によって予測される総削減コストは 3,209.53 ドルになります。Windows Azure のストレージ コストが変わらないと仮定しても、総額 14,080 ドルのコストを削減できます。
つまり、ドキュメント変換成功可能性のテストとドキュメントの変換の総コストが、控えめに考えて 14,080 ドル (ストレージ コストが同じ指数比率で下がり続けると仮定すれば 3,209.53 ドル) 以下なら、変換を実施することは理にかなっています。
テストと変換にそれ以上のコストがかかる場合、変換を実施する意味はないので、ドキュメントは既存の形式のままにしておくのがよいでしょう。Office 2010 では、既存の形式のドキュメントを問題なく読み取れます。新機能を使用する必要があるときには、手動で変換してください。
適切なツール
プラットフォームの互換性の問題に取り組む最も一般的なパターンは、アップグレードに起因するすべての問題を特定する （可能であれば修正する） ツールを探すことです。互換性の問題に関連するツールによって、この目標の全体または一部を達成することが可能で、どこでもツールを実行できると考えるかもしれませんが、ある時点で、問題が完全には解決していないことに気が付くでしょう。
この問題は、ボトルネックの 1 つです。互換性の問題 (バグ) は、特定のプラットフォームで発生する特殊なバグに過ぎません。既存のプラットフォームで、すべてのバグを特定して修正するのとまったく変わりありません。すべてのソフトウェアが常時問題なく機能しているという理由でヘルプ デスクを設置していない場合を除き、プラットフォームには互換性に関する多くのバグが存在しています。この状況は、バグがバグとして理解されないからではなく、対処が難しいバグであるために発生しています。
アプリケーションが停止するか、永遠に実行を続けるかを検出するプログラムは作成できないというアラン チューリングの 1937 年の証明については、少なくとも概要はご存じでしょう。この制約は解決が非常に難しい問題で、今日も研究に影響を与えており、科学者はプログラムの正確性を確保する新たな検出プログラムを作成することを目指しています。次に例を示します。
"コンテキストが制限されている分析は、同時実行プログラムの検証方法として魅力的なアプローチです。このアプローチでは、1 つのスレッドで実行されるコンテキストの数が定数 K で制限される、同時実行プログラムのすべての実行を分析することを推奨します。1 つのスレッドで実行されるコンテキストの数を制限することで、同時実行プログラムのチェックの漸近的な複雑さが軽減されます。ブール型の同時実行プログラムの "到達可能性" 分析は不可能ですが、コンテキスト制限下の同様の分析は NP 完全になります。さらに、同時実行におけるわずかなコンテキストの入れ替わりで、データ競合、原子性違反などの同期エラーが発生するという経験に基づいた証拠が豊富にあります。この 2 つの性質を利用することによって、コンテキストが制限された分析は、同時実行エラーを発見する効果的なアプローチになります。同時に、コンテキストの制限は、検証のコストと範囲の関係に有益なトレードオフをもたらします"
バグの定義を明確にする必要があります。プログラムがクラッシュする状況がバグであることには、ほとんどの人が同意しますが、状況によってプログラムの動作がバグかどうかが決まることもあります。たとえば、グラフの色の変更によって、思わしくない方向に意味が変化することもあれば、問題がなかったり、好ましくなったりすることもあります。バージョン チェックは、開発者がコードを記述して動作を導入する必要があるので、技術的には機能ですが、バージョン制限を満たしていないユーザーによってバグと見なされることがあります。
すべてのバグ (または、特定のカテゴリのすべてのバグ) を特定するのは不可能だということを踏まえて、自動化が有効な領域で集中的に自動化を行う必要があります。停止性問題が解決できたら、あらゆる無限ループという一般的なバグを停止できるようになるので、成果は大いにあるでしょう。
すべてのバグを特定して修復することを検討しても、必ずしもよい成果が得られるとは限りません。理論的には、経験的か状況的かを問わず、プログラムのバグの書き方は無限にありますが、すべてのバグを検出する手段は有限です。プログラムのバグの数が減ると、チェックの自動化による成果も同様に下がります。そのため、自動化の対象を選択する必要が生じます。
数学は比較的正直です。"自動化の作成コスト + 自動化の実行コスト" が "デバッグのコスト x バグの数" より低額になる場合は、バグを特定する自動テストを作成するとよいでしょう。
これは非常によく見られる問題に対して有効です。たとえば、Windows のアプリケーションについては、標準ユーザーのアカウントでユーザー アカウント制御を実行するのが多くの組織にとって現実的な選択肢です。管理者として実行するのが望ましいと考えられていた時代に設計されたソフトウェアの多くでは、コンプライアンスに関する重大な問題がある事も明らかになりました。これらの問題は、頻繁に発生し、よく似ているため、個々の問題のトラブルシューティングを行った場合と比較すると、すべてのバグを特定するプロセスを自動化するプログラムを作成することで大きな成果が得られました。
特定のプラットフォーム用の検証ツールを作成しているベンダーは、多くの顧客に販売して、自動化プログラムの作成コストを償却できます。ベンダーは、より簡単かつ安価に新しいテストを作成するために投資しているため、この数学は、多くのテストを実施するほど有利に働きます。同時に、作成が簡単で安価なテストでは、インシデントの数がとても少ないでしょう。第一種過誤 (偽陽性) と第二種過誤 (偽陰性) に注意することが重要になります。
新しいバージョンの Office で導入された検証テクノロジにより、第一種過誤と第二種過誤の両方が発生していた古いバージョンの Office の問題がいくつか解消されました。特定のシナリオへの適用可能性に関する混乱もあります。
たとえば、Office Migration Planning Manager ツールセットでは、潜在的な問題をスキャンして特定します。ドキュメントを新しいファイル形式に変換する際の問題も確認できます (ドキュメントを変換しない場合、これは問題になりません)。新しい検証機能では、非推奨 API の使用やアドインに起因することが多いアプリケーションのクラッシュなど、展開を困難にする問題に重点が置かれています。
次の作業が、評価、テスト、および変換という 3 つのプロセスにおける本当に最後の作業です。
- 感情的な不安を軽減し、理性的に考える。
- 適切なデータを収集する。
- データを分析し、データから体系的な情報に変換する。
次に、数学的な根拠を実践するためのいくつかのガイドラインを示します。
- 可能であるという理由だけで何かを行う必要はありません。
- アプリケーションの互換性に関する作業は、新聞記事を執筆するように実施します。最も重要なことから始めて、順番に作業を進めます。すべての作業が完成していなくても、最も重要な作業は完成する必要があります。
- 必須の作業と任意の作業に関連性があるように思えても、混同しないでください。
Office の互換性に関するプロジェクトで行う作業について適切な判断を下す際に使用する数学を探る冒険が、推論に疑問を持ち、効率を向上するきっかけになれば、さいわいです。
.jpg)
Chris Jackson は、マイクロソフトで "アプリケーションの互換性に詳しい人" として知られています。エンタープライズ アプリケーションの互換性に関するプリンシパル コンサルタントとして働いており、全世界のリード コンサルタントとして活躍しています。IT 担当者や開発者を対象としたカンファレンスで定期的に講演を行い、世界中の顧客やパートナーと仕事をしています。彼の任務は "レガシー ソフトウェアの足かせを外すことによって、テクノロジのアジリティを回復すること" です。ぜひ、彼のブログ (appcompatguy.com、英語) を参照したり、Twitter (twitter.com/appcompatguy、英語) で彼をフォローしてください。