バージョン8までのIEは、Microsoftが暗に独自性が高いことを認めているブラウザです。
同じHTML/CSS/JSであっても、バージョンごとに異なる仕様として動作することがあります。このため、上位のバージョンのIEで動作させるには「ドキュメントモード」いう機能を利用しなくてはいけません。
IEは、過去のレンダリングエンジンを再現させる機能を持っており、IE8からはドキュメントモードという名称で提供されています。Windows 9x/XP世代のWebシステムは多くの場合、IEのドキュメントモードを利用することで維持できているという状況です。
(※参考 : ドキュメント互換性の定義 - Microsoft )
しかし、IE11からはこのドキュメントモードが非推奨となり、今後サポートされなくなる可能性があります。現在のWindows8系OSのIEの最低バージョンである10は、2015年中旬でサポートが切れるため、今後のクライアントOS移行では実質的にドキュメントモードが利用できなくなってしまいます。
(※参考 : ドキュメント モードの非推奨 - Microsoft )
つまり理論上、IE8以下向けに作られたWebシステムは、Windows 7のEOLである2020年1月14日までに、相互運用可能なブラウザであるIE9以上向けに移行しなくてはいけません。
企業内の標準ブラウザとしてIE8を利用している場合、新規開発されるWebシステムも8向けになってしまいますので、早急にIE9以上へアップグレードする必要があります。Windows 7のEOLは2020年1月ですが、OS自体のアップグレードが早めに行われることを考えると、全くと言って良いほど時間がありません。
また、IE9以上を標準ブラウザとしていても、ドキュメントモードを利用しているレガシーWebシステムを移行を行わなくてはいけません。IEは独自実装は廃止し、古いWeb標準はある程度サポートするという方針のようなので、シンプルな仕組みで作られていた場合は、多少のレイアウト崩れ程度で動くかもしれません。ただ、Windows 8移行時直前に出来るほどリスクが低くないため、早めから意識する必要があるでしょう。
これらの対策が十分でない場合、クライアントOSのアップグレード時にシステムが動かなくなり、泣く泣くサポート切れの状態でWindows 7を保守し続けなくてはいけないという状況に陥ることが予想されます。
IE8向けWebシステムを作る際の対策
Windows 7のIEの最低バージョンは8であるため、今後もIE8向けWebシステムを新規で開発しざる得ない場合があるでしょう。IEは1OS上にマルチバージョンのインストールが許容されません。したがって、以下のような対策が必要になります。
★ 1. IEをアップグレードする。
IEをアップグレードするという、技術的に見ればベストな手段です。
ただし、IT運用の予算枠にIEのアップグレード分を追加して貰わなくてはいけないという問題があります。ユーザ企業側にこのような技術的課題への理解があり、トータルコスト最適化のために対策に乗り出そうとしている場合はスムーズに話が進むかもしれませが、単独にてシステム開発を受注した場合、この方法は採用しにくいでしょう。技術面でのベストな手段が、大人の事情からベストにはなり得ないという耳が痛い話です。
★ 2. Windows 8以上への移行日までをシステムのサポート期間とする。
Windows 7のEOLである2020年1月14日に移行期間を含め、2019年1月あたりまでをサポート期間としてしまう作戦です。
開発に1年かけたとして、5年維持できないという短命なシステムを開発します。システム化対象のサービス(業務)がPPM的に「問題児/花型」なステータスであれば、短いライフサイクルで改善が進むため問題は小さいかもしれません。しかし、「金のなる木/負け犬」の場合は現実的な選択とは言えません。最終的に移行時期に画面周りを全部改修して一斉移行するリスクを考えても、得策とは言えないでしょう。開発ベンダ側にとってはお得感がありますが、ユーザ企業にとってはトータルコストが大きい迷惑な方法と言えます。
★ 3. IE8とIE9以上(FireFox/Chrome)で動くように作る。
IE8とIE9以上(Firefox/Chrome)で動くように対策し、テストするという作戦です。
IE8向けには条件付きコメントやユーザエージェントによる検出を行い対策し、IE9以上には機能/動作検出型の開発をすることで、Windows 7のEOLに縛られないライフサイクルを確保します。当然ですが、普通に開発するよりもお金がかかります。Javaのようなキレイなやり方とは言い難く、マネジメントでの可視化も難易度評価も難しい、泥臭い方法になります。ユーザ企業側がこの問題を理解している場合、開発ベンダ側は要件フェーズで明確にスコープ定義をしておかないと、なし崩し的に対策を行う必要が生じ、火を吹く可能性があります。当然ですが、このような問題に対してはベンダ側からユーザ企業へ、IE8特化システムのリスクを事前に説明し理解を得る必要があるでしょう。
★ 4. Firefox/Chromeのみ対応にする。
IE向けに作ることを諦めるという作戦です。
しかし、エンタープライズ用途で利用されることを前提としているIEだからこそ受けられる恩恵、例えば長い期間のサポートを受けられなかったり、IT管理者によるActive Directoryなどの機能を使った統合管理が一切使えなくなります。Windows依存との完全な決別です。Windows 7時代はこのような方法は全く無いというわけでも無さそうですが、セキュリティ管理がいい加減になりやすいため、IT管理者側でも追加でセキュリティ強化ツールを選定するなど、IE以上に注意深く監視をする必要があります。
Firefoxに限定するなら、以下のページで開発のポテンシャルを確認できます。
＞＞ Firefox向けWebシステム開発でできること・できないこと - ふろしき.js
なお、Firefoxの場合は、法人向けに標準化対応を行うサービスも提供しています。Webシステムのフロントエンド部分について、ライフサイクルを長期に渡り動作させれるというのは魅力的かもしれません。
＞＞ 法人向けサポートのご案内 - Mozilla
