Partilhar via


OMPM の使用 (パート 3) - OMPM のその他の用途

原文の記事の投稿日: 2012 年 1 月 14 日 (土曜日)

寄稿者: 互換性の第一人者 Curtis Sawin

概要

OMPM は、主にドキュメント変換に関する問題の詳細情報を確認するときに使用します。また、"バイナリ形式の Office ファイルを Open XML ファイル形式に変換した場合、どのようなリスクがあるのか" という質問に対する回答を得るのにも役立ちます。ところが、"Office 2010 アプリケーションでバイナリ形式の Office ファイルを開くと、どのようなリスクがあるのか" という質問に対して OMPM を使用している人は少なくありません。その結果、一部の人については、見当違いの質問に対して OMPM を使い、かなりの時間、手間、そしてコストをかけて、優れたツールで誤った情報を入手していることになります。

展開前のタスクと展開後のタスクの特定

互換性プロジェクトでは、プラットフォームにかかわらず、互換性タスクを切り離し、展開前のタスクと展開後のタスクに組み込む必要があります。つまり、新しいプラットフォーム (Office 2010、Windows 7、Internet Explorer 9 など) に移行する前に、新しいプラットフォームを展開できるようにするタスクだけに焦点を当てて取り組む必要があります。こうしたタスクが、プラットフォームを展開できるかどうかに直接影響を及ぼすのは明らかです。展開前タスクが "展開実現" タスクと見なされるのは、このような理由があるからです。

展開後のタスクは、新しいプラットフォームで生産性の向上 (プレビューの貼り付け (英語) については説明したでしょうか?)、コスト削減などのメリットを実現できるようにするタスクです。さらに、展開後のタスクにより、将来のプラットフォームに移行に対する準備を行うこともできます。こうしたタスクは、"環境の最適化" タスクと見なされます。

たとえば、廃止されたマクロ コードの更新は展開後のタスクです。前のバージョンの Office で廃止されているオブジェクト モデル アイテムも引き続きコンパイルされますが、将来のバージョンの Office では使用できなくなる可能性があるからです。言い換えると、廃止されたコードによって、Office 展開がブロックされることはありません。だから、Office 2010 を展開したら、廃止されたコードを更新して、将来のバージョンの Office に備えます。

ドキュメントの変換も展開後のタスクです。ドキュメントを変換することで必要なネットワーク記憶域を減らすことができ、これが環境の最適化に役立つからです。

OMPM を最適に使用するには

前述したように、OMPM は、ドキュメント自体の問題ではなく、ドキュメントの "変換" に関する問題を特定します。つまり、特定のドキュメントについて、OMPM は、そのドキュメントが最新のファイル形式に "変換" されるかどうかを判断する際に役に立ちます。しかし、Office 2010 で "動作" するかどうかまではわかりません。

展開前のタスクで OMPM を使用して、Office 2010 で開いたドキュメントが動作するかどうかを判断しようとするのは、よくある OMPM の誤用です。その理由をいくつか以下に示します。

  • ツールの名前には "計画" と "移行" という言葉が使用されています。だから、移行を計画するときは、このツールを使用するべきですよね? (残念ながら、使われていませんが)。
  • ツールが提供する結果では、"赤"、"黄色"、"緑色" で問題が識別されます。赤、黄色、および緑色の各データが、"緑色 = 良い"、"赤 = 悪い"、"黄色 = それほど良くない (ただし、悪くもない)" であることは簡単に理解できます。
  • さらに重要なのは、このツールはIT 組織が持っていないデータを提供するという点です。このツールは環境全体をスキャンし、見つかったすべてのドキュメントの状態をわかりやすく示すことができます。IT 組織の多くは、"少し" の情報でもないよりはましと考えます。

最後の項目は特に魅力的です。OMPM は、状況を把握するためのデータを IT 担当者に提供します。お客様が OMPM を使用してドキュメント変換に関する問題を見つけ、"赤" の問題が発生しているドキュメントだけをテストすることはよくあります。この方法を使用すると、膨大なデータを管理しやすい量に簡単に整理できます。インベントリ全体に対する "赤" のドキュメントの割合は大抵 5 ~ 20% です。検出量のわずか 5% にインベントリを整理できるなんて、素晴らしい検出プロセスの使い方のように聞こえますね。

しかし、このアプローチには欠点がいくつかあります。前に説明したように、最も重大な欠点は、OMPM は "変換" に関する問題を示すもので、赤のドキュメントが Office 2010 で動作するかどうかを判断するための情報は提供しないという点です。また、"赤" のドキュメントだけに焦点を当てることでドキュメントの重要性が無視され、赤のドキュメントすべてが同じように重要である (つまり、テストする必要がある) と見なされます。時間を短縮していると思い込んでいるだけで、実際は時間を無駄にしています。変換に関する問題があるドキュメントに焦点を当てている可能性がありますが、ビジネス価値がもたらされることはないのです。最後に挙げるのは、この方法で OMPM を使用すると誤った安心感が生まれてしまうという点です。確かに赤の問題のみが発生していると報告されたドキュメントに焦点を当ててテストしていますが、Office 2010 で "ドキュメントが動作する" かどうかを判断しやすくなっているとは言えません。

調査によると、企業が Office 2010 の展開の準備にかける期間は 12 ~ 18 か月ということです。つまり、新しいバージョンの Office を展開することが決定してから、エンドユーザーが実際に使用するまで、最大で 1 年半かかる可能性があります。その準備期間のほとんどが、OMPM を使用して、時間 (そしてコスト) がかかるドキュメントを評価することに費やされます。事実、Office 2010 アップグレードの前に OMPM を使用しなければ、より迅速に、かつ低コストで展開することができます。さらなるリスクが生じることもありません。

OMPM とマクロに関する問題

OMPM の 2010 バージョンに新しく追加された機能は、"マクロに関する問題" を特定するツールです。つまり、このツールは、このオブジェクト モデルに関する考えられる問題の合計数と、64 ビット互換性に関する考えられる問題の合計数の 2 つのデータ ポイントを提供します。

"オブジェクト モデルの問題" は、OMPM レポート ツールに [Functionality Issue Count] として表示され、前のバージョンの Office から削除、変更、または廃止されたマクロ コードのアイテムの合計を集計します。"64 ビットに関する問題" は、[Compatibility Issue Count] として表示され、"64 ビット版 Officeで安全" として明示的に示されていないすべてのマクロ コード宣言の合計を示します。

多くの人がこの強化機能による分析は非常に有用で、展開前に確認する必要があると考えています。たとえば、機能に関する問題が 88 個、x64 互換性に関する問題が 3 つ存在したドキュメントを Office 2010 で使いたいとは思わないでしょう。ドキュメントを使うかどうかは次の情報によって判断します。

  • 64 ビット版オフィス 2010 を展開するかどうか
  • その問題が重大か無害か
  • 一番重要なのは、ビジネスにとって重要なドキュメントかどうか

64 ビット版 Office 2010 を展開しない場合、OMPM レポート ツールの [Compatibility Issue Count] 列のデータはすべて無視しても構いません。この状況では価値はなく無駄だからです。

[Functionality Issue Count] のデータは、削除、変更、または廃止されたオブジェクト モデル アイテムの集計です。影響力の少ないアイテムがほとんどですが、中には大きな影響力を持っているものもあります。これは、どのように見分ければいいのでしょうか? 残念ながら OMPM では区別されないので、データを見ても手掛かりはほとんど得られません。オブジェクト モデルの変更がマクロにどのように影響を及ぼす可能性があるかどうかの詳細については、「潜在的な影響がある Office 2010 オブジェクト モデルの変更について」を参照してください。

最後に挙げるのは、OMPM では機能または x64 のマクロに関する問題が一番多いドキュメントを判断できますが、そのドキュメント/マクロがビジネスにとって重要かどうかを判断できないという点です。ビジネス価値をもたらさないドキュメントのテストおよび修正サイクルに時間を費やすのは無駄です。このため、マクロに関する問題の数に基づいてテスト対象のドキュメントを整理すると、効率が悪くなることはよくあります。

Office ドキュメント検出の推奨アプローチ

この記事のほとんどの部分がすべきではないことについて説明していますが、それ自体あまり役には立ちません。ドキュメントおよびマクロの検出に OMPM を使用するのが良くないのであれば、一体何が良いというのでしょうか。まずはエンドユーザーから始め、そして、顧客について検討していきましょう。Office の大きなメリット (そして課題) は、エンドユーザーが Office を使用して独自のソリューションを構築でき、その Office ソリューションを管理するのが IT 組織ではないという点です。さらに、企業の多くが IT 組織に Office ドキュメントの管理を任せていないので、IT 部門は、Office ドキュメントがビジネスを行ううえで重要であることをほとんど理解していません。

プロジェクト マネージャー、関係マネージャー、または指定されたビジネス リーダーと協力してビジネスに不可欠なドキュメントを特定する方が、OMPM を使用して環境全体をスキャンして誤ったデータに焦点を当てるよりもずっと効率的です。この提携は、他の IT イニシアチブとプロジェクトに対して利用することもでき、環境での制定変更の迅速化にも役立ちます。

互換性プロジェクトのほとんどが、プラットフォームにかかわらず、"リスト作成、整理、テスト、および修正" のフローを使用します。Office では、検出に OMPM を使用し、"黄色" または "赤" でフィルタリングしたうえで整理し、より小さなサブセットに対してテストと修正を行うのが論理的であるように見えます。ここでうっかり誤った条件に基づいてリストを整理しているのです。これは、車を買うときに色を最優先にするようなものです。"ねえ、あなた。この青の車のリストから好きなものを選びましょうよ。" というのはいかがなものでしょうか。見当違いのデータ セットに対してテストや修正を行ってもリスクは軽減されません。それどころか、正しいデータにフォーカスを当てていないので、かえってリスクは大きくなります。

最初にビジネス部門と連携して重要なドキュメント/ソリューションを特定することで、検出と整理を同時に行う効率的な手段が提供されます。これは、データが生成されるそばからビジネス部門によって検証されるからです。その結果、効率性が向上して時間の短縮とコスト削減が実現し、さらに、適切なデータに焦点を当てることによりリスクが少なくなります。

まとめ

OMPM は、特定のタスクに適した非常に優れたツールです。"OMPM を使用してドキュメント変換に関する問題を見つけ、そのデータに基づいて、Office 2010 の展開後にドキュメントを変換する必要があるかどうかをビジネスの観点から判断する"、これは投資の価値を引き出し、コスト削減を実現する手段としては素晴らしいものです。OMPM を使用して見当違いの質問に回答することは、アップグレード プロジェクトのコスト増加と効率性の低下につながります。これによりビジネスのスピードが鈍り、Office 2010 によってお客様にもたらされる生産性のメリットにも遅れが生じます。

詳細情報

この記事の概念の詳細については、1 時間のビデオ「Solving Office Compatibility to Accelerate Office Deployments (英語)」を参照してください。このビデオは、米国カリフォルニア州アナハイムの Microsoft SharePoint Conference で録画されました。ビデオの概要を以下に示します。

Office ファイルとソリューションの互換性により、Office アップグレードの計画を開始する組織で懸念が生じます。この懸念により、展開プロジェクトが延長され新しいバージョンの価値の実現が遅れることはよくあります。展開プロジェクトを予定どおりに進めるにあたり重要なのは、適切なプロセスとツールを正しく利用して、潜在的なリスクを認識することです。このセッションは、時間とコストがかかる評価、未知への恐れ、コストの増加に対して適切なアプローチで取り組む方法を示しています。Office 互換性チームに問い合わせて、プログラムおよびリソースを利用する方法を学習し、Office 2010 またはOffice 365 クライアントの展開を円滑に進めてください。

リンク

OMPM の使用 (パート 1) - ドキュメント変換候補の特定および記憶域の節約量の予測
OMPM の使用 (パート 2) - 一括変換の実行

これはローカライズされたブログ投稿です。原文の記事は、「Using OMPM Part 3 – Are there other uses for OMPM?」をご覧ください。