更新をサボって早一年以上。タブレットアプリ開発に全力投球していたのでそれどころではありませんでした;。書いてみようかと思ったりします。ブラウザの互換性問題の緩和方法です。そもそもこの記事を書こうと思った経緯は、あるお客様でこんな話を相談されたからでした。別のブラウザに乗り換えたいと言っているお客さんがいる。バージョンアップに伴う再検証作業に恐ろしいコストがかかったため。乗換をしたいと言われている。思ってしまったのですが、その後いろんなところで話を聞いてみると似たような話が次々と出てくるので、おそらくこれはきちんと現場に情報が伝わっていないのだろうと思った次第。実はマイクロソフトも様々な情報を出してはいるのですが、ぶっちゃけ情報の正確性を意識するあまりどの説明も難しくなりすぎているので、誤解を恐れずにポイントだけをざっくりまとめてみよう、というのがこの記事の趣旨です。時代の到来による変化と対応の考え方それでは早速スタートです^^。環境の進化はものすごく速いです。進化は目覚ましいものがあります。した中、ブラウザ各社はいち早く新機能を市場に提供するために、リリースサイクルをどんどん短くしていくことになりました。情報を元に、各社のリリースタイミングをざっと表にまとめてみると、以下のようになります(半年ぐらい前にまとめたのでちょっと情報が古いのはご愛嬌;)。時系列順に書き換えてみると、以下のようになります。サイレントアップグレード(特にユーザに通知することなく最新版に自動的にアップデートされる)になっており、ユーザの方々が意識することなくアップデートが行われるようになっています。年に一度(最近はもう少し短くなる傾向があります)のアップデートになっていたりしますが、逆にこれらは大々的に取り上げられる傾向があります。こんなにすごいんだぜ!」的なアピールをしまくるのでそうなっているような気もするわけですが;、とつぶやいてみる;。諸刃な側面があります。最新機能を市場に素早くリリースできる一方で、新機能追加などによるデグレード問題への対処や対応が難しくなる。ブラウザ各社は、下方互換性を取りながらどのようにバグ修正や新機能を織り込んでいくのかに関して、様々な苦労をしながら製品をリリースしています。アプリ資産をどうすればよいの?」という課題を抱えられている方ではないかと思います。バージョンの変遷についてまとめてみたいと思います。世代以降の話に絞って書きだしてみると、次のようになります。リリースに同期して行われてきました。バージョンアップに伴うこれらの変更点の中で特に重要なのが、業界標準への対応強化という点です。関連の実装に問題があったり、あるいは独自機能が多かったりと、業界標準仕様から外れているところが多々ありました。あたりから業界標準への準拠を強めていくことになりました。アプリのブラウザ互換問題を引き起こすことにつながりました。アップグレードされてしまう。アプリをそのまま表示させると、表示が崩れてしまう。確かに業界標準仕様への準拠を高めるという方針は正しいものの、既存システムを持つ会社にとっては、ブラウザのバージョンアップが頭の痛い問題になる、という課題を抱えているわけです。世代から、ドキュメントモードと呼ばれる機能が搭載されることになりました。レンダリングエンジン(とほぼ同等のもの)も搭載されている、というものになります。描画エンジンも搭載されています。(ほぼ)同じ描画を行わせることができます。ブラウザのバージョンごとに若干方法が異なります)。キーを押していただくと、ブラウザ下部に開発者向けツールが出てきます。範囲で切り替えることができます。モード)を意味します。サイトでは、レンダリングエンジンのバージョンを切り替えるとあっさり描画が崩れます。描画エンジンでレンダリングしようと思っても、うまくレンダリングできないのは当然ですね^^。バージョンと、ブラウザ側で利用するドキュメントモードのバージョンとを揃えることが重要になります。変遷と共にモード数が増えていっています。保有するレンダリングエンジン)の一覧を示したものです。ドキュメントモードについては、まず以下の点に注意してください。レンダリングエンジンは現在残っていません。モードで描画させてみるとよいでしょう。モードについてこれは特殊な互換モードなのですが、ちょっと難しいのでとりあえずは無視してよいです。本稿では説明を割愛します。以降での取り扱いが変わることが決定しているため、今後の動向を見守る必要があります。これについては非常に重要なので、後述します。完全に同じ挙動になるというわけではありません。コントロールに絡むセキュリティ強化などについては非互換要素があります。ファイル(MSHTML.dll)しか持っておらず、その中での切り替えを行っています。互換を保証するものでもないし、再テストを全くしなくてよいというものでもない)。同様のレンダリングをさせるという方法は、ブラウザのバージョンアップの際には非常に効果的な手法であると言えます。バージョンに最適化させる形で作ることが多いと思います。アプリケーション側からブラウザに対して、「どのドキュメントモードでレンダリングさせるのか」を指定するようにします。ヘッダーに、以下の文字列を追加します。標準モードIE=11動作を確認したい場合には、以下のようにしてください。アプリケーションをひとつ作成する。ファイルを追加し、下記のコードを追加する。ヘッダーを追加するための設定を追加する。</configuration>以上でアプリケーションを動作させてみてください。内に記述した設定に基づいて、ドキュメントモードが変わることが確認できるかと思います。サーバごとに異なります。設定が異なりますので注意してください。レンダリングエンジンに関する説明なのですが、もう少し突っ込んだ解説をここではしておきたいと思います。(ちょっと難しいので、「うーん?」となってしまった方は、本項目は飛ばして、次の項目を読んでいただいて結構です。切り替えるという機能を備えている場合があります。呼び出した場合とで、全く異なるデザインのサイトが表示されます。いうツッコミはご容赦を;。スナップを取りたかったのですがちょっと大変なので;;;。呼び出してもこんな感じの画面になります。)呼び出すブラウザによって描画が変わる仕組みは、以下のようなものです。ヘッダー)に含めるようになっています。送り返すようになっています。このため、呼び出すブラウザのバージョンによって、大幅に画面が変わるということになるわけです。アプリが多くなってきていますが、仕組みはこれと似たようなものであることが多いです。)このことは、以下のようにすると実験することができます。リクエストされたものであると誤解します。変更してみてください。サーバから受け取ることができるようになります。用意しなくてもよくなる機能)だと考えた方がよいでしょう。サーバ側がユーザエージェント文字列を見るように作られていないと意味がない、という点です。~」とアピールしても全く意味がありません。ここまでの話をまとめると、以下のようになります。ドキュメントモードの二つである。ヘッダーを変えることができる。ヘッダーの変更は意味を為さないことが多い。レンダリングする方法を変えることができる。バージョンから利用されるという前提で開発されている。ヘッダーで指定しておくとよい。ここでは話を簡単にするために、以下のような点の解説を省いています。深い知識を得たい方は、以下のようなポイントについても学習するとよいと思います。詳細はネット上に情報が多数存在しますので、検索してみるとよいでしょう。ヘッダーを利用する方法に絞って説明しました。アプリに対して、後からまとめてドキュメントモードを一括指定したい場合に特に有効な方法です。要素を指定してページ単位にドキュメントモードを制御する方法もあります。バージョンによって違います。古い資料ですが、例えばこちらのような資料を見ていただくと、その決定ロジックがかなり複雑であることがわかると思います。思ったとおりのドキュメントモードにならない場合には、こうしたロジックを少し深く調査していく必要があります。ヘッダーをいじってしまうのが最も簡単だと思います。ブラウザモードという機能が搭載されています。これはユーザエージェント文字列を切り替えると共に、ドキュメントモードの判定ロジックにも影響を与えるものになっています。互換表示設定(互換表示リスト)という機能があります。サイトに対して送信するユーザエージェント文字列や、利用するドキュメントモードを調整することができます。ドキュメントモードが自動的に利用されますが、これは互換表示リストに以下の記述があるためです。さんのこちらのエントリが詳しいです。興味がある方は読まれてみるとよいかと思います。ブラウザのバージョンアップに対する戦略]さて、ここまでドキュメントモードを利用したレンダリングエンジンのバージョン変更方法について解説しました。バージョンアップする場合に比べて随分とラクになるはずです。使い続けようとか、そういった考え方は決して正しくないと思います。これらはいずれも、汎用製品の宿命であるサポートライフサイクルというものを無視した考え方だからです。レンダリングモードを搭載しています。身内の人間だから言うわけではないのですが;、エンジニア的な目線だと、たまに「ここまでやっているのにまだ文句を言われるのか;;」と思ってしまう瞬間もやっぱりあります。思う瞬間も、やはりあるのです。ミドルからすべて自作するとお金がかかります。我々はコストを下げるために汎用製品を利用してモノづくりをするわけですが、そうである以上は、作ったタイミングから先々のサポートライフサイクルを想定し、自分たちのアプリのアップグレード戦略を考えておく必要があります。普及に併せてよく取沙汰される方式です。インターネット上でコンシューマ向けサービスを展開している企業では、こちらの方式が利用されていることが多いでしょう。理由は単純で、こうしたシステムはそもそも頻繁にアプリのコードを書き替えているため、それに合わせて最新版のインフラに取り換えていくことが容易だからです。この方式を取る場合にはリリース頻度が自ずと増えるため、テスト実施の効率化(例えばテストの自動化など)についても積極的に取り組んでいることが多いでしょう。方式を取り入れる製品が多くなってきたこともあり、コンシューマ系では否応なくこうした対応が求められてきています。業務系のアプリ、特にイントラネット系の業務アプリでは、2の方式、つまりある程度の期間塩漬けしておき、一気にアップグレードするという戦略を採っているケースの方が多いでしょう。した戦略を採る背景には、イントラネットであればクライアントのバージョンなどを固定化しやすい、再テスト工数などを極力減らせる、などがあると思います。この方式2の怖いところは、いざバージョンアップが必要になったときに対応が後手に回りやすいことです。実際の現場でよく見かける例を挙げれば、以下のようなことがあります。徹底的に塩漬けを続け、サポートが切れる段階になって慌てて対応しようとする。関してよく見られます)移行時に最新インフラを選ばなかったり、移行検証に時間がかかりすぎてどんどん古くなってしまう。移行しようという話があったりします......)こうしたインフラのアップグレードがそう単純でないことは私も承知していますが、とはいえ対応が後手に回れば回るほど、追い詰められやすくなるのも事実です。サポート切れを見込んだ戦略を立てていなかったり、対応工数・コストを予算として積んでいないと、こうした問題は致命的になりやすいです。2の方式を採るのであれば、戦略なり予算なりをきちんと検討しておくことが欠かせません。ランタイムの移行に際しては、本稿で説明している「ドキュメントモード」のように、移行時のデグレードリスクを極力下げるような移行方法を検討することが極めて重要です。ランタイムに載せ替えれば、多くの場合は何らかの互換問題が発生してしまうはず。アプリ修正を完全に不要にすることはできないにしても、極力、修正量を少なくするような移行方法を検討するべきです。主な検討ポイントとしては、以下のような点が挙げられます。利用するように設定する。ブラウザアプリであれば、極力同じドキュメントモードを利用するように設定する。同じ振る舞いをするように設定する。ミドルのバージョンアップを行った場合には、アプリの再テスト(デグレードテスト、リグレッションテスト)が必要になりますが、テスト戦略なしにフルパステストを再度行うようにしてしまっては、膨大なコストがかかってしまいます。これを避けるためには、以下のようなことをしておくことも欠かせません。アプリケーションのコード資産を、常に綺麗に整理しておくリグレッションテストをしやすいように、テストケースやテスト結果データなどをきちんと整理しておくなお、再テストの容易化というと、真っ先にテスト自動化に飛び付こうとされる方がいらっしゃるのですが、それは必ずしも正しいアプローチではありません。ミドルのアップグレードに対してはさほど有効とは言えません。)は、打鍵の自動化はしてくれますが、結果検証に関しては不完全です(例:自動化ツールでは文字化けや画面崩れに気付けない)。変更・修正インパクトに応じたテストケースの適切な選出ルール、などを決めて実施していくことの方が、圧倒的にコスト効果の高い再テストにつながります。ランタイムのアップグレードへの対応容易性を高める上で極めて重要です。Manager)というツールを提供しています。理解すると、正しいテストの在り方や効果的なテストの実施方法がどのようなものなのかを知っていくことができると思います。的な方も多いでしょうが、ある程度モノづくりができるようになってきたら、こうしたソフトウェアテストに関しても知見を深めていくことをおすすめしたいです。話は本題ではないのでまた機会を改めて。インフラのアップグレード戦略を見直さなければいけない時期に差し掛かっているからです。下表を見てみてください。リリースしてきました。市場を一変させてしまったことからもわかるように、数年程度に一度というリリースサイクルでは、今の時代ではとても戦えないのが実情です。いやいやそれはコンシューマの世界であってエンタープライズの世界(企業向けシステムの世界)では関係ないでしょう、と思われている方もいるかもしれませんが、それは誤りだと思います。業界のトレンドというのはコンシューマ市場から発生してくることが少なくありません。コンシューマライゼーションと呼ばれています)。リリースしているわけにはいきません。へたった一年でアップデートしてきたことも、こうした背景事情を考えれば必然的なものです。時代への移行は、様々な変化を生み出します。ブラウザのドキュメントモードに関する方針変更です。扱い(利用を推奨しない機能)に変更されました。リリースのつどレンダリングエンジンを残すようにするのでは、製品サポートも含めて無理が出てきます。業界標準仕様に強く準拠するようになってきており、今までのように、マイクロソフトの独自仕様を残すためのドキュメントモードを残す必要性というのも昔に比べて減ってきています。開発のトレンドを踏まえれば、ブラウザアプリは常に最新の業界標準仕様に追随すべきであり、ドキュメントモードを非推奨扱いに変えていこうという動きも、(インターネットの世界のトレンドだけ見れば)ある意味自然な流れともいえます。その一方で、企業内のアプリがこうした頻繁なアップデートサイクルにリアルタイムで追随していけるようになるかと言えば、それはなかなか難しいと言わざるを得ず、実際には従来のような方式2、つまり適度な期間の塩漬けと最新版へのアップデートを繰り返す形になることが多いと思います。いう本質的な問いかけです。ブラウザというものは、そもそも業務アプリ開発用のインフラとして作られているものではなく、むしろコンシューマにおける利用を前提に、開発とアップデートが繰り返されてきているものです。ランタイムがインストールされていることと比べると、あまりにも大きな違いです。ランタイムのように、かなり長い間に渡って残り続けそうなランタイムになりつつありますね。ブラウザ上に載せようとする傾向があるように思います。アプリが作られていることが少なくありません。言いたくなる場合もあります。やろう、という発想は、今一度考え直すべき時期に来ているのではないでしょうか?業務アプリケーション開発は、開発生産性や保守性など、様々な要素のバランスを取って行うべきもの。インフラのアップグレードにどのように追随していくのかを予め考えるようにしていただければと思います。[まとめ]いろいろと話が脱線しましたが、最後に要点をまとめると、以下のようになります。動作させる場合には、ドキュメントモードを変更して動作させるとよい。このようにすることで、描画に関する非互換問題を最小化していくことができる。ヘッダーを追加することで指示できる。サーバの設定を変更することで、アプリ全体に対してまとめて指定してしまうとよい。バージョンをどのように上げていくのかの戦略が必要である。どのように対応していくのかの指針を定めておくことが重要である。バージョンアップ時のデグレリスクを最小化するために、ドキュメントモードをはじめとした互換設定をうまく利用する。デグレテストをなるべく容易化するために、テストケースやテスト結果データなどをきちんと整理しておく。いう方は、ぜひ以下の資料も読んでみてください。コンサルティングサービスの森さん、長本さん、稲葉さんによる渾身の一作です。(実はこのエントリも、森さん・稲葉さんにレビューしてもらいました。お二方、本当にありがとうございました^^。FeedbackTrademarks。