勉強会メモ「THE GUILD勉強会 〜ユーザーインタビュー設計〜」
THE GUILD主催のユーザーインタビューに関する勉強会に参加してきました。
今回はじめて社外向けに勉強会を実施されるということで、note枠で運良く滑り込めたのでレポートを書きます。
※言ってることが違う!などの問題があったらお知らせください!修正します…
概要
- #01 THE GUILD勉強会 〜ユーザーインタビュー設計〜 @DMM.com
- 「ユーザーインタビューとは、ユーザーから直接意見を引き出す重要なプロセスです。実際にユーザーに会いに行くことによって、データからは読み取れない情報を引き出し、ニーズや課題を発見することができます。今回の勉強会ではユーザーインタビューをどう行えばいいのか、ゲストスピーカーの皆さんにお話していただきます。」
- 日時:2018年4月12日 19:30〜
- 場所:DMM.com
- ハッシュタグ:#theguild_study
session 1. ユーザー中心組織論 〜ユーザー目線を中心とした組織を作るために〜 (金子 剛)
金子 剛:弁護士ドットコム株式会社 / デザイン・マネージャー
note記事: https://note.mu/osi_ire/n/na5e09ee243eb
スライド: https://www.slideshare.net/tsuyoshika/ss-93644660
インタビューはなぜ必要なのか?
● サービス開発においてユーザーインタビューをやることの一番の意味は、「他者視点」でものを判断できるようになる点。
- →物事は視点によって見え方が変わる:例えば、アルファベットの「U」を見る場合……正面から見ると、「U」に見えるが、横から見ると、「I」に見える。そして上から見ると、「:」に見える。
- →これはサービス開発でも同じ。企画者、デザイナー、ユーザーなど視点によって見え方が変わる。
- →なぜ違って見えるのか:価値観・境遇・知識の違いが大きい。
- 引用「常識とは、18歳までに身に着けた偏見のコレクションのことを言う」by アインシュタイン
- →ユーザーを理解しユーザー目線でプロダクトを評価するためには、共感が必要。
● 共感とは?
- 「他者と喜怒哀楽の感情を共有することを指す。もしくはその感情のこと。例えば友人がつらい表情をしている時、相手が『つらい思いをしているのだ』ということが分かるだけでなく、自分もつらい感情を持つのがこれである。」by wikipedia
● 「共感」と「同情」は違う
- 共感は、相手に入り込むこと。同じ苦しみを感じること。相手のことを想像すること。一方、同情は、自分だったら〜で考えること。苦しみを客観視すること。自分の実体験から類推すること。
● インタビューで大事なのは「相手を知り、共感する」こと。
- →例えば、スマホが欲しいというときは、「どんなスマホが欲しい?」「なぜそれがほしい?」「そう思った背景は?」ということをどんどん深掘り、紐解いていくことで、「相手の価値観」を知ることが重要。
- →こうしたプロセスを通して、同じ目線でプロダクトを評価することができるようになる。
なぜ組織で考えなければいけないのか?
● インタビューを行うだけでは成し遂げられないこととは何か
- →インタビューを推進するということは、価値判断を「ユーザー。中心」にすることと同義である。
- 例:「群盲象を評す」
- 象の足を触った盲人は「柱のようです」と答えた
- 象の尾を触った盲人は「鋼のようです」と答えた
- 象の鼻を触った盲人は「木の枝のようです」と答えた
- …
- →象はこれらの特徴をすべて捉えており、触り方によって、全然違う評価ができてしまう。
- プロダクト開発もこれと同様で、別の視点で評論すると、違う評価がでてきてしまう。プロダクトの「価値判断」は多元的である。
「ユーザー中心な組織」=価値判断を「ユーザー中心」にすること
● インタビューは、プロダクト開発のプロセスの中のほんの一部である。
● ユーザー中心でプロダクト開発をするためには、5つのポイントがある。
- ①Vision、②ビジネスモデル、③カルチャー、④チーム、⑤プロセス
- それぞれをユーザー中心に設計し直すためには?を以下詳しく見ていく↓
①ユーザー中心な「Vision」とは
● インタビューでは「なにを?(目標)」と「どう?(手法)」はわかるが、「なぜ?(使命)」は分からない。
- Vision(なぜ?)は、一般的な企業やプロダクトには大体あるが、あわせて「誰のため?」という問いが重要になる
● すべての人の視点に同時に立つことは不可能なので、「誰のため?」を明確にするためにプロトペルソナを作る。
- 1. どんな思いがあるから
- 2. 誰に ←ここでプロトペルソナ
- 3. どうなってほしいか
● プロトペルソナを作成する時には、Visionオーナー(熱を持っている人)を巻き込むことが重要。
- 誰のためのどんなVisionなのか、チームで共通認識として持てていることを目指す。
②ユーザー中心な「ビジネスモデル」とは
● サービス開発においては、ビジネスの正のスパイラルを回すことが大事。
- 価値の創出→ユーザーに届く→マネタイズ→(価値の創出)…
● 例えばリーンキャンバスを使えば、「価値からKPIがひとつなぎになっているか?」が分かる。
- この作成には、ビジネスエキスパート(会社の経営や売上を担っている層)を巻き込むことが必要。
③ユーザー中心な「カルチャー」とは
● インタビューにあたって大切な価値観は、「私たちはユーザーのことを知らない」という発想。
● 2種類の考え方:理性主義と経験主義
- 理性主義とは:わからないことは「考える」。原典から導く。学力テスト。前提から知識を得る。ウォーターフォール的。
- 経験主義とは:わからないことは「試す」。経験から導く。科学実験。行動から知識を得る。アジャイル的、リーン的。
● サービス開発は、「不確実性との闘い」である
- 「わかること」より「わからないこと」が圧倒的に多く、コントロールできない状況である
- →わからないなら、試すしかない。リスクを減らして試す
- →経験主義的なカルチャーを生み出すのが大事
● カルチャーはどう育むか?
- 金子さんが思う1つの解 → [デレク・シヴァーズ「社会運動はどうやって起こすか」
● ペンと紙をもって、今すぐ外に出よう
- まずは自らが「ダンス」しよう
- 大切なのはインタビューの精度ではなく「聞く文化」である
④ユーザー中心な「チーム」とは
● メンバーの多様性が高いほど、イノベーションの価値が高まる
- 参考: https://hbr.org/2004/09/perfecting-cross-pollination
- 改善を繰り返すのであれば、多様性の低いチームでコツコツ積み上げるのが良いこともあるが、イノベーションには多様性が必要
● 多種多様な職種で直接インタビューするチームは強い
- 多様性のあるメンバーを揃える
- インタビューに全員参加できる体制をつくる
● 大切なのは共感の「解像度」であり、それを上げるには作り手が実際にインタビューすることが求められる
- リサーチ会社に委託するより、リサーチャーの仲間をつくる方が良いと考えている(実体験でないと「共感」の解像度が下がるから)
- 可能なら、一緒にインタビューしてくれる専門家を探してほしい
- 自分でやるのでも良いが、仲間は増やしたほうがよい
⑤ユーザー中心な「プロセス」とは
● インタビューは単発のイベントではなく、学びのプロセスに組み込まれている必要がある
● 学びのプロセスで重要なポイント
- 1. 事実と推測の分離
- 2. インプットタイムの導入
- まず既知の知見を整理しよう
- エキスパート(すでに長年その問題に携わっている人、ユーザーに日常的に触れ合っている人、対象の問題に詳しい人、間接的にユーザーを観測している人)の知見は重要
- 3. 学びのサイクル
- 実験により事実を増やして成長するチームへ
- インタビュー(実験)を通して事実を増やして、発見し、事実を集め、推測するというプロセスを回す
● このプロセスを回していく内に、チームは成長し、エキスパートになっていく
- 成長する組織を作るために、学習するプロセスを回そう
総括
● インタビューで最も重要なのは「共感」である
● 「ユーザー中心」を組織に根付かせるには、5つの観点(Vision、…)を行き来する必要がある
● はじめは完璧でなくても良い
- まずは1人からはじめ、プロセスを回すうちに成長していく
● インタビューで得た熱量は、組織に宿る
- インタビューをイベントで終わりにしないために、しっかり組織に根付かせてほしい
参考図書
- Lean UX
- デザイン思考でゼロから1を作り出す
- エンジニアリング組織論への招待
- クリエイティブマインドセット
session 2. 「ユーザーの声を聞きたい」環境を整える 〜最小単位とプラス1〜 (西部 渉、伊藤麻紀子)
西部 渉:株式会社 DMM.comラボ / UXデザイナー
伊藤 麻紀子:株式会社 DMM.comラボ / UXデザイナー
note記事:https://note.mu/sukekiyo918/n/nfa40917332ec
スライド: https://www.slideshare.net/AyumuNishibe/1-93770575
ユーザーインタビューの相談が来てから完了までのプロセスを具体的に紹介。
最小単位:Step1 ヒアリング
● よくある相談パターン
- パターンA「データ見ながらサイト改修をしたんだけど、想定してたようにCVが上がらなくて、、、なんでかわかります?」
- →目的:定量データの裏付け(理由)を探りたい
- パターンB「新しくサービスやるんだけど、実際にニーズあるのかなあ。ターゲットに確認したい、、、」
- →目的:ユーザー課題の抽出・深掘り
- パターンC「サービスリニューアルにあたって、コンセプトが受け入れられるか、ユーザビリティ的に問題ないか、確認したいんだけど何かいい方法ありませんか?『UX的に』アドバイスありませんか?」
- →目的:仮説の検証
● 相談があった時、我々がまずやること:仮説から問いを立てる
- 仮説:ユーザーが離脱しているページは○○で、理由は○○ではないか」
- 問い:ユーザーが離脱している場所と原因はなんだろう
- ※問いは仮説より抽象度が高い
● 問いをはっきりさせておくと、アナリティクスやカスタマーサポートなどのデータで応用できる場合がある
- →ユーザーインタビューをする前にある程度離脱しているところを特定しておくなど、定性・定量データを事前に見直し、補完することが大事
最小単位:Step2 インタビュー設計
● 設計は、「問い」ベースで行う
- 質問の内容や仕方にバイアスをかけてしまい、課題の根本を探れないことがあるので設計は注意深く
● バイアスをかけないような質問の仕方を意識する:ECサービスの例
- × 普段「レコメンド機能」は使いますか?
- ◯ 普段どのように商品を探していますか?
- →抽象度を上げて、回答パターンが多くなるような質問をする。機能ベースで話をしない
● 工数・実施時間の目安(うまく行った例):全体で5〜15営業日
- タスク設計(準備とパイロットテスト) →3時間
- リクルーティング(法務・経理チェック含む) →2.5時間〜6時間
- 実査 →4.5〜15時間
- まとめ・書き出し →6〜10時間
- 分析・施策出し →3時間
● 社外の人にインタビューをお願いする場合は、謝礼の設計や法務との調整が発生する
- 予算の扱いは事業部の人たちがどういうふうにやりたいかに応じて考える
最小単位:Step3 実査
● アイスブレイク・ラポール形成の例:
- 相手に応じて、話し相手としてぴったりの相手になりきる
- 時事ネタを用意する
- ポイントは、相手と話題が共通なものを探して、温度を温めていくこと
● 会話が止まったときの発話の促し
- 数秒まつ(相手が考えているのであれば邪魔はしない)
- 話の途中であれば、「何か気になることがございますか?」など伺う
- 話の切れ目であれば、次の質問項目を投げる or 雑談を始める(ただし時間は決めておく)
● 話題を深掘りする方法
- 「なんで?」を5回繰り返す
- →尋問のようにならないように注意!インタビュイーはインタビューに来ているだけでも緊張している。柔らかい質問と、深く掘る質問を織り交ぜ、和ませながら会話するのがポイント
- インタビュイーの情報は事前にインプットしておこう
- →インタビュイーは悪気なくウソを付く場合もある
- 対象となるサービスや人に興味をもつのが一番大事
● ノンバーバル情報から読み取れることは多い
- 反応の速さ、声の大きさ、目や口の開き方、手の動き、目線のやり方、足踏み、姿勢など情報はいっぱい!
- 最初の数分でベースラインを知り、そこからどのくらい反応が違うかで読み取る
- 話していく中でキャリブレーションをする
● 記録のとり方
- Webカメラ
- マイク
- etc.
最小単位:Step4 分析
● 分析手法について
- 大事なのは、ユーザーの発言を鵜呑みにしないこと
- 「ここのボタンは赤がいいです」と言われたら、「なぜ赤がいいのか(アカが好き?目立つから?流行っているから?)」をできるだけインタビュー中に聞く
- ユーザーの心理調査が目的の場合は、上位下位関係分析法などを行う
● 共有方法について
- プロダクトチームに共有するのが結果・施策だけで良い場合
- →ユーザーインタビューのレポート+施策のレポート
- インタビュー結果を現場と一緒に分析したい場合
- →社員限定アカウント、社内でしかアクセスできないチャンネルで共有する
- →その場に参加できなかった人でも情報を参照できるようにすることが重要
● 施策への落とし込み方
- 例えば:カスタマージャーニーマップなどで、ユーザーのペインポイントを洗い出し、そこへの施策を打つ
- →「全方位的に施策を打つ」ムダを省くために、インタビューを行う
プラス1:DMM.comならではのこととは
● DMMでは、インタビューのライブ配信を行っている
- TV会議システムを使って会議室を中継している。これにより、離れた拠点にいて調査に参加できないメンバーでもリアルタイムでインタビュー内容を見てもらえる
- 別室の参加者の質問を受け付ける際には、Google Spreadsheetを使ってリアルタイムで受け取る
- 別室の参加者にインタビューメモをリアルタイムで書いてもらえるし、インタビュアーがインタビューに専念できるなどのメリットがある
● 事業部長の巻き込み方
- 上記のライブ配信の事前に日時を伝えておいて、もし都合が合えば来てくださいという感じで伝えておくと、意外に参加してくれる!
● インタビューの練習
- インタビュー前は社内でひたすら練習!
- そもそもこの質問で良いのかというところから考え直すことも重要
- タスク設計からやり直すこともある
session 3. パネルディスカッション(登壇者3名 + 深津貴之)
●(事前質問)候補者ってどうやって探すの?どう選ぶの?
- (金子)場合によると思いますが、ネットリサーチはやります。弁護士ドットコムだとプライベートな話が多くなるので、人の縁を繋いでリクルーティングしたりとかも。
- (深津)私の場合は、一番最初は隣の人に聞くことが多いです。それで解決しないときは社内の他の人に聞いたり、つぎは客先の人に紹介してもらったり。それでもっと広いところが必要になったら、調査会社さんに依頼したりする。そうやって段階を踏んでいます。
- (金子)そういう話でいくと、ユーザーがいそうな「駅」に行ってゲリラで聞いたりはします笑。
- (伊藤)DMMだと、事前アンケートを実施して、そのクラスタにピンポイントで聞きに行ったりすることがあります。
- (西部)年齢性別などのデモグラ情報でクラスタを切るというよりは、月に5000円課金してる人とかで切るとかやってます。
- (深津)あと、Twitterで雑にリクルーティングすることもある。「ビールおごるからおいで〜」みたいなのとか笑。
- (伊藤)最近だと、boshu.meとかのサービスを使ってもいいかもですね。
●(事前質問)誘導せずに率直な意見を聞くための方法は?
- (深津)たとえば、謝礼を一番最初にあげちゃうとか、サービスの悪口を一緒に行って盛り上がる(サービスよりもユーザー側の人だよというのを伝える)とかもあります。おすすめはしませんが笑、話しやすい雰囲気は作れます。
- (伊藤)私もそれやったことあります。「自分たちが作ったんじゃない」というのをユーザーに伝えたり笑。そうすることで今まで掘り出せなかったインサイトを得ることができたりしますね。
- (伊藤)あとはインタビューが終わった後のお見送りの時にも探りを入れたりもします。他の人はどうでしたか、という質問をぶつけるとか。
●(事前質問)発言に潜むインサイトをどのように汲み取っていますか?チームの中で結果の解釈がバラバラになることも…
- (西部)UXチームの方でファシリテートしながら一緒に結果をまとめていくと、ばらばらになりにくいかなと思っています。
- (金子)私の場合は、一回のインタビューで正しいインサイトが得られると思わないでほしいというのを伝えたりしています。大事なのはプロセスであって、繰り返す中で精度を上げていこうよと。
- (深津)私は分析のときに、「言ったこと」「やったこと」「観察者の解釈」「仮説」の4つが混ざらないようにするのは強く意識していますね。
●(事前質問)インタビュー後にどうやってデータを管理していますか?インタビューで集めたデータを整理して、やることを決めるまでの具体的な工程を知りたい!
- (西部)ユーザーインタビューしたときのメモを共有したり、ダイジェスト(○○のような発言をした人が5人中◯人いました、みたいなもの)を作って共有したりしています。
- (金子)ダイジェストつくったり、レポーティングをするとそれはそれでバイアスがかかるけど、どうやって工夫していますか?
- (西部)言ったこととやったことを分けるとか。目的にそってまとめるとかですかね。
- (深津)THE GUILDの場合は、サーベイ結果は基本的にお客様のものになります。あとはデータ管理含めて調査会社さんに任せちゃうことも多いです。
●(事前質問)インタビューの設計をどのように改善していきましたか?失敗談を教えてください!
- (伊藤)インタビューに不慣れなときは、聞きたい気持ちが強すぎて圧迫してしまったり…というのがよくありました。そうした問題を克服するために、自分がインタビューしたものを見直したり、チームのほかの人がインタビューしたものを見たりして、学んでいきまいした。自分がインタビューを受ける側になるのもオススメです
- (金子)私の失敗談は、長大なインタビュー計画を立ててしまったことかなと。1人にインタビューした瞬間にそれが崩れてしまうので。リーンに小さくやるのが大事。
- (西部)私は、アイスブレイクができずにガッチガチになっちゃってことがあったとか、ずっと違う話に終止してしまうとかがありました。そういうときはすっぱり諦めるというのがいいのかなと思います。
- (深津)私は、noteで、非公式でユーザーに会ったことがあって。全然中立的なインタビューができなかったことがありました。なので飲み会を主催して、ざっくばらんに言える空気を作る、という改善をしたことがあります。
- (こばかな)あれはそういう意図だったんですね笑。
●(事前質問)文化としてユーザーインタビューが根付いていない組織での始め方は?
- (西部)できるだけ、コンパクトにすみますよ、というプレゼンを決裁者にするとか。同じ課題を共有するとかで徐々にやっていくといいと思います。
- (金子)ユーザーインタビューは必要ならやればいいじゃんと思っています。根付いてない組織でもやれない理由はないはず。どちらかと言うと課題は、ユーザー中心の目線が根付いてないことなのかなと。いまいる組織をユーザー中心にする必要がないのであれば、究極的には転職すればいいとも思います。
- (伊藤)腰が重くなっている理由によるかなと。手段を目的化させずに、かしこまらずに(簡単に)やるのでいいと思います。
- (深津)インタビューのタイプによって、導入のハードルが違うと思いますね。例えば、プレフェーズのインサイトをとるためのインタビューは壁が厚い。一方で、プロダクトがすでにあるようなユーザーテストの文脈であれば、最初のインタビューはすごくやりやすいと思います。
- その他、決裁者に他のプロダクトのユーザーテストの様子を見せて危機感を煽るという手もあります笑。
●(事前質問)どうなればインタビューが成功しているといえるのでしょうか?結果の信憑性を客観的に図る方法は…
- (金子)インタビュー単体で成果を図ることは難しいと思います。得られた結果をプロダクトに反映して、それで良い結果が出ればインタビューの成果だと思えるのかなと。
- (伊藤)「アレも聴きたかったこれも聴きたかった」という声がチームからでてきたら、成功かなと思っています。
- (西部)新しい発見があったかどうか、とか、モチベーションが上がるかが重要かなと思います。数値になれば御の字だけど、熱量につながれば成功かなと。
- (金子)そうですね、インタビューの結果、ユーザー目線のカルチャーが根付いていればいいですね。
- (深津)ユーザーに聞こう!という空気感が社内にインストールされればそれで成功ですね。
- (西部)DMMにインタビューの文化が根づいたのは実は最近で、はじめのころは、「ユーザーに聞かなきゃ気持ち悪い!」というのを浸透させるのを目標にしてやっていました。
●(事前質問)BtoB向けのサービスや専門家を対象としたインタビューで気をつけるべき点はありますか?
- (西部)専門家が使っている言葉を勉強しておくのは大事かなと思います。何喋ってるかわからないとメモも深掘りもできないので。
- (金子)社内にいる専門家からインプットするとかは大事です。私の場合は、専門家は近くにいる状況が多かったので、そういう人を巻き込んでいくのが重要ですね。
- (深津)BtoBはちょっと特殊かなと思います。登場人物が多く、「誰がユーザーなんだろう」問題が起きたりします。ユーザーと決裁者が違うとか、登場人物に応じてニーズが全然違ったりするので、その背景を見ないで直接使う人だけを見て改善しても意味はないです。登場人物を整理して、全員の痛みだけを直すのか、ピンポイントで狙うのか、というのは最初に考えないとインタビューは難しいと思います。
- (伊藤)整理する時にはサービスブループリントを使うとかですかね?
- (深津)そうですね。サービスに価値を感じるポイントが人によって違うこともあったりするので、それを洗い出すのが大事です。
●(事前質問)ずばり、報酬はどうしてますか?また、渡すタイミングは?
- (金子)インタビュイーが学生さんだと、アマゾンギフト券をメールで送るとか。それだと集めにくいときは現金とか。ユーザーにとってうれしいかたちで報酬をお渡しています。
- (こばかな)金額や渡すものによって、インタビューにあんまり応えてくれなくなったりとかってあります?
- (金子)金額によって得られるインサイトが違うことはあんまりないと思います。ただ、専門性が高い人の場合はある程度の報酬を出さないと時給換算して来てくれないこともあるとは思いますね。
- (西部)DMMだと、DMMポイントがいい場合、現金がいい場合、とかで場合分けしています。ゲームのユーザーであればポイントがいいという声もあるし。
- (伊藤)悩んだら経理の方に相談するのが一番いいと思います。
- (深津)既存サービスのユーザーを呼ぶ場合は、来てよかったなと思ってもらうためにがんばります。金銭的な報酬だけで経過報告をしたり、食事を良くしたりとか、プラスアルファの価値を提供するとかは重要ですね。
●(事前質問)サービスにおける適切なインタビューの頻度は?
- (西部)問いが出てきたタイミングでやるのがいいかなと。
- (金子)自分たちの仮説精度がどれくらい高いか次第かなと思います。精度が低いうちは頻繁にやったほうがいいし、高くなってきたらあんまりやらなくていいかもとか。
- (伊藤)スクラムチームでMVPができた時とか、テストをしたいタイミングがあると思うのでそこにあわせたり。自分たちのサービスのフェーズに合わせて柔軟にやるのが良いと思います。
- (深津)事業会社のコアプロダクトであれば、月1回くらいのプロセスで回すのがおすすめかなと思う。とはいえそれはあくまで理想なので、リソースと相談になります。
- (伊藤)本来開発に注力すべき時に無理やりインタビューして開発チームが自身をなくしてしまうというような場合もあるので、注意が必要ですよね。
- (深津)そうですね、重要なのはユーザーからインサイトを引き出すことなので、時期によっては、インタビューで濃いインサイトを得ようとするのではなくチャット等の軽いコミュニケーションの頻度を増やす方向にするとかはありですね。
●(会場質問)ユーザーインタビューに応えてくれないような人や、してもすれちがっている人からもインサイトを得たい場合はどうしたらいいでしょうか?(メールで募集しても返信をくれないとか…)
- (金子)そのコミュニティに強い人に聞いたり、縁をたどるといいかもです。
- (伊藤)客観性が必要なのであれば、調査会社さんに依頼しちゃうのは1つの手です。
- (深津)あとは、リサーチの順番を逆にすることで難易度を下げるといのはあります。定量である程度あたりをつけて、定性で引き出したいことが見つかれば、コストを掛けてでもインタビューするとか。
●(会場質問)質問と言うかコメントですが、一回で終わらせず、頑張って二回やるのって大事だよなと思いました。そうすると次に繋がるので。
- (一同)そうですね!
- (深津)ちなみに最初に予算がつなかったときとかは、社外の勉強会とかで「うち予算がないので自腹でやってます」というと、多分次から予算が下りるようになると思います。喧嘩になるかもですが笑
●(会場質問)インタビューの環境づくりにおいて気をつけていることはありますか?
- (西部)インタビュイーの人数が多すぎると意見がひっぱられることもあるので、本質を聴きたいときは1on1にするとかを意識しています。あと気をつけているのは、できるだけ隣の位置に行くとか(女性であれば距離感にも注意する)もしてます。
- (伊藤)環境づくりについては、パーソナルスペースの研究は参考になるかと。対面よりは斜めに座るといいとか。あと同時にインタビューする人数については、事業部の人1名、サポートとしてUX部1人、とかで支援するかたちにしたりしますね。
- (深津)その場がフォーマルに見えるれば見えるほど緊張すると思うので、なるべく緊張をほぐすような環境にすると難易度は下がると思う。カフェでやるとかおすすめです。
- (伊藤)聞く相手がサービスのファンの方であれば、オフィスに招待してもらった!という特別感を感じてもらえるようにしたりという工夫もあります。
- (金子)あと人数に関して、中継で見てるのと実際にインタビューに参加するのは全然温度感が違うので、インタビューの温度感をぜひ知ってほしい!という人は(人数が大きくなってしまったとしても)参加してもらったりはします。
●(会場質問)金子さんの話の中であった、駅でインタビューするときのコツを教えてほしいです。
- (金子)気負わずに声をかけてみると、意外と話してくれます。コツとしては、腕章をつけたりバインダーをもったりしてスタッフ感を演出して、自分を強く持つ笑
- (伊藤)ゲリラインタビューはペアで、できれば女性がいたほうが警戒されにくくなるのでおすすめです。自信なさげな感じで話しかけるとかもいいですね。あとは、沢山の人に聞いてますという雰囲気を出す、テレビ番組のインタビューみたいな雰囲気を演出するとかもいいです。
- (金子)聞く場所で言うと、駅以外にもタバコ部屋はおすすめです。逃げられないので笑。
- (こばかな)花見会場のトイレの列とかもいいですよ。
- (深津)HUBみたいなバーで酒おごりながらやるというのもやりやすいんじゃないかなと思います。そういうゲリラインタビューは自分は苦手なのでやらないけど笑。
参加した所感
インタビューをするときには気をつけなきゃいけないポイントが山ほどあるし、腰が重くなってしまうという感じの質問がわりとあって、すごく分かるなあと思いました。とはいえ金子さんが仰るように、やるしかないというのも真実です。そういう時にこういった勉強会があると背中を押されるので、とてもありがたいなと思いました。
それにしても情報量が多く濃い勉強会だったので、議事メモが1万文字を超えていましたびっくり。とはいえ抜け漏れもあるかと思うので、他の方のレポートやハッシュタグ#theguild_studyで補完していただければ幸いです。
(noteで議事メモを書くのは初でしたが、やっぱりmarkdownが使えないのはつらいなと思いました…)