キャリアのネクストステップ — Quick and Dirty

フロントエンドに触れ始めてから、もうすぐ10年を迎えようとしている。

情報系の学生なら大学でWebの授業を受けるのがお決まりで、当時はReactよりもAngularのほうが知名度が高かった。Vueもおそらくすでにリリースされていたはずだが、当時の僕はまだ知らなかった。

あの「フロントエンド戦国時代」を経験したことは、その後のフロントエンドの変化を理解し、実感を掴む上で非常に役に立っている。コミュニティの議論を振り返ってみると、何年も前にすでに議論し尽くされたような問題も多く、これが「年を取る（大人になる）」ということなのかとしみじみ感じる。

キャリア初期には、記事の執筆や登壇、個人プロジェクトの作成など様々な挑戦をしてきた。しかし、主な貢献といえば依然として会社のプロダクトやサービスの中に閉じたものにとどまっており、その点は僕にとって少し悔いが残る部分でもある。

ここでは、未来とキャリアに対する僕の考えをいくつか共有したいと思う。意見交換は大歓迎だ。

フロントエンドと未来に対する考え

最近、フロントエンドエンジニアの市場はすでに飽和傾向にあり、以前ほど仕事を見つけるのが容易ではなくなったと感じている。

フロントエンドを専門にしていないエンジニアであっても、あるいは少しPCに詳しくてコーディングに抵抗がない人ですら、ReactやVueのドキュメントに目を通し、使いやすいUIコンポーネントライブラリを見つけ、ChatGPTやローカルで動かすLLMを組み合わせれば、Webページをでっち上げるくらい造作もない。もちろん初心者ならデバッグに時間がかかるのは想像に難くないが。そうなると、フロントエンドエンジニアの価値はどうしても別の部分で発揮されなければならず、それは駆け出しのフロントエンドエンジニアが仕事を見つけにくくなることを意味している。

ここで、もう一つの方向性について話したい。

ジュニアエンジニアの大半は、自分をある特定の領域に位置づけがちだ。たとえば「フロントエンドはフロントエンドだから、Web以外のものには手を出さない」「要件を満たしてUIのマークアップをするだけ」といった具合に。短期的にはそうした需要も依然として存在するだろうが、参入障壁の低下とUIコンポーネントライブラリの成熟に伴い、そうした開発者は必然的にボトルネックに直面することになる。もし大半の要件が他の開発者でも満たせてしまったり、ビジネス要件をただコードに翻訳することしかできないのだとしたら、自分の価値は一体どこにあるのだろうか？

短期的・中期的に見て、僕自身の答えはソフトウェアエンジニアだ。

フロントエンドエンジニアである前に、まずは一人前のソフトウェアエンジニアであるべきであり、その上でフロントエンド領域への理解がより深い、という状態だ。

これにはコンピュータアーキテクチャ、アルゴリズム、データ構造、セキュリティなどが含まれる。もちろんこれらは大きな方向にすぎないが、知っていることが多ければ多いほど、物事を見る視点はおのずと広がる。たとえば、コンピュータアーキテクチャへの理解や、Arduinoをいじって各種の低レイヤープロトコルを理解すること、Svelteを学ぶ際に仕組みが気になって自作の簡易HTMLパーサーを書いてみることなどだ。これらはフロントエンドと直接の関係はあまりないが、課題に直面したときにより広い思考の幅を与えてくれる。

僕が出会ってきた技術力の高いソフトウェアエンジニアの多くは、まさにそうした人たちだった。彼らは必ずしもLeetCodeを何百問も解いているわけではないが、低レイヤーの動作原理を深く理解している。かつてある同僚が、加湿器を改造してリレーを組み込み、Arduinoからスイッチを制御できるようにしてタイマー機能などを実現したと、興奮気味に僕に話してくれたことがあった。

また、ドメイン知識をある程度理解しておくこともお勧めしたい。例えば以前、証券関連のサービスに携わっていた際、日本の法的規制やNISA制度、信用取引を理解し、さらにはクオンツ取引の勉強や外部サービス（私書箱など）との連携を行った。また、日本の放送の仕組みを調査した際には、簡易的な字幕アナライザーを書いたこともある。これらはすべて、他のエンジニアから一歩抜きん出るための重要な鍵となる。

もう一つの路線は、エコシステムに参入し、エコシステムを創造することだ。

Reactの登場は、業界におけるUI構築の方法を塗り替えた。UIを関数と状態管理に抽象化し、副作用を切り離して管理することで、UIを再利用可能な様々なコンポーネントへと分割できるようにした。

これはフロントエンドエンジニアが挑戦できるもう一つの道だが、会社の規模が十分に大きくない場合、着手できるポイントを見つけるのは難しく、オープンソースコミュニティから切り込むしかない。また、誰もがエコシステムを変革するほどの力を持っているわけではない。しかし、過小評価する必要もない。例えばSvelteの作者である Rich Harris は、もともとジャーナリストであり、ビジュアル報道のためにコードを書き続ける中でSvelteを生み出したのだ。

さらに別の路線として、フロントエンド領域の様々なサブジャンルを探求していく道もある。一般的に「フロントエンド」といえばWeb開発、より正確にはHTMLとJavaScriptでUIを構築することを指すことが多い。しかしブラウザの能力は日々進化しており、以下のような多岐にわたる分岐が生まれている。

• データ可視化（Data Visualization）
• アニメーション（UIアニメーション、トランジション、マイクロインタラクションなど）
• アクセシビリティ（Accessibility）
• Webゲーム
• WebGPUの応用。例えばLLMのWebプラットフォームへの移植や、WebGPUと組み合わせて従来はローカルでしか動かなかったアプリケーションをWebへ移植すること
• WebAssembly
• エフェクト・3D：WebGLやThree.js
• 各種IoTのWeb連携：WebSerial、Web Bluetooth、WebUSBなど。僕自身、この分野は市場が限定的でややニッチではあるものの、大きなポテンシャルを秘めていると感じている。例えば自作キーボード愛好家の間で必須とされる VIA は、Web上で直接キーマップを変更できるが、これはWebUSBを活用した好例の一つだ。
• 低レイヤープロトコル：WebRTCの応用や、最近登場したWebCodecs APIなど
• パフォーマンスチューニング

熟知している分野が多ければ多いほど、当然ながら代替されにくい存在になる。

フロントエンドの参入障壁が下がった（もともと高くはなかったが）とはいえ、SEO、パフォーマンス、アクセシビリティをすべて兼ね備えたWebページを作るには、依然として確かな経験が必要だ。現段階のLLMでも要件を満たすサイトを形作ることはできるかもしれないが、これらすべてを両立させるのは容易ではない。

その他の方向性

ソフトウェア開発の観点から言えば、CI/CDや自動デプロイ、バージョン管理、テストなども挑戦できる方向性だが、これらはソフトウェアエンジニアであれば自然と身につく範疇のものだと僕自身は思っている。デプロイ対象のサービスが複雑でない限り、多くの場合は設定ファイルを書くだけで大半のことができてしまうからだ。

できれば特定の産業、たとえば太陽光発電産業、飲食業界、サービス業などと組み合わせられると良い。興味のある産業の中からニーズを見つけ出し、MVP（実用最小限の製品）を作って検証を進めていけば、最終的にフロントエンドは目的を達成するための一つの手段にすぎないことに気づくはずだ。

最近、Pieter LevelsとLex Fridmanのポッドキャストを観たのだが、PHP、jQuery、MySQLを使い、プロジェクトの大半を独力で開発して、月に30万ドルを稼ぎ出している。

どれも古臭い技術だが、課題を解決できている。これも一つの方向性だと思う。サービスを作る、プロダクトを作るという発想で開発を行い、技術なんてものは十分役に立ちさえすればそれでいい。

このコアな理念は、Git 的故事：這一次沒這麼好玩 という記事にある、LinusがGitを書いた際の濱野純（Junio Hamano）氏とのやり取りにも少し似ている。（素晴らしい記事なので、一読をお勧めする！）

当時、Linusはマージアルゴリズムを書こうとしていたが、スクリプト言語のほうが適していると考え、手伝ってくれる人を募った。それを偶然目にした濱野氏がPerlで実装したバージョンを作ったのだが、それがまさに「素早く、そして泥臭い（Quick and Dirty）」ものだった。

Linusの返信にはこう書かれていた：

…Quick and Dirty That’s exactly what I wanted. Q ‘n’ D is how the ball gets rolling.

この言葉は僕の心に強く刺さった。優秀なエンジニアはまさにこうした資質を持つべきだと僕は思う。まずはQuick and Dirtyを目指し、残りは後から考えればいい。

キャリアに対する考察

これまで、コミュニケーション、リーダーシップ、マネジメントといったソフトスキルについては触れてこなかった。もちろんこれらも非常に重要だが、最近の僕の考えでは、ソフトスキルと技術は相互に作用し合うものだ。自分の技術を高めることは、同時に自身のコミュニケーション能力を強化することにもつながっている。

どうすれば昇進できるのか、どのプログラミング言語を学べば仕事が見つかりやすいのかと尋ねる人は多い。そうした考え方は何一つ間違っていないし、かつての僕自身もよくそんなことばかり考えていた。どうすればマネジメント職に上がれるか、どうすれば給料を上げられるか、と。

しかし、ある程度経験を積んだ後は、より良いキャリアを追い求めることを「目的」にしてはならず、それはあくまで「手段」であるべきだと僕は考えている。

会社で自分の好きなサービスやプロダクトを作ること自体が明確な目標であるなら話は別だが、そうでなければ、資本主義市場の観点から見て、僕たちは自分の時間を切り売りして金銭と交換しているにすぎない。そして時間だけを差し出して対価を得るというのは、あまりに割に合わない。

これは僕自身も試行錯誤しているところだ。もしそれなりの大企業に勤めているなら、人脈を広げ、関係性やリソースをうまく活用して、自分が学びたいことを学ぶよう努めることができる。人脈の蓄積は、たとえ会社を辞めたとしても持っていけるものだ。最近のプロジェクトの変更に伴い、現在の僕はバックエンド開発がメインになっているが、そこから以前は意識していなかった多くの視点を理解できるようになり、かなりの収穫を得られている。

最近しみじみと感じているのは、**「毎月の安定した給料は、精神安定剤であり、毒薬でもある」**ということだ。

ストレスを感じたとき、「あと数日耐えれば給料日だ」と考える。会社から与えられたタスクさえ終われば、早く仕事を切り上げて帰宅できる。こうした安定には一長一短があるが、現在の僕にとってはデメリットのほうが勝っている。

もちろん、これは僕の力不足や性格との不一致にも起因している。開発において大いに腕を振るえる場面があったとしても、ほとんどの場合は仕様書の要件に従って実装するだけで、ゼロからイチでプロジェクトを主導することは極めて難しい。大企業ともなれば、サーバーを1台立ち上げるだけでもセキュリティチェックの山や法務部門の審査を通過しなければならないのだから尚更だ。

数年前の僕も、そうした幻想を深く信じ込んでいた。

『スタンフォード式 最高の人生設計（Designing Your Life）』でも言及されているが、ジェームズ・カース（James Carse）が提唱した「有限ゲームと無限ゲーム」という概念がある。

有限ゲームであれば、僕たちは勝つためにルールに従ってプレイする。しかし無限ゲームであれば、ゲームをプレイし続けることそのものを楽しむ。

誰もが追い求める人生は異なり一概には言えないが、幼い頃から試験、競争、就活に至るまで、僕たちは「特定の目標さえ達成すれば人生は満ち足りたものになる」という固定観念を刷り込まれ続けてきたように思う。しかし実際には、往々にしてそうではない。

要するに僕の考えは、僕たちはキャリアの外側にあるものに目を向けるべきだということだ。より重要なのは「自分はどんな人生を送りたいのか」、そして「今やっていることは送りたい人生と一致しているのか」ということだ。

工場や製造業、IC（集積回路）など、物理的な制約を突破するのが難しい分野もある。今日仕事を辞めていきなり自分でICを設計し、ファブ（半導体工場）を立ち上げるなんてことは不可能だ。しかし、いまのキャリアが自分の目標と合致しているかどうかを、自らに問い直すことはできるはずだ。

これからは毎日自分にこう問いかけようと思う。「今日、君は Quick and Dirty に動けたか？」と。

もちろんキャリアにしても人生にしても、僕も同じように迷っている最中だ。何か思うところがあれば、ぜひ僕にシェアしてほしい。