ポートフォリオを求めるフロントエンド職の求人は1割未満
Offers の正社員求人のうちタイトルにフロントエンドを含む求人151件で、必須条件・歓迎条件・選考の流れのどこかに成果物や社外へのアウトプットの語が出てくるのは14件(9.3%)でした(Offers(株式会社overflow)調べ・フロントエンド職の正社員求人 n=151・2022年6月〜2026年5月公開)。
経験者の書類選考は職務経歴書が中心で、ポートフォリオは提出を求められたときや、職務経歴書だけでは伝わらない判断を見せたいときに使うものです。
語が出てくる14件を、求人のどこに書かれていたかで分けると次のとおりです。
求人のどこに出てくるか | 件数 | 書かれ方 |
|---|
必須条件 | 2件 | OSS(オープンソースソフトウェア)への貢献・自作ライブラリの公開の経験が1件、ポートフォリオの提出が1件(デザイナー兼務の求人) |
歓迎条件 | 9件 | OSS の公開・貢献・コミュニティでの活動が8件、技術イベントでの登壇が1件 |
選考の流れ | 4件 | ソースコードやポートフォリオを「あれば」共有・提出する任意の書き方が3件、提出を求めるものが1件(必須条件と同じ求人) |
出所: Offers(株式会社overflow)調べ・フロントエンド職の正社員求人 n=151・2022年6月〜2026年5月公開。
必須条件でポートフォリオの提出を求めた1件は、タイトルが Web デザイナーとフロントエンドエンジニアの兼務の求人で、デザイナーの職務を含むものでした。フロントエンドエンジニアだけの職務の求人で、ポートフォリオの提出を必須とするものはありません。歓迎条件に出てくる語も、作品や制作物ではなく OSS(オープンソースソフトウェア)への貢献が中心です。
デザイナーの職務を含む求人に応募するなら、ポートフォリオの求められ方はデザイナー職に近くなります(ポートフォリオとは|IT職の転職で求人が見る中身)。
同じ151件のうち、選考の流れにコーディングテストや技術課題を書く求人は21件(13.9%)、必須条件に「◯年以上」の経験年数を書く求人は75件(49.7%)ありました。
まずは職務経歴書で実績を書き切り、ポートフォリオはそれを補う位置に置くのが順番です。職務経歴書の構成はエンジニアの転職活動時の職務経歴書の書き方で扱っています。
必須条件のGitHubは主にチーム開発の経験を指す
フロントエンド職の求人の必須条件に GitHub が出てくる10件(6.6%)のうち9件は GitHub を開発の道具として使った経験を求める書き方で、うち7件は「GitHubを利用したチームでの開発経験」のようにチームや複数人での開発を明記していました。プルリクエストやレビューまで書くのは、この7件のうち1件です。10件の残る1件は、AI ツールを並べた中の GitHub Copilot でした。
必須条件の GitHub は、公開リポジトリの提出ではなく、GitHub を使った開発の進め方(多くはチームでの開発)を聞いていると読むのが自然です。公開リポジトリが無くても、職務経歴書にブランチの運用やコードレビューで自分が担った役割を書けば、この条件には答えられます。
フロントエンド職の求人が条件に書く技術と観点
フロントエンド職の求人の必須条件で最も多い技術は React で、151件のうち76件(50.3%)が書いています(Offers(株式会社overflow)調べ・フロントエンド職の正社員求人 n=151・2022年6月〜2026年5月公開)。
ポートフォリオで見せる技術は、応募先の求人がどのフレームワークを書いているかに合わせて選ぶのが基本です。
技術 | 必須条件に出てくる求人 | 歓迎条件に出てくる求人 |
|---|
React | 76件(50.3%) | 35件 |
TypeScript | 55件(36.4%) | 15件 |
Vue.js・Nuxt | 52件(34.4%) | 28件 |
Next.js | 18件(11.9%) | 24件 |
出所: Offers(株式会社overflow)調べ・フロントエンド職の正社員求人 n=151・2022年6月〜2026年5月公開。
技術名のほかに、求人は設計や品質の観点も条件に書いています。必須条件か歓迎条件のどちらかに出てくる求人の件数は次のとおりです。
観点 | 必須か歓迎に出てくる求人 | 数えた語の例 |
|---|
設計・アーキテクチャ | 70件(46.4%) | 設計、アーキテクチャ |
デザイナー・Figma の語 | 20件(13.2%) | デザイナー、Figma |
パフォーマンス | 19件(12.6%) | パフォーマンス、表示速度、高速化 |
テスト | 16件(10.6%) | テストコード、単体テスト、E2E、Jest、Vitest、Playwright |
デザインシステム | 12件(7.9%) | デザインシステム、Storybook、コンポーネント設計、Atomic Design |
アクセシビリティ | 9件(6.0%) | アクセシビリティ、a11y |
出所: Offers(株式会社overflow)調べ・フロントエンド職の正社員求人 n=151・2022年6月〜2026年5月公開。
デザイナー・Figma の語が出てくる20件の中身は一様ではなく、デザイナーとの協業・連携を書く求人が8件、Figma などデザインツールの利用経験・知識・操作を書く求人が8件、応募者自身の UI(ユーザーインターフェース)デザインの経験を求める求人が4件でした。
パフォーマンスとテストを書く求人は1割強、アクセシビリティを書く求人は1割未満ですが、書いている求人の中には「パフォーマンスチューニングの実績」「Reactコンポーネントに対するテストコードの実装経験」「アクセシビリティを考慮したマークアップおよびそのテストを実装できる」のように、経験の中身まで指定するものがあります。
こうした条件と突き合わせてもらうには、フレームワークの名前を並べるより、設計で何を決め、品質をどの数値まで上げたかを見せるのが近道です。フロントエンドエンジニアに求められるスキルの全体像は、フロントエンドエンジニアのキャリアパスと必要なスキルにまとめています。
経験者の転職用ポートフォリオに載せる4つの要素
経験者のフロントエンドエンジニアが転職用ポートフォリオに載せるのは、職務の要約、業務の実績のケース、公開できるコード、品質の数値の4つです。どれも職務経歴書に書いた内容を、読み手が別の角度から確かめられるようにするためのものです。
要素 | 書く中身 | 読み手が確かめること |
|---|
職務の要約 | 経験年数、担当したプロダクトの種類、主に使った技術、チームでの役割 | 求人の必須条件の年数と技術に届いているか |
業務の実績のケース(2〜3件) | 課題、自分の役割、技術の判断、結果 | 設計の判断ができるか、成果を数字で説明できるか |
公開できるコード | 個人で開発したアプリ、OSS への貢献、技術の検証用のリポジトリ | コードの書き方、テストの書き方、コミットの粒度 |
品質の数値 | 表示速度の指標、アクセシビリティの対応範囲、テストの範囲 | 品質を測って改善した経験があるか |
経験者の転職用ポートフォリオで読み手が知りたいのは、作ったものの見た目より、業務の中でどの判断を自分が持っていたかという点にあります。作品の点数を増やすより、業務の実績のケースを丁寧に書くほうに時間を使いましょう。
業務の実績のケースは課題・役割・判断・結果の順で書く
業務の実績のケースは、1件ごとに課題、自分の役割、技術の判断、結果の4項目をこの順で書くと、読み手が判断の筋道を追えます。次は表示速度の改善を書いた例です(数値は伏せ字)。
項目 | 書く内容の例 |
|---|
課題 | 商品一覧ページの表示が遅く、スマートフォンからの離脱が多かった |
役割 | フロントエンド3名のチームで、計測の設計と改修の方針を担当した |
技術の判断 | 画像の遅延読み込みとサーバー側での描画への切り替えを比べ、改修の範囲が小さい前者から着手した。後者は次の四半期に回した |
結果 | LCP(75パーセンタイル)が◯秒から◯秒に縮み、スマートフォンからの離脱率が◯ポイント下がった |
技術の判断の項目には、選ばなかった案とその理由も1行添えます。採用する側が見るのは、正解を選んだかどうかより、比べた案と決め手を説明できるかです。社外に出せない数字なら、改善の向きと比率(「約半分に縮めた」など)で書けば足ります。
公開できるコードはREADMEで読む順番を案内する
公開リポジトリを載せるときは、README(リポジトリの説明書き)に何のためのコードか、使った技術と選んだ理由、動かし方、見てほしいファイルを書き、読み手が最初に開く場所を案内します。リポジトリ全体を読んでもらえるとは限らないため、見てほしいコンポーネントの設計やテストのファイルを名指ししておくと、評価してほしい箇所がぶれません。
個人で開発したアプリは、業務で使っていない技術を試した記録として位置づけるのが、職務経歴書と役割を重ねない置き方です。応募先が Next.js を書いていて業務では使っていないなら、同じ機能を Next.js で組み直し、違いを README にまとめておくと、その差を埋めた記録になります。テストと CI(継続的インテグレーション)の設定まで含めておくのは、求人のテストの条件にもそのまま答えられるからです。
ポートフォリオと職務経歴書をそろえたら、同じ内容を転職サービスのプロフィールにも登録できます。Offers は、エンジニア・PdM・デザイナーの正社員の中途転職に絞ったサービスで、登録したスキルと経験を見た企業からスカウトが届きます。
品質は公開された基準の数値で示す
フロントエンドの品質を示すときは、「速くした」「使いやすくした」と書く代わりに、Google の Core Web Vitals や W3C の WCAG(Web Content Accessibility Guidelines)のような公開された基準に照らした数値と達成状況で書くのが、読み手が他の応募者と同じ物差しで比べられる書き方です。
求人の側は「Core Web Vitals」「WCAG」の語そのものを1件も書いていませんが、パフォーマンスやアクセシビリティの経験を確かめるとき、共通の基準で書かれた実績は読み違えが起きにくくなります。
表示速度と応答性はCore Web Vitalsの3指標で書く
Core Web Vitals は、読み込みの LCP(Largest Contentful Paint)、操作への応答性の INP(Interaction to Next Paint)、表示の安定性の CLS(Cumulative Layout Shift)の3指標で、Google はそれぞれの良好の目安を LCP 2.5秒以内、INP 200ミリ秒以下、CLS 0.1以下としています(Google web.dev「ウェブに関する主な指標」)。
評価の単位は、モバイルとデスクトップに分けたページ読み込みの75パーセンタイルです。
指標 | 測るもの | 良好の目安 |
|---|
LCP(Largest Contentful Paint) | 読み込みの速さ | 2.5秒以内 |
INP(Interaction to Next Paint) | 操作への応答の速さ | 200ミリ秒以下 |
CLS(Cumulative Layout Shift) | 表示のずれの少なさ | 0.1以下 |
出所: Google web.dev「ウェブに関する主な指標」(2024年10月31日最終更新)。
INP は2024年3月に FID(First Input Delay)に代わって Core Web Vitals の安定版の指標になり、Chrome は FID から INP への移行期限を2024年9月9日としました(Google web.dev の告知のブログ記事・2024年3月12日更新)。
数年前の改善の実績を FID で書いている場合は、今の指標で測り直せるかを確かめておくと、面接で指標の変化を聞かれても答えられます。
ポートフォリオに書くのは、改善前と改善後の値、測った方法(実際の利用者のデータか、手元での計測か)、何を変えたかの3点です。
アクセシビリティはWCAG 2.2の達成基準で書く
アクセシビリティの対応は、WCAG 2.2 のどの達成基準をどの適合レベル(A・AA・AAA)で満たしたかで書くと、対応の範囲が伝わります。WCAG 2.2 は WCAG 2.1 に9つの達成基準を足し、4.1.1 構文解析を削除したもので、ウェブアクセシビリティ基盤委員会が2024年12月12日付けの W3C 勧告を日本語に訳して公開しています(WAIC「WCAG 2.2 日本語訳」)。
新しい達成基準のうち、2.4.11 隠されないフォーカス (最低限) と 2.5.8 ターゲットのサイズ (最低限) はレベル AA で、キーボードで操作したときのフォーカスの見え方や、ボタン・リンクの押せる範囲の大きさという、フロントエンドの実装がそのまま問われる基準です。ポートフォリオに書くのは、対応した達成基準の番号、確かめた方法(キーボードだけでの操作、スクリーンリーダー、自動チェックのツール)、残っている課題です。
テストは対象と粒度を書く
テストの経験は、「テストを書いた」ではなく、単体・結合・E2E のどの粒度で、どのコンポーネントや画面を対象に、どのツールで書いたかを書きます。求人の中にも「テスト(単体 / 結合 / E2E)いずれかの実装経験」「JestやVitestなどによる単体テストの経験」のように、粒度やツールまで指定する書き方があります(Offers(株式会社overflow)調べ・フロントエンド職の正社員求人 n=151・2022年6月〜2026年5月公開)。
CI の上でテストが回る構成や、テストを足したあとに減った不具合の件数を添えるのが、テストを運用した経験を示す近道です。
業務で書いたコードは会社の著作物として扱う
業務で書いたコードは、職務著作の要件を満たすと著作者が会社になるため、本人の判断だけでポートフォリオに載せたり公開リポジトリに置いたりはできません。文化庁は、会社の企画にもとづき、業務に従事する人が職務上つくったもので、契約や就業規則に別の定めが無いなどの要件をすべて満たすと会社が著作者になるとし、プログラムの著作物は会社の名義で公表するという要件を満たさなくてもよいとしています(文化庁著作権課「著作権テキスト -令和7年度版-」)。
業務の実績は、コードではなく文章と図で書き直すのが基本です。社名・顧客名・公開前の機能名・社内の数値を伏せ、課題と判断の構造だけを残せば、守秘義務に触れずに設計の力を見せられます。公開中のサービスの画面を載せる場合も、勤務先の規程や秘密保持の契約で許される範囲かを先に確かめておきましょう。業務の成果物を社外に見せるときの確認点は、エンジニアの転職に成果物は必要か|経験者の実績の示し方で詳しく扱っています。
ポートフォリオサイトそのものも実装の見本として見られる
ポートフォリオを Web サイトで作るなら、サイトそのものもフロントエンドの実装の見本として見られると考え、凝った演出より表示速度とアクセシビリティを優先するのが安全です。アニメーションを重ねたサイトより、スマートフォンでもすぐに表示され、キーボードだけで読み進められるサイトのほうが、前の節で書いた品質の主張と食い違いません。
形式は、職務経歴書に書ける1つの URL にまとめるのが基本です。静的なサイトで十分で、書類選考で開かれることを考えて、同じ内容をまとめた1つの文書ファイルも用意しておくと、提出の形式を指定されたときに困りません。自分のサイトの Core Web Vitals を測り、良好の目安に入っていることを確かめてから応募しましょう。
面接ではポートフォリオを判断の理由から説明する
面接でポートフォリオを説明するときは、作ったものの機能の紹介から入らず、どの課題に対してどの技術を選び、何を捨てたかという判断の理由から話します。Offers のフロントエンド職の求人151件のうち、選考の流れにコーディングテストや技術課題を書く求人は21件(13.9%)でした(Offers(株式会社overflow)調べ・フロントエンド職の正社員求人 n=151・2022年6月〜2026年5月公開)。
選考の流れに試験を書く求人では、面接とは別に試験でも実装の力を見られます。面接では、ポートフォリオに書いた判断を言葉で説明できるように準備しておきましょう。
ポートフォリオを見せる面接では、次の3つの問いへの答えを用意しておきましょう。
- その技術を選んだ理由と、比べた別の案
- もう一度作るなら変えるところと、その理由
- チームで意見が分かれたときに、どう合意を取ったか
フロントエンドエンジニアの転職用ポートフォリオの要点
経験者のフロントエンドエンジニアにとって、ポートフォリオは職務経歴書の実績を裏づける補強材料で、Offers のフロントエンド職の求人151件で成果物の語が条件や選考に出てくるのは14件(9.3%)でした(Offers(株式会社overflow)調べ・フロントエンド職の正社員求人 n=151・2022年6月〜2026年5月公開)。
作る場合は、作品の数ではなく、業務での判断と品質の数値を読み手が確かめられる形にします。
- 求人の必須条件の GitHub は、公開リポジトリではなく GitHub を使った開発の経験を聞いている(10件のうち7件はチーム開発と明記)
- 載せる中身は、応募先の求人が書くフレームワークと、設計・パフォーマンス・テスト・アクセシビリティの観点に合わせて選ぶ
- 業務の実績は、課題・役割・技術の判断・結果の順で書き、選ばなかった案も添える
- 品質は、Core Web Vitals や WCAG 2.2 のような公開された基準の数値で書く
- 業務で書いたコードは会社の著作物になりうるため、文章と図で書き直して載せる
ポートフォリオを整えたら、自分の経験がどの企業に評価されるかを確かめてみましょう。Offers にスキルと経験を登録すると、正社員のエンジニアを探している企業からスカウトが届き、ポートフォリオで示した強みがどの求人と合うかが見えてきます。