なぜフロントエンドキャリアが難しいのか
フロントエンドは「ツールチェインの寿命が短い」「設計の標準解が定まらない」「UI と性能のトレードオフが多次元」という三重苦の領域です。React 一本足や CSS フレームワーク依存だけでキャリアを伸ばそうとすると、3 年で陳腐化します。本記事では 言語・ブラウザ API・設計・運用 の 4 軸を並行して伸ばすための、書籍ベースの 5 年プランを提示します。
ゴールは「自分でフレームワークを評価できる」「Web Vitals を継続的に改善できる」「チームのフロントエンド方針を書ける」テックリード水準です。
Phase 1: 基礎 (0–6 ヶ月)
最初に固めるのは HTML/CSS のセマンティクスと JavaScript の言語仕様 です。Tailwind や React から入った人ほど、ここが空洞になりがちです。
- HTML/CSS: ボックスモデル、Flex/Grid、Cascade、ARIA をハンズオンで写経。
- JavaScript: スコープ、
this、Promise、モジュール、イベントループまでを言語で説明できる状態に。 - DOM/Fetch/Storage: ブラウザ API を素手で扱える感覚を身につける。
この段階では フレームワークを使わず にミニアプリ (TODO・カレンダー・チャット) を 3 本作るのが効きます。
Phase 2: 実務レベル (6 ヶ月–2 年)
React / Vue / Svelte いずれかを「主軸フレームワーク」として選び、業務で 1 年回す 段階。並行して TypeScript・テスト・状態管理を学びます。
// 例: Svelte 5 Runes での派生状態
let count = $state(0);
let doubled = $derived(count * 2);
このフェーズでよくある失敗は「フレームワークの API カタログ知識ばかり増えて、設計が育たない」こと。タスク粒度を「機能 → コンポーネント → モジュール → サブシステム」に意識的に上げていきましょう。
Phase 3: 設計とパフォーマンス (2–4 年)
ここから差がつきます。Web Vitals (LCP/INP/CLS) を本番サービスで継続改善できるか、画面・データ・状態の境界 を設計できるかが評価基準。
- LCP < 2.5s を維持するための画像・フォント・JS バジェット。
- INP < 200ms を阻害するメインスレッドブロッキングの計測。
- 機能フラグ・A/B テスト・段階リリースの運用。
アーキテクチャ面では「Feature-Sliced Design」「Islands」「RSC」など複数の流派を比較して、自分のチームに合う形を言語化できると一気に上位互換になります。
Phase 4: テックリードへ (4 年〜)
コードを書く比率が下がり、意思決定と育成 が中心になります。フレームワーク移行・パフォーマンス予算・採用基準・オンコール体制までフロントエンド部隊全体を回す立場です。
- 半年単位で「やめる技術・置き換える技術」を提案できる。
- 新人が 3 ヶ月で戦力化する学習パスを設計できる。
- プロダクトマネージャと SLO レベルで会話できる。
つまずきポイントと脱出ルート
| つまずき | 典型症状 | 脱出ルート |
|---|---|---|
| 言語空洞化 | フレームワークの外で書けない | Phase 1 を 1 ヶ月かけて再走 |
| 設計の言語化不足 | レビューで「なんとなく」しか言えない | アーキテクチャ書 2 冊を読書会で |
| パフォーマンス未経験 | 体感だけで議論する | RUM を入れて数字で会話する |
書籍は「読むだけ」では身につきません。1 冊につき 1 アウトプット (社内 LT / ブログ / リファクタ PR) をセットでやることを強く推奨します。