フロントエンドの移り変わりは早すぎるのか

インターネットでは毎日のように言われることですが、私はそこまでではないと考えています。

ネットでよくそう言われる理由として考えられるものと、それを踏まえてどう向き合っていくとよさそうか、個人的な考えをまとめてみます。

なぜ言われるのか

言語が実質的にJavaScript一択

バックエンド、というかサーバサイドでは技術選定に「言語の選択」が入りますが、フロントエンドでは実質的にはJavaScriptにほぼ固定されます（TypeScriptも別言語ではないので、ここではJavaScriptに含めます）

サーバサイドと比較して「技術の移り変わりが早すぎる」と評される場合、多くはその人の使用しているとある言語と比較されているように思われます。

実質的に言語が固定なので、比較するならすべてのサーバサイドの変化の総量と比較するのが妥当でしょう。

PHP + Python + Ruby + go + Java + Kotlin + Scala + Rust + その他諸々の変化の総量と比べて、それでもJavaScriptの移り変わりがそこまで早いのかは疑問があります。

変化の少ない言語や技術と比べると「早すぎる」と感じる場合はあるかもしれませんが、フロントエンド領域でなくても変化の早い言語は少なくないはずです。「Webの世界は新しいものが出すぎ」であれば分からなくはないです。

新しいものが注目を集めすぎる

同じ言語が広く使われているので、新しいものが次から次へと出てくるのは自然なことです。一方で、それをすべて追いかけるのは難しいというか、普通の人には現実的ではないでしょう。

そもそもそうして華々しく紹介された技術が必ずしも定着するわけではありません。定着しないままに消えていくものもあれば、同じコンセプトを持った後発の違う何かが主流になることも多いはずです。

特に新しいコンセプトを持ったソフトウェアは多産多死の試行錯誤の時代を経て、最終的に何らかのスタンダードが生き残るものです。落ち着く前のあれやこれやは、そういうフェーズに興味がある人以外はさほど気にする必要のないものです。

存在を知ったり下調べをするのはよいことですが「これからはこれじゃないと時代遅れらしい」のように囚われるのはよいこととは言えません。

新しいものがやや大袈裟に「これからはこれじゃないと！」みたいに言われる場面もありますが、それはまぁフロントエンドに限ったことではないでしょう。先の言語が実質的にJavaScript一択なので、その分だけ人目を引きやすいのはありそうです。

変化の小さい時代があった

Webフロントエンドという領域が確立されたのは2005年にGoogleMapsやGMailがリリースされたのが大きな契機でした。その後、数年を経てjQuery, Moment.jsなどの「とりあえずこれを使っておけば間違いない」定番が固まったと記憶しています。BootstrapやjQuery UIなんかも挙げられるかもしれませんね。

その少し後にAngular.jsによるSPAやパッケージマネージャー、バンドラを使った開発スタイルも登場しました。この流れが今日の俗に言う「フロントエンド開発」につながっていますが、それまでの定番はそれはそれで使われ続けました。必ずしもすべての側面で優れていたわけではないし、当時の日本だとIE6で動かないと業務での採用が難しい場面も少なからずありました。

前者のスタイルでやっていく分には年単位でずっと同じライブラリを使い続けてもさほど困らなかったのですが、後者に移行しようとすると時間の感覚がまったく変わってきます。昔からやってきた人の中には、このギャップに馴染めない層が少なくないように感じています。

当時はサーバサイドの開発が主で、言ってしまえば片手間程度の労力でフロントエンドを開発することが多かった感覚が生きている側面はあるように思います。

そうした人たちが「フロントエンドの変化は早すぎる」とこぼす → 実際新しいものはたくさん出てくる → 新しい人たちも「そうなんだ」と思ってしまう、このサイクルが世間の空気を作っている側面はわりとあるんじゃないかなぁと思います。

向き合う上での考え方

一歩半だけ遅れてついてく

新しいものは次から次へと出てくるので、実際のプロジェクトにあれもこれも導入するのはリスクの高い行動です。特に業務ではアプリケーションの寿命が長い場合も多いので、採用する技術が数年先にどうなっているかの予測も必要になります。

実務での採用という観点では最新をキャッチアップするよりも、そこから少し遅れて普及したと考えられる、なんならネットでは派手に取り沙汰されなくなったぐらいのものを積極的に拾っていくぐらいがいいかもしれません。皆が普通に使うようになって、人目を集めるための派手な言及が減ったあたりで食い付くのは効率的な立ち回りでしょう。

一方で新しい技術を最大限長く美味しくいただくにはそこから離れすぎるのも望ましくありません。ちょっとした下調べや情報収集ぐらいはある程度早い段階でしておくと、採用のタイミングを逃すリスクを減らせます。特に初期の注目を集めている時期は情報も多く目に入ってくるので、そこを完全にスルーするのももったいない話です。

更にはチームとしてそれを使いこなしてリターンを得られるか、そうなるまでにどれぐらいの時間が必要になるのかも極めて重要です。

そのあたりの見極めはあなた一人だけでなく、実際にチームで取り組まないと見えにくいことも多くなります。寿命の短いプロジェクトや、独立して試せる機会を見出して少しずつチャレンジしましょう。

本当に使えなくなるまでの時間は実は長いので慌てない

ネットで「もう○○は終わった」みたいに表現される技術も、実際にはすぐ使えなくなるわけではありません。

そう言われるものの多くは「今から新規プロジェクトを立ち上げるなら他にもっといい選択肢がある」ぐらいに捉えておくといいでしょう。ただちにあなたのプロジェクトから排除しなければいけない場面はそうそうないはずです。

次への乗り換えも常に視野には入れつつ、慌てず冷静に移行プランを練っていきましょう。具体的なメリットが薄ければ現状維持も真っ当な選択肢です。「もう古いから」はその技術を捨てる理由にはなりません。

メンテナンスが止まったパッケージはいずれビルドできなくなったり、依存ライブラリの脆弱性を解消できなくなったりするリスクはあるので、固執し続けるのもリスクはあります。またビルド周りのツールだと最近のものはやたら速かったりするので、移行コストに見合う恩恵を受けやすいかもしれません。

物にもよりますが、感覚的には「そろそろこいつを次の何かに移し替えたいな」と思ってからも2年やそこらは持たせられるケースが多いように思います。あまりにも寿命が短く感じる場合は、そもそも採用するタイミングが遅かったなんてこともありそうです。

いずれ離れることを想定して依存する

現代のフロントエンド開発はかつての時代よりも様々な依存関係から成り立っています。最初に選んだパーツをプロダクトの寿命が尽きる時まで使い続けるのは必ずしも現実的ではない場面も多くなります。

そうした状況下では、採用する技術のそれぞれについて、影響範囲と依存度をコントロールすることが大切です。

長く使うつもりのものは深く依存してもよいが、そうでないものは耐用年数を予想して、その時が来たら別のものに差し替えられるように設計していきましょう。

私は技術選定の際はフロントエンドに限らず、採用するものを

• Tier 1 : これを捨てる時はコードを一から書き直す覚悟を持つ「心中する」相手
• Tier 2 : 差し替えには大きな労力を必要とする「強く依存する」相手
• Tier 3 : いずれ差し替えることを想定した「依存を軽くする」相手

ぐらいにカテゴライズしています。

まとめ

学生の人と話す時とかに「フロントエンドは技術の移り変わりが早いと聞くので、バックエンドをやりたいです」とちょくちょく言われるのですが、それでフロントエンドを忌避してしまうのはもったいないと感じる場面が少なくありません。

新しいものがたくさん出てくるのは、広く使われているプラットフォームで活発に開発がなされていることの表れだし、様々な進化の可能性が模索されているのは面白い部分でもあります。

過度に忌避することなく、変化を楽しめるといいですね。