フロントエンド不安症

注意：この記事はあくまで僕自身の観点と考えを述べるものであり、同業者を批判する意図は一切ない。

成熟しつつあるフロントエンド領域

現在のフロントエンド領域（ここではWeb開発を指す）は成熟しつつあると僕は考えている。フロントエンドフレームワークはコンポーネント化という中核思想とリアクティブな仕組みを採用し、フレームワーク独自の構文や開発手法、哲学を組み合わせることで、大半のユースケースに対応できるようになった。現在行われている改善の多くはビルドツールに向けられており、例えば esbuild、vite、snowpack によってトランスパイル速度や開発体験を向上させたり、既存のフレームワーク上で様々な最適化を行ったりしている。Vue 3 の Composition API や、React が最近発表した React Server Components など、様々なレイヤーで開発者の認知負荷を下げる取り組みが進んでいる。

もう一つのトレンドは、ブラウザと他のセンサーや通信プロトコルとの統合だ。Web Serial API、Web Bluetooth、Web NFC などが挙げられる。ブラウザの支援によって、ユーザーは別途ソフトウェアやドライバをインストールする必要がなくなり、すべての操作をWebページ上で完結できるようになった。この手のアプリケーションにおいて、Webページはせいぜい「外殻」に過ぎず、見た目の美しさは必ずしも重要ではない。デバイスと正常に接続でき、インタラクションが取れればそれで十分なのだ。

一方で、CSSフレームワークやコンポーネントライブラリも成熟したため、優れたWebページを作るためのハードルはますます下がっている。多くの場合はGitHubで好みの使いやすいライブラリを見繕い、コードを少し手直しするだけで済んでしまう。今のフロントエンドフレームワークが提供できる機能は、すでに大半のWebページが必要とするレベルを超えつつあるように感じる。すべてのWebページがFacebookやNetflix、Airbnbであるわけではないのだ。

Translator

最近コードを書いていると、まるで翻訳者のような作業をしている気分になる。要件をコードへと翻訳し、余裕があればテストやアクセシビリティ対応を加えるが、本質的には翻訳者とほとんど変わらない。こうした「横流し」の作業は、いずれAIに取って代わられるか、あるいはアルバイトがAIの補助を受けながらコードを書くようになるだろう。

以前のライブ配信でCopilotを使ってVue 3を書いたことがある。配信内の機能はシンプルなものだったので参考価値はそこまで高くないかもしれないが、Copilotが生成したコードを見たとき、その将来性には大いに期待できると感じた。このような単純な実装コードをAIに任せられるようになれば、僕たちはもっと注力すべき別の事柄に時間を使えるようになる。

以下はCopilotを使用した他の例だ。すべてAIが自動生成したものだ：

• シリアル通信で現在の変数の値を出力したいとき、バッファを宣言するだけで、Copilotはこの関数内の変数から僕が出力したいものを推測してくれる

• AVRタイマーの設定：どのレジスタを使うべきかはデータシートを読まなければ分からないが、Copilotが直接教えてくれる（僕が求めていたものではなかったが）

• コードの断片と関数から、Copilotは僕がstop関数を欲しがっているかもしれないと推測し、僕が求めていたものと非常に近い実装を出してきた

「だが、すべては基礎に立ち返るべきではないか」という反論があるのも分かっている。その通りだ。基礎がしっかりしているソフトウェアエンジニアにとって、これらは単なるツールに過ぎず、正しい心構えを持っていれば変化を恐れる必要はない。だが、ここからが僕にとって居心地の悪さを感じる部分だ。

Webページは単なる媒体に過ぎない

Web開発における多くのアプリケーションは「媒体」や「乗り物」に属している。例えば、ネット上でオンラインストアを開いて商品を売りたいとき、Webページは取引を成立させるためのツールとなる。しかし、オンラインストアのサイトだけがあっても、商品がなければ一銭にもならない。あるいは、開発者はNetflixに似た機能を持つサイトを作れるかもしれないが、映像制作、スタジオ、ポストプロダクション、配信ルートなどがなければ、Netflixのようなサイトを作ったところで誰もお金を払ってくれないだろう。PChomeのWebサイトは見た目が洗練されていないが、その背後にある物流追跡、倉庫管理、決済システムなどをしっかりと押さえている。これらはWebページ単体では到底生み出せないものだ。ブログにいくら奇抜で派手な機能を実装したところで、コンテンツがなければ読者を引きつけることはできない。

これらの例を通して僕が言いたいのは、Webページは多くの場合、単なる媒体に過ぎないということだ。僕にとって、Webページ単体で価値を創造することは極めて難しい。なぜなら、その価値は背後にあるサービスやプロダクトから生まれているからだ。

このこと自体に善悪はない。インターネットが誕生して以来、Webページはずっと媒体という役割を担い続けてきたし、それは今も変わっていない。しかし僕自身は、この「媒体」であるということに不安を覚え始めている。理由は単純で、直接的に価値を生み出すことができないからだ。一度そう思い始めると、まるで脆い砂の城の上に寄りかかっているかのような感覚に陥る。端的に言えば、他人の引き立て役で終わるのが悔しいのだ。媒体という立場にあっても改善すべき余地は常にあるし、媒体に価値がないわけではないと理解している。ただ先ほど述べたように、僕自身の心の折り合いがつかないだけなのだ。

Webページは巨大な抽象化に依存している

Web開発の本質は、HTML、CSS、JavaScript、そしてブラウザという4大要素に関わっている。そしてHTML、CSS、JavaScriptがどのように発展するかは、各ブラウザベンダーの実装にかかっている。

開発者からすれば、HTMLとCSSの構文やルールを理解し、JavaScriptを組み合わせれば、Webページを書き始めることができる。残りの部分はブラウザに任せておけばいい。HTMLがどのように画面にレンダリングされるのか？ JavaScriptはどのようにコンパイルされるのか？ JITの背後にある実装は何か？ HTTPリクエストはどのように確立されるのか？ 動画はどのようにエンコード・デコードされるのか？ これらを知らなくても問題はない。すべてブラウザが処理してくれる。もう一度強調しておくが、これらを理解しているかどうかに正解も不正解もない。ただ僕の心が納得できていないだけだ。しかし、僕はこうした抽象化に不安を感じてしまう。テクノロジーの発展の成果をただ享受しているだけに思えてしまうのだ。どんな技術にも背後には多かれ少なかれ抽象化の概念が存在することは分かっている。そうでなければ、すべての開発者が機械語から書かなければならなくなってしまう。だが、よくよく考えてみると、Webページの抽象化の度合いの高さには本当に圧倒される。

Webページはピラミッドの頂点に位置する

Webページがブラウザに依存しており、HTML、CSS、JavaScriptの仕様も完全にオープンである以上、あらゆる進化には提案、ドラフトから標準化決定、そして最終的なブラウザの実装を待つ必要がある。Chromeは他のブラウザをリードすることが多く、様々な実験的APIを提供してはいるものの、プラットフォーム限定のものであれば使用シーンは大幅に制限されてしまう。先ほど例に挙げたBluetoothやNFCなどは何年も前から存在しており、他のプラットフォームでは当たり前に使えたものだ。しかしWebにおいては、開発者はブラウザが実装してくれるのを待たなければ使えず、技術の発展には制約が伴う。

この感覚は、新しい技術が登場してからしばらく経ち、ブラウザにようやく実装されて大興奮しているものの、周りはとっくにその技術の存在を知っていて、すでに自らのサービスに取り入れているのを知ったときの感覚にとてもよく似ている。

まとめると

整理すると、僕の焦燥感の源は以下の点にある：

• Webページの大半は単なる「媒体」や「乗り物」であり、「直接」価値を提供しにくい
• フロントエンド領域の発展が成熟しつつある
• 大半のコードは単なるTranslation（翻訳）であり、AIに取って代わられ得る
• Webページ自体が巨大な抽象化に依存している

価値の創造

僕は「価値」について考えるという記事でも似たような概念に触れた。キッチンタイマーは見た目がおしゃれであれば、機能が単純であっても消費者は買ってくれる（薄利多売のビジネスモデルに価値があるかどうかは議論の対象外とする）。しかし、それと同じ価格でユーザーにソフトウェアを買ってもらうことがどれほど難しいことか。もう一つの例は、僕が最近愛用している SwitchBot だ。背後の仕組みを観察してみると非常にシンプルで、Bluetooth機能を備えたSoCで接続し、スマホアプリや各種主要サービスと連携させることで、優れたIoTアプリケーションに仕上がっている。

第一歩

僕は自分自身が、もっと価値の生産者に近いポジションに行きたいと願っている。ここ1年ほど、僕はずっとこの方向に向けて歩みを進めてきた。僕の第一歩は、ハードウェアやIoTアプリケーションの研究に向かうことだった。現在では非常に安い価格でArduino（中国製）、AVRチップ、Raspberry Pi Pico、STM32などの低消費電力マイコンボードが手に入る。ブレッドボード、はんだごて、電子部品を一通り買い揃えれば、すぐにでも実験を始められる。

この1年間を振り返ると、正直なところ迷いも深まっている。趣味レベルの開発の強度では、この業界で長くやってきたエンジニアと比べてまだ大きな開きがあるのは目に見えている。その一方で、関連分野（組み込み系？）の給与水準を見てみると、本当に転職する気が失せるほど低い。だが、迷いがあるのも良いことなのだろう。少なくとも今の生活にはこうしたものを研究する余力があり、しかもこれほど安価に手に入るのだから、本当にありがたいことだ。

よく考えてみると、僕の唯一の強みは実業高校時代に学んだことがほぼすべて活かせる点かもしれない。レジスタ、マルチプレクサ・デマルチプレクサ、加算器など、これらの回路には高校時代に散々苦しめられた。トランジスタ、増幅回路、発振器、整流、共振といった、当時はテストのために詰め込んだ知識が、今になってどれほど貴重なものだったかを実感している。

第二歩

僕の第二歩は、実験回路をより製品に近い形態に近づけることだ。基本的な3DプリントとFusion 360による3Dモデリングを学び、PCBの製造についての理解を試みた。例えば以前、静電容量無接点方式キーボードの仕組みを理解するために、自分でPCBを設計して実際にプリントしてみた。

その後、回路に誤りがあることが判明して一旦作業をストップせざるを得なくなったが、一連のプロセスを理解してみると、想像していたほど難しくはないと分かった。ただプロセスに慣れるための時間と根気が必要なだけであり、実際はどんな分野でも同じことだ。最近は他に片付けるべき用事があるが、一段落したら続きを再開できるだろう。いつか実際の完成形を見られる日を楽しみにしている。

第三歩：ハードウェアとソフトウェアの統合

先ほど、Webの技術発展はブラウザの実装に制約されると述べた。そのため、最近はより可能性の広いプラットフォームを模索している。現在はMacBookとiPhoneを普段の開発機およびメイン端末として使用しているため、まずはiOSから入門した。動画にあるのは、BluetoothモジュールをMacBookと接続し、ポモドーロタイマーの現在の状態をPCと連動させている様子だ。ブラウザを一層挟むことなく、CoreBluetooth を通じて直接接続し、PC側からステータスを操作できる。

ここでの例は非常にシンプルだし回路の見た目も不格好だが、僕が表現したい概念は、ハードウェアとソフトウェアの統合（あるいはIoTの統合）によって、価値をさらに高めることができるということだ。見過ごされがちだったポモドーロタイマーの通知も、物理的なブザーやLED表示を用いることで解決できる。これは他のアプリケーションにもそのまま応用できるはずだ。

第四歩

第四歩は、Linuxカーネルの理解を試みることだ。比較的小規模なアプリケーションであればAVRのようなマイコンで事足りるが、多くの組み込みアプリケーションはLinuxカーネルをベースに構築されているか、ドライバを書いてハードウェアを制御している。

この一歩は、僕にとってはまだ少し先の話になりそうだ。

次の一歩

正直なところ、次にどうすべきかは僕にも分からない。もし何かアイデアがあれば、ぜひ Twitter で教えてほしい。

こうして振り返ってみると、僕の価値に対する定義は「形のあるもの」に偏っているのだろうか？ 現段階では確かにその通りだ。ソフトウェアに比べれば、こうした物理的なモノのほうが価値を生み出しやすいと僕は考えている。とはいえ、機械学習、AIアプリケーション、ゲーム開発、データサイエンス、動画編集ソフトなど、この手のアプリケーションはソフトウェアであっても、僕にとって直接的に価値を生み出せるものだ。UIのインタラクションを書くのは今でも楽しいが、そろそろ他の領域に目を向けるべき時が来たのかもしれない。