GitHubポートフォリオの作り方｜採用担当が見る5つのポイント
なぜGitHubが採用で重視されるのか
未経験エンジニアの採用選考において、GitHubアカウントの提出を求める企業が増えています。履歴書やポートフォリオサイトだけでは見えないものが、GitHubには表れるからです。
履歴書ではわからないこと
- この人は実際にどれくらいコードを書いているのか
- どんな思考プロセスで開発を進めるのか
- 他の人と協働する能力があるのか
- 継続的に学習しているのか
GitHubは、これらすべてを「履歴」として可視化します。GitHubアカウントは、エンジニアにとっての「仕事の実績書」です。
未経験者こそGitHubが重要
経験者であれば、職務経歴書で過去のプロジェクト実績を語れます。しかし未経験者にはそれがありません。だからこそ、GitHubでのアウトプットが唯一の実力証明になるのです。
「スクールの課題をやっただけ」の人と、「GitHubで自主的に開発を続けている」人。採用担当がどちらを評価するかは明白です。
採用担当が見る5つのポイント
では、採用担当はGitHubのどこを見ているのでしょうか。具体的なチェックポイントを解説します。
1. READMEの充実度
リポジトリを開いたとき、最初に目に入るのがREADMEです。
- プロジェクトの概要と目的が書かれているか
- 使用した技術スタックと、その選定理由があるか
- セットアップ手順が明記されているか
- スクリーンショットやデモURLがあるか
READMEがないリポジトリは、「説明する気がない」と見なされます。技術力以前の問題です。
2. コミット履歴の質
コミット履歴は、開発の過程を物語ります。
- コミットメッセージは何をしたかが伝わる内容か
- 1つのコミットが適切な粒度か（巨大な1コミットや、意味のない細かすぎるコミットはNG）
- 機能追加、バグ修正、リファクタリングが区別されているか
悪い例：「fix」「update」「修正」のような意味のないコミットメッセージの羅列
良い例：「ユーザー認証機能を追加」「バリデーションエラー時のメッセージ表示を修正」「商品一覧のページネーションを実装」
3. コードの品質
コードそのものの品質も見られています。
- 命名規則が統一されているか
- 適切にファイルやコンポーネントが分割されているか
- 不要なコードやコメントアウトが放置されていないか
- エラーハンドリングが適切か
4. Issues・Pull Requestの活用
IssuesやPull Requestを使っているかどうかで、チーム開発への適性が判断されます。
- Issueでタスクを管理しているか
- PRにはどんな変更を行ったかの説明があるか
- セルフレビューの形跡があるか
一人で開発している場合でも、IssueとPRを使う習慣をつけておくと、「チーム開発の作法を理解している」というアピールになります。
5. 継続的な活動
GitHubのコントリビューショングラフ（草）は、学習の継続性を示します。
- 毎日でなくても、定期的にコミットがあるか
- 直近1〜2ヶ月で活動が途切れていないか
- ポートフォリオ提出前に慌てて大量コミットしていないか
実務レベルのGitHub活用力を身につけて、転職を有利に進めませんか？
未経験者がGitHubで差をつける方法
「でも、未経験者のコードなんて大したものは作れない」と思うかもしれません。実は、コードの高度さよりも、開発プロセスの質の方が評価されます。
実践すべき5つのこと
1. すべてのプロジェクトにREADMEを書く
たとえ小さな学習課題でも、必ずREADMEを書きましょう。
- 何を作ったか（概要）
- なぜ作ったか（目的・背景）
- どう作ったか（技術スタック）
- どう動かすか（セットアップ手順）
この習慣だけで、他の未経験者と大きな差がつきます。
2. ブランチ運用を実践する
一人開発でも、mainブランチに直接コミットするのではなく、feature ブランチを切ってPRを出す運用を実践しましょう。
feature/user-authenticationのようなわかりやすいブランチ名をつける- PRには変更内容の説明を書く
- マージ後にブランチを削除する
3. Issueでタスク管理する
作りたい機能や修正したいバグをIssueとして登録し、それに対応するPRを紐づけます。これだけで、「計画的に開発を進められる人」という印象を与えられます。
4. コミットメッセージに一貫性を持たせる
プレフィックスを使ったコミットメッセージのルールを決めて、統一しましょう。
| プレフィックス | 用途 |
|---|---|
| feat: | 新機能の追加 |
| fix: | バグ修正 |
| docs: | ドキュメントの変更 |
| refactor: | リファクタリング |
| test: | テストの追加・修正 |
| style: | コードフォーマットの変更 |
5. プロフィールREADMEを作成する
GitHubのプロフィールページにREADMEを設定できることを知っていますか。自分のアカウントと同じ名前のリポジトリを作り、README.mdを配置すると、プロフィールページに表示されます。
- 自己紹介（学習中の技術、目指しているキャリア）
- 使用技術のバッジ
- 主要なプロジェクトへのリンク
やってはいけないGitHubの使い方
GitHubの使い方を間違えると、逆にマイナス評価になります。以下は避けるべき行動です。
1. APIキーや認証情報をコミットする
これは最も深刻なミスです。環境変数（.envファイル）に含めるべき情報をコードに直接書いてコミットしてしまうと、セキュリティ意識の欠如と判断されます。
.gitignoreに.envを必ず追加する- 過去のコミットに含まれていないかも確認する
2. スクールの課題をそのまま公開する
教材のコードをそのままコピーしてGitHubに上げている人がいますが、これは評価されません。むしろ、「自分で考えて書いていない」という印象を与えます。
3. 空のリポジトリや中途半端なプロジェクトを放置する
「このリポジトリには何もありません」という状態のリポジトリが並んでいると、途中で投げ出す印象を与えます。使わないリポジトリはArchiveするか削除しましょう。
4. コミットメッセージが雑
「あ」「test」「wip」「.」のようなコミットメッセージは、仕事でのコミュニケーション能力を疑われます。一人で開発していても、「他の人が読む前提」でメッセージを書く習慣をつけてください。
LuaGateのカリキュラム
Git/GitHubを使ったチーム開発を実践的に学べるカリキュラム
Todoアプリポートフォリオの問題点
なぜTodoアプリでは採用で評価されないのか、その理由と対策
TodoアプリとECサイト、ポートフォリオの差
採用担当に評価されるポートフォリオの具体的な作り方
面接で差がつくポートフォリオ戦略
ポートフォリオの作り方と面接合格のコツを解説
転職を考えている方へ
未経験からエンジニアへのキャリアチェンジを実現する方法
未経験からエンジニアを目指す方へ
プログラミング未経験でも大丈夫。ゼロからエンジニアになるロードマップ
GitHubは、あなたのエンジニアとしての姿勢を映し出す鏡です。近道はありません。でも、日々の学習をGitHubに丁寧に記録し続ければ、それ自体が最も説得力のあるポートフォリオになります。
