エンジニア転職のポートフォリオの作り方【採用担当が見る5つのポイント】

「ポートフォリオって何を載せればいいの？」「GitHubを整備すれば十分？」——エンジニア転職を目指す多くの方が、この疑問を抱えています。

実際のところ、ポートフォリオは履歴書や職務経歴書とは根本的に異なります。採用担当者が見ているのは「あなたが実際にコードを書けるか」「プロダクトを完成させられるか」「継続して学習しているか」という点です。いくら職歴を文章で説明しても、動くプロダクトには敵いません。

この記事では、採用担当者の視点からポートフォリオ評価の実態を解説し、未経験から経験者まで使えるサンプル構成と、GitHub整備の具体的な手順をお伝えします。「何を作ればいいかわからない」「どこまで準備すれば書類が通るか」という疑問に、採用現場の実情を踏まえながら答えていきます。

エンジニア転職でポートフォリオが重要な理由

エンジニア転職においてポートフォリオは、スキルを客観的に証明できる唯一の手段です。採用担当者がポートフォリオで確認するのは主に3点です。第一に、実際に動くプロダクトを作れるかどうか。第二に、コードの可読性と設計思想があるかどうか。第三に、継続的に学習・更新しているかどうか。特に未経験転職では職務経歴書だけでは実力が伝わらないため、ポートフォリオの有無が書類選考の通過率を大きく左右します。エンジニア採用では、コーディングテストや技術面接がありますが、書類選考の段階でポートフォリオを持っていない候補者は、そもそも次のステップに進めないことが多いのが実情です。

履歴書・職務経歴書との決定的な違い

履歴書と職務経歴書が「過去の経験を言葉で伝える書類」であるのに対し、ポートフォリオは「現在のスキルを実物で示す証拠」です。

採用担当者は毎日大量の書類を確認します。「Reactを使って開発した経験があります」という文章と、「実際にReactで作ったアプリのURL」では、後者の方が一瞬で実力を判断できます。特に未経験からの転職では、前職の業務経験がIT系でないため、職務経歴書だけで技術力を伝えるのは困難です。

エンジニア採用に携わる採用担当者の多くは、技術的なバックグラウンドを持つ人材（エンジニアリングマネージャーや現役エンジニア）がレビューに関わります。彼らが見ているのは「この人は実際にコードが書けるか」「うちのチームで即戦力になれるか」という点です。ポートフォリオはその問いに答える最も直接的な手段です。

書類通過率への影響

採用担当者へのヒアリングや転職エージェントの実績データを参考にすると、未経験エンジニアの書類通過率はポートフォリオの有無で大きく異なる傾向があります。

具体的には、「完成・デプロイ済みのプロジェクトをGitHubで公開している」候補者は、コードを一切公開していない候補者と比べて書類選考の通過率が高い傾向にあります。これは単純にスキルを証明できるかどうかの問題です。

特にスタートアップや成長期のIT企業では、エンジニアの採用枠が少なく競争が激しいため、ポートフォリオがない候補者は書類選考で弾かれるケースが多いです。逆に言えば、ポートフォリオさえ整備できれば、それだけで一定数の競合に差をつけられます。

採用担当者が最初に確認する3点

実際の採用現場では、書類を受け取った担当者が最初の30秒〜1分でポートフォリオを確認します。その際に見ているのは次の3点です。

1. GitHubのURLが存在するか: プロフィールにGitHubリンクがあるかどうかが出発点です。存在しない場合、その時点で評価が難しくなります。

2. コントリビューションカレンダーの緑の多さ: 継続して開発・学習しているかを一目で確認できます。直近3〜6ヶ月が緑で埋まっていると「アクティブに学習中」という印象を与えます。

3. ピン留めされたリポジトリのREADME: プロフィールに表示される主要リポジトリをクリックした際、READMEがしっかり書かれているかどうかです。READMEが空欄または最低限しか書かれていないリポジトリは、印象が悪くなります。

採用担当者がポートフォリオで見る5つのポイント

採用担当者がポートフォリオを評価する際には、明確な基準があります。以下の5つのポイントを知ることで、何をどう整備すればよいかが明確になります。

ポイント1: 動作するプロダクトがあるか

なぜ重要か: コードが動く状態のプロダクトは、「完成させる能力がある」ことを証明します。途中で放置されたコードは学習中の痕跡に過ぎませんが、デプロイ済みのプロダクトは成果物として誰でも確認できます。

どう対策するか: Vercel・Netlify・Renderなどの無料デプロイサービスを使って、必ず本番URLを用意しましょう。「ローカルでは動く」は選考では意味を持ちません。採用担当者がURLをクリックしてすぐにアプリを確認できる状態が理想です。

フロントエンドであればVercelやNetlifyが最も手軽です。バックエンドを含む場合はRenderやFly.io、データベースが必要な場合はSupabaseやPlanetScaleと組み合わせる方法が一般的です。デプロイまで行うと「環境構築・デプロイができる」という付加的なスキルのアピールにもなります。

ポイント2: READMEの充実度

なぜ重要か: READMEはコードの「説明書」です。採用担当者（特にエンジニアでない担当者や多忙なエンジニアリングマネージャー）が最初に読むドキュメントです。READMEが充実していれば「ドキュメントを書く習慣がある」「他者視点でコードを説明できる」ことを示せます。

どう対策するか: READMEには最低限、以下の要素を盛り込みましょう。

プロジェクト概要（何を作ったか、なぜ作ったか）
使用技術（言語・フレームワーク・データベース・インフラ）
セットアップ手順（`git clone`からローカル起動までのコマンド）
主な機能一覧
工夫した点・技術的なこだわり
デモURL / スクリーンショット
今後の改善予定（あれば）

特に「工夫した点」の記述は重要です。チュートリアルとの差別化ができ、技術選定の思考プロセスを示せます。採用担当者が「この人は考えながら作っている」と感じるREADMEが理想です。

ポイント3: コードの読みやすさ

なぜ重要か: 実際の開発現場では、一人で書いたコードを他の人がメンテナンスすることが日常です。命名規則が統一されている、適切なコメントがある、ディレクトリ構成が整理されているコードは「チームで働ける人材」の証明になります。

どう対策するか: 以下の点を意識してコードを整備しましょう。

命名規則の統一: 変数名・関数名・ファイル名が一貫したルール（camelCase / snake_case 等）に従っているか
適切なコメント: 処理の意図がわかりにくい箇所にコメントを追加する（コード自体の自明な説明は不要）
ディレクトリ構成: components / services / utils / hooks などのフォルダに役割ごとにファイルを整理する
不要なコードの削除: コメントアウトした古いコードを残さない、未使用のimport文を削除する

ESLint・Prettierなどのフォーマッターを導入してコードスタイルを統一することで、採用担当者に「開発ツールを使いこなせる」と判断してもらいやすくなります。

ポイント4: 技術選定の理由を説明できるか

なぜ重要か: 「なぜこのフレームワークを選んだか」「なぜこのDB設計にしたか」を説明できる候補者は、技術を受動的に使うだけでなく、能動的に選択・判断できると評価されます。面接での質問にもつながるポイントです。

どう対策するか: READMEや技術ブログに「技術選定の理由」を必ず書きましょう。

たとえば「フロントエンドにReactを選んだ理由は、コンポーネント分割による再利用性の高さと、採用を検討している企業の多くがReactを採用しているため、即戦力として貢献しやすいと判断したから」のような記述です。「みんなが使っているから」ではなく、「自分の目的に対してこの技術が最適だと判断した」という論理が重要です。

あえて選ばなかった選択肢（「Next.jsではなくViteを選んだ理由」等）に触れることで、技術的な比較検討ができることを示せます。

ポイント5: 更新・改善の継続性

なぜ重要か: 最終コミットが1年前のリポジトリは「放置されたプロジェクト」と見なされます。採用担当者は、転職活動中にも継続して学習・開発しているかを重視します。継続性は「入社後も自律的に成長できる人材か」を判断する指標です。

どう対策するか: 以下のアクションを転職活動中に実践しましょう。

週1〜2回のコミットを習慣化する（小さな修正・ドキュメント更新でも可）
GitHubのIssueに「やること」「バグ報告」を登録してプロジェクト管理の習慣を示す
バージョン管理のコミットメッセージを意味のある内容にする（`fix: ○○の修正`のようなConventional Commitsスタイルが理想）
転職活動中に新しい機能を追加・改善した記録を残す

コントリビューションカレンダーが直近3ヶ月で緑であれば、「アクティブなエンジニア」という印象を与えられます。

何を載せるべきか―成果物の選び方と構成

ポートフォリオに何を載せるかは、量よりも質の問題です。採用担当者は10個の未完成プロジェクトより、1個の完成度の高いプロジェクトを高く評価します。

成果物の数は2〜3個が最適

ポートフォリオに載せる成果物は、2〜3個が適切です。

1個では経験の幅が見えません。4個以上になると採用担当者が確認する工数が増え、それぞれの質が下がる傾向があります。2〜3個であれば、各プロジェクトに十分な説明を付け、完成度を高めることができます。

特に重要なのは「完成・デプロイ済みのもの」を最低1個は用意することです。未完成のプロジェクトをポートフォリオに含める場合は、それを明示した上で「現在開発中」と書きましょう。黙って未完成品を載せると、採用担当者が動作確認できず印象が悪くなります。

成果物の選び方の3つの基準

どのプロジェクトをポートフォリオに載せるか迷ったときは、以下の基準で判断してください。

基準1: 応募先の技術スタックに近いもの

志望企業がRuby on Railsを使っているのに、PHPのみのプロジェクトを載せても評価されにくいです。応募先の求人票で使用技術を確認し、なるべく合致するプロジェクトを優先しましょう。複数企業に応募する場合は、汎用性の高い技術（React・Next.js・Python・Node.js等）を使ったプロジェクトを選ぶとよいです。

基準2: 自分が工夫点を語れるもの

面接で「このプロジェクトで一番苦労した点は？」と聞かれた際に、具体的に答えられるプロジェクトを選びましょう。チュートリアルをそのままコピーしたものは、工夫点を語れないため面接で深掘りされると困ります。自分で考えてコードを書いた部分が多いプロジェクトを優先します。

基準3: 実際に使える・動くもの

「開発中」「ローカルのみ動作」より「本番デプロイ済みで誰でもアクセスできる」状態のプロジェクトが理想です。実際に使えるプロダクトは「最後まで完成させる能力」の証明になります。

各プロジェクトに載せるべき情報

ポートフォリオの各プロジェクトには、以下の情報を必ず含めましょう。

項目	内容例
プロジェクト概要	「レシピ管理アプリ。食材を入力するとレシピを提案するWebアプリ」（1〜2文）
使用技術	「React / Node.js / Express / PostgreSQL / Vercel」
工夫した点	「食材検索のUXを改善するためにデバウンス処理を実装した」
苦労した点	「DB設計でのN+1問題を解消するためにクエリを最適化した」
GitHub URL	`https://github.com/username/recipe-app`
デモURL	`https://recipe-app.vercel.app`

プロジェクト概要は長すぎず、採用担当者が5秒で「何を作ったか」を理解できる簡潔さが重要です。

避けるべき成果物の3パターン

次のパターンは避けましょう。

チュートリアルのコピー: YouTubeやUdemyのチュートリアルを一切改変せずそのまま載せると、「自分でコードが書けるか」が判断できません。チュートリアルを参考にした場合でも、UIの変更・機能追加・デプロイなどの独自の工夫が必要です。

未完成のもの（説明なし）: 「一部機能が動きません」という状態で放置されたプロジェクトは逆効果です。未完成なら「現在開発中（認証機能を実装中）」と明示する方が誠実です。

古い技術のみ: jQueryのみ・古いバージョンのフレームワークのみといった構成は、「最新の技術をキャッチアップできていない」という印象を与えます。できれば直近1〜2年以内の技術スタックを使ったプロジェクトを含めましょう。

GitHubを使ったポートフォリオ整備の実践手順

GitHubはエンジニアのポートフォリオとして最も広く認知されたプラットフォームです。プロフィールを丁寧に整備することで、採用担当者に与える第一印象を大きく改善できます。

GitHubプロフィールの整備手順

ステップ1: プロフィール写真とbioの設定

プロフィール写真は本人の顔写真またはプロフェッショナルなアバターを設定しましょう。デフォルトのアイコンのままでは「アカウントを使っていない」印象を与えます。

bioには使用技術・学習中の技術・簡単な自己紹介を100文字以内で記載します。たとえば「Webアプリ開発を学ぶエンジニア。React / Node.js / PostgreSQLで個人開発中。転職活動中」のような形です。

ステップ2: ピン留めリポジトリの設定

GitHubプロフィールには最大6つのリポジトリをピン留め表示できます。採用担当者が最初に目にする場所のため、ポートフォリオとして見せたいプロジェクトを選択します。

設定方法: プロフィールページ → 「Customize your pins」→ 表示したいリポジトリを選択

ピン留めするリポジトリは、必ずREADMEが整備されたものを選びましょう。

ステップ3: GitHubプロフィールREADMEの作成

自分のユーザー名と同名のリポジトリを作成すると、プロフィールページに独自のREADMEを表示できます（例: `github.com/username/username`）。スキルセット・自己紹介・制作物へのリンクを掲載するサマリーページとして活用できます。

README.mdの書き方テンプレート

各プロジェクトのREADMEは以下の構成を参考にしてください。

“`

プロジェクト概要

何を作ったか、なぜ作ったかを1〜3文で説明する。（例）食材を入力するとレシピを提案するWebアプリです。「冷蔵庫の余り物で何が作れるか」という問題を解決するために開発しました。

デモ

デモURL ![スクリーンショット](./screenshots/demo.png)

機能一覧

食材の入力・管理
AIによるレシピ提案
お気に入りレシピの保存
ユーザー認証（メール / Google OAuth）

使用技術

フロントエンド: React 18 / TypeScript / Tailwind CSS
バックエンド: Node.js / Express
データベース: PostgreSQL
インフラ: Vercel（フロントエンド）/ Render（バックエンド）

セットアップ

\`\`\`bash git clone https://github.com/username/recipe-app cd recipe-app npm install cp .env.example .env # 環境変数を設定 npm run dev \`\`\`

工夫した点

検索入力にデバウンス処理を実装しAPIコール数を削減
N+1問題を解消するためJoinクエリに最適化
コンポーネントを責務ごとに分割し再利用性を向上

今後の展望

スマートフォンアプリ版の開発
レシピの評価・レビュー機能の追加

“`

このテンプレートを参考に、プロジェクトの特性に合わせてカスタマイズしてください。

コントリビューションカレンダーを緑にする意義

GitHubのコントリビューションカレンダー（プロフィールページの緑のマス目）は、日々の開発・学習の可視化になります。採用担当者は「直近3〜6ヶ月にどれだけ活動しているか」を参考にします。

転職活動中の目標として、週2〜3回のコミットを意識しましょう。コミットの内容は大きなものでなくて構いません。バグ修正・README更新・リファクタリング・新機能の追加など、小さな改善の積み重ねで継続性が証明できます。

注意点として、コントリビューションカレンダーは「パブリックリポジトリへのコミット」か「プライベートリポジトリへのコミット（設定で表示）」が対象です。ローカルのみの変更は反映されないため、こまめにプッシュする習慣をつけましょう。

無料デプロイサービスの活用法

デモURLを用意するための無料デプロイサービスを紹介します。

サービス	対象	特徴
Vercel	フロントエンド（React / Next.js）	GitHubと連携・自動デプロイ
Netlify	フロントエンド（静的サイト）	フォーム機能・CDN標準搭載
Render	バックエンド（Node.js / Rails等）	無料プランあり（スリープあり）
Fly.io	バックエンド（Docker対応）	グローバルデプロイ対応
Supabase	データベース（PostgreSQL）	認証機能も提供

Vercelはフロントエンドに限ればGitHubと連携してプッシュのたびに自動デプロイされるため、最も手軽です。バックエンドが必要な構成の場合はRenderを組み合わせるのが一般的です。なお、Renderの無料プランはアクセスがないとスリープするため、採用担当者がデモを確認する際に起動待ちが発生することがあります。READMEに「初回アクセス時は起動に30秒ほどかかります」と記載しておくとよいです。

未経験・経験者別ポートフォリオ構成サンプル

ポートフォリオの最適な構成は、経験年数によって異なります。未経験の場合と経験者の場合で、それぞれ理想的なサンプルを提示します。

未経験転職向けポートフォリオ構成サンプル

未経験からのエンジニア転職では、「基礎を理解してプロダクトを作れること」と「デプロイまで自走できること」を証明することが最優先です。

作品①: 基礎Webアプリ（デプロイ済み）

内容例: ToDoアプリ・レシピ管理アプリ・メモアプリ
使用技術: React + Node.js（または Rails） + データベース
必須要件: デプロイ済みURL・整備されたREADME
アピールポイント: CRUDの基本実装・ユーザー認証・レスポンシブデザイン

> 採用担当からの評価コメント例: 「ToDoアプリでも、認証機能を自分で実装してデプロイまで完成させているのは評価できます。コードを見ると命名規則が統一されていて、READMEに工夫した点も書かれているので、開発の思考プロセスが伝わりました」

作品②: 応用Webアプリ（API連携・DB使用）

内容例: 天気情報アプリ・SNSクローン・ECサイトモック
使用技術: 外部APIを活用・データベース設計あり
必須要件: 設計意図をREADMEで説明
アピールポイント: 外部API連携・DB設計・非同期処理の理解

> 採用担当からの評価コメント例: 「OpenWeather APIと連携した天気アプリで、位置情報の取得からUI表示まで自分で実装しているのが印象的です。エラーハンドリングまで考慮されていて、実務を意識した実装だと感じました」

加点要素: GitHubプロフィール + 技術ブログ

QiitaやZennへの技術記事投稿があると、「アウトプットの習慣がある」「言語化能力が高い」として評価されます。月1〜2本のペースで、学習した内容や実装で詰まった点の解決方法を記事にしましょう。

技術ブログのURLをGitHubのbioや職務経歴書に記載することで、採用担当者がより深くあなたを理解できます。

経験者向けポートフォリオ構成サンプル

経験者（エンジニア歴1年以上）のポートフォリオでは、「実務経験の深さ」と「技術的な意思決定の経験」を示すことが重要です。

作品①: 現職・前職の設計概要（アーキテクチャ図）

内容: 関わったシステムのアーキテクチャ図・技術構成の概要
注意: 機密情報・ソースコードは掲載しない。概念的な設計図に留める
アピールポイント: システム規模・チーム構成・自分の担当範囲を明示

> 採用担当からの評価コメント例: 「前職でのECシステムのアーキテクチャ概要図があり、どの部分を担当したかが明確です。マイクロサービス化を提案・実装した経験の説明が具体的で、設計思想のある候補者だと判断しました」

作品②: 個人開発・OSSコントリビューション

内容: 個人で開発・運用しているプロダクト、またはOSSへのPRマージ実績
アピールポイント: 業務外でも技術に向き合う姿勢・OSS活動でのコードレビュー経験

OSSへのコントリビューションは、GitHubのプロフィールに自動で実績が残ります。バグ修正・ドキュメント改善・テスト追加など、小さな貢献でも積み重ねることが重要です。

> 採用担当からの評価コメント例: 「Reactのドキュメントにプルリクエストをマージしたのはユニークですね。細かいコードでも、OSSコミュニティのレビュープロセスを経験しているのはチーム開発での即戦力として期待できます」

作品③: 技術的負債解消・パフォーマンス改善の実績数値

内容: 「ページロード速度をXX秒からYY秒に改善」「テストカバレッジをX%からY%に向上」等の数値付き実績
アピールポイント: 改善前後の比較・使った技術・改善の根拠を説明できる

経験者の最大の武器は「実務でどのような課題を、どのように解決したか」という具体的な実績です。数値化できる改善実績はポートフォリオでも職務経歴書でも高く評価されます。

> 採用担当からの評価コメント例: 「N+1問題の解消でDBクエリを80%削減した実績があり、Grafanaでの計測方法も説明されていました。問題の特定から改善までのアプローチが体系的で、入社後も同様の取り組みを期待できると判断しました」

未経験・経験者共通のポイント

どちらの場合も、ポートフォリオを作成したら必ず第三者に見てもらうことを推奨します。転職エージェント・技術コミュニティ（connpassやDiscordのエンジニアコミュニティ）・メンターなど、フィードバックをもらえる環境を活用しましょう。

作ったもの本人は「わかって当然」と感じる部分も、初めて見る採用担当者には伝わらないことがあります。第三者の視点で「これは何を作ったか伝わるか」「README を読んで動かせそうか」を確認することが品質向上の近道です。

ポートフォリオは一度作ったら終わりではありません。応募先が変わるたびに最新化し、新しいプロジェクトを追加して継続的にアップデートしていきましょう。

よくある質問

エンジニア転職でポートフォリオは必ず必要ですか？

必須ではありませんが、特に未経験転職や第二新卒では実力を証明できる唯一の手段です。経験者でも「コードが書けること」を示す意味で用意することを強く推奨します。大手企業の一部ではコーディングテストのみで書類判断するケースもありますが、ほとんどのスタートアップ・IT企業ではポートフォリオが選考の重要な判断材料になっています。特に未経験の場合、ポートフォリオなしでの書類通過は難しい企業が多いため、1〜2個でも完成品を用意することを強く推奨します。

ポートフォリオのプロジェクトはいくつ必要ですか？

2〜3個が理想です。数が多くても品質が低いと逆効果になります。「1個でも完成度が高くデプロイ済みのもの」を持つ方が、「未完成品が5個」より評価されます。採用担当者は全プロジェクトを細かく確認する時間がないため、ピン留めした2〜3個の質が高ければ十分です。まずは1個を完成・デプロイまで持っていくことに集中してください。

チュートリアルで作ったものをポートフォリオに載せてよいですか？

そのままの掲載は避けた方が無難です。チュートリアルをベースに自分でUIを変更・機能追加・デプロイまで行ったものであれば、「元はチュートリアルを参考にし、自分でカスタマイズした」と明記することで問題ありません。採用担当者はコードを見れば「チュートリアルのコピーか自力で書いたか」を大体把握できます。独自の工夫を加え、その工夫をREADMEに説明できる状態にすることが大切です。

GitHubのコントリビューションカレンダーが空でも問題ありませんか？

問題はありませんが、継続的に学習・開発しているかの指標として採用担当者が参考にすることはあります。転職活動中は週1〜2コミットを意識するだけでも印象が変わります。コントリビューションカレンダーが直近3〜6ヶ月で活発であれば「転職活動中も学習を続けている」というポジティブな評価につながります。日々の学習の成果を小まめにGitHubにプッシュする習慣をつけることを推奨します。

ポートフォリオサイト自体を自作すべきですか？

自作できればアピールになりますが必須ではありません。GitHubのプロフィールページとREADMEを丁寧に整備するだけでも十分です。Notion・Qiita・個人ブログをポートフォリオ代わりに使うエンジニアも多くいます。自作ポートフォリオサイトはデザインセンスやフロントエンドスキルのアピールになりますが、「ポートフォリオサイトを完璧に作ること」よりも「プロジェクトのコードの質を上げること」の方が採用担当者への訴求力は高いです。時間が限られている場合は、プロジェクトの完成度とGitHubの整備を優先しましょう。

まとめ

エンジニア転職におけるポートフォリオの重要性と、採用担当者が実際に評価するポイントを解説しました。最後に要点を整理します。

採用担当者がポートフォリオで見る5つのポイント

動作するプロダクト: デプロイ済みURLで誰でも確認できる状態
READMEの充実度: 概要・技術・工夫点・セットアップ手順が揃っている
コードの読みやすさ: 命名規則・コメント・ディレクトリ構成が整理されている
技術選定の理由: なぜこのフレームワーク・この構成にしたかを説明できる
更新・改善の継続性: 最終コミットが最近で、継続的に活動している

最優先でやるべきこと

何より大切なのは、「まず1プロジェクトを完成・デプロイすること」です。完璧なポートフォリオを目指すあまり、いつまでも公開できない状態の方が多くいます。最初は小さなアプリでも、完成・デプロイ・README整備まで持っていくことで、採用担当者に「完成させられるエンジニア」という信頼を与えられます。

ポートフォリオが整ったら、次のステップとして面接対策と志望動機の準備を進めましょう。

エンジニア転職の面接でよく聞かれる質問と対策

エンジニア転職の志望動機の書き方・例文