Reactエンジニアのスキルシートの書き方｜面談で評価される実績の見せ方
公開 2026-10-29 監修：株式会社エージェントベスト
Reactエンジニアのスキルシートは、ReactとNext.jsなどの版・構成を書き、そのうえで「画面を実装した」「設計を決めた」「共通の部品を整えた」のどこを担ったかを書き分けるのが基本です。フロントエンドの経験は「画面を○枚作った」という書き方になりがちですが、読み手が知りたいのは画面の数ではなく、どんな課題をどこまで任されていたかです。
全体の構成はスキルシートの基本で解説しています。この記事では、Reactのエンジニアが書くときに押さえたい点に絞って説明します。
技術欄は「版」と「構成」をセットで書く
Reactの技術欄に「React、TypeScript」とだけ書くと、読み手は中身を推測できません。Reactは版や組み合わせるフレームワークによって、設計の考え方が大きく変わるためです。次の4つをセットで書くと、構成が一目で分かります。
| 項目 | 書き方の例 |
|---|---|
| Reactとフレームワークの版 | React 18→19、Next.js 14→15 |
| ルーティングと描画の方式 | App Router（サーバーで描画する部分あり）、Pages Router、SPAのみ など |
| データの取得と状態管理 | TanStack Query、Redux Toolkit、Zustand、Context など |
| スタイルとUI部品 | CSS Modules、Tailwind CSS、社内の共通コンポーネント など |
とくに、サーバーで描画する構成か、ブラウザだけで動く構成かは、案件との相性を判断する大事な情報です。Next.jsを使っていても、どのルーターを使っていたかで経験の中身が違います。求められる知識そのものはReactの案件で求められるスキルの記事にまとめているので、シートでは「どの構成で開発したか」が読み取れることを優先してください。
TypeScriptは、使っていたかどうかだけでなく、「型の厳しさの設定を上げた」「APIの型を自動で生成する仕組みを入れた」のような取り組みがあれば添えます。TypeScriptを軸にする方はTypeScriptエンジニアのスキルシートの記事も参考になります。
担当範囲を「実装・設計・共通部品」で書き分ける
Reactの案件は、決まった設計に沿って画面を実装する役割と、設計や共通部品の整備を任される役割とで、求められる経験が分かれます。シートでは、自分がどちらの役割だったかが分かるように書きます。
- 実装：デザインと仕様をもとに画面や機能を作った
- 設計：コンポーネントの分け方、状態の置き場所、ディレクトリの構成を決めた
- 共通部品：ボタンやフォームなどの共通コンポーネント、デザインシステムを作り、チームに広げた
- 周辺：API連携の仕様の調整、BFF（画面向けのAPI）の開発、テストやCIの整備
同じプロジェクトで複数を担った場合は、それぞれを別の行にします。「フロントエンド全般を担当」とまとめるより、「前半は画面の実装、後半はフォームの共通部品の設計と導入」と書くほうが、どの段階で何を任されたかが伝わります。
画面の数ではなく課題で書く
「管理画面を20画面作成」のような書き方は、量は伝わっても難しさが伝わりません。同じ1画面でも、入力項目の多いフォームと、一覧を表示するだけの画面では手間が違います。画面の数を書くなら、その中で難しかったことを1つ添えます。
- 「入力項目の多い申し込みフォームで、入力途中の保存と、項目ごとの検証を設計」
- 「大量の行を表示する一覧で、表示する行だけを描画する仕組みを導入」
テストの書き方も担当範囲として書く
フロントエンドのテストは、部品単位のテストと、ブラウザを動かして画面の流れを確かめるテストとで、役割が違います。「共通部品の単体テストを整備」「申し込みの流れをブラウザで確かめるテストを追加し、CIで自動実行」のように、どの種類のテストを、どの範囲で整えたかを書くと、品質に関わった深さが伝わります。
表示の速さとアクセシビリティの示し方
表示の速さの改善は、Reactの案件で評価されやすい経験です。シートには、何で測り、何を変え、どう変わったかを書きます。
- 測り方：Core Web Vitalsの指標、Lighthouse、ブラウザの開発者ツール、Reactのプロファイラーなど
- 変えたこと：読み込みの分割、画像の最適化、不要な再描画の削減、サーバーでの描画への切り替えなど
- 変化：どの指標がどう良くなったか
Lighthouseの点数は、測る環境によって変わります。点数を書く場合は、何を基準に測ったかを添えるか、「表示が始まるまでの時間を指標に改善」のように指標の種類と変化の方向で書くほうが、面談で説明しやすくなります。社外に出せない数値の扱いはスキルシートと守秘義務の記事をご覧ください。
アクセシビリティの取り組みも、書き方は同じです。「キーボードだけで操作できるように共通部品を直した」「画面読み上げで読まれる内容を確認し、ラベルを整えた」のように、何を確かめ、何を変えたかを書きます。
プロジェクト欄の記入例
次は書き方の型を示す例です。業種や規模はぼかしてあり、実在の案件ではありません。ご自身の経験に置き換えてください。
期間：○年○月〜○年○月（1年程度）
案件概要：toB向け SaaSの管理画面の開発
規模・立場：フロントエンドのチーム数名（後半は共通部品の担当）
担当工程：設計、実装、テスト、リリース
使用技術：React 18、Next.js（App Router）、TypeScript、TanStack Query、Tailwind CSS、Vitest、Playwright、Figma
担当内容：前半は請求まわりの画面の実装。後半は入力フォームの共通コンポーネントを設計し、既存の画面へ順に置き換えた
工夫・成果：サーバーのデータの取得を専用の仕組みに寄せ、画面ごとに重複していた取得処理を整理した。表示が始まるまでの時間を指標に、読み込みの分割で一覧画面の表示を速くした
この例では、構成（App Router、データ取得の仕組み）、役割の変化（実装から共通部品の設計へ）、測り方を添えた改善が読み取れる形にしてあります。
公開URL・GitHub・画面の画像の扱い
フロントエンドは、成果を見てもらいやすい分野です。ただし、業務で作った画面には守秘義務がかかることが多く、扱いには注意が要ります。
- 業務の画面の画像やURL：一般に公開されているサービスでも、「自分が担当した」と書いてよいかは契約によります。公開の可否を確かめてから載せてください
- GitHubのリポジトリ：個人で作ったアプリは、構成とコードの書き方を示す補足になります。READMEに構成と工夫した点を書いておくと、読み手が見るべき場所が分かります
- デザインとの連携：Figmaなどでデザイナーとやり取りした経験は、ツール名とあわせて「デザインの仕様のすり合わせを担当」のように書きます
個人の成果物は、実務の経験を補うものとして、シートの後ろの方に置くのが自然です。成果物の用意の仕方はReactエンジニアの独立の記事でも触れています。
よくある質問
クラスコンポーネントの経験しかありません。どう書けばよいですか？
そのまま正確に書いてかまいません。古い書き方で作られた画面の保守や、新しい書き方への置き換えを扱う案件では、判断材料になります。関数コンポーネントやフックを学習している場合は、実務と分けて「学習中」と書いておくと、面談での食い違いを防げます。
Vue.jsの経験もある場合、同じシートに書いてよいですか？
書いてかまいません。スキル一覧ではReactとVue.jsを分け、それぞれの期間と使い方の深さを書きます。Reactの案件に応募するときはReactの経験を上に並べます。Vue.jsを軸にする場合はVue.jsエンジニアのスキルシートの記事をご覧ください。
デザインも担当していた場合は、どう書けばよいですか？
デザインの作業は、実装と分けた行にします。「画面の構成案の作成」「既存のデザインの規則に沿った画面の追加」のように、どこまで自分で決めたかを書くと、読み手が任せられる範囲を判断しやすくなります。