この記事では、エンジニアが職務経歴書にポートフォリオを正しく組み込む5つのポイントを採用担当者の視点で解説します。GitHubのURLを貼るだけで書類選考を通過できない理由と、採用担当者が「確認したい」と感じる記載の書き方を例文付きで紹介します。
採用担当者がポートフォリオを確認する本当の理由
エンジニア採用において、採用担当者が職務経歴書だけで判断できる情報は「担当業務の範囲」と「使用技術の一覧」に限られます。この2点だけでは、応募者が技術を本当に使いこなせるのかを見極めることができません。
職務経歴書だけでは伝わらない「実装力」の差
「Reactを使った開発経験あり」という記載は、コピーしたコードを修正した経験でも、アーキテクチャ設計まで一人で担当した経験でも、同じ表現になります。採用担当者が職務経歴書の技術スタック欄から判断できるのは、あくまで「その技術に触れた経験の有無」にとどまります。
ポートフォリオが求められる理由は、この曖昧さを解消するためです。コードの可読性、設計の一貫性、ドキュメンテーションの質は、実際の成果物を確認しなければわからない情報です。採用担当者がコードを見て「この人は書ける」と判断するか否かが、書類選考の分かれ目になります。
採用担当者はここを見ている
- コードの可読性（命名規則・関数分割・コメントの有無）
- READMEの説明度（技術選定の理由まで書かれているか）
- コミット履歴の質と頻度（継続して書いているか）
- デプロイ済みかどうか（動くものとして確認できるか）
- スキルシートの技術スタックとの一致（乖離がないか）
採用担当者がポートフォリオを見る平均時間
書類1枚あたりに採用担当者が割く時間は、一般的に30秒から1分程度です。ポートフォリオへのアクセスは「URLをクリックする動機がなければ発生しない」という現実があります。職務経歴書上でポートフォリオへの導線が整っていないと、URLがあっても確認されないまま選考が終わります。
| 確認段階 | 採用担当者の行動 | 通過/不通過の分岐 |
|---|---|---|
| 職務経歴書の確認 | スキルと経験年数をスキャン | URLが目立つ位置にあるか |
| URLのクリック | 説明文があれば大半がクリック | 説明文なしでは半数以上がスキップ |
| README確認 | 最初の5行で概要が把握できるか | 概要がなければそのまま閉じる |
| デモ・コード確認 | 動くか・コードが読めるか | 完成度と可読性で合否の判断 |
職務経歴書とポートフォリオの役割を整理する
「職務経歴書に全部書いて、ポートフォリオはおまけ」または「ポートフォリオがあれば職務経歴書は最低限でいい」——この誤解が書類選考で落ちる原因の一つです。採用担当者から見ると、この二つは別々の情報を担う補完関係にあります。
| 書類 | 採用担当者に伝える情報 | 確認方法 |
|---|---|---|
| 職務経歴書 | 経歴・規模・役割・スキルの幅 | 流し読み（30秒〜1分） |
| ポートフォリオ | コードの質・設計力・学習姿勢 | READMEとコードを重点確認 |
ポートフォリオが特に有効な場面
- 若手・第二新卒エンジニア：職歴が浅く、実績でアピールできる材料が少ない
- 独学・スクール出身の未経験エンジニア：公式な職歴がなく、ポートフォリオが唯一の実力証明になる
- スタートアップ・ベンチャーへの応募：技術力を直接評価する企業が多く、コードを見た上で判断される
- 前職と異なる技術スタックへの転換：学習済みであることをコードで証明できる
ポートフォリオの有無より重要なもの
ポートフォリオが必ずしも求められない場面があるのも事実です。大手SIerや管理職ポジション、マネジメント経験が10年以上ある求人では、コードより「プロジェクト規模・チーム運営実績・関係者調整能力」が優先されます。個人開発の実績が少ない場合、無理にポートフォリオを整えるより、職務経歴書のプロジェクト詳細欄を充実させることを先行してください。
完全無料の履歴書・職務経歴書作成ツール
「サクレキ」質問に答えるだけで、選考書類がカンタンに完成
- 自己PR・志望動機も例文付きで安心
- スマホからでもOK。たった3分で履歴書・職務経歴書が完成
- 自動フォーマットで書き間違いゼロ
＼ 完全無料・簡単3分で完成！ ／
無料で履歴書・職務経歴書を作成する →職務経歴書へのポートフォリオ記載 5つのポイント
書類選考を通過するエンジニアの職務経歴書には、ポートフォリオの記載に共通したパターンがあります。以下の5点を押さえることで、採用担当者に「確認したい」と思わせる導線を作れます。
①記載箇所 — スキルシート上部とプロジェクト詳細の両方に書く
ポートフォリオURLを記載する箇所は1か所だけでは不十分です。採用担当者が「この人はどんなものを作っているのか」と気になるタイミングは2回あります。職務経歴書を読み始めたとき（スキルシート上部）と、特定のプロジェクト詳細を読んでいるとき（プロジェクト欄）です。
良い記載例
【ポートフォリオ・外部リンク】
GitHub：https://github.com/username
技術ブログ：https://zenn.dev/username
【個人開発プロジェクト】
■ タスク管理Webアプリ（2025年4月〜2025年8月）
使用技術：Next.js 14 / TypeScript / Supabase / Vercel
GitHub：https://github.com/username/task-manager
デモ：https://task-manager-demo.vercel.app
概要：個人のタスク管理効率化を目的に開発。カレンダー連携と優先度フィルター機能を実装。
NG例
ポートフォリオ：https://github.com/username
URLだけで説明がなく、何のコードか・どんな技術を使っているか採用担当者に伝わらない。
②説明文を添える — URLだけでは「見てもらえない」理由
URLだけが記載されていても、採用担当者にはクリックする動機が生まれません。「何のサービスか」「どんな技術を使ったか」「なぜ作ったか」が1〜2行で伝わることで、初めて「見てみたい」という行動につながります。
良い記載例
GitHub：https://github.com/username/portfolio-app
※ TypeScript + Next.js + PostgreSQL で構築したポートフォリオ管理アプリ。Lighthouse スコアで90点以上を維持し、コンポーネントの再利用性を重視した設計にしています。
NG例
GitHub：https://github.com/username/portfolio-app
URLの直後に何の説明もない。採用担当者がクリックするかどうかは運任せになる。
③使用技術・開発目的・成果の3点セットで明示する
採用担当者がポートフォリオの説明文に最低限求める情報は3つです。この3点がそろって初めて「経験の証明」として機能します。
- 使用技術：どの言語・フレームワーク・インフラを使ったか（例：React / Node.js / AWS EC2）
- 開発目的：なぜ作ったか（例：自分のタスク管理の煩雑さを解消するため）
- 成果・工夫点：何を達成したか・技術的に何を意識したか（例：Lighthouse スコアで90点以上を維持、コンポーネントの再利用性を重視した設計）
成果が数値で示せる場合は積極的に活用します。「月間アクセス500件」「API レスポンスを3秒から0.5秒に短縮」のような具体値は、採用担当者の印象に強く残ります。
採用担当者はここを見ている
- 技術選定の「理由」が書かれているか（「Reactを使いました」より「状態管理の複雑さを解消するためReact + Recoilを選択しました」）
- 課題 → 解決策 → 結果のフローが説明文から読み取れるか
- 数値化できる成果が含まれているか（件数・時間・スコアなど）
④GitHub・デモサイト・Qiitaの使い分け
ポートフォリオとして使える媒体は複数あります。それぞれの特性を理解した上で使い分けることで、採用担当者に伝わる情報の幅が広がります。
| 媒体 | 最適な用途 | 採用担当者が確認するポイント |
|---|---|---|
| GitHub | コードの公開・バージョン管理 | コード品質・コミット頻度・READMEの充実度 |
| デモサイト（Vercel / Render 等） | 動くサービスを見せる | 実際の動作・UX・完成度 |
| Qiita / Zenn | 技術的な知見のアウトプット | 学習姿勢・説明能力・使用技術の深さ |
3つすべてを用意する必要はありません。優先順位としては「GitHub（必須） → デモサイト（あれば強力） → Qiita/Zenn（補足として有効）」の順です。GitHub アカウントだけでも、READMEとコミット履歴を整えることで十分に機能します。
⑤機密案件・未完成のポートフォリオの正しい扱い方
業務で実装したコードは契約上公開できないケースがほとんどです。「見せられるものがない」と感じているエンジニアも多いですが、この問題には有効な対処法があります。
採用担当者はここを見ている
- 「業務コードは機密のため非公開」と職務経歴書に明記すること自体はプラス評価。責任感の表れとして受け取られる
- 代替手段として「業務で使用した技術を使った個人開発サンプル」を用意すると最も効果的
- 未完成のポートフォリオは「開発中」と明記した上でREADMEに設計図と進捗を記載すれば十分。完成していないことより「何を目指しているか」が見える状態が重要
ポートフォリオがあっても落ちるエンジニアのNGパターン3つ
ポートフォリオを持っているのに書類選考を通過できないエンジニアには、共通したNGパターンがあります。「作ったものの質が低い」のではなく、「見せ方に問題がある」ケースがほとんどです。
NGパターン1：URLだけ記載して説明ゼロ
NG例
GitHub：https://github.com/username
何のコードが公開されているか職務経歴書から読み取れない。クリックする前に次の候補者の書類へ移られる。
採用担当者はURLをクリックして確認する手間をかける前に、次の候補者の書類へ移ります。URLの直後に1〜2行の説明を追加するだけで、クリック率は大きく変わります。
NGパターン2：READMEが空または更新が数年前に止まっている
採用担当者が GitHub を開いた瞬間に確認するのが README です。空白や「準備中」だけの README は、職務経歴書に記載したプロジェクトへの信頼性を下げます。更新が数年前に止まっているリポジトリも同様で、「現在も継続して技術を学んでいるか」という視点でマイナスに働きます。
採用担当者はここを見ている
- READMEに最低限含めるもの：プロジェクト概要・使用技術・セットアップ手順・スクリーンショット（Webアプリの場合）
- 最終コミットが1年以上前のリポジトリは職務経歴書に記載しないか、「現在はメンテナンス停止」と注記する
NGパターン3：職務経歴書のスキルとポートフォリオの技術が連動していない
職務経歴書のスキルシートに「Python・Django・AWS」と書きながら、GitHub には「HTML・CSS・jQuery」のリポジトリしかない状態は、採用担当者に「書類の記載と実態が異なるのでは」という疑念を与えます。
採用担当者はここを見ている
- 職務経歴書のスキルシートとポートフォリオの技術スタックを一致させること
- 業務では使っているが個人開発では別の技術を使っている場合は「業務で主に使用。個人開発では〇〇を学習中」と注記を添える
職種別 ポートフォリオ記載例文
エンジニアの職種によって、ポートフォリオで見せるべき内容は異なります。自分の職種に近いパターンを参考に、職務経歴書の記載内容を整えてください。
職務経歴書全体の構成や自己PRの書き方は、エンジニアの職務経歴書の書き方で詳しく解説しています。
Webエンジニア（フロントエンド・バックエンド）
Webエンジニアは動くサービスを見せやすい職種です。GitHub のコードだけでなく、デモサイトまで用意することで採用担当者の確認がスムーズになります。
良い記載例（スキルシート上部）
【外部リンク】
GitHub：https://github.com/username
デモサイト：https://myapp.vercel.app
【個人開発プロジェクト】
■ ECサイト模擬アプリ（2025年4月〜2025年8月）
使用技術：Next.js 14 / TypeScript / Prisma / PostgreSQL / Vercel
概要：商品一覧・カート・決済フロー（Stripe連携）を一人で実装。Atomic デザインパターンを採用し、コンポーネントの再利用性を重視。
GitHub：https://github.com/username/ec-app
デモ：https://ec-demo.vercel.app
インフラ・クラウドエンジニア
インフラエンジニアはコード主体のポートフォリオを持ちにくい職種です。IaC コード（Terraform・Ansible 等）のリポジトリや、構築した環境の構成図・設計書を公開することがポートフォリオの代替として有効です。
良い記載例
【外部リンク】
GitHub：https://github.com/username
IaC コード：https://github.com/username/terraform-aws-sample
【個人プロジェクト】
■ AWS 3層アーキテクチャ構築サンプル（2025年6月〜）
使用技術：AWS（EC2 / RDS / ALB / CloudFront）/ Terraform / Ansible
概要：Webアプリを想定した3層構成（Web・AP・DB）を Terraform でコード化。GitHub Actions で変更時に自動適用する CI/CD パイプラインも実装。
※ README 内にアーキテクチャ図と設計方針を記載しています。
採用担当者はここを見ている
- 「環境を構築しました」より「なぜその設計にしたか」が伝わる構成図・コメントが評価を上げる
- Qiita / Zenn に環境構築の記事を投稿している場合はURLを添えると学習姿勢のアピールになる
独学・未経験エンジニア
未経験エンジニアにとって、ポートフォリオは職務経歴書で語れない実力を補う唯一の手段です。完成度よりも「作り切った実績」と「なぜこの機能を実装したかの説明」が明確なことを優先してください。
良い記載例
【外部リンク】
GitHub：https://github.com/username
Qiita：https://qiita.com/username
【制作物（独学）】
■ 家計簿Webアプリ（2025年9月〜2025年11月）
使用技術：Ruby on Rails 7 / MySQL / Bootstrap / Heroku
概要：収支を月別・カテゴリ別に集計・グラフ表示するアプリ。ユーザー認証（Devise）・管理画面（ActiveAdmin）を実装。
開発理由：既存の家計簿アプリの痒い所に手が届かない部分があり、自分で作ることで Rails の CRUD 操作・認証機能・DB設計の理解を深めることを目的に制作。
GitHub：https://github.com/username/household-app
数値で実績を示せない場合は「なぜ作ったか」と「技術的に意識した点」を具体的に書くことで、採用担当者に開発の意図と思考プロセスを伝えられます。実績がないことを不安に感じている場合は、職務経歴書 実績なし 例文も参考にしてください。
完全無料の履歴書・職務経歴書作成ツール
「サクレキ」質問に答えるだけで、選考書類がカンタンに完成
- 自己PR・志望動機も例文付きで安心
- スマホからでもOK。たった3分で履歴書・職務経歴書が完成
- 自動フォーマットで書き間違いゼロ
＼ 完全無料・簡単3分で完成！ ／
無料で履歴書・職務経歴書を作成する →まとめ
- 採用担当者がポートフォリオで確認するのは「コードの可読性」「READMEの充実度」「スキルシートとの技術的一致」の3点
- ポートフォリオURLはスキルシート上部とプロジェクト詳細欄の2か所に記載する
- URLだけの記載は確認されないまま終わる。1〜2行の説明文を必ず添える
- 使用技術・開発目的・成果の3点セットが揃って初めてポートフォリオが「実力の証明」として機能する
- 業務コードが公開できない場合は「機密のため非公開」と明記した上で、個人開発サンプルを別途用意する
職務経歴書とポートフォリオを連動させた書類は、採用担当者に「この人の技術を実際に確認したい」という動機を与えます。URLを添える位置、説明文の中身、GitHub 上の README を整備する——この3点を見直すことから始めてください。
職務経歴書全体の書き方については、職務経歴書の書き方で採用担当者が落とす書類のNGパターンと書類通過のコツを解説しています。
職務経歴書のポートフォリオに関するよくある質問
- GitHubだけでポートフォリオとして使えますか？
-
十分に使えます。GitHubはコードの質・コミット頻度・ドキュメントを一か所で確認できるため、採用担当者が最も好む媒体のひとつです。READMEの整備とコミット履歴の継続が、GitHubポートフォリオの評価を上げる最大のポイントです。デモサイトを別途用意できればより強力になりますが、GitHubだけでも問題ありません。
- 業務で開発したシステムはポートフォリオに使えますか？
-
所属企業の就業規則や機密保持契約を確認する必要があります。多くの場合、業務コードの外部公開は禁止されています。代替手段として「業務で使用した技術を使った個人開発サンプル」を別途作成し、職務経歴書に記載することを推奨します。「業務コードは機密のため非公開」と職務経歴書に明記すること自体は、責任感の表れとして採用担当者にプラスに受け取られます。
- スクール課題や模写コーディングはポートフォリオに使えますか？
-
使えます。ただし「スクール課題のため」と明記した上で、課題そのものより「自分でどんな追加実装・工夫をしたか」を説明することで、採用担当者に個人の技術力として伝わります。模写コーディングのみの場合は、そこに1つでも自分で機能を追加することを先に行うと、より説得力が増します。
- ポートフォリオのURLが将来変わる可能性があります。どうすればいいですか？
-
GitHub のリポジトリURLはアカウント名が変わらない限り変更されません。デモサイトのURLが変更される可能性がある場合は、独自ドメインを取得してVercel等のホスティングサービスに紐付けることでURLを固定できます。応募書類を送付した後にURLが変わった場合は、採用担当者にメールで変更後のURLを通知してください。
コメント