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

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

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

関連記事