エンジニア職務経歴書のGitHub書き方｜採用担当者が落とすNGと通過術

この記事では、エンジニアの職務経歴書にGitHubを記載する正しい方法を採用担当者目線で解説します。「GitHubを載せたら評価が上がるのか、それとも逆効果なのか」「URLを貼るだけでいいのか、何か補足が必要か」——書類選考を通過するための具体的な書き方と、逆に落とされるNGパターンまで、採用現場の視点からお伝えします。

採用担当者はGitHubを「本当に」見ているのか

技術系採用でGitHubチェックが標準化される理由

結論から言うと、技術系の採用においてGitHubのチェックは「オプション」ではなく「標準プロセス」になりつつあります。

採用担当者がGitHubを確認する理由は、職務経歴書に書かれたスキルが本物かどうかをコードで直接判断できるからです。「ReactとNode.jsを3年使用」と書かれていても、そのスキルが実際にどの水準なのかは文章だけでは測れません。GitHubを見ると、コードの書き方・設計の考え方・ドキュメントの整え方まで短時間で把握できます。

特に以下のような採用場面では、GitHubの確認はほぼ前提とされています。

• 技術試験を設けていないスタートアップ・ベンチャー企業
• 即戦力採用で書類選考段階からスキルレベルを絞りたい企業
• リモート採用で直接の面談機会が少ない採用フロー

GitHubで「評価が上がる人」と「下がる人」の分岐点

職務経歴書にGitHubを記載することは、必ずしもプラス評価につながるわけではありません。採用担当者が確認した結果、「書類の内容と実力が一致している」と判断されれば加点になりますが、コンテンツの内容次第では、書類選考通過率が下がるリスクもあります。

職務経歴書のどこにGitHubを書くか

基本は「URL・各種アカウント」欄への記載

GitHubを記載する場所は、職務経歴書の冒頭にある「連絡先・URL欄」や「各種アカウント欄」が基本です。多くの職務経歴書フォーマットには、名前・住所・連絡先の下に「URL / 各種アカウント」という項目があります。ここにGitHubのプロフィールURLを記載します。

ただし、URLを記載するだけでは不十分です。採用担当者が「どのリポジトリを見ればいいのか」わからないまま終わることが多いためです。見てほしいリポジトリを具体的に示す方法については、後のセクションで解説します。

テクニカルスキル欄と連動させると書類の完成度が上がる

より効果的な記載方法は、テクニカルスキル欄との連動です。スキルシートや保有スキル欄に書いた内容と、GitHubで見てほしいリポジトリが対応していると、採用担当者が「実力の証拠」として納得しやすくなります。

たとえば、スキル欄に「TypeScript / Next.js / PostgreSQL（実務3年）」と書いたうえで、GitHubの中で「このリポジトリで同じ技術スタックを使っています」と一言添えると、書類全体の信頼性が格段に上がります。

採用担当者がGitHubで確認する5つのポイント

GitHubを見る採用担当者が何を確認しているかを知っておくと、どのリポジトリを前面に出すべきかが明確になります。ポイントは大きく5つあります。

①コミットの継続性と最終更新日

採用担当者が最初に目を向けるのは、コントリビューションの活動グラフの密度と最終更新日です。1〜2年間まったくアクティビティがないGitHubは、「今は勉強・開発を止めている人」という印象を与えます。

コミット頻度が高い必要はありませんが、最低でも直近3〜6ヶ月以内に活動の痕跡があることが重要です。転職活動中に個人プロジェクトやアウトプットを出すことで、「学習継続中の人材」という印象を作ることができます。

②READMEの充実度（30秒で伝わるか）

採用担当者がリポジトリを開いて最初に見るのはREADMEです。「このプロジェクトが何なのか」「どんな技術を使っているか」「動かすにはどうすればいいか」の3点が30秒以内に伝われば合格です。

READMEがなかったり、「WIP」とだけ書かれているリポジトリは、採用担当者に「丁寧な仕事ができない人」という印象を与えます。開発スキルよりも「相手に伝える習慣があるか」が問われているとも言えます。

③コード品質と設計意図の可読性

コードの中身を細かく読む採用担当者は多くありませんが、全体的な「設計のクセ」は確認されます。

• 変数名・関数名が意味のある命名になっているか
• 一つの関数が過度に長くなっていないか
• コメントや型定義の扱い方はどうか

完璧なコードである必要はありませんが、「読みやすくしようとしている姿勢」は十分に伝わります。

④使用技術スタックとバージョン

使用している言語・フレームワーク・ライブラリのバージョンを確認されることがあります。職務経歴書に記載したスキルとGitHubのコードで使っている技術が乖離している場合は、信頼性に疑問を持たれるリスクがあります。スキル欄と実際のコードの整合性を事前に確認しておくことが重要です。

⑤チーム開発への貢献（PR・Issue・レビュー）

個人開発リポジトリだけでなく、オープンソースへの貢献やチームプロジェクトへのPR・Issueの履歴は高く評価されます。採用担当者は「一人で作れる人」だけでなく、「チームの中で機能する人」かどうかを確認しています。

大きな貢献でなくても構いません。READMEの誤字修正、ドキュメントの改善PRなど、小さな貢献の積み重ねが「チームへの関心と協調性」を示す材料になります。

採用担当者に刺さるGitHub記載の書き方【例文あり】

GitHubのURLだけ書いても差はつかない——「見てほしいリポジトリ」を指定する

GitHubのプロフィールURLを貼るだけでは、採用担当者はどのリポジトリを確認すべきかわかりません。何十人もの書類を処理する採用担当者が、自力でリポジトリを探して判断してくれることを期待するのは現実的ではありません。

「見てほしいリポジトリ」を職務経歴書内で明示することで、採用担当者の確認効率が上がり、自分の強みが確実に伝わります。URLを一行貼るだけの記載と、リポジトリを指定する記載では、書類の評価に大きな差が生まれます。

職務経歴書とGitHubの役割分担を設計する

職務経歴書とGitHubは「補完関係」であるべきです。職務経歴書が「何をやってきたか」の証明なら、GitHubは「どう作るか」の証明です。この役割分担を意識することで、書類全体に一貫したストーリーが生まれます。

項目	職務経歴書	GitHub
担当業務・実績	詳しく記載	不要
使用技術・スキル	スキルシートに記載	コードで補完
プロジェクト概要	簡潔に説明	READMEで詳述
設計意図・工夫点	箇条書きで触れる	コメント・READMEで詳述

職種・経験年数別の記載例

職種や経験年数によって、GitHubで見せるべきポイントは変わります。それぞれの状況に合った記載方法を確認しておきましょう。

これで落とされる——GitHubのNGパターン4選

GitHubの記載が逆効果になる典型的なパターンを整理します。該当するものがあれば、職務経歴書を提出する前に必ず対処してください。

「作りかけ」「コミット途絶え」でマイナス評価になる

リポジトリ一覧に未完成のプロジェクトが並んでいる状態は、「物事を最後までやり遂げられない人」という印象を与えるリスクがあります。コミット履歴が半年以上止まっている場合も同様です。

GitHubを職務経歴書に記載するなら、事前にリポジトリを整理することが前提です。見せたくない・未完成のリポジトリはPrivateに変更し、外部から見えるのは「自信を持って見せられる状態のもの」だけにしておきます。

READMEなし・説明ゼロのリポジトリは載せないほうがよい

コードだけあってREADMEがないリポジトリは、採用担当者に「この人は相手に説明する習慣がない」という印象を与えます。説明がないコードは、どれだけ優れていても採用担当者には評価されません。

最低限「何を作ったか」と「使用技術」の2点を書いたREADMEがないリポジトリは、職務経歴書に記載するリポジトリから外すか、提出前にREADMEを整備することを推奨します。

業務コードをPublicで公開してしまうリスク

前職・現職の業務で書いたコードをGitHubのPublicリポジトリとして公開することは、企業の機密情報漏洩にあたる可能性があります。採用担当者もこのリスクを認識しており、「自社の機密をこの人も外に出すのではないか」という懸念を持つことがあります。

業務で書いたコードは必ずPrivateリポジトリで管理し、Publicにするのは個人プロジェクトや学習用コードだけにしてください。

技術バッジを並べすぎて薄さが露呈する

プロフィールREADMEに技術バッジを大量に並べているだけでは、「使えるかどうか」の証明にはなりません。バッジが多いわりに実際のリポジトリが少ない・コミットが少ない場合、採用担当者に「ラベルだけで中身がない人」という印象を与えます。

バッジはあくまで補足情報です。実際のコードとREADMEが充実していれば、バッジは最小限で構いません。

提出前チェックリスト｜GitHub付き職務経歴書の最終確認

GitHubを記載した職務経歴書を提出する前に、以下の項目を必ず確認してください。一つでも該当するものがあれば、提出前に対処することを推奨します。

• GitHubのURLが正しく、実際にアクセスできる状態か
• 職務経歴書に書いたスキルと、GitHubで使っている技術に大きな乖離がないか
• 見てほしいリポジトリをURLや補足文で職務経歴書内に明示しているか
• 紹介するリポジトリにREADMEが整備されているか
• 業務コードがPublicリポジトリに含まれていないか
• 作りかけ・長期未更新のリポジトリをPrivateに変更したか
• 直近3〜6ヶ月以内にコミット実績があるか

まとめ

エンジニアの職務経歴書にGitHubを記載することは、使い方次第で強力な武器になります。

• 記載場所は「URL・各種アカウント欄」が基本。URLのみでなく、見てほしいリポジトリを具体的に指定する
• 採用担当者が確認するのは①コミット継続性 ②READ ME ③コード品質 ④技術スタック ⑤チーム貢献の5点
• 職務経歴書とGitHubは「補完関係」。書類で語れないコードの実力をGitHubが証明する設計にする
• NGパターン（作りかけ・コミット途絶え・READMEなし・業務コード公開）は提出前に必ず解消する

URLを貼るだけの消極的な記載ではなく、「見てほしいリポジトリを指定し、READMEで設計意図を語れる状態」にすることが、採用担当者の評価を高める最短の方法です。GitHubと職務経歴書をセットで設計することで、他の候補者との明確な差を生み出してください。

エンジニアの職務経歴書とGitHubに関するよくある質問

GitHubを職務経歴書に書かないと不利になりますか？

必ずしも不利にはなりませんが、技術系企業・自社開発企業では書類選考段階でGitHubの有無が判断材料になることがあります。特にスタートアップでは参照されるケースが増えています。GitHubアカウントを持っていない場合は、個人プロジェクトや学習コードから始めて提出できる状態にしてから転職活動を進めることを推奨します。

コミット数が少なくてもGitHubを載せていいですか？

コミット数の多さよりも、「完成したプロジェクトが一つあるか」「READMEが整備されているか」が重要です。コミット数が少なくても、READMEで設計意図や工夫点を語れているリポジトリがあれば採用担当者に伝わるものはあります。反対に、コミット数だけ多くてREADMEがないリポジトリは評価されにくい傾向があります。

業務での実績はPrivateリポジトリのためGitHubで見せられません。どうすれば伝わりますか？

職務経歴書のプロジェクト欄や職務概要欄に、使用技術・担当範囲・設計上の工夫点を詳しく記載することで補完できます。GitHubで見せられないぶん、文章での説明の精度を高めることが重要です。また、個人プロジェクトや学習用のリポジトリを別途整備してGitHubに公開しておくと、スキルの証明をある程度カバーできます。

ポートフォリオサイトを作った場合、GitHubとどちらを載せればいいですか？

両方載せることを推奨します。ポートフォリオサイトは「完成した成果物の見せ方」として、GitHubは「どう作ったかのプロセスとコード」として、それぞれ異なる評価軸を担っています。職務経歴書にはポートフォリオサイトのURLとGitHubのURLを両方記載し、それぞれの役割を一言で明示してください。