フロントエンド転職、実務経験浅い人は何を作るべきか

「ポートフォリオサイトのアクセス解析、見てみたんですけど」と切り出した候補者が見せてくれた画面には、平均滞在時間11秒、直帰率92%という数字が並んでいました。作品自体はUdemy教材のToDoアプリで、動作はする。でも採用担当者はおそらく数秒で離脱していたはずです。

私はIT・Web業界を中心に800名以上の転職支援に携わっていますが、フロントエンドエンジニアの相談で「ポートフォリオに何を作ればいいか分からない」という悩みは、実務経験が浅い人ほど頻繁に出てきます。今回は、模写コーディングだけで止まらないための題材選びと、「何を考えて作ったか」を伝える書き方を、実際の相談事例を交えてお伝えします。

目次

1. フロントエンドエンジニアの転職でポートフォリオが埋もれる理由
2. ポートフォリオを作る手順、遠回りしないための4ステップ
3. GitHubとポートフォリオサイト、両方いるのか
4. 実務経験が浅い人ほど「機能要件」で差がつく
5. 認証機能とAPI連携が効く理由
6. CRUD操作とエラーハンドリングも侮れない
7. テストとアクセシビリティまで意識すると、さらに差がつく
8. READMEと制作意図の書き方、BさんのBefore/After
9. 評価を下げてしまうNGパターン
10. 面接で聞かれること、逆質問への備え方
11. よくある疑問に答えます
12. ポートフォリオは何個必要ですか
13. 作成期間の目安はどれくらいですか
14. テンプレートを使うのはNGですか
15. 面接でポートフォリオのコードをどこまで細かく見られますか
16. 公開方法はVercelとNetlifyのどちらがいいですか
17. 未経験・実務経験が浅い状態から、転職までどれくらいかかりますか
18. まとめ、模写を卒業して「判断の跡」を残す

フロントエンドエンジニアの転職でポートフォリオが埋もれる理由

模写コーディングそのものが悪いわけではありません。デザインカンプ通りにコーディングする練習は、CSS設計やレスポンシブ対応の基礎を身につける段階では十分に意味があります。問題は、その模写を「ポートフォリオの最終成果物」としてそのまま提出してしまうことです。

採用担当者は同じような構成の作品を、1週間に何十件も見ています。有名なUdemy教材のToDoアプリ、カフェサイトの模写、ニュースサイトのクローン——これらは題材が被りやすいだけでなく、実装の中身まで似通っていることが多く、見た瞬間に「またこのパターンか」と流し見されてしまいます。

ここで相談に来たのがBさん、24歳、実務経験1年半のフロントエンドエンジニアです。受託のWeb制作会社に勤めていて、担当業務はコーポレートサイトのコーディングが中心。デザインカンプをHTML・CSSに落とし込む作業がほとんどで、ReactやVueを業務で触る機会はありませんでした。独学で学んだフロントエンド技術を武器に、自社開発企業のフロントエンドポジションへの転職を目指していました。

応募した11社のうち、書類選考を通過したのは0社。原因を一緒に探るなかで、ポートフォリオサイトに掲載していたのがUdemy教材のToDoアプリ1本だけだったことが分かりました。READMEは空欄、機能はタスクの追加と削除のみ。作れることは伝わっても、何を考えて作ったかが一切伝わらない構成になっていました。

ポイント： 実務経験が浅い人ほど、題材の目新しさよりも「機能要件の解像度」で差がつきます。何を作ったかより、なぜその仕様にしたかが見られています。

ポートフォリオを作る手順、遠回りしないための4ステップ

題材が決まっても、いきなりコードを書き始めると手戻りが多くなります。私が候補者に勧めているのは、技術選定・情報設計・実装・公開の4ステップです。

求人票にReactと書いてあるのにVueで作ってしまうと、面接で「なぜこの技術を選んだのか」を聞かれたときの説明が弱くなります。技術選定は1週間以内で片をつけ、応募したい企業の求人票で使われている技術スタックに合わせるのが基本です。

面接官がどの順番で画面を見るかを想像できているかどうかで、情報設計の出来は決まります。トップページには一番見せたい作品を先頭に置き、自己紹介・スキル一覧・作品詳細・連絡先へのリンクまで、迷わずたどり着ける導線を作ります。作品を複数並べる場合も、力を入れた1本を最初に配置し、それ以外は補足的な位置づけにとどめてください。

ロゴを並べただけのスキル一覧は、実はほとんど何も伝えていません。「実務で使ったことがある」「独学で個人開発に使った」「軽く触った程度」のように経験の深さを区別して書いておくと、面接官が的外れな質問をせずに済み、逆にこちらの誠実さも伝わります。いきなりFigmaでワイヤーフレームを作る必要はなく、紙やホワイトボードで画面同士のつながりを描いてみるだけでも、実装中の迷いは大きく減ります。

デザインの作り込みは後回しにして構いません。実装段階でまず優先すべきは機能要件を満たすことで、実務経験が浅い人ほどデザインに時間をかけすぎて機能実装が手薄になりがちです。CRUD操作やエラーハンドリングが一通り動く状態を先に完成させ、見た目の調整は最後にまとめて行う方が、途中で挫折しにくくなります。

公開先に悩む必要はありません。VercelやNetlifyのような無料のホスティングサービスで十分で、独自ドメインを取る必要もなく、発行されたURLをそのままGitHubのプロフィールや職務経歴書に載せれば問題ありません。公開設定を終えたら、応募直前だけでなく数日置いてからもう一度アクセスして、ビルドが壊れていないか確認する癖をつけてください。

ここまで含めて1ヶ月〜1ヶ月半で仕上げるのが目安です。業務が忙しく個人開発の時間が取れない場合は、機能要件を6つ全部詰め込もうとせず、認証機能とCRUD操作の2本柱に絞ってでも完成させることを優先してください。未完成のまま機能を増やし続けるより、小さくても完成させた作品の方が評価されます。

GitHubとポートフォリオサイト、両方いるのか

「GitHubとポートフォリオサイト、両方用意すべきですか」という質問もよく受けます。結論から言うと、役割が違うので両方あった方がいいですが、優先順位はポートフォリオサイトの中身が先です。

GitHubは制作の過程を見せる場所です。コミットログの粒度、ブランチの切り方、プルリクエストの説明文の書き方まで、実際にどう手を動かしたかが可視化されます。GitHubのコミット頻度そのものについては、以前GitHubコミット少ないエンジニア転職、面接の通し方でも詳しく書きましたが、量よりも「何を選び、何を諦めたか」を言語化できているかが評価の分かれ目になります。

一方でポートフォリオサイトは完成品としての体験を見せる場所です。実際に触ってもらい、レスポンシブ対応やローディング時の挙動、フォームのバリデーションといった細部まで含めて「この人がどんなUIを作る人か」を判断されます。採用担当者は基本的にポートフォリオサイトを先に開き、気になった実装があればGitHubのソースコードに移動する、という順番で見ることが多いというのが現場の実感です。

両方を用意する余力がなければ、まずポートフォリオサイト1本の完成度を上げることを優先してください。GitHubは公開リポジトリさえきちんと整理されていれば、面接の場で画面共有しながら説明する形でも十分にカバーできます。

リポジトリの整理という点では、コミット履歴を機能単位で分け、コミットメッセージに「何を」「なぜ」変更したかを一言添えるだけでも印象が変わります。1人で開発していてもプルリクエストを立てて自分でマージする形にしておくと、チーム開発を意識した進め方だと伝わりやすく、面接で「開発フローで意識したことは」と聞かれたときの答えにもなります。

実務経験が浅い人ほど「機能要件」で差がつく

上位に出てくる転職ノウハウ記事の多くは「Webサイトやアプリケーションを作りましょう」という抽象的な提案で終わっています。ですが実際に評価が分かれるのは、題材のジャンルではなく、その中に実務でよく出てくる機能要件がどれだけ入っているかです。

実務のフロントエンド開発では、ゼロから画面を作る機会よりも、既存の画面に機能を足したり、APIの仕様変更に合わせて表示を直したりする作業の方が圧倒的に多くを占めます。つまり採用担当者が知りたいのは「見た目をゼロから作れるか」ではなく「動いているものの内部構造を理解し、変更を安全に加えられそうか」です。この視点を持つと、題材選びの基準も自然と変わってきます。

私が候補者に勧める機能要件は、次の6つです。実務でこの全部を使わない現場もありますが、少なくとも一覧・検索・登録・編集の流れを体験しておくと、どんな求人にも話を合わせやすくなります。単体で全部盛り込む必要はありませんが、最低でも3〜4個は組み合わせてください。

具体的な題材としては、単純なToDoアプリより「在庫管理」「予約管理」「タスク進捗管理」といった、業務システムを模した管理画面の方がおすすめです。理由は単純で、実務のフロントエンド開発の大半は、こうした一覧・検索・登録・編集の繰り返しで構成されているからです。派手なランディングページより、地味な管理画面の方が「入社後に何を任せられそうか」を採用担当者が想像しやすくなります。

認証機能とAPI連携が効く理由

認証機能を入れると評価が上がりやすいのは、ログイン状態の管理・保護されたルートへのアクセス制御・トークンの扱いといった、業務でほぼ必ず出てくる設計判断が凝縮されているからです。単に「ログインフォームを作った」だけでなく、未ログイン状態でアクセスされたときにどう振る舞うかまで実装しておくと、それだけで一段階深い設計をしている印象になります。

外部API連携を選ぶ場合も、天気予報やニュース一覧のような単純な表示だけで終わらせず、ページネーションやエラーハンドリングまで実装しておくと評価が変わります。実務では「APIが失敗したときにどう表示するか」「読み込み中に何を見せるか」を必ず設計します。この非同期処理まわりの判断こそ、面接官が一番聞きたがるところです。たとえばGitHub APIを使って自分のリポジトリを検索・ソートできるアプリは、フロントエンドエンジニア自身の文脈にも合っていて、面接で話が広がりやすい題材の一つです。

模写止まりの題材	実務を意識した機能要件
ToDoアプリ(追加・削除のみ)	タスク管理(担当者割当・期限・フィルタ・ステータス別ソート)
カフェサイトの模写	予約管理画面(空き状況の検索・重複予約のバリデーション)
天気表示アプリ	外部API連携(ページネーション・検索・エラー時のリトライ導線)
静的なポートフォリオページ	認証付き管理画面(ログイン状態によるルート制御)

技術選定については、React・Vueどちらを使うべきかという質問も多いのですが、これは正直どちらでも構いません。応募先企業の求人票に記載されている技術スタックに合わせるのが一番効率的で、両方経験があるなら、より深く使い込んだ方を選んで一貫性を出す方が、器用貧乏に見えるより印象がいいというのが私の感覚です。

CRUD操作とエラーハンドリングも侮れない

CRUD操作は地味に見えますが、一覧・詳細・作成・編集・削除の5画面を矛盾なく繋げるだけで、状態管理の設計力が透けて見えます。編集画面で更新した内容が一覧にすぐ反映されるか、削除時に確認ダイアログを挟むか、こうした細部の作り込みが「実務で使えるレベルか」を判断する材料になっています。

エラーハンドリングも同様です。API通信が失敗したときに白い画面のまま固まるアプリと、エラーメッセージと再試行ボタンを出すアプリでは、採用担当者の受け取り方がまったく違います。ローディング中のスケルトン表示、データが0件のときの空状態表示まで用意しておくと、実務未経験に近くても「UI状態の設計を理解している人」として見てもらえます。

テストとアクセシビリティまで意識すると、さらに差がつく

ここまでの機能要件を満たした上でさらに差別化したいなら、最低限のテストとアクセシビリティ対応を加えてください。実務経験が浅い候補者のポートフォリオでテストコードまで書かれているケースは、私が見てきた中でも多くありません。だからこそ差がつきます。

すべての機能をテストする必要はありません。CRUD操作のうち中心となる1〜2機能だけでもVitestやJestでユニットテストを書き、READMEに「テストの方針」として一言添えるだけで十分です。フォームのバリデーションロジックなど、ロジックが独立していてテストしやすい部分から手をつけるのが現実的です。

アクセシビリティについても、キーボードだけでボタンやフォームを操作できるか、画像にalt属性が入っているか、色のコントラストが極端に低くないか、といった基本的な点だけ確認しておけば十分です。ブラウザの開発者ツールに入っているLighthouseでスコアを一度測っておき、READMEに数値を載せるのも、細部への意識を伝える手段の一つです。

私が見てきた限り、テストとアクセシビリティまで意識した候補者は、面接で「実務に入ってからのキャッチアップが早そう」という評価コメントがつくことが多い印象です。ゼロから完璧を目指す必要はなく、最低限の一手間を加えるだけで、そこまで手が回っている候補者自体が少ないぶん相対的に目立ちます。

READMEと制作意図の書き方、BさんのBefore/After

Bさんとのやり取りに戻ります。ポートフォリオを作り直すにあたり、題材を「在庫管理を模した管理画面」に変更しました。商品の一覧・検索・並び替え・在庫数の編集ができ、ログイン機能で保護し、在庫がゼロになった商品は一覧上で強調表示する仕様です。状態管理にはZustandを使い、最低限のユニットテストも書きました。

Before(元のREADME)は、次の3行だけでした。

React、TypeScriptで作成しました。ToDoの追加・削除ができます。npm installで起動します。

After(作り直したREADME)には、技術選定の理由・工夫した実装・あえて実装しなかった機能とその理由の3項目を追加しました。特に効いたのが最後の項目です。「通知機能(在庫がゼロになったらメール送信)は要件として検討したが、外部サービスとの連携が必要でスコープが広がりすぎるため、今回は一覧上での視覚的な強調表示にとどめた」という一文を加えたところ、書類選考の通過率が変わりました。

11社に応募して書類通過ゼロだった状態から、作り直したポートフォリオで6社に応募し、そのうち3社で書類選考を通過。2社の一次面接では、面接官から「あえて実装しなかった機能」について質問され、判断の理由をそのまま説明できたことが評価につながり、最終的に1社から内定が出ました。

READMEで一番読まれているのは「何を作ったか」ではなく、「何を作らなかったか、なぜか」です。全機能を詰め込むより、スコープを絞った理由を言葉にする方が実務者らしく見えます。

READMEの構成に迷ったら、次の6項目を見出しにしてそのまま埋めていく形で構いません。

この中で最も差がつくのが「あえて実装しなかった機能とその理由」です。時間や技術力の制約でやむを得ず削った部分を隠さず書くことで、逆にスコープを自分でコントロールできる人だという印象を与えられます。

職務経歴書との連動も意識してください。以前職務経歴書が書類選考で通らない理由、私が赤入れする5箇所でも触れましたが、実務経験が薄いうちは職務経歴書の実績欄が手薄になりがちです。その分をポートフォリオのREADMEで補う、という位置づけで書くと、書類全体の説得力が上がります。

評価を下げてしまうNGパターン

これまで何百件ものポートフォリオに目を通してきましたが、書類選考で見送りになりやすい作品には共通したパターンがあります。中でも面談で「公開URLを開いたらエラー画面が出た」というケースは、実力とは関係のないところで評価を落としてしまうので、提出直前に必ず別のブラウザ・別の端末から動作確認をしてください。

もう一つ注意したいのが、実務経験を実際より大きく見せる書き方です。「実務」という言葉を使っていなくても、書きぶりによっては業務プロジェクトのように誤解されることがあります。個人開発は個人開発として正直に書いた方が、後の面接で経歴と矛盾せず、かえって信頼につながります。実務経験が浅いこと自体は弱みではなく、今の実力を正確に伝えるための出発点として扱ってください。

面接で聞かれること、逆質問への備え方

ポートフォリオを提出すると、一次面接で必ずと言っていいほど掘り下げられます。私が同席してきた面接で頻出する質問は、次のようなものです。

これらの質問に共通しているのは、正解を試しているのではなく、判断の筋道を確認しているという点です。「実務で使うとしたら何を変えるか」という質問は、候補者が自分の作ったものを客観視できているかを見ています。

Bさんの場合、「今なら通知機能をトースト表示ではなくWebSocketでのリアルタイム更新にしたい、ただし今回のスコープでは学習コストが見合わないと判断した」と答えられたことが、評価の決め手の一つになったと面接官から後日聞きました。

一次面接に同席した経験から言うと、この手の質問への答え方には典型的な失敗パターンがあります。「なぜこの技術を選んだのか」と聞かれて「勉強したかったからです」で終わってしまうケースです。学習目的自体は悪くありませんが、そこで終わると実務での技術選定の話につながりません。「他にVueも検討したが、求人票でReactの記載が多く、コンポーネント設計の考え方も実務に近いと判断した」というように、比較検討の跡まで話せると印象が変わります。

逆質問の準備も忘れないでください。「御社のフロントエンド開発で、私が今回のポートフォリオで実装した機能要件(認証・API連携・状態管理)のうち、実務で特に重視されるのはどれですか」といった聞き方をすると、ポートフォリオの内容と実務との接続を自分から示すことができます。

よくある疑問に答えます

ポートフォリオは何個必要ですか

1個で構いません。ただし中途半端な作品を3個並べるより、機能要件を満たした作品を1個仕上げる方が評価されます。私が確認してきた通過者の傾向でも、複数作品を並べて評価が上がった例より、1本を深く作り込んだ例の方が圧倒的に多いです。時間に余裕があれば、毛色の違う題材をもう1個追加する程度にとどめてください。

作成期間の目安はどれくらいですか

実務未経験に近い状態からであれば、設計・実装・README作成まで含めて1ヶ月〜1ヶ月半が現実的な目安です。平日に1〜2時間、週末にまとめて数時間というペースでも、機能要件を絞れば十分に間に合います。それ以上長引く場合は、機能を詰め込みすぎている可能性が高いので、一度スコープを見直してください。

テンプレートを使うのはNGですか

デザインテンプレートを使うこと自体は問題ありません。避けるべきは、テンプレートの構成・コードをほぼそのまま流用し、自分で考えた要素がゼロに近い状態です。デザインは借りても、機能要件と実装ロジックは自分で設計してください。逆質問で「デザインはテンプレートを参考にしましたが、機能要件は自分で設計しました」と説明できれば、テンプレート使用自体はマイナスになりません。

面接でポートフォリオのコードをどこまで細かく見られますか

企業や面接官によって差はありますが、事前にリポジトリを開いて主要なファイル構成に目を通してから面接に臨む面接官は珍しくありません。ディレクトリ構成が整理されているか、コンポーネントが役割ごとに分割されているか、といった基本的な設計方針は見られていると考えてください。完璧である必要はなく、「なぜこの構成にしたか」を説明できれば十分です。

公開方法はVercelとNetlifyのどちらがいいですか

どちらでも構いません。フロントエンドのみの構成ならNetlify、API RoutesやSSRまで含めるならVercelの方が設定が楽、という程度の違いです。実務でどちらかのエコシステムに触れる機会があれば、そちらに合わせておくと会話のきっかけになります。

未経験・実務経験が浅い状態から、転職までどれくらいかかりますか

Bさんのように独学と実務経験を組み合わせている場合、ポートフォリオの作り直しから内定まで2〜3ヶ月というのが、私が担当してきた実例の中では多いパターンです。ただし応募先企業の採用状況や書類の完成度によって差が大きいため、あくまで目安として捉えてください。

まとめ、模写を卒業して「判断の跡」を残す

多くの転職ノウハウ記事は「ポートフォリオには実績・使用技術・制作意図を書きましょう」という項目の紹介で終わっています。ですが実務経験が浅い人が本当に知りたいのは、その項目を埋めるだけの材料がまだない段階で何を作ればいいか、という一歩手前の話のはずです。

模写コーディングだけのポートフォリオが埋もれるのは、実装力が足りないからではなく、そこに作った人の判断が何一つ残っていないからです。実務経験が浅いうちほど、実績の数字で語れる材料が少ない分、ポートフォリオの中に「何を選び、何を諦めたか」の跡を残すことが、書類選考を突破する一番の近道になります。

題材選びに迷ったら、派手さより実務で繰り返される一覧・検索・登録・編集の流れを持つ地味な管理画面を選んでください。そして完成させたら、READMEに実装しなかった機能とその理由まで書き切る。この記事で一番伝えたかったのは、この一点です。

ポートフォリオを見た採用担当者が知りたいのは「何が作れるか」ではなく「入社後、何を任せられそうか」です。その問いに答える作品を1つ仕上げることが、書類の枚数を増やすより確実に選考を前に進めます。

今すでにポートフォリオがある人は、まずREADMEを開いて「作らなかった機能」が書けるかどうかを確認してみてください。書けないなら、そこが次に手を入れるべき場所です。