00:02
はい、どうも、FREE AGENDAです。
一人で行くスタイルかな?
ということで、今回テーマは?
yamottyのIssue Analysisについてですね。
Issue Analysisとは、これは何ですかね?
なんかこれは、すげえ簡単に言うと、なぜなぜ分析みたいなやつなんだけど、
具体例で言うと、例えばプロダクトとか触ってるとさ、
これこうした方がいいんじゃないみたいな、Howのアイディアって無限に出てくるじゃないですか。
あと事業とか、普通に生活してても、これってこうした方がいいんじゃないみたいな、
Howのレイヤーってアイディアが発散するのはすごい簡単なんですけど、
それが本質的な問題を解決してるかどうかって、
結構順番としては逆で、当たってないことが多いというか、
良い問題、良いIssueを解決する策に当たってないことがすごい多い。
特に業界のこととか、そのプロダクトのことをよく知らない人ほど、
解決されてないものが起きている状態をよく理解するのってすごい難しい。
僕はその状態で試作をしてしまうことを良しとしなくって、
できるなら本当は全てのアイディアに対して優先順位がつく状態が理想であって、
それを目指すためにやっているのがIssue Analysisという行為になります。
具体的に言うと何をしているかというと、本当に簡単です。
一番大きいIssueを一番左側に書いて、スプレッドシートとかも書いてほしいんですけど、
それをさらに分解するとどういうIssueになるかっていうのを書いて、
その次にさらに分解するとどういうIssueになるかっていうのを書いて、
それと対応するタスクみたいなのを紐づけていくっていう回想構造をちゃんと作って、
一番大事なのは戻った時のどの一番でかいIssueと紐づいているのかっていうのを常にチェックするというか、
その上で優先度判断した時に、これは今やるべきじゃないとか、
そもそもやるべきじゃないとかっていう判断、カットしていくための判断にすごく多く使うのがIssue Analysisですね。
これのような説明がしやすいっていうところがある。
これは実際のYamaudiの作ったものを見たい人が多いですね。
確かに。昔のやつだったら出せるかもしれない。
これはあれですね、コンサルティングファームで言うところの、
どこのファームでも言っているか分からないけど、ルート構図分析と同じですね。
そうやって言うんだ。
ルート構図って言い方しますね。起きている現象みたいなのがたくさんあるじゃないですか。
こういう理由でコストが高いとか、こういう理由でシェアが下がっているとか、
03:03
それって起きている現象であって、それが何で起きているかみたいなやつって複雑な組織構成だったりとか、
積極的でない投資の基準とかいろいろあるじゃないですか。
そういうルート構図って呼んでいる一番シーンになっているやつ。
多分一つのシーンが複数の問題を生み出しているということがあるので、近いかもしれない。
かつ結構そういう組織系とか企業全体の一周みたいな話になってくると、
プロダクトよりももっと複雑で、一つの実際起きている問題っていうのが
複数のルート構図から起きていたりとか、
もちろん一つのルート構図が複数の問題を生み出していたりとかするので、
一本生のツリーみたいになるというよりはスパゲティになるんだよね。
間違いない。
そのスパゲティをよく書いた覚えがある。
それやるのって結構カロリーいるじゃないですか。
そうですね。
毎回やるのはすごいカロリーがあるので、
僕はやってるかやってないかが一番大きな差だなって思ったんですよ。
めちゃくちゃ精緻にそのルート構図をメンテナンスするかどうかっていうよりは、
それを一度でもやっておくかどうか、プロジェクトなりプロダクトとか事業とか
何かのタイミングで一回しっかりやっておくと、結構一回地図ができると、
スパゲティの構造だろうと、これどこにリンクしてるなっていうのは創記しやすくなるので、
やることがすごい重要だったかなみたいなのを今思ってますね。
面白い。
ちなみにヤモンティが作ってるやつのIssue3というか、
一番左側、要は一番大元になっているIssueってどれくらいの流度のものなんですか?
ちょっと見よっか。
じゃあ探す時間を15秒与えよう。
ありがとうございます。
その間15秒どうするか。
歌でも歌っておいてください。
Forever Loveでも歌おうか。
お願いします。
今朝6時なんで、その元気ないですね。
だいたい木曜の朝が、クリーアジアの16日で、
6時からなんで、だいたい5時に起きるIssueアナリシスが出てきたんで、
この話はまた後で。
これ何年、いつだろう?2018年とかに作ったやつかな?
これは一言で言うと、僕は見たことがあります。
そうだよね。
今視聴者さんには見えないと思うんですけど、
画面にヒロモッキーが作ったIssueアナリシスがスプレッドシートでガーって書いてあって、
何行くらいあるのか軽く見てもいいですか?
06:01
はい。
イメージをつかむために。
60行くらいありますね。すごいですね。
多いのか少ないのかちょっとわかんない。
これ当時だとTaberiっていうやってたプロダクトの一番大きいイシューが左側。
そこに書いてあるのを今見るとユーザー獲得とか、
こんだて作成の初回体験向上みたいなリュードのIssueが並んでいて、
サブイシューはユーザー獲得のところは月次で7万の獲得みたいなのを書いてますね。
サブイシュー2が例えばですけど、Facebookersの効果可視化とか、
WebへのSEO集客からのアプリ転換、最大化みたいなのが入っていて、
Twitterを起点としたウルサスモデルの回転を実証するみたいな話かな。
これがさらにソリューションが横についていて、
Facebookersのデータを全部クローディングしてビッグデータに流して集計可能にするとか、
あと2番目のやつは別のIssueアナリシスシートにリンクが貼られてますね。
スパゲッティ構造になってますね。
SEO集客からのアプリ転換だからさらに分解が多いので、
すでに配備切らないというか、分化されているってことですね。
そう、プロダクトから見たらちっちゃいIssueだけど、
これを専門でやろうとしたらでかいIssueだから別のところにいってますね。
確かに。一番大きいIssueのブロックは何ブロックくらいあるか見てもいいですか?
ユーザー獲得、初回体験向上、継続利用をしやすくする、
買い物がしやすいリストにする、新モードへのユーザー移行、だから6つ?
結構ファネルっぽい感じの分解の仕方ですね、ほとんど。
僕が好きなのがやっぱりファネルが分かりやすいというか、
上からファネルで落としていくっていう流れになってますね。
いや、面白い。僕もすごいファネルもちろん好きなんですけど、
ファネルって結構分析しろって言われるじゃないですか。
ファネル分析するけど、ファネルごとに改善アイディアをそういう風に
一周のブロックとして管理している人達ってあんまりいないなって
僕の所感としてもあって。
僕はファネルごとに問題点とか数字に現れていると思うので、
ファネルごとに数字の良い悪いが出て、その数字の悪い理由として
これと一緒でサブイシューみたいなやつをいくつか考えて、
サブイシューに対してソリューションとられる施策みたいなのをつくっていう。
全くもってこれと一緒なんだけど、管理の仕方は結構好きなんだけど。
09:03
僕はこれでいうところのサブイシュー数くらいをバーって上げて、
その中で優先順位をつけることをディレクションって呼んでるんだけど。
なるほど。
結構そういう管理ってみんなしてるようでしてないなって思うことが多いですね。
いろんな感じで考えていけって意味ですね。
なるほど、なるほど。
僕ファネルが好きなのはまず分析がしやすいのと
共通言語にしやすいっていうのが一番好きなんですよ。
あとはファネルが明らかにしてくれるのは何かっていうと
問題がある場所じゃないですか。
はい。
その程度もある程度分かるというか、何パーセントって形で
分かるっていう。
だけどその理由ってのはやっぱり絶対に分からないので、
その理由はとにかくそのインサイトを自分で触って
ドックフーディングしたりとか、ユーザーの声集めたりとか、
あとはNYインタビューやったりして、
これで言うとサブイシュー2くらいですかね、
の流度のものを上げていって、そこに対しての解決策は
もう手数だと思ってるんで、
例えば初回体験向上するっていうイシューに対して
サブイシューでオンボーディングっていうのがあって、
サブイシュー2で初回のサジェストの精度と納得感を上げるっていうのが
紐づいてるんですけど、そこに対するソリューションが多分
十何個紐づいてるじゃないですか、これ。
10個くらいありますね。
これ全部試して、その施策がGitHub Issuesと紐づけられてて、
分析した結果もここについてるみたいな。
これすごいクリアな方針だね。
手数を打つって決めてるっていうのはすごい良いことな気がする。
プロダクトは正解は分かんないんだよね。
その割り切りは結構良い気がするんだよね。
これをどれからやるやらで時間を使うパターンも結構あるわけじゃん。
限られたリソースの中ではすごく大事だなと思うんだけど、
多分ヤモンティは手数を打って見ないと分からない。
すごく手が早いエンジニアっていうのを揃えてどんどんやってみる。
チームを作ることで自分のプロダクト作りの仕方に最適化した環境を作ってるんだと思うんだよね。
すごいなんか、利にかなってるというか、
自分のやり方みたいなのをきっちり見つけて、
それに最適化した回し方みたいなのを作ってるっていうところが
さすがだなと思いました。
みんなもそう思うだろ?
うるせーよ。
でもなんかリソースって常に逼迫するんで、このボリューム。
これ確か2ヶ月ぐらいで全部やり切ったんですけど、
ここプライオリティって試作単位でやっぱりつけるんですよ。
1,2,3,4って。
当然1からやったりするんですけど、
12:00
1,2,3,4って。
当然1からやっていくんですよ。
で、うちの場合は面白いのは、その1,2,3,4完備するときに、
僕は絶対かかるコストを考えないっていう。
重要なものからやるべき。
その効果が高いと見込まれるものからやるべきっていう。
それはすごいチーム内のコンセンサスが強いんですよね。
僕だけじゃなくて、エンジニア側からの要望というか、
チームからの要求も強い。
だから下手なことをやってくれるなよっていう。
なるほどね。
だからそこはめちゃくちゃ真剣勝負というか、
シビアなジャッジをしていってますね。
これの効果が高いかどうかみたいのは、
どういうふうに判定してるんですか?
やっぱり試作なんで、試作って最後ここに効いたかなんですよね。
ファネル伸びたかで一番見るんですけど、
絶対これやるときはスプリットテストでやってました。
手を打つ前っていう意味ですね。
実装する前に、
効果が高いか。
効果を見込めるからですね。
それはね、自分が体験したときに最もペインだと思うかどうかとか、
ユーザーボースから上がってきた中で、
こういうペインが強いんだなっていう、
数値になるものではなくて、定性的な評価をしてます。
はいはいはい。
例えば僕らはじめタベリー触ってて、
全然自分が欲しいもの出てこねえなみたいな。
うん。
これひっくそだなっていうので、
アルゴリズムもそうだし、
アルゴリズムに反映するための、
スロースタートじゃなくて、
コールドスタートが、
コールドスタート問題を解決するっていうところが、
優先度が多分ギュッと高くなるっていう。
そこはかなり定性ジャッジですね。
体験に対して効くかどうかっていう。
はいはいはい。
なんかそこが結構組織が大きくなったりとか、
長く運営してるアプリだったりすると、
結構定性だけだと判断が難しくなるというか、
意識的にかかる人数が多くなるほど、
それって結構難しくなるかなって感じてて。
確かに。
だからデータ分析とかで施策の優先順位って、
求められるんですけど、
結構僕もそれに関する分析、
結構これに僕も近いことをやってるんですよね。
うんうん。やってるよね。
別に周囲のプロダクトマネージャーが、
こういう分解とかをして優先順位をつけるってことを
してなかったとしても、
自分で勝手にこういうイシュツリーみたいな形にして、
施策も考えるし、周りからもらった施策とかも
自分でこうやってマッピングして、
こういう全体像です。
どれからやりますかみたいな話になるじゃないですか。
ファネルとしてはこういう数値ですっていうと、
施策ごとに、
どの施策が効果高いか分析してみたいになるんですけど、
あれするんですよ。
そんなに分かんないと思うんだよね、やっぱり。
うん。
せいぜいそのポイントに人が通過してるかどうかとかって、
そのボリューム感とか、
そういうのがあって、
機能を使ってるかどうかとかって分析するけど、
やっぱりそこまでパッキリは分かんなくて、
僕は割ともう本当に、
プロダクトに一番詳しいと思っている人の裸感とかで
決めてもいいんじゃないかと思うんだけど、
15:00
ああ、そうっすね。
ただその、
タベリーとかって多分ヤモティは
意識的にやってると思うけど、
かなりターゲットが絞られている
タイプのサービスじゃないですか。
タベリーとかって、
多分ヤモティは意識的にやってると思うけど、
かなりそのターゲットが絞られている
タイプのサービスじゃないですか。
うんうん。
その、やっぱり使ってるユーザーが
すごいマスというか、
すごくいろんなタイプの人がいる
サービスになるほど、
やっぱりその感覚的な意見だけだと
分かんないことって増えてくるんだよね。
確かにね。
だからその、
例えばメルカリとかってすごく
使ってる人数が多くて、
男性も女性もいて年齢層も幅広くて、
例えば収入が高い人も低い人もいるから、
何が刺さるかっていうのって、
定性的に判断してもやっぱりなかなか
分からない。
逆に1個の施策が、
Aの群は好きだけど、
Bの群は好きじゃなくて、
そのオフセットで偽造みたいな感じになってるんじゃないかな
と思うんだけど、
そういうのは結構増えてくるから、
どんどん判断難しくなってくるんだよね。
確かに。
僕もそのどっちかっていうと、
実際は手数で処理するっていうのに
結構賛成なタイプなんだよね。
うんうんうん。
でも今の整理すごいいいなと思って、
マスに近いほど、
基本的にシンデレラにしていかなきゃいけないじゃないですか。
はいはい。
誰が使っても同じように効果が出るとか、
誰が使っても、
機能の優先度にそこまで差がない状態を保つ必要があるというか、
そうすると、
例えばメルカリで、
分かんない、これは適当に言いますけど、
売り上げの実は6割ぐらいは、
めちゃくちゃ高収入で単価が高い人たちからもたらされてる。
けどそういう人たちって、
ユーザー数としては、
10%ぐらいしか実はいないみたいな。
あるあるの構造じゃないですか。
今その話をしたら。
90%の人は楽しく使ってるんだけど、
この人たちからもたらされる売り上げっていうのは、
そんなに大きくないっていう。
そういう時に、
このアッパーの人たちだけを優遇するみたいなのが、
果たしていいかっていうと、
1000万DAU、
MAUだっけ、
そういう規模があるアプリで、
そんなことできるわけがなくって。
そうですね。
それは本当にそう思うかな。
本当に、
結構そこはいつも意見が分かれるところだと思うんだよね。
基本的に、
いわゆる売り上げみたいな物色に追おうとすると、
特に単価、
ロイヤルユーザーに集中する方が早いって話になるんだけど、
それってすごくマニアックな機能だったりとか、
結構ファネルのトリッキーなところみたいなやつ。
奥の方ですよね。
奥の方って言ってるのは、
初回のコンバージョンとかじゃなくて、
20個目から21個目の転換とか、
話が早いわけじゃないですか。
そういうところって結構使うユーザー少ない。
18:00
本当に使い込んでる人だけが、
開ける扉、
ゲームの裏技みたいなところ。
でも大体の人は最初のゲームの名前を、
主人公に名前を付けるところで押し取るやんぞっていう状況もあるわけですよね。
人数的に言うと。
バランスが止まらないと長期的には栄えなくて、
サービスって。
それはすごい難しいなとは思うんですよね。
そうですね。
ただちょっと前に、
自分がサービスの分析とか、
改善から得た学びみたいなやつを、
抽象化したドキュメントみたいなのを作ってて、
それは全ては話せるわけではないんだけど、
前にすごく思ったのが、
一番大事なのは、
大通りって呼んでるんですけど、
人が一番たくさん使っているところの施策みたいなのが、
何より王様だなというふうに思ってて。
間違いない。
大通りって、
使う人が少ないような奥の奥の機能みたいなやつを、
めちゃくちゃ良くしたとしても、
そんなに数字とかに跳ね返ってくることってないんですよね。
うん。
例えば、
この話ってメルカリの話で言うと、
すでにこれって、
山田慎太郎さんとかも記事で喋ってたんで、
全然話しても大丈夫な話なんですけど、
昔、
写真が並んでるサービスじゃないですか、
メルカリって。
あれって2列だったんですよね、写真が。
ああ、そうだね。
あれ3列にしたじゃないですか。
あれってすごいシンプルな改善なんだよね。
もちろんUI上のデザインの複雑さはあるんだけど、
やってること自体はシンプル。
1回で見れる写真の量を増やすっていう。
別にできることが増えたわけじゃない。
複雑な機能がついたわけじゃない。
でもあれはものすごいやっぱりメルカリでは効果があった試作の1個で、
なんでやっぱりあれがすごい効いたのかなっていう風に
結構考えたんですよね、前。
他にもいろんな試作いっぱい打ったことあるんだよね。
ものすごい難しいけど、
使いこなせたらめちゃくちゃいい機能とかつけたことももちろんあったし。
やっぱりいかに全員が必ず通る大通りにある試作かっていうのが
ほぼでかいなっていう風に思って。
間違いない。
結局メルカリを触るときに商品を探すっていう風なことって
基本的にはもうせざるを得ないんだよね。
いわゆる写真が並んでるところっていうのを使わない人はいなくて、
そういうところに試作を結構仕掛けるのがやっぱりでかいかなと思ってて。
検索のフィルターですごくマニアックな
フィルターの機能とかを実装するとかって
あんま人が使ってないから意味がないかなと思ってて。
逆にああいう一番大通りのところで
21:00
単位時間あたりに処理できる商品の検討数を増やすとか
単純にも本当に写真を読み込むっていうのが
一番大通りのところだと思ってて。
商品の検討数を増やすとか
単純にも本当に写真を読み込む
タイムラインから商品の詳細画面に飛ぶスピードを速くして
戻るスピードも速くするとかっていう風な
当たり前だけど全員がルーティンとしてやってることっていうのを
すごく高速化するとか楽にするっていうのが
一番効くんじゃないかなっていうのが
結構いくつか得た学びの中では大きい方の学び。
でもそれすごい重要だし
あれも実はそんなに分かってる人多くないというか
そうなんだ
ところだと思います。例えばですけど
僕は検索ってあらゆるサービスの中の
センターピンだと思ってるんですけどほとんどの場合
検索もしくは今だと推薦アルゴリズムっていう
これって多分インターフェース上の工夫ってもうないんですよほとんど
なるほど
メルカリがやってる写真検索とか
ああいう発明はちょいちょいあると思うけど
あれも多分使ってる人ってそんな多くないはずで
うん
基本的にはテキストを入れて
その時にユーザーさんが想起したキーワードの商品とかコンテンツを
できるだけ早く返してあげるっていうのが検索で
これなんか無限の戦いで
Googleはずっとそれをこすってるわけじゃないですか
こすって
これってユーザーからすると
別に今日も明日も使ってるのは
ただの窓なんですよね検索の
UI上の大きい変化とかは別にいらないし
求められてもないんだけど
後ろ側でやるアルゴリズムの精度を上げていくとか
そのキーワードを入れた時に
ユーザーが期待してたことを推測するっていう作業って
無限の戦いがあって
僕はそういうものこそ王道だなっていうプロダクトの中では
あとは初めに開いた時に絶対みんなが通る画面とか
一番のコアアクションを完結させるために必ず通る場所
これがなんかプロダクトのリソースの95%を割くべき場所で
95%って言ってましたか
そう
さっき絞ったプロダクトと
ジェネラルなプロダクトとみたいな訳があったけど
食べりでも結局そうなんですよね
枝葉の5%になりそうなものは全部削っていくというか
石はない質も基本的には95%に当たってるものに
限定されているはず
その中で例えば機能を追加するとか
画期的なことをやる時の
例外が一個だけあって
それはプロダクトの中では完結してないんだけど
プロダクトの外で完結している大きな仕事とか
ジョブをプロダクトの中に取り込んでくる時
例えばこんな手を決めるだけじゃなくて
買い物を終わらせるみたいな
その時は僕は例外発動
それはプロダクトを大きく変えるみたいなタイミングかな
24:03
アプリを使っている時に
そのアプリに付随して
オフラインで起こっていることが絡む時って
すごい難しさがあるなと思っているんだよね
メルカリとかはほぼオンラインで済むものかなと思うんだけど
基本的にメルカリも含め
いろんなサービスって
いわゆるオケージョンって呼ばれるものが重要かなと思って
オケージョンって日本語で訳すと何て言うか分からないけど
メルカリって使うの最初は結構面倒くさいと思うんだよね
写真撮って値段決めてとか
でもあるタイミングで物を処分してもいいなとか
処分したいっていうタイミングが
ライフスタイルの中で生まれる瞬間がありますと
引っ込んだりとか出産だったりとか
たまたま高いものをもらったけど自分は使わないだったりとか
もしくはメルカリで買ったけど自分にサイズが合わなくて
もう一回転売とか売っちゃおうかなって思うとか
オフラインで起こっているトリガーとなるオケージョンみたいなやつが
メルカリにはもちろんあるし
サービスによってオケージョンとかユースケースみたいなものが
オフラインにおけるのがすごい重要になると思うんだよね
スポーツファイだってどこで聴くのかによって
結構話は変わってくると思うんだよね
風呂の中で結構永遠に聴くのか寝る前に聴くのか
ジョギングしながら聴くのかとか
結構そういうのがあるから
スポーツファイとかグーグルミュージックとかは
こういうシーンで聴ける音楽リストとかっていうのを
結構用意するわけで
オフラインの中でいかにその人の生活とかに
溶け込むような感じにするかっていうことを
すごく考えてると思うんだよね
でも実際にスポーツファイのデータ分析のログをいくら触ってても
オフロードの中で聴いてるかとか
ドライブ中に聴いてるかとかっていうのは
全然分かんないわけであって
絶対分かんないもんね
あれはもちろん自分たちが使ったりとか
ユーザーに聴いた上での回答じゃないと思うんだけど
結構そういうのって
意外にしなければ分かんないから
いい話やなって思ってるっていう
そうですね、なんか生活者の観察っていう
ことをよく言うんすけど
僕らはその人が実際に持ってるイシューと
僕らが頭で叩き出したイシューって
絶対乖離があるみたいな前提があって
やっぱそこ埋めるのは観察しかないと思ってるんですよね
それはすごいなと思うよ
とことん人に向き合うみたいなのは
人が持ってることに向き合うかな
人に向き合っちゃうと
情緒とかが入り込んじゃうんで
そういう意識でやってますかね
27:05
結構話長くなってきたか、まあいいや
いつも思うのが
多分データ分析ってすごい
そういう意味でインサイトしてやっぱ浅いなと思ってるんだよね
いわゆるデプスインタビューとか
ユーザビリティテストみたいな
実際のユーザーの行動っていうのは
すごく深いというか
実際正しい行動だし
それが反映してると思うんだけど
そういうのって
複数人で意思決定するときに使うの
すっごい難しいなって感じて
なるほど
僕前はメルカリで
US事業の時の分析とか戦略やってたときに
ちょくちょくアメリカの方に行って
現地のユーザーに使ってもらった感想とか聞いてたんですよね
やってたね
今思うとあれはそんなに質のいいインタビューはできてたわけじゃないんだけど
それでもやっぱり触ってもらって得たインパクトがすごくでかくて
インタビューに行ったチームの中では
もうこれが一周だよね
間違いないよねみたいな感じの
感覚が出てくるんだよね
それをレポートとかにして
共有した瞬間に
周りの人って全く理解してくれないんだよね
分かる
だから深いんだけど狭いんだよね
すごく射程範囲が狭い
自分の徒歩
周囲1mにしか伝わらないインプレッションなんだよね
ユーザーインタビューに
データ分析は浅いんだけど
ぶっちゃけレポートにすれば
読んだだけの人でも何か伝わる可能性はあるっていうのがあって
会社が大きくなっていくほど
データしか見られなくなっていって
N1の声とかって
そんなに届きづらくなるっていうのは
構造的にあるなって思ってるんですよね
ただ同時に
そうなはずなのに
例えば一部の経営者とかって
俺の友達が言ったんだけどさ
分かる分かる
この機能クソだって言ってるんだけど
直してくんなみたいな
あるわけじゃないですか
N1警察出てきたり
見知らぬN1は
話は信用しないんですよね
プロのインタビュアーが起こした
不安のインタビューをしないのに
自分の周りのN1を信じるとか
不合理なこともあるなと思うけど
ベースとしては
定性とかインタビューみたいな情報っていうのは
やった本人にはすごく深く伝わるけど
周囲に伝播するのが
ものすごく難しい技術だなと思う
人間の認知がバグってるからですよね
それは
僕も
結論で言うと
意思決定者がN1を信じて
意思決定者がN1の重要性を知ってるかとか
使い方に慣れてるかってところに
ものすごい修練していくなと思ってて
最近僕いいなと思ったのが
ずっと自分でN1やってたんだけど
N1を他の人にやってもらうっていう
30:00
体制に変わったら
上がってくるレポートを見て
僕はインサイトを受けるんだけど
その時にN1をやった人って
N1をやった時に受けた感情とかも
ちょっと入ったりするの
そういう質問していくと
それが削ぎ落とされて
この人が本当にN1インタビューを通じて
得た向き合ったユーザーさんの
イシューって何かってのが
一回クッション挟むと
すごい綺麗に出てきたりするんだよね
へー
だから
自分がめちゃくちゃ長けてるとか
言うわけではないですけど
僕は少なくともN1インタビューっていうか
N1の生活からインサイトを見つけるってことに
すごい重きを置いている
人間だとして
そういう人が
うまく他の人のN1を吸い上げる力があると
分析も含めて
うまく使えるんじゃないかなっていうのが
最近思ったことですね
うんうん
だからヤモキはそういう
さっき話したら
やっぱり小さい組織で
そんなに合意を得ずに
意思決定をできるような体制に
向いてると思うんだよね
うんうん
逆にヤモキが自分で
N1インタビューしたものを
より上位者に伝えて
全く想像がつかないし
うまくいかなかったなそれ
逆に僕はデータ分析とかを使って
そういうのがすごくうまい方だと思うんだよね
うんうん
広く合意を作ることが
結構できるタイプかなと思ってるんだけど
うんうん
でもなんか
ごめんなさい
僕はでももう少し
ヤモキ側の仕事の仕方も
やりたいなと思ってるんだよね
ああそうなんだ
最近別にデータ分析がしたいって気持ちも
全然なくて
そのいい意思決定とか
いいディレクションみたいのを
作るっていうことに
最近はすごく重きを置いているので
データ分析はその中の
一つの手段ではあるし
特に多くの人数とかで
合意をしたかったりとか
後々までちゃんと
納得感のあるエビデンスを残すって意味での
データ分析がすごい役立つけど
データ分析を使って
良い意思決定ができることは
そんなに多くないっていう風に感じていて
いやーパンチラインじゃないですかそれ
うん
そうなんですよね
だから結構思うのが
良い意思決定って何かって話なんですよ
一つ
データ分析を使う
良い意思決定っていくつかあると思うんですけど
僕の中では大きく3つは
かなと思ってて
正しいこと
早いこと
納得感のあること
だと思ってるんですよ
データ分析は
早く意思決定するには
役に立つことがある
みんなが
俺の友達が言うにはって
ごちゃごちゃ言ってる間に
データ分析バシッと出して
お前らの言ったの聞いてないと
33:01
これがユーザーの声だって言って
沈めることができるんで
早く決まることがある
納得感を作ることも結構できると思う
それに
作法の人は役に立ってないと思ってる
だけど
多くの人はデータ分析は
正しい意思決定に
一番インパクトするツールだと思ってる
そこに非常に乖離があるかなと思っていて
ただその3つの意思決定の
柱が重要だとしたら
正しいっていう部分を
データ分析と
それ以外の力で補強して
プラスデータ分析を使えれば
この3つ全て満たせるので
非常に良い意思決定ができるかなと思っていて
その意思を埋めにいきたいっていうのが
今かもしれない
なるほどね
なるほどね
なんかそのN1みたいなものに
晒されてると
ウィルが生まれてくるみたいなところがあるから
こういう人
そのなんか私が解決したかったのは
こういう人のこの問題だっていうのに
気づかされるんですよね
あー
なんかそれが結局ウィルになって
なんかプロダクトのあるべき姿を
アップデートすることに
なんか僕は結構何回も経験してるから
その
正しさが変わっていくみたいなのがあると思うんですよね
うんうん
意思決定のさっきのフレームの中で言うと
でも企業ってそれし続けないと
基本的には永続的に
そのなんだ
革新的なことって絶対できないはずなので
やっぱなんか
そうですねその正しさと向き合うための
人と向き合うみたいなのが
なんだかんだ僕は優先順位地かなみたいな気がします
納得感とか本当はクソくらいだろうみたいな
昔は思ってたタイプだから
でも組織が小さければ結構必要ない
タスクかなと思ってるんで
うん
結構僕が得意なデータ分析って
それなりのなんだろう
サイズの組織でしか
意味ないスキルだなって
すごい感じてるんだよね
うーん
うん
多分小っちゃい組織に僕がいるんだったら
多分あの分析の力は
早い意思決定にふさわしい
振ると思うんだよね
はいはいはい
でもその訳ができてるのが
すごいいいなって思うと
納得感クソだろって思ってるとは言いつつ
僕結構納得感にコストは割いてるはずで
それはドキュメントを作るとかね
データ分析するとかは
全てそのためにやってるところがあるので
うん
なんだろうね
まあやっぱバランスなのかな
でもその中でも一番正しいのは
重要なのは正しさをどう作っていくかみたいな
それはすごい思う
でもやっぱ自分は結構
早さと納得感のところの
データ分析の有用性を
ものすごく理解してしまったので
結構たまにね
正しさはそこそこどうでもいいって
思ってる時もあるんだよね
あ、そうなんだ
うん、思ってる時はある
うーん
それは多分大きい組織だと
そもそも動くのが遅くて
36:01
その遅さがすごく無駄で
早く動けばもっと
いろんなことができるって
グッドとか動き方に
インパクトするかなって思ってるし
僕なんかあんまりその
ぎくちゃくした組織みたいなのは
自分自身が得意じゃないっていうのが勝手になって
そこを結構重んじてるんだけど
でもやっぱ最近
もう少しちっちゃい会社とか
サービスとかと仕事することが増えてきて
やっぱ正しくなきゃ意味ない
っていうのがめちゃくちゃあるから
だからその意思決定の中で
重視するものっていうのを
もちろん正しさはもともとないがしろにはしてないけど
もっと変えていかなきゃなと思ってると
データ分析とか
結構どうでもいいかなって
なるほどね
あとあれかも
正しさへの責務を感じるのって
やっぱ現場と対峙してる人ほど
強いかもしれない
例えば開発のリソースを預かってる人とか
そうかもしれない
彼らを無駄にすることはできないみたいな
もしかしたら立場とか
レイヤーの違いであるかもしれない
うん
それは本当にそうかもしれない
だいぶ長くなったねこれ
めっちゃ面白いけどね
ちょっと一旦このもんで切りますか
そうだね
インタビューとかユーザーの声に向き合うっていうのは
僕はこれからまだまだ
学んでいきたいなと思ってるんで
最近はあれですね
フリーアジェンダを取り終わった後に
ヤモティといろいろ
サービスについて話したりとかして
確かにね
試験を交換したりする回っていうのがあるっていうのは
楽しみにしてるけど
どうかな
そうしましょう
じゃあそういうことで
一周案内システム
面白い回だと思います
気に入っていただいた方は
チャンネル登録お願いします
それでは
バイバイ
