+++
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は履歴書ではなく、ショーウィンドウだ。よく見えるように飾れる人と、飾る暇もなく本物を作り続けている人が、同じ尺度で並べられている。何が見えて、何が見えないか。ここを取り違えると採用は静かに事故る。

---

## 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生成コードの問題

いまやGitHub上のコードにAIの出力が混じるのは当たり前になった。評価で問題になるのは、AIを使ったことではなく、**候補者自身が自分の出力を理解せずに提出しているケース**だ。

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

AIを相棒にしてコードを書くこと自体は、むしろこれからの実務そのものだ。問われるのは、相棒の出した案を読んで、なぜ採るのか・どこを直すのかを自分の言葉で言えるか。「相棒の出力をそのまま貼り付けて、自分では読んでいない」スタンスこそが、業務でも同じ事故を起こす。見るべきは「AIを使ったか」ではなく「AIと組んで、自分で舵を握れているか」。

---

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

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

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

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

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

---

## 月曜からできること

評価制度を作り変える前に、次の面接1回から変えられる。

1. 候補者のGitHubを開いたら、まずスター数の列を心の中で消す。見るのは「一番ちゃんと作り込まれたリポジトリ1つ」だけ。それを15分、コードとコミットログを声に出して読む。
2. 面接の前半30分を「コードレビュー課題」に充てる。50〜100行の、わざとバグと設計のにおいを仕込んだコードを渡し、「気になるところを上から順に話して」と頼む。書く力でなく読む力が、ここで丸見えになる。
3. 最後に1問だけ聞く。「これまでで一番、設計に悩んだのはどの場面か」。GitHubに一行も残っていない実務の重さが、この答えに出る。

この3つは制度変更も予算もいらない。今週の面接から回せる。

## まとめ

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

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

そして最も大事なこと: 「GitHubに何もない」ことは欠点ではない。業務で本物のシステムを作り続けているエンジニアほど、GitHubには何も上がっていないことが多い。ショーウィンドウが空なのは、店じまいしているからではなく、奥の厨房がフル稼働しているからだ。

---

*エンジニア採用について具体的に相談したい場合は [X（@awata_atsume）](https://x.com/awata_atsume) に。HR顧問として相談に乗っている。*

---

## 関連記事

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