Unity個人制作①発表会 — 完全攻略ガイド
対象： Unity個人制作①の受講生
発表準備日： 6/2（火）
発表会： 6/3（水）
はじめに — 発表で本当に問われていること
「ゲームを完成させる」だけが目標ではありません。
個人制作の発表会では、「自分が何を考えて作ったか」を相手に伝える力も同じくらい重要です。発表は面接・ポートフォリオ・チーム開発・将来の説明資料にもつながる実践的な練習です。
良い発表 ＝ 「すごいゲーム」ではなく、「作った人の考えが伝わる発表」
評価の5つの柱
発表は以下の5つの観点で評価されます。それぞれにGitの要素が組み込まれています。
| 柱 | 発表で話すこと | 見せるもの |
|---|---|---|
| 1. 動くこと | 基本機能の説明・デモ | ゲーム実演 or 動画 or ビルド済み exe |
| 2. 完成していること | Level 0→1→2 の到達過程 | README の完成度レベル + commit 履歴 |
| 3. 期限を守ること | 制作期間中の進め方 | commit のタイムスタンプ分布 |
| 4. 修正できること | エラー1つと解決方法 | README エラーログ + fix: commit |
| 5. 人に説明できること | 開発の流れを時系列で説明 | GitHub の commit 履歴 |
スライド構成（5〜8枚）
⚠️ 以下の構成はあくまでサンプルです。
自分のゲームや伝えたいことに合わせて、枚数・順番・内容は自由にカスタムしてください。
大切なのは「評価の5つの柱」が伝わること。構成の正解は1つではありません。
「短く・伝わりやすく」を意識してください。文章を長く書きすぎず、スクリーンショットを大きく載せると効果的です。
1枚目：タイトル
ゲームタイトル・制作者名・ジャンル・一言説明を記載します。
Dungeon Escape
制作者：山田太郎
2Dアクションゲーム
「鍵を集めて脱出を目指すゲーム」
2枚目：ゲーム概要
どんなゲームか・操作方法・クリア条件。スクリーンショットを大きく配置してください。
3枚目：制作目的
「なぜこのゲームを作ったのか」を書きます。
- Unityの物理演算を練習したかった
- UI制作を学びたかった
- 敵AIを作ってみたかった
4枚目：工夫したポイント
技術名を並べるだけでは不十分です。「何を・なぜ・どんな効果」の3点セットで書いてください。
| ❌ 悪い例 | ✅ 良い例 |
|---|---|
| DOTween を使いました | DOTween を使用して、アイテム取得時に拡大アニメーションを追加し、達成感を強化しました |
5枚目：苦労した点・エラー解決
問題が起きなかったことより、**「問題をどう解決したか」**が重要です。よくある例：
- NullReferenceException が発生した
- シーン遷移後にプレイヤー位置が戻ってしまった
- Git の競合が発生した
解決策まで書きましょう。README のエラーログと Git の fix: commit が対応していると説得力が増します。
DontDestroyOnLoad の影響で古いオブジェクトが残っていたため、
シーン切り替え時に初期化処理を追加しました
6枚目：システム構成
クラス構成や画面遷移を図で示すと伝わりやすくなります。
GameManager
├ Player
├ EnemyManager
├ UIManager
└ AudioManager
Title → Game → Result
7枚目：プレイ画面・動画
発表本番では緊張・操作ミス・バグが発生することがあります。動画を保険として必ず用意してください。
8枚目：まとめ
- 学んだこと
- 今後追加したい機能
- 次回改善したい点
9枚目：使用技術・アセット一覧
- 使用技術一覧（C# / Unity / Input System / DOTween / ScriptableObject / Animator / GitHub Desktop / UI など）
- 使用アセット
発表の流れ（8〜10分）
| 順番 | 時間 | 内容 |
|---|---|---|
| 1 | 1分 | タイトル・ゲーム概要（何のゲームか、操作） |
| 2 | 2分 | 制作目的・工夫したポイント |
| 3 | 1.5分 | 苦労した点・エラーと解決 |
| 4 | 2〜3分 | デモ or 動画（ゲームを見せる） |
| 5 | 1分 | Git 履歴を見せながら開発の流れ |
| 6 | 30秒〜1分 | まとめ・今後追加したいこと |
1. タイトル・ゲーム概要（1分）
ここは「相手を迷わせない」が最重要です。
例えば：
- ジャンル
- 目的
- 操作方法
- 何をすると楽しいか
を簡潔に。
悪い例：
「2Dゲームを作りました」
良い例：
「敵を避けながら鍵を集めて脱出する
ステルスアクションゲームです」
ここで世界観が伝わると、
後半が理解しやすくなります。
2. 制作目的・工夫したポイント（2分）
ここは最重要です。
発表で一番価値があります。
例えば：
- ScriptableObjectを使った
- Observerパターンを使った
- セーブ機能を作った
- InputSystemに対応した
- DOTweenで演出した
- UIを見やすくした
など。
単なる機能紹介ではなく、
「なぜそれを採用したか」
まで話せると強いです。
3. 苦労した点・エラーと解決（1.5分）
これは実務感が出ます。
面接でもかなり重要。
例えば：
- NullReferenceException
- Git競合
- シーン遷移
- アニメーション同期
- InputSystem
など。
重要なのは、
「どう調べて解決したか」
です。
ここで：
- ChatGPT
- 公式ドキュメント
- YouTube
- クラスメイト
などをどう活用したかも話せます。
4. デモ or 動画（2〜3分）
ここは長めが良いです。
実際、
聞いている側は
「動いているところ」
が一番印象に残ります。
特に：
- 演出
- アニメーション
- サウンド
- UI
は動画が強い。
また、
万一のために、
- 動画を先に用意
- 実機デモ失敗時は動画へ切替
が安全です。
5. Git履歴を使った開発の流れ（1分）
これはかなり実務的です。
特に：
- commit履歴
- 段階的開発
- issue対応
が見えると、
「本当に作った感」
が出ます。
ただし長くなりやすいので1分程度が良いです。
6. まとめ・今後追加したいこと（30秒〜1分）
最後は未来志向。
例えば：
- ステージ追加
- 難易度調整
- セーブ機能改善
- マルチプレイ
- スマホ対応
など。
ここで：
「今後も改善したい」
を見せると、
成長性が伝わります。
Git 履歴を「発表の証拠」にする
発表では、GitHub の commit 履歴を画面に映して以下の3点を説明してください。
1. 制作の流れを時系列で話す
例：「5/18 にプロジェクト作成 → 5/20 に移動実装 → 5/25 に UI 追加 → 6/2 に最終調整」2. エラーと解決をコミットと紐づけて話す
例：「5/22 に NullReferenceException が出た。README のエラーログに書いた通り、
PlayerController の null チェックを追加して fix commit した」3. Git で戻せる具体例を1つ話す
例：「UI が崩れる前の状態に戻すなら、
この commit（5/24 feat: タイトル画面追加）に戻せます」良い commit 履歴の例
feat: プレイヤーの左右移動を実装
feat: 敵キャラの生成処理を追加
fix: NullReferenceException（PlayerController）
docs: README の進捗メモを更新（5/21）
feat: タイトル画面と BGM を追加
fix: ゲームオーバー後にリスタートできない問題を修正→ いつ・何を・なぜ が第三者にも伝わります。
❌ 避けてほしい履歴
修正 / あ / 完成版 / いろいろ / testGit 運用ルール
| ルール | 内容 |
|---|---|
| Commit の頻度 | 1〜2時間ごと、または「1機能が動いたら」 |
| Push の頻度 | 1日 2〜3回 |
| 作業前 | 必ず git pull して最新を取得 |
| メッセージ | 内容がわかる日本語 or 英語（接頭辞推奨） |
コミットメッセージの接頭辞
| 種類 | 接頭辞 | 例 |
|---|---|---|
| 新機能 | feat: | feat: タイトル画面を追加 |
| バグ修正 | fix: | fix: NullReferenceException を修正 |
| リファクタ | refactor: | refactor: PlayerController を整理 |
| ドキュメント | docs: | docs: README の進捗メモを更新 |
README を「発表の裏付け」にする
README は単なる説明書ではありません。整理力・設計力・伝達力の高さを示すものです。
最低限書くべき内容：
- 概要（どんなアプリか）
- 使用技術
- 起動方法（どのシーンから起動するか）
- 操作方法
- フォルダ構成
- 制作担当（名前）
- 今後の課題
| README のセクション | 発表での使い方 |
|---|---|
| プロジェクト概要 | スライド2枚目（ゲーム概要）の元ネタ |
| 完成度レベル | 「Level 0→1→2 の到達」を commit 履歴と合わせて説明 |
| 進捗メモ | 制作期間中の歩みを時系列で話す |
| エラーログ | スライド5枚目（苦労した点）+ Git の fix: commit |
README の進捗メモ・完成度レベルと、Git の履歴が一致していると説得力が大幅に増します。
Unity Recorder でプレイ動画を用意する
発表本番で操作ミスやバグが出ても、動画があれば安心です。
動作確認バージョン： Unity 6 / Recorder 5.1.6
インストール手順
[Window]→[Package Management]→[Package Manager]- Recorder を検索してインストール
録画手順
[Window]→[General]→[Recorder]→[Recorder Window]を開く- Add Recorder → Movie Recorder を選択
- 形式：MP4、保存先：
Recordings/、ファイル名：movie_001.mp4のように設定 - 赤い録画ボタン（または F10 ショートカット）で開始
- Game ビューをクリックしてゲームをプレイ
- STOP RECORDING で停止 → 自動保存
解像度エラーが出る場合： Output Resolution が Match Window Size でエラーになる場合は、他の解像度を選択するか、Game ビューで解像度を先に定義してください。
動画の内容（1〜3分）：
タイトル画面 → ゲーム開始 → 代表的なプレイ → クリア or ゲームオーバー
ビルド済み exe の用意（必須）
Unity Editor が起動できない・重い場合の保険として必ず用意してください。
ビルド手順：
[File]→[Build Settings]を開く[Add Open Scenes]で必要なシーンを登録- Platform を Windows に設定
[Build]をクリックして保存先を指定
生成されるもの：
Build/MyGame/
├ MyGame.exe ← 実行ファイル
└ MyGame_Data/ ← このフォルダも必須（exe とセット）⚠️
.exeだけコピーしても動きません。_Dataフォルダごと一式で保管してください。
確認： Unity Editor を閉じた状態で .exe をダブルクリックし、タイトル〜基本操作が問題なく動くことを確認してください。
発表当日の流れ
開いておくタブ・ウィンドウ（4つ）：
- プレゼン資料（スライド）
- Unity（タイトル画面で待機）または ビルド済み exe
- GitHub リポジトリ（README タブ + commit 履歴タブ）
- プレイ動画（mp4）
デモの優先順位：
- Unity Editor で Play モード
- ビルド済み exe（Editor が重い・エラーが出る場合）
- プレイ動画（上記も不可のときの最終手段）
デモが失敗しても慌てず「ビルド版 / 録画を用意してあるので、こちらで見せます」と一言添えて切り替えてください。
試遊会のローテーションルール
発表会では、全員が「プレイヤー」と「制作者」の2つの役割を交互に担います。
3つのポイント：
① 全員が2つの役割を持つ
プレイヤーは他の人の席へ移動して遊びます。制作者は自分の席を守り、来た人がREADMEと画面説明を読んで自分でゲームを遊びます。自分の作品は自分では遊びません。
② 毎ウェーブ +1 席ずれる
11ウェーブで全11作品を1回ずつ遊びます。⑫の次は①に戻ります。
③ 1ウェーブ = 8分の流れ
まず README とコミット履歴を読む（0〜2分）→ 試遊（6分）→ ベルの合図で終了・自席に戻ってリセット
制作者として自席にいる間は、来た人が README と画面説明を読んで遊べる状態を保っておきましょう。
よくある失敗と対策
| 失敗 | 対策 |
|---|---|
| 文章が多すぎる | スライドは箇条書き＋大きなスクショ。詳細は口頭で |
| スクリーンショットが小さい | ゲーム画面はスライドの半分以上を占めるサイズに |
| 技術名だけ並べる | 「何を・なぜ・どんな効果」の3点セットで書く |
| 発表中に GitHub の画面を開いていない | 必ず GitHub を開いて commit 一覧を画面共有 |
| デモだけに頼る | ビルド済み exe と Unity Recorder の mp4 を必ず用意 |
| ビルド後に _Data フォルダを同梱せず提出してしまう | _Data フォルダもセットで zip 化してアップする。Editor を閉じた状態で起動確認 |
| 発表前に README の内容を確認・更新していない | 発表前に README の「発表内容（予定）」を完成させる |
| 最終日だけ commit | 6/2 までに README・コードを push 済みにしておく |
提出前チェックリスト（6/2 に確認）
提出物
- [ ] GitHub リポジトリ URL が README に記載されている
- [ ] 指導講師が Collaborator として追加されている
- [ ] 最終版が期限内に push されている
- [ ] ビルド済み exe（
_Dataフォルダ含む）を用意し、Unity なしで起動確認済み
Git
- [ ] 制作期間中、複数回の commit がある（最終日だけではない）
- [ ] 各 commit メッセージが内容を表している
- [ ] README の進捗メモが毎日更新されている
- [ ] エラーログに、実際に遭遇したエラーと解決方法が書かれている
発表
- [ ] プレゼン資料（5〜8枚）が完成している
- [ ] プレイ動画（mp4、1〜3分）を用意した
- [ ] README の「発表内容（予定）」セクションを埋めた
- [ ] コミット履歴を見せながら開発の流れを説明するリハーサルを1回以上した
まとめ
プログラミング学習では「動いた！」に目が向きがちです。
しかし発表では 「他人が理解できるか」「自分の考えが伝わるか」 を意識してください。コードを書く力と、伝える力の両方が、エンジニアの重要なスキルです。
参考資料
| 記事 | URL |
|---|---|
| 個人制作 発表資料の作り方 | https://soft-rime.com/post-28431/ |
| Unity Recorder で録画 | https://soft-rime.com/post-3497/ |
| なぜ README.md が必要なのか | https://soft-rime.com/post-28440/ |
| Git 活用 評価基準 | https://soft-rime.com/post-28449/ |
| GitHubを使ったUnityアプリのリリース版作成 | https://soft-rime.com/post-2503/ |
| PowerPoint for Web（ウェブ版PowerPoint）の使い方 | https://soft-rime.com/post-20051/ |
| 個人制作① READMEテンプレート | https://github.com/hidepon4162/unity-course-materials/blob/main/templates/%E5%80%8B%E4%BA%BA%E5%88%B6%E4%BD%9C%E2%91%A0_README%E3%83%86%E3%83%B3%E3%83%97%E3%83%AC%E3%83%BC%E3%83%88.md |