【テキスト版】#63 Issue Analysisについて-タベリー初期の資料も大公開（前編）

2020/05/16に公開したPodcastを書き起こした文章です。後編はこちら。

本質的な問題解決を目指すIssue Analysis

Yamotty：はい、どうもー。フリーアジェンダです。ということで、今回のテーマは？
Hikaru：Yamottyが提案したお題、Issue Analysisについてです。Issue Analysisとはこれ何ですか？
Yamotty：これは、すごい簡単にいうとなぜなぜ分析みたいなやつです。例えばプロダクトとか触ってるとさ、これこうした方が良いんじゃないみたいなHowのアイデアって無限に出てくるじゃないですか。事業とか、普通に生活してても、これこうした方が良いんじゃないみたいな、Howのレイヤーってアイデアが発散するのはすごい簡単なんですけど、それが本質的な問題を解決してるかって順番としては逆で、当たってないことが多いというか、良い問題に、良いIssueを解決する策に当たってないことが多いと思ってます。
Hikaru：うんうん。
Yamotty：特に業界のこととかそのプロダクトのことをよく知らない人ほど、解決されていないものが起きている状況をよく理解することがすごく難しい。僕はその状態で施策をしてしまうことを良しとしなくて、できるなら、本当に全てのアイデアについて優先順位がつく状態が理想であって、でそれを目指すためにやってるのが、Issue Analysisっていう行為になります。
具体的に何してるかっていうと、本当に簡単。一番大きいIssueをスプレッドシートの一番左側に書いて、それをさらに分解するとどういうIssueになるかっていうのを書いて、でその次に分解するとどういうIssueになるかを書いて、それと対応するタスクみたいなのを紐づけていくっていう、階層構造をちゃんと作ります。
で、一番大事なのは戻った時、どの一番でかいIssueと紐づいてるのかっていうのを常にチェックする。その上で、優先度判断した時に、これは今やるべきじゃないとかそもそもやるべきじゃないとかっていう判断、カットしていくための判断にすごく多く使うのが、Issue Analysisですね。これの良いのは説明がしやすいっていうところかな。

実際のシートを見ながら構造を解説

Hikaru：これは実際のYamottyの作ったものをみたい人が多そうですね。
Yamotty：確かに。昔のやつだったら出せるかもしれない。
Hikaru：これはあれですね、コンサルティングファームで言うところの、 Root cause分析と一緒ですね。
Yamotty：ああそうやって言うんだ。

根本原因分析の定義、例、手法

Hikaru：起きている現象みたいなのはたくさんあるじゃないですか。こういう理由でコストが高いとかこういう理由でシェアが下がってるとか。それって起きている現象であって、それがなんで起きてるかって複雑な組織構成だったり積極的でない投資の基準とかいろいろあるわけじゃないですか。 Root causeって呼んでる、一番主因的になってるやつ。そのひとつの主因が、複数のIssueを生み出す、Issueというか問題を生み出していることはまあ近いかもしれない。かつ組織型とか企業全体のIssueみたいな話になってくると、プロダクトよりももっと複雑で、ひとつの問題っていうのが、複数のRoot causeから起きてたりとか、もちろんひとつの Root causeが複数の問題を生み出してたりとかするので、一本戦のツリーみたいになるっていうよりは、スパゲティになるんだよね。
Yamotty：ああ、間違いない。
Hikaru：そのスパゲティをよく書いた覚えがある。
Yamotty：でもなんかそれやるのって結構カロリーいるじゃないですか。
Hikaru：そうですね。
Yamotty：毎回やるのはすごいカロリーがあるので、僕はなんか、やってるかやってないかが一番大きな差だなって思ったんですよ。その、めちゃくちゃ精緻にRoot causeをメンテナンスするかっていうよりは、それをやっておくかどうか。プロジェクトなりプロダクトとか事業とか、なんかのタイミングで、一回しっかりやって地図ができると、なんかスパゲッティの構造だろうとこれどこにリンクしてるなっていうのは割と想起しやすくなるので、やることがすごい重要だったかなみたいなのを、今は思ってますね。

Hikaru：面白い。ちなみにYamottyが作ってるやつのIssue Analysisだと、一番左側、要は一番大元の大元になってるIssueってどのぐらいの粒度なんですか？
Yamotty：え、ちょっとみようか。これは、いつだろう、2018年とかに作ったやつかな。
Hikaru：これは、僕はみたことがありますね。
Yamotty：そうだよね。
Hikaru：Yamottyが作ったIssue Analysis、何行くらいあるのか軽くみても良いですか？
Yamotty：はい。
Hikaru：えーっと、60行くらいありますね、すごいですね。

Yamotty：これ、多いのか少ないのかはちょっとわからない。これ当時タベリーっていうプロダクトの、一番大きいIssueが左側で、そこに書いてあるのを今見ると、「ユーザー獲得」とか「献立作成の初回体験向上」みたいな粒度のIssueが並んでいて、Sub-Issueはユーザー獲得のところは月次で7万の獲得、みたいなのを書いてますね。Sub-Issue2が、例えばですけど、「Facebook Adsの効果可視化」「WebへのSEO集客からアプリ転換最大化」みたいなのが入ってて、Twitterを起点としたULSSASモデルの回転を実証するみたいな話。
Hikaru：うんうん。

Yamotty：これがさらにSolutionが横についてて、「facebook Adsデータを全部クローリングしてBigQueryに流して集計可能にする」とか、2番目のやつは別のIssue Analysisシートにリンクが貼られてますね。なんかスパゲッティ構造になってますね。
Hikaru：SEO集客からアプリ転換だからさらに分解が多いので、ひとシートには入りきらないというか、分割されてるということですね。
Yamotty：プロダクトから見たら小さいIssueだけどこれを専門にやろうとしたらでかいIssueだから、たぶん別のところに行ってますね。
Hikaru：確かに。一番大きいIssueのブロックは何ブロックくらいあるか見ても良いですか。
Yamotty：はい。「ユーザー獲得」「初回体験向上」「継続利用をしやすくする」「買い物がしやすいリストにする」「新モードへのユーザー移行」だから5つか。
Hikaru：けっこうファネルっぽい感じの分解の仕方ですね。
Yamotty：そうですね。僕が好きなのはファネルがわかりやすいというか、上からファネルで落としていくっていう流れになってますね。
Hikaru：面白い。僕もすごいファネル好きなんですけど、ファネルって分析しろって言われるじゃないですか。ファネル分析するけどファネルごとに改善アイデアをIssueのブロックとして管理してる人っていないなって僕の所感としてもあって、僕はファネルごとに問題点とか数字にあらわれてると思うので、ファネルごとに数字の良い悪いは出て、その数字の悪い理由として、これと一緒だよねSub-Issueをいくつか考えて、そのSub-Issueに対して、Solutionとなる施策みたいなのを作るっていう、全くもってこれと一緒なんだけど、管理の仕方は好きなんだけど。僕はこれでいうところのSub-Issue2をバーって挙げて、その中で優先順位をつけることをディレクションって呼んでるんだけど。結構そういう管理ってみんなしてるようでしてないなって思うことは多いですね。

Yamotty：なるほど。なんか僕ファネルが好きなのは分析しやすいのと、共通言語にしやすいっていうのが一番好きなんですよ。であとは、ファネルが明らかにしてくれるのは何かっていうと、問題がある場所じゃないですか？　まあその程度もある程度わかるというか。何%という形で常に程度がわかるっていう。だけど、その理由っていうのは絶対にわからないので、その理由はとにかくそのインサイトを自分で触ってドックフーディングしたりとか、ユーザーの声集めたりとか、あとはN1インタビューやったりして、これでいうと、Sub-Issue2くらいの粒度のものを挙げていって、そこに対しての解決策は手数だと思ってるので。例えばね、初回体験向上するっていうタスクに対してSub-Issue1でOn-boardingっていうのがあって、Sub-Issue2で初回サジェストの精度と納得感をあげるってのがあって、そこに対するSolutionが十何個紐づいてるじゃないですか。
Hikaru：十個くらいありますね。
Yamotty：これ全部試して、その施策が全部GitHub Issuesと紐づけられてて、分析した結果もここに付いてるみたいな。
Hikaru：これすごいクリアな方針だね。手数をうつって決めてるのがすごい良い気がする。
Yamotty：まあね、プロダクトは正解わからないのでね。

優先順位の決め方

Hikaru：その割り切りは結構良い気がするんだよね。どれからやるで結構時間使うパターンもあるわけじゃん。それって限られたリソースの中では大事だなって思うんだけど、たぶんYamottyは手数を打ってみないとわかんないって思ってるから、すごく手がはやいエンジニアを揃えて、どんどんやってみる。チームを作ることで、自分のプロダクト作りの仕方に最適化した環境を作ってるんだと思うんだよね。すごいなんか、理にかなっているというか、自分のやり方みたいなのをきっちり見つけて、それに最適化した回し方みたいなのを作ってるところが流石だなと思いました。みんなもそう思うだろ？
Yamotty：うるせえよ（笑）でもなんか、リソースって常に逼迫するんで、このボリューム。これ確かね、２ヶ月くらいで全部やり切ったんですけど。ここPriorityって、施策単位でつけるんですよ、1、2、3、4、って。で当然1からやっていくんですよ。でうちの場合面白いのは、1、2、3、4を加味する時に僕は絶対かかるコストを考えない、重要なものからやるべき。効果が高いと見込まれるものからやるべきっていう。それは、すごいチーム内のコンセンサスが強いんですよね。僕だけじゃなくって、エンジニアからの要望ってか、チームからの要求も強い。下手なことをやってくれるなよっていう。だからそこはめちゃくちゃ真剣勝負というか、シビアなジャッジをして言ってますね。

つづく。後編はこちら。