+++
title = "エンジニア採用でGitHubやポートフォリオを見る時、実際に何を見るか"
date = 2026-06-08
description = "AIスタートアップのエンジニア採用で、GitHubやコード提出物を使った評価で実際に見ているポイント"
[taxonomies]
tags = ["HR×AI", "エンジニア採用", "GitHub", "技術評価", "採用面接"]
[extra]
public = true
belief_version = 1
ai_written = true
one_true_sentence = "GitHubのスター数とフォロワー数は、エンジニアの採用評価として最も意味のない指標だ。"

[[extra.faqs]]
question = "エンジニア採用でGitHubのどこを見れば技術力が分かりますか？"
answer = "スター数やコミット数より、コミットメッセージの質を見てください。「fix bug」でなく「なぜそのコードを書いたか」を説明しているかどうかが、チームでの説明責任の質に直結します。1つのリポジトリを深く読み、変数名・エラーハンドリング・テストの有無で判断するのが効果的です。"

[[extra.faqs]]
question = "GitHubに何もない候補者は評価を下げるべきですか？"
answer = "下げるべきではありません。業務で本物のシステムを作り続けているエンジニアほど、業務コードはPrivateで個人の時間もないため、GitHubには何も上げていないケースが多いです。GitHubの活動量でスクリーニングすると、「実務-native」なエンジニアを落とすリスクがあります。"

[[extra.faqs]]
question = "AIコードアシスタントを使った痕跡はどう見抜けばよいですか？"
answer = "コードのスタイルが部分的に不自然に変わっている、コメントが多すぎる、テストコードが存在しないという点が確認のヒントです。AIを使うこと自体は問題ではなく、AIが出したコードを理解せず貼り付けているかどうかが問題です。面接でコードの詳細を聞いて、説明できるかを確認してください。"

[[extra.faqs]]
question = "ポートフォリオ課題を出す場合、何を見るべきですか？"
answer = "コードの量より意図を重視してください。「なぜこのアーキテクチャを選んだか」「時間の制約の中でどこを優先したか」「次に時間があれば何を改善するか」を言語化できるかを確認します。エラーハンドリングとエッジケースへの対応も、本番環境での動作品質を判断する重要な指標です。"

+++

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件読む。それだけで「このエンジニアと仕事をするとどういうコミュニケーションになるか」のヒントが分かる。

---

## 関連記事

- [AIエンジニアを採用しても活かせない組織のパターン](/n/ai-engineer-hired-but-underused/) — 採用後に活躍しない原因を採用プロセスの視点から分析
- [AIスタートアップで非エンジニア職を採用する方法](/n/ai-startup-nontechnical-roles-hiring/) — エンジニア以外のポジション採用に特有の課題と対策
- [AI採用でカルチャーフィットを評価できない理由](/n/ai-hiring-culture-fit-limits/) — カルチャーフィット評価の限界とより実用的な代替指標