私が以前執筆した記事「意外と知られていない、IE11リリースによる本当の危機」がかなり好評でしたので、執筆者としてもう少しだけ言葉を残してみようと思います。
なぜQuirks？と考えたことはあるだろうか
Webシステムでは、わざとQuirksを使うというバッドプラクティスがどこでも横行しているでしょう。必然的に、そうならざる得ないケースがあったからです。マルチバージョン対応を最小のコストで行う方法として、Quirksが最も優れてしまったのというのが最大の要因です。
かつてWinXPの時代、6/7/8で同じ機能性が確保された無菌室状態のレンダリングモードはQuirksだけでした。IEのみしかいない世界では、Quirksに逃げられてしまう可能性があることを想定できていなかったのは、IE側のミスだったと言えます。IEは、バージョン間の相互運用性が確保できていないと暗に認めてしまうような機能を実装した時点で、X-UA-Compatibleを実装すべきだったのです。IEは自信を持って相互運用性が確保できたと言える状況になるまで、マルチバージョン対応の最善の方法にQuirksという抜け道を作ってはいけなかったのです。
しかしIEもまた、日本のSIのような、IE内だけでマルチバージョン対応を行うというレアケースを想定することは難しかったでしょう。日本のSIがWebでシステムを作ってしまった時点で、コストと正しさを両立できない仕組みを作ってしまった時点で、「あえてのQuirks」は必然的に止められなかったのでしょう。
正しさとコストを両立できるまでの6年
IE11のリリースで、Win7の時代にQuirksアプリをわざわざ開発する理由は失われてしまいました。問題は、Quirksを使うことが当たり前過ぎて、Quirksが何なのかをわかっていないような人がいるケース。そしてそれを、要件フェーズや品質管理側からコントロールできていないケースなのかもしれません。
今後のWebシステム開発では、IEの段階的なアップグレード計画、開発・移行を行うシステムのドキュメントモードのレベルの設計、テスト対象ブラウザについても、企業の持つシステム全体をトータルに見た上で、SI側がコンサルタントできないといけないはずです。そうしないと、6年後は最悪な状態に陥るでしょう。企業はWindowsのアップグレードを、諦めざる得ない状況になってしまうのです。専用に別の端末を確保し維持するという、コストパフォーマンスとして最悪の状態に陥るでしょう。
この6年をしっかりと設計し、全システムが見事IE10以上への移行に成功したのならば。バージョン検出やドキュメントモードでなく「機能/動作検出」による汎用的なWebシステムを作り上げたのであれば、HTML5の標準的プラットフォームにより、正しい方法で長いライフサイクルに耐えるシステムとなるはずです。
既存システムはコスト最適化させなくてはいけないというこの状況下で、Web開発を行うSIのコンサルタントにとっての、腕の見せどころなのかもしれません。
