ゲーム制作演習

Appearance

第01回 オリエンテーション ​

次回: 第02回 ゲーム構成要素設計1

ゲームを完成させる 方法論を学ぶ ​

ただ作るだけでは 完成すらあやうい ​

この授業の目的 ​

ゲーム制作を効率的に進めるための運用方法を学ぶ ​

  • この授業では、ゲーム制作を作業ではなく計画として捉え、監督に必要な知識と基本技法を扱います
  • 監督者として、目標、進捗、問題、優先順位を整理する練習をします
  • Git、タスク管理、レビュー、CI を「作業」ではなく「運用」の観点で扱います

今回の授業内容 ​

監督者の役割と心構え / 進行管理の全体像 ​

  • オリエンテーション
  • 監督者の役割と心構え
  • 進行管理の全体像
  • この授業で使う記録と判断の型

12回の流れ（1/3） ​

導入と設計基礎 ​

  1. オリエンテーション 監督者の役割と心構え、進行管理の全体像
  2. ゲーム構成要素設計1 コアループ、目的、ルール設計の基礎
  3. ゲーム構成要素設計2 フィードバック設計、想定リスクの洗い出し
  4. プロトタイピングとプレイテストの基礎 試作の目的、評価観点の設定

12回の流れ（2/3） ​

進行管理とチーム運用 ​

  1. タスク管理ツール入門 運用設計、担当、期限、優先度の標準化
  2. 進捗管理とリスク管理 見積り、遅延兆候の検知、対応方針
  3. Gitチーム運用基礎 ブランチ戦略、命名規則、コミット粒度
  4. プルリクエスト運用 レビュー観点、差分読解、合意形成

12回の流れ（3/3） ​

監督運用の定着 ​

  1. 監督ミーティング運営 議題設計、時間配分、意思決定ログ
  2. CI基礎 CIの目的、パイプラインの流れ、設計原則
  3. CI運用入門 失敗ログの読み方、一次切り分け、連携依頼
  4. 総括 監督運用ガイド、進行管理テンプレート、引き継ぎ資料

授業のゴール ​

第1回の授業後に説明できるようになること ​

  • 監督者が何を見る役割か説明できる
  • 毎回確認したい情報の型を挙げられる
  • 問題を見つけたときに、次に何を確かめるか言える
  • 授業内で残す記録の形を作り始められる

監督者とは ​

制作を前に進めるために判断する役割 ​

  • 目標が曖昧なら、どこまでを今回の到達点にするか決めます
  • 進捗が見えないなら、何を見れば判断できるか整理します
  • 問題が出たら、症状と原因候補を分けます
  • チーム内の情報を集めて、優先順位を決めて共有します

実装者と監督者の違い ​

見る範囲が違う ​

| 立場 | 主に見るもの |
|
|
|
| 実装者 | 自分の担当、仕様、コード、期限 |
| 監督者 | チーム全体の目標、依存関係、優先順位、障害 |

  • 現場では、同じ人が両方を担う場面もあります
  • その場合でも、視点を切り替えられないと判断が遅れます

毎回確認したい情報 ​

判断の前に最低限そろえたい5項目 ​

  1. 今回の目標は何か
  2. いまどこまで終わっているか
  3. 何が止まっているか
  4. 次に誰が何をするか
  5. どの判断を記録として残すか
  • この5項目が見えていないと、チームは感覚で会話する時間が増えます

問題を見たときの順番 ​

すぐ解決策に飛ばない ​

  1. まず症状を書く
  2. 事実として確認できることを書く
  3. 原因候補を分ける
  4. 追加で必要な情報を決める
  5. その後で次の行動を決める
  • 監督者は、速さよりも順序を崩さないことが重要です

記録を残す理由 ​

忘れないためだけではない ​

  • 前回の判断と今回の判断を比較できます

  • 口頭の認識ずれを減らせます

  • 途中参加の人にも状況を渡せます

  • 問題が再発したときに、前回の対応を確認できます

  • 記録は後ろ向きの作業ではなく、次の判断を速くするための材料です

この授業で作っていくもの ​

毎回少しずつ運用の型を増やす ​

  • ゲーム構成要素の整理メモ
  • 進捗確認メモ
  • タスク管理の基準
  • レビュー時の観点メモ
  • CI 障害の一次切り分けメモ
  • 最終回の引き継ぎ資料

実習 ​

いまある状況から 次の一手を決める ​

曖昧な感想ではなく 判断の材料を書く ​

実習1 ​

制作状況を4行で整理する ​

次の4項目を書いてください。

  1. 何を作っているか
  2. 今回の目標は何か
  3. 現時点で分かっている事実は何か
  4. いま不安な点は何か

実習2 ​

問題を「症状」と「原因候補」に分ける ​

  • 例: 「敵AIが完成していない」は症状です
  • 原因候補は、仕様未確定、担当の見積り不足、依存機能の遅れ、技術的難所などに分かれます
  • 1つの症状に対して、原因候補を2つ以上書いてください
  • そのうえで、追加で確認したい情報を1つ決めてください

実習3 ​

第1回版の記録フォーマットを作る ​

次の見出しで短く書きます。

  • 今日の目標

  • 今日わかった事実

  • 問題と原因候補

  • 次回までの行動

  • 共有しておく判断

  • 以後の授業でも、この記録の型を少しずつ更新しながら使います

今日の作業で見たいこと ​

長く書くより、分けて書けているかを見る ​

  • 目標と作業が混ざっていないか
  • 事実と推測が混ざっていないか
  • 原因候補を1つに決め打ちしていないか
  • 次の行動が具体的に書けているか

今回のまとめ ​

  • この授業では、制作を前に進めるための判断と共有を扱います
  • 監督者は、目標、進捗、問題、優先順位を整理する立場です
  • 問題は、症状、事実、原因候補、次の行動に分けると扱いやすくなります

おつかれさまでした！ ​

次回予告 第02回 ゲーム構成要素設計1 ​

記録の型を 設計確認にも つなげます ​