そろそろIE6が終わるのだけれども移行できる気がしない

未だにIE6を使い続けている企業はたくさんあります。それどころか、最近もIE6にしか対応しない社内アプリをつくったりもしてしまいました。

2014年にはついにIE6のサポートが切れるのだけれども、SI企業の方々はブラウザの移行にどれくらいリソースを割く気なのでしょうか？

回りは簡単に移行できると考えているのか、保守フェーズの人手が少ないままで行おうとしています。
そのような状態だと、間に合う気がしないです。

私自身はIE6のアプリを新しめのIEに切り替えるといったことは経験したことはないのですが、ブラウザを変えるにあたって気になっているのは以下の4つです。

1. JavaScript
2. CSS
3. 画面の大きさ
4. サーバーサイドの特殊コード

さて、以下一つずつ。

1. JavaScript
これは誰もが気にすると思うけれども、ブラウザ変えるだけで挙動が変わります。JQuery等のオープンなものを使っていればたぶん大丈夫だろうけれども、それでもライブラリの入れ替えは必要になるわけで。初期に作ったまま、化石とかしたライブラリだと多分新しめのブラウザだと動かないのではないでしょうか。

2. CSS
IE6はCSSのバグが多いです。最新のブラウザと全然見え方が違います。開発者はIE6のバグの入った解釈でデザインをしているため、間違いなく修正が必要になります。
ちょっとGoogleで検索をかけるだけでもたくさん。
http://www.google.co.jp/search?q=IE6+css&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:ja:official&hl=ja&client=firefox-a

CSSを知らないで書いていればいるほど知らないうちにIE6の挙動に合わせてCSSを書いているはずなのでどう映るかの確認から始めないと。テーブルの入れ子とかどうしたいのだろう。

3. 画面の大きさ
IE6で作った頃に比べてユーザーのディスプレイって大きくなっているはずだけれども、対応求められたりしませんか？ということ。CSSと絡んでくるけれども、画面の構成変更は（設計書も含めると）地味に時間がかかりますよ。

4. サーバーサイドの特殊コード
IE6の不具合対応のためにサーバーサイドにコードを埋め込んだことがあるのだけれども、そういうのって一般的ではないのでしょうか？

エラーメッセージ:「Internet Explorer ファイルをダウンロードできません」
http://support.microsoft.com/kb/816868/ja

私は2回ほど上の対応をしたことがあります。
他にもファイルのアップロード、ダウンロード周りをちらほらと。

ちなみに、上の不具合の回避策としてはレスポンスをShift-Jis(Windows-31J)で返却してあげることです。そうすればファイル名をURL-EncodeせずともIEがファイル名をきちんと処理してくれます。何かしらの理由があってレスポンスをShift-Jisにできない場合のみの対応になるのですが、毎回気がつくのはテストフェーズの後半になってからなので、なかなか根本対応は難しい・・・・・
次回、IE6のみ対応の案件の場合はレスポンスをShift-Jisで返すようにしたいです。（やらないけど）

と、4つ上げてつらつら書いてきたけれども、一番の懸念は技術者が不足しているってことだと思っています。IE6しか触ってない人はその後のブラウザに対する知識が不足しているだろうし、最新のブラウザで戦っている人はIE6なんてすでに見向きもしないだろうし。あまりに時間が開きすぎました。
ノウハウがないから結局全部テストし直し、必要に応じて要件から見なおす必要があるかもしれません。ノウハウがあれば短期間でできるのかも知れないけれども、現時点ではできる気がしないです。
これらのノウハウを持っている方々はいい稼ぎどきかも知れません。2度と使わないノウハウなので、新しく習得するのはお勧めできませんが。