プロダクトデザイナーのsuです。
プレイドではKARTEの既存プロダクトの磨き込みや新機能の開発に関わっています。他にもCDOとして、デザインメンバーがそれぞれの強みを発揮してもらえるようなフォーメーションの検討や、それぞれの開発チームで得られた学びを循環させるための取り組み、プロダクト／コミュニケーションデザイン領域外の課題解決に関わっています。
今回はプレイド社内で頻繁に行われる「ぽちぽち会」という取り組みについてまとめていきます。開発に関わるメンバー全員で、同じタイミングで機能や画面を触りながら、改善アイデアを洗い出す取り組みで、自分が所属している開発チームではフローに自然に組み込まれているものです。
リリース前後に改善のタイミングを作っていきたいという方にとって、なにか気づきをご提供できましたら嬉しいです。
プレイドの開発チームには、「デプロイドリブン」という考え方があります。新しい機能や画面をなるべく早いタイミングでリリースし、ユーザーの反応をもとに改善していこう、というものです。
早い段階で出すことで学習の頻度が増えるのと、実利用を通じて得られた気づきをもとにしたほうが自分たちだけで議論するよりも結果として最適解に辿り着きやすくなるのではという仮説をもとにした考え方です。KARTEの場合、実際のデータではないダミーデータでデザインしている段階ではわかることに限りがある特性があることも大きいです。
リリース時の基準になっているものには「プロダクトの価値が受け取れる形になっているか」というものがあります。
既存画面で影響範囲が大きい場合には、出す前に社内の有識者に触っていただいてフィードバックを得たり、何社かのユーザーさんに事前にお見せして不都合がある部分がないか検証を挟むこともあります。
一方、新しい機能や画面など、まだ利用されていない機能、価値検証の段階のものが多い場合、最低限「価値が受け取れる形」になっていれば、まずはリリースして学習を回せるようにしています。
例えば、あるデータが見れることが価値ということであれば、言葉を選ばず言うとUIが一貫していない野ざらしのUIでも先にリリースして、価値を確かめながら一貫性や使い勝手などをあとから上げていくような取り組みをしています。
実際にリリースをして、ユーザーから反応を得る・改善ポイントを集めるのとは別に、プレイドにはより高速に改善ポイントを見つけ出す機会があります。それが最初にお伝えした「ぽちぽち会」です。
元々はビジネスメンバーの機能理解のために「みんなで集まってプロダクトの新機能や画面をぽちぽち触ってみる」という会だったのですが、その取り組みを開発チーム自らがやってみたところ、思ったより学びや気づきが出てくるため、自分が所属しているチームでは定期的に行われるようになりました。
「今回はこの画面をさわってみよう」という風に扱う画面やテーマを決め、1時間など決められた時間内でぽちぽち触りながら、Slackの専用チャンネルにひたすら気づいたことや思ったことを投稿していきます。
投稿内容の粒度はバラバラで、「こういうのはどうか」というアイデアだったり、質問だったり、とにかく気づいたことがアウトプットされていきます。
そして、各投稿に対してスレッドを立て、そこで議論をしていきます。質問に答えたり、どのように改善していくかを話し合ったりなど、投稿したメンバーとそれを設計したメンバー、意見のあるメンバー間でコミュニケーションをとります。
議論した上で改善すべきとなったものはgithub issueにしていくのですが、ここで社内で作ったオリジナルツールの「issit」というslack appを活用しています。slackのメニューから任意のリポジトリにissueを作れるもので、ブラウザとの行き来がなくなるのと、issue化するとスレッドにも現れるので議論の消化がとてもしやすくなっています。
※スクリーンショットではstockholmというコードネームになっています
余談ですが、ちょうど今月、このツールを社外向けにも公開しましたのでこの場を借りてお知らせです。slackからissueをサクッと作りたい方はお試しいただけると嬉しいです。
ぽちぽち会をやり始めた当初は、出てきた改善アイデアは直近やらないものを含め全てgithubのissueにしていました。ただ毎回10,20くらいの磨き込める余地やアイデアが出るため、一時期は山のようにissueがbacklogに積まれるという状態になっていました。とはいえメインの開発と並行してそれらすべてを検討していくのは難しく、それがチリツモでメンバーの負荷になっているように感じたため、緊急性・重要性が高くない投稿に対しては「経過観察」というスタンプをつけて、issue化する前のものとして置いておくような運用をしています。
課題が大きなもの、再現性があるものについては今回置いておいたとしても別の経路からissueが上がったりするため、そうしたことをトリガーに「そういえばぽちぽち会でも話してたやつだな」という形でslack検索から掘り返すことができるため、あえてこうした運用にしているというのが現状です。
「ぽちぽち会」の取り組みで重要なのは、「フィードバックにポジティブに向き合えるかどうか」というマインドだと思っています。改善点を洗い出すということは言い換えると、プロダクトの粗を探しているようなもの。捉え方を間違えると、ただ作った人が凹むだけの時間になりかねません。だからこそ、作り手含め全員が「よりよいものをつくる」というマインドで取り組むことが重要だと考えています。
フィードバックを受ける側だけではなく、フィードバックを行う際にも、ポジティブな声かけを行う、例えば「ここが使いにくい」ではなく、「ここめっちゃいい。ここもこうしたらもっと良くなりそう」のような形で、「より良くするために自分に出せる意見はないか」という観点で発言できるように気をつけています。
一方で、そうした言い方をルールにするということはしていません。変に気を遣われてコミュニケーションしにくくなったり、フォーマットにしてしまうことでそもそもフィードバックを面倒なものと感じられてしまっては、良くするための種すら見つけられなくなってしまいます。
たとえ感情が入っていても率直に意見をもらえたほうが、プロダクトをより良くする機会につながると考えています。必要なのは、受け取る側の捉え方を変えること。相手のマインドや行動を変えるのは難しいですが、自分の考え方や物事の捉え方を変えることであれば自分でコントロールできます。
フィードバックの「内容」と「感情」を切り分けて捉える訓練をしてみたり、「伸びしろ見つけられた」くらい前に倒れるような捉え方をしてみる。ということがデプロイと学習を行き来してプロダクトを高速に磨いていくために必要なことなのではないかと考えています。
ぽちぽち会を開発フローに組み込む前と比べてみると、リリース直後の社内外からのUIや不具合に関する問い合わせが減ったように感じます。
また、他の開発チームでもぽちぽち会を開催して高速に改善ポイントを出しているチームも見かけるようになってきていて、プロダクト品質を高めるための取り組みが拡がっていることを嬉しく感じます。
これからも、チーム内外を問わず寄せてもらえた声や、その裏にある思いも一緒に抱えてより良いプロダクトにつなげていく。そしてまたフィードバックに向き合うというサイクルを回していきたいと考えています。