TL;DR（この記事の要約）

• GitHub・ポートフォリオは、レジュメだけでは見えない実装力・設計思想・コミュニケーション力を事前に把握できる選考材料です。

• 評価すべきは「草（コントリビューション量）」ではなく、READMEの質・コミット履歴・コードの設計・Issue/PRの使い方・技術選定の意図の5軸です。

• 非エンジニアの人事でも、READMEの充実度やコミットメッセージの丁寧さなど専門知識なしで判断できる項目で一次スクリーニングができます。

• ポートフォリオ提出は任意にすべきで、必須化すると在職中のシニア層を中心に応募が大幅に減ります。

• 評価結果は技術面接・コーディング試験と連動させて初めて価値が最大化します。

エンジニア採用でGitHub・ポートフォリオを正しく評価する方法

エンジニア採用でGitHub・ポートフォリオを評価するときは、コントリビューション量（草の濃さ）ではなく「READMEの質・コミット履歴・コードの設計・Issue/PRの使い方・技術選定の意図」の5軸で見ます。提出は任意にし、非エンジニア人事はチェックリストで一次選別、コードの最終判断はエンジニアに委ねるのが実務的です。本記事ではその具体的な手順を、選考フローへの組み込み方まで含めて解説します。

なぜ今、GitHub・ポートフォリオ評価が重要なのか

GitHub・ポートフォリオが選考材料として重視されるのは、レジュメのスキル年数からは「実際にどんなコードを書き、どう問題を解決するか」が見えないからです。アウトプットで判断する企業が増えた背景には、スキルベース採用の広がり・AI時代の実装力重視・リモートワークの普及という3つの構造変化があります。

「Java 5年、AWS 3年」というスキルシートの記載は、実装の質を保証しません。特にスタートアップでは入社直後から手を動かせるかが事業スピードに直結するため、実装力・設計力・コミュニケーション力を事前に確認できるGitHub・ポートフォリオの価値が高まっています。

統計データ：エンジニア採用市場の逼迫 パーソルキャリアの調査によると、2026年のIT・通信エンジニアの中途採用求人倍率は依然として10倍前後の高水準で推移しています（出典：パーソルキャリア「doda 転職求人倍率レポート」2026年）。また経済産業省の試算では、2030年に最大約79万人のIT人材が不足するとされています（出典：経済産業省「IT人材需給に関する調査」2019年）。即戦力市場が逼迫するなか、限られた母集団から見極める精度を上げる手段としてアウトプット評価の重要性が増しています。

ただし、GitHubの活用にはコツがあります。「コントリビューション数が多い＝優秀」と単純に考えると、業務コードがプライベートリポジトリにある優秀層を取りこぼし、大きな判断ミスにつながります。

GitHubプロフィールの正しい見方：5つの評価軸

GitHubプロフィールを採用選考で活用するときは、以下の5軸で確認するとエンジニアの実力を多角的に把握できます。どれか1つではなく、組み合わせて総合判断するのがポイントです。

1. READMEの充実度 — プロジェクトの目的・背景、セットアップ手順、使用技術と選定理由、デモリンク、既知の課題が書かれているか。READMEは「プロジェクトの顔」であり、ドキュメンテーション能力と伝える力が表れます。ただし入口の判断材料であり、決定打ではありません。

2. コミット履歴の質 — コミットメッセージが具体的か、小さな単位でこまめにコミットしているか、機能追加・バグ修正・リファクタリングが分かれているか。きれいなコミット履歴は、チーム開発でレビューしやすい進め方ができる兆候です。

3. コードの品質と設計 — テストコードの有無、ディレクトリ構成の論理性（src/ tests/ docs/など）、依存関係の管理、秘密情報がハードコードされていないか（.env.exampleの有無）。エンジニアの協力が必要な領域ですが、テストの有無は非エンジニアでも確認できます。

4. Issue・Pull Requestの活用 — 自分のプロジェクトでIssueを立てて管理しているか、PRに変更の意図を書いているか、OSSへのコントリビュートがあるか、レビューコメントが建設的か。協働スキルと、異なるコードベースへの適応力が見えます。

5. 技術選定と学習意欲 — 言語・フレームワークの使い分け、最新技術への関心、業務外での個人プロジェクトの有無。ただし個人プロジェクトがないことを減点理由にしてはいけません。

コミット履歴の良し悪しの見分け方は、以下の対比が目安になります。

最も重要な注意点は、「GitHubの草が濃い＝優秀」という判断を避けることです。業務コードはプライベートリポジトリにあることが多く、パブリック活動が少ない優秀なエンジニアは大勢います。

非エンジニア人事でも使える評価チェックリスト

非エンジニアの人事でも、READMEの読みやすさやコミットメッセージの丁寧さなど「仕事の丁寧さ」を測る項目なら一次判断ができます。コードの品質そのものはエンジニアに委ね、人事は「どの候補者を優先的にエンジニアに見てもらうか」を絞り込む役割に徹するのが効率的です。

以下は3分でできるクイック評価シートです。

非エンジニアが判断材料にしてはいけないのは次の3つです。「スター数」は人気度であって技術力ではありません。「フォロワー数」はSNSと同様に技術力と相関しません。「言語の色（使用割合）」は行数ベースなので実スキルとは異なります。

コード品質の判断を社内エンジニアに依頼する際は、以下のテンプレートを使うとエンジニアの負担を最小化できます。

ポートフォリオサイト・個人開発作品の評価ポイント

ポートフォリオサイトや個人開発作品を評価するときは、「実際に動くものがあるか」を最優先に見ます。企画書やデザインモックだけでは実装力の証明にならず、デプロイ済みでURLから動作確認できる状態が理想です。

ポートフォリオで確認すべき観点は次の4つです。

1. 動くものがあるか — デプロイされたWebアプリのURL、アプリストアのリンク、デモ動画があるか。最も重要な実装力の証明です。

2. 技術選定に意図があるか — 「リアルタイム更新が必要だったのでWebSocketを採用した」のように、目的に応じて技術を選び、その理由を説明できるか。

3. UI/UXへの配慮 — レスポンシブ対応、入力エラー時のハンドリング、ローディング状態の表示など、ユーザー視点で使いやすく作ろうとしているか。

4. 完成度とやり切る力 — 小さくても最後まで作り切ったプロジェクトは高く評価すべき。ただし学習用・実験用リポジトリが多いことは学習意欲の表れであり、減点理由にしない。

個人開発とチーム開発は、どちらを重視すべきか迷うところですが、両方見るのが理想です。自社のフェーズに合わせて重みづけを変えましょう。

スタートアップの初期フェーズでは個人開発の実績が、チーム拡大フェーズではチーム開発経験が、それぞれ重要になります。

選考フローへの組み込み方と候補者体験への配慮

GitHub・ポートフォリオ評価を選考に組み込むときは、候補者体験（CX）を損なわない設計が不可欠です。確認のベストタイミングは「書類選考と同時〜カジュアル面談の前」です。（参考：候補者体験改善の実践ガイド）

このタイミングが効果的な理由は、カジュアル面談でコードの話題をアイスブレイクに使え、技術面接の質問をカスタマイズでき、候補者に追加の負担をかけずに済むためです。

提出を「必須」にすべきかについては、必須にしないほうがよいというのが結論です。理由は3つあります。第一に、優秀なエンジニアの多くは業務コードがメインでパブリック活動が少ないこと。第二に、副業禁止企業の在職者は個人開発を公開しにくいこと。第三に、必須化すると母集団が大幅に縮小することです。

推奨は「任意提出にして、提出された場合はプラス評価」というアプローチです。求人票には「GitHubやポートフォリオがあればぜひ共有してください」と記載し、提出がない場合はコーディング試験で技術力を確認します（参考：コーディング試験設計ガイド）。

求人票の記載例は次のとおりです（参考：応募が増える求人票の書き方）。

良い例:

「GitHubアカウント（コントリビューション実績必須）」のように必須化する書き方は、応募のハードルを不必要に上げてしまうため避けましょう。

スカウト送信時のGitHub活用テクニック

GitHubはスカウト（ダイレクトリクルーティング）の段階でも強力な武器になります。事前にGitHubを確認したうえでスカウトを送れば、「あなたのことをちゃんと見ています」というメッセージが伝わり、テンプレ感のない個別メッセージが書けます。（参考：スカウトメール返信率アップの秘訣）

具体的な活用法は、候補者のリポジトリに触れて自社の技術スタックとの近さを示す、READMEの丁寧さから情報共有を大切にする姿勢を読み取って伝える、使用技術の共通点を明示する、といったものです。

ここまで個別化されたスカウトは、テンプレートメールと比較して返信率が大きく改善する傾向があります。ただし、ストーカー的にならないよう、言及するのはピン留めされたリポジトリに限定し、「見ました」ではなく「共感しました」という表現を使うバランスが大切です。

やってはいけないNG評価パターン5選

GitHub・ポートフォリオ評価で最も避けるべきは、バイアスのかかった誤った判断基準です。以下の5つは、いずれも優秀な候補者を取りこぼす典型的な落とし穴です。

1. コントリビューショングラフ（草）の濃さで判断する — 業務コードはプライベートリポジトリにあり反映されない。育児・介護など個人の事情でも活動量は変わり、多様性の観点でも問題がある。

2. スター数やフォロワー数で技術力を測る — スター数はマーケティング力やタイミングの影響が大きく、技術力の指標として不適切。

3. 言語やフレームワークの「数」で判断する — 10種類を浅く触るより、2〜3種類を深く使いこなすほうが実務では価値がある。

4. 「最近活動がない＝やる気がない」と判断する — 業務多忙、プライベートリポジトリでの活動、ライフステージの変化など理由は様々。面接で直接聞けば済む。

5. 特定のOSS貢献がないことをマイナスにする — 優れたプロダクトエンジニアの多くは業務コードに全力を注ぎ、OSS活動の時間がないことも珍しくない。

これらに共通するのは、パブリックな活動量を足切り基準にしてしまうという誤りです。GitHubは「見える範囲」がその人のすべてではないことを前提に評価しましょう。

技術面接との連動：GitHubを起点にした深掘り質問

GitHub・ポートフォリオを事前確認しておくと、技術面接の質が大きく向上します。重要なのは「何を作ったか」ではなく「なぜその判断をしたか」を語れるかどうかです。（参考：技術力評価の実践的手法）

GitHub起点の面接質問は、以下の3カテゴリで設計すると深掘りしやすくなります。

• 設計判断を掘り下げる — 「このプロジェクトでReactを選んだ理由は？他の選択肢と比較しましたか？」「スケールした場合、どこがボトルネックになりますか？」

• 問題解決プロセスを掘り下げる — 「一番苦労した技術的課題は？どう解決しましたか？」「もう一度作るなら何を変えますか？」

• チーム開発適性を掘り下げる — 「OSSにコントリビュートしたとき、どうコードベースを理解しましたか？」「技術的な意見が割れたとき、どう合意形成しましたか？」

技術面接を担当するエンジニアには、書類選考での所感（強み・深掘りポイント・懸念点）と推奨質問を事前に共有しておくと、限られた面接時間を効率的に使えます。GitHub評価で技術スキルを可視化しておくことは、入社後のミスマッチ防止にもつながります（参考：エンジニア採用ミスマッチを防ぐ原因分析と実践的な対策ガイド）。

ポートフォリオ評価のスコアリングシート

評価のブレを減らすには、スコアリングシートで数値化するのが有効です。複数の面接官が独立して採点し、後から突き合わせることで、属人的な判断のばらつきを抑えられます。評価基準を組織全体で統一するには、コンピテンシーモデルを明文化し、採用・評価・育成で同じ物差しを使うとさらに精度が上がります。

合計25点満点で、「15点以上なら技術面接に進める」といったラインを設定しておくと判断がブレにくくなります。運用ルールは、評価者を最低2名（人事1名＋エンジニア1名が理想）にする、独立して採点する、大きく割れたら3人目の意見を求める、定性コメントも必ず記録する、の4点を守りましょう。

職種・レベル別の評価基準カスタマイズ

GitHubの評価基準は、ポジションや経験レベルによって調整すべきです。一律の基準で全候補者を評価すると、適切な人材を見逃します。職種別の重点ポイントは次のとおりです。

• フロントエンド — デプロイ済みWebアプリの使い心地、レスポンシブ実装、アクセシビリティ配慮、パフォーマンス最適化、コンポーネント設計の再利用性。

• バックエンド — API設計の一貫性、データベース設計（ER図・マイグレーション）、エラーハンドリングとログ設計、テストの網羅性、認証・認可の実装。

• インフラ／SRE — Infrastructure as Code（Terraform等）、CI/CDパイプライン、監視・アラートのコード化、Dockerfileの品質、アーキテクチャ図などのドキュメント。

経験レベル別では、ジュニア（未経験〜3年目）は成長ポテンシャルを見ます。学習の軌跡、新技術への挑戦、失敗からの改善、チュートリアルのコピーではない自分なりのアレンジがあるかが評価軸です。シニア（5年目以上）は設計思想と影響範囲を見ます。アーキテクチャレベルの設計判断、技術選定理由、パフォーマンス・スケーラビリティへの配慮、メンタリングやレビューの質が問われます。

AI時代のポートフォリオ評価：新たな論点

GitHub CopilotやClaude CodeなどのAIコーディングツールが普及した現在、AIの利用自体は評価を下げる理由になりません。むしろ、AIを効果的に使いこなしているかどうかが新しい評価軸になりつつあります。（参考：Claude Code時代に採用すべきエンジニア像）

ポジティブに評価すべきは、AIが生成したコードを理解したうえでカスタマイズしている、出力をプロジェクトの文脈に合わせて調整している、AIでは対応しにくい設計判断や要件定義を自分で行っている、といった点です。一方で、全ファイルが同じスタイルで統一感がない、基本的なバグやセキュリティホールが放置されている、コミットが「一括で大量追加」のパターンばかり、といった兆候は注意が必要です。

コードがAIで生成されたかを見分けるのは難しくなっているため、面接で「この部分、なぜこの実装にしたのか」「この設計のトレードオフを説明してほしい」「AIツールをどう使い分けているか」を確認するのが現実的です。背景と意思決定プロセスを語れるなら、AIを使ったかどうかは問題になりません。

失敗事例に学ぶ：GitHub評価の落とし穴

実際の採用現場で起こりがちな失敗パターンを知っておくと、同じ轍を踏まずに済みます。代表的な3ケースを紹介します。

1. 「草が生えてない」で書類落ちにした — ある企業はコントリビューショングラフが空白の候補者を一律不合格にした結果、業務コードをプライベートで書いていた優秀なシニアを何人も見逃した。教訓：パブリックな活動量を足切り基準にしない。

2. ポートフォリオ必須で母集団が半減した — 「ポートフォリオURL必須」と記載した企業で応募者数が前年比50%以下に激減し、在職中シニアからの応募がほぼゼロになった。教訓：ポートフォリオは「あればプラス」に。

3. GitHub評価と面接評価が連動していなかった — 書類選考でGitHubを詳しく見ていたのに、結果が面接官に共有されず情報が活かされなかった。教訓：評価結果は必ず次の選考ステップに引き継ぐ。

これらはいずれも「評価設計の不備」が原因です。基準と運用ルールを明文化し、選考ステップ間で情報を連携する仕組みがあれば防げます。

導入ロードマップ：4週間でGitHub評価を選考に組み込む

GitHub評価を選考に組み込むなら、いきなり全面導入せず4週間で段階的に立ち上げるのが安全です。試験運用を挟むことで、自社に合った評価基準に調整できます。

1. Week 1：現状把握と目的設定 — 現在の選考フローを棚卸し（参考：選考フロー設計ガイド）、GitHub評価で解決したい課題を明確化、社内エンジニアに協力可能な時間を確認。

2. Week 2：評価基準の策定 — 本記事のスコアリングシートをベースに自社版を作成、職種・レベル別の重みづけを設定、基準をドキュメント化して共有。

3. Week 3：試験運用 — 直近の応募者3〜5名のGitHubを評価、人事とエンジニアでスコアを突き合わせて微調整、候補者への依頼文面を整備。

4. Week 4：本格運用開始 — 選考フローに正式組み込み、評価結果をATSに記録するルールを策定、月次で評価精度を振り返る仕組みを作る。

FAQ（よくある質問）

Q. GitHubアカウントを持っていないエンジニアはどう評価すればいいですか？

A. GitHubがないこと自体はマイナス評価にすべきではありません。企業のプライベートリポジトリで開発している人や、GitLab等を使っている人も多くいます。GitHubがない場合は、コーディング試験やシステム設計面接で技術力を評価しましょう。求人票にも「GitHubは任意」と明記しておくのが親切です。

Q. 非エンジニアの人事がGitHubを見て、本当に意味のある判断ができますか？

A. できます。コードの品質自体はエンジニアに任せるべきですが、READMEの充実度、コミットメッセージの丁寧さ、プロフィールの整備状況など、非エンジニアでも判断できる項目は多いです。本記事のチェックリストを使えば一次スクリーニングの精度は確実に上がります。最終的な技術判断はエンジニアに委ねつつ、「どの候補者を優先的にエンジニアに見てもらうか」の判断に活用してください。

Q. ポートフォリオの提出を求めると応募数が減りませんか？

A. 「必須」にすると確実に減ります。「任意」にして「あればプラス評価」と明記すれば、応募数への影響は最小限です。「GitHub URLがあれば記入してください」程度の任意欄を設けている企業は多く、候補者の抵抗感も少ないです。重要なのは、ポートフォリオがないことで不利にならないと明示することです。

Q. OSSコントリビューションの経験をどの程度重視すべきですか？

A. ポジションによります。インフラやツール系では実務直結のスキル指標になりますが、プロダクト開発では個人開発やチーム開発の経験のほうが参考になるケースが多いです。OSSコントリビューションは「あればプラス」程度の位置づけにし、必須条件にはしないのが無難です。

Q. GitHubの評価に使える外部の補完材料はありますか？

A. 候補者が技術ブログ（Zenn、Qiita、note等）で記事を書いている場合、技術的な思考プロセスや説明力を確認できる貴重な評価材料になります。LinkedInのスキルセクションや推薦文も補完情報として使えます。ただし、どの材料を使う場合でも、最終的な判断は面接での対話に基づくべきです。

Q. 候補者のGitHubを見る際、プライバシーの観点で注意すべきことはありますか？

A. GitHubのパブリックリポジトリは誰でも閲覧可能なので、確認すること自体に法的な問題はありません。ただし、候補者が明示的に共有していない個人的なリポジトリ（政治・宗教関連など）を判断材料にしないこと、評価は技術力と仕事の進め方に限定することが大切です。候補者に「GitHubを確認させていただきます」と事前に伝えるのが望ましいです。

Q. ジュニアとシニアで評価基準をどう変えるべきですか？

A. ジュニアは成長ポテンシャル、シニアは設計力と影響範囲を重視します。ジュニアはコードの品質が低くても「直近3ヶ月で成長している」「自分なりに工夫している」ことが重要です。シニアはアーキテクチャ選定の妥当性、パフォーマンス・セキュリティへの配慮、チームへの技術的影響力を確認してください。

まとめ・次のアクション

GitHub・ポートフォリオ評価は、書類選考の精度を高め、面接の質を向上させる強力なツールです。ただし、使い方を間違えると優秀な候補者を見逃したり、不公平な選考になったりするリスクもあります。今日から始められるアクションは次の3つです。

1. 求人票に「GitHub・ポートフォリオ歓迎（任意）」の一文を追加する — 応募のハードルを上げずに情報量を増やせます。

2. 本記事のチェックリストで次の書類選考を試す — まず3〜5名の候補者で試験運用し、感覚をつかみましょう。

3. 社内エンジニアに「15分だけ協力してほしい」と依頼する — 評価依頼テンプレートを使えば負担を最小限に抑えられます。

エンジニア採用の各ステップを改善したい方は、以下の記事もあわせてご覧ください。

• スキルベース採用の導入ガイド

• コーディング試験設計ガイド

• カジュアル面談の完全ガイド

• 選考フロー設計の実践手法

エンジニア採用にお困りの方は、ぜひ techcellar にご相談ください。エンジニア出身の採用コンサルタントが、GitHub評価の設計から選考フロー全体の最適化まで、伴走型でサポートします。