BetaLobbyテスターを 12 人集め、クローズド テストを 14 日間続けて、ダッシュボードで 本番環境へのアクセスを申請 をクリックすると、質問票が表示されます。3 つのパートに分かれた 9 つの質問で、7 問はテキスト ボックス（各 300 文字まで）、2 問は単一選択です。
私のアプリが却下されたときの回答は中身が薄く、「テスターはすべての機能を使い、すべて想定どおりだった」といった内容でした。通過したときは、すべての回答を具体的な事実に書き換えました。
Google は質問票の評価基準を公開していないので、ここに書くのは公式の回答ではなく、私の経験です。例はすべて架空の家計簿アプリのもので、書き方を示すためだけのものです。そのままコピーしないでください。
書き始める前に知っておきたい 4 つのこと
- 閉じると内容が消える：途中で閉じようとすると フォームを閉じますか？ と表示され、ボタンは 閉じて破棄 です。先に別の場所で書いておき、あとから貼り付けることをおすすめします。無料の 製品版へのアクセス申請の質問票 も使えます。Play Console と同じ 9 つの質問がそのまま並び、文字数の数え方も同じで、下書きは自分のブラウザの中にだけ保存されます
- 最後のボタンは「適用」：Apply の直訳で、クリックすると申請が送信されます。下書きの保存ではありません
- 文字数に気をつける：英語で書く場合、300 文字は 50 語ほどしかなく、1 文ごとに中身が必要です。私は各回答 260 文字前後を目安にしています。下の日本語の「具体的な例」は、英語にすると 190～280 文字ほどです
- 何語で書くか：ヘルプ センターでは、言語に関する要件は見つけられませんでした。私は英語で回答しました
パート 1：クローズド テストについて
実際にやったことを聞かれるパートです。中身が薄くなりやすく、事実との食い違いも起きやすいところです。
1クローズド テストのユーザーをどのように募集しましたか？
クローズド テストのユーザーをどのように募集しましたか？（例: 友人や家族を誘った、有料のテスト提供者を利用した）
募集した経路と人数を正直に書きます。有料サービスについても同じです。質問自体が募集方法の 1 つとして挙げているので、隠したり作り話をしたりするほうがリスクになります。
- あいまいすぎる例：ネットでテスターを募集しました。
- 具体的な例：Android デベロッパーのコミュニティ 2 つと職場の同僚に声をかけ、18 人が参加しました。有料のテスト サービスは使っていません。うち 5 人は普段から家計簿をつけていて、想定ユーザーに近い人です。
2アプリのテスターは簡単に募集できましたか？
アプリのテスターは簡単に募集できましたか？
単一選択：とても難しい、難しい、どちらでもない、簡単、とても簡単。正解はないので、実感どおりに選べば大丈夫です。
3クローズド テスト中にテスターが行った操作について説明してください
クローズド テスト中にテスターが行った操作について説明してください
質問の下のヒントでは、次の 2 つを書くよう求められています。テスターが すべての機能を使用したかどうか、そして 実際のユーザーに想定していた使い方と一致していたか です。違っていた場合は、その違いを説明します。
「全員がすべて使い、想定どおりでした」と書く人は多いのですが、これはあまり信じてもらえないでしょう。実際のテストがそこまできれいに揃うことはほとんどないからです。想定と違った点を書くほうが、かえって信頼できます。
次の 3 点を書くとまとまります。
- よく使われた機能：多くの人がよく使っていたもの
- あまり使われなかった機能：一部の人しか触らなかったもの、誰も使わなかったもの
- 想定との違い：たとえば、毎日使われると思っていたのに最初の数日だけだった、ある手順で多くの人がつまずいた、など
テスターが具体的に何をしたかわからなくても、珍しいことではありません。統計情報 では毎日何人がアプリを開いたかはわかりますが、どの機能を使ったかはわかりません。次の方法で確かめられます。
- 直接聞く：テスターのグループや個別のメッセージで数人に、どの機能を使ったか、どこでつまずいたかを聞きます。質問票を書くときではなく、テスト中に聞くのがおすすめです
- アプリ側のデータを見る：Firebase のような分析ツールを入れている、またはサーバーに記録があるなら、どの機能が使われたかを直接確認できます
- フィードバックを見る：ある機能の問題を報告した人は、少なくともその機能を使っています
もう聞ける相手がおらず、データもない場合は、確実にわかっていることだけを書き、その事情も説明します。自分でテストして見つけた問題を書いても構いません。自分で見つけたと明記すれば大丈夫です。見栄えをよくするために、全員がすべての機能を使ったとは書かないでください。
- あいまいすぎる例：テスターはすべての機能を使い、想定どおりの使い方でした。
- 具体的な例：ほとんどの人が毎日支出を記録し、月間の集計を確認していて、想定どおりでした。複数の帳簿とエクスポートを使ったのは一部の人だけでした。実際のユーザーも最初はあまり使わないと考え、この 2 つは設定画面に移しました。最初の数日しか熱心に記録しなかったテスターもいました。
- 具体的な利用状況がわからない場合：アプリに利用状況の分析を入れていないので、テスター 6 人に聞きました。全員が記録と月間の集計を使い、エクスポートを試したのは 1 人だけで、ほぼ想定どおりでした。2 人がエクスポートの場所を見つけられなかったので、位置を変えました。
私自身のアプリは、デベロッパーがチームを組んでお互いのアプリをテストするプラットフォームです。通過したときのこの質問の回答は、おおよそ次のような内容でした。一部のメンバーのアプリが起動直後にクラッシュしてチェックインできなかった、数人のテスターが途中でアンインストールした、それぞれに合わせて流れを調整した。どれもいい話ではありませんが、すべて実際に起きたことです。
4テスターからのフィードバックについて、概要を記入してください
テスターからのフィードバックについて、概要を記入してください。フィードバックの収集方法も記入してください。
書くことは 2 つです。どんなフィードバックを受け取ったか と どう集めたか です。集める方法には、メール、アプリ内フォーム、コミュニティなどがあります。テスターは Google Play から非公開でフィードバックを送ることもでき、モニタリングと改善 > 評価とレビュー > テストのフィードバック で確認できます。
ですから、申請のときに思い出そうとせず、初日からフィードバックを記録しておきましょう。あまり届かなかった場合はそのまま書き、ほかに何をしたか（誰に直接聞いたか、自分で何を見つけたかなど）を説明します。作り話はしないでください。
- あいまいすぎる例：テスターの反応はよく、大きな問題は見つかりませんでした。
- 具体的な例：アプリ内のフィードバック フォームとテスターのグループで集めました。主に 3 つで、Android 12 の端末 2 台でのエクスポート時のクラッシュ、記録までの手順の多さ、ダークモードでのグラフの見にくさです。週間集計の要望もあり、これは検討中です。
パート 2：アプリに関する情報
このパートで聞かれるのはテストではなく、アプリが誰のためのもので、何の役に立つかです。
5アプリの対象ユーザーは誰ですか？
アプリの対象ユーザーは誰ですか？
ヘルプ センターでは、できるだけ具体的に書くよう求められています。「すべての人」ではなく、どんな人がどんな場面で使うのかを書きます。
- あいまいすぎる例：家計を管理したいすべてのユーザー。
- 具体的な例：支出の管理を始めたばかりの若い社会人。特に、毎日数秒で記録を済ませたい人や、複雑な家計簿アプリの使い方を覚えたくない人。
6アプリがユーザーにどのような価値をもたらすのか説明してください
アプリがユーザーにどのような価値をもたらすのか説明してください
ポイントは、機能を並べることではなく、ユーザーのどんな問題を解決するかです。ヘルプ センターによると、ゲームの場合はそのゲームならではの特徴を書きます。
- あいまいすぎる例：機能が豊富で、デザインがよく、使いやすいアプリです。
- 具体的な例：家計簿が続かないのは、記録のたびに入力項目が多すぎるからです。このアプリは 2 ステップで記録でき、毎月の支出先を自動で集計するので、データを整理しなくてもお金の行き先がわかります。
7アプリの初年度のインストール数はどれくらいを想定していますか？
アプリの初年度のインストール数はどれくらいを想定していますか？
単一選択：0～1 万、1 万～10 万、10 万～100 万、100 万以上、わからない。これも正解はありません。実際の見込みで選び、見当がつかなければ わからない で構いません。見栄えのために高く選ぶ必要はありません。
パート 3：製品版の準備状況
本当に改善を重ねてきたかがいちばん表れるパートで、事前の準備がいちばん必要なところでもあります。
8クローズド テストでわかったことに基づいて、アプリにどのような変更を加えましたか？
クローズド テストでわかったことに基づいて、アプリにどのような変更を加えましたか？
具体的な変更を書きます。質問 4 のフィードバックと対応していて、テスト中に実際にリリースしたバージョンとも一致しているのが理想です。フィードバックがなくても問題ありません。自分で見つけた問題や リリース前レポート で見つかった問題も書けます。
ですから、テスト中は実際に変更を加えたバージョンを何度か出し、そのたびに何を変えたかを記録しておきましょう。
- あいまいすぎる例：いくつかのバグを修正し、使い勝手を改善しました。
- 具体的な例：Android 12 でのエクスポート時のクラッシュを修正し、記録ボタンをホーム画面に移して手順を 4 ステップから 2 ステップに減らし、ダークモードのグラフの配色を調整しました。テスト中に 4 つのバージョンをリリースしました。週間集計は未対応で、製品版の公開後に予定しています。
9アプリが製品版として準備ができたかどうかを、どのような方法で判断しましたか？
アプリが製品版として準備ができたかどうかを、どのような方法で判断しましたか？
判断の根拠を書きます。たとえば、主な流れがひととおり動いた、フィードバックの深刻な問題を直した、最近のいくつかのバージョンで具体的にどの問題が出なくなったか、などです。
最後に、プライバシーとデータの安全性に関する Google Play のポリシー要件を満たしていると添えてもよいでしょう（実際に確認している場合に限ります）。これはあくまで補足で、中心はテストから得た根拠です。
「バグは一切ありません」とは書かないでください。実際には終わっていないことを終わったと言うのもやめましょう。未解決の小さな問題があるなら、主な使い方には影響しないことと、どう対応するつもりかをはっきり書くほうが信頼できます。
- あいまいすぎる例：アプリは十分に完成しており、公開できます。
- 具体的な例：記録、集計、エクスポートといった主な流れはテスターの端末で正常に動作し、報告されたクラッシュは修正済みで、直近 2 つのバージョンでは新しいクラッシュの報告はありません。週間集計など中心ではない要望は、製品版の公開後に対応します。プライバシーとデータの安全性に関する Google Play のポリシー要件も満たしています。
再申請する場合
テキスト ボックスには前回の回答がすでに入った状態になっています。そのまま 次へ を押さず、1 問ずつ見直して、今回の状況に合わせて書き換えてください。
前回から何を変えたかを聞く質問も追加されます。新しい募集方法や、今回出したアップデートなどを書くとよいでしょう。前回却下された理由がまだわからない場合は、先に Google Play「More testing required」で却下される 5 つの理由と対策 を読んでみてください。
提出前の最終チェック
- すべての回答が実際に起きたことで、作り話や誇張がない
- 質問 4 のフィードバックと質問 8 の変更が対応している
- 質問 8 の変更と実際にリリースしたバージョンが一致している
- 7 つのテキスト ボックスを十分に書き、文法も整っている。AI に文法をチェックしてもらうのは構いませんが、一から書かせないでください。なかったことを簡単にでっち上げてしまいます
どんなによい回答でも、本物のテストの裏付けが必要です。製品版へのアクセスが認められるかどうかは最終的に Google 次第ですが、質問 3 と質問 4 に書く内容は、14 日間で少しずつ積み上げていくものです。
まだ 12 人のテスターを探しているなら、BetaLobby を見てみてください。デベロッパー同士でチームを組んでクローズド テストを助け合うプラットフォームで、16 人のデベロッパーが 1 チームになり、14 日間お互いのアプリをテストします。毎日のチェックインでは実際にあなたのアプリが開かれ、毎日何人がチェックインしたかを確認でき、デバイス情報つきのフィードバックも受け取れます。