講師：株式会社はてな 米山弘恭さん
■現場のリサーチ術
▼会社紹介
はてな
▼新市場の開拓
決まっていること
・大まかな時間・目標
・人員配置
決まっていないこと
・決まっていること以外の全部
・（例：事業テーマ、市場、顧客etc）
▼未経験なりの戦略
打席数にこだわる＋対話にこだわる
▼打席数にこだわる
・事業は「せんみつ(1,000件に3件)」
・歴戦の猛者たちでも”せんみつ”なら、我々はもっと低いはず
→ 最初は質より量。打率の低さを打席数で補う
（成功確率よりも試⾏回数を取る）
▼対話にこだわる
・未経験だからこそ先⼈の知恵に頼る（本、⼈、資料）
・ ⼝々に語られる『顧客に会いにいけ』
我々の聖書ことアジャイルソフトウェア開発宣⾔にも
・プロセスやツールよりも個⼈と対話を”, “契約交渉よりも顧客との協調を”
・顧客に会うのもアジャイル..ってこと?
→ 顧客になってくれそうな⽅にとにかく会って対話する
（事業検討~⽴ち上げプロセスの中⼼に顧客候補とのインタビューを据える）
▼対話（インタビュー）中心の事業検討サイクル
▼toittaが誕生
▼今日はこのサイクルの”型”を紹介します。
①仮説の型、②MVPの型、③検証の型、分析の型
▼1/4 仮説の型 リーンキャンバス
まずは「何が分かりたいのか」
・よく⾔われる「リサーチクエスチョンを明確にしましょう」
・⾃明の理をわざわざリサーチする⼈は普通いない、何か分からないことがある
・「分からない何かを分かりにいく」 活動 ≒「仮説（検証|探索）活動」
▼新規事業立ち上げにおけるゴール＝「事業」
顧客の課題解決と対価受領のシステム
▼新規事業⽴ち上げで検証するもの = 「事業案(仮説)」
顧客に対して、対価が得られるような課題解決ができる
仮説の集合体
▼事業案に備わるべき「問い」（仮説）」
・どんな状況にある顧客？
・何をしているときに？
・どんな課題がある？
・今はどう解決している？
・その課題にどのような対策を取る？
・結果としてどのような解決状態を提供する？
・それは他の⼿段よりどう(対価を得られるほど)優れている？
▼だいたいのケースで有効な「問い（仮説）」
・どんな状況にある顧客？
・何をしているときに？
・どんな課題がある？
・今はどう解決している？
・その課題にどのような対策を取る？
・結果としてどのような解決状態を提供する？
・それは他の⼿段よりどう(対価を得られるほど)優れている？
▼なぜなら：ビジネスのゴールはいつも事業の確立
顧客の課題解決と対価受領のシステム
▼…をまとめたのがリーンキャンバス
キャンバスを埋めていくと
リサーチクエスチョン = 課題仮説Xの検証 + 代替⼿段の探索
リーンキャンバスの良さ
①リサーチクエスチョンを浮かび上がらせる
②要素間フィットを素早く検査できる
③作る・変える・捨てる、すべてが高速
■2/4 MVPの型 営業資料型MVP
▼なにか検証したい = MVP作りたい
・MVP（Minimum Viable Product） = 実⽤最⼩限の製品
・動くプロトタイプや、動くかのようなモックを作ることが多そう
▼そのMVP、本当に必要？
MVP（Minimum Viable Product） = 実⽤最⼩限の製品
MVP（Minimum Verifiable Product） = 検証可能な最⼩限の製品
・必ずしもProduct（製品）である必要はない
・モノを作るべきなのは「モノでないと検証できない仮説しか残っていない」とき
▼「要は何が分かりたいのか」「分かるために何が必要か」を問う
①成否どちらかがそこそこ厳密に出る
②結果待ちが生じない
③すぐに作り直せて捨てても苦にならない
▼営業資料型MVPという提案
・前半：ピッチ
‧顧客の状況、課題
‧代替⼿段、その不満
‧ソリューション、提供価値
・後半：オファー
・お願い（仮契約, 試⽤, 稟議)
・対価（費⽤, 課⾦形態）
▼RUNNING LEAN 第3版を参考に
レベーターピッチ
‧顧客の抱える課題
‧ソリューションの⽅向性
‧得られる便益
‧代替⼿段と⽐較した優位性
マフィアオファー
・合意したい事項(仮契約など)
・得たいと考えている対価
・合意した時の優遇措置
▼エレベーターピッチ + マフィアオファー = 営業資料
▼営業資料型MVPのよいところ
①誰でも作れて、作り直しも簡単
②成否が目に見えて分かる
③リーンキャンバスと完全対応
■3/4 検証の型 半構造化インタビュー
▼検証したい→誰かに聞きたい
・顧客への課題解決ができる仮説を検証したい
・⼀番ストレートなのは「その顧客に、課題解決ができるかを聞きに⾏く」
…本当に？？
▼半構造化インタビュー
設問を「半分」構造化するインタビュー形式
・メインの質問は構造的に整理するが、なるべくオープン‧クエスチョンに
・回答に対する追加質問をアドリブで⾏う
▼半構造化インタビューのよいところ
①しゃべりの得意によらず誰もができる
②スクリプトを磨いていける
③結果の比較が容易にできる
■4/4 分析の型 親和図法
▼分析手法としての良さ、だけでない
分析結果の信頼性、確からしさ
＋
分析過程のすごみ
・多段抽象化によるバイアスの低減
・分析過程での理解と発⾒
・メンバーの共通認識醸成
▼親和図法のすごみ
①多段抽象化によるバイアスの低減
・KA法では1つの出来事に対して > ⼼の声 > 価値 と抽象化を⾏う
・さらにそれを⼩グループ> 中グループ > ⼤グループに抽象化していく
・ここまで多段の抽象化を重ねれば、⼀個⼈のバイアスはおのずと薄まる
②分析過程でのすさまじすぎる理解と発⾒
・発話ひとつひとつを読み込み、抽象と具体を⾏き来することになる
・この読み込む過程で否が応でも改めて顧客の発話と向きなおることになる
・「分かった気になっていた」「聞いていたのに脳にしまっていなかった」の連続
・理解と気付き、その結果訪れる強烈なアハ体験をあなたもぜひ
③分析にかかわるメンバーの共通認識醸成
・複数⼈が同時に参加できるワーク的な意味合いがあることにも着⽬したい
・分析にかかわる全員が同じ顧客像を描けることの強⼒さは筆⾆に尽くしがたい
・PdM,Eng,Desの全員が、同じ顧客を憑依させた状態でものを作ったらどうなるか
・ブレない、モメない、迷わない
▼親和図法の(特に過程で)よいところまとめ
①多段抽象化によるバイアスの低減
②すさまじすぎる理解と発見
③メンバーの共通認識醸成
■質疑応答
Q.最初期からエンジニアがチームに入っていたと思いますが、事業案ができるまでのディスカバリーフェーズでのエンジニアの動きはどういったものでしたか？（自分もエンジニアで似たような状況にいるのですが、開発物がない期間のエンジニアの動きとして何が正解なのかわかっておらず、質問しています）
A.エンジニアのみんなも全員インタビューしてました。リーンキャンバスを書いてスクリプトを書いてインタビューをして、結果のKA法だったKJ法での分析をしてってことをやりました。正直、割と他にミッションがなかった既存のサービスのメンテナンスみたいなところは当然あったんですが、もう本当にこれだけフルコミットすることができたので、ここは下手に物を作らずに、一緒にディスカバリー巻き込んでやってみようっていうことをやって、ある種その
チームのエンジニアのみんなには自分の得意な武器を一旦封じた縛りプレイみたいな形でやってもらう必要があったんですがでも、その結果その後のディスカバリーフェーズがある程度一段落した後のプロダクトの開発フェーズでもう手に取るようにたくさんのことがわかるっていう状態ができたので、それによって結果としてそのプロダクト開発自体のスピードだったりとかシュワネスですみたいなところが担保できたと思うんですね。なのでこれがどのケースにおいても正解とは思えないものの、一旦そのエンジニアであるとかプロダクトマネージャーであるみたいな色域のことをさておき、1回みんなでディスカバリーやってみようよみたいなふうにするのは一つ、いいプラクティスだったなと手応えがあるやり方だったなとは思ってます。
Q.製品に関する質問になってしまいますが、親和図法の作成プロセスの一部を自動化することでアハ体験が失われてしまう、みたいなことはないのでしょうか？
A.ありがとうございます僕はないと思って作っておりますとですね、親和図法は前工程後工程があっていくつかつらいポイントと面白いポイントがあるんですが、面白いポイント大体後半戦のところなんですよね揃ったデータを虚心坦懐に眺めながら抽象化を考えていく。やっぱり関係性を見出していくみたいなところの中で、その過程で、具体と抽象行き来して落ち着く瞬間があるみたいなので体験がある。しかしながら、前工程のただただデータを切り出していく集めていく。いうところで、基本の単純作業ですしなんなら一旦コーディングと呼ばれ接点を作っていく作業が終わってそれを抽象化していこうという、一番最初のステップについては本当に
言葉を選ばず言うと、苦しい時間なんですよね。その段階で本当にあまりにもヒントがなさすぎる防爆すぎる砂漠すぎる。状態から接点をまとめたりとか、関係性を見出したりとかしていく必要がある。その作業はスキップした方がきっと幸せになれると思っています。なので回答としては体験を感じていただく後工程の一番美味しいところにいかにスピードを持って到達してもらえるかっていうことを考えて作っているので、ある種いいとこ取りをしていただくことができるんじゃないかなと思ってるのが回答です。
Q.大変参考になるお話ありがとうございます。
なにも決まっていない状態で、リーンキャンバスをどこから埋めていったのでしょうか？また、最初は確度の低い仮説が多いと思いますが、検証する仮説を決める判断軸があれば教えてください。
A.ありがとうございますリーンキャンパスどこから埋めていったかというご質問から回答させていただくと、多くは顧客と課題のセットですので右側から埋めていくみたいなこと言ってますといきなりソリューションを考えると結構プロダクトアウトな考えになってしまうのでまずはこういった方がこんなところに困っていらっしゃるんじゃないかというのを仮説を書くとからスタートしました。
まずはここを埋めて、本当にそのお客さんがいらっしゃるのかとか本当にその課題があるのかっていうのを確かめに行くところをまずは優先したかなと二つ目のこの角度の低い仮説がいっぱいある中でどれを検証するのかっていう決めることを決める判断でこれについても割とその右から左みたいなところが割と通説としてあって、まずはカスタマーとプロブレムがフィットしているかなので、このお客さん本当に現実に存在してこういう行動を本当に取ってるとか、この課題は本当にあって本当にこういう代替手段を取ってるっていうところ、右側のところから進めていくみたいなことをグランドコンセプトしてました。
Q.品質管理の世界ではKA法のことを親和図法と呼んでいると学びました。KJ法とは異なるのでしょうか？それとも目的によってKA法とKJ法を使い分けていらっしゃるのでしょうか？
A.私の解釈、本を読んだり人に聞いたりした解釈の上でのお話なので本当に学術的に正しいかどうかはすいません確証いたしかねるんですが質的分析の手法というものがありその質的なデータを分析する手法を総称として、その下に親和図法なる手法の総称がまず中カテゴリーとしての診察方法ある親和図法にはいくつかの手法があっていわゆる更新は図を書くような手法であれば、あまねく新技であるとしそこであると、その中の一般にKJ法AB型みたいなものだったりとかKA法だったりとかっていうものがあるっていうふうに解釈をしています。はいKJ法と異なるかで言うと異なりますがこのKA法KJ法の使い分けが本当にその体系的に正しいものかってのは僕らもわからないです。
早期サクっと使い分けていて本当にわからないことを探索的に聞いていて周辺情報もたくさん聞いた上で、喋っていないことを明らかにしていくようなインタビューにおいてはKAを使うことが多いです。一方である程度わかりたいことがすごくきっぱり。イエスかノーかで答えられたりとか、ある程度カテゴライズできるようなものについては、KA法もどきといいます。ちょっとライトなKJをKJ法って本当に奥が深かったりとか大変にちゃんと確立されていて、学ぼうと思ったらそれ専門の期間があるレベルのものなので正しいかはさておきちょっとライトな掲示をやってみたいなこともあったりします
Q.インタビューの回数的に、１〜2日に1回やっているペースかと思います。インタビュー対象はどんな方達が多かったのか（企業、一般生活者、etc）、インタビューのアポを大量にとるために工夫した点や利用したツール・サービスなどあれば教えてください。
A.インタビューの対象になった方はですね振り返ると割とやっぱり企業所属のご担当者様みたいな、わりと後半はあのBtoBのプロダクトの事業のアイディアを検証していくことが多かったので企業の方が多かったです。ただ、前半の割と広く事業のアイディアを検証していくフェーズにおいては一般生活者の方が割と割合としては多かったです。
まず回答一つ目ですインタビューのアポイントた取るために工夫した点はツールに頼ることです。ツール等に頼ることですね社内の方に社内のメンバーにこういう方いませんかっていうふうに愚直に呼びかけるであるとかお知り合いにお知り合いをご紹介していただくみたいなところをまずは正攻法として取らせつつ、SNSでGoogle Homeを投下してこういう系のインタビュー答えてくれませんかみたいなことをみんなでやったりとかっていうのをやりつつもそれでも足りないときに、ユニーリサーチですねプロダクトフォースのユニーリサーチを使って、もう本当にユニーリサーチは、おんぶにだっこっていう形でたくさん使わせていただいたんですけど、応募者の募集をかけたら結構たくさんの一般消費者の方も含めてニッチなセグメントの方も集まってくるのでそちらで結構お話を聞かせていただいたことがありました。はい。
Q.デザイナーをしています。スクラムチームで1週間でスプリントを回しており、UX設計の重要さがあまりエンジニアに理解されず微妙なところでスコープが切られ、中途半端なMVPがリリースされることが苦しいです。UX設計の工程にエンジニアを巻き込む良い方法があればご教示いただきたいです。
A.はいそうですね。これすごく私達自身もまだ正解が見つけていないところではあるんですが、
ちょっと良いて手かどうかはさておき、スプリント2週間にしてちょっと中間のところにディスカバリーフェーズみたいなものがあったりとか、ユーザビリティテストをぐっとやる数日間みたいなものを作っていくみたいなものはこれまでちょっと手触りが良かったなっていう手法です。
ただ1週間っていうスプリントだと本当に多分1日で学校へ行かないといけないのでちょっと大変だなとは思いますでもどこか特定の日を1回ディスカバリーとかUXのデザインだけをやるっていう日に決めてしまってみんなで巻き込んでワークでやっていくみたいなことは割と手軽にできる策なんじゃないかなとは思っています。ただそうですね、中途半端にMVPリリースされてしまうこれ非常に苦しいですよねちょっと新規事業のフェーズとは、新規事業のチームとは少し別の昔のチームだったり開発既存の製品開発のチームのときの体験談を言うと、ディアルトラックアジャイル的にデリバリーの工程とディスカバリーの工程をあえて二つに分けて、そのサイクルをリファインメントとかのイベントの中で結合してそれ以外のところは各自個別に回していくみたいなところの方がかえって足並みが揃ったかなみたいなのはあったりします。
はい。ということでちょっと何かアプローチはいくつかあるとは思うんですが我々もちょっと
正確に伝えてないので一緒に頑張っていきましょうっていう感じです。
コメント