IE終了まであと１年！IE対応に関していろいろ思うこと。これまでの経験を踏まえて適当に語る

こんにちはjunです。2021年5月19日にとても嬉しいことがおきました。Twitterを見るとなぜかトレンドに「IE終了」という文字がありました。詳しくみてみるとなんとマイクロソフトが2022年6月にIEのサポートを終了するという旨のyoutube動画をUPしたのです。夢でなかったのです。ついに苦しいIE対応をしなくてい良いという大義名分が来年から得られることになったのです。あまりにも嬉しくて速攻で会社のslackに共有したほどでした。

サムネイルの写真もTwitterでバズって回ってきたものでとても面白かったです。ちなみにオリジナルはこのツイートです。

さてこの記事は技術記事じゃありません。ただIEサポート終了がうれしすぎて何か記事にできないかと思い、わざわざ新しいカテゴリーを作成しました。この「小言」は技術とは関係ないIT系に関する私の意見とかを述べるカテゴリーにします。あまり使わないかもしれませんが。まあQiitaでいうポエムみたいなものだと思ってください。

今回の記事では題目にある通り後１年のIEサポート終了が迫る中、我々webエンジニアがどうIEに向き合うべきかを私なりに意見を述べようと思います。順序的に

• これからの流れと情報の整理
• IE対応の背景、なぜ対応が必要なのか
• なぜ対応が嫌なのか
• IE対応肯定派の意見について
• その反論（小言）
• 最終まとめ

みたいな感じで行こうと思います。それでは早速いきましょう。

これからの流れと情報の整理

エンジニアたるもの必ず情報源を確認しましょう。まず上記のあった通りのマイクロソフトのサポート終了は日本時間2022年6月16日にセキュリティサポートを終了するとのことです。それ以降はどんなバグ。脆弱性が起きてもサポートをしないとのことです。

公式youtubeはこちら（https://www.youtube.com/watch?v=0Q_1Lfgpb5s）で、概要的なニュースはこちら（https://www.atmarkit.co.jp/ait/articles/1503/11/news134.html）を参考にするといいです。

ただしこのサポート終了はLTSB/LTSC以外のwindows10におけるInternet Explore11であり、Windows 10 LTSC(Long-Term Servicing Chanel)とWindows 10 Serverという製品に含まれるIE11は対象でありません。これらの製品のIEはなんと最長のもので2029年までサポートされています。

えっ！じゃあ苦労は2029年まで続くの！！？と心臓が止まりそうになったかもしれませんが、このLTSB/LTSCというのはエンタープライズつまり企業向けの長期サポートのwindows10です。導入には10万以上かかる法人向けのwindowsです。つまりウェブサイトをみるだけ、インターネットを使うだけにPCを買っている一般の方々がインストールしているwindowsではありません。

そのためまとめますと、「LTSB/LTSC以外の、一般の方々がインストールしているwindows」のIEサポートが2022年6月16日（日本時間）に終了するということです。OK?よかったですねー。

IE対応の背景、なぜ対応が必要なのか

いくつかの原因はありますが理由として

• 社内で使用しているシステムがIEしか対応していないので、既定ブラウザになっている。
• 日本ではなぜか10%ぐらいのシェアがあり、使用しているユーザーもそこそこいる

があります。特に前者のシステムがIEにしか対応していないというのはかなり大きく、マイクロソフトが長年IE11を残したり、Edgeの中にもIEモードを含ませていたり、windows10に入れている原因です。流石に強制的にIE11を消して社内システムが使えなくなった！なんてなったら流石にやばいです。

2020年の夏あたりに「マイナポータルがIEでしか使用できない」という事件がありましたが、それもその一つです。PCにてマイナンバーカードの情報を物理的に読み取って使用するにはJavaかIEのAvtiveXしかない。という縛りがあり基本的にマイナポータルはスマホからのアクセスを前提にして、PCブラウザでの対応を後回しにしたという感じです。これも技術的な制約上、IEを使用せざる得ない理由の一つです。

後者はちょっと自分でなんとかしてくれよと感じがしますが、正直ユーザーからしてみれば「ブラウザってなんすか？」というものぐらいです笑。なんか昔からインターネットみる時はこのアイコンだったしぐらいしか知らない人も多く、日本では前者の理由も加わってIEを使用している個人や会社がいます。私の取引先も私が指摘するまでIEを使用していました。（とくに役所や学校が多いです）

「それでもさぁ！」と言いたいお気持ちはわかります。まずはなぜ必要となっているのかの背景は以上の通りです。

なぜ対応が嫌なのか、すべきでないのか

そんな事情がありながらも、我々webディベロッパーはなぜIE対応をしたくないのでしょうか。技術的・工数的な視点で述べていきます。

CSSが崩れる

まずはこれですね。web上でのデザインを表現するためにCSSを使用しますが、「chrome、safariではきちんと表示されているのに、IEだけ違う！」という事件がおきます。理由としてはIEがそのCSSプロパティをサポートしていない、または特定の記述が必要だからです。他にもIEにしかないCSSのバグもあり、対処のためにトリッキーな書き方をする必要があります。

ES6が使えない

ES6はjavascriptだと思ってください。javascriptにはES5,ES6といったものがあります。ES6の方が新しくスマートでより良い記述が可能です。例えばES5では変数宣言にvarしか使用できず、定数などは大文字にして表記すると言った運用面でカバーしたり、クラスの書き方も関数を使用してとっつきにくい感じでした。

しかしES6ではconstでの定数宣言、class{}を用いた表現ができる様になりました。それがそのまま使えればいいのですが、はい。。IEです。なんとIEではES6がサポートされておらず構文エラーを起こしてスクリプトが停止します。そのため渋々ES5の書き方をするということもありますが、Vue,Reactなどのjsフレームワーク、その他のnpmパッケージなどで取得できるライブラリでES5の書き方をしていないものがあります。というよりES6の方が開発がスムーズにいきます。

そのため開発を効率的に行うjsライブラリを使用できなかったり、IE確認で時間を取られます。（そのくせIEのデバッガーは遅くてよく止まります。）

javascriptファイルが重くなる・ビルドの負担が大きい

ES6が使えないので最新のjsは諦めて、旧石器時代のjsの構成でやる...?というのは酷です。そのためどこかの神様がBabel、PolyfillというES6とES5の互換性を作ってくれるライブラリを作り出しました。BabelはES6の書き方をES5に変えてくれ、Polyfillはjsの言語特徴を利用してES6の機能をES5に追加します。

それであれば万事解決...とはなりません。とてもありがたいのですが弱点としてjsのバンドルサイズが重くなったり、babelによる書き換えのためにnode.jsの環境が必要となったりとまだまだ開発に難があります。中にはBabel、Polyfillを使用しても解決できずIEだけ動かないというものも少しあります。Babel、Polyfillも万能ではありません。

これらの措置はIEのためだけに行うものであり、他のモダンブラウザであれば不要なことです。同じjsファイルでも上記の処理をしなければ100kbも軽くなったりすることもあります。

開発工数がかかる

上記の様にIEだけの特別なチェックや開発、ファイルが必要となったりで開発側の負担が大きいです。負担が大きいということは工数もそれだけ伸びるので費用もかさみます。開発者だけが苦労するだけでなく、工数も伸びてしまい費用がかさみ、その割には利用者は全体の数％とあまり得でない気もします。

公式が使うなと言っている

開発したマイクロソフト自身が「IEは技術的負債」とまでいい、段階的にEdge（IEの後継、いわゆるモダンブラウザ）に移行する様にユーザーに呼びかけています。つまり公式自ら「IEは危ないから使わないで！」としているのに使うのはいかがなものかとあります。

セキュリティーリスクがある

IEは現在セキュリティーサポートのみでアップデートはされていません。もしIEに脆弱性が発生したら（しかたなく）マイクロソフトが対応して、セキュリティパッチを出すと言った感じです。その際に危惧されるのが「ゼロデイ攻撃」と呼ばれるものです。「ゼロデイ攻撃」はそのマイクロソフトのパッチが適用される前、脆弱性情報が発表される前に素早く対象のマシンを攻撃するものです。セキュリティパッチが効く前を狙った攻撃です。

開発元がしっかりしていればいいのですが、2020年1月のIEにおける脆弱性対応にパッチ提供に３週間かかったりなどもうサポートのやる気なさを感じさせるぐらいになっている。セキュリティバグも多いのでIEに限定した攻撃というものも存在している。わざわざそんな危険なブラウザ使う人も少なくなるだろうし、というかIEが原因でwebサイトの情報が漏れるなんでまっぴらゴメンです。ならばIEでは使えない様にした方がいいというものも納得できます。

IE対応肯定派の意見について

このようにIEにはデメリットが多いですが、「IEに対応すべきだ！」という恐ろしい方々が存在します。「これだから、IT知らない人は..」「開発者の気持ちも考えずにまったっく..」と言いたいですが彼らの意見には、耳を傾かせるべき内容もありました。

シェア数％としても母数が多ければそれなりにいる

IEのシェアは日本では7.4%、世界は1.94%と言われています。 インターネット利用者は統計的に世界でPCで40億人、日本では１億800万人はいるそうです。もちろん全員がwindows,PC,ブラウザを使用しているとは言えませんが単純にパーセンテージをかけてもIE使用者は最大約、日本で80万、世界では7700万となります。まあ無茶な計算なのでもう少し低いでしょうけど。

だたし1万人はIEを利用していそうです。どうでしょうか？この数はあなたの顧客となりうる数ですがを捨てられますか？といわれると「うーん」となります。

ただしビジネスであればこんなチンケな数より、メジャーブラウザを利用している人をターゲットにした方が工数と利益率が最適になりそうです。ただしビジネス意外にもwebサイトは使用されます。次の理由につながります。

情報の公共性を担保すべきだ！

では仮に1万人のユーザーは少なくともIEを使用して様々なサイトを見ているとしましょう。webサイトにはビジネスでなく公共的なもの、例えば政府広報や自治体のサイトなどがあります。その場合デジタルデバイドなく、全ての人に情報が渡るべきサイトの場合は対応について少し考える必要がありそうです。

開発が面倒って、それあなた（開発者）の感想ですよね

あー。はい。確かに技術選定をしてライブラリとか適切に入れて、チェックしたりIEだけ専用のファイルを読み込んだり、Babel、Polyfillを使用すればなんとかなります。開発工数は伸びるけど確かに「できなくはないです」。逆に開発者がだだこねて「最新の技術じゃないと嫌だ！」「お金があってもIE対応は嫌！」となっては顧客的には納得いきません。顧客にとってみれば動いていればいいんですから、機能が豊富なwebアプリならともかくwebサイト作成ぐらいならやれば？という意見もあります。

その反論（小言）

対応すべき派はこんな感じです。他にあったら追加しようと思います。ではその反論や私の意見を述べようと思います。

セキュリティリスクのあるものは使うべきでない

一番はこれです。いきなりジョーカーみたいなものですが、セキュリティリスクのあるブラウザ（アプリ）を使用するのはいかがなものかと思います。ましてやIEが原因なのに情報漏洩をwebサイトのせいにされたらたまったものじゃありません。Dropbox、Boxといったクラウドストレージサービス、AWSやGCPなどは特に嫌がると思います。（Dropboxは2020年10月からIEサポートしていません）というよりもログインを必要とする様な機密情報を扱うサイトでは使用させるべきでないです。webアプリ系のサイトはIEを使用させなくても良いと思います。

マイクロソフトがIEを残しているのは企業のため

window8を強制的にwindows10にアップデートした過去がある伝説のマイクロソフトさんですが、この様なことをするならIEがいつの間にか削除されていてもおかしくないと思います。でもIEは明示的にLTSB/LTSCに残したり、EdgeにもIEモードたる物を残しています。それはなぜか？

理由としては対応理由の一つであった「IEしか対応していないシステムがある」からです。つまり企業のシステムが対応できるまで一応、IEを利用できる様にしておこうという措置です。webサイトを見るブラウザの一つでなく、IEでしか動かないものを動かすための救済ブラウザなのです。企業のシステムはお金や大人の事情ですぐには代替できません。一方ユーザーのwebサイト閲覧はどうですか？最悪、Edgeのアイコンおすだけですよ？？IEを残しているのは企業や特定環境のシステム利用のためであり、一般的なユーザーのサイト閲覧アプリとしての利用は正直想定していないと思います。

公共性と言っても横浜市のコロナの予約サイトはIE非対応だったよ

これ結構大きいかなと思います。横浜市のコロナワクチン予約サイトはマニュアルのPDFにも書かれている通り、IE対応されていません。公共性の高いコンテンツはIE対応すべきとの意見は確かにありますが、コロナという、ましてや最初の利用者が高齢者・中年（IEの利用率が高め）に対してIE非対応としたのは大きな判断だったと思います。

真意は開発者と受注者しかわかりませんが、多分開発の速度的な問題だったと思います。前述の通りIEの場合はIEでのチェックが必要となり、工数が増え結果的に時間がかかります。さらにIEだけ動作不良がある、予約できないとなったらかなりバッシングされそうです。であれば早く予約システムを簡単でも作成して、動作が保証されるものを開発するならばIEを対応しないのは妥当だと思います。

ブラウザの「ブ」の字もわからない人は怒ったり、マニュアル読んでもよくわからないかもしれませんが、IE利用者のシェアと開発スピード・質を天秤にかけたら仕方なかったんじゃないかと思います。

私はこの対応判断は素晴らしいと思います。日本のIE非対応化の大義名分の一つになり得そうです。

必要なのは啓蒙である

IE使うな問題は過去の古いものから新しいものへの移行です。これはソフトウェアだけの問題でなく、他にもあると思います。今まで使いやすかった方法や物をやめて、今すぐ新しいものにしてください！という経験はありませんか？物だけでなく、考え方とかもそうです。「昔はOKだったけど今はだめ」、「これからはこうすべき」というものはあると思います。

古い物、使い慣れた物を使いづけたい気持ちはわかります。学習コストもあれば愛着もあるかもしれません。しかしIEはそれらを凌駕するほどのデメリットと、切り替えたことによるメリットを知らないからIEを使用するユーザーがいるのだと思います。

先述の横浜市コロナワクチン予約サイトの様に、マニュアルで明記したりして明示的にIEを使わない様に教えることもできます。なんらかのきっかけがあれば、きっとユーザーは乗り換えてくれると思います。特にセキュリティリスクなどデメリット部分をしれば、IEを止めるきっかけになると思います。

一応マイクロソフトには自サイトをIEで開くとEdgeで開く様に転送する様にサイトを登録してくれる機能を提供しています。申請を行い、XMLを書く必要がありますがEdgeで開く様にしたり、サイトに「IE非対応です」と書いて啓蒙するのが一番いいと思います。

まとめ。結局IEは対応す..

まとめますと、これから作られるwebサイト・アプリはIE対応しなくていいと思います。対応しても一般ユーザー的にも2022年6月ですし、その期間のために工数を増やしても意味ない気がします。最近、チェックでIEを開くとEdge移行用固定ヘッダーがでてきたりしてすごいことになっています。結局はユーザーに対する啓蒙が一番だと思います。今後webディベロッパーが行うべきはことは、 IE対応はしなくてもいいが、IEで見ちゃった人のためにEdgeに転送したりIEで見れないことをサイトで伝えること。そしてできたらブラウザ移行に関する情報を提供すること だと思います。以上！めちゃ長くなりましたが記事はこれでおしまいです。なにか意見あればぜひコメントください。それでは。