GAME DEV FOUNDATION
2026-06-27 版 / 4人初心者チーム向け

4人インディーゲーム開発の前提知識ガイド

この資料は、会議の台本ではなく、会議に臨む前に全員が同じ前提知識を持つための教材です。ゲームがどう作られるか、どんな作業が発生するか、何にいくら必要か、どこで公開できるか、4人でどう分担するかを、企画を決める前の共通言語としてまとめています。

目標: 会議前の共通知識を作る 想定: 8番出口 / MECCHA CHAMELEON 系 方針: 小さく作り、早く試遊 概算: 1 USD = 162円
4人インディーゲーム開発の知識土台を示す文字入り説明画像
画像生成による説明画像。クリック/タップで原寸表示できます。本文では、この内容を前提知識として分解します。
下へ読むほど、ゲーム開発の全体像から費用・作業・公開・運営へ進みます。 全体読了目安: 35〜55分
0

この資料で身につける前提知識

目的は、企画会議で扱う論点の意味を理解できる状態になることです。企画アイデアを話す前に、ゲーム開発の構造、費用、実作業、公開、権利の基礎を同じレベルまでそろえます。

理解する

ゲームは体験を設計する制作物

世界観や素材の前に、「プレイヤーが何を見て、何を判断し、どう反応するか」を作る仕事だと理解します。

理解する

作業は企画・実装・素材・検証に分かれる

小さなゲームでも、プログラム以外に、アート、音、UI、QA、ストア準備、法務整理が発生します。

見積もる

費用は0円ではなく段階で増える

初期は無料中心でも、Steam登録費、素材、音、外注、広告、PC購入などの予算判断が必要になります。

話し合える

選択肢と制約を比べられる

「やりたい」だけでなく、作業量、予算、公開先、権利、チーム体制を踏まえて企画を選べるようにします。

読了後の理想状態: 全員が「ゲーム開発には何が必要か」「自分たちは何を調査・決定すべきか」「無理なスコープは何か」を説明できる。会議はその知識を使って、企画と制作方針を選ぶ場にします。

会話に参加するための概念マップ

以下の言葉を完璧に使いこなす必要はありません。ただし、会議や制作中に出てきたときに「何の話をしているか」が分かる状態を目指します。

エンジンと構造

  • ゲームエンジン: Unity/Godot/Unrealなど、ゲームを作る土台
  • プロジェクト: 1本のゲームの設定・素材・コード一式
  • シーン: タイトル、ステージ、メニューなどの画面単位
  • オブジェクト: プレイヤー、壁、敵、ボタンなどの部品
  • コンポーネント: 動き、見た目、当たり判定などの機能

プレイを作る要素

  • 入力: キーボード、マウス、ゲームパッドの操作
  • カメラ: 何を見せるかを決める視点
  • 当たり判定: 触れた、ぶつかった、見つけた等の判定
  • UI: HP、メニュー、設定、説明、リトライ導線
  • フィードバック: 音、光、揺れ、演出で結果を伝えること

共同制作の管理

  • Git: 変更履歴を残して共同作業する仕組み
  • ブランチ: 作業を分けるための枝
  • コンフリクト: 同じ場所を複数人が変更して衝突すること
  • チケット: 作業を小さく分けた依頼/タスク
  • ビルド: 他人のPCでも遊べる形に書き出すこと

公開と権利

  • アセット: ゲームに入れる画像、音、3Dモデル、フォント
  • ライセンス: 商用利用、改変、クレジット条件
  • QA: バグと体験品質を確認する作業
  • ストア素材: 説明文、画像、動画、ロゴ、年齢区分
  • ロイヤリティ/手数料: 売上から差し引かれる費用
1

ゲーム開発の全体像

ゲーム開発はプログラミングだけではありません。小さなゲームでも、5つの層と「作って・遊んで・直す」流れが必要です。

ゲーム開発は5つの層でできていることを説明する日本語入り画像
クリック/タップで原寸表示できます。小さなゲームでも、企画・プログラム・アート・サウンド・体験の土台は小さく全部必要です。

5つの層を会議の共通語にする

何をするか初心者が誤解しやすい点
企画・ルール体験、ルール、成功/失敗、難易度を決める世界観や設定を先に大きくしすぎる
プログラム入力、移動、判定、UI、ビルドを動く形にするエンジンを選べば自動でゲームになると思う
アート背景、キャラ、UI、ライティング、演出を作る見た目の量が制作期間を圧迫する
サウンドBGM、効果音、環境音、音量調整を扱う最後に入れればよいと思いがち
体験の土台タイトル、設定、セーブ、説明、アクセシビリティ本編以外を省くと製品として遊びにくい

開発は一直線ではなく、反復する

1

体験を決める

何を感じさせるかを1文にする。

2

ルール化

観察、判断、行動、結果を書く。

3

プロトタイプ

仮素材で遊べる最小版を作る。

4

試遊

初見の人に遊んでもらい記録する。

5

本制作

面白さが見えた後に量を増やす。

6

公開/改善

ストア準備、QA、発売、パッチへ進む。

2

面白さの作り方

参考作品から学ぶべきなのは、見た目や舞台ではなく「プレイヤーに何を観察させ、何を判断させるか」です。

観察、判断、行動、結果のコアループを説明する日本語入り画像
クリック/タップで原寸表示できます。最初はこの1ループだけを遊べる形にします。ギミック追加は後です。

コアループを1文で書く

コアループは、プレイヤーが何度も繰り返す基本行動です。短時間インディーでは、この輪が分かりやすいほど配信やSNSで伝わります。

テンプレート: 「プレイヤーは 何を見る何を判断する何をするどう結果が返る
  • 観察系: 異変や違和感を見つける。
  • 反応系: ミスを避ける、タイミングを合わせる。
  • 推理系: 少ない情報から正しい選択をする。
  • 操作系: 単純操作だが失敗が笑いや驚きになる。

参考作品は「構造」で見る

作品/型学ぶ構造小規模向きの理由真似してはいけないこと
8番出口型1行ルール、観察、短い反復、違和感の発見限られた舞台でも成立しやすい通路、標識、演出、名称を表層模倣する
MECCHA CHAMELEON型強いフック、配信参加、見て分かる勝敗映像で伝わりやすい初回からオンライン対戦を抱え込む
短編ホラー/観察系音、間、限定空間、予測と裏切り素材量を絞れる既存作の舞台・怪異・固有表現を寄せすぎる

強いフックの条件

10秒で説明でき、見ている人が「自分も分かる」と感じること。

配信映えの条件

驚き、失敗、気づき、笑いが画面上で伝わること。

初回の危険

フックが弱いまま、素材量やストーリー量で埋めようとすること。

3

最初の1ヶ月と制作工程

最初の成果は完成版ではなく「遊べる検証版」です。面白いか分からないものを本制作しないための期間です。

最初の1ヶ月の到達目標

作るもの / 作らないもの

最初に作るまだ作らない
3〜10分で終わる1ループ長編ストーリー
仮の見た目と音完成品質の全素材
成功/失敗が分かる判定ランキング、実績、課金
簡単なタイトル/リトライモバイル/コンソール移植

3ヶ月・6ヶ月・12ヶ月の現実的スコープ

期間現実的な完成物向いているゲーム避けるもの
3ヶ月無料公開/小額販売の超短編、縦切りデモ1舞台、1ルール、5〜15分多数ステージ、オンライン、長編
6ヶ月Steam/itch.io向け短編15〜30分、配信向き、繰り返し広い探索、複雑AI、ボス多数
12ヶ月低価格帯の完成版30〜90分、短編ホラー/謎解き/アクションパズルオープンワールド、MMO、長編RPG
4

実際に発生する作業

ゲーム開発は「アイデアを出す」「コードを書く」だけでは終わりません。遊べるものにするまでには、企画を検証し、素材を作り、操作感を整え、バグを潰し、公開用の情報を作る作業が並行して発生します。

作業は小さく切る

「ゲームを作る」では大きすぎます。入力、カメラ、判定、UI、SEのように、1〜2日で確認できる単位へ分解します。

学習時間は別枠

初心者は実装時間より調べる時間が長くなります。見積もりには「作る時間」と「覚える時間」の両方があります。

依存関係がある

ストア画像は画面がないと作れず、QAはビルドがないとできません。前の成果物が次の作業を支えます。

完了条件を決める

「頑張った」ではなく、「他人のPCで動く」「初見が遊べる」のように確認できる状態で終わらせます。

作業の全体地図

企画・設計

  • 体験コンセプトを1文にする
  • 参考作品を構造で分解する
  • コアループを書く
  • 成功/失敗条件を決める
  • 1プレイ時間を決める
  • 作らないリストを作る
  • 仕様メモを更新する

実装

  • プロジェクトを作る
  • Gitで共同作業する
  • 入力とカメラを実装する
  • 移動、判定、失敗処理を作る
  • UI、設定、リトライを作る
  • サウンド再生をつなぐ
  • Windows/Mac向けにビルドする

アート・UI

  • 仮素材で画面を組む
  • ステージを白箱で作る
  • モデル/画像/テクスチャを作る
  • ライティングと色味を整える
  • タイトル、メニュー、設定画面を作る
  • スクリーンショットを撮る
  • ストア画像を作る

音・演出

  • 必要なSEリストを作る
  • BGM/環境音の方向性を決める
  • 音量バランスを調整する
  • 驚きや気づきの演出を作る
  • 効果音のタイミングを合わせる
  • 素材ライセンスを記録する
  • 無音でも遊べる情報設計を確認する

QA・公開

  • テスト項目表を作る
  • 初見プレイを録画する
  • バグ報告を整理する
  • 難易度と酔いやすさを見る
  • ストア説明文を作る
  • トレーラー素材を集める
  • リリースチェックを行う

チケット例と工数感

下の時間は、学習時間を除いた粗い目安です。初心者チームでは、初回だけ調査・詰まり・やり直しで2〜3倍かかることがあります。

チケット例目安工数前に必要なもの完了条件主担当例
プロジェクト作成とGit初期設定2〜6hエンジン候補、共有アカウント全員が同じプロジェクトを開ける実装
プレイヤー移動とカメラ4〜12h操作方針、視点方針歩く、見る、止まる、酔いやすさを確認できる実装
白箱ステージ作成3〜8h1プレイの長さ、導線仮の形だけでスタートから終了まで移動できる体験設計/アート
コアギミック試作8〜24h観察、判断、行動、結果の定義1回の成功/失敗が判定され、結果が返る実装 + 体験設計
タイトル/リトライUI4〜10h画面遷移方針起動、開始、失敗、再挑戦、終了ができる実装/アート
音量設定とSE再生3〜8hSEリスト、音量基準操作/成功/失敗の音が鳴り、音量調整できる音/実装
初見テスト用ビルド作成2〜5h最低限遊べるプロトタイプ開発者以外のPCで起動し、録画/報告できる実装/QA
初見プレイテスト1回2〜4hテスト用ビルド、質問項目録画、観察メモ、改善点、重大バグが残るQA
バグ整理と優先度付け1〜3h/回バグ報告、再現手順S/A/B/Cに分類され、担当と期限があるQA + 実装
Steam/itch.io説明文ドラフト3〜8h体験1文、特徴、プレイ時間初見が内容を誤解せず、検索用語も入っている公開
カプセル画像/キービジュアル案6〜20h画面方向性、タイトル、見せたい体験小さな一覧表示でも内容と雰囲気が伝わるアート/公開
短尺動画/トレーラー粗編集6〜20h見せられるプレイ映像15〜30秒で「何をするゲームか」が伝わる公開
素材台帳の作成と更新1〜2h初期 + 随時素材の入手元素材名、URL、ライセンス、確認日が残っているQA/公開

成果物ベースで見る12週間の進み方

時期主な目的作る成果物この時期に判断すること
1週目前提をそろえる体験1文、参考作品分解、作らないリスト、共同開発ルール草案作りたい体験は短く説明できるか
2週目紙と仮画面で検証するコアループ図、白箱ステージ、簡単な操作メモプレイヤーが何を判断するゲームか
3〜4週目1ループを動かす仮素材プロトタイプ、ビルド、初見テスト記録3〜10分で面白さの芽が見えるか
5〜6週目縦切り版を作る1場面だけ完成に近い画面、音、UI、リトライ導線この品質で量産できるか
7〜9週目内容を増やすステージ/ギミック追加、演出追加、素材台帳、バグリスト増やしても面白さが薄まらないか
10週目公開準備を始めるストア文、スクショ、短尺動画、デモ候補ビルドitch.io/Steamのどちらを先に出すか
11週目直す重大バグ修正、難易度調整、音量調整、説明改善発売/公開を止める問題が残っていないか
12週目公開またはデモ配布公開ビルド、リリースノート、問い合わせ先、次回改善リスト正式販売に進むか、もう一度検証するか

作業ごとの完了条件

作業完了と言える状態未完了の典型
体験設計初見の人に10秒で説明でき、4人全員が同じ説明をできる雰囲気だけ決まり、プレイヤーの行動が言えない
プロトタイプ他人のPCで起動し、3〜10分の1ループを最後まで遊べる開発者の環境でしか動かない、勝敗や終了がない
縦切り版1場面だけ、画面・音・UI・失敗処理・リトライが製品に近い素材は綺麗だが操作や判定が仮のまま
QA重大度、再現手順、ビルド番号、担当者が記録されているDiscordの雑談にバグ報告が流れて残らない
公開準備ストア説明、スクショ、動画、ロゴ、連絡先、素材権利がそろっているゲームは動くが、販売ページに載せる情報がない
このセクションの読み方: チームで分担する前に、まず全員が“そもそも作業にはこれだけの種類がある”と理解しておくことが重要です。
5

エンジン・ツール・費用

結論は「固定費を抑えて、学びやすい構成から始める」です。選定は好みではなく、作りたい体験とチームの学習コストで決めます。

エンジン選定の分岐

Unity 第一候補

日本語情報、教材、アセットが多い。2D/3Dどちらにも対応しやすく、初心者が詰まった時に検索で戻りやすい。

注意: Personal/Pro条件は公式料金ページで確認。

Godot 低コスト

MITライセンスで始めやすい。2Dや小規模3D、固定費を抑えたいチームに向く。

注意: コンソールや商用支援はUnity/Unrealより確認が必要。

Unreal 本格3D

リアル寄り一人称3Dや高品質ライティングに強い。学習負荷とPC負荷は高め。

注意: ロイヤリティ条件はEULAで確認。

無料中心スターターセット

用途最初の推奨有料化するタイミング
エンジンUnity Personal / Godot / Unreal収益条件やチーム規模が変わる時
コードVS Code、Visual Studio Community効率重視でRider等を検討する時
3DBlenderテクスチャや専門DCCが必要な時
2D/UIKrita、Figma、Aseprite制作量が増え、共同編集や効率が必要な時
Audacity、無料/有料素材編集やミックス品質を上げたい時
管理GitHub、Discord、Trello/Notion大容量素材、権限管理、外注が増えた時

費用の全体結論

PCあり・最小 初期 2万〜5万円

無料ツール中心。Steam登録費、小さな素材購入、検証用の実費だけで始める構成です。

PCあり・標準 初期 12万〜40万円

有料素材、音、フォント、ドメイン、最低限の法務確認まで入れた現実的な構成です。

外注・広告あり 初期 60万〜300万円以上

キービジュアル、トレーラー、音楽、広告、イベント、専門家確認を含めると一気に増えます。

構成初期費用の概算年間/継続費の概算含まれるもの向いている状況
最小構成 PCあり2万〜5万円0〜2万円無料エンジン、無料制作ツール、Steam登録費、少額素材最初の検証、itch.io無料配布、短編デモ
標準構成 PCあり12万〜40万円2万〜8万円Steam登録費、有料素材、音源、フォント、ドメイン、少額法務確認、予備費Steam短編販売、チームで真面目に1本作る場合
拡張構成 PCあり60万〜300万円以上10万円以上外注アート、トレーラー、BGM制作、広告、展示、専門家確認販売前提で品質と露出を上げる場合
PCを4人分新調上記に +60万〜120万円保守/買い替え別1人15万〜30万円程度の開発PCを4人分現PCでUnity/Unreal/Blenderが重い場合
Unity Pro等が必要になった場合原則、初期は不要約35.6万円/年/人目安2,200 USD/年/シートを1 USD=162円で概算売上/資金調達など公式条件の閾値を超える場合

サンプル見積で見る足し算

税、為替手数料、地域差、セール、公式価格改定は含まない概算です。1 USD = 162円で丸めており、実購入前に必ず公式価格を再確認します。

構成費用の内訳例チーム合計4人で均等負担した場合読み方
最小構成Steam登録 約16,200円 + 少額素材 5,000〜10,000円 + 音/フォント 0〜5,000円 + 予備費 0〜15,000円約2万〜5万円約5,000〜12,500円/人まず検証するための最低限。PC購入と外注は含まない。
標準構成Steam登録 約16,200円 + 素材 4万〜8万円 + 音 2万〜5万円 + フォント/ドメイン 0.5万〜2.5万円 + 法務確認 3万〜15万円 + 予備費 2万〜5万円約12万〜40万円約3万〜10万円/人Steam短編販売を現実的に狙うライン。外注の大物はまだ含めない。
外注・広告あり標準構成 + キービジュアル 5万〜30万円 + トレーラー 5万〜30万円 + BGM/SE外注 5万〜30万円 + 広告/展示 10万〜100万円以上 + 追加法務約60万〜300万円以上約15万〜75万円以上/人完成度と露出を買う構成。縦切り版で方向性が固まってから検討する。
PCも新調各構成 + 開発PC 15万〜30万円 × 4人上記 + 約60万〜120万円約15万〜30万円/人を追加UnrealやBlender作業が重い場合に検討。既存PCで動くなら初回は後回し。

何にいくら必要か

費用項目必須度最小構成標準構成拡張構成発生タイミング
Steam Direct登録費Steamなら必須100 USD、約16,200円/アプリ同左複数タイトルなら本数分Steamページ作成前
itch.io公開任意初期費用0円販売時の手数料/支払い条件を確認支援者向けページやデモ配布にも利用試遊配布時
Unity PersonalUnityなら確認条件内なら無料条件内なら無料売上/資金調達が増えたら有料プラン確認エンジン選定時
Unreal EngineUnrealなら確認初期費用0円初期費用0円100万USD超の総収益から5%ロイヤリティ対象商用化前
GodotGodotなら確認0円0円必要に応じて外部支援/移植費エンジン選定時
Apple Developer ProgramApp Storeなら必須後回し99 USD/年、約16,000円毎年更新iOS/macOS公開時
Google Play ConsoleGoogle Playなら必須後回し25 USD、約4,100円/一度のみ追加審査/運用対応Android公開時
2D/ドット絵ツール任意無料ツールAsepriteなど約3,000円台/人Photoshop等のサブスクアート制作開始時
音編集/DAW任意Audacity等0円REAPER割引ライセンス約9,700円目安商用/高機能DAWや外注音を作り込む時
アセット購入ほぼ必要0〜1万円1万〜8万円10万〜50万円以上プロトタイプ後
BGM/効果音ほぼ必要無料素材中心1万〜5万円5万〜30万円以上縦切り版以降
フォント必要商用可無料フォント0〜2万円ブランド用フォント購入UI/ストア制作時
Web/ドメイン任意0円年1,500〜5,000円LP制作や有料ホスティングSteamページ公開前後
Git LFS/クラウド保管素材量次第0円月0〜5,000円大容量ストレージ/バックアップ素材が増えた時
法務/契約相談推奨自作合意書3万〜15万円継続相談、商標、法人化販売前、外注前
外注アート/音/動画任意なし5万〜30万円30万〜200万円以上縦切り版で方向性確定後
広告/イベント任意0円0〜10万円10万〜100万円以上デモ/発売前

初回におすすめの予算ライン

まず検証だけ

0〜5万円。無料ツールと仮素材で1ループを試す。販売判断はまだしない。

Steam短編を狙う

15万〜35万円。Steam登録費、素材、音、フォント、少額法務確認、予備費を含める。

見た目と露出を上げる

60万円以上。キービジュアル、トレーラー、BGM、広告、イベント出展まで考える。

会議前に各自で確認すること: 自分のPCで候補エンジンが動くか、Steamで出したいか、外注を使う可能性があるか、有料素材にいくらまで出せるか。ここが分かるだけで企画の現実度を判断しやすくなります。
価格・条件は変動します。資料内の金額は2026-06-27時点の確認情報または概算です。実際の登録・購入前に公式ページで再確認してください。
6

公開先と販売準備の前提知識

ゲームを作るだけでは公開できません。どこで配るか、どんなストア素材が必要か、いつ審査があるかを知っておくと、企画段階から必要作業を見積もれます。

プロトタイプからitch.io試遊、Steamページ準備、デモ、発売、パッチ改善までの日本語入りロードマップ画像
クリック/タップで原寸表示できます。初回は PC 向けを基本に、itch.ioで試遊、Steamを本命にする流れが現実的です。

初回公開のおすすめ順

  1. ローカル配布: 身内と初見数人に遊んでもらう。
  2. itch.io: 無料/低価格で試遊を広げる。
  3. Steamページ: ウィッシュリストとストア素材を準備する。
  4. デモ: 反応を取り、改善点を集める。
  5. 発売: バグ修正体制を置いて公開する。

公開先の初回適性

公開先初回適性強み注意点
itch.io試遊・無料配布に強い軽く公開でき、フィードバックを集めやすい商用の主戦場としてはSteamより弱い場合がある
SteamPC販売の本命ウィッシュリスト、レビュー、配信者導線が強い登録費、審査、近日登場期間、ストア素材が必要
BOOTH / DLsite国内補助国内創作・同人向けに使いやすいターゲット層とゲーム内容の相性を見る
App Store / Google Play初回は後回しユーザー数は大きいストア規約、端末検証、操作設計、集客が別物
コンソール当ててから移植ヒット後の展開先になる開発機、NDA、審査、移植コストが重い

公開時にゲーム本体以外で必要になるもの

必要物何に使うか作る担当の例準備タイミング
ストア説明文ゲーム内容、特徴、プレイ時間、対応言語を伝える企画担当 + 公開担当Steamページ公開前
スクリーンショット実際のプレイ画面を見せる。雰囲気だけでなく操作や目的が伝わる画が必要アート担当 + QA担当縦切り版以降
カプセル画像/キービジュアルSteamなどの一覧でクリックされるための画像アート担当、必要なら外注ページ公開前
トレーラー/短尺動画SNS、Steam、実況者向けに体験を短く伝える公開担当 + 全員で素材提供デモ公開前後
ビルドと動作環境Windows/Macなどで実際に遊べるファイルと最低スペック実装担当 + QA担当毎週の確認、公開直前に確定
レーティング/年齢区分ストアや地域に応じて必要になる年齢区分公開担当ストア提出前
サポート導線不具合報告、問い合わせ、実況ガイドライン、連絡先公開担当発売前
権利証跡素材・フォント・音源・AI生成物の利用条件を説明できる状態QA/公開担当 + 全員素材を入れたその日から

売上はそのまま手元に残らない

差し引かれる/考慮するもの何が起きるか会議前に理解しておくこと
ストア手数料Steam、App Store、Google Playなどは販売額からプラットフォーム手数料を差し引く売上金額と入金額は違う。比率や条件は各ストア公式/契約で確認する。
税金・消費税/VAT地域や販売形態によって税処理が入る税務は自己判断しすぎず、販売前に確認する。
返金・チャージバック購入後に返金されると、売上として残らない短編ゲームほど説明文と期待値調整が重要。
為替・送金海外ストアでは通貨換算、送金、銀行手数料が発生する場合がある外貨表示の金額をそのまま円の手取りと見ない。
先に回収する経費Steam登録費、素材、外注、広告などを売上から先に戻すかを決める必要がある収益分配の前に、経費回収ルールを文書化する。
メンバー分配残った利益を人数、役割、作業量、契約に応じて分ける「4等分」か「担当比率」か「代表に集約」かを早めに決める。

Steam公開の逆算メモ

審査時間

ストアページとゲームビルドの審査は、それぞれ3〜5営業日を見込みます。差し戻しがあると延びます。

提出期限

発売予定日の少なくとも7日前にはストアページとビルドを提出する前提でスケジュールを組みます。

近日登場

Steamでは発売前にComing Soonページを最低2週間公開する必要があります。公開準備は完成後ではなく制作中から始めます。

7

4人チームの分担と運営の前提知識

4人では専任分業より兼任が自然です。ただし「責任者は1作業に1人」だけは守る必要があります。全員でやる作業と、誰かが最終判断を持つ作業を分けて理解します。

4人チームは兼任で進めることを説明する日本語入り画像
クリック/タップで原寸表示できます。全員が基礎を知り、主担当を分ける。プロトタイプ段階ではC案の全員兼任型が扱いやすいです。

おすすめ: 全員兼任・プロトタイプ優先型

主担当兼任最初の成果物
A体験設計レベル、議事録体験1文、コアループ図
B実装ビルド、Git1ループの試作
Cアート/音UI、仮素材仮画面、仮SE、雰囲気案
DQA/公開ストア調査、試遊記録テスト表、公開準備リスト

作業責任の分け方

作業主担当支援成果物曖昧にすると起きる問題
コアループ設計体験設計担当全員観察、判断、行動、結果の1枚メモ面白さの判断基準が人によって変わる
Git/ビルド管理実装担当QA担当共有リポジトリ、ビルド手順、配布先誰の環境でも動く状態を作れない
ステージ白箱体験設計担当アート担当、実装担当仮配置のプレイ空間見た目制作に入ってから導線を作り直す
アート方向性アート担当体験設計担当色、形、画面密度、参考画像素材ごとに雰囲気がばらつく
SE/BGM方針アート/音担当QA担当SEリスト、音量基準、素材台帳音が最後まで仮のままになり、体験の手触りが弱くなる
UI/設定実装担当アート担当タイトル、ポーズ、リトライ、音量設定遊べるが製品として使いにくい
テスト計画QA担当全員テスト表、バグリスト、初見プレイ記録バグや不満が雑談に流れて直らない
Steam/itch.io準備公開担当アート担当、実装担当説明文、画像、動画、ビルド、価格案ゲーム完成後に公開素材がなくて止まる
共同開発ルール代表/進行担当全員収益分配、費用精算、離脱時ルール売れた時、抜けた時、外注した時に揉める

制作中の情報共有で必要なもの

進捗

できたこと、動くもの、スクショ、ビルドを見せる。口頭説明だけにしない。

課題

詰まり、仕様の迷い、バグ、素材不足を出す。責める場にしない。

次の一手

担当、期限、完了条件を決める。作らないリストも毎週見る。

そのまま使えるバグ報告テンプレート
  • 何が起きたか: 症状を1文で。
  • どうなってほしいか: 期待する動作。
  • 再現手順: 誰でも同じ手順で試せるよう番号で。
  • 発生環境: OS、解像度、入力機器、ビルド番号。
  • 添付: スクショ、動画、ログ。
8

法務・QA・マーケ

初心者チームが後で詰まりやすいのは、完成前に見えにくい領域です。合意書、素材台帳、試遊記録、ストア素材は早めに小さく始めます。

法務・権利

共同開発の収益分配、著作権、離脱時ルール、素材ライセンス、フォント、音源、AI生成物を記録します。

専門家確認が必要: 契約、税務、商標、権利譲渡、法人化。

QA・プレイテスト

クラッシュやバグだけでなく、初見で伝わるか、酔わないか、もう一度遊びたいかを確認します。

テスターは身内 → 友人外 → Discord/コミュニティ → デモへ段階拡大。

マーケ・公開準備

ストア説明文、スクリーンショット、短尺動画、デモ、実況者向け素材を、発売直前ではなく制作中から貯めます。

短時間ゲームは「見た瞬間に分かる」素材が重要。

優先リスク表

リスク影響今すぐやる予防策専門家確認
共同開発の権利・収益が未定当たった瞬間に揉めるA4 1〜2枚で合意書を作る販売前に推奨
素材ライセンス不明公開停止、差し替え素材台帳を作り、URLと条件を記録怪しい素材は相談
参考作品の表層模倣炎上、差別化不能学ぶ要素/避ける要素を分ける商標・著作物は必要に応じて
試遊が身内だけ面白さを誤判定初見3〜5人から記録を取る不要
ストア素材が遅い公開が遅れるスクショと短尺動画を制作中から保存不要

共同開発合意書で最低限決めること

QAとマーケの実務チェック

QAで見るもの

  • 重大度: クラッシュ、進行不能、セーブ破損はリリースブロッカー。
  • 再現性: 手順、発生率、環境、ビルド番号を残す。
  • 初見理解: 何をすればよいか、30秒で伝わるか。
  • 体験: 酔いやすさ、音量、難易度、もう一度遊びたいか。

マーケで用意するもの

  • Steamカプセル画像、スクリーンショット、短い説明文。
  • 15〜30秒の短尺動画、正式トレーラー、GIF素材。
  • プレスキット: ロゴ、画像、概要、連絡先、実況ガイドライン。
  • ウィッシュリスト導線: ストアページ公開後にSNS/デモ/動画から誘導。

QAの重大度を理解する

重大度リリース判断対応の考え方
S: 致命的クラッシュ、進行不能、セーブ破損、起動できない公開停止直るまで発売/公開しない。再現手順とログを最優先で集める。
A: 重大操作不能、音が出ない、重要UIが読めない、重要ギミックが壊れる原則公開前に修正頻度が低くても体験を壊すなら優先。応急処置も検討する。
B: 中程度表示崩れ、軽い引っかかり、誤字、一部環境だけの問題状況次第発売前に直すのが理想。残すなら既知の問題として管理する。
C: 軽微細かい違和感、演出の粗さ、調整余地パッチ対応可発売後改善リストに回せるが、積みすぎると印象が悪くなる。
素材台帳に残す項目
項目記録内容
素材名ファイル名、用途、配置場所
入手元URL、作者名、購入日/取得日
ライセンス商用利用、改変、クレジット、再配布の条件
証跡購入履歴、スクショ、規約確認日
9

会議前の理解確認

ここは会議の進行表ではありません。この資料を読んだ人が、企画会議に参加する前に説明できるべき前提知識を確認するためのチェックです。

読了後に説明できるべきこと

読後に自分で考える論点

論点なぜ必要かこの資料で見る場所各自が考えること
どんな体験を作りたいかゲームの方向性、作業量、公開先がここから決まる面白さの作り方参考作品の好きな要素を、見た目ではなく構造で書く
1本目の規模をどこまで小さくするか初心者チームはスコープ過多で止まりやすい最初の1ヶ月と制作工程3ヶ月、6ヶ月、12ヶ月のどれを狙うか考える
どのエンジンで始めるか学習コスト、PC負荷、素材入手性が変わるエンジン・ツール・費用自分のPCでUnity/Godot/Unrealを動かせるか確認する
初期予算はいくらまで出せるかSteam登録、有料素材、外注、法務確認の判断に必要費用の全体結論0〜5万、15〜30万、60万以上のどの感覚か考える
公開先はどこを第一候補にするか必要素材、審査、集客方法、操作設計が変わる公開先と販売準備itch.io試遊、Steam販売、モバイル後回しのどれが現実的か考える
4人の仮担当をどう分けるか担当不明の作業は最後まで残る4人チームの分担自分が主担当にできそうな領域と、避けたい領域を書く
権利とお金をどう扱うか売れた時、抜けた時、外注した時に揉めないため法務・QA・マーケ収益分配、費用立替、素材利用の不安点を書き出す

理解が浅いときの戻り先

作業量が見えない

「実際に発生する作業」と「成果物ベースで見る12週間の進み方」に戻る。

お金が見えない

「費用の全体結論」と「何にいくら必要か」を読み、PCあり/なしで分けて考える。

公開のイメージがない

「公開時にゲーム本体以外で必要になるもの」を読み、作る素材を確認する。

10

用語と公式ソース

金額・規約・公開条件は変わるため、実際に登録・購入する前に必ず公式ページで再確認してください。

初心者向け用語集
用語意味
コアループプレイヤーが繰り返す基本行動の輪。
プロトタイプ面白さを検証するための試作品。
縦切り版完成品質の最小単位。1場面だけ最後まで磨いたもの。
ゲームエンジンUnity、Godot、Unrealなど、ゲーム制作の土台になるソフトウェア。
シーンタイトル画面、ステージ、メニューなど、ゲーム内の画面/場面単位。
オブジェクトプレイヤー、壁、カメラ、ボタンなど、シーン内に置く部品。
コンポーネント見た目、物理、スクリプト、当たり判定など、オブジェクトに付ける機能。
Prefab / テンプレート同じ敵、ボタン、ギミックなどを再利用するための部品化されたデータ。
アセット画像、3Dモデル、音、フォント、コード部品など、ゲームに入れる素材。
当たり判定ぶつかった、触れた、範囲に入ったなどを判定する仕組み。
入力キーボード、マウス、コントローラー、タッチ操作などを受け取る仕組み。
カメラプレイヤーに何を見せるかを決める視点。3Dでは酔いやすさにも影響する。
UIタイトル、メニュー、設定、字幕、説明、リトライなどの操作画面。
フィードバック音、光、揺れ、アニメーション、表示でプレイヤーの行動結果を返すこと。
ビルド開発中のゲームを、他人のPCでも遊べる形に書き出すこと。
Git変更履歴を残し、複数人で作業するための仕組み。
ブランチGit上で作業を分けるための枝。機能追加や修正を分離できる。
コンフリクト複数人が同じ箇所を変更し、どちらを採用するか判断が必要になる状態。
チケット作業を小さく切ったタスク。担当、期限、完了条件を持たせる。
QAバグ、遊びやすさ、理解しやすさ、動作環境を確認する品質保証作業。
スモークテスト起動、開始、終了など、最低限壊れていないかを見る短い確認。
リグレッション前は動いていた機能が、修正後に壊れること。
ストアページSteamやitch.ioなどで、ゲーム説明、画像、動画、価格を載せる販売ページ。
カプセル画像Steamなどの一覧で表示される宣伝用画像。クリック率に影響する。
ウィッシュリストSteamでユーザーが発売前/購入前に興味を登録する仕組み。
レーティング年齢区分。ストアや地域によって必要になる。
ライセンス素材やツールをどの範囲で使えるかを定めた条件。商用利用、改変、クレジットが重要。
ロイヤリティ売上や収益に応じて支払う利用料。
NDA秘密保持契約。未公開情報やプラットフォーム情報を外に出さない約束。
パッチ公開後にバグ修正や改善を配布する更新。
公式ソース一覧