エンジニア転職でGitHubは見られるのか｜14社を調べた結果

エンジニア転職でGitHubが見られるかは、応募する経路で変わります。当サイトが掲載している転職サービス14社を1社ずつ確認したところ、GitHubのアカウントを評価に使うと公式サイトに明記していたのは1社だけでした。この記事では、その調査結果と、経路ごとに何が読み取られるのかを整理します。

14社を確認した結果、GitHubを評価に使うと明記していたのは1社だった

「GitHubは転職で見られますか」という問いに答えるために、当サイトが掲載している転職サービス14社の公式サイトを1社ずつ読み、「何で応募者を評価すると書いてあるか」で分類しました。結果が次の表です。

評価に使うと明記しているもの	社数	該当するサービス
GitHub のアカウント 公開リポジトリを解析してスコアを出す	1社	Findy
その場で書かせたコード スキルチェックのランクで応募先が決まる	1社	paiza転職
職務経歴書・面談・求人条件での絞り込み コードを直接は見ない	12社	doda ／ ギークリー ／ Green ／ 社内SE転職ナビ ／ ウィルオブテック ／ ワークポート ／ レバテックキャリア ／ リクルートエージェント ／ マイナビ転職ITエージェント ／ AIdea Career ／ テックゴー ／ ユニゾンキャリア

GitHubのアカウントを評価に使うと明記していたのはFindyの1社、その場で書かせたコードで評価する仕組みを持つのがpaiza転職の1社、残る12社は職務経歴書・面談・求人条件での絞り込みで進める形でした。

ここで注意していただきたいのは、「明記していない」は「見ていない」ではないということです。担当者が個別にプロフィールを開く可能性は、各社の公開情報からは確認できません。この調査で言えるのは「仕組みとして組み込んでいると公表しているか」までです。当サイトはこの線を越えて断定しません。

それでもこの数字には意味があります。GitHubを整える作業が、応募先の選び方より先に来ることはないと分かるからです。14社中12社は、GitHubに何時間かけても評価の入口が変わりません。

同じアカウントでも、経路によって読み取られる範囲が違う

GitHubが関係する2社と、採用担当が直接プロフィールを開く場合とでは、対象になる範囲がまったく違います。3つの経路を、それぞれの公式の記述から並べたものが次の表です。

経路	何を見ているか	対象になる範囲	プライベートリポジトリ
GitHub のプロフィール 採用担当が URL を開いて直接見る	コントリビューショングラフ／ピン留めしたリポジトリ／プロフィール README	自分で設定した表示範囲	設定すれば活動量だけグラフに出る。リポジトリ名やコードの中身は出ない
Findy（スキル偏差値） GitHub 連携でスコアを算出する	コミット量／他プロジェクトへの貢献度／他者からのコード支持／アカウントの影響力	直近1年間の公開リポジトリ	対象外
paiza転職 スキルチェックのランクで判定する	GitHub を見ない。スキルチェックで獲得したランク	受験して提出したコード	関係しない

この表でいちばん大事な列は、真ん中の「対象になる範囲」です。プロフィールの見た目を整えることと、サービスのスコアが上がることは、別々に起きます。この2つを同じ作業だと思って進めると、時間をかけたのに評価が動かない、ということが起こります。

GitHubのプロフィールで設定できることは、公式ドキュメントに一覧がある

採用担当がURLを開いて直接見る場合、見えるのは自分が設定した範囲だけです。GitHubの公式ドキュメント「GitHub プロファイルの設定と管理」には、プロフィールで扱える項目が並んでいます。転職で関係するのは次の6つです。

• プロフィール README — プロフィールの先頭に表示される自己紹介
• アイテムをピン留めする — 見せたいリポジトリを上部に固定する
• 概要を表示する — アクティビティの概要を出すかどうか
• コントリビューションを表示する — いわゆる草のグラフ
• プライベート コントリビューション及び達成 — 非公開リポジトリでの活動をグラフに含めるかどうか
• コミットの詳細を表示する

このうち誤解が多いのが5番目です。プライベートリポジトリのコントリビューションを表示する設定にしても、公開されるのは活動があったという事実だけで、リポジトリ名やコードの中身は出ません。

これは両方の意味を持ちます。業務で書いたコードが漏れる心配なくグラフを埋められる一方で、中身を見せたことにはなりません。「草は生えているが、何をした人か分からない」というプロフィールは、この設定だけを触った結果として生まれます。

Findyのスキル偏差値が対象にしているのは「直近1年間の公開リポジトリ」

GitHub連携でスコアを出すのが、GitHubの開発履歴からスキルを偏差値化するFindyです。Findyは自社ブログで、スキル偏差値を「GitHubの公開リポジトリを対象に、コミット量や他プロジェクトへの貢献度、他者からのコード支持やアカウントの影響力などを中心に独自のアルゴリズムで解析してスコアリングしたもの」と説明しています。そして解析対象は「直近1年間のGitHubの公開リポジトリ」と明記されています。

この一文から、実際の作業に直結する2つのことが読み取れます。

1. プライベートコントリビューションの表示設定をオンにしても、スキル偏差値には反映されません。対象が公開リポジトリだからです。プロフィールのグラフは濃くなりますが、スコアは動きません
2. 数年前の活動は対象から外れます。過去に公開したものが多くても、直近1年が薄ければ、そのぶんは評価に入りません

Findy経由で応募するつもりなら、やることは「昔のリポジトリを整える」ではなく「これから1年、公開の場で手を動かす」に変わります。応募の3日前に始めて間に合う作業ではありません。逆に言えば、転職を検討し始めた時点で公開の活動を始めておくと、半年後に効いてきます。

評価軸に「他プロジェクトへの貢献度」と「他者からのコード支持」が入っている点も、作業の中身を変えます。自分のリポジトリを増やすことだけでなく、既存のプロジェクトへの関わりも対象に含まれる、と読めるためです。

paiza転職はGitHubを見ない。その場で書かせたコードで評価する

同じスカウト型でも、スキルチェックのランクで応募先が決まるpaiza転職は仕組みが違います。難易度別のプログラミング問題を解いてランクを獲得し、求人には「通過ランク」が設定され、指定ランク以上で応募できるという形です。オンラインエディタでそのまま実行・採点ができると説明されています。

GitHubに公開できるものが無い人にとって、この経路は現実的な代替になります。受験して提出したコードだけで判定されるため、業務のコードを出せるかどうかが関係しません。公開できる成果物を1年かけて積むのと、問題を解いてランクを取るのとでは、必要な時間の桁が違います。ランクの取り方と練習に使う時間の見積もりは、コーディングテストを誰が受けるのかを14社で調べた記事にまとめています。

一方で、この形が向かない場面もあります。アルゴリズムを解く力と、設計や運用の力は別物です。インフラ・SRE・情シスのように、成果がアルゴリズムのコードとして表れにくい職種では、ランクが実力の代理指標になりにくくなります。

残り12社は、GitHubではなく職務経歴書と求人条件で進む

14社のうち12社は、評価方法としてGitHubを挙げていませんでした。この12社で進める場合、読まれるのは職務経歴書と面談での説明です。GitHubのURLを職務経歴書に書くこと自体は妨げられませんが、それが評価の入口になっているわけではありません。

12社の中でも、技術の情報をどこまで求人票に載せているかには差があります。たとえば求人票に言語・OS・DB・クラウド環境を記載しているレバテックキャリアのように、開発環境を求人情報に書いているサービスがあります。この場合、応募者側は自分のスキルと求人の技術スタックを、応募前に照らし合わせられます。

12社側で進める場合、職務経歴書に書くべきなのは「何を作ったか」より「どの規模の、どういう体制で、どこを担当したか」です。GitHubで示せるのは書いたコードそのものですが、職務経歴書で読まれるのは担当範囲と判断の履歴になります。同じ経験でも、示す場所によって書き方が変わります。

GitHubで自分を説明するのが難しい人ほど、求人側の情報量が多いサービスを選ぶ意味があります。自分から出せる情報が限られるなら、相手から出ている情報で判断するという考え方です。求人票の技術情報だけでなく、企業の特性（大手系列企業・社員数500名以上・上場企業・設立30年以上）や残業時間の月間平均で絞り込めるマイナビ転職ITエージェントのように、働く条件の側を細かく持っているサービスもあります。

どの経路から始めるかを決める3つの質問

経路を先に決めると書きましたが、決め方が分からないという状態がいちばん止まります。当サイトが使っている判断の順番を置いておきます。上から順に答えて、最初に「はい」になったところで止めてください。

1. いま公開しているリポジトリのうち、直近1年に手を入れたものが3つ以上ありますか。「はい」なら、GitHub連携でスコアが出る経路が使えます。すでにある材料が、そのまま評価の対象になります
2. 問題を解く形の試験に、2時間ほど使えますか。「はい」なら、その場で書かせて判定する経路が使えます。過去の公開物が無くても成立し、必要な時間が短いのが特徴です
3. どちらも「いいえ」ですか。その場合、GitHubは評価の入口になりません。職務経歴書と、求人側の情報量が多いサービス選びに時間を使うほうが早く進みます

1つ目の質問で「3つ以上」としているのは、ピン留めの枠が実質4つで、そのうち1枠は差し替え用に空けておきたいからです。1つしか無い状態でGitHub連携の経路を選ぶと、スコアの根拠が薄いまま応募することになります。

2つ目を「2時間」としているのは、問題を解く形式に慣れる時間を含めた目安です。普段の業務で競技プログラミング的な処理を書いていない場合、形式そのものに戸惑うことがあります。ここは実力ではなく慣れの問題なので、時間を確保できるかどうかで判断してください。

3つ目に当てはまる人がいちばん多いはずです。14社中12社がこの経路だからです。「GitHubを整えなければ転職できない」という前提は、実際の掲載状況とは合っていません。

応募の前にやること — 5つの手順

順番が大事です。整えてから経路を選ぶのではなく、経路を決めてから整えます。ここまでの3つの経路のどれを使うかで、やることが変わるためです。

1. 公開できるものと、できないものを仕分ける。業務で書いたコードは、雇用契約や秘密保持の対象になっていることがあります。判断がつかないものは公開しない側に置きます
2. プロフィールREADMEを3行で書く。下にテンプレートを置きました
3. ピン留めを4つに絞る。数を出すほど、1つあたりを見てもらえる時間は短くなります
4. コントリビューションの表示設定を決める。グラフを埋めたいならプライベートを含める。ただしスキル偏差値には効きません
5. 使う経路を1つ決めてから、そこに合わせて手を入れる

プロフィールREADMEのテンプレート

採用担当がプロフィールを開いて最初に読む場所です。経歴を書く場所ではなく、「何をどれくらいやってきた人か」を1画面で伝える場所として使います。職務経歴書と同じ内容を貼ると、どちらも読まれません。

## 現在
<職種> を <年数> 年。いまは <領域> を担当しています。

## よく使う技術
言語: <3つまで>
基盤: <クラウド / DB / CI など3つまで>

## このアカウントで見られるもの
- <リポジトリ名> — <1行で何か>
- <リポジトリ名> — <1行で何か>
※ 業務のコードは含みません。<含めない理由を1行>

最後の1行を入れておくと、公開物が少ない理由が伝わります。説明がないまま少ないのと、理由が書いてあって少ないのとでは、読み手の受け取り方が変わります。「業務のコードは公開できないため、個人で書いたものだけを置いています」の一文があるだけで、空のプロフィールが「事情のあるプロフィール」になります。

READMEに何を書くかで迷ったときの考え方

テンプレートの3つの見出しは、それぞれ別の問いに答えています。「現在」はいま何をしている人か、「よく使う技術」はどの求人と話が合うか、「このアカウントで見られるもの」はこの先どこを見ればよいかです。3つとも1行で答えられるなら、それ以上は足さないでください。

技術の一覧を長くしたくなりますが、3つまでに絞るほうが伝わります。10個並んでいると、どれが主戦場なのかが読み手に判断できません。求人票の技術スタックと照らし合わせる相手にとっては、絞られているほうが照合が速くなります。

逆に書かないほうがよいのは、資格の一覧、学習中の技術、意気込みです。プロフィールREADMEは意欲を示す場所ではなく、いま何ができるかを示す場所として使うと、迷いが減ります。学習中のものを書くなら「学習中」と明示して、実務で使ったものと混ぜないでください。

ピン留めを4つに絞るときの選び方

4枠の使い道を決めておくと、迷わなくなります。編集部が使っている割り当ては次のとおりです。

• 1枠目 — いちばん長く手を入れているもの。コミット履歴に継続が出ます
• 2枠目 — 応募先の技術スタックに近いもの。経路ごとに差し替えます
• 3枠目 — 他の人が使える形にしたもの。READMEと使い方が書いてあるもの
• 4枠目 — 直近に触ったもの。止まっていないことが分かります

「業務のコードは出せない」人の進め方

受託や客先常駐が中心の場合、公開できるものが手元に無いことがあります。ここを無理に埋めようとすると、契約に触れる方向へ進みかねません。公開しない前提で組み立てます。

1. プライベートコントリビューションの表示だけをオンにする。活動量は出ますが中身は出ません。「動いている人」であることは伝わります
2. READMEに理由を1行書く。前述のテンプレートの最終行です
3. コードで評価する経路に寄せる。paiza転職のように、その場で書かせて判定する仕組みなら、過去の公開物が無くても評価が成立します
4. 職務経歴書側に寄せる。12社はもともとGitHubを評価に使うと明記していません。この場合、技術の説明は職務経歴書で行うのが本筋です

4番目が、この記事の集計から出てくる結論です。14社中12社にとって、GitHubが空であることは応募の障害になっていません。

つまずきやすい点

• 草を濃くすることを目的にしてしまう。グラフは活動量の記録であって、技術の説明ではありません。ピン留めとREADMEのほうが読まれます
• 業務のコードを判断せずに公開する。取り返しがつかない種類の失敗です。迷ったら公開しない
• チュートリアルの写経をピン留めする。同じ題材が並ぶと、他の応募者との違いが出ません
• READMEが空のリポジトリを見せる。何のコードか分からないものは、読み飛ばされます
• 応募の直前にまとめて整える。Findyの対象が直近1年である以上、直前の作業では動く範囲が限られます
• 全部のリポジトリを公開に切り替える。数が増えるほど、見てもらえる1つあたりの時間は減ります

GitHubを整えても効果が薄い人・向かない人

ここまでと逆のことを書きます。GitHubの整備が効かない立場の人がいます。当てはまる場合、そこに時間を使うより先にやることがあります。

• 公開できる成果物を作る時間が取れない人。直近1年の公開リポジトリが評価対象である以上、時間をかけられないなら、この経路は後回しにしたほうが早く進みます
• インフラ・運用・情シスなど、成果がコードとして残りにくい職種の人。設定や運用設計はリポジトリに出しにくく、GitHubで表せる範囲が限られます。職務経歴書側で書くほうが伝わります
• 受託や常駐が中心で、公開の可否を自分で判断できない人。判断できないものは公開しない、が原則です
• マネジメント側に寄っている人。直近のコミットが少ないのは自然なことで、そこを埋めようとするより、扱った規模や体制を書くほうが実態に合います
• 転職の時期が1〜2か月以内に決まっている人。Findyの評価が直近1年を見る以上、この期間で動かせる幅は限られます

当てはまる場合は、GitHubに時間を使う前に、転職全体の段取りを7つの工程で確かめるほうが進みます。どこから見ればよいか決めきれないときは、6つの質問で条件に合うサービスを見るという入口も用意しています。

よくある質問

GitHubのアカウントは、職務経歴書に書いたほうがよいですか

見せられる中身があるなら書いて問題ありません。ただし、14社中12社は評価方法としてGitHubを挙げていないため、書いたことで評価が変わる前提では組み立てないほうが安全です。アカウントを書く場合は、ピン留めとREADMEを整えてからにしてください。空のアカウントのURLは、書かないほうが情報量が多くなります。

草（コントリビューショングラフ）が薄いと不利になりますか

経路によります。採用担当が直接プロフィールを開く場合は目に入りますが、グラフが示すのは活動量であって技術ではありません。Findyのスキル偏差値については、対象が公開リポジトリなので、プライベートを含める設定でグラフを濃くしてもスコアには反映されません。paiza転職はそもそもGitHubを見ません。

業務で書いたコードを公開してもよいですか

雇用契約や秘密保持契約の対象になっていることがあり、判断は勤務先との契約内容によります。当サイトは、判断がつかないものは公開しないことをおすすめします。公開してしまってから取り消すことはできません。どうしても見せたい場合は、業務のコードそのものではなく、同じ課題を自分で書き直したものを置く方法があります。

転職活動を始めるまで時間がありません。何から手を付けますか

GitHubの整備は後回しにしてください。Findyの評価が直近1年を対象にしている以上、短期間で動かせる幅は限られます。先に職務経歴書と、応募先の選定に時間を使うほうが結果につながります。コードで示したい場合は、その場で書いて判定される仕組みのほうが短期間で形になります。

ピン留めするリポジトリが4つもありません

枠を埋めることが目的ではないので、1つでも構いません。説明のあるリポジトリ1つのほうが、READMEが空のリポジトリ4つより伝わります。数が足りないことより、何のコードか分からないものが並んでいることのほうが読み手を困らせます。

GitHubのアカウント名は本名でなくても構いませんか

ハンドルネームのままで問題ありません。ただし職務経歴書に書いて提出する場合は、提出書類の氏名とアカウントが同一人物だと分かる形にしておくほうが親切です。プロフィールREADMEの冒頭で職種と年数に触れておけば、それだけで結びつきます。

まとめ

• 当サイト掲載の14社を確認したところ、GitHubを評価に使うと明記していたのは1社（調査日 2026年8月31日・n=14）
• ただし「明記していない」は「見ていない」ではない。担当者が個別に見る可能性は公開情報からは分からない
• GitHubが見られるかは経路で変わる。プロフィールを直接見られる場合と、スコアが算出される場合は別
• プライベートコントリビューションを表示しても、出るのは活動量だけで中身は出ない
• Findyのスキル偏差値の対象は直近1年間の公開リポジトリ。表示設定を変えてもスコアは動かない
• paiza転職はGitHubを見ず、その場で書かせたコードのランクで判定する
• 整えてから経路を選ぶのではなく、経路を決めてから整える

GitHubで自分を説明しきれない場合は、求人側の情報量が多いサービスを選ぶほうが判断しやすくなります。開発環境が求人票に書かれていれば、応募前に自分のスキルと照らし合わせられます。

14社の集計は、当サイトが各サービスの公式サイトを確認して作成した記事データベースにもとづきます。各社の確認日は、転職サービス一覧の各ページに「最終確認日」として掲載しています。

関連記事

• Findy（ファインディ）の特徴と向かない人 — スキル偏差値の仕組みと、対応職種・エリア
• Green（グリーン）の特徴と向かない人 — 企業と直接やりとりする形のサービス

次に読む

paiza転職の特徴と向かない人｜GitHubに公開できるものが無い場合の、もう一つの見せ方です。

出典

• GitHub Docs「GitHub プロファイルの設定と管理」（2026年8月31日確認）
• Findy Blog「Findyのスキル偏差値とは？OSS活動やエンジニア転職の指標として活用」（2026年8月31日確認）
• paiza「paizaスキルチェック」（2026年8月31日確認）