+++
title = "エンジニア採用で GitHub ポートフォリオをどう評価するか — 2026年版"
date = 2026-06-08
description = "技術力の指標として GitHub を見るとき、何を見てはいけないか。星の数でなく何で判断するか"
[taxonomies]
tags = ["エンジニア採用", "GitHub", "技術評価", "採用実務", "HR×AI"]
[extra]
public = true
belief_version = 1
ai_written = true
one_true_sentence = "GitHub の星の数はエンジニアの実力ではなく、マーケティングの上手さを測っている。"

[[extra.faqs]]
question = "GitHubのスター数が多い候補者は技術力が高いと判断していいですか？"
answer = "判断の根拠にしないほうが安全です。スターが多いリポジトリの作者に共通するのは「タイミングよく、PR上手に、需要のあるものを公開した」ことです。技術力より露出の上手さを測っている場合が多く、逆に業務で本物のシステムを作るエンジニアほどGitHubに何も上げていないことが多いです。"

[[extra.faqs]]
question = "GitHub評価の限界を補うために採用で何を組み合わせればいいですか？"
answer = "コードレビュー課題（実際の業務に近いコードを渡してレビューしてもらう）とシステム設計の会話を組み合わせると効果的です。書く能力より読む能力が測れるコードレビュー課題と、「これまでで一番複雑な技術課題は何だったか」という会話でGitHubには出てこない実務経験を確認できます。"

[[extra.faqs]]
question = "OSSへのコントリビュートがある候補者はどう評価すればいいですか？"
answer = "PRを出したこと自体より、レビューコメントへの対応を見てください。指摘された点を理解して修正しているか、修正の理由を説明しているか、却下されたPRで議論をどう展開したかが重要な評価ポイントです。Issue・PRコメントの書き方は業務でのコミュニケーションスタイルを予測する手がかりになります。"

[[extra.faqs]]
question = "AI生成コードを面接で見抜く方法はありますか？"
answer = "コードのスタイルが一貫していない（部分的に異様に丁寧で部分的に雑）、コメントが説明的すぎる（日本語が異様に丁寧）、面接でコードの詳細を聞くと答えられない部分があるという3点が判別のヒントです。AIを使ってコードを書くこと自体は問題でなく、自分でレビューしていない出力をそのまま提出するスタンスが業務上の問題につながります。"

+++

「GitHubを見れば技術力がわかる」という採用担当者の言葉を、エンジニアから何度か聞いた。半分は正しくて、半分は間違っている。何が見えて、何が見えないかを整理する。

---

## GitHub で「見えること」と「見えないこと」

### 見えること

- **コードを書く習慣があるか** — コミット頻度から、継続的にコードを書いている人かどうかは分かる
- **どんな技術に興味があるか** — スターを付けたリポジトリ、コントリビュートしているプロジェクト
- **プロジェクトを完成させられるか** — ある程度の規模のリポジトリに README があり、ドキュメントが整備されているか
- **他者と協働できるか** — OSSへのIssue、PRのやり取りの質

### 見えないこと（重要）

- **業務コードの品質** — 多くのエンジニアは業務コードをPublicにしない。GitHubで見えるのは個人プロジェクトのみ
- **チームへの貢献** — コードレビューの質、設計議論への関与、メンタリングはGitHubには出ない
- **問題解決の過程** — 完成したコードは見えるが、どう考えてその実装に至ったかは見えない
- **実際のシステム設計能力** — 個人プロジェクトと、数百万ユーザーを捌くシステムの設計は別物

---

## 「星の数」で判断してはいけない理由

GitHubのスター数は技術力の指標ではない。

スターが多いリポジトリを作る人に共通しているのは、**「タイミングよく、PR上手に、需要のあるものを公開した」**こと。技術力が優れているというより、コミュニティへの露出が上手い場合が多い。

実際に見られるパターン:
- 便利なCLIツールを1つ作って5000スター → 他のコードは書いていない
- SNSで人気の「学習ロードマップ」リポジトリ → 本人の実装コードはほぼない
- Qiitaの記事と連動したサンプルリポジトリ → サンプルコード専業

逆に、業務で本物のシステムを作っているエンジニアは、GitHubにほとんど何も上げていないことが多い（業務コードはPrivate、個人の時間はない）。

スター数で採用判断すると、「GitHub-native」なエンジニアを選び、「実務-native」なエンジニアを落とすことになる。

---

## では何を見るか

### 1. コードの「書き方」の一貫性

量より質。1つのリポジトリを深く読む。

チェックポイント:
- 変数名・関数名がどれだけ意図を伝えているか（`data` でなく `userAuthToken`）
- コミットメッセージが変更の「なぜ」を説明しているか
- エラーハンドリングが実用的か（`try {} catch {}` で握りつぶしていないか）
- テストがあるか。テストがない場合、それが意図的な選択か怠慢か

### 2. 「途中のもの」より「完成したもの」

半分だけ実装されたリポジトリが10個あるより、1つ完成しているリポジトリの方が情報量がある。

完成の定義:
- READMEに「動かし方」が書いてある
- 実際に動く（デプロイされている、または手元で動かせる）
- バージョン 0.x.x でも、設計の意図が読み取れる

### 3. OSSへのコントリビュートがある場合 — レビュー対応を見る

PRを1つ開いたことよりも、**レビューコメントへの対応**の方が採用判断として有益。

見るポイント:
- レビューで指摘された点を理解して修正しているか
- 修正の理由を説明しているか
- 却下されたPRで議論をどう展開したか

### 4. 「語り口」を見る

Issue、PRコメント、Discussionでの書き方は、業務でのコミュニケーションスタイルと近い。

- 問題を正確に記述できているか
- 再現手順を整理できているか
- 相手の意図を汲んでいるか

---

## AI生成コードの問題

2025年以降、GitHub上のコードにAI生成が混入するようになった。採用評価で問題になるのは、**候補者自身がAIの出力を理解せずに提出しているケース**だ。

判別のヒント:
- コードのスタイルが一貫していない（部分的に異様に丁寧、部分的に雑）
- コメントが説明的すぎる（AIが出力したコメントは日本語が異様に丁寧）
- 面接でコードの詳細について聞いたとき、答えられない部分がある

AIを使ってコードを書くこと自体は問題ではない。ただし「自分でレビューしていない出力をそのまま提出する」は、業務でも同じ問題を起こす。

---

## GitHub評価の限界を補う方法

GitHub単体での評価に限界があるため、組み合わせて使う。

**コードレビュー課題**:
実際の業務に近いコードを渡して、レビューしてもらう。書く能力より読む能力が測れる。「改善するとしたらどこか」を口頭で話してもらうと、思考過程が分かる。

**システム設計の会話**:
「このシステムをどう設計するか」を会話形式で。ホワイトボードや紙でもいい。過去に設計した経験を話してもらう形が自然。

**過去のプロジェクトを語らせる**:
「これまでで一番複雑な技術課題は何だったか」「そのときどう解決したか」。GitHubには出てこない、実際の経験が聞ける。

---

## まとめ

GitHubは参考情報として使うには十分だが、主要な評価指標にするには不適切だ。

採用でGitHubを見るとき:
- スター数・フォロワー数は無視する
- コードの質と一貫性を1つのリポジトリで深く見る
- OSSコントリビュートがあればレビュー対応の質を見る
- GitHub以外の評価手段（コードレビュー課題、設計会話）を組み合わせる

そして最も大事なこと: 「GitHubに何もない」ことは欠点ではない。業務で本物のシステムを作り続けているエンジニアほど、GitHubには何も上がっていないことが多い。

---

*エンジニア採用について具体的に相談したい場合は kenny@atsume.io に。HR顧問として相談に乗っている。*

---

## 関連記事

- [AIエンジニアを採用しても活かせない組織のパターン](/n/ai-engineer-hired-but-underused/) — 採用後に活躍しない組織側の問題を具体的に分析
- [AI採用スクリーニングと人間判断の境界線](/n/ai-screening-human-judgment-line/) — どこまでAIに任せてどこを人間が判断するかの線引き方法
- [AI採用でカルチャーフィットを評価できない理由](/n/ai-hiring-culture-fit-limits/) — ツールでは測れないカルチャーフィット評価の現実