プロダクト開発における効果的なフィードバックの方法 #しんらつ会 とは？

以前、なぜプロダクト開発においてフィードバックが必要なのかについてお伝えしました。
参照：プロダクト開発においてフィードバックが必要な理由

読後、「フィードバックの重要性は理解した。でも、うまくやるにはどうしたらいいの？」このように感じる方もいらっしゃるかもしれません。そこで今回は、プロダクト開発において、どうしたら効果的なフィードバックを行えるのかについて、他社・自社の事例を交えてお伝えしたいと思います！

フィードバックをする前に心がけたいこと

フィードバックの方法に入る前に、心がけておきたい事項があります。それは、フィードバックする側とされる側の認識を揃えることです。

お互いの認識がズレている状態でフィードバックを送り合っても、それは良いフィードバックになりません。

例えば、まだプロトタイプの段階で見た目の部分に対してはまだ詰め切れていないのに、「この色は良くない」とか「マージンを修正したい」などのフィードバックをもらったら、「いや、今はその話じゃなくて…」と思いますよね。前提条件が合っていないとそういった行き違いが発生してしまうし、積み重なるとチームに悪い影響を与えかねません。

この話は、フィードバックのときだけではなく、ミーティングの際に用意するアジェンダにも言えることです。例えば、プロジェクトメンバー5人で1時間のミーティングをするとして、アジェンダを設定しないままミーティングを始めるとどうなるでしょうか。おそらく、良いミーティングにはならないでしょう。ミーティングで話し合うべきことのすり合わせができていないミーティングでは、一人ひとり思い込みベースで議論することになってしまうため、決めるべきことが決まらないしムダな時間がかかってしまいます。そんな経験に心当たりはありませんか？

フィードバックでも同じです。「これは何のためのフィードバックなのか」「どの点に関してフィードバックをしてほしい / するべきなのか」など、前提条件を揃え、認識のすり合わせを行なってからフィードバックを行うことが大事なのです。

具体的な方法 〜他社の事例〜

では、プロダクト開発における具体的なフィードバックの方法の話に移ります。
GoodpatchではBaltoというフィードバックツールを出しているのですが、そのBaltoをご利用いただいているチームで実際に行っている方法をご紹介します。そのチームでは、『おさわり会』という時間を設けているそうです。

（参考：トクバイさんとワン会を実施しました🐶 – Balto Blog ）

『おさわり会』は開発メンバー全員が対面でフィードバックを送り合う時間のことで、新しい機能を皆で触り倒しているそうです。1つのスプリント期間を2週間に設定し、2週目の半ばあたり（火曜日〜水曜日）にフィードバックを集中的に送り合っているとのことです。スプリント内に実装を行なった機能の検証のために行っているのですね。

毎日ひっきりなしにフィードバックを送るのではなく、『おさわり会』のように集中して送り合う時間を取ることで、開発にメリハリをつけられます。このほかにも、他企業のチームでは、同様の時間を1ヶ月に1回ほどのスパンで設けてフィードバックの送り合いを行っている、というお話も伺いました！

具体的な方法 〜自社の事例〜

Goodpatchのあるプロジェクトでは、提供しているプロダクトをコアに使っているユーザーから、使いづらさや気になる点などに対する厳しい意見をもらう会を設けています。その名も、『辛辣に意見ください会』です（以下、しんらつ会）。

『しんらつ会』を始めた経緯と対象者

しんらつ会を始めた経緯としては、ユーザー数の伸びの要因は離脱率の高さだと考え、それを解決するために「辛辣な意見をもらってユーザー体験を改善しよう」というところから始まったそうです。行うタイミングとしては、ユーザー体験の改善を迫られたタイミングで実施しているとのことでした。
実際に辛辣な意見をもらう人を選ぶときの軸として、「社内のメンバー」であり「コアに使ってくれているユーザー」だといいます。なぜでしょうか？

それは、「社内であれば下手な遠慮をせずに話してくれるが、他社の方からだと会社同士の関係値を気にしてぶっちゃけられないのでは？」という仮説があったからです。また、コアに使ってくれている人にお願いする理由は、実務で使い続ける中で見えてきた使いづらさや気になるところを感じている可能性が高いからだそう。職種は問わず、完全に一人のユーザー目線から話してもらうことを心がけているとのことでした。
『おさわり会』同様、実際に対面での時間を取ってもらい、遠慮なく辛辣な意見を言ってもらっているそうです。

『しんらつ会』の工夫

いくら『しんらつ会』とはいえ、作っている人を目の前にして辛辣なことを言うのは、ためらわれるように思えます。そこでフィードバックをもらう開発側が意識したのは、辛辣に言っていい空気感を作ることだと話していました。

一例ですが、「このアプリのどこがむかつきますか？」という聞き方をすることで、建前じゃなくて本音でしゃべるような言葉遣いや接し方をし、フィードバックを送る側の人たちに対して「ここでは本音を言っていいんだ」と思ってもらうようにしているんだとか。
それにより、細かいバグよりもコアなユーザー体験の不満、根本的な使いづらさなどの、プロダクトの真価を問われるフィードバックをもらえるそうです。これこそプロダクト開発におけるフィードバックの、真骨頂と言えるのではないでしょうか。

『しんらつ会』の効果

『しんらつ会』を複数回実施した結果、多数のフィードバックが寄せられたそうです。実際にフィードバックがまとめられた社内Wikiを見てみると、プロダクトをより良くしたいという一心から、たくさんのフィードバックとそれに対するアクションがまとめられていました。

そして、もらったフィードバックをベースに機能追加や改善を繰り返し、すでにリリースされているものがいくつもあるそうです。それらは今では欠かせない機能になっており、『しんらつ会』の効果が具体的なアウトプットとして表れている証拠なんだと感じさせられます。

まとめ

プロダクトの改善のため、耳の痛いフィードバックにも真摯に向き合い実行に移すことが大事なんだと思います。その耳の痛いフィードバックを集める手段が、今回紹介した『おさわり会』や『しんらつ会』なんですね。ただ「フィードバックは大事だからやろう」だけだと、なかなか運用に乗らないですし、やり方を間違えるとチームに不協和音を起こしてしまう可能性だってあります。そういった際に、フィードバックにまつわるルールを策定することが、効果的なのかもしれません。

あなたのチームにも『おさわり会』や『しんらつ会』と同じような取り組みはありませんか？多種多様なフィードバックの方法を共有するためにも、ぜひTwitterで「#しんらつ会」
と付けて、投稿してください！興味深い取り組みに関しては、BaltoのTwitterアカウントでシェアさせていただきます。