GitHubポートフォリオの作り方（エンジニア転職）

エンジニア転職では、GitHub上の公開リポジトリが選考の補助材料になることがあります。このページはそのポートフォリオ整理に限定し、職務経歴書の書き方や志望動機の組み立ては履歴書の領域と切り分けます。Pinnedリポジトリ、READMEの構成、デモ手順、機密のマスク、Contributionの見せ方を中心に解説します。フォロワー数やスター数の目標値は示しません。

Pinned repo

プロフィール上部に固定表示するリポジトリ。採用側が最初に見ることが多い。

README

目的、技術選定理由、実行手順、未実装を書く文書。履歴書とは別用途。

機密境界

社名、顧客、未公開API、本番URLを公開リポジトリに載せない線引き。

最小デモ

cloneして数コマンドで動く状態。スクリーンショットやGIFは補助。

GitHubポートフォリオと職務経歴書は補完関係です。経歴書がタイムラインと役割を担い、GitHubが具体的なコードと設計判断の証拠になります。同じ内容を両方に冗長コピーする必要はありません。

GitHubポートフォリオの役割比較では、「観点」は「目的」、「GitHub（このページ）」は「コードと設計の証拠」、「職務経歴書」は「経歴と役割の要約」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

GitHubポートフォリオの役割比較では、「観点」は「形式」、「GitHub（このページ）」は「リポジトリとREADME」、「職務経歴書」は「PDF・Web履歴書」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

GitHubポートフォリオの役割比較では、「観点」は「機密」、「GitHub（このページ）」は「公開前提でマスク」、「職務経歴書」は「一般化した記述」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

GitHubポートフォリオの役割比較では、「観点」は「更新」、「GitHub（このページ）」は「実装に合わせて」、「職務経歴書」は「転職期にまとめて」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

GitHubポートフォリオの役割比較では、「観点」は「関連記事」、「GitHub（このページ）」は「このテーマ」、「職務経歴書」は「履歴書」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

求人票に「GitHub URL提出」とある場合、見られるのはPinnedの少数リポジトリであることが多いです。全リポジトリを磨くより、代表1〜3本のREADMEを完成させる方が効率的です。

GitHubポートフォリオの求人票の読み替えでは、「書いてあること」は「URL提出」、「確認したい実態」は「Pinnedの有無」、「面談での質問例」は「どのリポジトリを重点的に見ますか」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

GitHubポートフォリオの求人票の読み替えでは、「書いてあること」は「OSS貢献」、「確認したい実態」は「自前実装の割合」、「面談での質問例」は「Forkのみのrepoは対象外ですか」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

GitHubポートフォリオの求人票の読み替えでは、「書いてあること」は「デモ」、「確認したい実態」は「ローカル実行可否」、「面談での質問例」は「クラウドデモURLは必要ですか」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

GitHubポートフォリオの求人票の読み替えでは、「書いてあること」は「ライセンス」、「確認したい実態」は「商用利用コード」、「面談での質問例」は「業務時間外の成果物のみでよいですか」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

GitHubポートフォリオの求人票の読み替えでは、「書いてあること」は「共同開発」、「確認したい実態」は「Contributionの割合」、「面談での質問例」は「ペアプロジェクトの役割はREADMEで足りますか」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

GitHubポートフォリオの求人票の読み替えでは、「書いてあること」は「秘密保持」、「確認したい実態」は「公開NG分野」、「面談での質問例」は「過去案件の技術名のみ書いてよい範囲は」です。件数・年収・合格率は集計方法や時期で変わるため、求人票と公式サイトの最新情報を確認してください。

• Secretsと社名をgrepで確認した
• Pinnedを1〜3本に絞った
• READMEに目的・手順・トレードオフを書いた
• 履歴書の記述と矛盾がない
• Licenseファイルを追加した

確認ポイントは「Secretsと社名をgrepで確認した」です。GitHubポートフォリオの求人票に無いことが多いので面談メモに残します。曖昧な答えのときは最近の実例を1つ依頼してください。実例が出せない仕事は期待値が人によって違います。未確認のまま応募理由にしないでください。

確認ポイントは「Pinnedを1〜3本に絞った」です。GitHubポートフォリオの求人票に無いことが多いので面談メモに残します。曖昧な答えのときは最近の実例を1つ依頼してください。実例が出せない仕事は期待値が人によって違います。未確認のまま応募理由にしないでください。

確認ポイントは「READMEに目的・手順・トレードオフを書いた」です。GitHubポートフォリオの求人票に無いことが多いので面談メモに残します。曖昧な答えのときは最近の実例を1つ依頼してください。実例が出せない仕事は期待値が人によって違います。未確認のまま応募理由にしないでください。

確認ポイントは「履歴書の記述と矛盾がない」です。GitHubポートフォリオの求人票に無いことが多いので面談メモに残します。曖昧な答えのときは最近の実例を1つ依頼してください。実例が出せない仕事は期待値が人によって違います。未確認のまま応募理由にしないでください。

確認ポイントは「Licenseファイルを追加した」です。GitHubポートフォリオの求人票に無いことが多いので面談メモに残します。曖昧な答えのときは最近の実例を1つ依頼してください。実例が出せない仕事は期待値が人によって違います。未確認のまま応募理由にしないでください。

GitHubポートフォリオでは、ツール名の羅列より、自分が判断した範囲の説明が先です。秘密情報は一般化し、確認できない数字は書きません。

1. 01
   公開棚卸し

   Public repo一覧を取得し、不要なものをPrivate化またはアーカイブ。ForkだけのものはPinnedから外す。

2. 02
   代表1本選定

   自分が設計から説明できるもの。チュートリアル丸写しのみは避け、差分をREADMEに書く。

3. 03
   READMEテンプレ

   概要、技術選定、セットアップ、スクリーンショット、今後の課題の見出しを固定。

4. 04
   経歴書と突合

   履歴書のプロジェクト名・期間とREADMEの説明が矛盾しないか確認。

IPAの情報セキュリティ関連ガイドは、公開コードに機密を載せない一般論の参照先になります。個人の著作権やOSSライセンス遵守は各リポジトリのLICENSE表記で確認してください。

GitHubポートフォリオの作り方（エンジニア転職）の判断材料は、出典が公開されている情報に限ります。媒体ごとの求人数や平均年収は集計定義が違うため、求人票や公式サイトの最新情報で確認してください。内定や年収アップは保証できません。提示された労働条件は書面で確認し、口頭の話だけを契約内容にしないでください。

Projinや明光キャリアは未経験〜初級向けに、ポートフォリオレビューの観点例を共有してくれる場合があります。ただし最終内容の責任は本人にあります。

• Projin

  未経験・第二新卒向けに、ポートフォリオの見せ方レビューを相談できる場合があります。

• 明光キャリア

  初級エンジニア向け。GitHubと履歴書の整合チェックを面談で支援。

• リクルートエージェント

  IT以外も含めた転職全体の資料整理。GitHub必須でない職種では優先度を下げてよい。

相談先を複数使う場合は、企業名・求人ID・応募経路を一覧にして重複応募を防いでください。転職支援とスカウトでは受けられる支援が異なるため、同じ基準で単純比較せず、目的に合う窓口を選びます。

• リポジトリ数を増やすだけ

  PinnedのREADMEが空では意味がありません。1本完成させてから次へ。

• 社名・Secrets公開

  NDA違反とセキュリティリスク。一般化と環境変数.exampleに置換。

• 履歴書と矛盾

  READMEの期間や役割が履歴書とズレると信頼を損ないます。

1週間で代表リポジトリ1本のREADMEとデモ手順を仕上げる進め方です。新規開発より既存の整理を優先します。

1. 01
   月：棚卸し

   Public/Private整理とSecretsスキャン。

2. 02
   火：README骨子

   代表repoの見出しだけ先に書く。

3. 03
   水〜木：デモ整備

   docker composeやnpm scriptsで再現手順を短く。

4. 04
   金：プロフィール更新

   Bioに役割を1行、Pinnedを確定。URLを履歴書に追記。