「GitHubのURL貼っておきました」では通らない時代
転職活動でポートフォリオを用意するエンジニアは増えています。しかし、「とりあえずGitHubのリンクを職務経歴書に載せた」「チュートリアルで作ったTodoアプリをデプロイした」という状態では、採用担当者の目にはほとんど止まりません。
ポートフォリオは「自分が何を作れるか」を証明する手段であると同時に、「どんな課題意識を持ち、どう考えてものを作るか」を伝えるコミュニケーションツールです。この2つの視点がそろって初めて、選考を動かすポートフォリオになります。
この記事では、転職活動において実際に評価されるエンジニアのポートフォリオとはどういうものか、何を作ってどう見せればいいかを、具体的に掘り下げます。
採用担当者はポートフォリオの何を見ているか
まず「見られる側」の視点を理解することが重要です。採用担当者——特に技術面接の前段を担う人事や採用チーム——がポートフォリオを確認する時間は、初見でせいぜい3〜5分です。その短い時間で「この人は話を聞く価値がある」と思わせる必要があります。
技術担当者(現場のエンジニア)が見る場合は、コードの質・設計の意図・技術選定の理由が主な評価対象になります。「なぜこのフレームワークを選んだのか」「どんな問題を解決しようとしているのか」「コードは読みやすいか」という観点で読まれます。
どちらの目線においても重要なのが「文脈」です。作ったものの背景——どんな課題があって、なぜこれを作ろうと思ったのか——が伝わることで、技術力だけでなくエンジニアとしての思考力も同時に示すことができます。
何を作ればいいか:テーマ選びの3つの軸
ポートフォリオで「何を作るか」に悩む人は多いですが、評価されやすいテーマには共通の特徴があります。
自分が実際に困っていた問題を解決するもの
「自分の読書記録を管理するアプリ」「家族で使う買い物リストの共有ツール」のような、実際の生活課題から発想したプロダクトは、説得力のあるストーリーを持っています。採用担当者が「なぜこれを作ったのですか?」と聞いたとき、「自分が不便に感じていたから」という答えは非常に強いです。課題の解像度が高ければ高いほど、プロダクトへの考察も自然と深まります。
応募先の事業ドメインに関連するもの
転職先の業界や技術スタックに関連するプロダクトを作ることで、「この候補者はうちの仕事に興味を持っている」という印象を与えられます。ECサービスに応募するならカート機能付きのショッピングサイト、SaaSに応募するなら認証付きのダッシュボードといった形です。完成度よりも「理解して作った」という形跡のほうが重視されます。
技術的な挑戦を含むもの
「新しいフレームワークを試してみた」「パフォーマンス最適化にこだわった」「セキュリティを意識した認証フローを実装した」など、技術的なこだわりが伝わるプロジェクトは、エンジニアとしての好奇心と成長意欲を示せます。最先端の技術を使う必要はありませんが、「なぜこの技術を選んだか」を語れることが重要です。
「作って終わり」にしない:見せ方の設計
ポートフォリオは作るだけでなく、「どう見せるか」の設計が評価を大きく左右します。
READMEは最重要ドキュメント
GitHubのリポジトリを見る採用担当者が最初に読むのはREADMEです。ここに「何のアプリか・なぜ作ったか・使用技術・工夫したポイント・動作確認の方法」が書かれていれば、コードを全部読まなくても概要が伝わります。
特に「工夫したポイント」は必ず書くべき項目です。「検索のパフォーマンス改善のためにインデックスを設計しました」「ユーザーごとのデータ分離のためにRow Level Securityを導入しました」といった具体的な記述が、技術力の証拠になります。
デモ環境を用意する
コードを読めない採用担当者でも動作確認できるように、実際に触れるデモ環境を用意することは非常に効果的です。VercelやRenderなどを使えば無料で本番に近い環境を公開できます。デモ用のテストアカウント(メールアドレスとパスワード)をREADMEに記載しておくと、摩擦ゼロで体験してもらえます。
スクリーンショットと動画
デモ環境を見に行く手間をかけたくない人向けに、READMEにスクリーンショットや短い動画(GIF)を埋め込んでおくと効果的です。特に「ここが一番のこだわりポイントです」という画面を視覚的に見せられると、短時間で印象を残せます。
コードの品質:採用担当エンジニアが実際に見ること
技術面接の担当者がコードを見るとき、何に注目しているかを知っておくことは、ポートフォリオ制作の質を上げるために非常に役立ちます。
| チェックポイント | 評価される状態 |
|---|---|
| 変数・関数の命名 | 意図が一目でわかる名前がついている |
| 関数の粒度 | 1関数が1つのことをしている(単一責任) |
| コメントの質 | 「何をしているか」ではなく「なぜそうしているか」が書かれている |
| エラーハンドリング | 例外ケースや異常系が考慮されている |
| テストコード | 主要なロジックにテストが書かれている |
| コミットの粒度 | 意味のある単位でコミットが分かれている |
特に「コミット履歴」は意外と見られているポイントです。fix update 作業中 といったコミットが続いていると、開発プロセスへの意識の低さが伝わってしまいます。逆に「feat: ユーザー認証機能を追加」「refactor: API呼び出しをカスタムフックに切り出し」のような具体的なコミットメッセージが並んでいると、チーム開発への適応力が高いと判断されます。
複数作るより、1本を磨く
ポートフォリオを量で勝負しようとする人がいますが、「10個の中途半端なプロジェクト」より「1〜2個の完成度の高いプロジェクト」のほうが採用担当者に刺さります。
1本のプロジェクトを「話せるレベル」まで仕上げるとは、どんな状態でしょうか。「なぜこれを作ったのか」「技術選定の理由」「設計で迷った箇所と最終的にどう判断したか」「リリース後に気づいた改善点」——これらを30分の面接で語り尽くせるくらいの深さで作り込んでいることが理想です。
プロジェクトに「ストーリー」がある状態です。ストーリーがあれば面接で自然と話が広がり、技術力だけでなく思考力・判断力・コミュニケーション力まで同時にアピールできます。
ポートフォリオサイト自体をポートフォリオにする
個人のポートフォリオサイト(自己紹介ページ)を自分で作ることも有効な手段です。プロジェクト一覧・使用技術・経歴・GitHubへのリンクをまとめたサイトを自作することで、「Webの基本的な実装ができる」ことを暗黙的に示せます。
特にフロントエンドエンジニアを目指している場合、ポートフォリオサイト自体のUI/UXデザインやアニメーションのクオリティが、センスと実力の証明になります。完璧なデザインである必要はありませんが、「自分で作った」という誠実さと「ここにこだわった」というポイントを持っていることが大切です。
まとめ
採用担当者の目に止まるポートフォリオは、「作った事実」ではなく「なぜ作ったか・何にこだわったか」が伝わるものです。テーマは自分の課題意識や応募先への関心から選び、READMEとデモ環境で見せ方を設計し、コードの品質とコミット履歴で技術力を証明する——この3層を意識することで、ポートフォリオは選考を動かす武器になります。まずは1本、語り尽くせるプロジェクトを作り上げることから始めてみましょう。