GitHubのスター数とフォロワー数は、エンジニアの採用評価として最も意味のない指標だ。

エンジニア採用でGitHubやポートフォリオを見る時、実際に何を見るか

思考版1 AI執筆

AIスタートアップの採用でエンジニアのGitHubを見てほしいと言われることがある。

「このGitHubを見てどう思いますか」という質問に、どう答えるかが難しい。

スター数が多い = 良いエンジニア、ではない。コミット数が多い = 良いエンジニア、でもない。では何を見るのか。

見てはいけないもの

まず「見てはいけない指標」を確認する。

スター数・フォロワー数： 人気度の指標であって技術力の指標ではない。人気OSSを作ったことがあるエンジニアが良いエンジニアかどうかは別の話だ。

コミット数・コントリビューション数： 毎日コミットするツールを使えば増やせる。READMEのタイポ修正を1行ずつコミットしても増える。

使っている言語の種類： 5言語使っていても、どれも表面的な理解の場合がある。

フォークしているリポジトリの数： フォークは「調べた」「気になった」の記録に過ぎない。

実際に見ること

1. コードのコミットメッセージ

コミットメッセージは、そのエンジニアが「なぜそのコードを書いたか」を残す習慣があるかどうかを示す。

「fix bug」「update」「WIP」だけのメッセージが続くリポジトリと、「feat: add retry logic for API timeout - fixes edge case where...」のようなメッセージが続くリポジトリでは、後者の方が良い。

コミットメッセージの質は、チームで仕事をする時の説明責任の質につながる。

2. READMEの書き方

READMEは「このコードが何のために存在するか」の説明書だ。

良いREADMEは、インストール手順だけでなく「なぜこのツールを作ったか」「どういう場面で使うのか」「他のツールとの違いは何か」が書かれている。

これは、仕事で「なぜこの実装を選んだか」を説明できるかどうかと直結する。

3. イシューへの対応

他人のリポジトリへのコントリビューションより、自分のリポジトリのイシュー対応を見る方が参考になる。

バグ報告を受けた時に「再現できません」で終わらせているか、詳細を聞いて調査しているか。機能要望に対してどう対話しているか。これはチームでの仕事スタイルの予告編だ。

4. AIコードアシスタント活用の痕跡

2024年以降の採用では、AIツールをどう使っているかが重要な評価軸になっている。

GitHubのコードで確認できる点：

  • コードの一貫性（AIが生成したコードをそのまま貼り付けると、文体が突然変わることがある）
  • コメントの質（AIが生成したコメントは多すぎることが多い）
  • テストコードの存在（AIに実装させてもテストを書かせないエンジニアと、テストを書かせるエンジニアの差）

AIを使うこと自体は問題ではない。AIが出したコードを理解せずに貼り付けているかどうかが問題だ。

ポートフォリオ課題を出す場合の見方

採用プロセスでコーディング課題を出す場合、GitHubに加えて何を見るか。

コードの量より意図： 「なぜこのアーキテクチャを選んだか」「時間の制約の中でどこを優先したか」「次に時間があれば何を改善するか」を聞く。これが言語化できないエンジニアは、設計の議論ができない。

エラーハンドリングとエッジケース： ハッピーパスだけ動くコードと、エラー時に丁寧に処理するコードでは、プロダクション環境での動作が全然違う。

テストの有無と内容： テストを書かない選択をしたエンジニアがいたら、「なぜ書かなかったか」を聞く。「時間がなかったから」は理由になる。「テストは後でいい」は思想の問題かもしれない。

AI時代に追加された評価軸

2025年以降、AIスタートアップの採用で新しく見るようになった点がある。

プロンプトエンジニアリングの痕跡： LLMを使ったツールを作ったことがあるかどうか。あれば、プロンプトの設計とデバッグの経験がある。

RAGや埋め込みへの理解： LLMを外部データと組み合わせた経験があるかどうか。表面的な「ChatGPTを使った」ではなく、アーキテクチャレベルの理解があるか。

モデルの選択基準： なぜGPT-4ではなくClaudeを選んだか、なぜローカルモデルを選んだか。コストとパフォーマンスのトレードオフを考えて選んでいるか。

今日渡せるもの： 次にエンジニアのGitHubを見る時、スター数を見る前にコミットメッセージを10件読む。それだけで「このエンジニアと仕事をするとどういうコミュニケーションになるか」のヒントが分かる。

関連記事