Unityチーム開発の基本手順：1週間で完成させる「探す」プロジェクト

■ Gitでコミットは、なぜ「1日1回更新」はリスクになるのか

■ おすすめの更新頻度

■ 具体的な運用ルール案（職業訓練校向け）

1. 毎朝・作業前

• 「Pull」してから作業開始
  • GitHub Desktop → Fetch origin → Pull
  • 最新の状態を確認してからUnityを起動。

2. 作業中（1〜2時間に1回）

• 小さな単位でコミット
  • 例）Add player movement, Fix camera follow, Update UI layout
• Unityを閉じる前に「Commit and Push」まで完了。

3. 昼休み・終業前

• Pushして全員の変更を同期
  • これにより、夜間・翌日の作業が安全に始められる。

4. シーンファイルの扱い

• シーンを複数人で編集しない。
• どうしても同じシーンを触る場合はサブシーン分割かブランチ分けを徹底。
  • 例）feature/ui-scene、feature/main-scene

■ 教育的メリット

■ まとめ

• 「1日1回更新」は最低限の安全策にすぎません。
• 実際の開発では、「1〜2時間に1回コミット、1日2〜3回プッシュ」が標準です。
• この粒度で履歴を残すことで、トラブル対応力と実務感覚が大きく向上します。

Unity チーム開発：チーム企画書テンプレート（完全版）

以下のテンプレートは、1週間で進めるUnityチーム開発（テーマ：「探す」）用です。各チームは、この内容を README.md に貼り付けて使用します。

※毎日更新し、進捗・担当・成果を明確に記録します。

# Unity チーム開発課題「探す」

**7日間開発プロジェクト — チーム用 README テンプレート**  
指導講師：小西秀明（職業訓練校 Unity講座）

---

## 目次
- [チーム情報](#team-info)
- [メンバーと役割](#members-and-roles)
- [プロジェクト概要](#project-overview)
- [使用予定のUnity機能](#unity-features)
- [進行スケジュール（目安）](#schedule)
- [進捗メモ](#progress-notes)
- [開発ルール](#development-rules)
- [発表内容（予定）](#presentation-plan)

---

## チーム情報 <a id="team-info"></a>

| 項目 | 内容 |
|------|------|
| **チーム名** | 例：Team C - 光を探せ！ |
| **チームリーダー** | 例：野上 |
| **メンバー** | 例：野上・小上・佐々上・稲上 |
| **リポジトリ名** | 例：`team-c-search` |
| **作成日** | YYYY/MM/DD |

---

## メンバーと役割 <a id="members-and-roles"></a>

| 役割 | 担当 | 主な内容 |
|------|------|----------|
| リーダー・プログラマー | 〇〇 | 探索ロジック実装、Git運用、進行管理 |
| ディレクター / UI・演出 | 〇〇 | 企画構成、UI設計、演出調整 |
| デザイナー | 〇〇 | ステージ構成、背景デザイン、照明設定 |
| QA / サポート | 〇〇 | 動作テスト、README更新、プレハブ管理 |

> ※メンバーが3人の場合は、兼任を明記してください。  
> （例：プログラマー兼UI担当 など）

---

## プロジェクト概要 <a id="project-overview"></a>

| 項目 | 内容 |
|------|------|
| **ゲームタイトル** | 例：光の手がかり |
| **一言で説明すると** | 例：音と光を頼りにアイテムを探す3D探索ゲーム |
| **ゲームの目的** | 例：時間内に隠された宝石を見つけ出す。 |
| **プレイヤー操作** | 例：WASDで移動、スペースで調べる |
| **勝利条件** | 例：制限時間内に全アイテム発見 |
| **失敗条件** | 例：時間切れ・誤探索でポイント減少 |
| **特徴・工夫点** | 例：光・音・ヒント表示を組み合わせた誘導演出 |

---

## 使用予定のUnity機能 <a id="unity-features"></a>

☑ = 使用予定（下記チェックボックスに `[x]` を入れる）  

> 使用予定の機能は `[ ]` を `[x]` に変更してください。  
> 例：  
> `- [x] PlayerController（移動・入力）` → 使用する機能  
> `- [ ] NavMesh / AI` → 今回は使用しない機能

- [ ] PlayerController（移動・入力）  
- [ ] Trigger / Collider  
- [ ] UI（Canvas, Button, TextMeshPro）  
- [ ] ScriptableObject / JSONデータ  
- [ ] アニメーション / DOTween  
- [ ] サウンド（BGM・SE）  
- [ ] NavMesh / AI  
- [ ] Timeline / Cinemachine  
- [ ] その他（　　　　　　　　　　　　　　　　　　　　）

---

## 進行スケジュール（目安） <a id="schedule"></a>

| 日 | 内容 | 主な成果物 |
|----|------|------------|
| 1日目 | チーム結成・企画書作成・Git初期化 | README.md完成 |
| 2日目 | プロトタイプ実装開始 | プレイヤー移動・探索判定 |
| 3日目 | UI・探索対象の追加 | 画面構成確定 |
| 4日目 | ステージ・演出・サウンド統合 | 初期プレイテスト |
| 5日目 | 中間発表・改善 | 改良版動作確認 |
| 6日目 | デバッグ・最終調整 | 完成版 |
| 7日目 | 発表会 | プレゼン＋作品公開 |

---

## 進捗メモ <a id="progress-notes"></a>

| 日付 | 作業内容 | 担当 | 備考 |
|------|-----------|------|------|
| 10/○ | プロトタイプ作成開始 | 野上 | プレイヤー操作OK |
| 10/○ | 探索ロジック追加 | 小上 | 当たり判定テスト中 |
| 10/○ | UI仮組み | 佐々上 | Canvas設計 |
| ... | ... | ... | ... |

> ※ 毎日、各メンバーが更新してください。  
> GitHubのコミット履歴に残る形で進捗を記録します。

---

## 開発ルール <a id="development-rules"></a>

- **Git運用**  
  - 1〜2時間ごとにCommit  
  - 1日2〜3回Push  
  - 作業前に必ず「Pull」して最新を取得  
  - コンフリクトが起きた場合はリーダーが調整  

- **Unityプロジェクト設定**  
  - Unity 6（URP）を使用  
  - 各自、同バージョンを統一  
  - 不要アセットは追加しない（軽量管理）  

- **フォルダ構成推奨**
```
Assets/
├─ Scripts/
├─ Prefabs/
├─ Scenes/
├─ UI/
└─ Audio/
```
---

## 発表内容（予定） <a id="presentation-plan"></a>

| 項目 | 内容 |
|------|------|
| **タイトル** | （例）光の手がかり |
| **ゲーム紹介** | （例）音・光・時間を頼りに宝を探す探索アクション |
| **アピールポイント** | （例）演出と探索を融合した独自のUI設計 |
| **担当箇所で頑張った点** | （例）DOTweenを活用した演出とUIの統一感 |
| **発表担当** | （例）リーダーが操作、全員でコメント補足 |

---

> **目的**  
> このREADMEは「開発ドキュメント」としてチーム全員が更新することを目的としています。  
> 完成よりも「考え方・工夫・チーム連携の過程」を重視してください。

---

© 2025 職業訓練校 Unity講座（講師：小西秀明）

使用方法のポイント

• GitHubリポジトリのルートに README.md を作成し、上記内容をコピーして保存。
• 1日ごとに更新して、進捗・発見・変更点を明記。
• 発表時にはこのREADMEがプレゼン資料にもなります。
• .gitignore はUnity公式テンプレートを使用してください。