個人制作発表会ガイド

2026年5月29日2026年6月8日

このガイドは、Unityを使った個人制作の成果を発表する「Unity 発表会」に向けた実践的な手引きです。専門学校でプログラミングを学び始めた方にも参考になるよう、準備から当日の進め方まで具体的に解説しています。

対象： 個人制作の受講生
発表準備日： 発表数日前
発表会： 発表当日

はじめに — 発表で本当に問われていること

「ゲームを完成させる」だけが目標ではありません。

個人制作の発表会では、「自分が何を考えて作ったか」を相手に伝える力も同じくらい重要です。発表は面接・ポートフォリオ・チーム開発・将来の説明資料にもつながる実践的な練習です。

良い発表 ＝ 「すごいゲーム」ではなく、「作った人の考えが伝わる発表」

評価の5つの柱

発表は以下の5つの観点で評価されます。それぞれにGitの要素が組み込まれています。

※ 採用で見られる点：未経験採用では、技術力そのものよりも学習意欲・継続力・主体性・言語化力が見られます。柱1・2＝最後まで完成させる力、柱3＝期限を守る就業姿勢、柱4＝自分で調べて解決する力、柱5＝相手に伝える力、と対応しています。

※ 完成度レベルの目安：Level 0＝コア機能が動く（例：自機が動いて攻撃し、敵を倒せる）／Level 1＝ゲームの体裁が整う（例：タイトル・BGM・SE・リスタート）／Level 2＝一連の流れが完成（例：アイテム・ボス・クリアまで）。具体的な定義は、各自のゲームに合わせて README テンプレートの「完成度レベル」で設定します。

スライド構成（5〜8枚＋付録）

⚠️ 以下の構成はあくまでサンプルです。
自分のゲームや伝えたいことに合わせて、枚数・順番・内容は自由にカスタムしてください。
大切なのは「評価の5つの柱」が伝わること。構成の正解は1つではありません。

「短く・伝わりやすく」を意識してください。文章を長く書きすぎず、スクリーンショットを大きく載せると効果的です。

1枚目：タイトル

ゲームタイトル・制作者名・ジャンル・一言説明を記載します。

Dungeon Escape
制作者：山田太郎
2Dアクションゲーム
「鍵を集めて脱出を目指すゲーム」

2枚目：ゲーム概要

どんなゲームか・操作方法・クリア条件。スクリーンショットを大きく配置してください。

3枚目：制作目的

「なぜこのゲームを作ったのか」を書きます。

• Unityの物理演算を練習したかった
• UI制作を学びたかった
• 敵AIを作ってみたかった

4枚目：工夫したポイント

技術名を並べるだけでは不十分です。「何を・なぜ・どんな効果」の3点セットで書いてください。

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分）

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: ゲームオーバー後にリスタートできない問題を修正

→ いつ・何を・なぜ が第三者にも伝わります。

❌ 避けてほしい履歴

修正 / あ / 完成版 / いろいろ / test

Git 運用ルール

コミットメッセージの接頭辞

📌 上記のGit運用ルール（commit頻度・push頻度）は授業内の目安です。就職活動でGitHubをポートフォリオとして整える場合は、採用担当者の視点で見直しが必要です。
→ 就活に向けたGitHubポートフォリオ整備ガイド

README を「発表の裏付け」にする

README は単なる説明書ではありません。整理力・設計力・伝達力の高さを示すものです。

最低限書くべき内容：

• 概要（どんなアプリか）
• 使用技術
• 起動方法（どのシーンから起動するか）
• 操作方法
• フォルダ構成
• 発表内容（予定）
• 制作担当（名前）
• 今後の課題
• 進捗メモ（制作期間中の記録）
• エラーログ（遭遇したエラーと解決方法）

README の進捗メモ・完成度レベルと、Git の履歴が一致していると説得力が大幅に増します。

Unity Recorder でプレイ動画を用意する

発表本番で操作ミスやバグが出ても、動画があれば安心です。

動作確認バージョン： Unity 6 / Recorder 5.1.6

インストール手順

1. [Window] → [Package Management] → [Package Manager]
2. Recorder を検索してインストール

録画手順

1. [Window] → [General] → [Recorder] → [Recorder Window] を開く
2. Add Recorder → Movie Recorder を選択
3. 形式：MP4、保存先：Recordings/、ファイル名：movie_001.mp4 のように設定
4. 赤い録画ボタン（または F10 ショートカット）で開始
5. Game ビューをクリックしてゲームをプレイ
6. STOP RECORDING で停止 → 自動保存

解像度エラーが出る場合： Game ビューのアスペクト比が Free Aspect など可変設定だとエラーになります。Game ビューを固定解像度（例: 1920×1080）に設定してから録画してください。

動画の内容（1〜3分）：
タイトル画面 → ゲーム開始 → 代表的なプレイ → クリア or ゲームオーバー

アプリのリリース版（発表バージョン）作成（必須）

発表前々日中（準備日の前日）にビルド版を完成させ、GitHubに登録しておきましょう。直前まで調整を続けると動作確認の時間がなくなるため、期限を決めて作業を切り上げることが大切です。

ビルド済み exe の用意

このガイドは Windows 環境を前提にしています。Mac で制作している場合： .exe は Windows 専用です。発表・試遊は Windows PC で行うため、Unity Hub で Windows Build Support（IL2CPP）モジュールを追加し、Build Settings の Platform を Windows に切り替えてからビルドしてください（Mac の .app は Windows では起動しません）。

1. Unity Editor で File → Build Settings を開き、Platform が Windows になっていることを確認してから Build を実行する
2. ビルド後、出力フォルダに ゲーム名.exe・ゲーム名_Data フォルダ・UnityPlayer.dll など複数のファイルが生成される（Unity 6 では IL2CPP のため .exe 単体では動かない）。出力フォルダの中身を丸ごと zip 化すること（一部だけでは起動しない）
3. Unity Editor を閉じた状態で .exe をダブルクリックし、タイトル〜基本操作が問題なく動くことを確認する

GitHub でリリース版を登録

1. GitHub リポジトリページを開き、右側の Releases → Create a new release をクリック
2. Choose a tag に v1.0 などのタグ名を入力して作成する
3. タイトルに「発表バージョン」など分かりやすい名前を付ける
4. Attach binaries 欄に作成した zip ファイルをドラッグ＆ドロップしてアップロード
5. Publish release をクリックして完了

提出前に、GitHub リポジトリの Settings → Collaborators → Add people から指導講師を招待してください（招待先のアカウント名は Slack の案内を参照）。

詳しい手順は以下の記事も参考にしてください。

GitHubを使ったUnityアプリのリリース版作成

プログラム作成を進めていき、リリースできるバージョンに達した時、この作業でリリース版を管理してい ...

 https://soft-rime.com/post-2503/

リリース後のアプリ修正・機能追加はよくあることです。ファーストリリースに強くこだわるのではなく、発表後に調整を加えてより良い作品にする考え方でいいです。

試遊の流れ

開いておくタブ・ウィンドウ（6つ）：

1. プレゼン資料（スライド）
2. Unityエディタ（プロジェクトを開き、Playボタンを押せば即デモできる状態にしておく）
3. ビルド済みexe（実行ファイルが確認できるエクスプローラウィンドウ）
4. GitHubリポジトリ（作品のリポジトリ画面）
5. GitHubDesktop（作品のリポジトリ画面）
6. プレイ動画（mp4が確認できるエクスプローラウィンドウ）

試遊会のローテーションルール

発表会では、全員が「プレイヤー」と「制作者」の2つの役割を交互に担います。

3つのポイント：

① 全員が2つの役割を持つ
プレイヤーのときは他の人の席へ移動して遊びます。自分の席（自分の作品）には自分では着かず、制作者として来た人がREADMEと画面説明を読むだけで遊べる状態に整えておきます。自分の作品は自分では遊びません。

② 毎ウェーブ +1 席ずれる
参加人数と同じウェーブ数で、全作品を1回ずつ遊びます（例：12人なら11ウェーブ）。最後の番号の次は①に戻ります。

名前（任意）

タイトル
ジャンプが難しい

内容
足場の端に乗るのが難しく感じた。

③ 1ウェーブ = 8分の流れ
まず README とコミット履歴（あれば Issue / Pull Request も）を読む（0〜2分）→ 試遊（6分）→ ベルの合図で終了・自席に戻ってリセット

ベルの合図で自席に戻ってリセットするときは、次の人が README と画面説明だけで遊べる状態に戻しておきましょう。

よくある失敗と対策

提出前チェックリスト（提出期限までに確認）

提出物

• [ ] GitHub リポジトリ URL が README に記載されている
• [ ] 指導講師が Collaborator として追加されている
• [ ] 最終版が期限内に push されている
• [ ] ビルド済み exe（出力フォルダ一式・UnityPlayer.dll 等を含む）を用意し、Unity なしで起動確認済み

Git

• [ ] 制作期間中、複数回の commit がある（最終日だけではない）
• [ ] 各 commit メッセージが内容を表している
• [ ] README の進捗メモが毎日更新されている
• [ ] エラーログに、実際に遭遇したエラーと解決方法が書かれている

発表

• [ ] プレゼン資料（5〜8枚）が完成している
• [ ] プレイ動画（mp4、1〜3分）を用意した
• [ ] README の「発表内容（予定）」セクションを埋めた
• [ ] コミット履歴を見せながら開発の流れを説明するリハーサルを1回以上した

就活で活かす

この発表と成果物は、そのまま就職活動の材料になります。提出して終わりにせず、次の4点を整えておきましょう。

面接用に1〜2分へ圧縮する

発表会の8〜10分は、面接ではそのまま使うには長すぎます。次の型で1〜2分に圧縮しておくと、自己PR・ガクチカとしてすぐ話せます。

1. どんな課題・目的に取り組んだか
2. どこを工夫したか（なぜそれを選んだか）
3. つまずいた点と、どう調べて解決したか
4. そこから学んだこと・次に活かすこと

AIや参考記事で書いた箇所も、自分の言葉で説明できるように

面接では「このコードは何をしている？」と問われることがあります。AIや記事を使った箇所も丸写しのままにせず、自分の言葉で説明できる状態にしておきましょう。説明できないコードは、書けること以上にマイナスに見られます。

GitHub をポートフォリオとして整える

採用では、まず人事（非エンジニア）が GitHub を開くこともよくあります。README の冒頭に「1行でどんな作品か＋スクリーンショット（できれば GIF）＋起動方法」を置き、誰が見ても30秒で分かる状態にしましょう。リポジトリは public にし、GitHub プロフィールに固定（Pin）しておくと、応募書類のリンクから見てもらいやすくなります。

ピン留めの手順：右上のプロフィールアイコン →「Your profile」→「Popular repositories」または「Pinned」上部の「Customize your pins」→ 見せたいリポジトリを最大6件まで選択 →「Save pins」。並び順は、左上を一番見てほしい作品にします（対象は public リポジトリです）。

Issue / Pull Request の経験も語れる：個人制作①では必須ではありませんが、使っていれば課題管理や変更の経緯も見せられます。加えて、直前のチーム開発演習で使った Issue / Pull Request の経験は、面接で「実務に近い進め方を理解している」材料として語れます。

公開する前にアセットの権利を確認する

public にする前に、有料アセットやライセンスのあるアセットをリポジトリに含めていないか確認しましょう。.gitignore を適切に設定し、使用アセットは出典・ライセンスを README に明記します。権利に配慮できることも、実務での信頼につながります。

まとめ

プログラミング学習では「動いた！」に目が向きがちです。

しかし発表では 「他人が理解できるか」「自分の考えが伝わるか」 を意識してください。コードを書く力と、伝える力の両方が、エンジニアの重要なスキルです。

参考資料

「動く作品」だけでは足りない時代へ ～GitHub・Git履歴・Pull Request が見られる理

ゲームやアプリを作ったあと、「完成しました！」と提出するだけで十分だった時代もありました。ですが ...

 https://soft-rime.com/post-28498/