エンジニア転職ポートフォリオ完全ガイド｜採用担当が本当に見ているポイント

転職市場で「ポートフォリオを出してください」と言われたとき、多くのエンジニアがつまずくのは「何を作るか」ではなく「何が評価されるか」を知らないことだ。

採用担当は1日に数十件のポートフォリオを見ている。そのほとんどをスキップする理由は単純で、「動かない」「READMEがない」「技術選定の理由が書いていない」の3つだ。逆に言えば、この3点をクリアするだけで通過率は大幅に改善する。

この記事では、採用側の視点から「どの部分で合否判断をしているか」を具体的に解説する。転職準備中のエンジニアが今すぐ手を動かせる改善策に絞って書いた。

採用担当がポートフォリオで真っ先に確認すること

書類審査でポートフォリオのURLを開いてから、採用担当が最初の10秒で判断していることがある。

デプロイされているか、URLは動くか

採用担当がローカル環境でアプリを起動することはない。GitHubのREADMEだけ送られてきて「動作確認はローカルで」と書かれていても、実際に試す採用担当はほぼいない。

動かせないポートフォリオは存在しないのと同じ扱いになる。Vercel、Render、Railway、Supabase——無料で使えるホスティングサービスは複数ある。フロントのみのアプリならVercelに5分でデプロイできる。

デプロイチェックリスト

• URLが死んでいない（スリープ状態の無料サーバーでも30秒以内に起動する設定にする）
• モバイルでも崩れない基本的なレスポンシブ対応がある
• エラー画面でサービスが止まっていない

READMEに何が書いてあるか

GitHubリポジトリのREADMEは履歴書の「自己PR欄」に近い。何も書かれていないか、デフォルトのREADMEのままのリポジトリは、作品として見てもらえない。

採用担当が確認するのは以下の5点だ。

1. 何を作ったか（アプリの概要、ターゲットユーザー）
2. なぜ作ったか（課題感や動機）
3. どの技術を使ったか（技術スタック一覧）
4. なぜその技術を選んだか（選定理由）
5. どうやって使うか（セットアップ手順、デモURL）

「なぜその技術を選んだか」を書いているポートフォリオは全体の2割程度しかない。これを書くだけで差別化になる。

---

技術選定の「なぜ」がなければ意味がない

ポートフォリオで最も差がつくのはここだ。同じ技術スタックを使っていても、選定理由を説明できるエンジニアと「なんとなく使った」エンジニアでは評価が全く違う。

技術選定理由の書き方

技術選定の理由は、機能一覧を並べるより「なぜ他の選択肢ではなくこれを選んだか」の比較軸で書く方が伝わる。

悪い例

フロントエンドにReact、バックエンドにNode.js、データベースにPostgreSQLを使いました。

良い例

フロントエンドはReactを採用。当初Vueも検討しましたが、応募先の求人票でReact経験が求められていたため、実務への適用を意識してReactを選びました。状態管理はZustandを使用。ReduxはBoilerplateが多く今回の規模に対してオーバースペックと判断しました。

「なぜVueではなくReactか」「なぜReduxではなくZustandか」という比較の文脈が入ると、技術的な判断力が伝わる。

応募先の技術スタックと合わせる判断

ポートフォリオで使う技術は、応募先の求人票を見て逆算するのが最も効率的だ。

転職先としてよく挙がる構成：

応募先が決まっていない段階でポートフォリオを作るなら、TypeScript + React + Docker の組み合わせが最も汎用性が高い。

「流行っているから」は面接で詰まる

面接でポートフォリオについて質問されたとき、「なんとなくNext.jsが人気だったので」という答えは評価を下げる。

「Next.js App RouterのServer Componentsを使うことで、SEOに重要な初期表示速度を改善できると考えた」という説明ができると、技術への理解が伝わる。

ポートフォリオに使う技術は、公式ドキュメントと自分の言葉で1〜2文説明できるものに絞る。説明できない技術を使うくらいなら、確実に説明できる技術で丁寧に作る方が評価が高い。

Docker勉強法初心者向けロードマップ

ポートフォリオにDockerを組み込む前に読んでおきたい。コンテナ化の意図を説明できるようになる

---

コードの品質が採用担当に見られる場面

GitHubのリポジトリを見る採用担当の中には、技術担当者がコードレビューをするケースがある。特に中小Web系企業やスタートアップではCTOや開発リーダーがポートフォリオのコードを直接読むことがある。

読みやすいコードの最低ライン

コード品質で最低限押さえるポイントは5つだ。

1. 変数名・関数名に意味がある

data、temp、func1 のような名前は避ける。userProfile、fetchOrderHistory、handleFormSubmit のように、読んで意図がわかる名前にする。

2. コメントが「何をしているか」ではなく「なぜそうしているか」を説明している

// 悪い例: 何をしているか（コードを読めばわかる）
// userオブジェクトのnameプロパティを取得する
const name = user.name;

// 良い例: なぜそうしているか（コードから読み取れない文脈）
// APIのレスポンスでnullが返ることがあるため、フォールバック値を設定
const name = user.name ?? 'ゲスト';

3. 関数が1つのことだけをしている

100行を超える関数は分割する。「1関数1責務」はポートフォリオでも守る習慣にする。

4. エラーハンドリングがある

APIリクエストに try-catch がない、バリデーションがないフォームは「実務では使えない」印象を与える。

5. 環境変数で機密情報を管理している

APIキーやDB接続文字列がコードに直書きされていると、セキュリティ意識の欠如として評価に影響する。.env.example をリポジトリに含めるのが基本だ。

---

「面接で説明できるポートフォリオ」の作り方

ポートフォリオの目的は書類通過だけではない。面接でポートフォリオを見ながら質問に答える場面があり、そのときに詰まると評価が落ちる。

面接でよく聞かれるポートフォリオへの質問

採用面接でポートフォリオについて聞かれる質問パターンは大体決まっている。

設計・アーキテクチャについて

• 「なぜこの技術スタックを選んだのですか？」
• 「設計で迷った部分はありますか？」
• 「もし作り直すとしたらどこを変えますか？」

実装の詳細について

• 「一番苦労した部分はどこですか？」
• 「このAPIはどういう設計にしていますか？」
• 「認証はどのように実装していますか？」

改善・拡張について

• 「今後追加したい機能はありますか？」
• 「パフォーマンスの改善余地はどこですか？」

これらすべてに答えられるかどうかが、「自分で理解して作ったか」「チュートリアルをコピーしただけか」を見分けるポイントだ。

「作り直すならどこを変えるか」が評価を分ける質問

「もし作り直すとしたら？」という質問への答えは採用担当が最も重視する回答の一つだ。

自分の成果物の弱点を自分で認識しており、改善策を考えられるかどうかを見ている。「特にないです」という回答は自己分析の甘さとして見られる。

良い回答例：

現状はサーバーサイドでページ単位に全データを取得していますが、ユーザーが増えるとN+1問題が発生する構造になっています。DataLoaderを導入してクエリをバッチ処理するか、設計を見直してIncludes/Joinを活用する方向で改善を考えています。

問題を認識していること、解決策の方向性があること、技術用語を正確に使えること——この3点が伝わる。

エンジニア転職の準備完全ガイド

ポートフォリオ作成と並行して進める転職準備の全体像。自己分析から面接対策まで7ステップで解説

---

ポートフォリオを作る前に決めておくこと

何を作るかは、多くのエンジニアが最初に詰まるポイントだ。「良いアイデアが思いつかない」という状態で止まっている期間が長いほど、転職準備が遅れる。

テーマ選びの3つの基準

1. 自分が実際に使う場面を想像できるか

架空のECサイトや「ToDoアプリ以外」という縛りだけでテーマを選ぶと、作り終えた後に「なぜ作ったか」を説明できなくなる。自分が日常の中で「あったら便利」と感じた問題からテーマを選ぶと、動機の説明が自然になる。

2. 転職先の業種・ドメインに近いか

EC系の企業に転職したいなら商品管理や在庫のドメインを扱う作品が有利だ。SaaSに転職したいなら認証・マルチテナント・サブスクリプション管理のようなテーマが評価される。

3. 2〜4週間で完成させられる規模か

大きすぎるテーマは途中でモチベーションが落ちて「完成しませんでした」という結果になりやすい。機能を絞ってMVP（最小限の機能）で一度完成させてから追加機能を実装する順番が現実的だ。

「ToDoアプリでもいい」という話

「ToDoアプリはダメ」という意見を見るが、完成度が高いToDoアプリは普通に評価される。

評価されないのはToDoアプリそのものではなく「チュートリアルをそのままコピーしてデプロイもしていない」状態だ。ToDoアプリでも、以下の要素があれば面接で話せる作品になる。

• ユーザー認証（登録・ログイン・ログアウト）
• データの永続化（DB連携）
• デプロイ済み（URLで動作確認できる）
• READMEに技術選定の理由がある
• テストコードが一部でもある

この5点が揃ったToDoアプリは、デプロイなし・説明なしのオリジナルアプリより評価が高くなることがある。

---

転職ステージ別のポートフォリオ戦略

経験年数やキャリアの段階によって、ポートフォリオに求められる内容が変わる。

未経験・第二新卒の場合

採用側に「ちゃんと動くものを自分で作れる」という最低限の証明をすることが目的だ。技術の深さよりも「完成させた」実績が重要になる。

重視すべきポイント：

• デプロイまで完結している
• READMEが整っている
• コードがGitHubにある
• アプリとして最低限動く

使う技術の難易度よりも「なぜ作ったか」「どこで詰まって、どう解決したか」を語れることの方が評価される。

実務経験1〜3年の場合

チュートリアル以上の「自分で考えた部分」があるかどうかが見られる。既存のチュートリアルをベースにしていても、独自の機能追加や設計判断があれば差別化になる。

重視すべきポイント：

• 実務で学んだことをポートフォリオに反映している
• テストコードが含まれている
• 設計についての説明ができる
• リファクタリングの意識が見える（コミット履歴）

SES経験者の場合

SESは常駐先のコードを公開できないため、ポートフォリオがない状態になりやすい。この場合、個人開発のポートフォリオが転職活動の鍵になる。

SES在籍中でもポートフォリオが作れる時間の作り方：

• 通勤時間の30分でドキュメントを読む
• 土日の2〜3時間で実装を進める
• 1ヶ月で機能1つずつ追加する

SESからの転職で「ポートフォリオがありません」という状態は避けたい。最低1つのデプロイ済みアプリを用意することが転職活動の前提条件になる。

SES3年目は転職のベストタイミング？

SESからポートフォリオ付きで転職する戦略。データで見る市場価値と年収UP方法

---

まとめ：採用担当の視点で自分のポートフォリオを見直す

採用担当がポートフォリオを見るときの優先順位は以下の通りだ。

1. デプロイされているか ——動かないものは評価できない
2. READMEに技術選定の理由があるか ——「なぜそれを選んだか」が書いてある
3. コードが読みやすいか ——変数名、コメント、関数の責務分離
4. 面接で説明できるか ——設計判断・苦労した点・改善点を言語化できる

この4点のうち、今の自分のポートフォリオがどこに引っかかっているかを確認してほしい。多くの場合、デプロイとREADMEの2つを整えるだけで通過率は改善する。

ポートフォリオ作成で行き詰まっているなら、まず「デプロイまで完結させること」を最初のゴールに設定する。READMEの整備、コードの改善はその後に積み重ねていける。