MOBILE GAME RELEASE QA

モバイルゲームの公開前QAで
「再現できない」を減らす、4つの証跡

不具合の件数を増やすより、開発者が同じ状態を再現できる報告を残す。小規模チームでも回せる公開前チェックの組み立て方を整理します。

曲刚（Gang Qu）｜2026年8月1日

「ホーム画面で落ちました」。この一文だけでは、担当者はビルドを探し、端末を推測し、プレイヤーが何をしたかを聞き直すところから始めます。修正時間より確認時間の方が長くなりやすい報告です。

公開前QAで価値があるのは、発見した人の記憶に頼らず、別の担当者が同じ状態へ戻れる証拠です。最低限、次の4点を一つの報告にまとめます。

ストアの自動テストを「入口」にする

Google Playの公開前レポートは、アップロードしたアプリを複数のテスト端末で自動操作し、安定性、Android互換性、パフォーマンス、アクセシビリティ、セキュリティの問題候補を示します。端末差を広く見る入口として有効です。

AppleのTestFlightでは、テスターがスクリーンショット、コメント、クラッシュに関する情報を送れます。App Store Connectでは、プラットフォーム、OS、ビルド、端末などでフィードバックを絞り込めます。

機能名ではなく、失敗した時の影響で並べる

チェック項目を画面順に並べると、軽微な表示崩れと進行不能が同じ一行になります。公開判断では、プレイヤーへの影響と復旧手段を基準にした方が優先順位を共有しやすくなります。

30分で作る受け入れパック

1. 今回の変更で売上、継続率、プレイヤーデータに影響するシナリオを3件に絞る。
2. 各シナリオに、開始条件、操作、期待結果、必要証跡を一行ずつ書く。
3. 対象ビルドと端末一覧を固定し、実行者が変わっても同じ条件を使えるようにする。
4. 失敗報告には、ビルド、端末、操作経路、期待値と実結果がそろっているかを確認する。
5. 修正後は同じ手順を再実行し、結果と証跡を更新する。

この形にすると、「確認済み」という言葉を、誰でも追える記録へ置き換えられます。公開直前に必要なのは長い報告書ではありません。チームが同じ判断を繰り返せる、小さく明確な受け入れパックです。