エンジニアの転職活動で「GitHubを整備しておけ」とよく言われる。だが「整備する」の中身が曖昧なまま、リポジトリを増やしたりコントリビューショングラフを緑にしようとしている人は多い。
重要なのは「採用担当が何を、どの順番で見ているか」を理解した上で整備することだ。
採用担当がGitHubを確認する時間は、1人あたり平均3〜7分程度と言われている。この短時間で彼らが判断しているのは「この人は今も技術に向き合っているか」「書いたコードは読める品質か」「プロフィールからスキルセットをすぐに把握できるか」の3点だ。
この記事でわかること:
- 採用担当がGitHubで実際に確認するポイント
- 転職に強いGitHubプロフィールの作り方
- リポジトリのREADMEを採用担当に刺さる形で書く方法
- コントリビューショングラフの現実的な整備方針
- OSSコントリビューションを転職でどう使うか
採用担当がGitHubを確認する3つの理由
採用担当がGitHubを見るのは「技術力の証明書」として使えるからだ。
理由1: 職務経歴書の技術スタックが本物かを確認する
職務経歴書に「Go・AWS・Docker経験あり」と書いてあっても、GitHubを見ると何年もアクティビティがない。このような矛盾が実際に起きている。
GitHubは「実際に手を動かして書いたコードの履歴」なので、職務経歴書の裏付けとして機能する。
理由2: コードの品質・思考の癖を見る
正式なコードレビューの場では見えない「本人のコーディングスタイル」がGitHubでは露わになる。
採用担当（または技術面接担当）が見ているポイント:
- コミットメッセージが意味を持っているか（「fix」だけのコミットが続いていないか）
- 関数・変数名の命名が読みやすいか
- コードの構造が整理されているか
- テストコードが存在するか
理由3: 学習への継続性を確認する
転職市場でエンジニアに最も求めている資質の一つが「継続的に学習できること」だ。GitHubのコントリビューショングラフはその可視化として機能する。
直近3ヶ月が白紙のエンジニアに対して、採用担当は「今は技術を触っていないのか？」という疑問を持つ。これが書類選考の段階で影響することがある。
転職前に整備すべきGitHubプロフィールの5要素
要素1: プロフィールREADME（最優先で整備）
GitHubのトップページに表示されるプロフィールREADMEは、採用担当が最初に目にするものだ。
整備すべき内容:
# Hi, I'm [名前]
## About Me
- バックエンドエンジニア 経験5年
- Javaメイン → 最近Go・AWSに注力
## Tech Stack
**言語:** Java, Go, Python
**フレームワーク:** Spring Boot, Gin
**クラウド:** AWS (EC2, RDS, Lambda, ECS)
**DB:** PostgreSQL, Redis
**その他:** Docker, Kubernetes, GitHub Actions
## Featured Projects
- [ECサイトAPI](リンク) — Go + PostgreSQL + ECS
- [個人開発アプリ名](リンク) — 概要一行
## 現在学習中
- Rust
- Terraform
ポイント:
- 経験年数・主な使用言語を最初に書く
- 技術スタックはカテゴリ別に整理する
- 「現在学習中」は学習継続性を示す効果がある
- 代表的なプロジェクトへのリンクを含める
要素2: ピン留めリポジトリの選定
GitHubプロフィールには最大6つのリポジトリをピン留めできる。ここには代表作のみを表示する。
ピン留めするリポジトリの基準:
- 転職先で使いたい技術を使っているもの
- 完成していて、動作する（デプロイ済みであればベスト）
- READMEが充実している
- コミット履歴が継続的に積み上がっている
ピン留めを避けるもの:
- 「test」「temp」「sample」などの名前のリポジトリ
- コミットが1回しかないもの
- チュートリアルをそのままコピーしただけのもの
- README.mdが空のもの
要素3: 各リポジトリのREADMEの充実
ピン留めしたリポジトリのREADMEは、以下の構成で書く。
# プロジェクト名
## 概要
何のために作ったか（1〜2行）
## 技術スタック
- 言語: Go 1.22
- フレームワーク: Gin
- DB: PostgreSQL 16
- インフラ: AWS (ECS Fargate + RDS + ALB)
- その他: Docker, GitHub Actions
## アーキテクチャ
[図解または説明]
## 開発の背景
なぜこの技術を選んだか / 工夫した点
## セットアップ
$ docker-compose up
$ go run main.go
## デモ
[デモURL or スクリーンショット]
採用担当が最も重視するのは「なぜこの技術を選んだか」の説明だ。フレームワークやDBの選定理由を書くだけで、「技術選定ができるエンジニア」として評価が上がる。
要素4: コントリビューショングラフの維持
採用担当が見るのは直近3〜6ヶ月のコントリビューションだ。過去2〜3年前の頑張りより、直近の継続性が重要視される。
現実的な維持方法:
- 毎日コミットする必要はない。週3〜4回程度で十分
- 業務のコードがPrivateリポジトリであっても、設定で表示可能（Settings > Contributions から「Private contributions」をオン）
- 個人開発・技術ブログのコード管理・OSSコントリビューションをGitHubで行う
- 学習記録（Zenn/QiitaのMarkdownをGitHubで管理）も立派なコントリビューション
要素5: スター・フォロワー数よりコミット品質
GitHubのスター数やフォロワー数は転職では直接的な影響が小さい。採用担当が見ているのはコードの品質とコミット履歴だ。
採用担当が実際に行う確認:
- コミット数と最終コミット日（最近も触っているか）
- コミットメッセージの質（何をしたかが伝わるか）
- 関数名・変数名の命名（読みやすいか）
- README の完成度
- テストファイルの有無
経験・目的別のGitHub活用戦略
SES・受託開発から自社開発へ転職したい場合
SESや受託開発のエンジニアは「業務コードを見せられない」制約がある。この場合は個人開発で代替することが唯一の解決策だ。
個人開発で作るべきもの:
- CRUD機能 + 認証 + デプロイ済みのWebアプリ
- 使用技術は転職先で使われているモダンスタック
- できればDockerで環境構築できるようにする
自社開発企業が「SESの実務コードは見られないのは理解している。個人開発はありますか？」と聞いてくるのが典型的なパターンだ。個人開発がなければ「技術力を確認できない」と判断される。
エンジニア転職ポートフォリオ完全ガイド
採用担当が本当に見ているポートフォリオの評価ポイントと、通過率を上げる具体的な作り方
5年以上の実務経験者の場合
経験豊富なエンジニアがGitHubでアピールすべき観点は、ジュニアとは異なる。
シニアエンジニアがGitHubで見せるべき要素:
- アーキテクチャの設計判断（READMEでの技術選定理由の説明）
- 複数のリポジトリが有機的に連携しているプロジェクト
- テストカバレッジ・CI/CDの実装
- OSSコントリビューションの記録
シニアポジションの採用では「高い技術力と設計能力」の証明が求められるため、「作った量」より「どう作ったか」が重視される。
OSSへの参加を転職に活かす
OSSコントリビューションは「本物の実力証明」として転職市場で高く評価される。
OSSコントリビューションの始め方（ハードルの低い順）:
- ドキュメント・翻訳の修正: 誤字・分かりにくい説明の改善。コードスキル不要
- バグ報告（Issue作成）: 再現手順を丁寧に書くだけで貢献になる
- Good First Issueの解決: 初心者向けラベルのついたIssueを選ぶ
- 機能追加・バグ修正: 本格的なPR。マージされれば最強のアピール材料
GitHubの「Contributions」タブには、PRのマージ・Issue作成・コードレビューコメントが記録される。すべてが採用担当に見える「実績」になる。
GitHubプロフィールの整備チェックリスト
転職活動を始める前に、以下を確認しよう。
必須（1週間以内に完了）:
- プロフィールREADMEの作成・更新（スキルセット・代表プロジェクト）
- メインの技術を使ったリポジトリをピン留め（最低2〜3個）
- ピン留めリポジトリのREADMEを充実させる
- コントリビューション設定でPrivateリポジトリも表示
- プロフィール画像の設定（アイコンでもOK、空欄はNG）
推奨（転職活動開始1ヶ月前まで）:
- デプロイ済みの個人開発アプリを最低1つ公開
- テストコードを含むリポジトリを用意
- コントリビューションを週3〜4回のペースに維持
- SNS（X/Twitter）でアウトプットとGitHubリンクを繋げる
理想（3ヶ月前から取り組む）:
- OSSへのコントリビューション実績（1件以上）
- 技術ブログとGitHubを連携させる
- 複数の技術スタックにまたがる一貫したプロジェクトを公開
GitHubと連携させると効果的なアクション
技術ブログとの連携
技術ブログ（Zenn・Qiita）の記事に「GitHubのコードリンク」を張ることで、ブログ読者がGitHubに来る流れができる。採用担当が技術ブログを経由してGitHubを確認するルートは意外と多い。
エンジニアが技術ブログを書くべき4つの理由
技術ブログがスキル定着・転職武器・副収入に繋がる仕組みを解説
LinkedInとの連携
外資系IT企業や外資系コンサルを狙う場合、LinkedInのプロフィールにGitHubリンクを貼ることが標準的だ。外資系の採用プロセスでは、GitHubを見た上でスカウトが来ることも珍しくない。
転職エージェントへのGitHubリンク提供
転職エージェントに登録する際は、必ずGitHubのURLを提供しよう。エージェントがGitHubを確認した上で「この候補者はGoのコードが書けます」と企業側に紹介してくれると、選考が通りやすくなる。
企業別・採用担当が評価するポイントの違い
転職先の企業タイプによって、GitHubのどこを重視するかが変わる。
外資系IT企業（Google・Amazon・Microsoft等）
最も厳しくGitHubを見る。
重視されるポイント:
- アルゴリズム・データ構造を扱ったコードの質
- OSSへの貢献実績（マージされたPRが強い）
- 技術的な議論のコメント・レビュー履歴
メガベンチャー（Mercari・LINE・SmartHR等）
コードの品質と最新技術への取り組みを見る。
重視されるポイント:
- テストコードの有無と品質
- モダンな技術スタックの使用
- CI/CDの実装（GitHub Actionsなど）
- コントリビューションの継続性
自社開発スタートアップ
少人数でのコードレビューなので、コードスタイルと推進力を見る。
重視されるポイント:
- コードの読みやすさ（命名・構造）
- 完成してデプロイされているプロダクト
- 週次程度のコントリビューションの継続
大手SIer・SES企業
GitHubを重視しない傾向があるが、あると差がつく。
重視されるポイント:
- 業務以外での学習意欲（何かをやっていること自体が評価される）
- 資格・経歴書との整合性確認
スキルアップしながらGitHubを整備する方法
GitHubの整備は「見せるためだけ」の作業ではなく、スキルアップと連動させることで効率が上がる。
個人開発テーマの選び方
転職後に使う技術を使った個人開発を行うと、GitHubの整備とスキルアップが同時に進む。
例えば:
- バックエンドエンジニア志望→ Go + PostgreSQL + ECSのREST API
- フルスタック志望→ Next.js + TypeScript + Supabase
- インフラエンジニア志望→ Terraform + AWS + Kubernetes
学習コストを下げる方法
GitHubの整備と並行してスキルを習得する場合、独学だと方向性が定まりにくいこともある。プログラミングスクールを活用すれば、転職に直結する技術を体系的に習得しながらポートフォリオを作れる。
Winスクールは個人レッスン制で、自分のペースと目標（転職先の技術スタック）に合わせたカリキュラムが組める。
エンジニア転職の準備完全ガイド
GitHubだけでなく職務経歴書・面接対策も含めた転職準備の全体像を確認する
まとめ
GitHubはエンジニアの転職において「あれば有利」から「なければ不利」に変わりつつある。特に自社開発企業や外資系を狙う場合は、GitHubの整備がほぼ必須の前提になっている。
整備のポイントおさらい:
- プロフィールREADME: スキルセット・代表プロジェクトを30秒で把握できる形で書く
- ピン留めリポジトリ: 転職先で使う技術を使った完成度の高い作品を選ぶ
- README充実: 技術選定の理由を書くと「設計思考があるエンジニア」として評価される
- コントリビューション: 週3〜4回の継続が、学習意欲の可視化になる
- OSSコントリビューション: 小さくても実績があると、面接で差がつく
転職活動を始める3ヶ月前にGitHubの整備を開始し、並行してスキルアップと個人開発を進めていくのが最も効率的な準備だ。