チーム開発で初学者がやりがちなこと【Unity×Git編】

はじめに

個人制作では問題にならなかった作業のクセが、チーム開発になると一気にトラブルの火種になります。

特にUnityでは、シーンやPrefabの扱い方、Gitとの連携方法を誤ると、せっかく進めた作業が競合や上書きで失われてしまうことがあります。

この記事では、授業や現場で実際に起きやすい「初学者がやりがちなこと」と、それを防ぐための実践的な対策を整理します。

1. シーンを同時に編集して競合

Unityのシーンファイル（.unity）やPrefab（.prefab）は、現在では YAML形式（テキスト形式） で保存されます。

そのためGit上で差分を見ることは可能ですが、内部には膨大なオブジェクトIDや構造情報が含まれており、人間が安全にマージできるほど単純ではありません。

複数人が同じシーンを同時に編集すると、変更箇所が重なってマージ不能になり、最悪どちらかの作業を破棄することになります。

対策

  • シーンの担当を明確に分ける（例：MainSceneはAさんのみ）
  • 共通UIやオブジェクトはPrefab化して分担編集
  • メインシーンの編集は1人に限定する

※YAML形式でも「安全にマージできる」とは限りません。実質的には「テキスト化されたバイナリ」と考えて運用しましょう。

2. Pullを忘れてPushして競合

「Pushできない！」「エラーが出た！」

Gitの基本操作で最も多いミスです。

他の人の変更を取り込まずに自分の変更をPushしようとすると、リモートとローカルの内容が食い違ってエラーになります。

対策

  1. 作業前に必ず Pull
  2. 作業後に Commit → Push
  3. 競合が出たら自己判断せずリーダーに報告

GitHub Desktopでは「Fetch origin → Pull origin」をこまめに押す習慣をつけましょう。

3. Libraryフォルダをコミットしてしまう

Library フォルダはUnityが自動生成するキャッシュデータであり、他のメンバーと共有する必要はありません。

これをPushすると、リポジトリが数GBに膨れ上がり、CloneやPush/Pullが極端に遅くなります。

対策

.gitignore に以下を必ず記述：

/Library/
/Temp/
/Logs/
/Obj/
/Build/

クローン直後に .gitignore が正しく設定されているか確認しましょう。

4. Prefabを直接シーンで修正して混乱

シーン上のPrefabインスタンスを直接修正すると、他のメンバーの環境では変更が反映されず、Prefabとシーンがズレます。

また、作業中に「ついでにここも直そう」と仕様を途中で盛ってしまう ケースも多く、これがチーム混乱の原因になります。

対策

  • Prefabモードで編集する（Apply不要）→ Prefab Assetそのものを開いて編集すれば、自動的に反映される
  • シーン上のPrefabを変更した場合はApplyを押す（明示的に反映）
  • 仕様を変えたくなった場合は、必ず共有・承認を得てから実装

個人制作では柔軟さが強み、チーム制作では一貫性が最優先です。

5. クローン直後に大量の差分が出る

Unityのバージョンや改行コード設定が異なると、

クローン直後に大量のファイルが「変更あり」と表示されることがあります。

対策

  • 同一のUnityバージョンを全員で使用（例：6000.2.9f1）
  • .gitattributes に以下を追加して改行コードを統一
* text=auto
  • クローン直後の「変更検出」は、まずDiscard（破棄）してから作業開始

6. Push前にPlay確認していない

「小さな修正だから大丈夫」と思ってPushした結果、他のメンバーの環境でエラーを出すことがよくあります。

対策

  • Push前に必ずPlay実行
  • ConsoleにWarningやErrorが出ていないか確認
  • SerializeFieldや変数名を変更した際は特に注意

7. 命名やフォルダ構成がバラバラ

命名やフォルダ構成に統一性がないと、「どれが最新？」「同じ機能が2つある」などの混乱が起きます。

対策

  • スクリプト名＝クラス名を統一
  • Prefab・Script・Sceneを機能別に整理
  • 命名規則と構造をREADMEで共有

例：

Assets/
 ├─ Scripts/
 │   ├─ Player/
 │   └─ Enemy/
 ├─ Prefabs/
 │   ├─ UI/
 │   └─ Stage/
 └─ Scenes/

8. 他人のブランチを直接編集

mainや他人のブランチを直接編集すると、作業内容が上書きされてトラブルになります。

対策

  • 作業前に自分のブランチを確認
  • ブランチ名は feature/名前_機能例：feature/konishi_inventory_ui
  • mainブランチの更新はPull Request経由のみ

9. 警告や競合を無視

警告や競合メッセージを読まずに進めると、問題が大きくなってから発覚します。

対策

  • ConsoleやGitのメッセージを読む癖をつける
  • 意味が分からない場合はSlackで共有
  • 「自分以外も出ていないか」を確認する

10. 仕様を途中で盛る

チーム制作では「自分の好み」や「思いつき変更」は危険です。

見た目や挙動を勝手に変えると、他メンバーの動作確認やUI整合性が崩れます。

対策

  • 仕様変更はSlackで提案・承認後に実装
  • 変更履歴をREADMEに追記
  • 「良かれと思って」はチームではトラブルの元

勝手な改良は“バグの温床”。意図の共有こそが品質管理です。

11. 意思疎通不足

最終的に多くのトラブルは「報告・連絡・相談の不足」から発生します。

対策

  • 毎朝／毎夕に進捗共有
  • Slack・コメント・Issueを活用
  • 「自分の変更を説明できる」状態を意識する

まとめ

チーム開発では、個々の技術力よりもルール・報告・整合性の維持が成功の鍵です。

YAMLで保存されるUnityプロジェクトはGit管理と相性が良い一方、同時編集や独断的変更には非常に弱い構造です。

コードを書く力よりも、チームで開発を「壊さず進める力」を身につけましょう。

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

Git,Unity,バージョン管理,便利機能

Posted by hidepon