準備は OK? サポート終了までに知っておきたい古い Internet Explorer 向けに作成された Web コンテンツの最新 Internet Explorer へのマイグレーション方法 - monoe's blog - Site Home

今年の 8 月にマイクロソフトの公式ブログでアナウンスがあったように、 2016 年 1 月 12 日からは、そのバージョンの Windows にインストールすることが可能な最新のバージョンの Internet Explorer だけがサポート対象となります。

そのため、Windows Vista や Windows 7、Windows Server 2008 を使用されている場合は、その時点でインストール可能な最新バージョンの Internet Explorer に切り替えていただく必要があります。

いままで、Windows のサポートは最新のサービスパックの適用されたものが対象でしたが、なぜか OS の一部であるはずの Internet Explorer はそうではありませんでした。しかし、これでようやく足並みがそろったことになります。

以下は 2016 年 1 月 16 日以降でもサポート対象となる Windows と Internet Explorer の組み合わせです。青太字の組み合わせは、OS の既定のバージョンの Internet Explorer ではありませんので、該当の Windows を既定の構成して使用している人は Internet Explorer をバージョンアップしておく必要があります。

このサポートポリシーの変更は一般のユーザーはそれほど影響は受けないかもしれませんが、企業ユーザーには大きなインパクトとなる可能性があります。

企業内で使用している Web ブラウザーをバージョンアップする場合、業務で使用している既存の Web システムが新しいバージョンの Web ブラウザーで正常に動作するか検証を行う必要があり、問題がある場合には修正作業が発生します。また、HTML5 に代表される新しい技術のサポートや Web 標準への準拠、今現在のインターネット上の脅威に対する安全性や信頼性の向上も期待されることでしょう。

このように、新しいバージョンの Web ブラウザーを採用する際には、きちんと過去の資産との互換を取りながらも、最新の技術もサポートしなければならないというジレンマを抱えることになります。

(新しい Web ブラウザーを採用する際のジレンマ)

今回の記事では、旧バージョンの Internet Explorer 向けに作成された既存の Web コンテンツを、新しい Internet Explorer で正常に動作するようにするためのマイグレーション方法を中心に、このジレンマをどのように解消していくかについて紹介します。

Web システムに対して動作保障を謳う限り、Web コンテンツ、あるいはそれらを閲覧するための Web ブラウザーに変更が生じた際には、正常動作を確認するための検証が発生し、問題が発生した場合には正常に動作させるための移行作業が発生します。

そのため Web ブラウザーと OS のバージョンアップの際には必然的に検証作業と移行作業が発生します。とくに、いままでのように特定の Web ブラウザーの特定のバージョンに依存した実装を行っていると、Web ブラウザーの仕様変更の影響を大きく受けるため移行作業の工数がかさんでいきます。

例えば、現在 Windows 7 を使用し、既定でインストールされている Internet Explorer 8 を使用しているユーザーが、Web ブラウザーを現在最新の Internet Explorer 11 にバージョンアップしたとしても Window 7 のサポート期間が 2020 年の 1  月 14 日までしかないので、東京オリンピック前には移行作業を行うことになります。

Web ブラウザーの移行作業を軽減するには

Web ブラザーをバージョンアップに伴う Web コンテンツの移行作業を軽減するには、特定の Web ブラウザーとバージョンに依存しない方法で Web コンテンツを作成します。具体的には、HTML5 からの Web 標準技術でコンテンツを作成することをお勧めします。

HTML5 ではそれまでの HTML の仕様で曖昧さがあった部分が払拭されており、かつ、ブラウザーベンダーも互いに情報をやり取りするなどして相互運用性を高める方向で実装が行われています。さらに、以前は Web 標準化されておらず、Web ブラウザーの独自実装機能を使用するしかなかった高度な機能も、多くの場合 HTML5 の機能のみで実装することが可能です。

また、HTML5 はブラウザーベンダーにまたがる Web 標準の仕様であり、理論的には Web ブラウザーの仕様や機能の変更に影響を受けることはないため、Web ブラウザーがバージョンアップされたとしても移行作業を小さくおさえることができます。

(現在サポートされている Windows と Internet Explorer の寿命)

検証作業はなくならない、絶対に

Web 標準に準拠した技術でコンテンツを作成することで移行作業を減らすことができます。減る、というのも控えめな表現で、各ブラウザベンダがきちんと相互運用性を確認しあい仕様を守れば移行作業自体が発生しない可能性も考えられます。

しかし、検証作業は別です。科学技術の著しい進歩、もしくは超自然的な力によって奇跡的に移行作業が発生しないとしても、その「移行作業は必要ない」ということを確認し証明するためにすべての動作検証を行う必要があります。

たとえば、担当している Web サイトが「最新バージョンの Internet Explorer と Safari、Firefox、Chrome をサポートします」と謳っている場合、それらの Web ブラウザーがアッデートされるたびに正常動作を保証しているすべての機能を検証する必要があります。

ちなみに Internet Explorer は現状、新しい Windows のリリースか、サービスパックのリリースのタイミングでバージョンアップが行われます。同じく Mac OS の既定の Web ブラウザーである Apple Safari は毎年の OS のバージョンアップのタイミングでされているようです。Internet Explorer、Safari のバージョンアップの間隔はそれなりにありますが、Mozilla Firefox と Google Chrome は 6 週間おきにアップデートされるのでこの 2 つの Web ブラウザーについて厳密に動作保障するとなると、6 週間間隔で検証を行う必要が出てきます。

(Web ブラウザーのバージョンアップの間隔)

検証作業を行う頻度の差はあれ、正常動作を保証する限りは、なにがしかの機能を変更したあとの検証作業はなくなることありません。それを理解して上手に付き合っていくことが肝要です。

検証作業と仲良く付き合うには

検証作業がなくなることはありませんが、作業にかかる工数を圧縮することで負担を減らすことができます。検証の品質を下げることなくかかる負担を減らすことができれば検証作業の発生は問題にはならず、実施の頻度をあげ品質を向上させることができます。

作業の効率化のために必要なこと

工数圧縮の基本になるのは作業の効率化です。必要な手順を必要にして充分な作業で行い無駄な作業と時間を削減します。そのために必要になるのは、どのよう方法があり、その方法に対してドキュメントやツールといったどのようなリソースが用意されているかです。

これらのものは大きく 3 つの整理することができます。

(Internet Explorer の移行作業を効率的に行うための 3 つのポイント)

1. ナレッジ

   作業の計画立案、手順についての正確な情報と、そこから導かれるベストプラクティスです。
   ベストプラクティスを得るためには目的に対しどのような情報が用意されているかを俯瞰的に把握しておく必要があります。
   新しい Internet Explorer 向けに Web コンテンツをマイグレーションするための資料としては以下のものが用意されています。

   
    
2. ツール

   目的の作業に対し、どのようなツールが提供されているか把握し、適切なタイミングと用途で使用します。ツールを有効に利用することで手動での作業に対し大きく効率を上げることができます。
   新しい Internet Explorer 向けに Web コンテンツをマイグレーションするためのツールとしては以下のものが使用されます。

   
    
3. 運用管理

   計画された作業、手順を明確に、「いつ」、「誰が」、「どのような作業」を行い、「現在はどのような状態であるか」を把握し、作業が適切に行われるよう管理します。
   検証 (テスト) の管理には Visual Studio 2013 の Premium 以上の Edition に含まれる Team Foundation Server が使用できます。

計画を立てる前の情報の収集は重要です。とくに Internet Explorer 11 移行ガイドは、最大公約数的ではありますが、当てはまるケースでのベストプラクティスとなっていますので計画を立てるまえに必ず一読することをお勧めします。

Internet Explorer のバージョンは Windows の既定の Web ブラウザーであるため、そのバージョンは Windows と関係しており、かつ、インストール可能な Windows のバージョンが複数にまたがる場合があります。この関係を利用して、Internet Explorer のバージョンを変えずに Windows を先にバージョンアップし、その後、徐々にバージョンアップした Windows にインストール可能な最新の Internet Explorer 向けにマイグレーションするという方法をとることができました。

(Windows のバージョンと Internet Explorer の関係)

たとえば、Windows XP の既定の Web ブラウザーは Internet Explorer 6 ですが、Internet Explorer 8 までバージョンアップすることができます。Internet Explorer 8 は Windows 7 の既定の Web ブラウザーです。Windows や Internet Explorer をバージョンアップする際にはこの関係を利用し、まず Internet Explorer 6 用に作られた Web コンテンツを Windows XP 上の  Internet Explorer 8 で動作するようにします。

次に OS を Windows 7 にバージョンアップし、Web コンテンツは Windows 7 上の Internet Explorer 8 で運用するようにします。

Internet Explorer 8 をバージョンアップするタイミングがきたら、Internet Explorer 8 用に作られた Web コンテンツを  Internet Explorer 11 で動作するようにし、Windows 7 上の Internet Explorer 11 で運用します。

そして、Windows 7 をアップデートするタイミングがきたら OS をバージョンアップし、 Windows 8.1 上の Internet Explorer 11 で Web コンテンツを使用するようにします。

このように Windows と Internet Explorer を交互にバージョンアップすることにより、移行にかかる工数やリスクを減らす方法がとられます。

2014 年 4  月 28 日に Windows XP のサポートが終了したこともあり、現在 (2015 年 3 月時点) のエンタープライズ領域のユーザーは、Windows 7 で  Internet Explorer 8 を使用しており、管理部門では、次の移行に備え Windows 7 上の Internet Explorer 11 もしくは Windows 8.1 上の Internet Explorer 11 の評価をしていると考えられます。

この状況を加味したのかどうかは不明ですが、Internet Explorer 11 からは、後方互換機能として従来のドキュメントモードに加え、Internet Explorer 8 をエミュレーションするエンタープライズモードという機能が搭載されています。 また、Windows 10 に搭載される新しい Internet Explorer および Prodect Spartan と呼ばれる新しい Web ブラウザーには、後方互換性を確保する目的で引き続き Internet Explorer 11 のレンダリングエンジンが搭載されるとのことです。
(2015/3/25 訂正 : 2015 年 月 24 日付けの IE blog の記事によればこの方針は変更され、Windows 10 に搭載される新しい Internet Explorer には引き続き Internet Explorer 11 のレンダリングエンジンが使用されるものの、Project Spartan には新規に開発された Edge レンダリングエンジンのみが搭載されることになりました。新しい Internet Explorer  では従来どおりの後方互換機能が使用できますが、Project Spartan は旧バージョンの Internet Explorer の後方互換機能はサポートされません)

上記の点を踏まえ、これから Web システムを新しい Internet Explorer へと移行を計画されている場合は、ターゲットは Internet Explorer 11 にすることをお勧めします。理由は、前述したように Windows 10 に搭載される新しい 2 つの Web ブラウザーで Internet Explorer 11 のレンダリングエンジンが搭載されるというのもありますが、(2015/3/25 訂正 :  Windows 10 に実質 Iinternet Explorer 11 と同じものが新しい Internet Explorer として搭載されるため)と、Internet Explorer 11 自体がすでに Web 標準に準拠した Web ブラウザーとなっているので、Internet Explorer 11 の Edge モードで正しく動作する Web システムであれば、Windows 10 に搭載される新しい Web ブラウザーでも、他のモダンブラウザでも正常に動作するはずだからです。

ここでは、Web システムを新しい Internet Explorer にマイグレーションする際の全体的なステップについて 3 段階にわけて紹介します。なお、ここで紹介する内容は Internet Explorer 11 移行ガイドの内容を簡易的に説明するものなので、そちらを読んでいただいても結構です。

1. 既存資産の情報収集 (インベントリ)
   インベントリとは「棚卸し」の意味があります。 業務で使用している Web サイト、アプリをすべて洗い出します。
   洗い出しには実際の業務担当者にインタビューを行い、業務に使用している全ての Web サイトやコンテンツを列挙してもらいます。
   サードパーティー製のアプリを使用している場合には、これからバージョンアップしようとしている Web ブラウザーに対応しているのか、または対応する方法はあるのかを、この段階で問い合わせます。
   
2. 優先順位付け
   使用している Web サイト、アプリの列挙が完了したら、洗い出したサイトやアプリの重要度を測り、優先順位を決めます。
   以下に、優先順位の判断の基準となる 3 つの例を挙げます。
   1. ビジネスインパクト
      業態や組織に対しどれくらいの影響をもっているのか
      例) E コマースシステムのように収益に関わるものであるか、従業員の勤怠システムのように間接部門的なものであるか
   2. 利用範囲
      Web システムの利用範囲を明確にして影響を測ります。
      例) 社内の少数のチーム内だけで使用されているのか、社外や顧客にまで使用されているのか
   3. 利用者
      利用者の属性と関わる業務を明確にし、影響を測ります。
      例) 従業員、顧客、協力企業など 、誰が利用しているか

   必要性や重要度については明確に重みづけを行うことをお勧めします。
   以下は、優先順位をつける際の分類方法の例です。

   1. 重要ではない
   2. あると便利
   3. 必要(クリティカルではない)
   4. 重要
   5. ミッションクリティカル

   気を付けなければいけないのは、重要度が高いからといって、優先度が必ずしもそれに準ずるとは限らないことです。重要度が高いからこそ、慎重に計画を立て一番最後に作業を行うということもありえます。優先順位についてはポリシーを含め充分に検討を行いましょう。

3. 計画と実施
   優先順位が決まったら実際にどのように作業を実施していくか計画を立てます、
   計画は大きく「暫定的な対応」と「中長期的な対応」2 つに分けることができますが、これらは完全に別々になるわけではありません。
   移行が必要になって、すぐにすべての Web システムの更新か可能であれば良いのですが、多くの場合そうではありません。
   場合によっては、Web サイトの対応が Web ブラウザーの入れ替えまで間に合わない可能性もあります。
   そういった場合には、暫定的な対応でとりあえず最低限動作するようにしておき、本格的な対応は中長期的なプランで考えます。

(全体的なマイグレーションステップ)

ここからは前出の 3 ステップから 3 番目の [計画と実施] についての部分をもう一段掘り下げて紹介していきます。

マイグレーション作業のステップを 3 段階にわけで紹介していきます。

1. トリアージ (影響調査によるマイグレーション対象の抽出)
   新しい Internet Explorer を使用して既存 Web システムの検証を行い影響の度合いを調べ、改修作業を行う対象を抽出します。
   この内容は 3 段階に分けることができます。
   1. 影響調査
      影響の度合いを調べレベル分けをします。
      以下はレベル分けの例です。 
      1. 実運用に支障をきたす(データが入力/視認できない等)
      2. 入力/視認は可能であるものの意図しない動作が発生する
      3. わずかなレイアウトの崩れなど

      このとき調査対象となっている Web システムが Internet Explorer ドキュメントモードや互換表示設定を使用していないか確認してください。ドキュメントモードを使用している場合は、Internet Explorer のどのバージョンを指定しているかを明確にしておいてください。

      また逆に、既に今回のマイグレーションを Internet Explorer のドキュメントモードで行うと方針が決まっており、バージョン間の非互換箇所の明確化が重要でないと判断できる場合は、あらかじめ想定されるドキュメントモードを設定して(現状 IE9 で使用しているので、ドキュメントモードをあらかじめ IE9 に設定しておく、など)おいてから検証を行っても良いでしょう。

   2. 切り分け
      影響が確認されたものに対し、新しい Internet Explorer 向けにコンテンツの修正が行えるものと行えないものを切り分けます。
      ここでは実際にコンテンツの修正を行うかどうかは別にして、事実として可能かどうかだけを判断してください。
      コンテンツの修正が行えないものについては以下のように理由を明確にします。
      1. サードパーティー製のパッケージ
      2. 構造が複雑で手が付けられない/予算工数が検討の余地がないほどかかる
      3. ActiveX、Java アプレット など
   3. 判断
      マイグレーション作業の対象とするものとしないものに分けます。
      マイグレーション作業の対象とならないものとしては以下のようなものがあります。
      1. 影響調査で問題が発生しなかった
      2. 影響はあったが軽微なもので実運用には問題ないと判断した
      3. ActiveX や Java アプレットで使用されており動作しない
      4. 使用を終了する予定である
2. 決定
   実施するマイグレーション方法を決定し、実施する優先順位を決めます。
   • 方法
     適用するマイグレーション方法を決定します。
     前述したように、既存 Web システムは Internet Explorer の後方互換機能を使用し、できる限り手を加えず新しいバージョンの Internet Explorer 向けにマイグレーションするのが一般的です。
     しかしながら、新しい Internet Explorer から搭載された新技術を使用したり、Internet Explorer 以外のモダンブラウザとのクロスブラウザ対応を行う場合には Web 標準に準拠するようコンテンツを書き直す必要があります。
     具体的にどのようなマイグレーション方法があるかについては、以降の Web コンテンツのマイグレーション方法を参照してください。
   • 優先順位
     トリアージによりマイグレーション対象となったものから ページ単位で作業を行う順番を決めます。
     優先順位のつけ方は前述のマイグレーションステップとその方法 の 優先順位付け の内容を参考としてください。
3. 実施
   マイグレーション作業を実施します。
   マイグレーションにはさまざまなやり方や組み合わせがありますが、基本的には以下の 3 とおりの方法しかありません。
   1. 新しいバージョンの Internet Explorer の仕様に合わせてコンテンツを書き換える
   2. Internet Explorer の後方互換機能を利用
   3. 仮想化

   上記 3 つの機能について、次の項で詳しく紹介します。

ここでは旧バージョンの Internet Explorer 向けに作られた既存の Web システムを、新しい Internet Explorer で動作させるためのマイグレーション方法について紹介します。

(マイグレーションの方法は 3 つに集約される)

新しい Internrt Explorer 向けのマイグレーション方法は、以下のように大まかに「書き換え」、「後方互換」、「仮想化」の 3 つに分けられます。

書き換え

既存の Web システムのコンテンツを新しい Internet Explorer 向けに書き換える方法です。コンテンツが新しい Internet Explorer 向けに最適化され、Web 標準準拠や HTML5 に代表される新機能が有効に利用できる等、メリットが多く理想的ではありますが、すでに正常に動作しているものに手を入れることへのリスクや、書き換えに工数がかかるなど、Internet Explorer の後方互換機能を利用する方法と比較してコストがかかる傾向があります。

コンテンツの修正作業で必要になるバージョン間における機能の非互換性を検出すめためのツールとして、Compat Inspector が用意されています。また、Compat Inspector の使用を補助するための Fiddler 用のスニペットも用意されています。

後方互換

Internet Explorer の後方互換機能を利用する方法です。書き換えと比較してわずかな改修で済む場合が多く、完全な書き換えにかかるコストに成果が見合わない場合に選択されます。また Internet Explorer の後方互換機能でカバーできない互換性の問題でも発生しないかぎり、基本的にはコンテンツそのものに手を入れる必要はないためデグレーション(リグレッション) 発生のリスクも低く抑えることができます。

Internet Explorer 11 には後方互換機能として、互換表示リスト、ドキュメントモード、エンタープライズモードがあります。

仮想化

ActiveX コントロールや古い Java アプレットの使用、特定の旧バージョンの Windows と Internet Explorer でしか動作しない場合には接続をイントラネット内に限定した仮想環境で運用することができます。

Internet Explorer のマイグレーション用というわけではありませんが、Windows で使用できる仮想化ソリューションとしては、Hyper-V や Virtual PC (Windows 7 まで)、Windows XP モード (Windows 7 のみ) があります。

しかしながら、この方法でサポート期間の終了した製品を運用し続けることはセキュリティ的に大きなリスクを抱えることになりますので、推奨できません。

また、仮想化は Web コンテンツのマイグレーションではないので、これ以降は紹介しません。

ここからは既存の Web システムを可能なかぎり変更せず、新しい Internet Explorer で正常に画面を動作させるための、Internet Explorer の搭載している後方互換機能について紹介します。

ドキュメントモード

ドキュメントモードは、以前のバージョンの Internet Explorer との描画の互換を保つために用意されている機能です。

HTML の meta タグが、HTTP のレスポンスヘッダーに Internet Explorer の任意のバージョンを指定すると、そのバージョンの Internet Explorer のレンダリングルールを使用してコンテンツの描画を行います。

(ドキュメントモードはレンダリングルールを
指定されたバージョンの IE のものに切り替える)

なお、Interntet Explorer 11 までのドキュメントモードが変更するのは、あくまでも「レンダリングのルール」のみであり、レンダリングエンジンそのものが切り替わるわけではありません。レンダリングエンジン自体は最新の Tritent (MSHTML.dll) が使用されます。

ドキュメントモードの指定

ドキュメントモードの指定は、HTML の場合は以下のように HTML 内の meta タグの http-equiv 属性に X-UA-Compatible を、content 属性に Internet Explorer のバージョンを指定するための設定を記述します。

(HTML でのドキュメントモードの指定)

Web サーバーで行う場合は HTTP レスポンスヘッダーに X-UA-Compatible という名前のフィールドを追加し、値に Internet Explorer のバージョンを指定するための設定を記述します。

(IIS web.config でのドキュメントモードの指定)

HTML と HTTP のレスポンスヘッダーに異なるバージョンの指定があった場合には、より表示に近いほうのが設定を上書きするので、HTML の設定が有効になります。

ドキュメントモードに指定可能な値

ドキュメントモードでバージョンの指定に使用可能な値は以下の表にあるとおり X-UA-Compatible の値として指定可能な値は 5 ～ 10 までの数字と、その先頭に EmulateIE がついた EmulateIE7 ～ EmulateIE10、edge です。

数字は、レンダリングルール使用する Internet Explorer のバージョンで、edge は使用している Internet Explorer 標準のレンダリングルールを使用することを示しています。たとえば Internet Explorer 11 でアクセスした場合は Internet Explorer 11 のレンダリングルールで、Internet Explorer 10 の場合は Internet Explorer 10 のレンダリングルールを使用します。

バージョン番号のみの設定と “EmulateIE” + バージョン番号の設定の違い

X-UA-Compatible に指定可能な値で、Internet Explorer のバージョンを示す数字の前に EmulateIE という記述のある/なしは、DOCTYPE 宣言での互換モードを処理するか無視するか、の違いです。

EmulateIE では DOCTYPE 宣言での互換モードを考慮し、DOCTYPE 宣言が正しくないか、指定された HTML のバージョンが古い場合は Internet Explorer 5.5 との互換である Quirks モードでレンダリングを行います。バージョン番号に EmulateIE がつかない場合は DOCTYPE 宣言の指定を考慮せず、指定されたバージョンの Internet Explorer  のレンダリングルールで描画します。

DOCTYPE 宣言

DOCTYPE 宣言による互換指定は、まだ Internet Explorer にドキュメントモードが搭載される以前、Internet Explorer 6 から、前バージョンの Internet Explorer 5.5 との互換を取るために搭載されました。指定可能なモードは「標準」と「互換」の二つがあり、「標準」を指定した場合は使用している Internet Explorer のバージョンで描画を行い、「互換モード」もしくは DOCTYPE の宣言がない場合は  Internet Explorer 5.5 に合わせた Quirks モードで表示をします。Quirks モードでは、Internet Explorer 5.5 で誤って解釈していた部分は、誤ったままで表示します。文法ミスがあっても適当に解釈して表示します。

(HTML4.01 の DOCTYPE 宣言)

とくに Internet Explorer 5.5、6 では CSS の解釈が大きく異なることがあったので、古い Internet Explorer 向けに作られたコンテンツでは指定されていることがあります。 (とはいえ、Internet Explorer 5.5 がリリースされたのは 2000年 7 月 なので、その時代のページがどれくらい残っていて、かつそれを考慮する必要があるか別途判断する必要があります)

ではなにが「標準」として解釈されなにが「互換」として解釈されるかは以下のような条件になります。

(DOCTYPE 宣言による互換モードの判断)

なお、Internet Explorer 10  以降では Quirks モードの扱いが変更され HTML5 を意識したものになっており、それ以前の Internet Explorer のものとは動作が異なりますので注意が必要です。

ドキュメントモード、その他ドキュメント互換について以下のドキュメントをご参照ください。

エンタープライズモード

Internet Explorer 11 から新たに後方互換機能として、エンタープライズモードが追加されました。

エンタープライズモードは Internet Explorer 8 の振舞を再現するものです。類似の機能として、すでにドキュメントモードがありますが、ドキュメントモードが単純に過去の Internet Explorer のレンダリングルールで画面を描画するだけなのに対し、エンタープライズモードは Internet Explorer 11 上で Internet Explorer 8 をエミュレートします。

これにより、今まで描画ルールの変更だけでは対応できなかった細かな違いを埋めることができます。

(エンタープライズモードはレンダリングルールの変更だけでは
まかなえない部分に対応する)

エンタープライズモードの使用

エンタープライズモードを有効にするには 2 つの方法があります。グループポリシーを指定するか、もしくは、レジストリを直接書き換えるかです。

企業内ネットワークのように組織単位で設定を管理したい場合、グループポリシーを使用します。グループポリシーによるエンタープライズ モードの管理では、 2 つのポリシーを適用できます。一方のポリシーは、組織全体でエンタープライズモードを有効化して、エンドユーザーがそれぞれのエンタープライズ モード設定を任意に選択できるようにしたりするものです。これは Web アプリケーションのテストに使用することもできます。

(メニューバー [ツール] 内に [エンタープライズモード] メニューが表示れさる)

もう一つのポリシーでは、XML ファイルを使用し、指定した Web サイトにのみエンタープライズ モードを自動的に有効化する方法です。この方法でユーザーがエンタープライズモードの設定を行う必要がないので、ユーザー向けにメニュー オプションを有効化する必要はありません。

ただし、グループ ポリシーを使用できるのは Windows ドメインに参加しているコンピューターだけです。

家庭で使用しているコンピューターのように、Windows ドメインに参加していないコンピューターで、エンタープライズ モードを有効にするには、ローカル管理権限を持つユーザーアカウントで以下のレジストリ キーを追加設定する必要があります。

ただし、レジストリ キーを直接ユーザーに書き換えさせるのは危険ですので、適切なレジストリ キーを含む reg ファイルを作成し、それを実行するのが良いでしょう。

エンタープライズモード実行時のドキュメントモードの処理

エンタープライズモードが有効な状態で、ドキュメントモードが設定された Web コンテンツにアクセスした際は、エミュレートされた Internet Explorer 8 がドキュメントモードの処理を行うので Internet Explorer 11 のドキュメントモードとは処理内容が異なります。

この違いを利用し、Internet Explorer 11 のドキュメントモードでは互換性の問題が発生する場合には、エンタープライズモードでのドキュメントモードを試すことができます。

エンタープライズリストマネージャー

エンタープライズリストマネージャーは、 エンタープライズモードを適用する Web サイトのリストを作成するためのツールですが、ドキュメントモードの指定も行うことができます。この機能を使用すると、オンライン上にあるコンテンツのようにソースを編集してドキュメントモードの設定を行えない Web コンテンツに対してもドキュメントモードを適用することができます。

(エンタープライズリストマネージャーは
ドキュメントモードの指定も可能)

なお、エンタープライズリストマネージャーの指定で行われるドキュメントモードの処理は Internet Explorer 11 で行われるものと同じです。

エンタープライズモード、エンタープライズモードリストマネージャーの詳細については以下のドキュメントをご参照ください。

Windows 10 に搭載される Web ブラウザーでの後方互換機能の振舞いの変更

Windows 10 には Internet Explorer と Project Spartan と呼ばれるまったく新しい Web ブラウザーが搭載されます。この 2 つの Web ブラウザーは、ドキュメントモードの指定に対する処理の振舞いが従来の Internet Explorer と異なります。

Windows 10 に搭載される新しい Internet Explorer のイントラネットにおけるドキュメントモード設定に対する振舞いは従来どおりですが、インターネット上にある Web コンテンツに対してはドキュメントモードの指定は無視されます。

(Windows 10 搭載の Internet Explorer では
インターネット上のドキュメントモード設定を無視する)

インターネット上の Web コンテンツに設定されたドキュメントモードに対し、従来のように旧バージョンの Internet Explorer のレンダリングルールを適用するには、エンタープライズモードを使用するか、マイクロソフトが管理している互換表示リスト (Compatibility View list = CV リスト) に旧バージョンの Internet Explorer でしか動作しないサイトとして登録されている必要があります。

(エンタープライズモード、CV List を使用すると
インターネットでもドキュメントモードが有効に)

エンタープライズモードの使用は、クライアント側でしかコントロールできません。よって、Web サイト側で、ユーザーに対してドキュメントモードを使用させたいのであれば、互換表示リストに自サイトを登録するようマイクロソフトに依頼することになるでしょう。ただし、これについては、今後なにか別な対処方法がアナウンスされる可能性もあるので、実施については新しい Internet Explorer と Spartan の正式な仕様が公開されるまで待ったほうが良いでしょう。

互換性リストについては以下のドキュメントの内容をご参照ください。

ただし、Internet Explorer 11 の edge モードで正常動作する Web サイトにおいては、ドキュメントモードを使用する必要はないので、こういった処理も必要ありません。

新しいバージョンの Internet Explorer へ 既存の Web システムを移行する際、必ず行わなればならないのがバージョン間の非互換性の検出です。

Internet Explorer のバージョンごとの機能の変更点については、ドキュメントとしては以下が用意されているので、移行作業に入る前にどのようなことが書かれているのか、確認しておくことをお勧めします。

ツールとしては、非互換性機能の検出用として Compact Inspector が、さまざまな検証目的して modern.IE が用意されています。

ここからはこれらのツールについて紹介しします。

Compat Inspector

Compat Inspector は、Internet Explorer のバージョン間の非互換性を検出するためのツールです。

「ツール」と書きましたが、Compat Inspector は単独で動作するアプリケーションなどではなく CDN でホストされている JavaScript のライブラリです。

使用する際には、以下のように検証対象となる Web ページに js ファイルへの参照を記述します。

Compat Inspector を参照したページの右上には、赤、黄、青の三色のインジケーターが表示されます。

(Compat Inspector 使用の際に表示されるインジケーター)

インジケータをクリックすることにより、検出された情報を表示するページに遷移します。

(Compat Inspector の情報ページ)

検出結果ページの debug、Verify チェックボックスにチェックをつけ、F12 開発者ツールの JavaScript デバッガをアタッチしてページを更新することにより非互換機能使用箇所を検出することができます。

なお、Compat Inspector を使用した詳細なデバッグ手順について以下のドキュメントをご参照ください。

Compat Inspector は便利なツールですが、検証対象となるページ全てに参照を記述するというのは現実的ではありません。

既存の Web システムに使用されているページが何千何万とある場合は、Compat Inspector の参照タグを追記するだけでも大変な労力がかかりますし、システムを運用したままチェックすることもできません。

そういった問題を解決するには、Fiddler と Compat Inspector を組み合わせて使用します。

Fiddler

Fidder はプロキシ型と呼ばれる HTTP デバッガ アプリケーションです。Web サーバーとクライアントの間の HTTP パケットを傍受し、解析できるだけでなく、パケットの改ざんなども行うことができます。

(Fiddler はサーバーとクライアント間のパケットをキャプチャし
改ざんすることができる)

この機能を利用し、検証作業者の使用するコンピューターの HTTP パケットをキャプチャし、そこに含まれるすべての Web コンテンツに Compat Inspector への参照を一時的に書き込んでしまえば、検証対象の Web ページにいちいち Script タグの記述を追加する必要はなくなります。

Fiddler と Compat Inspector を組み合わせる具体的な手順については、以下のドキュメントをご参照ください。

また、Fiddler と Compat Inspector を使用した、Internet Explorer バージョン間の非互換性検出の一連の作業について、実際にデモを行っているセッションの動画がありますので、こちらも合わせてご覧ください。(0:25:02 からデモが始まります)

Fiddler そのものについての詳細は以下のドキュメントをご参照ください。

modern.IE

modern.IE は、マイクロソフトが提供する Web ページを検証するための Webサイトです。modern.IE で提供される機能は、一部のサードパーティー製のサービスを除き、無償で使用することができます。 また、modern.IEは、OS の種別を問わず、最新のモダンWebブラウザーから使用することができます。

(modern.IEのトップページ)

modern.IE については、既にこのブログでも詳細な記事を書いているので、あたらためて詳しい説明はしませんが、簡単に提供される機能と特徴を紹介します。modern.IEが提供するWebページを検証するための機能は以下の4つです。

1. Webページのスキャン
   指定した URL の Web コンテンツを解析し、不具合箇所、改善点とアドバイス、学習マテリアルの案内などをしてくれます。
2. クロスブラウザーの表示テスト
   インターネットのサーバー上で、Windows、Mac OS、Android、iOS、および、そこにインストールされる既定、およびメジャーな Web ブラウザーのセットのインスタンスを立て、URL で指定された Web ページを表示した際の画面ショットを取得し表示します。
   セットとして用意されていない OS と Web ブラウザーの組み合わせについては、マイクロソフトのパートナー企業がホストする BrowserStack  (※有償。ただし 90 日の試用期間あり) を使用することができます。
3. 最新のInternet Explorerとの互換性テスト
   URL で指定された Web ページに対し、サーバーサイドで Compat Inspector を実行し、その結果を返します。
4. 仮想マシンの提供
   Windows XP 以降の Windows OS と、各バージョンの Internet Explorer がインストールされた仮想マシンを提供しています。
   ユーザーは任意の組み合わせの仮想マシンをダウンロードし、ローカルの仮想環境で起動して検証作業を行うことができます。

modern.IE の詳細については、以下の記事をご参照ください。

また modern.IE が提供する Web ページのスキャン機能はオープンソースとして GitHub で公開されており、これをローカルで動作させることもできます。

modern.IE の Web ページのスキャン機能をローカルで実行する方法については以下の記事をご覧ください。

IT 管理者用のドキュメントとツール

ここまで、Internet Explorer の後方互換性の機能と、コンテンツを書き換えるためのバージョン間の非互換性検出機能、およびマイグレーション作業についてのドキュメントを紹介してきましたが、IT 管理者向けのドキュメントも用意されています。このドキュメントには Windows ドメインのグループポリシーを使用した Internet Explorer の展開方法など、大規模組織における Internet Explorer のアップデートを効率良く行う方法が記載されていますで、企業の IT 管理者は目を通しておくことをお勧めします。

また、ユーザーの利用している Web サイトの収集と分析用のツールも用意されていますので、こちらも適宜ご利用くださいませ。

ここからは旧バージョンの Internet Explorer 向けに作成された Web コンテンツを最新の Internet Exolorer 向けにマイグレーションする際に行う検証作業 (テスト) を整理するとともに、作業の管理と効率化について紹介します。

なお、ここで紹介する内容は最大公約数的なものとなっていますので、実施する際は実際の運用にあわせ、取捨選択してください。

Internet Explorer マイグレーションの際に行われる検証の種類

旧バージョンの Internet Exporer 向けに作成された Web コンテンツを最新の Internet Exolorer 向けにマイグレーションする際、実施される検証作業は大きく 2 つに分けられます。Web システムの機構的な「動作検証」と、Web コンテンツの「表示検証」です。

(IE マイグレーションで行う検証は、動作検証と表示検証の 2 つ
動作検証は自動化できる)

動作検証

動作検証は、演算やページ遷移などの動作を検証するものです。例えば、行われた操作や入力に対し、Web サイトやアプリケーションか想定された正しい結果を返すかどうかを確認します。検証すべき動作としては、ハイパーリンクの動作、UI のインタラクション、get、post に対するレスポンスなどがあります。

この検証は多くの場合ツールを使用して自動化することができます。

表示検証

表示検証は文字通り、Web ブラウザー内のコンテンツが、仕様のとおりに表示されているかどうかを確認します。検証対象となるのは、Web ブラウザー内に描画される Web コンテンツですが、業務系の Web アプリなどでは、Web ブラウザーの外観そのものも検証する場合があります。

Web コンテンツの描画は、Web ブラウザーのレンダリングエンジンやレンダリングルールのみならず、OS のグラフィックシステムや既定のフォント等の様々なものの影響をうけます。文字の折り返しや、数字の桁落ちなど、プログラムでは検証が難しいこと��ら目視で行われるのが一般的です。

表示の検証作業は、目視での確認が多くの場合必須となりますが、自動 UI テストツールに画面ショットを取得する機能がついているのであれば、取得された画像を確認することで画面表示までの手順を省略することになるので、検証にかかる工数を減らすことができます。

検証作業が行われるタイミングと頻度

Internet Exporer のマイグレーション作業において、検証作業の行われるタイミングは、事前調査での不具合の検出、開発/修正、リリース時と、おおまかに 3 つに分けることができます。

(すべてのタイミングにおいて同じテストケースを実行)

1. 事前調査
   調査段階での不具合発生箇所の検出を目的として、未修正の Web システムに対し、新しい Internet Explorer を使用してテストを行います。
2. 開発/修正
   調査で検出された不具合を修正、あるいは開発したもののテストを行います。このテストは事前調査で検出された不具合、および、それに対処するための開発/修正によってに発生する不具合が無くなるまで繰り返し行います。
3. リリース
   リリース前にすべてのテストをリリース対象となっているシステム全体に対して行います。

上記のタイミングで行われるテストはすべて同じテストケースを使用します。まれに「同じもので大丈夫ですか?」という質問をいただきますが、テストケースは仕様が変更されないかぎり同じものでなければなりません。なぜならば、テスト (検証作業) は、システムが仕様通りに動作していることを証明するためのものに他ならず、テストケースはそれを行うための装置だからです。よって、基本的に仕様が変更されない限りは、テストケースが変更されることはありません。

きちんと仕様に沿った精度の高いテストケースを、マイグレーション作業のさまざまなフェーズで使いまわすことにより、検証作業を効率良く行うことができます。

なお、精度の高いテストを行うには、仕様に正確に沿うことはもちろん、動作に対しての有効なカバレッジを持ったテストケースを作成しておくことが肝要です。

テストケースとは

検証作業に使用される環境、操作手順、使用するデータをまとめたものです。テストケースは仕様の実際的な動作を示すものであるため、仕様が変更された場合には、テストケース/テストコードにその変更を反映する必要があります。

テストケースを作る際には詳細で正確な手順とデータを用意することはもちろんのことカバレッジも意識する必要があります。

カバレッジ

ここで言うカバレッジとは、そのテストが保証しうる動作の範囲のことです。つまり、機能に対して発生しうる全ての操作のうちの何割をそのテストケースでカバーできるのか、ということです。プログラムコードのテストにおける目標となるカバレッジは 8 割です。ひとつのテストケースで目標となる割合を満たせない場合( 少なくとも正常系、異常系のテストケースは必要なので、ひとつで済むことはない)は、複数のテストケースを用意します。

検証作業の運用と管理

検証作業を効率よく運用するには、綿密な計画を立てるのはもちろんのこと、作業の実施状況をきちんと把握し管理する必要があります。

検証作業の管理の目的は、ひとえに要件に沿った検証の完了を保障することにほかなりません。テストケースと合わせ、作業状況を綿密に管理することにより検証作業の精度と効率を上げることができ、結果、サービスや製品の品質を向上に結びついていきます。

(検証作業の管理の目的は、要件に沿った検証の完了を保障すること)

テストケース、作業状況の管理、レポートの作成、ソース管理については、それらを統合したツールの積極的な使用をお勧めします。

テストスイート

Visual Studio 2013 の Premium 以上のエディションであれば付属の Team Foundation Server (TFS) のテスト機能を使用して、検証作業の計画から管理までをまかなうことできます。また、TFS の提供するコード化された自動 UI テストを使用すれば、Web システムの動作検証作業を自動化し、検証にかかる工数を大きく削減することができます。

Team Foundation Server (TFS)

Team Foundation Server (TFS) はソフトウェアをチーム開発するためのサーバー製品で、ソースコード管理からプロジェクト管理、ビルド、テスト、バグ情報を一貫性を保って一元管理することができます。テストケースを実行した際の作業内容をレコーディングして、あとで再生して実施状況を確認したり、バグ表のアサインやメンバー間のチャットなども行えます。

TFS についての詳細な情報については以下のページをご参照ください。

TFS によるテストケースの作成と実行についての具体的な手順は、以下のドキュメントをご参照ください。

テストケースを実行した手順を記録、再生する方法については、以下のドキュメントと、デモのビデオをご覧ください。

(TFS210 テスト再実行の効率化)

TFS のテスト機能についての詳しい使い方については、ステップバイステップの自習書がありますので、ぜひこちらをお試しください。

TFS はイントラネット内に管理用サーバーを構築して使用しますが、インターネット上にある Visual Studio Online を管理用サーバーとして使用することもできます。また、Visual Studio Online は Web ベースの UI をもっており、これを使用するとコンピューターに Test Manager (TFS のテスト用クライアントツール) がインストールされていなくても、テストケースの作成や管理、簡易的ではありますがテストケースの実行などが行えます。

Visual Studio Online については以下のドキュメントをご参照ください。

自動 UI テスト

Web アプリケーション向けのテストツールには、Web コンテンツへの UI への操作をプログラム的に自動化してテストする機能が搭載されているものがあります。自動 UI テストを使用することにより、Web ブラウザーを使用した手動での動作テストの工数を削減することができます。また、複雑な手順を実行する際の操作ミスを防ぎ、ステップごとの画面ショットの取得やレポートの生成も行えます。

とはいえ、自動 UI テストがすべてのケースに有効なわけでもありません。たとえば、自動テストを実行するためのレコーディングや、修正にはそれなりに時間と工数がかかります。よって短期間の開発やテストの回数が少ない場合には、手動テストのほうが効率的である場合があります。

自動 UI テストが向いているもの、向いていないものは以下のとおりです。

TFS の自動 UI テストツール

TFS にも コード化された UI テスト という名前で、自動 UI テスト機能が搭載されています。この機能は Visual Studio の Premium 以上のエディションに付属する TFS で使用することができます。

コード化された UI テストは、Web コンテンツに対し、手動で行った一連の操作をレコーディングし、実行可能な C#、もしくは VB のコードを出力します。レコーディング中にアサーションの設定もできるので、レコーディングしたままのテストをそのまま使用することができます。もちろん、出力されたコードを修正して使用することもできます。

TFS の コード化された自動 UI テスト については以下のドキュメントとデモの動画をご覧ください。

(コード化された UI テストによるユーザー インターフェイスのテストの簡単な実施)

自動 UI テストツールの使用を前提としたマイグレーションの流れ

古いバージョンの Internet Explorer 向けに作成された Web コンテンツを新しい Internet Explorer 向けにマイグレーションする作業において、自動 UI テストを導入すると、調査段階での不具合検出や、修正中の動作検証、その後の運用におけるメンテナンスにかかる工数を大幅に削減することができます。

自動 UI テストツールの導入を前提とした作業の進め方は大まかに以下のようになります。(なお、このシナリオは自動 UI テストツールが実行するコードが既にあるという前提となりますので、自動 UI テストを初めて導入する場合は、第一回目の検証は、自動 UI テスト用コードのレコーディングを兼ねた手動でのテストになるとご理解ください。)

1. これから新たに導入する新しい Web ブラウザーを使用して、未修正の既存の Web システムに自動 UI テストを実施します。
   
2. 既存の Internet Explorer で正常に動作しているものに対し、新しい Internet Explorer を使用してエラーになるということは、互換性に問題があるということに他ならないので、Compat Inspector を使用して問題箇所を検出し、修正作業を行います���

   

   このとき自動 UI テスト機能が取得した画面ショットを確認して、簡単な表示のチェックを同時に進めても良いかもしれません。
   
3. 修正作業が完了したら再び前回と同じテストを行い、エラーがあればまた修正してテストします。これを完全にエラーがなくなるまで繰り返します。

   

4. 自動 UI テストによる動作テストが完全に成功したあとに表示のテストを行います。
   コンテンツに表示崩れや桁落ちなどが発生していた場合は、Internet Explorer 互換性クックブック内にある CSS とレイアウトの互換性の変更点 の内容をもとに修正を行います。

   

5. 表示の不具合箇所の修正作業が完了したら再び前回と同じテストを行い、エラーがあればまた修正してテストします。これを完全にエラーがなくなるまで繰り返します。

   

6. 表示のエラーがなくなり、余裕があれば modern.IE のコードスキャン機能を使用して Web ページの構造をブラッシュアップしても良いでしょう。
   modern.IE のコードスキャン機能は GitHub からソースコードを入手してローカル環境でホストして使用することもできます。

   

   Web 標準、クロスブラウザー対応の Tips として、ドキュメント  クロス ブラウザー開発 標準と互換性のベスト プラクティス も用意されていますのでぜひこちらもごください。

Visual Studio 2013 Team Foundation Server テスト機能の採用事例

TFS の提供するテスト機能は、既にパートナー企業において大きな実績を上げています。以下の事例では、TFS のテスト管理機能とコード化された UI テスト機能の利用によりテスト 1 回あたりの作業負担が 1/3 ～ 1/5 に削減されたとのことです。

面倒な検証作業も、適切なツールを使用して工数を削減することにより、単に作業にかかる負荷を圧縮するだけでなく、品質を上げるためのツールとしてよう出来るようになります。

今回は、旧バージョンの Inrernet Explorer 向けに作られた Web システムを最新の Internet Explorer で支障なく動作させるためのマイグレーション方法について、計画の立て方から用意されているツールまでを紹介しました。

日本マイクロソフトでは、IE Camp と題して、上記で紹介したような Internet Explorer のマイグレーション方法についてのセミナーを月 1 回のペースで行っていますので、ぜひご参加いただければと思います。

新しい Internet Explorer への移行セミナー ～互換性に関する情報・対応例など最新情報をご紹介します～

○ 2015年４月16日（木）15:00～17:30 （受付開始 14:30） http://aka.ms/iecamp2
○ 2015年５月13日（水）15:00～17:30 （受付開始 14:30） http://aka.ms/iecamp3