GitHub を職務経歴書代わりに使う｜エンジニア中途必須の 7 タスク

GitHub は職務経歴書の代わりになりますが、リポジトリを並べるだけでは評価されません。採用担当が短時間で「何ができる人か」を判断できるよう、プロフィール、README、Pinned Repo、設計意図を整える必要があります。

タスク 1: プロフィール README を整える

プロフィール README には、得意領域、主要技術、最近取り組んだテーマ、連絡先、職務経歴書やポートフォリオへのリンクを置きます。技術スタックのバッジを並べすぎるより、何を作り、どのような課題を解いたかを短く書く方が評価されます。

中途採用では、個人の趣味開発よりも業務に近い再現性が見られます。中途ポートフォリオの最新トレンド と同じく、成果物だけでなく判断プロセスが伝わる構成にしてください。

タスク 2: Pinned Repo を 3〜6 件に絞る

Pinned Repo は採用側が最初に見る棚です。学習途中の小さなリポジトリを大量に並べるより、完成度の高い 3〜6 件に絞ります。Web アプリ、API、インフラ、データ処理、OSS 貢献など、見せたい強みに合わせて選びましょう。

各 README には、目的、機能、技術選定理由、セットアップ方法、設計上の工夫、今後の改善を入れます。AI を使った開発経験があるなら、生成 AI 時代のスキルポートフォリオ のように、人間が判断した部分を明確に書くことが重要です。

タスク 3: Contribution Graph を過信しない

緑の草が多いことは継続性の証明になりますが、それだけで採用されるわけではありません。業務コードは非公開のことが多く、採用側もそれを理解しています。無理に毎日コミットするより、質の高いリポジトリと説明文を用意する方が効果的です。

ただし、OSS への issue、PR、レビューコメントは強い材料になります。コードを書く力だけでなく、非同期で議論し、他者の設計に合わせる力が見えるからです。これは リモートワーク向け職務経歴書 でも評価される観点です。

タスク 4: 職務経歴書と接続する

GitHub は単体で完結させず、職務経歴書の実績と紐づけます。たとえば「API のパフォーマンス改善を担当」と書いた職務経歴書に対し、個人リポジトリでは同種の設計やベンチマークを公開しておくと説得力が増します。

会社の機密コードは公開できません。代わりに、抽象化したサンプル、設計メモ、技術記事、検証コードを用意します。採用側が知りたいのは、過去のコードそのものではなく、同じレベルの課題をもう一度解けるかです。

判断前に確認したいチェックリスト

• プロフィール README に得意領域と連絡先を入れたか
• Pinned Repo を見せたい強みに合わせて絞ったか
• 各 README に技術選定理由と設計意図を書いたか
• 職務経歴書の実績と GitHub の公開物がつながっているか

関連記事

• 中途ポートフォリオの最新トレンド
• 生成 AI 時代のスキルポートフォリオ
• リモートワーク向け職務経歴書

まとめ

GitHub を職務経歴書代わりに使うなら、コード置き場ではなく評価導線として整える必要があります。読む人が迷わず強みを理解できる構成にしましょう。