SIerのバックエンド職人として5年
私は新卒でSIerに入り、Java/Spring Bootによる業務システムのバックエンド開発を5年やってきました。RESTful APIの設計、トランザクション境界の検討、N+1問題の解消、インデックス設計まで、サーバサイドの仕事は人並み以上に自信を持っています。
ただし、画面側はずっと「他チーム」の仕事でした。私が触るとしてもjQueryで$('#submit').on('click', ...)をいくつか書く程度。Reactという単語は知っていましたが、コンポーネントもJSXもVDOMも、概念として何を解決しているのかピンと来ていませんでした。
転機は5年目に転職した自社開発SaaSスタートアップです。「フルスタックで動ける人を採用している」と聞いてはいましたが、入社初日に渡されたチケットがNext.jsの管理画面の改修で、私は完全に固まりました。
コンポーネント思考の壁
最初の数週間は、率直に言って苦痛でした。バックエンド脳の私は、画面を「ページ単位」で考えます。/users/editに飛んだら、サーバがHTMLを返す。あのメンタルモデルが染み付いています。
ところがReactでは、画面は「コンポーネントツリー」として組まれていて、UserEditPageの中にUserFormがあり、その中にInputFieldがあり、stateは親が持っているのか子が持っているのか、useEffectは何回走るのか、依存配列に何を入れるのか……毎日デバッグでconsole.logを撃ちながら、画面が無限ループしては謝るような日々でした。
特に挫折しかけたのがTypeScriptです。Partial<Pick<User, "name" | "email">>のような型を読むと、頭の中でJavaのジェネリクスに翻訳しようとして、毎回失敗していました。
救われた選書: 設計脳をフロントに転用するために
最初に読み切ったのが『プロを目指す人のためのTypeScript入門』(通称ブルーベリー本)でした。型システムを「制約を表現するDSL」として捉え直す視点を得て、ジェネリクスやUnion型の使いどころが急に立体的に見えるようになりました。バックエンド時代に書いていたJSON Schemaが、TypeScriptの型と地続きであることに気づいたのも、この本のおかげです。
次に手に取ったのが『りあクト!』です。3部構成のうち言語編を一気読みし、関数型のmap/filter/reduce、不変性、useStateとuseReducerの使い分けまで、コンポーネント思考の地盤がここで固まりました。「Reactは関数の集まりであって、クラス階層ではない」という当たり前のことに、ようやく腹落ちしたのです。
実装力をつけるためには『TypeScriptとReact/Next.jsでつくる実践Webアプリケーション開発入門』を写経しました。SSR/CSRの境界、Server ComponentとClient Componentの責務分離は、私のサーバサイド経験と意外なほど相性がよく、ここで一気にフルスタック視点が組み上がりました。
CSSは長年の苦手分野でしたが、『CSS設計完全ガイド』でBEMやFLOCSSの命名規則を体系的に押さえ、CSS変数とカスケードの仕組みを理解した時点で、デザイナーさんとの会話が劇的に楽になりました。
現場での実践: 既存コードのリファクタリング
入社半年後、私は既存のNext.js管理画面のリファクタリングプロジェクトに参加しました。バックエンド時代に培った「責務分離」の感覚を、コンポーネント分割に持ち込みました。フォームのバリデーションをカスタムフックとして抽出し、API呼び出しをデータレイヤとして切り出す。これはバックエンドのレイヤードアーキテクチャと同じ発想です。
パフォーマンスチューニングでは『超速! Webページ速度改善ガイド』を片手に、Next.jsのImage最適化、useMemoの効きどころ、不要な再レンダリングのプロファイリングなどを地道に潰しました。Lighthouseのスコアが62から94まで上がったとき、初めて「フロントエンドも工学だ」と確信しました。
テストは『フロントエンド開発のためのテスト入門』をベースに、Testing Libraryでコンポーネントの振る舞いをテストし、PlaywrightでE2Eを整備しました。
バックエンド出身者がフロントに行く意義
1年経った今、私はAPIもUIも触るフルスタックエンジニアとして仕事をしています。設計レビューでバックエンドとフロントを横断して議論できる人材は意外と少なく、「APIのレスポンス形がフロントの実装難度を決める」という当たり前のことを両側から語れることに、希少性が出てきました。
これからフロントに踏み出すバックエンドエンジニアの方には、「設計力は捨てなくていい、翻訳するだけ」と伝えたいです。コンポーネント分割はクラス分割と地続きですし、型はAPIの契約と地続きです。