エンジニア採用でGitHubプロフィールを見る時に気をつけておきたいこと
エンジニアだけでなく、人事や事業サイドの経営陣の人などからも「採用候補エンジニアのGitHubを見ている」という話を聞く機会が増えた一方で、話を伺っていると「GitHubを採用に活用したい」という想いは感じるものの、GitHub（の、特にプロフィール画面）の見方については懸念を感じる事が少々あったので、自分への警鐘も兼ねて見る際の注意点を纏めておきたい。
※エンジニアではない人に読まれる可能性を考慮している記述も、一部含みます。
Summary
- GitHubプロフィールは初期表示の内容や見栄え(?)だけで判断せず、可能な限り実態を正しく把握する事を意識しながら見るようにしよう
- GitHubプロフィールに表示されている情報が何を意味しているのか？それは自分達の採用活動で重視したい情報なのか？を意識しながら見るようにしよう
- GitHubプロフィールではその人の表に出せない実績までは見えないので、見えている情報だけで採用是非を判断しないようにしよう
- GitHubプロフィールとそこから見える実績は、あくまで「加点材料」としてのみ利用しよう
- GitHubから得られるOSS貢献情報の解釈を誤解しているケースをよく見聞きするが、記事後半に書いた “誤解d. 「◯◯のcontributiorは◯◯に詳しい」とは限らない” のケースが特に多いという体感
1) 思考停止で「プロフィールが何だか凄い」になってしまわない
まず前提として、GitHubのプロフィールは「盛ろうと思えば盛れる」ものである、という事を知っておく必要がある。
例としてプロフィール画面のアクティビティ（通称: 草）を取り上げてみると、この草は自動的に生やす事も可能といえば可能で、実際にそのやり方を紹介している記事なんかもある。これを自分のプロフィール画面の為に使うかどうかは、そのエンジニアの考え方や思想次第ではあるものの、万が一閲覧者を欺く意図があるとするならば、さすがにそれは閲覧者を舐め過ぎている気がする（草をクリックするだけで詳細は簡単に辿れるので）。何より、こうした盛る意図が込められた情報を元に採用されたとしても、採用側もエンジニア自身も後々不幸になるだけな気がしている。
一方で「プロフィールを良く見せようとする」のは、イチエンジニアの自分の意見としてはそれは当然の行為だし権利であるとも思っている。もし採用側がGitHubを（場合によっては 過剰に）参考にして、採用後に当初想定との不一致が起こってしまった、、、という事になってしまっても、その責任は採用した側にある。
そして、GitHubのプロフィール装飾には無関心だが凄いエンジニアも無数にいる、という事も忘れてはいけない。
2) 「採用する側として期待していること」を極力掘り下げておく
例えば、あるツール/ライブラリに強そう に見える エンジニアが応募してきたとする。採用側はそのエンジニアに対して、
- ツール/ライブラリの活用法をよく知っている
- 何ならそのコードの中身についても読んでてよく知っている
- あわよくばcontributorでもある
という期待を抱いたとする。ここで 「3 を満たしている＝1, 2も満たしている」と考えてしまうと期待値がズレてしまうリスクがある。
contributionにも色々な手段があるが、最近興味深かったのがGoが1.17にバージョンアップした事に伴うバージョン番号記載ファイル（設定ファイルやドキュメントである事が多い）の修正pull requestが大量に作成されていた、というケースだ。GitHubを雑に”go 1.17"と検索しただけで似たようなissueやpull requestが結構な数HITするし、中には 早い者勝ち競争に敗北したようなpull request もあったりする。そして真っ先にpull requestを作成してそれが採用・mergeされたユーザーは、そのリポジトリのcontributorの階段を登るか、或いはcontributorの仲間入りを果たす事になる。
こうした経緯でcontributorの仲間入りを果たしたユーザーが、「ツール/ライブラリの活用法をよく知っている」「何ならそのコードの中身についても読んでてよく知っている」と言えるのかどうか？は、プロフィールを閲覧する側として注意を払っておいた方が良い。特にそのユーザーが採用応募者で且つこうしたcontributionをアピールしているようであれば、そのユーザーの他の活動についても補足的に追いかけておく、、ぐらいはやっておいても損は無い。
3) できれば複数のエンジニアから意見を募る
contributionにも色々な手段があると書いたが、この中には「CIやCDの利用サービス変更」や「ライブラリのバージョン修正や差し替え」といったものも含まれる。これらは概ね設定ファイルやドキュメントなど、そのリポジトリの”本体”では無い部分が占める事が多いが、先にも書いた通りこうした”本体外”への修正が取り込まれた場合でも、そのリポジトリのcontributorとして名を連ねる事もあり得る。
これは完全に個人的な意見だが、このような内容の対応は当該リポジトリオーナーの判断でやれば良いものではないか？というのが自分の意見だ。セキュリティ上の脆弱性がある事を教えてくれるような提案ならまだしも、「俺が作ったこれを使え」「お前が使っている◯◯はもうオワコンだから、これを使え」という、ある種の布教活動のような主旨の提案がpull requestで送られてくると、訪問販売の営業に押し掛けられたかのような、、正直あまり良い気分はしない（繰り返しになるけど、個人の意見です）。
私はこう考えているが、当然これがエンジニア全員の考え方であると言うつもりは無いし、そんなはずも無い。だからこそ「採用活動でGitHubプロフィールを見る」というケースにおいて、その一次情報や詳細情報についてどう解釈するべきか？複数のエンジニアの意見を募っておいた方が、解釈の偏りを避けるという意味でも良いと思っている。
意見を募るタイミングはその組織の採用のやり方によりけりな部分もあるが、例えば1stオファー/コンタクトにはエンジニアが関わらない・且つ非エンジニアな採用担当者がオファーの決め手の1つとしてGitHubプロフィールの情報を参考にしている、というようなケースでは、その1stコンタクトのタイミングからエンジニアの協力を仰ぎ、GitHubのプロフィールについての解釈を咀嚼してからオファーを出す、という動き方にしても良い気がする。
GitHubプロフィールについて過去に遭遇した誤解の実例
結論やこの記事で言いたかった事は先に書いた通りだが、これ以降では、今回の記事を書くキッカケにもなった私が遭遇してきた「GitHubプロフィールの見え方に関する種々の誤解群」と、GitHubプロフィールから見えてくる情報を補完する為に簡易的に出来る事について書いてみる。
誤解a. プロフィール画面のスター（☆）は その人が“付けた数” で “付けられた数” ではない
GitHubプロフィール画面の左部に “☆671” のように表示されるスター数が「その人が他者から得られた評価指標」と誤解されているケースがあった。そうではなく、これは 公開されているリポジトリに対してそのユーザーが☆を”付与した数” である（自分自身で公開したリポジトリにスターを付ける事も可能である）。公式ドキュメントには、
- 「興味のあるプロジェクトを追跡し、ニュースフィードで関連コンテンツを見つけることができます」
- 「リポジトリに Star を付けるということは、リポジトリメンテナに対してその作業についての感謝を示すことでもあります」
と書かれている。
エンジニアを生業としている ＆ GitHubを日常的に使っている自分にとってはこの誤解は少々驚きだったのだが、非エンジニア目線で現状のGitHubの画面を見ると、少なからずこういう誤解も起こり得るUIなのかも知れない。この誤解によって例えば「公開されているオープンソースプロジェクトに頻繁かつ大量にスターを付けている人」が過剰に評価されていた可能性も無くは無い。
誤解b. “Repositories” 欄の内容は、必ずしもその人自身の成果とは限らない
プロフィールページには “Repositories” というリポジトリの一覧が表示される欄がある。これらが全てこのユーザー自身の成果である と誤解をされているケースに遭遇したのだが、この一覧は本家からforkしたものも表示されるのがデフォルト仕様 となっている。
※ 以下は私のrepositories画面。デフォルト表示では、forkしたリポジトリが含まれて一覧表示される
もし「その人自身が作成した / その人自身がオーナーであるリポジトリ」だけを確認したい のであれば、検索欄にある Type というプルダウンで “Source” を選択すればフィルタ表示してくれる。仮にこの状態で表示されているリポジトリに “☆ 10” のような表示があれば、それは「その人自身がオーナーとして作成・管理しているリポジトリが他のユーザーから10個のスターを獲得した」という事を意味する。ちなみにスターは自分のリポジトリに対しても（他人のリポジトリと同様に）1つ付与する事が出来る。
※ Type = Source でフィルタしてみると、総リポジトリ数42に対して “31 results” と数が減っている事が分かる
そしてType=Sourceを選択していない状態で表示されていた forkリポジトリ については、
- forkした “だけ” のもの
- forkした上で自身でも開発を行い、本家側にその内容が取り込まれた（いわゆるcontribute（貢献）した）もの
の2種類が、この画面上では特に見分けが付かずに混在表示される。おそらく採用担当者目線でこの画面を見た際には後者の「contributeした実績」を確認したいのではないか？と思われるが、一見しただけではその見分けが付かないので閲覧時は注意が必要である。
誤解c. “Overview”欄の“Pinned”は、必ずしもその人自身の成果とは限らない
プロフィール画面に遷移直後は Overview というタブが初期表示される。このタブには、自分のプロフィール画面が初期表示された際に目立つようにpin止め表示したいリポジトリをユーザー自身が選択出来る、という機能がある。これが設定されたリポジトリは Pinned という欄に固定表示されるようになる。自身の”代表作品”としてアピールしたいリポジトリや、過去の貢献実績をアピールしたい（他ユーザー所有の）リポジトリをpin止めしておく、という使い方がよく見られる。
このpin止めの仕様について、公式ドキュメントで「フォークへのコミットはコントリビューションとして扱われないので、所有していないフォークをピン止めすることはできません」という記述があるのだが、この説明が意味するところを実際に動かしてみて例示してみる。まず私のアカウントには aws-sam-cli と aws-sdk-go がforkしてあり、pin止め画面にはこれらが下記のように表示される（例示の為、一覧表示時に aws という文字列でフィルタしている）
aws-sam-cliについてはfork元である aws ユーザーのリポジトリが “ユーザー名/リポジトリ名” 形式で表示されている一方で、aws-sdk-goにはそれが無い。これは aws-sdk-go は単にforkした “だけ” で、fork元=本家に対してまだ何の貢献もしていないから である。逆にaws-sam-cliの方は、過去に私が何らかの貢献をした実績がある為、本家側である “aws/aws-sam-cli” も表示されている。
まとめると、
- 自身がオーナーのリポジトリ または forkしたリポジトリ は、”ユーザー名/” という接頭辞抜きでリポジトリ名が表示される
- 他ユーザーがオーナーのリポジトリ は ”ユーザー名/” という接頭辞付きでリポジトリ名が表示され、且つ貢献実績がある場合のみpin止め可
という事になる。
私ののプロフィールで先述の2リポジトリを実際にpin止めしてみると下記のように表示される。
一応の補足として、aws-sam-cli側に表示されているスター数は”aws/aws-sam-cli” というリポジトリに集まったスターの数であり、私の貢献実績を評価しているものではない。
逆に、自身がオーナーのリポジトリ または forkしたリポジトリ（”ユーザー名/” という接頭辞が無い方）側にスターがある場合も同様にリポジトリに集まったスターを意味しているが、このケースはそのユーザー自身への評価であるとも言える。※ あるリポジトリをforkし → fork元が開発を止めたが → forkしたユーザーは開発を継続しており → そのforkリポジトリにスターが付いている、といったケースもある。
ちなみに気付かれるかも知れないが、このpin表示からだけでは、表示されているリポジトリに対してこのユーザーがどういう貢献を行ったのか？までは分からない。公式ドキュメントにコントリビューションとしてカウントされる条件（＝リポジトリのpin止めが可能になる条件）の説明があるが、pin止めからは「条件のいずれかを満たしているのだろうな」という事しか分からない。
誤解d. 「◯◯のcontributiorは◯◯に詳しい」とは限らない
誤解cで紹介したpin止め機能は、使う側の意図としては概ね、
- アピールしたい自作リポジトリ
- アピールしたい著名ライブラリへのcontribution
の2つのいずれかに分類される。
で、第三者目線でこのpinを見た時、それがこのユーザーの貢献内容を正確に表しているのだろうか？という疑問が湧くのだが、特に後者のcontributionについては「◯◯というリポジトリのcontributorに名を連ねている人は、◯◯に詳しい人」と思われがちだが、必ずしもそうとも言い切れないケースもある ので見る際には注意しておいた方が良い。
普段からGitHubをよく使っているエンジニアなら知っている事だが、contributiorの称号はそのリポジトリの主機能部分以外への貢献でも付与されるケースもある。例えばドキュメントの修正（typo修正だったり、英単語の使い方といった細かい指摘も含む）や、各種設定ファイルの修正、ライブラリのバージョンアップ等々、間接的な内容でもcontributorとして名を連ねる事は可能だ。
“contribution” の実態把握（簡易版）
ある程度網羅性がありつつ、且つ簡潔にcontribution内容を把握する為の1つの方法としてはgithubの検索機能がある。画面から実施したい場合 https://github.com/search/advanced に遷移すると対象リポジトリやユーザーを指定しつつ複合条件で検索が可能なのだが、「あるユーザーのcontribution内容を知りたい」という事に特化するなら、以下に挙げるURLを直接指定・遷移する事で（簡易的にではあるが）知る事が出来る。
https://github.com/search?&q=author:${USER} repo:${REPOS}このURLでは、
${USER}で指定したユーザーが、${REPOS}で指定したリポジトリで作成したissueとpull request
を確認する事ができる。
例としてユーザー＝私、リポジトリ＝aws-sam-cliの場合は https://github.com/search?&q=author:goldeneggg repo:aws/aws-sam-cli というURLになる。以下がその実行例だが、このURLで遷移直後の初期表示ではCommitsというサイドメニューが選択された状態になっており、この状態で、
指定したユーザーがpull requestを作成して且つmergeされた内容
を把握する事が出来る
※このヘルプ に記載の通り、Commitsは「リポジトリのデフォルトブランチだけが検索され」る。つまり、リポジトリがデフォルトと設定しているブランチに（pull requestがmergeされて）取り込まれたcommitだけが表示される。
Issues というサイドメニューにも 6 という数字が表示されているが、これは 指定ユーザーが起票したissueとpull requestの合計数が6個ある事を意味しており、内容を確認したければサイドメニューのIssuesを選択・遷移すれば良い。一覧の左側にアイコンが表示されているが、
- レ点を◯で囲ったようなアイコン = Issue（赤色のものはclose済）
- 矢印のようなアイコン = Pull Request（赤色のものはclose済、紫色のものはmerge済）
を意味している。
※これ以上のより細かい検索を行おうとすると、諸々の制約があり条件を全て満たせない可能性もあるので（詳細はヘルプを参照）、そうした場合はGitHub APIを駆使する等のより手の込んだ仕組みが必要になってくる。ちなみに私は「あるユーザーが作成した、特定の拡張子のファイルを{含んでいる,含んでいない}pull request」という条件指定での情報収集にAPIを活用している。
