【転職活動で使える】GitHub / ポートフォリオの見せ方・作り方

ポートフォリオは再現可能な実績の証拠であり転職においては実績をアピールするためのエビデンスです。

採用側が見たいのは、①何ができるか（成果・品質）、②どう考えたか（プロセス・意思決定）、③同じ成果を再現できるか（手順・環境）の3点で、エンジニアはGitHubでREADME・実行手順・設計意図・テストを揃え、Issue/PRで思考の跡を残すことが近道です。

本記事では、見せ方＞作り方の順で、構成テンプレ・README雛形・スクショの撮り方・公開/非公開の線引き・面接での提示術（URL/QR/紙1枚）まで、具体策を解説します。

ポートフォリオ（提出資料）の基本設計

転職で使うためのポートフォリオは、相手に見せるために資料や読み手の導線をしっかり用意しておくことが大切です。目的と読み手（ペルソナ）を決め、伝える順番を整えれば、同じ実績でも評価が一段上がります。

採用側は「何ができる（成果）」、「どう考えた（プロセス）」、「再現できるか（手順・環境）」の3点を短時間で見極めます。トップは要約→代表作へ導線を絞り、各事例では課題→打ち手→結果→学びを1枚で完結させます。

GitHubでもNotion/スライドでも、情報設計は共通です。最後に連絡・面談CTA、証拠（スクショ/ログ）、更新日を明記し、信頼と最新性を担保します。

目的とペルソナ定義

ポートフォリオを作りこむ前に「誰に何を判断してほしいか」を絞ります。現場は再現性、人事は一貫性、役員はインパクトを見ると言われます、この温度差を前提に、見る人別の知りたい情報（数値・期間・体制・ROI）を先回りして配置します。

• 目的：選考通過／面接内デモ／年収交渉の根拠づけ などを“1つ”に絞る
• ペルソナ：現場リーダー、人事、役員…それぞれが知りたい指標を想定

ペルソナ	すぐ知りたい	好む形式
現場リーダー	再現性・運用負荷	手順・コード/ダッシュボード
人事	一貫性・コンプラ	1枚サマリー・実績要約
役員	インパクト・ROI	Before/After・数字のグラフ

動線設計（トップ→事例→深掘り→連絡）

トップは3行要約と代表作カードで“嗅覚”をつくり、詳細は課題→打ち手→結果→学びの順で迷わせない設計が理想です。深掘り用にGitHubやデモ、補足資料を用意します。閲覧者の集中が切れない「一本道」を意識すると離脱が減ります。

• トップ：3行サマリー／代表作カード3〜5件／スキルタグ
• 事例ページ：課題→打ち手→結果→学び→再現手順→証拠
• 深掘り：GitHub/デモURL、ダッシュボード、補足資料
• CTA：面談依頼・メール・LinkedIn（QR/ボタン）

事例カードは型で用意する

事例はカード化して粒度をそろえると比較が容易になります。タイトルで役割×成果を一発提示し、期間・体制・数値を冒頭に記載します。最後にREADMEやデモへのリンクで“証拠”へ誘導すると、評価が高くなります。

• タイトル（役割×成果の要約）
• 期間・体制（例：3名／8週間）
• 結果（数値）：◯％改善／◯h削減／売上◯円 など
• 学び：再現条件・限界
• リンク：README/デモ/資料

証拠と安全のバランス

強いポートフォリオは見せられる証拠が揃っていますが、守秘は絶対です。社名や顧客情報はダミー化し、スクショはモザイクで加工。生データは持ち出さず、再現用のサンプルと手順を添えます。安全に配慮しつつ、検証可能性を確保する設計が信頼を生みます。

• 証拠：スクショ（モザイク）／ログ抜粋／グラフ再現／テスト結果
• 秘匿：社名・顧客名・生データは禁止、ダミー化と注記を徹底

メタ情報と検索性

採用側は短時間で必要情報に到達したいもの。タグ（職種・領域・技術）と更新日、関与度（Lead/Support）を明示し、GitHubならREADME先頭に実行手順とデモを直リンクします。内部リンクや目次を整え、検索でも辿れる“情報の住所”を付けると到達率が上がります。

• 各事例に更新日／タグ（職種・領域・技術）／関与度（Lead/Support）
• GitHubはREADME先頭に実行環境・使い方・デモへの直リンク

計測と保守

公開して終わりではありません。クリックや閲覧数を簡易計測し、反応の良い構成を残して磨く。四半期ごとに棚卸しして古い事例はアーカイブ、見せるポートフォリオは最新3〜5本に集約します。リンク切れやレイアウト崩れの定期点検もセットにし、常に“今の実力”を映す状態に保ちます。

• クリック計測（UTM/短縮URL）／GitHub Insights／Notionの閲覧数
• 四半期ごと棚卸し：古い事例はアーカイブし最新3〜5本に絞る

直前チェックリスト

最後は品質の最終確認をします。トップで“何者か”が3行で伝わるか、代表作に定量成果が出ているか、守秘の配慮が十分か、CTAが各ページにあるかをチェック。更新日が一年以内に揃っているかも重要です。

• トップで“何者か”が3行で伝わる
• 代表作は3〜5件、数字が冒頭に出ている
• 課題→打ち手→結果→学び→証拠→再現手順の順番
• 連絡先・CTAが全ページ下部に常設
• 秘密情報のダミー化／モザイク済み
• 更新日が1年以内に揃っている

この基本設計を先に固めれば、GitHubでもNotionでも“見せた瞬間に伝わる”強いポートフォリオに仕上がります。

GitHub編：見せ方の黄金パターン

採用側は“全部”を読みません。トップ（プロフィール/ピン留め）→代表3〜5本→READMEの冒頭→実行手順/デモの順に、最短で再現性が分かる導線を辿ります。レポジトリは厳選し、READMEは目的→環境→使い方→設計→テスト→スクショの型で即判断可能にします。

Issue/PRには思考の痕跡を残し、デモとバッジで“動く証拠”を添えると最適です。以下の4点を整えるだけで、評価体験は劇的に向上します。

リポジトリ選定基準（3〜5本に絞る）

「過去全部」ではなく「採用要件に直結する代表作」だけを置きます。役割・規模・成果が被るものは統合し、用途の異なる3〜5本にまとめます。

選定のものさし

観点	目安	例
役割の明確さ	自分の貢献が判る	Lead/Supportの明記、コミット比率
再現性	READMEだけで再現可	ワンコマンド実行・Dockerfile
汎用性	別案件でも応用可	ライブラリ化／設定切替
規模の多様性	S/M/L を混ぜる	ミニツール／中規模API／フロント+バック
学びの深さ	失敗→改善の痕跡	Issue/PRに検討ログ

READMEテンプレ（目的/環境/使い方/設計/テスト/スクショ）

READMEは採用側にとっての仕様書です。最初の15秒で「何を、どう試せるか」を伝え、1分で判断できる構成にします。以下のテンプレでは、上から順に埋めるだけで“動く証拠”まで到達できます。

章立て（推奨順）

1. 目的（課題/背景・解く価値）
2. デモ/スクショ（動画/GIF/URL）
3. クイックスタート（1分で動く）
4. 環境（言語/ランタイム/依存）
5. 設計（構成図/ディレクトリ/主要責務）
6. テスト/品質（実行方法・カバレッジ）
7. 使い方（CLI/API/画面）
8. 学び/限界/今後
9. ライセンス/注意（機密・商標回避）

コピペ雛形（抜粋）

# プロジェクト名
> 一行で目的と成果（例：検索の平均応答を30%短縮）

## デモ
- URL: https://...
- GIF: docs/demo.gif

## クイックスタート
```bash
# 1) セットアップ
make setup   # or: npm i / pip install -r requirements.txt
# 2) 起動
make up      # or: npm run dev / docker compose up
# 3) テスト
make test

## 環境
- Node 20 / Python 3.11 / Postgres 15
- 主要依存: Next.js / FastAPI / Playwright

## 設計
- 構成図: docs/architecture.png
- ディレクトリ:
  - /app … アプリ本体
  - /infra … IaC/コンテナ
  - /tests … 自動テスト
- 責務: app/api=..., app/service=...

## 使い方
- CLI: `npm run cli -- --help`
- API: `GET /v1/search?q=...`
- 画面: `/` → 検索 → 結果詳細

## テスト・品質
- 実行: `npm test` / `pytest -q`
- カバレッジ: 82%（/src 配下）

## 学び・限界・今後
- 学び: キャッシュ戦略 A/B 比較で〇〇が有効
- 限界: 〇〇条件で性能低下（代替案：□□）
- 今後: モニタリング強化、E2E テスト追加

## ライセンス・注意
- 実データは含みません（全てダミー/匿名化）
- © 2025 YourName

Issue・PR・Projectsで思考ログを可視化

面接官は「何を作ったか」だけでなく「どう考えたか」を見ています。コード差分は結果でしかないので、課題→選択肢→判断→検証の思考の跡を GitHub 上に残しましょう。Issue には課題定義と仮説、PR には採用理由とテスト観点、Projects には進捗と優先順位。小さめの PR を連発し、意思決定をテキストで残すと再現性が伝わります。

• 最低限の運用ルール
  • Issue：目的／KPI、代替案 A・B・C と評価軸、受入基準（DoD）、影響範囲
  • PR：目的（何を／なぜ）、採用・不採用の比較、テスト結果、Before/After スクショ、互換性
  • Projects：Todo / In Progress / Review / Done：WIP 制限（同時作業を 2〜3 件に固定）

• 粒度の目安
  • Issue＝「1 つの意思決定につき 1 件」
  • PR＝「レビューに 20 分以内で読める差分」
  • コミット＝「1 つの意図（命名を動詞で）」

• 可視化の小ワザ
  • ラベル統一：feat / fix / perf / docs / chore
  • 相互リンク：PR 冒頭に「Closes #123」／Issue から設計図・計測ログへリンク
  • 週次まとめ：Projects の Done から「今週の学び」を 3 行で記録

デモ公開（GitHub Pages 等）と Badge 整理

“動く”デモは最強の説得材料です。README の冒頭に Live Demo を大きく置き、1 クリックで到達できる導線を用意します。実データは使わずダミー化し、ヘルスチェックや動画 GIF での代替も準備。あわせてバッジで「状態を一目で」伝えると、審査者の判断が速くなります。

• デモ公開の選択肢（用途別）
  • 静的フロント：GitHub Pages（最速・無料）
  • SSR/API あり：Vercel / Render（無料枠で OK、環境変数管理も簡単）
  • 触れる環境：Codespaces / Devcontainer（エディタ付きの再現）
  • 重い処理：短尺 GIF・録画リンクを併記（回線や時間に依存しない）

• 運用ポイント
  • 導線：トップ → README → Live Demo（3 クリック以内）
  • 安全：スクショはモザイク、ダミーデータ種を /fixtures に明記
  • 信頼：404/エラー監視、デプロイ手順は /docs/deploy.md に明記

• おすすめ Badge（最大 5 つに厳選）
  • Build（CI Passing）／Coverage（80% など）
  • Lint/Format（OK）／Security（Dependabot/Snyk）
  • Live Demo（外部リンクボタン）

• 仕上げチェック
  • README 冒頭に Live Demo と 1 分クイックスタート
  • バッジは 5 個以内で視認性良好
  • デモはダミーで安全、リンク切れなし
  • デモ不可の要件は GIF と数値ログで代替表現済み

この 2 セット（思考ログ＋動く証拠）が揃うと、「作れます」から一歩進んだ再現できる人の証明になります。

GitHub編：作り方の実践

“見せ方”を決めたら、あとは作り方で再現性を担保します。評価者はコードの量よりも、進め方の健全さ（粒度・検証・証跡）を見ています。小さく作って早く見せる→安全なデータで検証→法務ラインを越えない、の3点を満たせば、安心して「任せられる人」に映ります。

小さく作って早く見せる（コミット粒度/TDD）

完成形を追うより、15〜30分で動く最小単位を積み上げます。粒度が細いほどレビューと説明が容易。TDD（テスト駆動）を緩やかに取り入れると、仕様が自然に文章化されます。

• 目安
  • ブランチ：1課題＝1ブランチ（ feat / search-caching など）
  • コミット：1意図＝1コミット（20〜80行/件、メッセージは動詞始まり）
  • PR：20分で読み切れる差分／Before→Afterのスクショ付き

• 軽量TDDループ
  1. 期待する振る舞いをテストで書く（失敗を確認）
  2. 最小実装で通す（仮実装OK）
  3. リファクタ（命名・分割・例外処理）

• コミット文テンプレ
  feat: add cache layer to cut p95 latency by ~30%
  test: add e2e for query timeout (3s SLA)
  refactor: extract repository interface

サンプルデータの匿名化・ダミー化

“動く証拠”にはデータが要りますが、実データの持ち出しは厳禁。匿名化かダミー化で安全に再現しましょう。

• 方針と使い分け
  • 匿名化（Anonymization）：実データを不可逆に加工（統計検証や分布再現が目的のとき）
  • ダミー化（Synthesis/Mock）：架空データを生成（機密の可能性があるときは原則こちら）

• 具体策（例）
  • 置換：氏名/メール/住所 → Faker や乱数で置換
  • マスキング：下4桁のみ表示、日付は月単位へ丸め
  • ノイズ付与：正規分布ノイズで数値を±数％ゆらす
  • カーディナリティ調整：まれ値（一意なIDや極端な金額）を除外

• 実装メモ
  • サンプルは /fixtures や /sample_data に格納、生成スクリプトも同梱
  • READMEに「本データは合成・匿名化」の注記、生成方法と件数を明記
  • データの統計プロファイル（平均・分散・分布図）を添えると説得力UP

ライセンス/著作権/秘密情報の線引き

評価は上げたい、でも法務ラインは越えない。ライセンス表示・権利帰属・秘密情報の扱いを最初に決め、READMEに書いておきます。

• OSSライセンスのミニ比較

ライセンス	商用利用	条件/注意	向くケース
MIT	可	著作権表示	サンプル/テンプレ配布
Apache-2.0	可	特許条項あり	企業利用を想定
GPL-3.0	可	派生物をGPLで公開	ライブラリ自体を公開したい

著作権・雇用の注意

• 前職/現職で作成したコード・資料は持ち出さない（職務著作）
• 再実装でも機密仕様の再現は避ける（特定顧客の要件等）
• 画像/フォント/データセットは出典とライセンスをREADMEに記載

秘密情報のガード

• .env／鍵は絶対にコミットしない（.gitignore + 秘密管理）
• 誤コミット対策：pre-commitでsecret scan（trufflehog/gitleaks）
• スクショは社名・顧客名をモザイク、UIの配置だけを示すダミーで代替可

表記テンプレ（README末尾）

本リポジトリは学習・採用選考向けのサンプルです。
企業・顧客の機密情報は含まず、データはすべて合成/匿名化しています。
ソースコードは MIT License、記載のロゴ/商標は各権利者に帰属します。

面接での見せ方

面接は「見せて→納得してもらう」プレゼンです。URLを渡すだけでは弱く、その場で“動く証拠”を短時間で体験してもらう設計が重要です。入口（URL/QR/紙一枚）→60秒デモ→対話の深掘り（逆質問）までを一連の導線にすると、評価者の意思決定が早まります。下記の型をそのまま使えば、オンライン/対面どちらでも再現できます。

URL/QR/紙一枚ポートフォリオの使い分け

その場の環境によって最短で開ける手段を切り替えます。URL＝事前共有／QR＝当日即時／紙一枚＝電波・社内端末制限の保険という役割分担を決めておきましょう。

使い分け早見表

シーン	最適手段	具体策
オンライン（事前提出あり）	URL	メールに「トップ／代表3本／Live Demo」の直リンクを並べる
対面・会議室（私物PC不可）	QR	A4一枚にQR×3（トップ/代表作/デモ）。短縮URLも併記
電波不安・端末制限あり	紙一枚	Before/After図・主要数値・画面キャプチャで1分要約
役員最終（短時間）	紙＋QR	紙で要点→興味箇所だけQRで詳細へ誘導

紙一枚のレイアウト（A4）

• 3行サマリー（役割×成果）
• 代表作カード（数値・期間・体制）×3
• Before/After図（1枚）
• 右下にQR×3（ポートフォリオ・代表作・Live Demo）

60秒デモ台本（導入→操作→指標）

デモは**60秒で“価値→操作→結果”**を見せ切るのがコツ。下の台本を読み上げるだけで成立します。

• タイムライン台本

• 0–10秒｜導入
  「◯◯の応答を30％短縮したミニプロダクトです。GitHubとLive Demoがあります。」
• 10–35秒｜操作
  「起動はdocker compose up。検索に“abc”を投げると、キャッシュ層が働きP95が210ms→140msに下がります。」
• 35–50秒｜仕組み
  「ボトルネック解析→キャッシュ戦略比較→E2EテストまでをIssue/PRで記録しています。」
• 50–60秒｜着地
  「御社の◯◯でも同じ手順で再現可能です。詳細はREADMEのクイックスタートと指標ログをご覧ください。」

• 画面構成（切替順）
  1. READMEの一行要約＆Live Demoボタン
  2. 実行ターミナル（起動→ログ）
  3. 計測ダッシュボード（Before/After）
  4. Issue/PR（意思決定ログ）

• 小ワザ
  • 失敗に備え、30秒の録画GIFを用意（無音・軽量）
  • 見せる指標は1つだけ（例：P95、CVR、MTTR）
  • 口頭の数字は画面にも表示（テキスト注釈）

逆質問へのブリッジ（評価軸との照合）

デモ直後は関心が最も高い瞬間。相手の評価軸と自分の実績を照合する質問で合意形成に入ります。ゴールは「再現できる前提」を互いに言語化し伝えることです。

• ブリッジの言い回し例
  • 「今ご覧いただいたP95短縮は、御社の◯◯指標でいうとどのKPIに最も近いでしょうか？」
  • 「最初の90日で期待されるアウトカムに当てはめると、どの段階から私が主導できますか？」
  • 「似た事例でつまずきやすい点は？その場合の支援体制や判断ラインを伺いたいです。」

• クロージングの一言（30秒）
  • 「本件はクイックスタートとテストが揃っているので、入社後1週目から検証可能です。
    もし◯◯環境での適用に障壁があれば、代替案Bで1スプリント内に比較して報告します。」

• 逆質問チェックリスト
  • KPI/評価指標に名称で紐づけて聞けた
  • 90日・体制・権限を具体語で確認した
  • リスクと支援/合意形成の場を質問できた

この流れに沿えば、ポートフォリオは“置き資料”から合意形成のツールに変わり、短時間でも強い印象を残せます。

GitHub / ポートフォリオの活用はIT転職に強いエージェントを利用する

ポートフォリオは「作って置く」だけでは効果が限定的。求人ごとの評価軸に合わせて“見せ替える”ことで初めて刺さります。そこで役立つのが、IT職種に強いエージェントの利用です。

IT専門転職エージェント＠PRO人【アットプロジン】 (PR) なら、求人票の行間（採用背景・KPI・技術スタックの優先度）を踏まえ、IT経験のあるITに詳しいアドバイザーが、GitHubや1枚ポートフォリオのチューニングなどにも知識を持ったアドバイスが期待できます。

まとめ：GitHub / ポートフォリオの見せ方・作り方

ポートフォリオは「量」より「設計」。採用側は成果・プロセス・再現性の3点を短時間で見ます。まずは代表作を3〜5本に厳選し、READMEを目的→デモ→クイックスタート→設計→テスト→学びの型で即判断可能に。Issue/PRで思考ログを残し、Live Demo＋バッジで“動く証拠”を提示。作り方は小さく速く（粒度/TDD）、データは匿名化・ダミー化、ライセンスと守秘を徹底。面接はURL/QR/紙1枚→60秒デモ→逆質問ブリッジの導線で“合意形成”まで運びます。