就活に向けたGitHubポートフォリオ整備ガイド

広告

就職活動が近づいてきたとき、「GitHubを整えよう」と思っても何をどう直せばいいかわからない人は多いです。

このガイドでは、採用担当者が実際にGitHubを見るときの視点から、就活に向けてやるべきこと・避けるべきことを具体的にまとめました。

⚠️ このガイドは「就職活動用のポートフォリオ整備」に特化しています。授業内発表会の準備はUnity個人制作①発表会ガイドを参照してください。

採用担当者はGitHubの何を見ているか

採用担当者が最初に確認するのはREADMEです。コードを全部読む時間はないため、READMEの完成度が第一印象を大きく左右します。

続いて確認するのがcommitの履歴です。「継続して開発しているか」「commitメッセージから何をしたか読めるか」が評価対象です。

最終的に確認されるのがコードの中身です。ただしここまで読んでもらうためには、READMEとcommit履歴で「読む価値がある」と思わせる必要があります。

READMEに書くべきこと

就活用READMEで優先度が高い項目は次の通りです。

項目内容
プロジェクト概要何を作ったか・なぜ作ったか
使用技術言語・エンジン・ライブラリ・ツール
動作確認環境OS、Unityバージョンなど
起動・プレイ方法ビルド版の場所、操作方法
工夫したポイント技術的に挑戦した部分（「なぜ・どんな効果」まで）
苦労した点と解決策エラー1つとその解決プロセス
今後の改善点成長意欲を示す

工夫したポイントの書き方

技術名を並べるだけでは評価されません。

❌ 悪い例✅ 良い例
ScriptableObjectを使いましたデータをScriptableObjectで管理することで、コードを変更せずにゲームバランスを調整できるようにしました
DOTweenを使いましたDOTweenでアイテム取得時の拡大アニメーションを追加し、プレイヤーへのフィードバックを強化しました

「何を・なぜ・どんな効果」の3点で書くことを意識してください。

commitの考え方

現場とズレやすいポイント

「1〜2時間ごとにcommitする」という時間ベースのルールは学習中の目安です。採用担当者や現場エンジニアが重視するのはcommitの内容と質です。

就活で評価されるcommitの例：

feat: プレイヤーの移動処理を実装（Rigidbody使用）
fix: NullReferenceException を修正（PlayerController の null チェック追加）
refactor: EnemyController をコンポーネント分割
docs: README に操作方法を追記

避けるべきcommitの例：

修正 / あ / 完成版 / いろいろ / test / 作業中

大切なのはこの2点

  1. 作業した日はcommitする — 毎日でなくてもよいが、作業した日は必ず残す
  2. 1commitに1つの意味 — 機能追加とバグ修正を同じcommitにまとめない

ブランチについて

個人制作ではmainブランチへの直接commitで構いません。ただし、新しい機能を追加するときはbranchを切る習慣をつけておくと、実務感が伝わります。

GitHub Desktop でのブランチ操作手順

  1. 画面上部の Current Branch をクリック → New Branch
  2. ブランチ名を入力（例：feature/enemy-ai）して作成
  3. そのブランチで開発・commitを続ける
  4. 完成したら Current Branch → main に切り替え
  5. メニュー Branch → Merge into Current Branch → 作ったブランチを選択

commitの接頭辞（feat: fix: docs:）と合わせて使えると、採用担当者に「チーム開発を意識している」印象を与えます。

AIツール活用の示し方

ChatGPT・Claude・CopilotなどでAIを使って開発した場合、それを隠す必要はありません。むしろ使いこなした過程を示すことがアピールになります。

READMEや発表の中に次のような一文を入れられると評価されます。

「敵AIの移動ロジックはClaude Codeを使って生成し、実際に動作確認して不要な処理を削除・整理しました」

「AIを使った」だけでなく、「出力を理解して判断した」という部分を見せることがポイントです。

就活用GitHubで避けること

避けること理由
commitが最終日だけに集中している継続的に開発していないと判断される
READMEが空・最小限第一印象で読む気を失わせる
commitメッセージが「修正」「変更」のみ何をしたか伝わらない
アセットに依存しているのに自分で実装したように書く後で説明できず信頼を失う

就活前チェックリスト

README

  • 概要（何を・なぜ作ったか）が1〜2文で書いてある
  • 使用技術が列挙されている
  • 工夫したポイントが「なぜ・どんな効果」まで書かれている
  • 苦労した点と解決策が書かれている
  • 起動方法・操作方法が書かれている

Git

  • 制作期間中、複数の日付にわたってcommitがある
  • commitメッセージが内容を表している（feat: fix: など）
  • commitが最終日だけに集中していない

全体

  • リポジトリがpublicになっている
  • ビルド済みexeがReleasesに登録されている（Unityの場合）
  • 説明なしに他者が見て内容が伝わるか確認した

まとめ

就活でGitHubが見られるのは「コードが書けるか」を確認するためだけではありません。

「整理して伝える力があるか」「継続して取り組めるか」「自分の判断で動けるか」

これらを採用担当者はGitHubを通じて読もうとしています。完成度より、作ったプロセスが見えるGitHubを目指してください。

訪問数 7 回, 今日の訪問数 7回

広告

Git

Posted by hidepon