dely CTO大竹氏が教えるアイデア検証プロセス　“認知バイアス”を回避してプロダクトを改善する方法

クラシルのグロース戦略

新田慶秋氏（以下、新田）：みなさん、こんばんは。delyの新田と申します。

今日はdelyのエンジニア陣が5名登壇をして、レシピ動画サービス「クラシル」に関するグロース戦略やエンジニアリング方針、あとはユーザー調査手法に関してお話ししたいと思います。

まずトップバッター、CTOの大竹からお話をさせてもらえればと思います。みなさん拍手でお迎えください。

（会場拍手）

大竹雅登氏（以下、大竹）：こんにちは。大竹と申します。まず自己紹介です。あらためまして、大竹雅登と申します。今、delyでCTOをやらせていただいています。

もともと海外で開発のインターンをしたあとに帰国して、学生時代に、弊社代表の堀江と出会ってdelyを創業しました。クラシル自体は3個目のプロダクトなので、2つ事業撤退を経験して、3個目にクラシルを2016年に立ち上げました。

クラシルは「70億人に1日3回の幸せを届ける」というテーマでサービスを開発しているんですが、クラシルをダウンロードしている人？　インストールしている人？

（会場挙手）

ありがとうございます。去年の12月に1,000万ダウンロードを累計で突破したぐらいの規模で、今でもさらに伸びているんですが、そのぐらいの規模感になってきています。テレビCMもやったので、だいぶマスに広がってきたと個人的には思っております。

昨日、少し大きなリリースを出したんですが、見たことがある人？

（会場挙手）

おっ、すごい。内容としては、ヤフーさんの連結子会社となったという話です。この目的をひと言でいうと、「めちゃくちゃでかいことをやりたかったので、ヤフーと組んで最速でやろう」ということで今やっています。

記事を読んでもらえればわかるんですが、食の領域のECをやろうと思っています。そこがマーケットとしてめちゃくちゃでかいので、そのマーケットをレシピ動画から拡大して狙っていきたいと考えています。

そこが取れれば、もうめっちゃデカいことになる。僕ら「どうせやるんだったらデカいことやろうぜ」と会社として思っているので、こんなタイミングで出しました。ぜひ読んでいただけるとおもしろいと思います。

認知バイアスを回避するためのアイデア検証プロセス

では、本題に入ります。今日は施策についての話ですね。「認知バイアスを回避するためのアイデア検証プロセス」というタイトルでやらせていただこうかなと思います。

今日お話ししたいことは、認知バイアスというものを回避してプロダクトを改善する方法みたいなものを、僕らが自分たちでやっているものの中から得た知見を含めて話したいなと思っています。

まず、認知バイアスとはなにかというと、「先入観」と日本語訳されることもありますが、なにかしらの心理的な状態によって、事実や真理と違う捉え方をしてしまうということを一般的には指します。

プロダクト開発をみなさんされていると思うのでなんとなくわかると思いますが、なにかを開発しよう、施策をやろうとか、機能を追加しようというときに、もちろんユーザーさんが使ってくれることを想定してやっていると思うんですけど、そこに認知バイアスみたいなものが紛れていることは事実としてあるかなと思います。

そうしたアイデアの検証プロセスをしっかり整理してやらないと、リリースしてみたらぜんぜん使われないとか、もしくは、運がよければリリース前日とかに気づいて「うわっ」みたいな、「なんかあんまりよくねえな、これ」ということもたまにあるかなと思うんですよね。そこをいかに回避していいプロダクト開発をしていくかということを話そうかなと思います。

改善アイデアを発見する

3つあるんですが、まず「改善アイデアを発見する」というのが第1に重要であると思っています。

僕らはペルソナとカスタマージャーニーを作っています。左側はペルソナで、細かく書いてあります。本当は4ページ目ぐらいまであるんですけど。

右側が典型的な生活行動みたいなことを書いています。これはもう超細かく書いていて、クラシルをどういうシーンで開いて、どこでまたもう1回開いて作って、満足したらどんな行動をするかというところまで。

先々月くらいには、典型的なクラシルユーザーの方に来ていただいて、1人90分かけて12人分のペルソナを作ったり共感マップを作るといったことを行いました。

まず、全体像をつかむのが重要です。なにか局所的なデータを見てもなかなか全体像はつかめないと個人的には思っています。まずは全体像をつかんでから、「ここもっと知りたいね」となってはじめてデータ分析に入っていくほうがいいんじゃないかなと思っています。

それを要素分解するというのが肝なんですが、ここがすごい重要であると思っています。

「課題事実」「原因仮説」「解決策」

改善のアイデアが出てくると思うんですけど、僕らは「課題事実」と「原因仮説」と「解決策」という3つに分けられると考えています。

僕もたまにやってしまうのが、これをごっちゃに考えちゃうとか、もしくは最初に「事実」について話していたのに、後ろの「解決策」についてのソリューションの話をしている、ということがあります。

具体的にどういうものかというと、「課題事実」というのは、誰が見ても同じことをイメージできるものということですね。典型的なのは、離脱率とかそういう数値的なものももちろん課題事実ですし。もしくはユーザーの行動。定量的なものじゃなくて定性的なものだとしても、ユーザーさんがこういうふうに動いたというところまでは事実なので、これはズレることはほぼないと思います。これをいっぱい集めるのも重要です。

ただ、ここからがズレてくるポイントで、原因仮説。それは、課題がどういう原因によってそうなっているのかという仮説を作ると思うんですが、この時点で人によって捉え方が変わってくることがよくあります。

例えば「『ピーマン』をキーワード検索した人の離脱率が高い」という事実があるとして、人によっては、なんでそうなるのかという仮説を考えると、「ピーマンをがっつり消費したいのに、ちょっと添えるみたいなレシピしか出てこないから、満足度が低い」という人もいるだろうし、「今、その人が持っていない材料がそのレシピの中にピーマン以外に含められていて、『これは作れないよ』といって離脱しちゃう人が多い」ということが仮説として考えられます。これは人によっておそらくズレてくるポイントです。

さらに、それに対する「どうやってそれを解決しようか」と考えるところもさらに分岐すると思うんですよね。仮に左側の仮説が正しかったとしたら、食材の消費量を検索ロジックの変数に加えるとか、食材の消費量で検索結果に対して手動でフィルタリングできるとかになるだろうし。

右側のところは、「詳細画面じゃなくて、検索の一覧上で必要な食材を表示してあげればもっと見やすいんじゃないか？」という人もいるだろうし、「手動で使いたくない食材を除外検索できるといいんじゃない？」という人もいる。

こういう感じで、まずよくありがちなのが、そもそもここを分類していなくて、「キーワード検索の離脱率が高いよね」みたいな話をしてたのに、いきなりソリューションの話にいってしまったりするわけですね。やはりこれは意識しなければわかりません。

まず、こうやって要素分解して、どういう状態になっているかを自分たちの頭の中で整理するのが重要かなと思っています。

「実装フェーズ」と「デザインフェーズ」を設ける理由

ここからは、その改善アイデアを検証していくサイクルに入ります。まずその方法論の前に、組織構造というか、開発フローについてちょっと説明します。

僕らは開発フローを2つに分けています。1つが、一般的には「実装フェーズ」。当たり前ですが、プロダクトは実装しないとリリースされないので、実装する人たちがいるし、そのサイクルが入っているんですけど。もう1個が「デザインフェーズ」を設けています。

ここで先ほどのアイデアの検証をやっています。これはなにやっているかというと、さっきみたいに分解していったアイデアについて、「本当にそれって正しいのかな？」というのを、プロトタイプを作ってミニマムのコストで最速で検証する。

よくあるのが、「実装してみたらなんかよくわからない感じになっちゃっていた」というのはあるあるだと思うんですが、それをできるかぎり早い段階で知れるようにしようというのが、このフェーズを設けている理由です。

アイデアがあって、プロトタイプを作って、ユーザーテストで検証して、それについての学習を得てから、必要だったらもう1回アイデアを検証するということをクルクル回して、いい感じになったら実装フェーズに渡すというステップを踏んでいます。

アイデアの検証のところには、ユーザーテストをしていて、もちろんどういうことを知りたいのかという設問を事前に洗い出してから、ユーザーをリクルーティングしてテストをするってことをやっているんですが、そこで検証することがほとんどです。

例えば、この図があったときにどのように検証していくか。それでどういうことがわかって、最終的にどうなるか、というのを1個1個ステップでやりたいんですけど。

課題事実は絶対にfixなので、ここはズレることはほぼないです。ただ、「じゃあ左側のところと右側のところって本当に正しいの？」というのを検証します。

アイデアを検証してから実装へ

まず、例えば「検索する食材の消費量を検索ロジックの変数に加えてユーザーテストをしてみました」ってやるとするじゃないですか。そのときに自分たちの思い描いていたユーザーさんの反応と違うなと思ったら、違うとわかると思うんですね。その時点でこの仮説は棄却みたいな。

そもそもやっている中で、原因仮説のほうが違うんじゃないかと思うと思います。ユーザーさんの声や実際に動いている行動を見るかぎり、なにかこういう理由で嫌だなと思っているわけじゃないなということを気づくことがあると思うんですね。

やっちゃいけないのが、原因仮説のほうがぜんぜん違うのに、解決策をいろんなパターンをどんどんやっていても、結局その前段階で違うのでダメになってしまいます。なので、こっちが違ったら、もう右下とかはそもそも検討の余地なし、みたいなイメージですよね。

じゃあユーザーさんの声で「自分の持っていない食材のレシピが表示されている」という課題があったら、ソリューションを探して解決策を検証していくわけですけど、右側のやつは「なんか冗長だし、そもそも機能に気づかない」、というふうになったら、左側のほうをやります。

ここで「1個いいやつがあったね」ってなったら、これは検証済みのアイデアとしてストックされるわけですね。

さっきのものに戻ると、この中の、デザインフェーズでいろいろクルクル回しているなかで検証済みのアイデアが1個ポーンと出てきます。これが出てきたらはじめて実装フェーズに渡すというステップを踏むことによって、いきなり思いついたアイデアを検証もなにもせずにポーンって入れちゃうよりは、確実に施策の精度とか確度が上がっていくと思います。

こうしたことをすることによって、ちゃんと改善できる開発フローや開発組織を作っていけるんじゃないかなと思います。

認知バイアスがあることを理解する

最後、まとめです。認知バイアスというのがあるかなと思っていて。こういうところで、最初これらのアイデアは、全部最もらしいと思ってみんな考えて作っているわけですけど、そこにはなにかしらの、その人固有の体験から生まれたソリューションのアイデアだったりもするわけですね。

そうしたことが認知バイアスとして入っているので、こういうプロセスを経てしっかり検証していくことで、認知バイアスを減らすことができます。そうすることでちゃんとプロダクトを改善していくという流れが作れるんじゃないかなと。しかも、それを属人的じゃなくて、組織的とか仕組みで解決できるようなやり方で開発できるんじゃないかなと思ってやっています。

以上になります。ありがとうございました。

（会場拍手）