※本記事にはアフィリエイトリンク（広告）が含まれます。Amazonのアソシエイトとして、ゲームのタネは適格販売により収入を得ています。
作品が一通り動くようになると、今度は細かな気になるところが増えてきます。もう少し画面を整えたい。別の表現も試したい。でも、直し続けていると、いつ公開するかが決まりません。
公開前に、今回の完成形を使える状態にする条件と、その確認方法を書いておきましょう。見つかった問題をその条件に照らせば、必ず直すものと、公開後に検討するものを分けやすくなります。
この連載では完成形、機能、試作、素材や画面の範囲を考えてきました。最終回では、それらを実際に確認し、公開するか判断するところまで整理します。
「完成」の条件を、確認できる形にする
「ちゃんと遊べる」「エラーがない」だけでは、何を確かめればよいか曖昧です。第1回の完成形を、開始から終了までの具体的な操作に分けます。
例えば、架空の探索ゲームなら「対応する環境で起動し、手掛かりを調べて謎を解き、結末まで進める」。画像の幅をそろえる架空のツールなら「対応する画像を選び、幅を指定し、変換結果を安全に保存して確認できる」といった条件です。これは説明用の設計例で、実際の検証結果ではありません。
そのうえで、対象環境、確認する操作、期待する結果、記録先を決めます。ゲームには中断・再開や必要な操作方法、ツールには元ファイルの扱い、上書き防止、失敗時の案内なども、今回の仕様に沿って含めます。入力方法や文字の読みやすさについても、想定する利用者に必要な条件を決めます。
確認していないことを、完了にしない
公開前には、使う人がたどる流れを実際の配布物で通します。開発中の画面で動いたことと、公開するファイルを別の環境で起動できることは別の確認です。
| 確認すること | 探索ゲームの例 | 画像ツールの例 |
|---|---|---|
| 配布物を使い始める | 指定環境で起動し、操作方法が分かる | 対応環境で起動し、対象画像と保存先を選べる |
| 最後まで進む | 手掛かりから結末まで通して遊ぶ | 画像を変換し、保存結果を開いて確認する |
| 失敗や中断 | 不正な操作や中断後の扱いを確かめる | 非対応ファイル、保存失敗、既存ファイルの扱いを確かめる |
| 人に伝える情報 | 対応環境、操作、中断方法を知らせる | 対応形式、出力先、元画像の扱いを知らせる |
同じゲームでも分岐や操作方法が複数あるなら、どの経路を実際に通し、どれをまだ確認していないかを残します。一つの経路を通せたことは、全分岐の確認にはなりません。確認に使ったバージョンと環境も記録しておきます。
問題を、公開への影響で分ける
見つかった問題は、見た目の大小だけでなく、利用者が何を失うかで判断します。
| 状況 | 今回の判断例 |
|---|---|
| 起動できない、結末に進めない、保存データが壊れる | 原因を調べ、修正して再確認する。解決できなければ公開を延期するか、対象環境を狭める |
| 画像の上書きや送信について、利用者が判断できない | 動作と説明を整え、安全に利用できることを確認する |
| 文字が読みにくく、対象者が必要な操作を選べない | 対象環境・利用者に必要な読みやすさを満たしてから公開する |
| 雰囲気を豊かにする追加演出を思いついた | 今回の体験に不可欠かを確認し、必須でなければ後で検討する |
| 対応予定外の環境で未確認の問題がある | 対応範囲を正確に伝え、対応を約束する前に確認する |
表は判断例です。既知の問題を後回しにするときは、発生条件、影響、回避方法の有無を記録します。利用者に影響する制限は公開時に分かるように伝え、未確認のことを「問題なし」と書かないようにします。
公開後の改善を予定していても、必ず実施できるとは限りません。後で検討する案と提供を約束した機能を分けて管理します。
『Factorio』は1.0を開発の終わりとはしていない
『Factorio』の開発ブログは2019年、既存部分を磨き続けるだけでは開発が長引くという認識から、1.0の公開日を決め、期日に向けて重要な点に集中する方針を説明しました。同時に、1.0は開発の終了や作品が完全に終わったことを意味しないと記しています。Factorio開発ブログ：Countdown
この事例は、公開の区切りと、その先の開発を分けて考える参考になります。ただし、ブログだけでは個々の不具合の公開判断やテスト結果までは分かりません。既に公開されていた大規模なゲームと、初めて配布する個人作品では条件も異なります。日付を決めれば安全に公開できるという意味ではありません。
自作では、日付と一緒に「満たせなければ延期する条件」も書いておきます。例えば、セーブデータが壊れる問題や、画像を意図せず上書きする問題が残るなら、原因と影響を確かめてから判断します。
公開するファイルで、最後にもう一度確かめる
修正が終わっても、その後に別のファイルを公開すれば、確認した結果と実際の配布物がずれてしまいます。公開予定のファイルを識別できる名前やバージョンで残し、それを使って最初から最後まで確認します。
不具合を修正したときは、直した操作だけでなく、その変更で影響を受けそうな周辺も再確認します。例えば保存処理を変えたなら、通常の保存に加えて、既存ファイルがある場合や保存に失敗した場合を、対象環境で試します。すべての組み合わせを試せないときは、確認した範囲と残った不確実さを記録します。
公開の直前に変更を加えた場合も、その変更を含む配布物で必要な確認をやり直します。未確認の配布物を、直前の別バージョンの結果で「確認済み」とは扱いません。
終了条件と公開後の窓口を一枚にまとめる
| 書き出すこと | 自分の作品のメモ |
|---|---|
| 今回の完成形と対象環境 | ＿＿＿＿＿＿＿＿ |
| 必ず通す操作と、期待する結果 | ＿＿＿＿＿＿＿＿ |
| データ・安全性・利用に必要な情報の条件 | ＿＿＿＿＿＿＿＿ |
| 確認した配布物、バージョン、環境、結果 | ＿＿＿＿＿＿＿＿ |
| 既知の問題、影響、回避方法、伝え方 | ＿＿＿＿＿＿＿＿ |
| 満たせなければ延期・対象縮小する条件 | ＿＿＿＿＿＿＿＿ |
| 公開後の連絡先と、対応できる範囲 | ＿＿＿＿＿＿＿＿ |
| 今回は確認できていないこと | ＿＿＿＿＿＿＿＿ |
一つでも公開条件を満たせていなければ、修正、対象の見直し、延期を選べます。条件を満たした場合も、確認結果と既知の制限を残したうえで公開します。公開後に反応を見て改善する方法は、マーケティング入門第9回も参考にしてください。
最初の完成形から見直したいときは第1回、残す機能で迷ったときは第2回に戻れます。完成条件は、作ったものを安全に届けるための判断に合わせ、制作中に更新して構いません。
ゲーム制作の企画を本で学びたい方へ
制作管理やゲーム開発の本を探すときは、対象となる作品の規模、テストや公開準備を扱う範囲を目次で確認してみてください。
リンク先は書籍の検索結果です。特定の本を推薦するものではありません。価格、刊行年、対象読者を確認して選んでください。
事例は2026年11月4日に開発ブログを確認しました。作品の実機検証や、当時の公開前テストの完了状況は確認していません。
