GitHub の星の数はエンジニアの実力ではなく、マーケティングの上手さを測っている。

エンジニア採用で GitHub ポートフォリオをどう評価するか — 2026年版

思考版1 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顧問として相談に乗っている。

関連記事