GitHubポートフォリオの見せ方｜転職で評価されるリポジトリの特徴と整え方
エンジニアの転職活動で「GitHubを見せたほうがいい」という話はよく聞く。ただ、実際にどの程度見られているのか、何をどう整えればいいのかとなると、意外と情報がまとまっていない。職務経歴書は書き方のテンプレートがいくらでもあるのに、GitHubの「見せ方」については手探りで進めている人が多い。
結論から言うと、GitHubは「見る企業」と「ほぼ見ない企業」にはっきり分かれる。ただ、見る企業にとってはかなり重要な判断材料になるし、見ない企業でもリンクが貼ってあれば目を通すことはある。つまり整えておいて損はない。この記事では、転職で評価されるGitHubポートフォリオの作り方と、やりがちな失敗パターンを整理する。
エンジニア転職でGitHubはどの程度見られているか
GitHubをどれくらい重視するかは、企業のカルチャーや採用フローによってまったく違う。Web系のスタートアップや自社開発企業では、書類選考の段階でGitHubのリンクを求められることが多い。特にLAPRASやFindy経由のスカウトでは、GitHubの活動が評価のベースになっているケースもある。こういった企業では、GitHubの内容が一次面接の話題になることも珍しくない。
一方で、SIerや大手企業の中途採用では、GitHubを必須としていないケースが大半。職務経歴書と面接のやりとりで判断するスタイルが主流で、GitHubの提出は「あれば見ます」くらいの温度感になる。ただし、これは「見ても意味がない」という話ではない。他の候補者と横並びになったとき、GitHubにしっかりしたアウトプットがある人は確実に印象が残る。
採用する側の視点で言うと、GitHubで見ているのは「コードの上手さ」だけではない。むしろ注目されるのは、技術選定の意図、コードの読みやすさへの配慮、ドキュメントの書き方といった「この人と一緒に仕事ができそうか」を判断する材料になる部分。つまりGitHubは技術力の証明というよりも、仕事の仕方を伝えるツールとして機能する。
「見せるGitHub」の整え方
GitHubを転職に活かすなら、まずやるべきはプロフィールページの整備。GitHubにはリポジトリを最大6つピン留めできる機能がある。何もピン留めしていないと、最近pushしたリポジトリやフォークしたリポジトリが自動で表示されてしまう。これだと「何をやっている人なのか」がまったく伝わらない。自分の技術スタックや興味がわかるリポジトリを選んでピン留めしておくだけで、第一印象がかなり変わる。
ピン留めするリポジトリには、必ずREADMEを書く。採用担当やエンジニアがリポジトリを開いて最初に見るのはREADMEだから、ここが空だと「中身を見る気にならない」というのが正直なところ。READMEに書くべき内容はシンプルで、「何を作ったのか」「なぜ作ったのか」「どの技術を使ったのか」「どうやって動かすのか」の4つ。技術的に込み入った判断をした箇所があれば「なぜその選択をしたのか」まで書いてあると、読む側の解像度がぐっと上がる。
コミットメッセージも意外と見られるポイント。「fix」「update」だけが延々と並んでいるコミット履歴は、あまりいい印象を与えない。かといって完璧なコミットメッセージを求められているわけでもなくて、「何を変えたか」が一読でわかる程度の粒度があれば十分。実務でも同じことが求められるわけだから、普段からの習慣として意識しておくと自然と整う。
転職に効くリポジトリの特徴
ピン留めするリポジトリを選ぶとき、「どんなリポジトリが評価されるか」の基準を持っておくと迷わない。
まず評価されやすいのは、実用性のあるもの。自分が実際に困っていた問題を解決するために作ったツールや、業務効率化のために書いたスクリプトは、「課題発見 → 解決」の思考プロセスが見える。「なぜこれを作ったのか」にストーリーがあるリポジトリは、技術力とは別の文脈で評価される。
技術選定の意図が見えるリポジトリも強い。たとえば「Expressではなく Honoを選んだ理由」「ORMを使わずに生SQLで書いた判断」のようなことがREADMEやコミットメッセージから読み取れると、この人は技術を選ぶときにちゃんと考えているな、という印象になる。正解かどうかは問題ではなくて、判断のプロセスが見えること自体に価値がある。
テストが書かれているかどうかも、採用側は地味に見ている。テストが一切ないリポジトリと、基本的なテストケースがカバーされているリポジトリでは、後者のほうが「実務でもテストを書く人だろう」という信頼につながる。フル網羅のテストを書く必要はない。主要な関数やAPIエンドポイントに対するテストが数本あるだけでも印象は変わる。
逆に言うと、リポジトリの数は多ければいいわけではない。ピン留めする6つのうち、しっかり作り込んであるものが2〜3個あれば十分。残りは興味のある技術を試した実験的なリポジトリでも問題ない。大事なのは「この人のメインのアウトプット」がどれかわかること。
やりがちな失敗パターン
GitHubポートフォリオで最もよく見る失敗は、チュートリアルで作ったコードをそのまま置いていること。UdemyやProgateの教材に沿って作ったToDoアプリやブログアプリがピン留めされていると、採用側は「この人のオリジナルの成果物はどこだろう」と探すことになる。チュートリアルで学ぶこと自体は悪くないが、そこから何かひとつでもオリジナルの要素を足すだけで印象は大きく変わる。データベースのスキーマを変えてみる、UIを自分なりに作り直す、機能をひとつ追加する。それだけで「教材をなぞっただけではない」と伝わる。
空のリポジトリや、READMEだけで中身がほぼないリポジトリを放置するのもよくあるパターン。「いつか作ろう」と思って作成したまま手つかずのリポジトリは、ピン留めを外すかアーカイブしておくのがいい。存在しているだけで「途中で投げ出す人」という印象を与えかねない。
もうひとつ、草（コントリビューショングラフ）を生やすことが目的化してしまうケース。毎日コミットしている緑のグラフは一見すると勤勉な印象を与えるが、中身を見たら空コミットや意味のない変更が並んでいたら逆効果になる。採用する側もそのパターンは知っているので、草の濃さよりも個別のリポジトリの質のほうがずっと重視される。数ヶ月に1回しかコミットしていなくても、中身がしっかりしていれば何の問題もない。
GitHub以外のアウトプット手段も組み合わせる
転職におけるアウトプットは、GitHubだけに閉じる必要はない。むしろ複数のチャネルを組み合わせたほうが、自分の技術力や思考プロセスを多角的に伝えられる。
ZennやQiitaへの技術記事の投稿は、コードだけでは伝わりにくい「なぜその技術を選んだのか」「どんな問題にどうアプローチしたのか」を文章で補完できる。技術ブログを書く習慣がある人は、採用側から見ると「言語化能力がある＝ドキュメントやレビューコメントもちゃんと書ける人」という期待につながる。バズる記事を書く必要はなくて、自分が詰まったポイントとその解決策をメモ的に残すだけでも十分なアウトプットになる。
個人開発のアプリやサービスを実際にデプロイして公開するのも効果的。GitHubにコードがあっても、動いているものを見せられるかどうかで説得力がまったく違う。Vercel、Cloudflare Pages、Fly.ioなど、無料枠でデプロイできるサービスはいくらでもある。URLひとつで「これを作りました」と見せられる状態にしておくと、面接での会話が具体的になる。
OSSへのコントリビューションも、できる範囲で取り組む価値がある。ドキュメントの修正やtypoの修正でもいいし、issueに対する小さなパッチでもいい。「他人のコードを読んで理解し、適切に修正できる」というスキルは、実務で毎日求められるもの。OSSコントリビューションの経験があると、その能力があることの裏付けになる。
まとめ
GitHubを転職に活かすために必要なのは、高度な技術力ではなく「見せ方の工夫」と「最低限の整備」。プロフィールのピン留めを設定し、READMEを書き、コミットメッセージに気を配る。それだけで他の候補者との差別化になる。リポジトリは数より質が大事で、実用性があり、技術選定の意図が見え、テストが書かれているものが評価されやすい。
チュートリアルのコピペ、空リポジトリの放置、草を生やすだけの運用はむしろマイナスになりうるので、心当たりがあれば整理しておきたい。GitHub以外にも、技術記事の投稿、個人開発のデプロイ、OSSコントリビューションなど、アウトプットの手段は複数ある。自分のスタイルに合ったものを組み合わせて、転職活動で使える「見せるアウトプット」を準備しておくのが、結果的にいちばん効率がいい。