「動く作品」だけでは足りない時代へ ～GitHub・Git履歴・Pull Request が見られる理由～
ゲームやアプリを作ったあと、「完成しました！」と提出するだけで十分だった時代もありました。
ですが現在は、
- どう作ったか
- どのように成長したか
- チーム開発できるか
も重視されるようになっています。特に就職活動では、GitHub を見る企業が増えています。
なぜ GitHub を見るのか？
企業は、「この人は本当に開発できる人か？」を知りたいからです。
完成品だけでは、実は分からないことがあります。例えば：
- AIで作ったのか
- 他人のコードをコピーしたのか
- 自力で直したのか
- 少しずつ理解しながら成長したのか
完成したゲームだけでは判断できません。しかし GitHub には：
- コミット履歴
- 修正の流れ
- エラー修正
- README
- branch運用
などが残ります。つまり「開発の足跡」が見えるのです。
Git履歴で見えるもの
例えば次のような履歴が残っていると、「少しずつ積み上げている」ことが伝わります。
5/10 プレイヤー移動実装
5/11 当たり判定追加
5/12 バグ修正
5/13 UI追加これは実務でも非常に重要です。
逆に危険なパターン
一方、こうした履歴だと「本当に作ったのかな？」と思われることがあります。
最初のコミット
完成版（最終）特に現在は生成AI（ChatGPT・Claude・Cursorなど）でコード生成ができてしまうため、「理解しながら開発している」証拠がより重要になっています。
Pull Request とは？
Pull Request（PR）は、「この変更を取り込みませんか？」という提案です。
例えば feature/player-move というbranchを作り、プレイヤー移動追加・バグ修正・UI変更などを行ったあと、「main に取り込んでください」と提案する。これが Pull Request です。
なぜ Pull Request が重要？
実際の現場では、「いきなり main を変更」することはほとんどありません。理由は：
- バグを防ぐ
- 他人が確認できる
- 品質を維持する
- 変更内容を説明できる
ためです。つまり PR は「チーム開発の基本」なのです。
Unityでも Git は重要
Unityでも Git はかなり使われています。特にチーム制作・個人制作・就職ポートフォリオ・インディーゲーム開発では一般的です。シーン追加、スクリプト修正、Prefab変更、UI更新など、あらゆる変更の履歴を管理できます。
GitHub Desktop から始めよう
Gitにはコマンド操作もありますが、最初のうちは GitHub Desktop を使うのがおすすめです。画面で操作できるため、Gitの概念を理解しながら無理なく始められます。
まずは Commit・Push・Pull・Branch の4つの操作に慣れることが大切です。コマンドはそのあとでも十分間に合います。
採用担当が見ている可能性があるポイント
企業によって違いますが、例えば以下のような点を確認することがあります。
- READMEがあるか
- 継続的に更新しているか
- コミットメッセージが分かりやすいか
- Git履歴が自然か
- branchを使っているか
- Pull Request経験があるか
大切なのは「上手さ」より「積み重ね」
最初から完璧なコードを書く必要はありません。むしろ試行錯誤・修正・バグ対応・学習の跡が見える方が自然です。Git は「失敗を記録する道具」でもあります。
まとめ
現在の開発では、「作品だけ」ではなく「どう開発したか」も重要になっています。GitHubは、学習履歴・成長過程・開発姿勢・チーム適性を見せることができる強力な道具です。
- スティーブ・ジョブズは徹底したリハーサルを行っていた
- Commit・Branch・Pull Request・README を少しずつ覚えていくことには大きな意味がある
- 完成品だけでなく「開発の過程」も大切にしていこう
完成品だけでなく、「開発の過程」も大切にしていきましょう。