OSS採用面接でPR件数を盲信すると起きる落とし穴とマージ率の確認法

採用選考やベンダー選定で候補者・委託先のGitHubプロフィールを見るとき、マージ済みプルリクエスト（PR。コード変更の提案を送り、レビューを経て取り込んでもらう仕組み）の件数を実績の指標にしていないでしょうか。件数だけを見て評価すると、実力を見誤る落とし穴があります。人事評価やベンダー選定にGitHub実績を使っているエンジニアリングマネージャー・PMの方に、確認すべき具体的な観点を整理しました。

海外のあるOSS貢献者は、398件のマージ済みPRのうち29件が自分自身のリポジトリへのものだったと公開し、外部リポジトリへの369件だけを実績として数えたと説明しています。さらに生涯で送ったPRは918件で、マージされたのは398件、つまり半分以下しか採用されていないとも述べています。この数字の内訳こそが、業務でGitHub実績を評価に使う際の重要な手がかりになります。

何が起きるか：件数評価が生む誤判定

多くの現場で「GitHubのPR数が多い人は実力がある」という粗い評価基準が使われがちです。

しかし件数だけを見ると、自分が管理者権限を持つ自分のリポジトリへのPRと、他人が審査した外部リポジトリへのPRが混在したまま集計されてしまいます。

前者は自分でレビューして自分でマージできるため、技術力の証明としては弱いものです。後者は無関係な第三者のメンテナー（リポジトリの管理・審査を担う人）が品質を判断してから通しているため、信頼度がまったく異なります。

この区別をせずに「PR 300件」という数字だけで採用面接や外部委託先の技術力評価を進めると、実質的な貢献が薄い候補者を過大評価してしまう恐れがあります。

なぜ起きるか：Hacktoberfestと自己リポジトリの構造的な混入

原因を段階的に分解すると、まず海外OSSコミュニティには毎年10月に開催されるHacktoberfest（オープンソースへの貢献を促すキャンペーン）という文化があります。

初心者向けリポジトリに1ファイルのスクリプトを送るだけでマージされる例が多く、短期間に件数だけを積み上げやすい構造があります。先述の貢献者も2024年の1年間で306件の外部マージを記録し、そのうち234件は単一のPythonリポジトリへの1ファイル提出でした。

次に、GitHub検索APIの仕様上、author: で検索すると自分が所有するリポジトリへのマージも同じ「merged pull requests」として一覧に含まれます。フィルタをかけない限り、件数の内訳は見えません。

さらに、プロフィールの表示件数やREADMEのバッジは多くの場合「マージ数」を単純表示するだけで、外部リポジトリか自己リポジトリかを区別しません。この3つが重なることで、件数の数字だけが独立して評価者の目に入り、内訳の検証をしないまま採用判断に使われてしまいます。

自分の組織が該当するか確認する方法

評価プロセスにこの落とし穴が潜んでいないか、次の点を確認してください。

採用基準やベンダー選定の評価シートに「GitHub PR数」「マージ数」という項目がそのまま数値だけで存在するか
面接で候補者のプロフィールを見る際、リポジトリの所有者と貢献者が同一かどうかを毎回確認しているか
社内の技術評価ガイドラインにOSS実績の「質」を判定する基準（レビュー内容・リポジトリの利用規模など）が明文化されているか

どれか一つでも当てはまらない場合、件数評価に偏っている可能性があります。

実際にGitHubの検索クエリで内訳を確認する方法は次のとおりです。

# 対象ユーザーの全マージ済みPRを検索（ブラウザで開く）
https://github.com/search?q=is%3Apr+is%3Amerged+author%3Aユーザー名&type=pullrequests

# GitHub CLIでAPIから直接取得する場合
gh api -X GET search/issues -f q="is:pr is:merged author:ユーザー名"

このクエリで返る件数から、対象ユーザー自身が所有するリポジトリ（プロフィールのRepositoriesタブで確認可能）へのマージ件数を差し引けば、外部評価に使える実質的な件数が出ます。

対策の手順

候補者やベンダーのOSS実績を評価に使う場合、次の手順で内訳を検証してください。

1. 上記のGitHub検索クエリで対象ユーザーの全マージ済みPR一覧を取得する
2. 各PRのリポジトリ所有者と、対象ユーザーのGitHubアカウント名を比較する（自己所有リポジトリは除外対象）
3. 除外後の件数を「外部評価済み件数」として記録する
4. 外部リポジトリの種類（利用者数の多いOSSか、個人の学習用リポジトリか）を数件サンプリングして確認する
5. 送信件数に対するマージ件数の比率（マージ率）も併せて見る。極端に高い比率は、難易度の低いリポジトリへの提出に偏っている可能性を示す

この手順を評価テンプレートに組み込めば、面接官やPMごとに評価がぶれるリスクを減らせます。

社内で技術評価の標準化を進めている組織であれば、この検証手順をエンジニア採用のチェックリストやコードレビュー文化の説明資料に転用するのも有効です。

既存の評価シートに「外部リポジトリへのマージ件数」「マージ率」「サンプリング確認済みリポジトリの種類」という3項目を追加するだけで、件数だけの判断から一段階深い検証に移行できます。

まとめ

GitHubのPR件数は、内訳を見ずに信じると評価を誤らせる指標です。

自己リポジトリと外部リポジトリの区別、送信件数に対するマージ率、リポジトリの種類のサンプリング確認、この3点を評価プロセスに組み込むことが現実的な対策になります。

次に候補者やベンダーのGitHubプロフィールを見る機会があれば、まず検索クエリを実行して内訳を自分の目で確かめることから始めてみてください。