グレーボクシングでステージの形が決まり、遊びの手応えもつかめたら、次に確かめるのは「この品質で、最後まで作りきれるか」です。そのために、ゲームの一部分だけを製品版に近い品質まで作り込むのが、バーティカルスライスです。全工程の中では、プリプロダクション(作るべきか・作れるかを、企画と試作で確かめる段階)の締めくくりにあたり、ここで決めた品質と見積もりをもとに、量産(プロダクション)に進むかどうかを判断します。全体の流れは「ゲーム開発の全工程マップ」で確認できます。
本記事では、バーティカルスライスの定義と、似た言葉(プロトタイプ・ホリゾンタルスライス・MVP・体験版など)との違い、目的、何を含めてどこを切り出すか、期間と完成の判断、作りすぎの罠を解説します。後半では、生成AIで見た目を安く作れるようになった今、この工程で何に気をつけるべきかを、筆者の実例とあわせて紹介します。
夕宮たいだふぁ……みんな〜、今日は「バーティカルスライス」の話だよぉ。名前はかっこいいけど、中身は「一部分だけ、先に本気で完成させてみる」なんだぁ。いっしょに見ていこ〜。
バーティカルスライスとは
ひとことで:ゲームの一部分を製品版に近い品質まで作り、「この品質で作れる」ことを示す版です。
ゲームを1枚の表にたとえると分かりやすくなります。横の軸にステージや章などの「区間」、縦の軸に企画・プログラム・絵・アニメーション・音・UI・文章といった「層」を並べます。バーティカル(縦)スライスは、このうち1つの区間を選び、すべての層を縦に切り出して、製品に近い品質まで仕上げたものです。グレーボクシングで決めた形の一部を、美術の作り込み(アートパス)まで含めて完成させる、と考えても構いません。
英語圏の資料でも、ほぼ同じ意味で説明されています。
- プロジェクトのすべての構成要素にわたる進み具合を示すことに重点を置いたマイルストーン(Wikipedia「Vertical slice」が引く、Chandler の制作管理の本『The Game Production Toolbox』の説明)
- ゲームの一区画を取り出し、最終版に入るほぼすべての要素と、ほぼ完成した絵で仕上げたもの(『Fallout』の共同制作者 Tim Cain。Game World Observer、2023年11月)
- 「作れるか」を確かめるための、制作の試作。全種類の要素を1つずつ、出荷品質に近い忠実度で作り、制作の流れを一度通して詰まる所を見つける(Rami Ismail の解説「Prototypes & Vertical Slice」、2022年9月)
Tim Cain は、自身が関わった『The Outer Worlds』では、町や船を含む「Roseway」という区画をバーティカルスライスにし、クラフトや仲間の切り替えといった一部の機能は入れなかった、と紹介しています。「ほぼすべての要素」は「全部」という意味ではありません。判断に必要な物を選んで作ります。


プロトタイプ・MVP・体験版との違い
ひとことで:似た言葉は「何を確かめるための版か」で見分けます。
| 呼び方 | ひとことで | 確かめること | 見た目の品質 | 主に見せる相手 |
|---|---|---|---|---|
| プロトタイプ | 遊びが成立するかを確かめる、使い捨ての試作 | 作るべきか | 問わない | 開発チーム |
| ファーストプレイアブル | 主要な遊びが初めて通しで動く版(会社によってはアルファと同じ意味) | 遊びの一連がつながるか | 仮の素材が多い | チーム・出資者 |
| ビューティフルコーナー | 完成した見た目を示す、ごく小さな区画(多くは遊べない) | 目指す見た目 | 製品と同じ | チーム・出資者 |
| バーティカルスライス | 一部分を製品版に近い品質で作った版 | この品質で作れるか | 製品版に近い | チーム・パブリッシャー・出資者 |
| ホリゾンタルスライス(この連載での意味) | ゲーム全体を荒く通した版 | 全体のつながり・順番・おおよそのプレイ時間 | 一部はグレーボックスのまま | 開発チーム |
| αROM(アルファ版) | 主な機能がそろい、最初から最後まで通して遊べる段階の確認用ビルド | 全体が通るか | 仮の素材を含むことが多い | チーム・パブリッシャー |
| MVP | 学ぶための最小の製品(Eric Ries) | 顧客について学べるか | 目的しだい | 実際の顧客 |
| 体験版(デモ) | 一般に配る、ゲームの遊べる一部分 | 遊んだ人に、買いたい・ウィッシュリストに入れたいと思ってもらえるか | 製品と同じ | 一般のプレイヤー |
いくつか補足します。
- ビューティフルコーナーは、Tim Cain が制作の段階の一つとして挙げているもので、遊べないことも多い「見た目の見本」です。バーティカルスライスは、見た目に加えて、遊びと制作の流れまで通す点が違います
- ホリゾンタルスライスは、資料によって逆向きの2つの意味があります。Tim Cain は「全エリアがおおまかに遊べるが未完成(一部はグレーボックスのまま)」の版とし、エリアのつながり・探索の順番・おおよそのプレイ時間をつかむために使うと説明しています。一方、ソフトウェア開発では「技術の層ごとに別々に作り、あとで組み合わせる進め方」を指すこともあります。この連載では前者の意味で使います
- ファーストプレイアブルは、制作管理の本(Chandler)の説明として、2年の開発ならコードを提出する12〜18か月前に置く、と紹介されています(Wikipedia「Video game development」)。大きな開発での例なので、インディーにそのまま当てはめる必要はありません
- αROM は、α版の段階で提出・確認用に作るビルド(ROM)を、日本の現場でそう呼ぶことがあります(カートリッジの ROM の名残です)。α版の基準は会社やパブリッシャーとの契約で違います(「αROM(アルファ版)とは」)
- MVP は「最小限の完成品」ではありません。提唱者の Eric Ries は、最小の労力で、顧客について検証された学びを最大限集められる版と定義しています(Lean Startup Co.「What is an MVP?」)。バーティカルスライスが主に作り手の側の「作れるか」を確かめるのに対し、MVP は買い手の側について学ぶための物です
- 体験版は、宣伝のために一般に配る物です。バーティカルスライスを土台に作ることはあっても、目的が違います。スライスには仮の作りや調整前の部分が残っていても構いませんが、体験版には製品と同じ水準の安定性が必要です(出し方は「体験版(デモ)の作り方」)





似た言葉が多すぎて……むずかしいねぇ。でも「何を確かめる版か」で見分ければ、だいたい迷わないよぉ。
バーティカルスライスの目的
ひとことで:品質の基準を決め、制作の流れを一度通し、残りの量と期間を見積もり、続けるかどうかを判断するためです。
品質の基準を決める
バーティカルスライスは「このゲームの見た目と手触りは、これです」という見本になります。絵の描き込みの量、アニメーションの滑らかさ、UI の質感、音の厚み、文章の口調。以後の制作で迷ったら、スライスと見比べます。言葉で「高品質に」と頼むより、実物の見本があるほうが、チームでも外注でもぶれません。決めたことは、スタイルガイドや仕様の文書に書き残します(「ゲームアセット制作の流れ」)。
制作の流れ(パイプライン)を検証する
量産では、同じ種類の作業を何十回、何百回と繰り返します。スライスでは、キャラクター・背景・小物・UI・エフェクト・音・文章などの種類ごとに、作る→エンジンに組み込む→ゲームの中で確かめる、までを一度通します。Rami Ismail は、バーティカルスライスを「設計の試作」ではなく「制作の試作」と呼び、全種類の要素を1つずつ作って流れを通すことで、詰まる所を見つけるのだと説明しています。例えば「キャラクター1体を最後まで通したら、表情の差分の書き出しに毎回半日かかると分かった」なら、量産の前に書き出しを自動にできます。
残りの量と期間を見積もる
スライスを作る間、種類ごとにかかった時間を記録しておくと、残りの作業の見積もりに使えます。ただし、1回目の作業には試行錯誤の時間が含まれます。Rami Ismail は、2回目を作ると制作の効率がどれだけ上がるかが分かり、それが期間の見積もりに役立つと述べています。考え方の例を挙げます。
- スライスで背景1枚に3日かかり、そのうち1日は初めての試行錯誤だった
- 2枚目を作ってみたら、2日で済んだ
- 残りの背景が40枚なら、約80日。これに組み込み・修正・調整の余裕を別に足す
数字は例ですが、「1回目ではなく2回目の速さで見積もる」「余裕は別に足す」という考え方は、どの種類の素材にも使えます(スケジュールの立て方は「ゲーム開発のスケジュールとマイルストーン」)。
続けるか・やめるかを判断する
PS5 の設計を率いたことで知られる Mark Cerny は、2002年の D.I.C.E. Summit の講演で、プリプロダクションと量産は「昼と夜ほど違う」二つの段階だとし、プリプロダクションの終わりに「publishable first playable」——完全に磨き込んだゲームの一部分——を作り、それでプロジェクトを続けるか終えるかを決める、と説明しました(VGC、2020年2月の記事による)。同じ記事は、ゲーム開発の失敗の8割は、プリプロダクションでしたこと・しなかったことから直接生じる、という Cerny の考えも伝えています。日本でも、試作の審査で予算の約1割だけを承認し、その結果を見て次の予算を決める進め方が、CEDEC+KYUSHU 2023 の講演で紹介されています(4Gamer、2023年11月)。
売り込みとチームの士気
パブリッシャーや出資者に、完成した姿を見せる材料にもなります。言葉や企画書では伝わりにくい「このチームは、この品質で作れる」を、遊べる形で示せるからです。ただし Rami Ismail は、パブリッシャーの企画への関心はプロトタイプとバーティカルスライスの間でほとんど変わらず、変わるのは「作れる」という信頼のほうなので、売り込みはプロトタイプの段階から始めてよい、とも述べています(詳しくは「インディーゲームの資金とパブリッシャー」)。
チームにとっても、完成した姿を一度見ると、量産の長い期間の目標がはっきりします。



ほえ〜、失敗の8割はプリプロダクションで決まっちゃうんだぁ。最初に一部分だけ本気を出すのは、そのためなんだねぇ。
何を含め、どこを切り出すか
ひとことで:ゲームの代表的な一部分を選び、遊びの一連・本番の素材・UI・音・演出を、量産と同じ作り方でそろえます。
含めるもの
| 要素 | スライスでの状態 | 例 |
|---|---|---|
| 遊びの一連 | 始まりから終わりまで通して遊べる(入る→遊ぶ→報酬→次へ) | アクションなら、1エリアの入口からボスを倒すまで |
| 絵・3D | 製品と同じ品質で、量産と同じ作り方で作る | 背景・キャラクター・小物 |
| アニメーション・演出 | 主な動きと演出 | 攻撃・被弾・会話の演出・画面の切り替え |
| UI | 本番のデザインで操作できる | HUD・ポーズメニュー・会話の文字枠 |
| 音 | その区間の BGM・主な効果音・(あれば)声 | 曲・攻撃の音・決定の音 |
| 文章 | 本番の文体と口調 | 会話・説明文・用語 |
| 動作 | 狙う機種で、狙う快適さで動く | 目標のフレームレート・読み込み時間 |
| ビルド | 開発環境の外で起動できる実行ファイル | 他の人の PC で遊べる |
逆に、すべての機能をそろえる必要はありません。設定画面の細かい項目、セーブの全機能、難易度の切り替え、多言語対応などは、ゲームの売りに関わらなければ後回しにできます。迷ったら「この要素がないと、製品の品質で作れるかを判断できないか」で決めます。
どこを切り出すか
よく選ばれるのは、ゲームの中盤の代表的な場面です。序盤はチュートリアルが多く、終盤の山場は特別な演出が多いので、どちらも「普通の1時間」の密度を表しにくいからです。ただし、これは一つの考え方です。ゲームの売りが冒頭の体験にあるなら、冒頭を選ぶこともあります。もう一つの基準は、いちばん手間とリスクのかかる要素を入れることです。ボス戦が売りなら、ボスを1体入れます。
| ジャンル | 切り出す例 |
|---|---|
| 3D アクション | 中盤の1エリア(戦闘2〜3回・小さな謎解き・中ボス1体) |
| 2D アクション | 1ステージ(新しい仕掛け1つ・敵3種類・ステージの最後まで) |
| ノベルゲーム | 1章ぶん(背景・立ち絵の表情差分・BGM・効果音・スチル1枚・選択肢1回) |
| パズル | 1ワールドぶん(易しい問題から難しい問題への流れが分かる10問ほど) |
| カードゲーム | CPU との1試合(カードの絵・演出・効果音・UI をすべて本番で) |
どれも例です。区間の大きさは、ゲームの規模と、判断に必要な量で決めます。



中盤の「ふつうの場面」を選ぶのがコツなんだぁ。いちばんおいしい山場だけ作っても、量産の参考にならないでしょ?
バーティカルスライスの進め方
ひとことで:目的と完成の条件を先に書き、見た目の基準を小さく決めてから広げ、量産と同じ手順で作って時間を記録します。
①目的と完成の条件を書く
何を確かめるためのスライスか(例:「戦闘の手触りと、背景を量産する速さ」「会話の演出の品質と、1章ぶんの制作時間」)、期限、完成の条件、誰が遊んで判断するかを、1枚にまとめます。目的が決まっていないと、何を作り込むかが決まらず、作りすぎにつながります。
②区間と、作る物の一覧を決める
前の節の考え方で区間を選び、その区間に必要な素材・機能・文章を一覧にします。この一覧は、量産で使うアセットリストのひな形にもなります。
③見た目の基準を小さく決める
いきなり区間全体を作らず、キャラクター1体・背景1枚・UI の1画面のような小さな単位で見た目の案を作り、基準を決めてから広げます。案が2つあるなら、この段階で並べて比べます。ここで決めた1点が、スライス全体の見本になります(先に挙げたビューティフルコーナーに近い考え方です)。
④量産と同じ手順で作り、時間を記録する
残りの素材と機能を、量産と同じ道具・同じ手順で作ります。素材ごとに「作業の時間」「やり直しの回数」「詰まった所」を記録します。あとで見積もりに使うのは、この記録です。
⑤組み上げて、ビルドで遊ぶ
開発用のエディタの中だけでなく、実行ファイルにして、狙う機種で通して遊びます。読み込みの時間、フレームレート、操作の手触りは、ビルドにしないと分からないことがあります。
⑥遊んでもらい、判断する
他の人に説明なしで遊んでもらい、反応を記録します。最後に、記録から見積もりをまとめ、続ける・規模を変える・やめる、を決めます。大きな会社やパブリッシャーとの契約では、マイルストーンは支払いの条件になる成果物として決められることが多く(ゲーム専門の弁護士 Tom Buscaglia の解説、Game Developer、2005年)、スライスの出来が次の予算に関わることもあります。個人なら、この判断の場を自分で設け、日付を決めて行います。
期間と完成の判断
ひとことで:期間は作り始める前に決め、遊んだ人の反応・見積もり・文書・動作・続けるかの判断がそろったら完成とします。
期間の考え方
期間に決まりはありません。Rami Ismail は、バーティカルスライスは作るのに数か月かかり、半年以上の作業になることも珍しくない、と述べています。個人や少人数では、全体の計画に対して長くなりすぎないよう、先に期限を決めます。あわせて、「スライスの区間がゲーム全体の何分の1か」と「スライスにかかった時間」を掛け合わせ、全体の計画と食い違わないかを確かめます。例えば、全体の20分の1の区間に2か月かかったなら、同じ作り方では全体に40か月かかる計算です。2回目以降の効率を見込んでも計画に収まらないなら、量産に入る前に規模を見直すサインです。
完成の判断
次の条件がそろったら、スライスは完成と判断します。
- 遊んだ人の反応:説明なしで遊んでもらい、狙った面白さが伝わり、続きを遊びたいと言ってもらえる(「プレイテストのやり方」)
- 見積もりが出せた:素材の種類ごとの時間が分かり、残りの量と掛け合わせて期間が出せる
- 基準が文書になった:スタイルガイド・メトリクス・発注書のひな形・技術の決まりごと
- 狙う機種で動く:開発用の PC 以外でも、狙う快適さで動く
- 続けるかを決めた:このまま量産する/規模を変える/やめる、のどれかを決める
スライスの報告をまとめる
完成したら、判断に使った材料を1つの報告にまとめておきます。量産の途中で「なぜこの基準にしたのか」「見積もりの根拠は何か」を振り返るときに使えます。
| 項目 | 書くこと |
|---|---|
| 目的と範囲 | 何を確かめるためのスライスか、どの区間を作ったか |
| かかった時間 | 素材・機能の種類ごとの時間(1回目と2回目)、やり直しの回数 |
| 詰まった所 | 制作の流れで時間がかかった所と、量産までの対策 |
| 基準 | スタイルガイド・メトリクス・発注書のひな形・検収の基準の置き場所 |
| 見せかけ・手作業 | 量産では別の作り方が必要な所 |
| 遊んだ人の反応 | 伝わった面白さ、つまずいた所 |
| 見積もりと判断 | 残りの量と期間、続ける・規模を変える・やめるの結論 |
作りすぎの罠
ひとことで:磨きすぎ・その部分だけの特別な作り・見た目だけの見せかけの3つが、バーティカルスライスの典型的な失敗です。
磨きすぎて期間を食う
スライスは製品版に近い品質まで作りますが、細部まで磨き続けると終わりません。スライスの目的は、基準と見積もりを得ることで、完成品を作ることではありません。期限と完成の条件を先に決め、条件を満たしたら止めます。直したい所は一覧に残し、量産の中で直します。
その部分だけ特別な作りになる
スライスの区間だけ、手作業で一つずつ置いた演出、その場限りのプログラム、その区間でしか使えない専用の素材で作ると、見た目は良くても、量産では同じ物を作れません。見積もりも「特別な作り方」での時間になり、当てになりません。スライスは、量産と同じ道具・同じ手順・同じ仕様で作ります。手作業でしか作れない部分が出たら、「量産ではどう作るか」を書き残します。
見た目だけの「見せかけ」にする
動画や画面写真では完成して見えるのに、実際には決まった操作でしか動かない、裏で決め打ちの処理が走っている。そうしたスライスは、売り込みの場では効果があっても、自分たちの判断を誤らせます。見せかけの部分があるなら、どこがそうかを記録し、見積もりにはその部分を本物で作る時間を入れます。



スライスだけ特別扱いで作り込むの、絶対ダメだよ! 量産できない作り方だと、見積もりが全部あてにならなくなっちゃうんだぁ。
AIゲーム開発でのバーティカルスライス
ひとことで:AI で「見た目の完成度」は安く作れるようになったからこそ、量産と同じ作り方で通せたかを確かめ、決めた見た目を発注書と検収の基準に落とします。
重心はどう動くか
以前は、製品に近い見た目を作ること自体が大変で、見た目の完成度がそのまま「このチームは作れる」の証明になっていました。生成AIを使うと、それらしい絵や画面は短い時間で作れます。そのぶん、見た目だけでは「作れる」の証明になりにくくなりました。AI を使う場合、スライスで確かめるべきことは、次の2つに移ります。
- 同じ品質で量産できるか:この見た目を、数百点・数十時間ぶん、同じ品質でそろえられるか。発注→生成→検収→直しの流れが回るか
- 遊びが本当に動いているか:見た目ではなく、遊びの一連がビルドの中で通るか
AIに任せやすいこと
| 作業 | AI への頼み方 | 人が確かめること |
|---|---|---|
| スライスの組み立て | エンジンへの組み込み、演出のスクリプト、ビルドの作成 | 遊んで手触りを判断する |
| 足りない部品を埋める | 決めた仕様の範囲で、UI の部品・エフェクト・小物・足りない文章を作らせる。作った物には「仮」の印を付けさせる | 「仮」の物を確かめ、本番に残す物を決める |
| 基準を文書にする | スライスの画面から、色・線・比率・明るさなどの決まりごとを抜き出し、スタイルガイドと発注書のひな形の下書きにさせる | 何を「正」(基準)にするかを決める |
| 制作の流れを計測する | 素材ごとの作業時間・やり直しの回数・検収で不合格になった数を記録させる | 見積もりに使う数字を選ぶ |
| 検収を自動にする | 大きさ・接地(足元の位置)・身長などを機械で判定するスクリプトを作らせる | 合格の基準を決める |
決めた見た目を、スタイルガイドと発注書に落とす
生成AIは、同じ指示でも回ごとに絵柄が少しずつ揺れます。そこで、スライスで決めた見た目を、以後の生成の基準として文書にします。スタイルガイド(色・線・光・比率の決まりと、良い例・悪い例)、発注書のひな形(毎回必ず守る所と、毎回変える所)、検収の基準(何を満たせば合格か)の3つです。量産の途中で「スライスのときと何か違う」と感じたら、この3つと見比べれば、ずれた所を言葉にできます。


量産の流れを AI で回せるかを確かめる
スライスの中で、量産と同じ流れを小さく回してみます。例えば同じ種類の素材を10点、発注書→生成→検収→直しの順で作り、合格するまでの回数と、人が確かめるのにかかった時間を記録します。生成そのものは速くても、人の確認と直しに時間がかかるなら、それが量産の本当の速さです。例えば、生成は1枚あたり数分でも、選ぶ・直す・確かめるのに1枚30分かかるなら、100枚で約50時間が人の時間になります。見積もりには、この人の時間を使います。合格の割合が低いなら、量産に入る前に発注書か検収の基準を直します。
人が決めること・確かめること
- 製品の品質とは何か(どこまでを合格にするか)
- 遊んだ手触りと面白さ
- 見た目の案の選択(2案を比べて、どちらを基準にするか)
- 権利と開示(生成AIで作った素材をゲームに入れるなら、Steam では内容の申告で開示する。詳しくは「ゲーム開発の権利と規約」)
- 続けるか・やめるかの判断
落とし穴
- 見せかけになりやすい:50回生成していちばん良かった1枚は、量産で同じ当たりを出せるとは限りません。スライスの見た目が「選び抜いた1枚」なのか「毎回出せる品質」なのかを区別します
- 仮の物が残る:AI が埋めた文章や素材はそれらしく見えるので、仮のまま製品に残りやすくなります。「仮」の印と一覧を必ず残させます
- 急ごしらえのコードがそのまま本番になる:AI で素早く組んだスライスのコードを量産でも使い続けると、直すたびに別の所が壊れる原因になります。量産に入る前に、作り直す範囲を決めます
- 絵柄のぶれに気づかない:一括で生成した素材は、1枚ずつ見ると気づかない揺れを含みます。並べて検収します
依頼文は、例えば次のように書きます(書き方の基本は「Codexプロンプト設計」)。
Goal: 第1章の冒頭(約10分)を、製品と同じ品質のバーティカルスライスとして組み上げる
Context: 本文は docs/scenario/ch1.md(決まっている文はそのまま使う)。見た目の基準は docs/style_guide.md と art/reference/。
足りない文や素材は作ってよいが、必ず「仮」の印を付ける
Done when: 起動から第1章の冒頭の終わりまで通して遊べるビルドがあり、
「仮」の一覧(場所・理由)と、素材の種類ごとの作業時間を docs/slice_report.md にまとめている
筆者の実例
開発中の RPG の試作では、物語の一部分を「製品品質の縦切り」として Codex に作らせました。決まっている文章はそのまま使い、足りない文は「仮」を付けて、筆者があとから直しています。最後は筆者が最後まで遊び、「見本として完成」と判断しました。次の段階では、すぐに全体へ広げず、2〜3分の基準区間で見た目の2案を比べてから広げる計画です。
また、一括で生成した全身の絵は、キャラクターの向きによって体格が揺れることがありました。そこで、縮小した状態で検収しています。縮小して並べると、体格やシルエットの違いを見比べやすくなります。Codex には、触ってよい範囲・納品前の確認・報告書の型をまとめた AGENTS.md を渡し、作品の根幹に関わる判断は「要裁定」として筆者に残させています(「Codex AGENTS.md完全ガイド」)。



ぁぅ……AI だと、それっぽい完成画面がすぐできちゃうんだよねぇ。「毎回この品質で出せるか」まで確かめてねぇ。
よくある失敗と対処
ひとことで:スライスの「選び方」「記録」「その後の扱い」でつまずくことが多いです。
| 症状 | 主な原因 | 対処 |
|---|---|---|
| 作り込んだのに見積もりに使えない | 作業時間を記録していない | 素材の種類ごとに、時間とやり直しの回数を記録する |
| 量産に入ったら、スライスより遅い・質が落ちる | 選んだ区間が特別だった、または特別な作りをした | 中盤の普通の場面を選び、量産と同じ作り方で作る |
| スライスの後に企画が膨らむ | 見た目が良くなって、欲が出た | 足すなら何を削るかを決め、規模の表を見直す |
| スライスをそのまま体験版として公開した | 目的の違いを区別していない | 体験版は別の工程として、安定性と内容を作り直す |
| 期限を過ぎても終わらない | 完成の条件がない | 期限と完成の条件を先に決め、満たしたら止める |
| 量産の途中で見た目がぶれる | スライスで決めた基準を文書にしていない | スタイルガイド・発注書のひな形・検収の基準に落とす |
| 作り手の満足だけで終わる | 他の人に遊んでもらっていない | 説明なしで遊んでもらい、反応を記録する |
| スライスのコードが量産の足を引っ張る | 急ごしらえのコードを使い続けた | 量産の前に、作り直す範囲を決める |
チェックリスト
ひとことで:スライスを作り始める前と、完成と判断する前に、次の項目を確かめます。
- [ ] 切り出す区間を選んだ理由(代表的な場面か、いちばん手間とリスクのかかる要素を含むか)を説明できる
- [ ] 期限と完成の条件を、作り始める前に決めた
- [ ] 遊びの一連・絵・アニメーション・UI・音・文章を、量産と同じ作り方で作った
- [ ] 手作業でしか作れなかった部分と、見せかけの部分を記録した
- [ ] 素材の種類ごとに、作業時間とやり直しの回数を記録した
- [ ] 2回目の速さをもとに、残りの量と期間を見積もった
- [ ] スタイルガイド・メトリクス・発注書のひな形・検収の基準を文書にした
- [ ] 開発用の PC 以外でも起動し、狙う快適さで動いた
- [ ] 説明なしで他の人に遊んでもらい、反応を記録した
- [ ] (AI を使う場合)「仮」の一覧があり、量産と同じ流れを小さく回して合格の割合を測った
- [ ] 続ける・規模を変える・やめる、のどれにするかを決めた
次に読む記事
ひとことで:スライスで基準と見積もりが決まったら、素材の量産と、全体を通すαROM へ進みます。
- グレーボクシングとは:スライスの前に、ステージの形と寸法を灰色の箱で決める
- ゲームアセット制作の流れ:スライスで決めた基準で、素材をリスト・発注・検収で量産する
- αROM(アルファ版)とは:主な機能がそろい、最初から最後まで通して遊べる段階
- インディーゲームの資金とパブリッシャー:スライスを売り込みにどう使うか
- 体験版(デモ)の作り方:一般に配る体験版の範囲と出し方



ふぁ……一部分だけ本気で作ってみると、残りの道のりが見えてくるんだぁ。まずは小さな区間から試してみてねぇ。









