サービスの課題やニーズを知ることを目的に実際にユーザーから意見を聞き出して調査するユーザーインタビューについて、2つの事例をもとに聞きました。
@spring_raining
こんにちは、UITの玉田です。今回もUIT INSIDEを始めたいと思います。UIT INSIDEは、ユーザーインターフェースとテクノロジーを愛する 開発者のためのポッドキャストです。さて、今回はユーザーインタビューについて話そうかなと思います。今回ユーザーインタビューに関わりのある 3人をお呼びして、実際にどういったことをやっていったかとか、どういうことを
@spring_raining
聞いていくとか、実施する上で考えていることなどなど話していければなと思います。それでは、よろしくお願いします。
@asakura_dev
よろしくお願いします。
@spring_raining
では、まず自己紹介ですね。自己紹介を3人の方にお願いしようかなと思うんですけれども、西山さん、お願いしてもいいですか。
@asakura_dev
はい。フロントエンドエンジニアをしています、西山です。Xのハンドルネームはasakura_devです。僕は今LINEドクターの方に関わっていて、ユーザーの方に話を聞く機会があったので今日参加してます。ただ今日はユーザーインタビューの専門家が来ているので、どちらかというと勉強させていただこうかなと思います。
@spring_raining
よろしくお願いします。
@asakura_dev
お願いします。
@spring_raining
では、お願いしてもよいでしょうか。
Tetsushi FURUYA
はい。LINEヤフーでメディア系・情報系のサービスでユーザーリサーチを担当している古屋と言います。
@spring_raining
はい、よろしくお願いします。
Moyu Hanada
はい。同じくメディア系・情報系のサービスでユーザーリサーチを担当している花田と申します。よろしくお願いいたします。
@spring_raining
よろしくお願いします。 今回はですね、この3人お呼びしたんですけども、枠組みとしては、西山さんが参加されたユーザーインタビュー、そして古屋さん、花田さんが参加されて、参加というか 実施されているユーザーインタビューの2つケースを今回
@spring_raining
用意していまして、それぞれの内容についてちょっと最初に簡単に聞いていこうかなと思います。
@spring_raining
では、 実際にユーザーインタビューをされているということで、古屋さん、花田さんのケース についてちょっとお伺いしようかなと思うんですけれども、まず、もう結構あれですかね、もうかなりの回数をこなされているということなんですけれども、どういった形で、ユーザーインタビューとか形態についてちょっと
@spring_raining
聞いてもよいでしょうか。
Tetsushi FURUYA
そうですね、形態というか、大体ボリュームっていうのは年間に数十とか いうくらいやってるっていう感じですね。どういう雰囲気でやるかっていうのは様々で、
Tetsushi FURUYA
テスト的にやるというか、まずリサーチチームの内部で仮説検証をするためにやるっていうケースもあるし、企画の、事業の企画の中から生じているその仮説検証ポイントとか いうものを明らかにするためにインタビューすることもあるし、 あとはその企画の人たち、エンジニアとかデザイナーも含めてですけれども、そういう人たちのそのユーザーに対する理解を高めるためのインタビューみたいなこともやってるよ、みたいな感じですね。
@spring_raining
じゃあ、あれですね、目的自体は様々で、その目的に合わせてこう、どういったことを聞くかっていうのをあらかじめ決めて、 インタビューをするんですね。
Tetsushi FURUYA
そうですね、結構お題が降ってきて、それを満たすためにやるというよりは、自分たちリサーチのチームの方から、この今の事業の課題ってこうだよねみたいな問題意識を先に持っていて、 で、その問題意識をできるだけこう事業企画、事業の皆様の方にも共有した上で、やっぱりユーザーに何か聞いてみた方がいいよねみたいな 空気作りというか、そういうところから含めてやってるっていう感じですね。
@spring_raining
なるほど。逆になんていうんですかね、こう、あまりこうなんて、今回はこういうことを なんか聞こうかなと思わずに、こう、雑談というか、こう、本当にこう、率直な意見みたいなのを 聞くためにユーザーインタビューをするってことはそんなにないですかね。
Tetsushi FURUYA
一応あれですね、ぱっと気軽に聞けるサービスみたいなものも世の中にはあって、そういうもので 構えずにというか、思い立ったらもう1時間後に聞けるよみたいなサービスもあるので、そういうサービスを使ってちょっと軽く聞いてみると いうこともやりますし、課題の内容によっては、これちゃんとみんなで準備して、どんなことを聞いたりとか、どういうものを見せて感想を聞くのかみたいな、周到な準備をしてやるっていうケースも
Tetsushi FURUYA
あるので、様々ではありますね。
@spring_raining
なるほどなるほど、ありがとうございます。もう1点、そうですね、事前にヒアリングをした上で、ちょっと聞いてみたいなと思ったのは、結構、割とこうなんですかね、トークスクリプトというか、こういったことを聞こうかなと思う上で、ここういうこと、順番で聞いて、こういうみたいな、 あるという風に伺ったんですけれども、結構そういう、こういうことを聞きたいみたいな
@spring_raining
目的がある場合だと特にそうなんですけども、そういう、こう、どういう、こう、トークスクリプトがあったりとか、そういうのもあったりする
Tetsushi FURUYA
そうですね。なんか、リサーチ業界的にはよくインタビューフローという風に呼ばれるんですけど、アンケートで言うと調査票みたいな扱いのものとして、インタビュー側ではインタビューフローと いうのが一般にはあって、で、その、このインタビューでは、1番こういうこと聞きたいんだよねみたいな ものがあるんですよね。キーのクエスチョンになるものがあるんですけど、いきなりこう、インタビューの冒頭で、そのキーのクエスチョンだけをいきなりドカンとぶつけるっていうのは、
Tetsushi FURUYA
ちょっと有効なお答えを引き出すことができないケースが多くて、 でそこのキーのクエスチョンに至るまでに、どういうこう、インタビュワーとインタビュイーの 間にこう信頼関係であるとか情報のこう共有であるとかを進めていくかっていうことを考えながら、どういう順番でどういう質問をしていこうかな、どういう会話をしていこうかなっていうことを事前にある程度設計したり準備したり
Tetsushi FURUYA
することをまとめたものがインタビューフローというものになるかなという風に思ってます。
@spring_raining
やっぱりそういうところ、こう、なんかいきなりこう直接聞くと聞き出せないみたいなのが、その通りだと思うんですけど、では、それをこう、実際にこう実践していくのっていうのは、すごく、こう、話しながら、聞きながら、こう頭を使うっていう、すごい、めちゃくちゃやっぱり 私だと特に難しそうだなって思うところではあるんで、なかなかすごいプロだなっていう、すいません、
@spring_raining
感想が幼稚ですけれども、そういうところは、はい、思いましたね。
Tetsushi FURUYA
実際にそのインタビューのプロっていうものは世の中には存在していて、 その、もうインタビューだけで飯食ってるみたいな人はもう結構いるんですね。もう有能な方はもういろんな企業に引っ張りだこになってるような領域ではあって、 奥の深い領域ではあるんですけれども、だからといってその専門スキルを
Tetsushi FURUYA
確実に有している人じゃないと実施できないのかっていうとそういうわけではなくて、あくまでも会話の延長線上ではあるから、もちろんそのスキルの領域はあるんだけれども、ある程度その会話というか、 もしくはこうビジネスに資するこう聞き出し方ってのはどういうものかっていうことがある程度分かってる方であれば、別にその専門職に限られた話ではなくて、企画の人でもデザイナーの人でもエンジニアの人でも、 なんだったらバックオフィスの人でも全然できるものではあります。
@spring_raining
ありがとうございます。そうですね、結構なんかコツとか、すごいそういうなんかうまくやる方法みたいなのは、すごい後でも聞いてみたいなと、はい、思っております。
@spring_raining
では、次は西山さんのケースについて伺いたいんですけれども、西山さんのケースだと、あれですかね、あんまり厳密にはユーザーインタビューではないですかね。
@asakura_dev
そうですね。自分が担当してる、今、LINEドクターっていうサービスなんですけど、ユーザーが、いわゆる診療を受ける 一般のユーザーと、あともう1つ、医療機関とか薬局とかもLINEドクターのユーザーなんですけど、そこの、今回僕が言ったのは、その、お医者さんのところに行って、ざっくばらんに話を聞いてきました
@asakura_dev
ていう感じでした。
@spring_raining
あれですね、いわゆるtoCではなくて、toBというか、プロっていうか、その、限られたその業種の人が使うサービスっていう、
@asakura_dev
そうですね、完全にもうお医者さんが使う部分に関して、 不満点であったり、ここが変だったり、こういう機能が欲しいとか、そういうちょっといろんななんかアイデアをもらいに行ったという感じでした。
@spring_raining
なるほど。なかなかあれですね、単純にこう、ちょっとビクビクしながら聞いてきそうですね。すごい。めっちゃクレームつけられたらどうしようかと。
@asakura_dev
そうですね。 僕自身が実際にその使ってるユーザーのところに、本当に現場に行くっていうのが初めてだったので、ちょっと緊張 して。あと、失礼のないようにっていう。
@spring_raining
はい。
@asakura_dev
新卒研修の時を思い出しながら行った感じでした。
で、元々その、いわゆるカスタマーサクセスという、普段その医療機関とか薬局と向き合ってるメンバーの人が、定期的にそうやって医療機関とかいろんな方に話を聞きに行くんですけど、そこにエンジニアもせっかくならついていったらどうですか。っていう提案をもらって、それで、じゃあ
@asakura_dev
ついてきますっていう感じで話を聞きに行った感じでした。
@spring_raining
なるほどなるほど。そうですね。結構こう言って、ざっくりこう 感想というか、こう言ってよかったとか、こういう情報があったとか、こういうフィードバックが、 自分の中でフィードバックがあったりとかはしましたか。
@asakura_dev
そうですね。今回、その医療機関にその一定ヒアリングするっていうことが、エンジニアというか自分自身のゴールと してはやっぱり、行ってきたらって言ってもらったその人の意図としては、視野を広げるっていう、エンジニアの視野を広げるとか、モチベーションが上がるとか、多分そういう部分だったので、なんかそこの部分はやっぱり色々学びがあったかなと思いました。
@asakura_dev
普段って本当にそのスクラム開発をしてるんですけど、毎回その2週間のスプリントの中で、目の前の仕事に本当に一生懸命ってか忙殺されてて。で、その分やっぱり ちょっとユーザーさんとの距離が遠くなってしまったりとか、理解が不足していく部分があると思うので、なんかそういう中で、実際にその ユーザーの話を聞いてっていうところで、なんていうか、現実に引き戻されるじゃないですけど、よりなんか、
@asakura_dev
広い視野で、長期的な視野でサービス開発に臨めるようになったかなっていう風に思いました。
@spring_raining
そうですよね。なんかもう、自分も実際そうなんですけど、こう作っている、実際に作っている人が 作っているものが、こう実際にどういう人に使われてるのかっていうのを、頭では実際にこれは使われてるっていうのはわかるんですけど、 では、それがどういう、こう、感想を持って聞かれてるのかっていうのとか、本当になんかもう、自分も経験あるんですけども、すごい、予想外の使われ方を
@spring_raining
するみたいなのはすごくよくあることですし、そういう繋がり、繋がりっていうか、こう、 断絶がなくなるっていう、そういう繋がりを持てる機会っていうのは、 すごいいいなと思いましたし、すごい。あと1点、すごいいいなと思ったのは、そういう、ユーザーインタビュー、ヒアリングきませんか。っていう、
@spring_raining
声かけしてくれること自体が、すごい、めっちゃいい。
@asakura_dev
そうですね、はい、すごくありがたかったです。そこで、その1個、その追加で学びというか気付きとしてあったのが、 で、色々その医療機関に話を聞いていくと、もちろん知ってるはずだし、当然のことなんですけど、いろんなツールを使われてるんですよね。我々が普段 slackとかzoomとかwikiとかいろんなたくさんのツールを使うのと同様に、医療機関もいろんなサービスを
@asakura_dev
利用しているので、なんか自分がそのサービス作ってる時は、なんか自分のサービスが主人公だと思って結構作ってたんですけど、どうも話を聞いていくと、本当にたくさんあるサービスのいろんな併用してるサービスの1つというか、 主人公じゃないんだなっていうことに気づかされたので、自分たちのサービスが中心として使われてるって思って考えて作ると、すごい危険だなっていうのは、例えば画面サイズとかを、 なんていうか、自分のサービスをブラウザ100パーセントで使われてるとは限らないと思うので、そういう学びもありましたっていう感じでした。
@spring_raining
では、そうですね。じゃあ、次で話すことで言いますと、 色々とこもう、さっきの話でも、すごいユーザーインタビューをやることですごい得られた情報っていうのは、もう本当に聞けたかなと思うんですけれども、 これはどちらかというと古屋さん、花田さん向けに我々こうユーザーインタビューの
@spring_raining
素人ではあるので、もし今後こういう、ユーザーインタビューをする、実施する上でこういう ことをやればいいよみたいな、そういうすごい花田さんが、特に実際にユーザーインタビューをされてるのは花田さんですよね。はい、そうです。
何かこういうアドバイスみたいなのは難しいとは思うんですけど、もしあれば聞きたいなと思っております。
Moyu Hanada
なんかインタビューをするときって、こう、インタビュー相手ってどういう人が来るかいつでもわからないんですよ。
こう、どんなユーザーさんが来るかって、ほんとに話し始めてちょっと時間が経たないとわからなくて。例えばこう、想像していたようなインタビューフロー、 さっきあったように、どういう質問をしていくかっていう順番をこう全部していったとしても、時間がすごく余ってしまうこともあれば、なんか時間がすごく足りなくなってしまう、この質問を聞きたいのに。みたいなことが
Moyu Hanada
結構多く、人によって、どんな人かによって、その質問、同じような質問をし続けるっていうことが難しいので、もしこれからインタビュー初めてするよ。初めてやって不安だよ。みたいな人は、本当に自分が質問したいこと以上に、3倍とか4倍ぐらい 聞きたいことを持っておくと、どんなユーザーの人が来ても何がしかサービスにとって力になるような企画の元であったりだとか、何か課題解決の
Moyu Hanada
1個、未来の課題解決の手になるような意見が聞けるかもしれないので、こう聞きたいことは、実際に聞きたいことの量の3倍とか4倍とかもって準備しておくといいかなとは思います。
@spring_raining
なるほどなるほど。本当にそうですね。全部聞くわけではない。でも、その話の流れでこういうことが聞けるなみたいな、そういうのを考えながらピックアップしていく
Moyu Hanada
そうです。そうですね。あとは、私は事業部についている そのリサーチャーなので、その事業部の全体の課題を認識して挑むと、例えば、今時間が余っちゃっても、今こう話している、今本当に解決したいと思って持ってきたネタよりも、全然違う事業部内の領域のネタだったらこの人に聞けるかもしれないな
Moyu Hanada
いうことがあると思うので、その結構狭い視野ではなくて、結構広く課題を認識して、で、こういう人に聞いたら答えが出るんじゃないかっていうのを把握しておくと、調査の コスパが良くなるっていうか、こう、時間とか1回の回数に対して得られる情報は多くなるかなとは思いますね。
@spring_raining
なるほど。今回の場合だと、複数人に聞くっていうのも確かにそれはありますよね。その複数人でそれぞれそのユーザーインタビューの内容が変わった時に、この人には聞けなかったけれども、後日そういう 聞きたいことみたいなのが、あそこからチョイスっていうところもできると思いますし。
そうですね。本当に話の流れっていう、すごいふわっとした感じですけども、
@spring_raining
本当に。ちなみに、そういう、その3倍、4倍こう聞きたいことを持っておくっていうことの外側に行くというか、それでもこう自分たちの想定してなかったこう 内容が出てくるみたいなこともあったりしますか。
Moyu Hanada
そうですね。逆に、なんだろう、もうインタビューして聞いていくっていうのは、質問に対する答えを聞いていくというよりかは、その人がどういうふうにこの私たちのプロダクトを使っているのか っていうのをの解像度を上げていく作業だと思っていて。だから、その質問に対する応答でその答え合わせをしていくというよりかは、なんかその人の人間像というか、その人がどういう人なのかを知るために言葉を
Moyu Hanada
かけて答えを知ってくみたいなのの繰り返しになるので、逆にこう、もうそのプロダクトに対する使い方がルーティーンで決まっていたりだとか、もう自分として明確な答えをお持ちの方だったりすると、なんか15分ぐらいで聞きたいこと全部聞けちゃうみたいな ことも起きてしまうので、なんかそういう時は、その、オンラインインタビューをやっている、普段オンラインインタビューでやっている時は、その、一緒に聞いている、それこそ今一緒にご同席いただいているふるやさんであったりとか、事業部の方とかもご同席いただいているので、
Moyu Hanada
質問ください質問くださいみたいな感じでリアルタイムでslackを送って、こう質問をいただいてその場でするとか、 そういう感じで対応することもありますね。
@spring_raining
お、ということはあれですかね、その質問、ユーザーインタビューに参加してる人っていうのは、1人、2人とかではないということなんですかね。
Moyu Hanada
1人2人と、何人かが聞いているパターンていうのもある。はい、そういった時は そういうことで対応します。その3倍、4倍持ってても、質問を仕切ってしまう時は、そういう風に質問をもらおうとしたりします。
@spring_raining
そうですね。なんか、普通の質問だと、こう、はい、いいえみたいなので答えられる質問とかも全然出せると思うんですけど、そういうのではなくて、こう、話を広げられるような質問をいっぱい用意するっての、すごく、こう、事前準備がすごく時間がかかりそうだなという風に感想としては思いましたけど、やっぱりそういう準備が大事ということですね。
Moyu Hanada
そうですね。質問、どんな質問するかって、その、あまりにもその、インタビューの本線と離れすぎてしまうと不信感を抱かれてしまうかもしれないので、あくまで私たちの場合は スマートフォンの使い方の範疇というか、スマートフォンと普通の生活の範疇の中で、こう、どういうこと聞いたらいいかなっていうことを考えて準備しますね。
@spring_raining
確かに個人情報とか聞くわけではなくて、そうですよね。関連のある内容、かついろんな範囲を理由。すごく いやでもなかなかこう、1中一夜では難しい、マスターできなさそうな、すごいところだなと思いました。
Moyu Hanada
でもなんか私もここ1年2年ぐらいで初めてやるようになったんですけど、やってみないとできるようになんないので、 最初はなんか、ある程度なんかインタビューフロー決めて、なんかパって話に行っても平気なんじゃないかと最近は思います。その、始める前はすごい知らないことは怖いことなので、すごい怖かったんですけど、 始めてしまえばもうなんかやるしかないからっていう。
@spring_raining
おお、すごい。
Moyu Hanada
そんなに身構えなくてもいいものかなと思います。
@spring_raining
ちょっと思ったのは、このUIT INSIDEの収録自体もちょっとユーザーインタビューに似てなくはないなとは思ったんですけども、 ただあれですね、こう、意味のある情報を引き出すっていうところの難しさはありますよね。この収録自体は本当にこう、何かこう聞いて、こう、身になるような情報が 引き出せたらいいなっていう、すごいふわっとしたところなんですけども、そういう誘導ではないですけれども、何かこう、やっぱりそのユーザーインタビューをすることでこういった情報を得たいみたいな目的が出てくると一気に、
@spring_raining
そうですね、難しさ、難しさっていうか、こう、準備がやはり必要になってくるところでありますし、本当にためになりました。
@spring_raining
じゃあ、そうですね。もう1点伺いたいところでいきますと、 今回そのフロントエンドにエンジニア向けのポットキャストの中でユーザーインタビューに関することについて聞いていこうかなとは思ってたんですけれども、じゃあ、そうですね、
@spring_raining
逆にこう、ユーザーインタビューを実施するチーム側からして、ユーザーインターフェースのところでこういうことについて意見を来ることが多いとか、何かこう、エンジニアに対して、こういうところに気を付けて設計をするとユーザーに好感が持たれるとか、 印象が変わるようなところとかってあると聞いてみたいなと思いました。
Moyu Hanada
今のそのなんか切り口というか、なんかユーザーの人ってほんとに私たちみたいにパーツごとの 言葉を知って使ってるわけじゃん。このモジュールごとの呼び方も知らないし、メニューの呼び方もわかんないし、 そこまで詳細に理解をして使っているわけではない方が多いから、
Moyu Hanada
1つのパーツをこう呼ぶのにも、この面どうですか。って聞くのにも、聞きたかった言葉っていうものがあまり返ってこないような、そういうものがユーザーインタビューだったりするんですね。だから、その 直接エンジニアの方にこういうことが喜ばれますよっていうのは結構切り出して取ると結構難しくて、これはなんだろう、デザインの問題と、こういう企画の問題と、こういう導線の問題と、こういう開発の問題が全部混ぜこぜになった状態の意見だなみたいなのが
Moyu Hanada
出てきたりすることが多いので、こう何かを切り出してちょっとこの部分がっていうのはちょっと難しいかもしれないです。想像、自分たちがこう作っているプロダクトとか開発しているものとかって、こう自分たちはよく知っているから、こういう風に使われるだろうとか、それこそさっきのその西山さんのお話でもありましたが こういう風に使われるだろうって想像していたりとか、この面は横カルーセルって呼ぶよなって思ったりするかもしれないけど、そうは伝わってなかったり、あとは、ここってレコメンド領域だと思ってたけど、別にそうは捉えられてなかったりとか、
Moyu Hanada
そういったことってすごいいっぱいあるので、なんか逆に1回自分のITリテラシーを0だとして、1回スマートフォンとか プロダクトを見てみると、新しい視点じゃないですけど、そういう気持ちでユーザーって使ってるのかなって思ってもらうことはできるのかなと思います。
@spring_raining
なるほど。いや、本当にそうですね。多分、それぞれの画面とか、それぞれのコンポーネントに名前がついてて、 理想で言うと、このコンポーネントについてどう思いますか。とか、この名前のついてるこの画面についてどう思いますか。みたいなのは、 あれですね、あんまりこう、期待、具体的なこう意見を期待してユーザーインタビューっていうところでは、やっぱりなかなか難しいんですね。
Moyu Hanada
なんかそういう時は大体こう、なんか使ってるサービスとか、普段このお使いのこの面、どういう風に見てますか。って ふわっと聞いて、そこから出てきたボキャブラリーを使って同じように繰り返して、私も同じような言葉を使って返していくくらいしかなるほどできないので、なんかそれも難しさであり、 ピンポイントで結構エンジニアの方に何か有用なって言うと結構難しいかもしれないな、
@spring_raining
うんうん。でもそれは実際なんて言うんですか。本当にその問題がどれか1つの要素、例えばUIのここがダメだから こういう意見が来るっていうことは実際そんなにないのかもしれないですね。本当にこう、もっと根本的にこう、ここの連携が良くないとか、 そもそものそのこの機能のこの発想が良くないとか、そういうところまで踏み入ってしまうっていうところはやっぱりいっぱい出てくると思うので、
@spring_raining
そうなってくると、本当に、こう、 ここダメだから直した方がいいみたいな、こう、そういうフィードバックっていうよりは、やっぱりむしろこう、本当に、今回の西山さんのケースもすごいそうなんですけども、本当に実際にこういう使い方をされてるっていうのが 知れるっていうこと自体が、やっぱり1つの本当に良い情報として私たちが受け取れるところなのかもしれないですね。
Moyu Hanada
古屋さんなんかありますかね。
Tetsushi FURUYA
結構そのプロダクトがそもそもどういうものだと位置づけられているのか。利用者の皆様の頭の中に、その事前の期待であるとか、想起であるとかっていうことと、その起動した後に どういう風に使おうと思うのか、その画面に映ってるものをどういう風に捉えるのか、何に着目して、何を気づかないのか、みたいなことって、事前の認識、事前の想起っていうことと強く連動しているものだと思うんですよね。
で、そのこのプロダクトは一体どういう方向性のものなのか、どういう性格のものなのか、何をやるためのプロダクトなのかっていうイメージ
Tetsushi FURUYA
の話と、内部の体験って、すごく強く結びついているってことをいつもインタビューしてて感じるんですよね。
全く同じその機能があったとしても、性格によって、そのプロダクトの性格一致付けによって、使われ方自体も変わってくる みたいなことはすごくあるんですよね。例えばSNSみたいなことだと、誰でも、例えばどんなSNSでもポストできる、いいねできる、フォローできるみたいなことは基本的な機能は大抵揃ってると思うんですけど、
Tetsushi FURUYA
しかしSNSごとに全然使われ方というかは違うわけですよね。それって、その機能とかUIパーツだけの話ではなくて、 どういう位置付けのものとして認識しているのかっていうことと、使われ方が連動しているっていうところが いつもあるなという風にインタビューしてても思うので、単にこの機能があるからこういう風に使ってくれるはずじゃんみたいなことっていうのは簡単には通用しない。
Tetsushi FURUYA
そこを変えたいんだったら、そもそものこのプロダクトのキャラクター、ブランド、位置付けみたいなものからこう変えていく必要もあるかもしれないし、 そこを変えるのは難しいんだったら、その今の自分たちのプロダクトがどういう位置付けのものなのかっていうものを直視した上で、そこにそぐう、 ぴったりマッチするような機能を提供していくっていうような割り切りなのか、ことが必要なのかなとは思いますね。って感じですかね、
@spring_raining
本当に、SNSの例とかもそうですよね。なんかもう機能で言うと、どのサービスも同じ機能を提供してるはずなのに、使われ方ってのはもう全然変わってくるっていうのは、やっぱりニュアンスとか細かいところだけではなくて、本当にそういう、これは文化というか、そういうところも 本当にあると思うんで、そういうところは、私たちが得ていくための手段がユーザーインタビュー、多分ユーザーインタビューでしかそういうところって得られない
@spring_raining
気はしますよね。うん、本当になんか私もちょっとお願いしたいですね。そのユーザーインタビューについていってもいいですか。っていう。
@asakura_dev
なんかもう1回話聞いてみてと。今の話を聞いて思ったのが、なんかエンジニアの視点としても、理想は 一旦コードも仕様書も全て忘れた状態でこのサービスってどう見えるのかなって体験できたり、知れるとそれが理想だと思うんですけど。やっぱり我々はもうコードも仕様書も知っちゃってるので、 そこのバイアスっていうのは常にあるので、やっぱりそこで、じゃあ実際ユーザーさんがどう感じるのか、どう見えるのかっていうのは、やっぱりユーザーインタビューを通してじゃないと知れないのかなっていう風にちょっと思いました。
@spring_raining
記憶をなくすのは無理なので。
@asakura_dev
そうですね。
@spring_raining
ユーザーインタビューを皆さんやって、ちゃんとエンジニアもそんな人ごとじゃなくて参加しましょう、ちゃんと聞いてみましょうという。あの、あれですね。 聞いてみましょうっていうか、そのユーザーインタビューで得た情報を間接的に聞くのではなくて、直接聞くのがやっぱ1番かもしれないですね。
Tetsushi FURUYA
もうそれはね、本当にそう思いますね。こう、レポート、インタビュー調査をやりました、どなたかがやりましたと。
で、そのレポートを読んで理解した気になるんじゃねえよっていうところをいつも思うんですよね。本当に、実際に自分の目で 見聞きするっていう、そのレポーティングされてることの外側にもかなり重要な情報が含まれてるので、そこを見に行った方がいいのかな、直接取りに行った方がいいのかなっていう風なことはいつも思います。
@spring_raining
肝に命じておきます。ありがとうございます。いや、本当にいい話が聞けてよかったです。ちょっとまた 皆さんこれを広めていこうかなと思います。はい。ではじゃあいい時間になったのでクロージングに移ります。
@spring_raining
今回はユーザーインタビューについて色々な話を聞いていきました。LINEヤフーのフロントエンド組織UITでは、このような技術的なキャッチアップを日々行っております。
@spring_raining
UIT INSIDE以外にも、毎週にも様々なフロントエンドの情報交換を行っています。
今後もUIT INSIDEを通してこのような情報を外部に発信していけたらと思います。
最後にこのポッドキャストに対する感想をお待ちしております。
@spring_raining
#UIT_INSIDEでツイートしていただきますと、スタッフがひろいます。エピソードのご意見やご感想など、いつでもお待ちしております。
それでは、ありがとうございました。
@asakura_dev
ありがとうございました。
Tetsushi FURUYA
ありがとうございました。
