引用記事です。
ふと、前にFirefoxの派生ブラウザを使っていたとき、非対応ブラウザと言われてSlackが利用できず、
User Agent SwitcherでFirefoxになりすまし無理やり使っていたことを思い出しました。
ついでにSlackが日本語対応したことも思い出したのでSlackの対応ブラウザを調べて見ると、個人的に面白いことが書いてあった。
Slack の推奨環境 — 対応 OS とブラウザ – Slack
ブラウザ主眼です。
使っている OS (またはブラウザ) がサポート対象外になりました。どうしてですか?
Slack の品質向上に集中するため、対応 OS やブラウザをできる限り限定するようにしています。古いバージョンの OS やブラウザも含めて幅広い対象をサポートすることにより、新機能の開発など、Slack の品質向上のための作業にかけられる時間がその分少なくなってしまいます。ですがこれは、私たちにとっても、ユーザーの皆さんの利便性を考えると、とても難しい決断でした。一部のユーザーの方にはご迷惑をおかけすることになり大変申し訳ありませんが、どうぞご理解いただけますよう、よろしくお願いします。
古いブラウザやレアなブラウザ対応は、開発者としても苦痛なものがあります。
開発者としてはそのことばかり考えていましたが、開発者のリソースが喰われるということは≒機能向上のスピードも落ちるということであり、
ユーザーの利便性を考えているようで実は別の方面でユーザーに不利益が出ている。
ということは書かれれば当然ですが、案外気づいていなかったなと思いました。
一度対応してしまうと新機能も対応しなければならないので、着手遅れどころか開発速度も下がるわけで。延々に。1
畑違いなんですが、アプリ系もそれぞれ作るのは大変そうだと眺めていたので、ElectronやReact NativeでOSの違いをあまり意識せず作れることも、思っている以上にメリットが大きいのかなと思いました。
サポート対象外であることを明記するだけでなく、なぜブラウザを完全にブロックしてしまうのですか?
私たちは、ユーザーの皆さんに可能な限りベストな状態で Slack を利用してもらいたいと考えています。問題やバグへの修正対応をしていないサポート対象外のブラウザをご利用いただいた場合、なんらかの支障が出ることは避けられず、そのような利用状況を完全に防ぐことを目的に、対象外のブラウザをブロックすることにしています。
これも(ITに比較的強い?)自分がブロックされていたときの例では、
一部動かない・崩れることがあっても、主要ブラウザを使っていないから承知のうえだ。とりあえず触らせてくれ
っと思っていました。
しかし提供側に立ってみると、
想定外の不具合が出ることはもとより、
それを含めた大小様々な問い合わせが非推奨ブラウザが原因で出てくるんじゃないかなと思いました。
問い合わせが増えるし、解決ではなく非対応で打ち切るしかないということは、サポートと利用者双方にとって損でしかないなと思いました。
本来の推奨環境下での問い合わせ・調査にもノイズになりそうですしね。
Opera は Google Chrome 派生ブラウザです。Chrome には対応しているのに Opera がサポート対象外としてブロックされているのはなぜですか?
Opera は Chrome をベースとしていますが異なる点が多く、Chrome と一緒にしてサポートするには大変難しいものがあります。私たちの第一目標は、ユーザーの皆さんにベストな状態で Slack を利用いただくことです。そのため、対応ブラウザを限定するという難しい選択をする必要がありました。
これも自分は、「一部ブラウザでしか利用できない機能」を見かけたことがあります。
それは(自分がそのブラウザでなくても)+αな機能だと思いました。
しかし反対の立場で考えると、-αであるのかな、と。
「私たちの第一目標は、ユーザーの皆さんにベストな状態で Slack を利用いただくこと」であれば、全機能がフルに使える環境と、一切使えない環境の2分化をしたほうが、ユーザーにとっては誠実なのかもしれません。
機能でなくレイアウトでも、(ブラウザごとの)UI・UXの変化だけでも受ける味2は大きく異なってきますし、そこすらも均一化できることが理想なのでしょうか。
鵜呑みはできないかもしれない
もちろんこれはSlack側の言い分なので聞こえよくしていることと思います。
また、お国柄・企業スタンスやSlackのユーザー層、提供形態を考えてみると、まあ強気でもイケるかなという気がします。
現実は古いPCを使ってる企業への納品や、「このブラウザに対応してくれたら契約が取れる(=が貰える)」という状況に対して、上記の利を説いてみても効くかは懐疑的です。
たくさんのブラウザで動くならそれは便利でしょうし、お金になりますし。PVだって増えるでしょう。
「動かないこと」がお金になるとは直接結びつきませんし、間接的にも結びつくことが測定できるかと言えば謎です。
お金を出す3相手のお願いが通りやすいのが日本の一部IT業界の特徴かなとネットや実体験だけ見ているとすこし思うので。
感想
こーいった話が出たときに技術的な拒否感だけで話をすすめるのは簡単。
技術的負債4になることが明確なことだけで忌避するのに十分ではないでしょうか。
しかもスタートアップのような先進的バリューのための負債ではなくてどちらかと言えば後ろ向きなことですし。
でも制作物やユーザーの全体的・長期的な目線を持って挑むことで、
やらねばならぬとも相手からの印象がよくなったり、
「できるけどやらない」説得の一助になったりしないかなと願いたいですね。
ということで、
非対応ですテロップを出すどころか
「わざとブラウザを制限するサービス」
があることと、
「それがユーザーの便益につながる」
ことが書いてあったことが目からうろこでした。
参考
-
ブラウザ機能格差への3つの対応概念 まとめ - Qiita
「皆にベスト」ならレグレッシブ・エンハンスメントですが、記事でも書かれているようにそもそもHTML5など機能面の差異が…。 -
シェアの少ないJS殺しブラウザ対応の話 - Qiita
すごい労力に見える。十分にグローバルなサービスになると畢竟対応していくことになるのかも。 - 2016年以降に「IE8に対応して」といわれたとき思い出したい六項目 - Qiita
- 古の技術になりつつあるIE8・IE9対応でやること、使えないもの - Qiita
-
Google Chromeは新たなInternet Explorer 6になりつつある | スラド IT
タイムリーなもの。
反応を見るに眉唾ですが、古すぎて周りに対応できないこともあれば、逆に新しすぎて周りが対応できなくて差が生まれることもある、という見方もできるのかなと。 -
IE11のバグまとめ - Qiita
サポートされている主要ブラウザだからと言って問題が無いわけではない。
しかし、SlackはIE11に対応しています。
すべてを突っぱねているわけではなさそう。取捨選択の見極めも大事?(流石にIE最終バージョンはサポート中ですしシェアからみても外せないでしょうし、Slackの推奨ブラウザが殊更特殊というわけではありません)
あとはSSLのプロトコルの初期値の話も見かけたので、常時SSLの普及やプロトコルの更新が続いていることによる問題もあるかもしれません。
IE8だとhttpsサイトが表示きない時の対策 - ナウいプログラマ
軽く調べると、ブラウザ対応の手法やpolyfillがいろいろ見つかるので「頑張ればできる」状態にありそうなことも問題だと思います。
大手や競合がやってれば圧は強くなりそうですし、メジャーバージョンアップでも過去利用できていたものの後方互換は当然的風潮あります。
ユーザーも経営者も開発者もみんなハッピーな都合のいい冴えたやり方は無いだろうか…。