GitHubの見せ方｜採用担当が見る7ポイントと運用テク

最終更新: 2026年6月 | 30-40代エンジニアのためのGitHub単体運用ガイド

転職活動でGitHubのURLを添えるとき、採用担当はコードを隅々まで読むわけではありません。限られた時間でプロフィール・ピン留め・READMEをざっと眺め、「この人は今も手を動かしているか」「設計判断ができるか」を推し量ります。だからこそ、同じ成果物でも整え方ひとつで印象は大きく変わります。

本記事はGitHub単体の運用・整備テクニックに絞って深掘りします。GitHub・ブログ・登壇・OSSを横断してどう組み合わせるかの全体像はポートフォリオの見せ方を、ブログやOSSの個別深掘りはそれぞれの記事をあわせてご覧ください。

データ調査時点: 2026年6月｜出典: 各IT転職エージェント公開情報

求人数・年収などの数値は調査時点の公開情報に基づきます。最新の情報は各サービスの公式サイトをご確認ください。当サイトの評価基準は記事制作ポリシーをご覧ください。

1. 結論：ミドルのGitHubは『現役性と再現性』を示す場

未経験者のGitHubが「コードが書ける証明」なのに対し、実務経験のある30代・40代のGitHubに期待されるのは別物です。結論から言えば、ミドルが示すべきは次の2点です。

現役性

「マネジメント中心で、もう手を動かせないのでは」という40代特有の懸念を払拭する。最新のコミット・モダンな技術スタックの痕跡が効きます。

再現性

「なぜその設計にしたか」をREADMEで語れること。手が動くだけでなく、判断の理由を再現可能な形で残せるのがミドルの差別化点です。

ミドルの優先順位：即席アプリを量産するより、①整ったプロフィール＋ ②設計判断が伝わるリポジトリ1〜2個＋ ③継続の痕跡に時間を投資する方が費用対効果が高いケースが多いです。数ではなく、1つの完成度で勝負しましょう。

2. 採用担当が見る7つのポイント

技術系の採用担当・エンジニア面接官がGitHubを開いたとき、無意識にチェックしている観点を7つに整理しました。順番に潰していけば、限られた閲覧時間で好印象を作れます。

コントリビューション（草）＝継続性

緑のグラフは「今も活動しているか」の第一印象。毎日埋める必要はなく、不自然に詰める必要もありません。継続の痕跡があれば十分です。

ピン留めリポジトリ＝見せたい代表作

最大6枠に何を置くかで自己プロデュース力が伝わります。READMEが整い技術判断が見えるものだけを厳選します。

README＝コードを読まずに伝わる説明

概要・構成図・起動方法・工夫点・残課題が書かれているか。多くの採用担当はREADMEで判断を済ませます。

技術選定の理由＝設計判断の証拠

「なぜこの言語・構成にしたか」が書かれていると、ミドルらしい判断力が伝わります。最も差をつけやすい部分です。

issue・PRの使い方＝協働の作法

個人開発でもissueでタスクを管理し、PR単位で変更を積んでいると、チーム開発に馴染む人だと伝わります。

コード品質＝命名・粒度・テスト

全部は読まれませんが、開いた1ファイルの命名・関数の粒度・テストの有無で印象が決まります。

3. リポジトリREADMEチェックリスト

ポイント3・4で触れたREADMEは、GitHub運用で最も投資対効果が高い箇所です。プロフィールREADMEの雛形はポートフォリオの見せ方にありますので、ここでは各リポジトリのREADMEに絞って、ミドルが書くべき項目をチェックリストにしました。

✓1行で「何を解決するもの」かが書かれている
✓技術スタックと、なぜそれを選んだかの一文がある
✓アーキテクチャ図 or 構成の概要がある
✓ローカルでの起動手順（環境構築コマンド）がある
✓工夫した点・設計上のトレードオフが書かれている
✓既知の課題・残タスク（Known Issues）を正直に書いている
✓デモURL or スクリーンショットがある（動くものは強い）
✓ライセンスが明記されている

下は「工夫した点・トレードオフ」セクションの記述例です。ミドルらしさは、選んだ理由と選ばなかった選択肢を併記できるかに出ます。

## 設計上の判断

- 永続化はPostgreSQLを採用。当初はNoSQLも検討したが、
  集計クエリが多くトランザクション整合性が要るためRDBを選択。
- 認証は自前実装せず外部IdPに委譲。運用負荷とセキュリティ責任を
  外出しする判断（小規模個人開発のため）。
- 非同期処理はあえて入れていない。現状のスループットでは
  オーバーエンジニアリングと判断した（負荷が増えたら導入予定）。

## 残課題（Known Issues）

- E2Eテスト未整備。現状はユニットテストのみ。
- N+1クエリが一覧画面に1箇所残っている（issue #12）。

4. ピン留め・草・プロフィールの運用テク

ピン留めは「見てほしい順」に並べ替える

ピン留めは表示順を手動で変えられます。最も自信のあるリポジトリを左上に置きましょう。OSS貢献のフォーク先や、業務に近い技術構成のものを前に出すと、応募先に刺さります。

古い・未完成リポジトリはアーカイブで整理

削除せずともアーカイブすれば「読み取り専用の過去作」として整理できます。学習用の使い捨てリポジトリが大量に並んでいる状態を解消し、現役性のノイズを減らせます。

草は「無理なく継続」が原則

空コミットや意味のない更新で草を埋めるのは逆効果になり得ます。OSSのドキュメント修正、個人開発の小さな改善など、意味のある変更を週数回積む方が誠実に見えます。

プロフィールREADMEで「顔」を作る

プロフィールトップのREADMEに得意領域・経験年数・連絡先・アウトプット先をまとめます。雛形はポートフォリオの見せ方を流用してください。

5. 業務コードを出せない人の代替策

30-40代の多くは「業務コードは公開できないし、家庭や仕事で個人開発の時間も取りにくい」という現実を抱えています。GitHubが薄いこと自体は珍しくありません。出せないなら、別の形で現役性と再現性を示しましょう。

知見の汎用版を作り直す

業務で得た課題感から固有情報を取り除き、小さな汎用ツールやサンプルとして公開する。社内ツールの汎用版はよくあるパターンです。

OSSに小さく貢献する

ドキュメント修正・翻訳・issue報告など、コードを書かない貢献でも公開された履歴が残ります。詳細はOSS貢献の記事へ。

技術記事で思考を可視化する

コードを公開できなくても、設計判断やトラブル対応の思考過程は記事にできます。これも立派なアウトプットです。

サンプルコード付きの検証リポジトリ

新技術を試した最小構成のサンプルを公開する。完成プロダクトでなくても、検証の丁寧さが伝わります。

6. ミドルがやりがちなNG例

NG1：bot的なコミットで草を量産

自動コミットや空更新で草を埋めると、見る人が見れば不自然さに気づきます。継続性を偽装するより、薄くても本物の活動を残しましょう。

NG2：フォークしただけのリポジトリが大量

スター代わりにフォークしたリポジトリが並ぶと、自分の成果物が埋もれます。フォークは整理し、貢献したものだけ残します。

NG3：READMEのない空リポジトリを放置

コードがあってもREADMEがないと読まれません。説明のないリポジトリは公開しないか、最低限の概要を付けます。

NG4：業務コードをそのまま公開

守秘義務・著作権違反になり、信頼を一発で失います。社名・内部数値・固有構成は出さず、汎用化してから公開します。

7. 30代・40代でのGitHubの使い分け

30代：技術の幅と設計判断を見せる

手が動くのは前提として、技術選定やリファクタの判断ができることをREADMEで示すと効果的です。Web系・新領域への挑戦時はGitHubの効果が大きくなります。関連: 30代の転職。

40代：現役性を疑われないことが最優先

「もう手を動かせないのでは」という先入観を、直近のコミットとモダンな構成で払拭します。マネジメント志向でも、コードを読み書きできる現役性を見せると採用の安心材料になります。関連: 40代の転職。

8. よくある質問

Q. GitHubに公開リポジトリがほとんどありません。転職で不利になりますか？▾

A. GitHubが空でも、それ自体で不採用になることは多くありません。多くのエンジニアは業務コードを公開できないからです。ただし、Web系・自社開発企業では『コードが書ける現役性』を見たい採用担当もいるため、個人開発・OSS・技術記事のいずれか1つでも継続している痕跡があると安心材料になります。空のまま放置するより、小さくても整ったリポジトリを1〜2個用意する方が効果的です。

Q. 業務で書いたコードをGitHubに載せても大丈夫ですか？▾

A. 業務コードをそのまま公開するのは守秘義務・著作権の観点で原則NGです。会社に著作権が帰属しているケースが大半で、社名や内部構成が特定できる情報を出すと信頼を失います。業務で得た知見を活かして、固有情報を取り除いた『汎用版』を個人で作り直して公開するのが安全な方法です。

Q. コントリビューションの草（緑のグラフ）は毎日埋めるべきですか？▾

A. 毎日埋める必要はありません。草は『活動が継続しているか』を示す補助的な指標であり、不自然な毎日コミットはかえって作為的に見えることもあります。週に数回でも、意味のある変更が継続的に記録されていれば十分です。業務リポジトリが非公開でも、個人開発やOSSへのコミットで活動を可視化できます。

Q. ピン留めリポジトリには何を選べばいいですか？▾

A. 最大6枠には『最も見てほしいもの』を厳選します。READMEが整っていて技術判断が伝わるリポジトリ、設計の工夫が見えるもの、OSS貢献のフォーク先などが候補です。チュートリアルそのままの学習用リポジトリや、READMEのない未完成リポジトリは外し、質で勝負しましょう。

Q. 古いリポジトリが残っていると印象が悪いですか？▾

A. 古い技術スタックの学習用リポジトリが大量に残っていると、現役性が伝わりにくくなることがあります。アーカイブ機能で過去のものを整理するか、ピン留めで見せたいものを前面に出すと印象が整います。ただし完成度の高い過去作品なら、年代が古くても残す価値はあります。

Q. GitHub以外で技術力を示す方法はありますか？▾

A. あります。技術ブログ（Zenn・Qiita）、OSS貢献、登壇資料、個人開発のデモサイトなどが代表例です。GitHubはあくまで成果物の置き場の一つなので、横断的な見せ方はポートフォリオの見せ方を、ブログ単体の運用は技術ブログの記事を参照してください。

GitHubの見せ方をプロに相談しよう

IT特化型エージェントなら、応募先に刺さるGitHub・成果物の見せ方を具体的にアドバイスしてくれます。

おすすめエージェントランキングを見る

ポートフォリオの見せ方（横断） →技術ブログの書き方・プラットフォーム選び →OSS貢献の始め方・8つの貢献 →継続的な学習の進め方 →技術面接対策ガイド →職務経歴書の書き方 →