toBのプロダクトは、A/Bテストで気軽に画面を変えられない
稲垣景子氏（以下、稲垣）：今回は「『ほしいものをつくる』ためのリサーチの日常化トライ」というテーマにさせていただきました。ご質問やご意見がありましたら、オープンチャットでぜひお寄せください。のちほどチャットでお答えしていければと思います。
自己紹介ですが、自分は最初にブライダル企業からキャリアを始めました。実はプロダクトマネージャーになったのは、まだ5年〜6年前です。ウェディングプランナーからWebディレクターになり、SEO担当者を経て今はSaaS企業でプロダクトマネージャーをしています。
ふだんはプロダクトマネージャーとしてSmartHRに関わっているんですが、実はプロダクト構成が複数に分かれています。PM5名で開発をしている「SmartHR本体」と、そのデータを使っていく「プラスアプリケーション群」とがあり、私は複数名体制で1個のプロダクトを作るチームのPMをやっております。
先ほど「リサーチの文脈」というお話があったんですが、私はリサーチの専門家ではないので、「ユーザーリサーチ文脈」という観点で、SmartHRで何をやっているかをお話しさせていただきますね。
まず私たちのバリューの1つに「人が欲しいと思うものをつくろう」があります。toBの業務システムは、A／Bテストがものすごく困難です。ボタンの位置やラベルがちょっと変わるだけでも、紙で印刷されてるマニュアルの資料や自動化ツールに影響が出てしまうため、気軽に画面を変えられないんですね。
そこで、実際にリリースをする前に、いかにアジャイルに仮説検証を進めるかがすごく大事になってきます。これはコロナ禍以前からですが「もっと気軽に、でももっと深くユーザーの声を聞いて、仮説検証していけるようになるといいな」という悩みを抱えていました。
リリース前にどれだけ仮説検証ができるか
稲垣：実際にふだん、同じ文脈を持つものとしてどんなことをしているかというと、さまざまなかたちで行っています。中でも先ほどお伝えしたように、リリースしたあとに動かしていくことが難しいので、リリース前の活動がすごく多いです。特にオレンジの部分は、この2年で拡張してきました。もともとやれていなかったユーザビリティテストを始めたり、スプリントレビューも改良を続けてきました。
何のためかというと、仮説検証の流動を小さくし、一方で頻度は高く、かつより多くの人にフィードバックをもらえるように、共有できる範囲を広くしていくことを意識して、さまざまな試行錯誤をしてきました。
社内外のインタビューやヒアリングを活発化していったり、Zoomで行っているユーザビリティテストを全社に配信して、より多くの人に見てもらったり、バザール形式のスプリントレビューなどをやってきました。さっき「この2年で拡張したことが2つあります」と言いましたが、今日はその中でもスプリントレビューについて、お話します。
たぶんみなさんも、できるだけ頻度高く、実際のユーザーのフィードバックが欲しいのはやまやまだと思います。ただ、毎週毎週ヒアリングにお客さまを呼ぶのは、なかなか難しいですよね。
実際にスプリントレビューで何を試行錯誤してきたのかというと、まずは社内でできることを始めました。毎週開発チーム同士で、お互いにレビュアーをやっている状態から、チャットサポートチームに参加してもらって、客観的なフィードバックを得たり。
私たちは人事労務のSaaSなので、必要に応じて社内ユーザーである人事担当者や労務担当者を招いたり。ターゲットユーザーのCS担当者を招いたり。まずは開発チームの外の声を聞くことのハードルを下げ、できるだけリアルに近い声を集めるかたちで、スプリントレビューの改良を始めていきました。
より多角的に、もっと広い意見を集めるには「バザール形式」が効果的
稲垣：「より多角的に、もっと広く意見を集める方法はないだろうか」という観点で、実際にやってみたのがバザール形式のスプリントレビューです。これは、ご存知の方もいらっしゃるかもしれませんが、サイエンスフェアのようなスタイルで行うスプリントレビューです。
オフラインでやるときは開発アイテムごとにエリアを物理的に区切って、チームの代表者が機能を紹介しながら、参加者たちが回って「ああでもない、こうでもない」と議論を行うようなかたちです。私たちのプロダクトは大規模スクラムの体制を取っているので、複数のチームがそれぞれに開発中のアイテムを持っていることを生かしてトライしたレビューのスタイルです。
これを緊急事態宣言の合間を縫って1回、試しにやってみたんですね。そうしたところ、思っていた以上に、ふだん出てこないような意見がたくさん出てきました。特にセールスならセールスならでは、カスタマーサクセスならカスタマーサクセスならではの、さまざまな意見が出てきました。これはやっていく価値がすごくあるな、と感じたんです。
当日の様子はこんな感じです。みんながわーっと集まって、操作者が1人いて、それを見ながらみんなに付箋に意見を書いてもらって、集まった意見をまとめて最後にトリアージをし、反映をしていきます。
Zoomとオンラインホワイトボードでレビューを実施
稲垣：とはいえ、状況はコロナ渦なんですよね。今度は「実はオンラインでもできるんじゃないか」と考え、実際にやってみました。
具体的には、ブースを区切る代わりに、Zoomのブレイクアウトルームを使いました。ブレイクアウトルームごとに開発チームが待機していて、参加者は自由にブレイクアウトルームを移動できるようにして、興味のあるアイテムを紹介しているチームのルームに参加してもらうかたちを取っています。
とはいえ、あまりにも自由に行き来してしまうと、何が起こっているかわからなくなってしまうので（笑）。せめて時間は区切って、レビューセッションと移動を繰り返すかたちで行っていきました。
メインルームは進行管理だけにして、それぞれのルームで行き来をしてもらいます。それぞれのルームの中には、ファシリテーターとレビューガイドをする人、タイムキーパーがいます。
物理のホワイトボードはないので、miroが活躍してくれました。参加者には、miroで自由にペタペタと意見を貼っていってもらいます。「どんなものが集まっても最後は私たちがトリアージするので、思ったことは全部書いてください」と、かなり思考発話に近いような付箋を貼っていってもらっています。
実際のユーザーのフィードバックで得られた成果と反省点
稲垣：これが意外とうまくいったので、もう一歩ステップアップしたいということで、今度はユーザーを招待してやってみました。合計30名超ぐらいの方に来ていただいて、モックや開発環境に触ってもらいながら、フィードバックを受けてみました。
参加者のみなさんを長時間拘束するので大丈夫かなとも思っていたんですが、満足度がすごく高かったという意外なポイントがありました。
一方で、やっぱりユーザーさんはフィードバックに慣れていらっしゃらないので、セッション時間の中で「フィードバックをください」と言われると焦ってしまったり、多くの人が見ている中で操作することになかなか慣れていないので、「素直な声を挙げにくいのかもしれない」という声もあとから挙がったりしていました。とても楽しかったんですが、フィードバックはちょっと浅めだったかな、という反省が残っています。
その結果、「新機能をお披露目するイベントと、フィードバックを受ける機会は分けたほうがよさそうだよね」という、結論にたどり着きました（笑）。とはいえ、もっと気軽にユーザーからの一次情報をもらうために、接点を作ることにしたんです。
もっとユーザーとの距離を縮めるための新たな取り組み
稲垣：以前から、カスタマーサクセスやマーケティングチームを中心として「SmartHR Sensei コミュニティ」という活動を始めています。私たちは、ユーザーさんのことを「Sensei」と呼んでいます。人事労務のプロとして、私たちの知らないことを教えていただこう、という意味で「Sensei」とお呼びしているんです。
仮説検証をもっと加速させるために、開発チームが直接ユーザーさんとコミュニケーションを取れる場をつくり、ご相談やヒアリングなど、声をかけやすい仕組みをつくっていきたいと思っています。
やっぱりユーザーのことを知るためにすごく大事なのは、できるだけユーザーに近いところに私たちが出かけていくことだな、と実感したポイントの1つです。
最後にTipsを1つご紹介します。ユーザビリティテストをオンラインで行う中で得られた発見です。Zoomで圧迫感が出てしまうのを防ぐために、開発者が全員Zoomに入るのではなく、視聴用にGoogle Meetも使うことにしました。配信担当が一緒に入って、Zoomの画面共有をGoogle Meet側でして、状況を一緒に見たい人（大人数）はこっちを見るというかたちでやってみたところ、参加しているレビュイーさんの圧迫感を軽減できたよ、といううれしいポイントを最後にご紹介して終わりにします。ありがとうございました。
リサーチは「現状と行動の橋渡し」をするもの
上田葵氏（以下、上田）：それでは始めます。PMとUXリサーチャーの伴走型リサーチを経て、リサーチャーの目線からPMの方へ伝えたい3つのことについて、今日はお話ししていこうと思います。
前置きをしておくと株式会社メルカリでは、今行われているリサーチのだいたい7～8割が、PMの方と一緒に行っていく伴走型のリサーチです。今日はその実際の事例を踏まえながら、みなさんにお伝えしていきたいと思います。
まず初めに自己紹介です。私は今メルカリでUXリサーチャーをしております。メルカリには今から3年前の2018年の秋に、もともとはPMとして新卒で入社しました。そのあとPMから徐々にUXリサーチの業務に移っていったんですが、現在は調査の設計から実査・分析、あとは社内でUXリサーチができる体制や仕組み作り、環境整備に力を入れています。
お話の前に、私がここで話す「リサーチの定義」について確認していきます。UXリサーチを直訳すると、「お客さまの反応や体験について調べて、明らかにしていくこと」ですね。私はよく、社内のPMやデザイナーのみなさんに「リサーチは現状と行動の橋渡しですよ」というお話をしています。
この橋渡しをするために私たちが知ったり確認するための方法が、アンケート調査や、お客さま一人ひとりと向き合って行動や言葉を理解していく、いわゆる定性調査です。
今日は時間が短いので、3つに絞ってお伝えしたいと思います。この3つを守るとけっこうリサーチで困ることがないよという、私からのTips的なアドバイスです。ここ数年PMの方とたくさんのリサーチをやってきて、ここを押さえているとスムーズに調査が進む体感があったので、経験ベースでお伝えしたいと思います。
リサーチのゴール設定に欠かせない「3つの要素」
上田：今回紹介する事例は、実際に今年メルカリで行ったプロジェクトの事例です。PM、アナリスト、リサーチャーとデザイナーというチーム構成でリサーチを行いました。もちろん開発側のメンバーがもっと裏にいるんですけれども、直接調査に関わったのはこのメンバーになります。
まず今日のポイントの1つ目は、「調査ゴールの設定を明確にしましょう」というお話です。この調査ゴールは、私がけっこう社内で口酸っぱく言っているところです。簡単に言うと「あなたがリサーチを行った上で明らかにしたいことって何ですか」という3つになります。
ゴールは3つの要素から成り立っていると考えています。まずは「誰に対して」の調査なのか。そして「何を知りたい、あるいは確認したいのか」。あと、そもそも「なぜそれを知りたいと思ったのか」。これが背景の部分になります。
この「Who、What、Why」をクリアにしておかないと、どんな調査でも設計の段階からけっこう失敗してしまうので。まずこれらを明確にすることが、リサーチを組み立てていく上でのファーストステップになります。私がPMの方とコミュニケーションする時も、常にこれを心がけて、最初のシンクの時間でしっかりとお話ししています。
メルカリでの農作物の出品を増やすには？
上田：ちょっとわかりづらいなと思う方のために実際の事例でご紹介します。例えば今年の初めに行った調査ですが、メルカリでは現状「食品の出品が少ないよね」という課題があるんですね。それに対してどうすればいいのか、ちょっと調査したいという声が上がりました。
今回は「農作物」とちょっとカテゴリを絞ったんですが、「農家さん」による出品を増やしたいというところで。Whatに当たる「農作物の出品を増やすには、私たちはどういった訴求が必要なのか」を確かめたい、知りたいという部分があったんですね。
そもそもなぜこの話が出てきたのかというと、メンバーのアナリストがいろいろ調べた結果、ログの定量分析から「どうもフードカテゴリーにかなりのポテンシャルがあるぞ」ということが見えてきました。それが背景になって、この調査を組み立てていきました。
ここまででゴール設定ができたら、次に私たちがやるべきステップは「仮説出し」になります。これもけっこうキモになるんですが、中には「どういったものが課題なのかわからない」といった、ちょっと探索的な調査もあります。仮説が出しづらい場合の多くは、構造化して考えていくとけっこう出てくるんですね。
ここでの仮説は「現状の課題」。今回で言うと、メルカリには農作物を作っているのに出品をしている人は少ないという、大きな現状の課題があります。そのままだと大きすぎるので、解決可能なサイズまでどんどん分解して考えていくと、私たちが調査などで確かめないと「そうだよね」とは言えないものになります。
どんな課題も、構造化すれば仮説が出てくる
上田：実際に（課題を）分解するとどうなるのかを見ていきましょう。まず「メルカリには農産物を育てているお客さまはいるけれど、農産物は出品していない方が多くいるのではないか」という課題があったとします。これを一旦分解すると、例えば「そもそもメルカリで食べ物を売るイメージがないんじゃないか」。どうでしょう、たぶん今聞いてらっしゃる方の中にも「うんうん」と思う方が多いかなと思うんですけど（笑）。あんまりイメージがないですよね。
これはまだ課題として大きいので、もうちょっと分解して考えていきます。訴求としての方向性。例えばメルカリは全国に使ってくださるお客さまがいるので、地方のお客さま。珍しくない果物や野菜も、メルカリだと「ぜんぜん違う地域の人が欲しいかもしれないよね」という認知を増やすと、もしかしたら出してくれるんじゃないかな、という方向性があったり。
実は、私の実家は農業をしているんですが、農家ってめちゃくちゃ忙しいんですよ（笑）。作る作物によっては、本当に1年中休みがないこともざらなので。そもそも農家さんの立場に立った時に「出品に割く時間はないんじゃないの？」という話が出てきたり。
それをもうちょっと嚙み砕くと、「メルカリってめっちゃ簡単に出品できますよ」という話を訴求したら出品が増えるんじゃないのかという仮説が出てきます。こんな感じで、どういった課題でもどんどん構造化して考えていくと、いくつかポロポロと仮説が出てくるんですね。
こういった仮説をベースにインタビューの台本を考えたり、アンケートの設問に組み込んだり、質問によっては農家さんに直接聞いたり。いろんな方法で、自分たちが着目するチェックポイントを仮説というかたちでしっかりと出していく。このプロセスが、のちのちのインタビューや調査が終わったあとにどういったデータが得られるかのキモになります。
「生の体験談」を入手するのは調査、その分析がリサーチ
上田：最後の3つ目は、ちょっとマインドセット的なところに近いです。「あくまでも調査って、生の体験談を入手することなんですよ」とお伝えしたいです。忘れてほしくない姿勢が「生の体験談を入手して、それを分析して答えを導き出していくのがリサーチ」というメッセージですね。
これも事例を交えてお伝えしていきます。よくある誤解として、例えば今回の「農作物の出品を増やすにはどうすればいいのかな」と考えた時に、よくあるパターンが「そっか、インタビューしてお客さんに聞けば答えが見つかるかもしれない」。
みんなが答えを持ってきてくれるかも、と考えてしまって、「どうすればいいと思いますか？」とお客さまに直接聞いちゃうパターンですね。そして出てきたいろいろな答えを、お客さまの声としてストックする。
もちろんそれは大事なんですけど、その中に正解が転がっているわけではないことを、しっかりと覚えておいていただきたいんです。あくまでも私たちは調査の中でヒントを見つけて、お客さまの言葉や行動を振り返って分析をして、そこから「どうすれば農作物の出品が増えるんだろうか」という答えまで導き出していく。ここまでしてリサーチなんですよ、というところですね。
ゴールを明確にし、仮説を出し、お客さまの生の声を分析する
上田：ということで、3つのポイントのまとめです。まず1つ目が「調査のゴール設定を明確にしましょう」というところです。この3つの要素を必ずしっかりクリアにした上で、どういった調査が必要なのかを考えるようにすると、けっこうしっかりとリサーチの設計の部分から土台を作れると思います。
2つ目がこの「仮説出し」ですね。仮説出しができる課題に対しては、できるところまで分解して仮説を出していきましょう。これはインタビューやユーザビリティテストなど、いろいろなことに当てはまりますね。
3つ目、リサーチすべてにおいての基本のスタンスとして「お客さまの声・生の体験談をそのまま真に受けるんじゃなくて、そこからあくまでも分析して答えを出していく」。その姿勢を忘れないようにしてください、というのが今日伝えたい3つのメッセージになります。
今日の話を聞いて、「メルカリ、リサーチおもしろそう」と思っていただいた方は（笑）。「mercan」というメディアに、最近取り組んでいるUXリサーチの事例だったり……私だったり、あとはアナリストの方とコラボして、定量・定性での調査にも力を入れています。実際にどういうことをやってるんだろうと興味のある方は、いくつか記事があるので、よかったらご覧になってみてください。ということで、ありがとうございました。
リサーチの分析は具体的にどんなふうに行っている？
司会者：ありがとうございました。おそらく今日参加されてる方は、PMの方が多いんじゃないかなと思うので。たぶんもう胸に刺さりまくってるんじゃないかなと思っております（笑）。ありがとうございます。
上田：（笑）。
司会者：ちょうど今いただいている質問は上田さんにお聞きするのがいいかなと思うので、せっかくなので、1問だけ聞かせていただいて。そのあと、ほかのみなさんへのご質問はアフタートークで質問いただければと思います。
オープンチャットで「リサーチの分析を具体的にどのように行っているか」という、ご質問をいただいています。なんらか事例等々があれば、回答いただけると助かります。
上田：これはプロジェクトによってけっこうまちまちなんですけれども。メルカリの場合、出品を中心に見ているチームがあったり、購入を中心に見ているチームがあったり、体験ベースでチームが分かれている現状があります。
その場合に応じて一番最適な手法を選ぶ……例えばKA法とかKJ法で分析を行うこともあれば、ジャーニーマップを作っていくアウトプットもあります。最初にPMの方とアナリストの方とシンクをして、どういうアウトプットが欲しいのかをすり合わせた上で、それに向けてリサーチしていくことが多いですね。
なので「必ずこのフォーマットで分析をします」というものは特になくて。今回ご紹介した農家さんの事例のアウトプットとしては、インサイトを定量データと一緒にまとめてスライドにするというかたちで、特にジャーニーは作っていないんです。行動ベースでしっかりとまとめて、農家さんの気持ちなどを細かくマッピングしていって「こういうことあるよね」というグルーピングをして、アウトプットをまとめていました。
司会者：なるほど、ありがとうございます。「仮説を分解できるところまで構造化していく」という切り方が、仮説の内容なのかジャーニーのような単位なのか、という違いなのかなと、今聞きながら思っていました。すごく参考になったので、たぶん明日からもうちょっといいPMになれそうな気がしています（笑）。ありがとうございます。
上田：（笑）。ありがとうございます。
