アナリストがプロダクトディスカバリーに触れ、デリバリー至上主義から改心した話

今回はプロダクトディスカバリー（以下ディスカバリーに略）を実践してみての気づきを記していきます。

ディスカバリーの定義については後述しますが、リサーチ手法という観点ではMixed Methods（定性調査と定量調査をミックスする手法）に近しい手法です。

ディスカバリーという言葉は、国内では

で記されたことで注目度が上がってきているようで、米国では上記以前から注目されています。

Rettyでは、私の入社前からディスカバリーを実践していました。

入社当時はその概念・活動を知らずでしたが、オンボーディング時に内容を聞いて

と思っておりました。

しかし、入社してから3ヶ月間、ディスカバリーの取り組みを経験し・ユーザーの解像度を高められること・チームで「価値ある」プロダクトを作っていくというコンテキストを揃えられること

という点で良い手段だと感じています。

本文が長くなってしまったので先に5行結論を書いておきます。

現場オンボードが終わって実務に入って数日後のある日。

ある機能A、B、Cが重要なメトリックスに効いていることがわかり、より多くのユーザーにその機能を使ってもらうための施策を考えておりました。そこで、A、B、Cのどこから優先度をあげて施策に落とし込むかをチームで議論し、無事に優先度決めができました。（ここではA機能を使ってもらうことが最も優先度が高いと決めたとします）

「では、A機能を使ってもらうための施策検討に進みますか」と私が言うとPdMから「いや、施策実施前にディスカバリーで探索を進めていきましょう。まだ、既存のユーザーがA機能をどういう使い方をしており、また、どんな体験・価値を享受すると使って頂けているのかなど未知が多いです」と。

私の頭の中では「ディスカバリー？？？」となったわけです。チームでは日々使われる言葉でしたが、これが私がディスカバリーという言葉を深く考え始めるきっかっけとなった出来事でした。

ディスカバリーとはなんでしょうか？

直訳として「なにかを発見する」、プロダクトディスカバリーという意味合いでは「プロダクトのなにかを発見する」というニュアンスは理解できると思います。

しかし、「具体的になにを発見するのか？」 についてはわかりません。

調べてみると

などでてきます。

誤解を恐れずに言えば、これらは点での手法を並べているだけだと思います。

よりディスカバリーを理解するために書籍もあさってみました。

参照1/  LEAN UX

つまり、点の手法ではなく、フローの概念であり、そのフローのパーツとして各検証手法を織り交ぜていくことが重要だとわかります。

参照2/  INSPIRED

と記しています。

ちなみに、実践を通じてわたしが思うディスカバリーとは

と考えています。

より端的にいうと、仮説に対してユーザーの解像度を上げていく探索と発見の繰り返しです。

つまり、プロダクトづくりにとって「ディスカバリー」は超重要な過程であり活動です。

「高速でゴミを生み出していないか？」

突然ですが、この言葉にドキっとする人もいるかと思います。

はサービス・プロダクト作りに関わる人であれば、誰しも一度は経験したことがあると思います。

しかも作った後に判明することほど辛いことはありません。「これは勉強代になった」というプラス思考への転換より、途方にくれ、すごい無駄をしたな、という空虚な気持ちの方が上回るというのがリアルだと思います。

しかし、これらを頭ではわかっていても業務の中では

と、機能を出すこと（デリバリー）がゴールで、チームで目的を理解・確認しないまま機能・その集合体であるプロダクトを創り上げてしまうことがあります。

このような事態を避けるためにディスカバリーを行います。言語化すると、

仮説に潜むリスク（＝不確実性）をリリースする前に発見し、ユーザーのためにつながらない「無駄」への投資を下げるため。これがディスカバリーがある理由です。

RettyではPdM・デザイナー・データアナリストでディスカバリーを担うワンチームを構成し、このチーム単位で1週間を1スプリントとして回しています（1つのチームの中に複数のディスカバリーが走ることもあります）。

各チームは「どんなユーザーのどんな課題を解決・改善するか」が明確化された大きめの課題を複数担当します。

・問いを立てる・問いのリファインメント

・問いの検証・問いの検証レビュー

・問い→検証を繰り返して未知→既知を増やしていきます。・ディスカバリーフェーズを終えたものはデリバリー（施策検討・実装フェーズ）に移ります。

これらディスカバリーのプロセスをスライドやMiroに可視化していきます。個人的にこの可視化への落とし込みを怠らないことが非常に重要だと考えています。

が最適だと思います。

下記が1つのある課題に対し、問い・検証を複数完了しおえた過程（一部加工済み）になります。未知フェーズのものを検証可能な問いに置き換え、検証し、既知への転換を繰り返します。可視化することで、次は何を説くべきなのかの合意形成がしやすくなっています。

こんな感じで可視化を進めてます（内容は一部加工済み）

アナリストは問いを立てる・検証に注力します。ここをPdMと伴奏していきます。

良質な答えを手にするための鍵は、良質な問いにある。ディスカバリーに注力していく中で非常に重要になる考えです。

アナリストは構築済みの問いに対して分析をするのではなく、PdMなどチームメンバーと、問いを立てるところから議論に参加していきます。

具体的な分析が始まる前のこのフェーズでは、アナリストは以前に行った関連する分析結果やインタビューなどから問いとなる材料を提供し、問い、問いに紐づく仮説出しを行うMTGを進めていきます。

では、この良質な問いをどのように作るのか？ここは日々私も葛藤している部分ではありますが、PdMの@tnkdaitoが社内Wikiやnoteにも型化してくれています。

個人的には、後述の実例でも記載した

をよく使って議論を進めました。これらは記載通り

です。

実際の例だと

これらを適切な検証方法で分析を進めることで下記のような体験の線がわかりました。

また価値についても、Rettyで「詳しい人たちのオススメがあるから安心してお店が決められる」という価値を感じて、行きたいお店が見つかっている。ということもわかりました。

この線の中で、より知りたい部分についてはファネルで細分化して各問いをつくっていきます。（例：どのように、「行きたいリストに追加してもらえているのか、継続的に使ってくれているユーザーとの行動差分はあるのか？」等）

このように問い→検証→問い→検証を繰り返すことで未知から既知を増やすディスカバリーを進めていきました。

個人的にもこれらの問いを考える習慣がつき、チームとしても根付き始めていることで、安易に解決策に走らないカルチャーになってきています。

とはいえ、まだまだ磨ききれていない部分ではあるので、ここはチームとして精度を上げていきたいポイントです。

検証方法は定量分析、N1ログ分析、定性分析（ユーザーインタビュー等）、アンケートでのプロトタイプ検証等、問いに応じて適切に試していきます。

上記の中でアナリストは定量・定性の分析を共に進めていきます。

定量分析をアナリストが進めるのはイメージが付く人も多いかと思いますが、いわゆるUXリサーチ等を駆使した定性分析も進めていきます。経緯などはこちらに記されています。

まずアウトプットをする箱を用意するということが非常に効きました。

抽象的にいうと、目的からの逆算ということ。

データ分析の場合、仮説検証型と探索型と大きく分かれると思いますが、ここは検証型で進めていきました。

実際に分析・リサーチを進めている中で「何の目的だったっけ？こっちに変えた方がいいんじゃない？」などと、問いが自然とすり替わり、目的を見失ったりすることはあるあるだと思います。（※分析プロセス、結果から意図して問いをPIVOTすることはあります）

しかし、事前にアウトプットの箱があると、それに答えられるように、分析結果・情報を入れることになるので、旗となりレールとなり道を失わずに進めます。加えてアウトプットフォーマットが先にあることで、チームで認識がすり合いやすくなります。

とりあえず調べるのではなく、なぜ、何を、どう知りたいかを用意。

普段から習慣づいている人からすると当たり前ですが、非常に有効な手段です。

実際のスライド（内容は一部加工済み）

ディスカバリーをする上で気づいたメリットを書いていきます。

前述した通り、早く創れるからといって誰も必要としてない無駄な機能・プロダクトはつくらない。成功の確実性を高めるためにも、リスクを言語化し、検証し未知を既知にしていく（=ディスカバリー）。結果、自分たちの仮説（アイデア）が間違ってることに早く気づくことが大切。

こういった価値観がプロダクトに携さわるチームメンバーが意識的に考えられていると思っています。少なくとも私はこの3ヶ月で頭に叩き込まれました。

チーム内外でコンテキストを揃えやすくなっていると思います。

前職で私自身が開発をしていた際は「なんでこれを作るの？」「これを実装することでユーザーの何を解決するの？」とよく思うことがあり、実装フェーズでの手戻りがよく発生していました。また、実際にはストーリーがあったにも関わらず、PdM→エンジニア間でそのコンテキストがごっそり抜け落ち、点としての実装になっていたこともありました。

しかし、ディスカバリーでは、スプリントレビューの時点で、チーム内外のエンジニア等からもFBを頂けたり、実装・施策段階（デリバリーフェーズ）でコンテキストが揃っているのでコミュニケーションコストが減り、スムーズに進みやすくなっていると思います。

一方で、ディスカバリーを完璧にできているわけでもないので、実践過程で起きた課題も記します。

ある課題に対してどのくらいディスカバリーに投資し、どのタイミングでデリバリーするかという問題です。

型化がしにくく、教科書がないため「どこまで既知になればディスカバリーに目処をつけるか？」とチームでよく議論したりしました。最終的にはPdMによる意思決定を握ります。

正解はないので非常に難しいですが、こういった時にも可視化は非常に役立ちました。今Q進めたディスカバリーを1枚のスライドで可視化していたので、「この未知が既知になればデリバリーに進んでもよいのではないか？」とPdMがチームに合意を取り、一定ディスカバリーが進みリスクもかなり最適化されている状況だったのでデリバリーに進む判断をしました。

分析前にアウトプットの箱を用意しつつも、箱の質が低かった

これはディスカバリーの課題というより、業務を進める上で起きた課題です。

ある問いに対して分析をし、問いに対する答えは出たが、ネクストアクションに繋がらなかったことがありました。具体的には、定量分析で具体的な件数（xxxをyyyする人はn件以上等）がでればネクストアクションに繋げられると思ったが、そうは至らなかったケースです。

これは、分析設計で件数だけでなく比率も踏まえたアウトプットイメージ（箱）を作ることができていれば、検証ができて、問いに答えられ、ネクストアクションが決まっていたとチームで振り返りました。

この課題の解決策として、アウトプットイメージを複数パターンを作っておくことで、この件での大きな手戻りはなくなりました。

ここまでディスカバリーを実践してみての気づきや実際の運用方法について書いてきました。

今後ディスカバリーを導入する方がいらっしゃれば、1つでも役に立つことがあれば嬉しいです。

ディスカバリーをする前の私は「できるだけ多くの施策やリリースをし実践をフットワーク軽く試す」ことがプロダクトを成長させることの正義だと思っていました。

しかし、機能があればOKという話ではなく、「ユーザーにとって本当に意味があるものなのか」ということはPdMだけでなくプロダクトづくりに関わるメンバー全員が考え続けるべきであって、この価値観を事前検証時から実践することで、不確実性を下げられることに非常に効果的であることを身にしみて感じました。

たくさんの早いリリースは大抵失敗し、結果的に目的の検証には遠回りになることが多いです。であればリリース前に検証を重ねてユーザーを知る努力をする。ユーザーのことを知った気になってはいけないんだな。ユーザーに対する謙虚は常に持つべきだな。

これをディスカバリーを通じて学びました。

そのためには、良い問いを設定することに投資すること、そこから逃げないこと。なぜなら、良い問いであればあるほどユーザーを知る良い検証になり、良いソリューションに繋がる。アナリストとしてどんだけSQLを書くスキルがあっても、うまくユーザーインタビューができても、問いの設定が誤っていれば元も子もないです。

一方、良い問いを立てることが成果を出すために必要であることは真ですが、良い問いを立てるだけで成果が出るわけではないことも真です。

だからこそ、デリバリーを通じてその問いを確かめ、さらにその評価を踏まえて次なる問いを立案し、またそれを実行して評価する。これらを繰り返し、事業上の成果の最大化を図る必要があるんだと思います。