GitHubは『エンジニアの履歴書』
エンジニアの転職・案件獲得において、GitHubは事実上のポートフォリオです。「コードを書ける」の証明だけでなく、「設計判断」「ドキュメント」「継続性」が見られます。本記事では、GitHubで見られるポートフォリオを作るための整え方を編集部の視点で整理します。成果は個人差が大きく保証されるものではありません。
プロフィールREADMEの作り方
(1) 1行の自己紹介：「○○エンジニアです」。(2) 技術スタックを明示：言語・フレームワーク・クラウド。(3) 主要プロジェクト：代表3〜5個へのリンク。(4) 連絡先：Twitter・LinkedIn・メール。(5) 視覚要素：GitHub Stats等のバッジは控えめに。プロフィールREADMEは「会ったときの第一印象」になります。個人技術ブログの始め方 もご参考に。
公開リポジトリの選び方
(1) 完成度の高いものに絞る：実験的なものはprivateで。(2) READMEが整っている：目的・使い方・技術選定が分かる。(3) READMEに画像・動画：「何ができるか」が一瞬で分かる。(4) テストとCI：品質への配慮を見せる。(5) ライセンス：OSSなら明示。「数」より「質」、見られる前提で公開を選びます。未経験からフロントエンドエンジニア もご参考に。
READMEに書くべき項目
(1) 1文での説明：「○○を○○するツール」。(2) スクリーンショット・GIF：視覚で分かるように。(3) 使い方：クイックスタート3分以内。(4) 技術スタックと設計判断：「なぜこの構成か」。(5) 制約・既知の課題：誠実に明示。(6) 貢献ガイド：OSSとして開く場合。ランディングページの作り方 もご参考に。
コミット・PR履歴の見え方
(1) コミットメッセージ：「変更内容」と「なぜ」の両方。(2) PRの設計：小さく・分かりやすく。(3) レビュー対応：議論の質も見られる。(4) OSSへの貢献：外部リポジトリへのPRは強い武器。(5) 継続性：Contributions Graphの「継続している」がプラス。「綺麗な履歴」は技術力以上にチーム適性を示します。GitHub Actions学習 もご参考に。
OSSへの貢献の始め方
(1) 使っているOSSのIssueを覗く：good first issue から。(2) ドキュメント改善から：技術ハードル低くインパクト大。(3) テストケース追加：コード理解と貢献の両立。(4) バグ修正：小さく確実に。(5) 機能提案・実装：メンテナと事前合意してから。「使う側→貢献する側」のシフトは大きな成長機会です。TypeScript学習 もご参考に。
転職での見られ方
(1) 採用担当はREADMEを最初に見る：コードより先に文章。(2) 3〜5リポジトリを深く見る：選択と集中。(3) コミット履歴で人柄を読む：コミットメッセージ・PR説明。(4) OSS貢献は加点要素：外部評価の証明。(5) 継続性が信頼に繋がる：数年続く活動はプラス。ハイクラス転職とエージェント活用 もご参考に。
失敗しがちなパターン
(1) 未完成リポジトリの大量公開：印象が悪化。(2) READMEが手抜き：コードに自信があっても伝わらない。(3) 個人情報・秘密の漏洩：APIキー・credentialsの混入。(4) OSSへの一方的なPR：メンテナとの合意なし。(5) 転職時だけ更新：継続性が見られている。対策は、(1)厳選公開、(2)README重視、(3)シークレット監視、(4)コミュニケーション尊重、(5)平時の継続、です。IT・Web業界の職種完全マップ も合わせてご活用ください。