ブログ

クローズドβでのフィードバック収集設計

TL;DR

クローズドβでのフィードバック収集は、参加者全員が使える単一の場所を用意し、そこに気づいたことを気軽に投稿してもらう設計が基本です。個別インタビューだけに頼ると声を拾い切れず、かといって公開ボードをそのまま使うと少人数特有の文脈が失われます。ベータ専用の場所を用意し、正式公開時に運用を切り替えるのが現実的です。

クローズドβでのフィードバック収集設計は、参加者全員がいつでも投稿できる単一の場所を用意し、気づいたことを気軽に書いてもらう仕組みを作ることが基本になります。参加人数が少ないからこそ、個別インタビューだけに頼りたくなりますが、それだけでは日々の細かい気づきを取りこぼしてしまいます。

なぜクローズドβのフィードバックは特別扱いが必要なのか

クローズドβの参加者は、正式公開後の一般ユーザーとは前提が異なります。プロダクトが未完成であることを理解した上で使っており、初期バグや分かりにくい導線について、通常より踏み込んだ指摘をしてくれる傾向があります。この文脈のある声を、正式公開後の一般的な要望と同じ場所で扱ってしまうと、「ベータ版だから仕方ない」で片付けられるはずの声と、正式版で本格的に検討すべき要望が混ざり、あとから仕分けし直す手間が発生します。

インタビューと投稿できる場所を両輪で使う

インタビューは、参加者がなぜそう感じたかという背景まで深く聞ける一方、実施できる人数・頻度には限りがあります。全参加者に均等にインタビューする時間は取れないことがほとんどです。そこで、インタビューとは別に、参加者が気づいた瞬間にすぐ書き込める場所を用意しておくと、インタビューで拾いきれない日々の小さな気づきも記録できます。定量と定性のバランスをどう取るかという論点は、ベータに限らずフィードバック収集全般に共通する課題です。

着目してほしい観点を先に伝えておく

クローズドβでは、何も指定せずに「自由にフィードバックしてください」と伝えるより、「詰まった箇所」「初見で分かりにくかった表現」など、着目してほしい観点をあらかじめ伝えておくほうが、実用的なフィードバックが集まりやすくなります。参加者は何もかも報告する必要はないと分かると、逆に報告のハードルが下がる傾向があります。

ベータ専用の場所を用意し、正式公開時に切り替える

クローズドβの声を、正式公開後に使う公開ロードマップとは別の場所で集めておくと、ベータ特有の文脈を保ったまま扱えます。正式公開のタイミングで、ベータ中に集まった声のうち今後も追いかけるべきものを公開ボードへ引き継ぎ、運用を切り替えるという流れが現実的です。公開後のロードマップ運用については「プロダクトロードマップを顧客に公開するメリットと注意点」で扱っています。

まとめ

クローズドβでのフィードバック収集は、インタビューと、参加者が気軽に投稿できる場所を両輪で用意し、着目してほしい観点を先に伝えておくことで、拾える声の質と量のバランスを取れます。ベータ専用の場所を用意しておき、正式公開のタイミングで公開ボードへ運用を引き継ぐ設計がおすすめです。実際の投稿・ステータス管理の様子はデモボードで確認できます。

よくある質問

クローズドβでは個別インタビューだけで十分ではないですか?

インタビューは深い文脈を拾えますが、実施できる人数と頻度に限りがあります。インタビューと、参加者が気づいた時にすぐ投稿できる場所を併用すると、拾える声の量と質のバランスが取れます。

クローズドβの声を最初から公開ボードで集めてもいいですか?

技術的には可能ですが、正式公開後の一般ユーザーの声と混ざってしまい、ベータ特有の文脈(初期バグ報告や導線の分かりにくさなど)が埋もれやすくなります。ベータ期間中は分けておくことをおすすめします。

参加者に何をフィードバックしてほしいか、こちらから指定すべきですか?

ある程度の指定は有効です。「詰まった箇所」「分かりにくかった表現」など、着目してほしい観点を事前に伝えておくと、受け取れるフィードバックの質が上がります。

クローズドβが終わったら、集めた声はどうすればいいですか?

正式公開後のロードマップ管理に引き継ぐのが現実的です。ベータ中の声を土台に、公開ボードでの運用へ移行する流れを最初から想定しておくとスムーズです。