見出し画像

みんながUXリサーチできる組織にするための3ステップ

Koichi Watanabe

こんにちは、カミナシでUXデザインとリサーチをしている渡邊 (@nabetaro_san) です!

カミナシのプロダクト開発では、UXリサーチを起点に議論や意思決定を進めています。が、今はカミナシには専属のUXリサーチャーがいるわけではなく(ご興味ある方是非🙏)、チームメンバーみんなが実践していく必要があります。

今回はカミナシでみんながUXリサーチを行う上で取り組んだことを3ステップで書きたいと思います。

誰のためのnote?
これからUXリサーチをチームで取り組んでいきたいと思っている方
UXリサーチにはじめて取り組む方
プロダクト開発に取り組んでいるPMやデザイナーの方
カミナシのUXリサーチってどんな感じ?と気になる方


UXリサーチを取り組む中で、出てきた課題

カミナシでUXリサーチをしっかりやっていこう!となったのは去年の夏頃 (2021年夏頃) ですが、当時は新プロダクトを開発するスモールチームでスタートしました。当時、チームの中でUXリサーチの方法を模索していく中で、以下のような課題がありました。

チーム間の連携が整っておらず、情報キャッチアップの効率が悪かった
UXリサーチで得た情報のストックができず、活用しきれていなかった
UXリサーチの成果を最大化できる仕組みを整えていなかった

これらの課題は直接プロダクト開発に影響するため、チーム内はもちろん、チーム間も含め、みんながUXリサーチをできる組織にするために主に3つのステップを進めてきました。

  1. チームや部署間での情報連携を整備する

  2. UXリサーチの目的別に情報をストックする

  3. デスクリサーチを徹底する

カミナシでは、これらの3ステップを進めていったことで、社内の顧客に関する情報が集約・整理され、プロダクト開発の議論や意思決定が進めやすくなってきたと思います。

今回はその3ステップについて、カミナシでの事例をご紹介しながら書いていきたいと思います。
※ カミナシはBtoBのSaaSスタートアップで、規模は100名未満ほどです。

Step 1. チームや部署間での情報連携を整備する

まずは今あるチームや部署間で、UXリサーチをどのように行うのかという目線を揃え、情報連携をしっかりと整備します。

カミナシはBtoBのプロダクトを提供していますが、セールスチームやカスタマーサクセスチームなどの顧客と深い接点を持つチームが持つ情報は、当然プロダクト開発においても重要な情報になります。

チームや部署間で、これらの情報が連携されないと、実は社内に情報があるのに顧客にヒアリングしてしまった…!ということになりかねません。

はい、カミナシでも実際にありました。プロダクト開発サイドで、ヒアリングを顧客にしてみたところ…

「前にも同じこと話したんだけど、また聞くんですか?」

あの瞬間は生きた心地がしませんでした…。

UXリサーチは特定の個人やチーム内で完結できるものではなく、組織全体で情報を活用しながら行うのがいいかもしれません。

とは言ってみても、カミナシでもいきなり連携方法から考えて始めたわけではなく、スモールなチーム内でまずはUXリサーチをやってみて、という感じでした。

実践してみると、事前にどのチームの情報を得ておくべきなのか、カスタマーサクセスチームにどのようにヒアリングの依頼をするか、などなど社内でやるべきことが見えてきます。

カミナシのヒアリング調査のワークフロー例

それらのやるべきことを整えていくことで、プロダクト開発においても顧客やユーザーのWhyを、ボトムアップで見つけられる構造にできるかもしれません。

Step 2. UXリサーチの目的別に情報をストックする

チームや部署間での情報連携が整ったら、UXリサーチで得た情報をどのように社内にストックしておくかを決めておきます。

チームそれぞれが得た情報には、それぞれ目的が存在し、目的に対する事実もしくは解釈された情報が格納されていきますが、目的⇄事実⇄解釈という情報の関係性を保つようにします。

これらの関係性が整理されていないと、例えば解釈された情報を事実として理解してしまう可能性があり、結果として間違った情報を鵜呑みにしてしまうなどの状況が発生します。

カミナシでも発生したことがあり、

顧客の「Aという業務があります」という事実に対して、「Aという業務はなかった!」と180度誤解してしまうケースがありました。

これの恐ろしかったところは、ヒアリングした際は記録として残っていたにも関わらず、時間が経つうちにチームメンバーが誤解していったところです。

その後、Aという業務はプロダクトの体験に大きく関わることが判明し、再度顧客に調査をするなんてこともありました。

得られた事実を誰がいつ見てもわかるような形で保管し、そこから生まれた解釈とを分けておくといいのかもしれません。

また事実だけではなく、目的自体も明示しておく必要があります。

チームや部署間で情報を閲覧できるようになると、チームごとに事実から都合のよい解釈を生んでしまう可能性があります。

大げさな例

そのため、得られた事実はどのような目的から得られたものなのかを整理し、解釈を生み出す必要があります。

カミナシでのnotionストック例

Step 3. デスクリサーチを徹底する

チームや部署間での情報連携と、情報をストックする準備ができたら、いよいよUXリサーチを開始します。

ここで気をつけているのは、”すぐにヒアリングをしないこと”です。

カミナシではデスクリサーチを十分に行った上で、必要な場合に限りヒアリングを行っています。

ヒアリングをすぐに行うと答えにすぐ近づける感覚があります。が、十分な事前知識と仮説を作らなければヒアリングで得られる情報に大きく差が出てくるなと思いました。

カミナシでも以前ヒアリングを行う際に、十分にデスクリサーチをする時間がなく、ヒアリングを行いましたが、結果としては「調べたらわかることだった」ということがありました。

BtoBの場合だと、実際にサービスを使っていただいている顧客にヒアリングを行う必要があるため、調整などを含めると、どうしてもヒアリングの回数には限りがあります。そのため毎回のヒアリングの質を上げるために、十分な準備とデスクリサーチをする必要があります。

以下はデスクリサーチ時に、カミナシでチェックする基本的な項目です。
もしプロダクト開発を進める上で、デスクリサーチでどのような事を調べるべきか迷ったら、是非参考にしてみてください。

戦略を考える上での調査
市場動向の一時情報はどうか
競合もしくは競合になりうるサービスは何か
業務・業界を理解する調査
Webサイト、書籍では何が書かれているか
社内に有識者がいるか。その人は何を話していたか
過去のUXリサーチ結果には何が書かれているか
顧客の課題の特定を行う調査
商談はどのようなきっかけで始まり受注に至ったか。失注した理由は何か
どのような要望やフィードバックがきているか
カスタマーサクセスチームに顧客は何を話していたか
定量的にはどうなっているか
過去のUXリサーチ結果には何が書かれているか

また組織でUXリサーチを行う上では、チームで役割分担をしながらデスクリサーチをして、チームで学習レベルを上げていくのも重要だなと感じました。

個人がデスクリサーチを行うという手段もまたありますが、デメリットとしては、情報が属人化しやすく、組織に情報が落ちにくくなります。

情報が属人化すると、チームで意思決定をする時に属人化した情報に左右されやすくなります。そしてチームメンバーの理解や納得感がなくなり、多重リサーチになる可能性もあります。

これらのデメリットを考えると、チームで分担し情報を集め、その情報をチームで同期して進めた方が、議論や意思決定が建設的になるかもしれません。

みんながUXリサーチできるには中長期の探索が必要

今回3ステップの取り組みについて書いてみましたが、組織の規模やフェーズによっても変わってくるため、まずは実験的に取り組んでみて、自社に合うような形を探索していくのがいいと思います。

カミナシも変化が非常に激しい環境なので、完璧に取り組めるわけではなく、そのときどきで常にベストな形を見つけるように日々奮闘しています。

この記事を読んで「面白かった!」「参考になった!」と思っていただけたら、スキを押していただけると嬉しいです。


カミナシはPMを大募集しています!
カミナシのPMチームはまだ立ち上がったばかりで、0→1な環境です。
みんながUXリサーチできる環境もPMがメインで進めています。
一緒に「UXリサーチの仕組みをつくりたい」「カミナシでUXリサーチしてみたい」という方は是非👍

この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!