blog の更新をサボって早一年以上。たまにお客様にお会いすると、「blog もう更新しないんですか？」とかよく聞かれるのですが；、最近は Windows 8 タブレットアプリ開発に全力投球していたのでそれどころではありませんでした；。が、ようやく半年ぐらい苦しんでそこそこ軌道に乗ってきたので、ちょっと気分転換も兼ねて blog を書いてみようかと思ったりします。お題は IE ブラウザの互換性問題の緩和方法です。
そもそもこの記事を書こうと思った経緯は、あるお客様でこんな話を相談されたからでした。
「ブラウザを IE から別のブラウザに乗り換えたいと言っているお客さんがいる。理由としては、以前、クライアントの更改時に IE のバージョンアップに伴う再検証作業に恐ろしいコストがかかった��め。他社製ブラウザだったらそういうことが起きないと思うので、IE から乗換をしたいと言われている。何か助言をもらえないか？」
ええええ；；、それはあり得ないでしょう；、と思ってしまったのですが、その後いろんなところで話を聞いてみると似たような話が次々と出てくるので、おそらくこれはきちんと現場に情報が伝わっていないのだろうと思った次第。実はマイクロソフトも様々な情報を出してはいるのですが、ぶっちゃけ情報の正確性を意識するあまりどの説明も難しくなりすぎているので、誤解を恐れずにポイントだけをざっくりまとめてみよう、というのがこの記事の趣旨です。
- 現在のブラウザを取り巻く環境
- IE のバージョンの変遷
- IE のドキュメントモード（レンダリングエンジン）
- レスポンス HTTP ヘッダーによるドキュメントモードの調整方法
- （参考）リクエスト HTTP ヘッダー／サーバ側の挙動／ブラウザ側での解釈
- クライアント OS やブラウザのバージョンアップに対する戦略
- OS やランタイムのバージョンアップをなるべくラクにするために
- Rapid Release 時代の到来による変化と対応の考え方
それでは早速スタートです^^。
［現在のブラウザを取り巻く環境］
改めて言うまでもないですが、昨今の IT 環境の進化はものすごく速いです。例えば今や IT 業界を席巻しているタブレットの急先鋒である iPad が発売されたのは 2010 年 5 月、つまり今からたったの 4 年前。ブラウザの世界もまた非常に進化が激しく、HTML5 や CSS3 などの進化は目覚ましいものがあります。こうした中、ブラウザ各社はいち早く新機能を市場に提供するために、リリースサイクルをどんどん短くしていくことになりました。Wikipedia の情報を元に、各社のリリースタイミングをざっと表にまとめてみると、以下のようになります（半年ぐらい前にまとめたのでちょっと情報が古いのはご愛嬌；）。
時系列順に書き換えてみると、以下のようになります。
表を見て、「えっ？ Chrome ってそんなに頻繁にバージョンアップしてるの？」と思われた方もいるかもしれませんが、Chrome などはサイレントアップグレード（特にユーザに通知することなく最新版に自動的にアップデートされる）になっており、ユーザの方々が意識することなくアップデートが行われるようになっています。これに対して、IE や Safari はバージョンアップサイクルを比較的長めに取る傾向があり、概ね 1 年に一度（最近はもう少し短くなる傾向があります）のアップデートになっていたりしますが、逆にこれらは大々的に取り上げられる傾向があります。……というより特にマイクロソフトは「新しい IE ってこんなにすごいんだぜ！」的なアピールをしまくるのでそうなっているような気もするわけですが；、とつぶやいてみる；。
こうした「素早いアップデートの提供」のことは “Rapid Release” と呼ばれていますが、こうした Rapid Release は諸刃な側面があります。つまり、最新機能を市場に素早くリリースできる一方で、新機能追加などによるデグレード問題への対処や対応が難しくなる。ブラウザ各社は、下方互換性を取りながらどのようにバグ修正や新機能を織り込んでいくのかに関して、様々な苦労をしながら製品をリリースしています。
［IE のバージョンの変遷］
さて、おそらくこの記事を読まれている方々の多くは、「クライアント OS のバージョンをアップするときに、古い IE 用に作ったWeb アプリ資産をどうすればよいの？」という課題を抱えられている方ではないかと思います。それにお答えする前に、ちょっとだけ、IE のバージョンの変遷についてまとめてみたいと思います。あまり古い話をするとキリがないので、Windows XP 世代以降の話に絞って書きだしてみると、次のようになります。おおまかにいえば、IE のバージョンアップの多くは新 OS リリースに同期して行われてきました。
上記ではいろいろと書かれていますが、IE バージョンアップに伴うこれらの変更点の中で特に重要なのが、業界標準への対応強化という点です。特に昔の IE には、CSS 関連の実装に問題があったり、あるいは独自機能が多かったりと、業界標準仕様から外れているところが多々ありました。（簡単に言えば、HTML/CSS の標準仕様に厳格に対応させたブラウザと、IE ブラウザとの間で、同一の HTML/CSS の表示がまるで異なってしまう） Web 界隈ではこうした点が特に非難されたこともあって、マイクロソフトでは IE 8.0 あたりから業界標準への準拠を強めていくことになりました。
半面、このことは、古い IE 向けに作られた Web アプリのブラウザ互換問題を引き起こすことにつながりました。例えば、Windows XP 上の IE 6.0 向けに作られた Web システムを保有している際、クライアント OS を Windows 8 にアップグレードしようとすると、必然的に IE が 10.0 にアップグレードされてしまう。この時に、IE 10.0 で IE 6.0 向けに作られた Web アプリをそのまま表示させると、表示が崩れてしまう。確かに業界標準仕様への準拠を高めるという方針は正しいものの、既存システムを持つ会社にとっては、ブラウザのバージョンアップが頭の痛い問題になる、という課題を抱えているわけです。
［IE のドキュメントモード（レンダリングエンジン）］
こうした問題を緩和するため、Internet Explorer には IE 7.0 世代から、ドキュメントモードと呼ばれる機能が搭載されることになりました。誤解を恐れずに非常に簡単に言うと、新しい IE には、古い IE のレンダリングエンジンも搭載されている、というものになります。例えば IE11 には、IE11 の最新の描画エンジンだけでなく、IE10, 9, 8, 7 の描画エンジンも搭載されています。このため、例えば IE11 を使って IE7 用に作られた Web サイトを開く場合には、ドキュメントモードを IE7 に切り替えてやれば OK。そうすることで、IE7 と（ほぼ）同じ描画を行わせることができます。
このドキュメントモードの切り替えは、F12 開発者ツールの中で行うことができます（※ ブラウザのバージョンごとに若干方法が異なります）。ブラウザを開いている際に F12 キーを押していただくと、ブラウザ下部に開発者向けツールが出てきます。この中のエミュレーションタブの中にある「ドキュメントモード」を変更していただくことにより、描画エンジンを IE11～IE7 の範囲で切り替えることができます。（図中で “Edge” と書かれているのは、最先端のモード（このケースだと IE11 モード）を意味します。）
この MSDN blog の場合には、IE7～11 の範囲で描画エンジンを切り替えてもほとんど描画が変わらないと思いますが、例えば MSN などのサイトでは、レンダリングエンジンのバージョンを切り替えるとあっさり描画が崩れます。下図の左側が IE11 モードでの描画、右側が IE7 モードでの描画です。IE11 用として Web サーバから送られてきた HTML を、無理矢理 IE7 の描画エンジンでレンダリングしようと思っても、うまくレンダリングできないのは当然ですね^^。
これらのことからわかるように、IE で Web アプリを表示させる場合には、Web アプリ側が利用を想定している IE バージョンと、ブラウザ側で利用するドキュメントモードのバージョンとを揃えることが重要になります。このドキュメントモードに関しては、実は IE の変遷と共にモード数が増えていっています。下表は、各 IE がサポートするドキュメントモード（すなわち各 IE が保有するレンダリングエンジン）の一覧を示したものです。
ドキュメントモードについては、まず以下の点に注意してください。
- IE6 モードについて
ドキュメントモードが本格的に導入されたのは IE7 以降であるため、IE6 のレンダリングエンジンは現在残っていません。ですが、IE6 と 7 は比較的差が小さいため（業界標準適合のために大きく描画が変わっていったのが IE8 以降であるため）、IE6 向けに作られた Web サイトは、まずとりあえず IE7 モードで描画させてみるとよいでしょう。 - Quirks モードについて
これは特殊な互換モードなのですが、ちょっと難しいのでとりあえずは無視してよいです。本稿では説明を割愛します。 - IE12 以降での取り扱いについて
ドキュメントモードについては IE12 以降での取り扱いが変わることが決定しているため、今後の動向を見守る必要があります。これについては非常に重要なので、後述します。
また注意すべき点として、ドキュメントモードさえ変えれば過去の IE と完全に同じ挙動になるというわけではありません。例えば ActiveX コントロールに絡むセキュリティ強化などについては非互換要素があります。とはいえ、一番問題になりやすい HTML/CSS の描画問題（描画崩れ）について大幅に問題を軽減できるため、このドキュメントモードを利用して過去の IE と同様のレンダリングをさせるという方法は非常に効果的であると言えます。
［レスポンス HTTP ヘッダーによるドキュメントモードの調整方法］
とはいえ、このドキュメントモードの変更を個々のエンドユーザに行ってもらうのは非現実的ですし、��もそも Web アプリを作るときには、特定の IE バージョンに最適化させる形で作ることが多いと思います。このため、通常は Web アプリケーション側からブラウザに対して、「どのドキュメントモードでレンダリングさせるのか」を指定するようにします。具体的には、レスポンス HTTP ヘッダーに、以下の文字列を追加します。
ドキュメントモード | X-UA-Compatible |
IE7 標準モード | IE=7 |
IE8 標準モード | IE=8 |
IE9 標準モード | IE=9 |
IE10 標準モード | IE=10 |
IE11 標準モード | IE=11 |
動作を確認したい場合には、以下のようにしてください。
- Visual Studio を起動し、新規に空の Web アプリケーションをひとつ作成する。
- Default.aspx ファイルを追加し、下記のコードを追加する。 （見づらいスクロールでごめんなさい；）
1:<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="WebApplication1.Default" %>
2: 3:<!DOCTYPEhtml>
4: 5:<htmlxmlns="http://www.w3.org/1999/xhtml">
6:<headrunat="server">
7:<metahttp-equiv="Content-Type"content="text/html; charset=utf-8"/>
8:<title></title>
9:</head>
10:<body>
11:<formid="form1"runat="server">
12:<div>
13:ドキュメントモード <spanid="lblDocumentMode"></span>
14:</div>
15:</form>
16:</body>
17:</html>
18: 19:<scripttype="text/javascript">
1: 2: document.getElementById('lblDocumentMode').innerHTML = document.documentMode;
</script>
- web.config ファイルを追加し、カスタム HTTP ヘッダーを追加するための設定を追加する。
1:<?xmlversion="1.0"encoding="utf-8"?>
2:<configuration>
3:<system.web>
4:<compilationdebug="true"targetFramework="4.5.1"/>
5:<httpRuntimetargetFramework="4.5.1"/>
6:</system.web>
7:<system.webServer>
8:<httpProtocol>
9:<customHeaders>
10:<clear/>
11:<addname="X-UA-Compatible"value="IE=9"/>
12:</customHeaders>
13:</httpProtocol>
14:</system.webServer>
15:</configuration>
以上でアプリケーションを動作させてみてください。web.config 内に記述した設定に基づいて、ドキュメントモードが変わることが確認できるかと思います。
レスポンス HTTP ヘッダーへのカスタム HTTP ヘッダーの追加方法は、Web サーバごとに異なります。IIS の場合には上記のように web.config ファイルを利用しますが、Apache などでは設定が異なりますので注意してください。
［（参考）リクエスト HTTP ヘッダー／サーバ側の挙動／ブラウザ側での解釈］
ここまでが基本的な IE のレンダリングエンジンに関する説明なのですが、もう少し突っ込んだ解説をここではしておきたいと思います。（ちょっと難しいので、「うーん？」となってしまった方は、本項目は飛ばして、次の項目を読んでいただいて結構です。）
我々が開発する Web アプリ（特に業務用 Web アプリ）のほとんどは、どんなブラウザからリクエストが来ても、通常、全く同一の HTML/CSS を送り返します。しかし、Web アプリによっては、どのブラウザのどのバージョンからリクエストが来ているのかをサーバ側で判定し、送り返す HTML や CSS を切り替えるという機能を備えている場合があります。例えば MSN のサイトは、同一の URL でありながら、IE11 で呼び出した場合と、IE9 で呼び出した場合とで、全く異なるデザインのサイトが表示されます。（左側が IE11 で呼び出した場合、右側が IE9 で呼び出した場合）（← 右のスナップショットは IE9 じゃないだろ！ というツッコミはご容赦を；。本当は IE9 できちんとスナップを取りたかったのですがちょっと大変なので；；；。でもホンモノの IE9 で呼び出してもこんな感じの画面になります。）
呼び出すブラウザによって描画が変わる仕組みは、以下のようなものです。Web サーバに HTTP 要求を送る際、Web ブラウザは自動的に、自分のブラウザの種別やバージョンの情報をリクエスト HTTP ヘッダー（具体的には UserAgent ヘッダー）に含めるようになっています。我々が開発する Web アプリ（特に業務用 Web アプリ）のほとんどはこの情報を無視するため、どんなブラウザから来ても常に同一の HTML や CSS、JavaScript を送り返すのですが、MSN のようによく作り込まれた Web アプリでは、このリクエスト HTTP ヘッダーを読み取り、その情報に基づいて、クライアントに最適な HTML や CSS などを送り返すようになっています。このため、呼び出すブラウザのバージョンによって、大幅に画面が変わるということになるわけです。（ちなみに最近では、スマホからリクエストされた際に異なる HTML/CSS を送り返すように作り込まれた Web アプリが多くなってきていますが、仕組みはこれと似たようなものであることが多いです。）
このことは、以下のようにすると実験することができます。例えば、IE11 を利用しながらも、Web サーバに送出するリクエスト HTTP ヘッダーとして IE9 と同じものを使うと、Web サーバ側はやってきたリクエストが IE9 からリクエストされたものであると誤解します。そして、IE11 ブラウザに対して、IE9 に対して送り返すものと同じ HTML/CSS を送り返します。
具体的には、IE の F12 開発者ツールにおいて、エミュレーションタブの中の「ユーザーエージェント文字列」を、”Internet Explorer 9” に変更してみてください。IE11 でありながら、IE9 のときと同じ HTML/CSS をサーバから受け取ることができるようになります。
もちろん現実的に考えて、エンドユーザがこの F12 開発者ツールを開いてユーザエージェント文字列を切り替えて使う、ということはちょっと無理なわけで、あくまでこの機能は開発者向けの簡易デバッグツール（わざわざ古い OS や IE を用意しなくてもよくなる機能）だと考えた方がよいでしょう。ただ、それ以前のポイントとして注意していただきたいのは、ユーザーエージェントの文字列切り替え機能の利用は、そもそも Web サーバ側がユーザエージェント文字列を見るように作られていないと意味がない、という点です。先に説明したように、我々が開発する Web アプリ（特に業務用 Web アプリ）のほとんどは��どんなブラウザからリクエストが来ても、通常、全く同一の HTML/CSS を送り返します。このような場合、ユーザエージェント文字列を変更して、いくら Web サーバに「僕は IE9 だよ～」とアピールしても全く意味がありません。
ここまでの話をまとめると、以下のようになります。
- IE の下方互換表示で特に重要なのは、① ユーザエージェント文字列の切り替えと、② ドキュメントモードの二つである。
- ユーザエージェント文字列の切り替えを行うと、Web サーバに対して送出するリクエスト HTTP ヘッダーを変えることができる。
- 多くの業務系 Web アプリは、どんなブラウザからリクエストが来ても同じ HTML/CSS を返すので、リクエスト HTTP ヘッダーの変更は意味を為さないことが多い。
- ドキュメントモードを利用することにより、Web サーバから受け取った HTML/CSS をレンダリングする方法を変えることができる。
- 多くの Web アプリは、特定の IE バージョンから利用されるという前提で開発されている。このため、異なるバージョンの IE から呼び出された場合に備え、ブラウザで利用するレンダリングエンジンのバージョンを、X-UA-Compatible レスポンス HTTP ヘッダーで指定しておくとよい。
なお、ここでは話を簡単にするために、以下のような点の解説を省いています。より深い知識を得たい方は、以下のようなポイントについても学習するとよいと思います。詳細はネット上に情報が多数存在しますので、検索してみるとよいでしょう。
- 上記ではサーバ側からレンダリングエンジンバージョンを指定する方法として、レスポンス HTTP ヘッダーを利用する方法に絞って説明しました。この方法は、すでに作られている Web アプリに対して、後からまとめてドキュメントモードを一括指定したい場合に特に有効な方法です。しかしこれ以外にも、meta 要素を指定してページ単位にドキュメントモードを制御する方法もあります。
- 実際のブラウザ内では、かなり複雑なロジックに基づいてドキュメントモードが決定されており、しかもこれが IE のバージョンによって違います。少し古い資料ですが、例えばこちらのような資料を見ていただくと、その決定ロジックがかなり複雑であることがわかると思います。思ったとおりのドキュメントモードにならない場合には、こうしたロジックを少し深く調査していく必要があります。 （が、そうした調査は大変なので、業務 Web アプリではレスポンス HTTP ヘッダーをいじってしまうのが最も簡単だと思います。）
- 古い IE にはブラウザモードという機能が搭載されています。これはユーザエージェント文字列を切り替えると共に、ドキュメントモードの判定ロジックにも影響を与えるものになっています。
- IE には互換表示設定（互換表示リスト）という機能があります。これを利用すると、特定の Web サイトに対して送信するユーザエージェント文字列や、利用するドキュメントモードを調整することができます。例えば（本稿執筆時点では）、store.apple.com のサイトを呼び出す場合は、ユーザエージェント文字列として IE10 のものが、また描画には IE10 のドキュメントモードが自動的に利用されますが、これは互換表示リストに以下の記述があるためです。
<domain docMode="EmulateIE10" versionVector="10" uaString="IE 10" featureSwitch="overrideXUACompatible:false" trackingid="481134">store.apple.com</domain>
互換表示リストに関しては、hebikuzure さんのこちらのエントリが詳しいです。興味がある方は読まれてみるとよいかと思います。
［クライアント OS やブラウザのバージョンアップに対する戦略］
さて、ここまでドキュメントモードを利用したレンダリングエンジンのバージョン変更方法について解説しました。この機能を利用することにより、クライアント OS のバージョンアップやブラウザのバージョンアップは、何も考えずに IE をバージョンアップする場合に比べて随分とラクになるはずです。しかし、だからといって昔のレンダリングエンジンをいつまでも際限なく利用し続けようとか、あるいはこのドキュメントモードを使うのもイヤなのでいつまでも Windows XP を使い続けようとか、そういった考え方は決して正しくないと思います。これらはいずれも、汎用製品の宿命であるサポートライフサイクルというものを無視した考え方だからです。
マイクロソフトの製品は、業界の中で見れば比較的製品サポートの長い会社であり、さらに IE に関していえば、IE11 でも未だに IE7 のレンダリングモードを搭載しています。身内の人間だから言うわけではないのですが；、エンジニア的な目線だと、たまに「ここまでやっているのにまだ文句を言われるのか；；」と思ってしまう瞬間もやっぱりあります。もちろん私もエンジニアなので、「一度作ったアプリはなるべく塩漬けしてそのままそっと放置したい」という気持ちもわかるのですが、その一方で、先々のことを考えずにアプリのことを作りっぱなしにしすぎなんじゃないか？と思う瞬間も、やはりあるのです。
OS からミドルからすべて自作するとお金がかかります。だからこそ我々はコストを下げるために汎用製品を利用してモノづくりをするわけですが、そうである以上は、作ったタイミングから先々のサポートライフサイクルを想定し、自分たちのアプリのアップグレード戦略を考えておく必要があります。おおまかにいえば、このアップグレード戦略には以下の 2 つの方式があります。
方式①の、タイムリーに最新版の OS やランタイムに載せ替えていく方式は、昨今、Agile や Rapid Release などの普及に併せてよく取沙汰される方式です。インターネット上でコンシューマ向けサービスを展開している企業では、こちらの方式が利用されていることが多いでしょう。理由は単純で、こうしたシステムはそもそも頻繁にアプリのコードを書き替えているため、それに合わせて最新版のインフラに取り換えていくことが容易だからです。また、この方式を取る場合にはリリース頻度が自ずと増えるため、テスト実施の効率化（例えばテストの自動化など）についても積極的に取り組んでいることが多いでしょう。昨今、Rapid Release 方式を取り入れる製品が多くなってきたこともあり、コンシューマ系では否応なくこうした対応が求められてきています。
一方、業務系のアプリ、特にイントラネット系の業務アプリでは、②の方式、つまりある程度の期間塩漬けしておき、一気にアップグレードするという戦略を採っているケースの方が多いでしょう。こうした戦略を採る背景には、イントラネットであればクライアントのバージョンなどを固定化しやすい、再テスト工数などを極力減らせる、などがあると思います。しかしこの方式②の怖いところは、いざバージョンアップが必要になったときに対応が後手に回りやすいことです。実際の現場でよく見かける例を挙げれば、以下のようなことがあります。
- 徹底的に塩漬けを続け、サポートが切れる段階になって慌てて対応しようとする。（特に XP と IE6 に関してよく見られます）
- 移行時に最新インフラを選ばなかったり、移行検証に時間がかかりすぎてどんどん古くなってしまう。（XP から今さら Vista に移行しようという話があったりします……）
こうしたインフラのアップグレードがそう単純でないことは私も承知していますが、とはいえ対応が後手に回れば回るほど、追い詰められやすくなるのも事実です。特に、予め、サポート切れを見込んだ戦略を立てていなかったり、対応工数・コストを予算として積んでいないと、こうした問題は致命的になりやすいです。②の方式を採るのであれば、戦略なり予算なりをきちんと検討しておくことが欠かせません。
［OS やランタイムのバージョンアップをなるべくラクにするために］
実際の OS やランタイムの移行に際しては、本稿で説明している「ドキュメントモード」のように、移行時のデグレードリスクを極力下げるような移行方法を検討することが極めて重要です。特に、②のような移行スタイルを採る場合、何も考えずにそのまま最新の OS やランタイムに載せ替えれば、多くの場合は何らかの互換問題が発生してしまうはず。アプリ修正を完全に不要にすることはできないにしても、極力、修正量を少なくするような移行方法を検討するべきです。主な検討ポイントとしては、以下のような点が挙げられます。
- クライアント OS のアップグレード
- .NET デスクトップアプリであれば、極力同一の CLR を利用するように設定する。
- ブラウザアプリであれば、極力同じドキュメントモードを利用するように設定する。
- サーバ OS のアップグレード
- IIS が、極力同じ振る舞いをするように設定する。（アプリケーションプール、パイプラインモード、64 ビット化、CLR バージョンなど）
また実際に OS やミドルのバージョンアップを行った場合には、アプリの再テスト（デグレードテスト、リグレッションテスト）が必要になりますが、テスト戦略なしにフルパステストを再度行うようにしてしまっては、膨大なコストがかかってしまいます。これを避けるためには、以下のようなことをしておくことも欠かせません。
- アプリケーションのコード資産を、常に綺麗に整理しておく
- リグレッションテストをしやすいように、テストケースやテスト結果データなどをきちんと整理しておく
なお、再テストの容易化というと、真っ先にテスト自動化に飛び付こうとされる方がいらっしゃるのですが、それは必ずしも正しいアプローチではありません。例えば JUnit/NUnit などの単体テスト自動化ツールはそもそもコードのリファクタリングに対しては有効ですが、上記のような OS やミドルのアップグレードに対してはさほど有効とは言えません。また、UI レベルから行うテスト自動化ツール（例えば Coded UI Test など）は、打鍵の自動化はしてくれますが、結果検証に関しては不完全です（例：自動化ツールでは文字化けや画面崩れに気付けない）。むしろ、① テストの適切な分類、② テストケースの重要度の濃淡付け、③ 変更・修正インパクトに応じたテストケースの適切な選出ルール、などを決めて実施していくことの方が、圧倒的にコスト効果の高い再テストにつながります。昨今の開発現場のソフトウェアテストは場当たり的に実施されていることが少なくありませんが、まずそうしたやり方を実直に見直していくことも、OS やランタイムのアップグレードへの対応容易性を高める上で極めて重要です。
ちなみに、マイクロソフトはソフトウェアテストの専用ツールとして、MTM（Microsoft Test Manager）というツールを提供しています。Visual Studio に比べると知名度の低いツールではありますが、MTM を理解すると、正しいテストの在り方や効果的なテストの実施方法がどのようなものなのかを知っていくことができると思います。開発者の場合は、作ることに手一杯で品質保証まで手が回らないよ！ 的な方も多いでしょうが、���る程度モノづくりができるようになってきたら、こうしたソフトウェアテストに関しても知見を深めていくことをおすすめしたいです。とはいえ MTM の話は本題ではないのでまた機会を改めて。
［Rapid Release 時代の到来による変化と対応の考え方］
さて、今回なぜこのようなソフトウェアテストなどの話まで話題を広げて書いたのかというと、それは、今、多くの企業が OS やインフラのアップグレード戦略を見直さなければいけない時期に差し掛かっているからです。その背景にあるのが、Rapid Release 時代の到来です。下表を見てみてください。
（途中で Windows 98 の延命用 OS として Windows Me が出た等の例外を除けば）もともとマイクロソフトは、2～3 年に一度程度のサイクルで新しい OS をリリースしてきました。しかし 4 年前に発売された iPad というタブレットが PC 市場を一変させてしまったことからもわかるように、数年程度に一度というリリースサイクルでは、今の時代ではとても戦えないのが実情です。
いやいやそれはコンシューマの世界であってエンタープライズの世界（企業向けシステムの世界）では関係ないでしょう、と思われている方もいるかもしれませんが、それは誤りだと思います。歴史を振り返ってみれば、Windows を初めとする PC がメインフレームなどの大型コンピュータに取って代わったのと同じように、IT 業界のトレンドというのはコンシューマ市場から発生してくることが少なくありません。実際、スマホやタブレットの業務利用などはその最たるもので、コンシューマ市場においてユーザがその利便性に気付き、ビジネスへの応用を考える、ということがしばしば起こります（この現象は IT のコンシューマライゼーションと呼ばれています）。このことを考えれば、PC 市場で大きなシェアを持つマイクロソフトも、数年に一度といったのんきなペースで OS をリリースしているわけにはいきません。Windows 8 から 8.1 へたった一年でアップデートしてきたことも、こうした背景事情を考えれば必然的なものです。
しかし、こうした Rapid Release 時代への移行は、様々な変化を生み出します。例えばその一つが、IE ブラウザのドキュメントモードに関する方針変更です。実は IE11 がリリースされた際に、このドキュメントモードが deprecated 扱い（利用を推奨しない機能）に変更されました。ここまで IE は、バージョンが上がるごとに過去のレンダリングエンジンバージョンを残し続けてきたわけですが、すでに IE11 では 8 個ものドキュメントモードを持っており、このまま OS や IE のリリースのつどレンダリングエンジンを残すようにするのでは、製品サポートも含めて無理が出てきます。また、新しい IE では業界標準仕様に強く準拠するようになってきており、今までのように、マイクロソフトの独自仕様を残すためのドキュメントモードを残す必要性というのも昔に比べて減ってきています。さらに加えていうなら、昨今の Web 開発のトレンドを踏まえれば、ブラウザアプリは常に最新の業界標準仕様に追随すべきであり、ドキュメントモードを非推奨扱いに変えていこうという動きも、（インターネットの世界のトレンドだけ見れば）ある意味自然な流れともいえます。
その一方で、企業内のアプリがこうした頻繁なアップデートサイクルにリアルタイムで追随していけるようになるかと言えば、それはなかなか難しいと言わざるを得ず、実際には従来のような方式②、つまり適度な期間の塩漬けと最新版へのアップデートを繰り返す形になることが多いと思います。そうした方針がきちんと立っていないのであれば、この機会に、自社がどのようなアップデート戦略を採っていくのかを考えていく必要があるのではないでしょうか？
また、これに併せてぜひもう一つ考えていただきたいのが、本当に Web ブラウザが業務アプリの開発インフラとして最適なのかどうか？という本質的な問いかけです。業務アプリを開発する場合、OS やミドルが安定していて欲しい（＝変わらないで欲しい）というのは当然の要望だとは思いますが、ここまでの話からもわかるように、Web ブラウザというものは、そもそも業務アプリ開発用のインフラとして作られているものではなく、むしろコンシューマにおける利用を前提に、開発とアップデートが繰り返されてきているものです。これは、Windows 8 においても未だ VB6 ランタイムがインストールされていることと比べると、あまりにも大きな違いです。（今だと、CLR 2.0 ランタイムが VB6 ランタイムのように、かなり長い間に渡って残り続けそうなランタイムになりつつありますね。）
日本にはブラウザ神話とでも呼ぶべきものがあり、なんでもかんでも Web ブラウザ上に載せようとする傾向があるように思います。多数のテキストボックスが所狭しと詰め込まれた画面、Fn キーによる入力制御、ドラッグ＆ドロップ操作の多用、マルチウィンドウ制御、スプレッドシート処理などなど、開発生産性や保守性を度外視したような Web アプリが作られていることが少なくありません。こうしたアプリは、ブラウザのバージョンアップでの下方互換問題に当然ひっかかりやすいわけですが、根本的なところとして、そもそもそれは Web でやるべきだったのか？と言いたくなる場合もあります。RFP で最初から Web ブラウザに縛られているからといった具合にやむを得ないケースもあるでしょうが、頭ごなしになんでも Web でやろう、という発想は、今一度考え直すべき時期に来ているのではないでしょうか？
業務アプリケーション開発は、開発生産性や保守性など、様々な要素のバランスを取って行うべきもの。「作ること」だけを考えるのではなく、「保守すること」、すなわち OS やインフラのアップグレードにどのように追随していくのかを予め考えるようにしていただければと思います。
［まとめ］
いろいろと話が脱線しましたが、最後に要点をまとめると、以下のようになります。
- 古い IE のバージョン用に作られたアプリを最新の IE で動作させる場合には、ドキュメントモードを変更して動作させるとよい。このようにすることで、描画に関する非互換問題を最小化していくことができる。
- ドキュメントモードは、Web サーバから Web ブラウザに対して、X-UA-Compatible レスポンス HTTP ヘッダーを追加することで指示できる。Web サーバの設定を変更することで、アプリ全体に対してまとめて指定してしまうとよい。
- 企業システムにおいては、クライアント OS や IE のバージョンをどのように上げていくのかの戦略が必要である。特に、OS や IE の Rapid Release にどのように対応していくのかの指針を定めておくことが重要である。
- 実際のアップグレードを円滑に行うためには、特に以下の 2 点が重要である。
- OS や IE のバージョンアップ時のデグレリスクを最小化するために、ドキュメントモードをはじめとした互換設定をうまく利用する。
- デグレテストをなるべく容易化するために、テストケースやテスト結果データなどをきちんと整理しておく。
今回は話を簡単にするために、かなり解説を端折っていますが、この機会にもっとこの領域を詳しく知りたい！ もっと正確に知りたい！ という方は、ぜひ以下の資料も読んでみてください。コンサルティングサービスの森さん、長本さん、稲葉さんによる渾身の一作です。（実はこのエントリも、森さん・稲葉さんにレビューしてもらいました。お二方、本当にありがとうございました^^。）