00:02
s-umemoto
デザインの味付け。はい、始まりました。デザインの味付け。この番組は株式会社ajike代表の梅本と、その仲間たちがデザインについて雑談を交えながら話す番組です。
今日のお相手は、原さんです。原さん、よろしくお願いします。
n-hara
よろしくお願いします。
s-umemoto
あの、梅雨入りはしてないですけど、雨が降ってますか?そっちは。
n-hara
今日は降ってないですけど、でも曇りですね。天気はあんまり良くないです。
s-umemoto
困ったときの天気話を振りました。準備また忘れてた。
前工場。
ちょっとあれだよね、過ごしやすい時期からちょっとだけ地面と暑くなってる感じがするみたいな。
そうですね、ちょっと暑いです。気温が高いですね。
あれ、今は犬の散歩は行くんでしたっけ?
n-hara
今はまだできますね。
s-umemoto
毎日行ってんの?
n-hara
毎日は行ってないです。小型犬なので。
s-umemoto
夏、多分7月ぐらいからちょっと厳しくなってきますね、外の散歩は。
それはあれ、散歩をさせたほうが逆に犬には健康よくないみたいな。
n-hara
そうですね、気温が高いんで、犬は地面に近いので、プラス10度とか言うんですけど、体幹。
30度のときに出したら40度ぐらいの感覚になって、あるので焼けちゃうんです。
s-umemoto
あー、なんか聞いたことあるな。肉球ね、焼け出しちゃってるってね。
n-hara
お腹とか臓器も反射の熱で痛めちゃうとかするんで。
そりゃかわいそうだね。
昼間はもうだめですね、夏は。
s-umemoto
ちょっと季節には気をつけてやっていければなと思います。
さて今日のテーマは何でしょうか。
今日のテーマは、ユーザーの声を聞くときに気をつけなくてはいけないことというテーマです。
いいテーマですね。このまま聞いちゃいましょう。
ちなみにこれはなんでこのテーマにしたんですか。
n-hara
最近結構ユーザーインタビューとかユーザーテストとかを案件で自分自身もやったりとか、
お客さんにレクチャーすることとかが増えてきてたりしてまして、
新規事業系のサービスの検討されているお客さんにインタビューとテストの方法をレクチャーする案件を担当してまして、
そこで結構自分自身もレクチャーすることによって気づいたりとか学ぶところがいろいろありまして、
ここを気をつけないと実際こういうことになっちゃうなとか、こういうこと落ちりがちだよなみたいなところとかっていうのがいろいろ見えてきた。
その辺のテーマでした。
s-umemoto
なるほど。この落ちりがちだっていうのはまたそのまま質問しちゃいますけど、
03:03
s-umemoto
つまり何に気をつけなきゃいけないんですかね。早速本題の質問になって申し訳ない。
n-hara
そうですね。一連やっぱりいざテストって本当に計画作って実際やって分析していろんな工程があって、
いろいろそれぞれに細かい注意点とかもちろん観点とかポイントってあるんですけど、
今回ちょっともう何ですかね、案件をやる上でここをマストで多分気をつけなきゃいけないっていうのをちょっと絞って3つ話したいなと思います。
3つです。
1つが事業のフェーズにあった検証目的を設定することっていうところが1つ目になってまして、
これどういうことかっていうと、検証するときって何かしらその目的があって検証するっていうことがあるんですけど、
何を知りたくてその検証するのかっていうところがすごい大事だと思ってるんですけど、
新規事業のときって新規事業のフェーズがあって実行がそもそもその市場性があるのかとか、
そういうところもあれば実際プロトタイプ作ってプロトタイプが使いやすいのかどうかっていうところのそのタイミングでもインタビューしたりテストしたりっていうのがあると思うので、
いろんなタイミングで検証するタイミングがあると思うんですけど、
今やってる新規事業って結構手前の段階の今フェーズではあるので、
特にその手前の段階のときっていうのは、この事業のフェーズにあったしっかり目的を設定するっていうのが本当に結果にもすごい火分を付いてきますし、
事業として成功するかどうかにもかかってくるところなんじゃないかなっていうふうに思ってるっていうのがあります。
事業のテーマとしてはユーザーの課題起点から始まるような、ユーザーがこういう課題持ってるから、
じゃあそこに対してソリューションないかなっていうふうにビジネスの可能性を考えていくっていうパターンと、
市場として結構こういう傾向があるからとか、こういうところに他の標語がいないからこのテーマでやっていくのはどうだろうかっていう感じで、
ビジネス起点で立ち上がるテーマの2種類のパターンあるんじゃないかなと思うんですけど、
特にそのビジネス起点のときになってしまう落ちりやすな状況として、
このテーマで行くときにユーザーは欲しいだろうとか利用してくれるだろうっていう、
ビジネス起点から来てるからこそそれをやってくれるんじゃないかっていうバイアスが結構かかりがちっていうのが、
結構落ちりやすな状況としてあるかと思ってます。
s-umemoto
横文字が多すぎてちょっと今頭に入りきれなかった。
今の話はマーケティング用語で置き換えると、
マーケットインとプロダクトアウトみたいな言葉だと思うんですけども、
ユーザーはこうやって欲しがるだろうと思う。
市場データとしてはそういうニーズが出てきてるよみたいなときには、
これをぶつけたらいいんじゃないかってやってみる。
けどもうまくいかないかもっていうバイアスがかかってしまってるよとかそういう話ですかね。
06:03
n-hara
そうですね。
結構ビジネス起点でのテーマでいろいろ事業を考えていくときには、
検証するときにもそのバイアスがかかってる状態でやってるので、
例えば新規事業だったらプロトタイプ1回目に見えるような形で作ってみて、
実際これ欲しいって聞いたりっていう検証とかもあったりすると思うんですけど、
このときにやっぱりバイアスとして欲しいだろうっていう前提だったりとか、
利用してくれるだろうっていう予定があるので、
実際にテストするときにもユーザビリティの観点が入っちゃって、
結果を解釈しちゃうっていうことが起きることがあるかなと思っていて。
s-umemoto
なるほど。
n-hara
なんでうまく操作をしてくれたからとか、
やってきたこと自体が価値があるんだとか、
っていうふうに紐づけてしまうっていうことが、
このフェーズでやろうとしたときにはよく起こってしまうことかなと。
s-umemoto
そういうことね。
わかりました。
なんか営業資料で欲しいかどうかみたいなのを検証しなきゃいけないけど、
営業資料の先の使い心地みたいなユーザビリティのところで検証したら、
目的とか得られる結果が別だから、
ちゃんと今の時期に合わせた検証目的を設定しないとダメよ、
みたいな話をしてくれてるってことですね。
n-hara
そんな感じです。
s-umemoto
難しいこと言うな。
でも大事だよね。
n-hara
そうですね。
プロトタイプ作ってやることによってイメージが、
お客様、被験者自体も聞きやすく分かりやすくて、
そういう良い面ってもちろんあるんですけど、
見るところがプロトタイプ自体の反応になってしまったりすることが多くあるので、
とりあえずボタンを押したとか、とりあえず文字があったんで読みました。
そういうことが起きていて、
実際そもそもそれ使ってくれるシーンってどういうシーンなんだろうかとか、
そもそも使ってくれる人ってどんな人なんだろうかっていうところの価値検証にはなってないっていうことがなるかなと。
それが授業のフェーズにあった正しい検証目的を設定しましょう。
これすごく全体的に一番重要かなって思ったところではあります。
s-umemoto
ありがとうございます。
n-hara
一番大事な話をしてくれたわけですね。
そうですね。
なので誤った解釈をしないように、まずは目的をちゃんと整理して、
この検証では何を知りたくて、それをどのように調整していくのかっていう、
何で分かるようにするのかっていうところをちゃんと明確にした上で、
結果を判断するっていうことが大事かなと思います。
s-umemoto
これでいいんじゃない?
n-hara
これだけでいいんですか。
09:01
s-umemoto
これに絞って、皆さんこれですから、目的さえあれば。
n-hara
本当に目的が大事ですね。
s-umemoto
目的が大事。
すみません、冗談をそこまでしてまして。
今のが一つ目なので、二つ目は何ですか。
n-hara
二つ目もすごい重要だなと思っているところではあるんですけど。
重要なんかい。
検証の後の工程をちゃんと具体的にイメージしていくっていうところで、
例えば分析、どういうふうに分析するのかとか、
あと分析しても何にアウトプットするのかとかですね、最終のゴールみたいなところは、
しっかり明確にした上で、それと逆算して質問設計をしていったりとか、
インタビューしないで設計していくっていうことになると思うので、
しっかりその結果、アウトプットっていうところを明らかにした上で、
検証を実施するっていう、そのあたりがすごく重要かなと思ってます。
そうですね。
それイコール多分仮説を立てるみたいなことと同じような話かなと思うんですけど、
こういう結果が出るだろうとか、こういう例えばペルソナに反映されることになるだろうとか、
利用シーンに反映されることになるだろうっていう仮説があって、
そこに対して今回の結果を反映していくっていうような形になる。
それをやっていくことによって、何を今回のテストでは聞かなきゃいけなかったんだったっけとか、
本当にこれで十分なんだっけっていうところの質問の内容の過不足にも気づくことができるようなものかなと思うので、
しっかりアウトプットとか、何の仮説を明らかにするための検証なのかっていう、
s-umemoto
ちょっと目的にもつながりますけど、そこをしっかり明確にするっていうのもすごく重要だと思ってます。
確かに。一つ目と同じぐらい大事な話でしたね。
そうですね。同じぐらいでしたね。
仮説がないと振り返りってほとんど意味ないですからね。
n-hara
そうですね。
s-umemoto
仮説がない案があると、仮説がない計画書みたいなのが出てきたら、
アートとビジネスは違うけど、アートの場合は別に何でもいいなと思うんですけど、
ビジネスの場合は仮説がなかったら、やらないほうがいいよねっていう感じですよね。
n-hara
そうですね。立ち戻る先がないのと、結果によって得られる学びがすごい抽象的というか、
仮説をしっかり明確にして、どこまで立ち戻らなきゃいけないのかとか、
何を更新しなきゃいけないのかっていうのは、しっかり定義してあるかと思います。
s-umemoto
はい。ありがとうございます。
そしたら3つ目お願いいたします。
n-hara
3つ目が、現象の流れによって被験者に与える印象を想定することっていうところで、
これはシナリオ設計とかにつながる話かなと思うんですけど、
アンケートとかインタビューの質問の流れを設計するときに、
12:02
n-hara
どういう流れでインタビューしたらいいんだろうかとか、
どういう感じで聞いたらいいんだろうって結構悩まれる方多いんじゃないかと思うんですけど、
結構この流れっていうのはユーザーの回答にもモロに影響するところがあるので、
どういった流れでユーザーに質問することが何の回答に影響を与えるのかとか、
例えばその辺りをしっかり注意をするというか、想定をしておくってことが必要になってます。
なので、1つ目検証の目的の話をしたと思うんですけど、
その辺の目的をクリアするためには、前提としてユーザーに対して何を確認する必要があって、
どういう流れで質問したらユーザーはその回答を答えやすいのかっていう観点を持つことが大事だと思うので、
よくインタビューのスキルとかで言われる、テクニックで言われるような浅いところから深いトピックに入っていきましょうとかっていう話があったりすると思うんですけど、
まさにそう思うので、事業側としてもこれを聞きたい、これを直球で欲しいかどうか聞きたいみたいなところがあると思うんですけど、
いきなりするとユーザーが準備ができてないので、その場で何か無理やり答えるとか、答えられないとかですね、そういうことが出てきてしまう可能性があるので、
ちゃんと質問を受ける側の思考の流れとか状況っていうところを想定して、じゃあどういう順番で聞いていったらユーザーは記憶をたどっていってスムーズにその回答を導き出せるのかとか、
その辺をちゃんと想定して設計するって重要かなと思ってますね。
s-umemoto
ラポーフの形成とかからですね、信頼をしてから、話しやすい雰囲気を作りながら、
n-hara
そうですね。
s-umemoto
再質問して確信というか、自分たちの本当の知りたいことを聞いていくみたいな流れをちゃんと。
n-hara
そうですね、そうですね。
s-umemoto
確かに大事ですね。
でも今こうやって話しても簡単だけど、これやると難しいんだよね、実際設計するときに。
n-hara
そうですね、そうですね。
s-umemoto
原さんが冒頭で話したみたいに、お客様ご自身でユーザーテストをできるようにするために、
こうやって体系的に伝えなきゃいけないじゃないですか。
n-hara
はい。
s-umemoto
この今日出してくれたアイディアっていうのは、その中でもやっぱり一番大事だなと思った3つを出してくれたっていう感じなんですか。
n-hara
そうですね。
特に多分注意が必要っていうところとセットかなというところでもありますね。
ポイントとして重要ですし、それをしないと結構起こるリスクというか、注意点みたいな。
s-umemoto
なるほど。
n-hara
はい。
s-umemoto
結構あれ、一つ目その検証目的で、そのサービス自体に価値を感じるかどうかっていうのと、
15:06
s-umemoto
サービスそのものが使いやすいかどうかみたいな状況に分けて、
ちゃんと設定しなきゃいけないって話をしてくれたと思うんだけど、
そういう設問設計がそこでちょっとごっちゃになってるなみたいなケースも感じたりはするっていうことですか、現場で。
n-hara
そうですね。多分多くあるんじゃないかなと思っていて、
やっぱりそもそもバイアスがあるっていうのが前提で動いてくるってことはよくあると思うんですけど、
このサービスで成功するとか、受け入れられるんじゃないかっていうのはやっぱり事業側としてはそういう期待を持って作っていると思うので、
それをやろうとしたときに、分かりやすいものとしてのプロトタイプとか、
ユーザーにとって価値がより分かるものっていうのを用意して反応を見るってことをやること自体はよくあるというか、
別にそこ自体が間違ってるってものではないと思うんですけど、
それをやることによっていろんな情報がユーザーに入ってくることになるんで、
ユーザーがそれを見て感じたこととか、言った発言とか行動っていうのが、
何に対して出たものなのかっていうのを割とちゃんと明確にしておかないと、
全体としては良くいい感じだったねって感じの結果を導いてしまって、
結局4人出したときは、そもそも使ってくれる人いなくて、
使いやすさどころの話じゃなかったよねみたいなことも起こる可能性があると思うので、
それはやっぱり事業の上、明らかにしなきゃいけないことっていうのはフェーズフェーズで違うと思うので、
ちゃんと前半のフェーズで確認をしなきゃいけないことを明確にした上で、
そこがクリアできてるかっていうのにちゃんと注力して、
客観的にしていくっていう、そういうことが必要なんじゃないかと思います。
s-umemoto
なるほど、いい話ですね。
ちなみに今日のテーマって、ユーザーの声を聞くときに気をつけなきゃいけないことじゃないですか。
どうやったらユーザーの声を正しくサービスに取り入れられるって原さんは考えてますか。
n-hara
そうですね、先ほどのその3つの注意点みたいなところを踏まえて、
やっぱり小さく回数を重ねることしかないんじゃないかなと思っていて、
初っ端からテストでうまい結果が出たりとか、正しい結果が出てくるっていうことは本当にないと思うので、
とにかくインタビューをするとかテストをすること自体に、
あまり失敗を恐れて1回で頑張って10人に対してやろうとか、
例えばそういう感じでハードルを感じてやるものではなくて、
本当にユーザーの声を取り入れるってことに対して、
にがるな状態でというか回数を重ねてやっていくチャレンジしていくっていうことによって、
多分振り返ったときに何が間違ってたのかっていうのが、
さっきの3点が明確になっていれば改善箇所みたいなのがしっかり分かると思うので、
じゃあ次はこうしていこうっていう、そういうサイクルを回すっていうのは、
18:02
n-hara
結果的には正しい声をちゃんと取り入れられてるっていう結果になってくるんじゃないかなと思いますね。
ユーザーの声を聞くときもやっぱり小さく回数を重ねていくっていうことをお聞きしましょうと。
そうですね。
10人とか20人とかは定量的にデータとして集めないと意味ないんじゃないかって思ってしまう場面もあると思うんですけど、
結果的にそれぐらいの人数に聞くのはもちろんいいと思うんですけど、
いきなりその人数に聞くって本当にすごい大変な作業だと思うので、
まずは5人とかですね、よく言われる5人とかに対して聞いてみることを、
回数を重ねていったら、それを4回やったら20人に対して聞いたことになるねとか、
そういうことだと思うので、なるべく一度に大人数にというよりは回数を重ねて小人数に対してやっていくっていう。
s-umemoto
分かりました。
今日はユーザーの声を聞くときに気をつけなきゃいけないこと、
基本でもあるんだけども本当に難しいというエッセンスをしっかり教えていただいたかなと思いますので、
皆さんぜひ参考にしていただければと思います。
今日も聞いていただきましてありがとうございました。
n-hara
ありがとうございました。
s-umemoto
編集後期。
久しぶりにネットワークの調子が収録中悪くなりましたね。
そうですね。後半がちょっと心配ですね。
全然つなげられると思うんですけど、最近編集ずっとサボってたんで、
前と後ろズバーンって切って音楽入れるだけみたいなやつだったので、
今回は途中ちゃんと聞いて、こことここいらないんだみたいなことしてつなぎ合わせなきゃいけないですね。
お願いします。
AIや音声編集も楽になるようにしなきゃいけないですね。
そんな雑談でございました。
今日もありがとうございました。
