チーム内では、プロダクトはお決まりのペースで動いています。見慣れたアカウント、予測しやすいデータ、そして操作でつまずいても近くに説明してくれる誰かがいます。しかしベータ版になると、チームのコントロールが及ばない状況が生まれます。参加者はそれぞれ異なるデバイス、作業習慣、期待値を持ってやってきて、自分たちの日常の合間にプロダクトを使います。

ベータテストとは、一般公開の前に課題を見つけ、開発の方向性を定めるための外部利用期間です。信頼性の問題や足りない機能、体験全体の使いづらさなどを洗い出すことができます。合意された用途に耐えうる品質は必要ですが、ベータ版だからといって予定しているすべての機能が完成している必要はありません。GOV.UKのベータフェーズに関するガイダンスでも、必要に応じてまずは限定的な規模から始め、実際のユーザーとともに開発と学びを継続していくことについて触れられています。

ベータ版で何を確かめたいのかを決める

「フィードバックを得る」だけでは目的が曖昧すぎて、効果的なテストを組み立てられません。たとえば、新しいインポート機能がユーザーの実際のファイルで機能するか、手厚いサポートがなくてもスムーズに使い始められるか、あるいは多様な条件下でもサービスが安定して稼働し続けるか、といった具体的な検証が必要です。こうした問いによって、誰に参加してもらうべきか、どんなデータを集めるべきかが決まります。

たとえばレポートツールのベータ版なら、扱うデータの種類やITリテラシーのレベルが異なる人たちを対象に含めるとよいでしょう。熱心な既存顧客だけに声をかければ参加者集めは楽になりますが、初めて使う人が定着できるかどうかの検証には限界があります。結果を分析する際には、そうした前提条件もしっかり意識しておきましょう。

参加者には、プロダクトの成熟度や現時点でわかっている制限事項、問題の報告方法、受けられるサポートについて事前に伝えておく必要があります。未完成の機能が重要な作業に影響を与える可能性がある場合は、現実的な代替手段を用意してください。また、参加者の時間を尊重したフィードバック方法を用意することも大切です。長文のアンケートに定期的に回答してもらうよりも、気づいた問題をサッと報告できるシンプルな仕組みのほうが、お互いにとって負担になりません。

日常的な利用とピンポイントな調査を組み合わせる

利用ログやサポートへの問い合わせを見れば、どこで問題が起きているかが分かります。そして、インタビューや的を絞ったユーザビリティテストを行えば、その背景にある理由を深掘りできます。何の連絡もしてこない参加者は、満足しているのかもしれませんし、忙しくて返信できないだけかもしれません。あるいは、すでに使うのを諦めてしまった可能性もあります。「何も言ってこない」ことは、「すべて順調である」証拠にはなりません。

意思決定に活かせるよう、各問題の発生バージョン、状況、深刻度を記録しておきましょう。めったに起きないデータ消失の問題と、頻繁に起きる見た目上の些細な問題とでは、対応の優先度がまったく異なります。対象範囲を広げる前に何を解決しておくべきかをあらかじめ合意し、集まった情報をもとに判断してください。

ベータ版が真価を発揮するのは、得られた知見に対してチームがまだ柔軟に対応できるときだけです。検証や改善の時間を取らないまま「ベータ版」と銘打ってリリースするのは、未完成のツケをユーザーに押し付けているだけにすぎません。