Google Playで初めてアプリを公開するとき、クローズドテストの人数と期間だけを満たしても、本番アクセスを申請する準備が完了するとは限りません。申請では、テスターがどう利用し、どんな意見が届き、それを受けて何を変えたかも説明します。
開始前に、対象アカウント、参加者の状態、テスト内容、フィードバックの記録方法を決めておくと、14日後に情報を集め直さずに済みます。
対象になるアカウントを確認する
Google Playの新しい個人デベロッパーアカウント向けテスト要件は、2023年11月13日以降に作成された個人アカウントが、新しいアプリを本番公開する前に満たす条件を案内しています。
該当する場合、本番アクセスを申請する時点で、次の状態が必要です。
- クローズドテストを実施している
- 12人以上のテスターがオプトインしている
- そのテスターが14日間連続でオプトイン状態を維持している
14日分を合計すればよいわけではありません。途中でオプトアウトした人が再参加しても、連続期間はつながらないと公式ヘルプに明記されています。締切日だけを見るのではなく、各参加者の開始日と継続状態を確認します。
組織アカウントや、基準日より前に作成した個人アカウントでは表示される手順が異なる場合があります。Play Consoleのダッシュボードにある本番アクセスの案内を確認し、自分のアカウントへ表示された条件を基準にしてください。
14日間の前にテスト計画を一枚にする
テスターへリンクだけを送ると、インストール後に何をすればよいか分かれます。最初に、短いテスト計画を共有します。
| 項目 | 決める内容 |
|---|---|
| 対象ビルド | バージョンと配布日 |
| 確認する機能 | 登録、主要操作、保存、課金前後など |
| 利用してほしい場面 | 初回利用、再起動後、通信状態の変化など |
| 報告方法 | Play Consoleの非公開フィードバック、専用フォーム、メール |
| 修正版の確認 | 直した項目を誰が、どのビルドで再確認するか |
すべての画面を網羅するよう求めるより、アプリの中心となる操作を明示します。Googleの公式案内も、探しているフィードバックの種類を伝え、できるだけ多くの機能を使ってもらうよう勧めています。
参加者の属性を集める場合は、テスト判断に必要な範囲へ絞ります。氏名や詳しいプロフィールを集めなくても、端末、OS、アプリのバージョンと、行った操作が分かれば切り分けられる問題は多くあります。
テスターの参加状態を日付で管理する
14日間は、問い合わせ件数ではなくオプトインの継続期間です。管理表には、少なくとも次を分けて残します。
- 招待した日
- オプトインを確認した日
- 14日間の完了予定日
- 途中で参加状態が変わっていないか
- フィードバックまたは確認結果
人数は12人ぴったりに固定せず、途中で参加できなくなる人がいる可能性も考えて募集します。ただし、必要人数より多く集めれば申請が自動的に通るという意味ではありません。Googleは、人数と期間に加えてテスターの関与も確認すると説明しています。
「アプリを入れたままにしてください」だけで終わらせず、オプトイン状態を14日間維持する必要があることを明確に伝えます。テスターが参加をやめる操作を誤って行わないよう、終了の連絡まではテストから退出しないことも依頼文へ含めます。
フィードバックを修正判断へつなげる
Google Playのテスト用フィードバックは非公開で、Play Consoleから確認と返信ができます。公式ヘルプでは、日付、言語、返信状態、アプリバージョン、端末などで絞り込めると案内されています。
別のフォームを併用する場合も、記録単位をそろえます。
- 何をしようとしたか
- 実際に何が起きたか
- 期待した結果
- 使用したアプリバージョン、OS、端末
- 再現する頻度
- 対応内容と再確認の結果
感想と不具合を同じ一覧に入れても構いませんが、次の行動は分けます。「文字が分かりにくい」は表示文言の検討へ進み、「保存後に消える」は再現条件とデータの状態を確認します。対応しない意見にも、対象外と判断した理由を短く残すと、後の申請回答をまとめやすくなります。
不具合報告で必要な聞き方は、アプリの不具合問い合わせで集める情報でも整理しています。
本番アクセス申請の回答材料を残す
14日間が終わってから記憶だけで申請文を書くのではなく、期間中に回答材料を更新します。Googleの案内では、本番アクセス申請で主に次を説明します。
- テスターを集める難しさ
- テスターがどの機能を、どの程度使ったか
- 想定する本番ユーザーの利用と違いがあったか
- どのようにフィードバックを集め、何が届いたか
- テストを受けてアプリへ加えた変更
- 本番公開の準備ができたと判断した理由
ここで必要なのは、良い評価だけを並べることではありません。「三件の不具合があった」など、記録していない数字を後から作らないでください。実際に残した報告、変更履歴、再テスト結果から説明します。
修正を入れなかった場合も、理由を区別します。再現しなかった、今回の公開範囲では扱わない、仕様どおりだった、次の更新へ送る、といった判断が残っていれば、テストから何を学んだかを説明できます。
IndieFormをテスター用の窓口にする場合
Play Consoleの非公開フィードバックだけで運用できるなら、別の窓口を増やす必要はありません。スクリーンショットやクラッシュ情報をTest and release内で確認でき、そこで返信まで完結するチームもあります。
アプリ内から同じフォームを開きたい場合、IndieFormでは、アプリバージョン、ビルド番号、OS、端末、言語をURL経由で問い合わせへ添えられます。テスターは操作と結果の説明に集中し、開発者は報告を環境情報と対応付けて確認できます。
IndieForm自体は、Google Playのオプトイン人数や14日間の継続を計測せず、本番アクセスの承認も保証しません。参加状態はPlay Consoleで確認し、フォームはフィードバックと対応履歴を残す用途に限定します。
申請前に記録を点検する
本番アクセスを申請する前に、次の順で確認します。
- 対象の個人アカウントへ表示された条件を読み直した
- 12人以上が14日間連続でオプトインしている
- 中心機能を使ってもらった記録がある
- 届いたフィードバックを要約できる
- 修正した内容と再確認の結果を説明できる
- 本番公開できると判断した根拠がある
Google Playの要件や申請画面は更新される可能性があります。人数や期間を古い解説だけで決めず、申請時に公式ヘルプとPlay Consoleを開き直してください。14日間を待機期間ではなく、公開判断の証拠を作る期間として設計すると、申請後の運用にも使える記録が残ります。