アプリのベータテストの進め方

ベータテストを行うには、何を知りたいのかを決め、実際のユーザーに近い少人数を招待し、最初に取り組むべき明確な課題を与え、決まったスケジュールで1か所にフィードバックを集めます。テストを妨げている問題を直し、段階的に対象を広げ、事前に決めた終了基準を満たしたときにベータを終えます。飽きたときではありません。

ベータは、ソフトローンチとは違います。開始、終了、答えるべき問いのある、構造化された実験です。

ベータの位置づけ

アイデアの検証では、その問題が解決する価値があるかを問います。ベータでは、より狭い問いを立てます。このバージョンの製品は、実際の状況で、実際の人々にとって問題を解決しているか？ ローンチは、その答えがほぼ「はい」になってから行います。

誰かを招待する前に、まずご自身でテストしてください。ローンチ前にアプリをテストする方法で説明しています。テスターが、サインアップが動かないことを発見する立場になってはいけません。

ステップ1：ベータで何を明らかにすべきかを書き出す

2〜3個の問いを選びましょう。計画の他のすべては、その問いから決まります。

架空の例： 小さなカフェ向けのシフト管理アプリは、2つの目標を設定しました。「マネージャーは、初回のセッションで助けを借りずに1週間分のシフト表を公開できるか？」と「スタッフは2週目に、自分からアプリを開くか？」です。

ステップ2：ベータの種類を選ぶ

初めての製品なら、数ラウンドに分けたクローズドベータが通常は最適です。

ステップ3：適切なテスターを集める

最適なテスターは、今まさにその課題を抱えていて、ターゲットとなるユーザーに合っており、ベータ期間中にアプリを試す時間がある人です。見つける場所は次のとおりです。

• ウェイトリストやメールリスト。ローンチ前に見込み客を集める方法をご覧ください。
• 課題を検証する際にインタビューした人。
• ユーザーが集まるニッチなコミュニティ。ただし、そこでの宣伝ルールには従ってください。
• ネットワークの中で、条件に合う人への直接の招待。

いくつかのスクリーニングの質問をして、バランスの取れたメンバーを選べるようにしましょう。たとえば、役割、今どのようにその課題を解決しているか、使う端末、その課題がどのくらいの頻度で発生するかです。回答がターゲットとなるユーザーに合う人を招待してください。ターゲットとなるユーザーが自分たちの仲間でない限り、ベータを創業者仲間だけで埋めないようにしましょう。

招待文の例

[名前]さん、サインアップ時に[課題]についてお話しいただきましたよね。[製品]の小規模な非公開ベータを始めることになりました。これは[成果]を実現するものです。期間は[開始]から[終了]までです。テスターの方には、少なくとも週に1回、[実際の作業]のために使っていただき、毎週金曜日に短いチェックインに答えていただくことをお願いしています。お礼として、ベータ期間中は無料でご利用いただけ、さらに[創業者価格 / 無料期間の延長]を提供します。ご興味ありますか？

時間の負担については、正直に伝えてください。何に参加するのかを分かっている人のほうが、質の良いフィードバックをくれます。

ステップ4：ベータ用の準備一式を整える

最初の招待を送る前に、次を用意しておきましょう。

• ようこそメッセージ。 リンク、サインイン方法、最初に試してほしい作業、問題の報告方法を書きます。
• 既知の問題の一覧。 テスターが同じ問題を10回報告しないようにするためです。
• フィードバックの窓口を1つに。 フォーム、共有チャットのグループ、メールアドレスなど、1か所にまとめます。5か所ではありません。
• バグ報告のテンプレート。 やったこと、期待したこと、実際に起きたこと、端末とブラウザ、スクリーンショットを聞きます。共有できるバージョンは良いバグレポートの書き方にあります。
• 基本的な分析またはログ。 記憶に頼らず、何が起きたかを確認できるようにします。
• データに関する明確な説明。 ベータ中にデータがリセットされる可能性があるなら、テスターに伝えてください。未完成のアプリに機微な情報を入力させてはいけません。
• 利用規約とプライバシーの基本事項。 短いベータ契約書とプライバシーの説明を用意します。個人データを扱う場合は、地域のルールや専門家の助言を確認してください。

ステップ5：ラウンド制で実施する

ラウンドごとに分けることで、より多くの人が問題に出会う前に直すことができます。

ラウンド1では、テスター2〜3人に、初めてアプリを試している様子を画面共有してもらいましょう。静かに見守り、どこでためらうかを観察してください。ベータ全体で最も有益な1時間になることがよくあります。

ステップ6：リズムを決めてフィードバックを集める

「何かフィードバックはありますか？」という漠然としたメッセージでは、曖昧な回答しか返ってきません。その代わりに、短く定期的なチェックインを行いましょう。

毎週のチェックイン（架空の質問例）

1. 今週、[製品]を何に使いましたか？
2. 不満に感じたことや、分かりにくかったことは何ですか？
3. 作業を完了するのを妨げた、足りなかったものはありましたか？
4. もうこの製品を使えなくなったら、どう感じますか？（非常に残念 / ある程度 / まったく）
5. その他、何かありますか？

本人の言葉と、本人の行動を組み合わせて見てください。素晴らしいと言いながら一度もログインしない人も、何かを伝えています。

ステップ7：届いた内容を仕分ける

すべてのフィードバックを1つのリストにまとめ、毎週仕分けしましょう。

ベータの途中で大きな機能を追加することは控えてください。機能を追加するたびに、コアとなる製品が機能しているかを判断しにくくなります。

ステップ8：フィードバックの輪を閉じる

テスターは、自分の意見が使われていると分かると、フィードバックを続けてくれます。

• ラウンドごとに短い変更履歴を送る。「ご報告いただいたXを修正しました」。
• テスターの報告が修正につながったときは、個別に名前を挙げてお礼を伝える。
• ベータが終わるときは、テスターに伝える。データやアカウントがどうなるか、そして創業者向けの特典は何か。

ステップ9：ローンチの準備ができたかを判断する

ベータを始める前に終了基準を書き出し、終わりに正直にチェックしましょう。テンプレートは次のとおりです。

• ブロッカーやデータ消失のバグがない
• 新しいテスターの大半が、助けなしでコアの作業を完了する
• 後の週に、多くのテスターが自分から戻ってくる
• 上位の混乱のポイントを直し、再テストした
• サインアップ、パスワードの再設定、支払いの流れが最初から最後まで動く
• テスターの言葉で、この製品が誰のためのものかを明確に伝えられる

ほとんどの項目にチェックが入ったら、オンボーディングを磨き、公開ローンチに進みましょう。利用の戻りが少ない場合は、それはバグの一覧の問題ではなく、製品の問題です。ローンチする前に、インタビューに戻りましょう。

Mythexでベータを行う

Mythexで作っている場合、いくつかの機能がベータにうまく対応します。

• ラウンド1のプレビューリンク。 共有ボタンで、ライブのプレビューへのリンクを作成できます。Mythexのアカウントがない人でも使えるため、公開前の未完成の作業を、初期のテスターに試してもらえます。グループごとにリンクを1つ作り、終わったら削除してください。リンクがプロジェクトを起動し、クレジットを使う仕組みについては、プレビューのドキュメントをご覧ください。
• 長いラウンドには公開する。 公開したアプリは独自のアドレスで動くため、数週間にわたって使うテスターに適しています。
• 各ラウンドの前にApp Testing。 チャットで/testと入力すると、エージェントがプレビューをクリックして回り、壊れている流れを報告します。テスターを招待する前の有効な確認です（App Testingのドキュメント）。
• チェックポイント。 ベータの途中で修正によって何かが壊れたら、以前のチェックポイントに戻せます。

テスターのバグ報告をチャットに貼り付け、エージェントに再現と修正を依頼してください。修正が反映されたら、テスターに知らせましょう。

よくある質問