はじめに
こんにちは、ログラスで PdM をやっている石畑です。
社会人になってからずっとエンジニアをやってきたのですが、半年ほど前に PdM にコンバートしました。エンジニアである自分がいかにプロダクトディスカバリーを行い、機能開発を行ったのか振り返ってみたので、同じ境遇の方やこれからプロダクトマネジメントを学びたい方などの参考になれば幸いです！
ディスカバリーとは
ディスカバリーの目的
そもそもディスカバリーとは何でしょうか？ひとことで言うと「何を作るか決めるプロセス」ですが、「INSPIRED」には、ディスカバリーの目的は以下のリスクに対処することだと書かれています。
・顧客はこれを買ったり、これを使うことを選んでくれるだろうか？（価値のリスク）
・ユーザーはこれの使い方がわかるだろうか？（ユーザビリティーのリスク）
・私たちはこれを作れるだろうか？（実現可能性のリスク）
・このソリューションは私たちのビジネスに貢献するだろうか？（事業実現性のリスク）
引用元 : マーティ・ケーガン; 佐藤真治; 関満徳. INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント
本格的に開発を始める前に、これらのリスクに対して仮説検証を繰り返して答えを見つけるのがディスカバリーの目的になります。
Fail Fast
ディスカバリーで常に意識しなければいけないのが Fail Fast、つまり「安く、早く、失敗する（学ぶ）」ことです。「BIG THINGS」には、ピクサーの映画制作の例で「安く、早く、失敗する」ことの重要性が書かれています。
伝説的映画スタジオのピクサーでは、「監督は映画の開発フェーズに何年もかけることを許されている」
…（中略）
もちろん、アイデアを開発し、脚本を書き、絵コンテを描き、それを何度となくくり返すことにも、コストはかかる。だがこの段階であれば、「試行錯誤のコストは少額ですむ」。
…（中略）
これは大事なことだとキャットムルは強調する。なぜなら制作に入ると「コストが一気に膨らむ」からだ。
このコストの差が重要な理由は単純だ。大型プロジェクトではトラブルが起こるのは確実で、「いつ」起こるかだけが問題だからだ。反復的プロセスによって、その「いつ」が「計画フェーズ中」になる確率を大幅に高めることができる。
引用元 : ベント・フリウビヤ; ダン・ガードナー. BIG THINGS どデカいことを成し遂げたヤツらはなにをしたのか？
ディスカバリーをしていると「早く答えを出したい」衝動にかられるのですが、「いかに作らずに間違いに気がつけるか」が重要になります。
影響度（リスク）が大きいものから始める
せっかく学びを得ても前提がひっくり返ると、その学びはほとんど意味がないものになってしまうため、解決する順番を意識する必要があります。
「プロダクトマネジメントのすべて」では、必要な仮説を 4 つの階層に分けて整理しています。上の階層の意思決定が下の階層に影響します。
引用元 : 自己流から一流プロダクトマネージャーになるために学ぶべきこと #pmconf2020
Core は新規にプロダクトを立ち上げる場合や、大きく方針転換をする場合にしか変わることはないと思うので、多くの場合は Why から始めることになると思います。
もちろん「どう作るか？」がユーザー体験や課題のスコープに影響したり、GTM で優先度が変わることもあるので、単純な一方通行ではなく、相互にも依存しますが、概ね上から下に進んで行くと手戻りを小さくできます。また、多くの場合、下に行くほど検証コストが高くなっていくので、その観点でも重要です。
ここまでのまとめ
- ディスカバリーは「価値」、「ユーザビリティー」、「実現可能性」、「事業実現性」の 4 つのリスクに答えを出す
- 可能な限りコストが安く・早い方法で価値検証を繰り返す
- Why → What → How と進めていく
自分は上記の考えを前提に、実際に取り組みを進めていきました。
実際の取り組み
それでは、実際にやってきたことを書いていきたいと思います。正直、そんなにきれいに分けられないですし、全てを列挙することはできないですが、概ね以下の取り組みをやっていきました（2,3 は並列にやっているイメージ）。
- 業務・課題を学ぶ
- ユーザーストーリーマッピング
- 業務全体・大枠の体験の作成
- 競合調査
- ワイヤーフレーム作成
- ビジネスインパクト測定・機能の優先度決め
- KPI 作成
- 顧客データ・要望分析
- 詳細な体験・UI の作成
- UI / UX 作成
- 実例マッピング
- プロトタイプ作成
- 技術検証
- スパイク実装・PoC の作成
簡単に紹介していきます。
ユーザーストーリーマッピングで業務・課題を学ぶ
とにかく様々な場面で事あるごとに作っていたのがユーザーストーリーマッピングでした。エンジニアで、経営管理システム開発歴が 1 年半程度である自分に圧倒的に足りないのはドメイン知識です。
しかし、例え自分に知識が無くとも、社内には元々経営管理を行い、現在も様々な顧客の業務を間近で見ている CS の方々がいます。CS の方と大小様々なユーザーストーリーを作成することで、まず徹底的にユーザーと業務について学んで行きました。
ユーザーストーリーマッピングとは
ユーザーストーリーマッピングは「ユーザーストーリーマッピング（Jeff Patton 著）」で紹介されている探索のための手法です。やり方はとても簡単で、
- （詳しい人が）ストーリーを語る
- 語ったことを付箋に貼る
これだけです。
様々な業務をストーリーで理解することで、「誰が、何のために、何をするのか」の共通理解を作ることができます。
もう少し具体を以前 LT で発表しているので、興味ある方はよかったら参照してください。
ディスカバリーを成功に導くユーザーストーリーマッピング
ユーザーストーリーで課題を特定する
顧客ヒアリングなどもしながら様々なパターンのストーリーマップを作成し、ユーザーの業務知識を深めていきました。
- Loglass の使用の有無
- 業界・規模
- 注力セグメント
初めはどういう分岐があるかわからなかったので、詳細に作成 → まとめる、というのを繰り返すことで徐々に重要なストーリーを抽出・理解を深めていきます。
そして、AsIs が分かってきたら ToBe も付箋で書いていき、現状との差を比較し、課題を特定します。全ての課題をディスカバリーすると規模が大きすぎるので、ユーザーストーリーマッピングで課題の優先度も決めてこの先の探索を進めていきました（データ分析の結果などで優先度は定期的に見直す）。
大小さまざまなストーリーマップを作成
付箋さえあればできるので、とてもコスパが良いです。
ワイヤーフレームで大枠の体験を作成する
大体、解決すべき課題は見えてきているので、ワイヤーフレームでよりソリューションのイメージを詳細化し、価値検証をしていきます。
ワイヤーフレームは色々抽象度があると思いますが、「どんな画面になるか？」というよりも、
- どういう工程があって
- ユーザーはそこでどのようなアクションを行い
- どういうデータが作成・表示されるのか
というのを中心に作っていきます。今まで（ユーザーストーリーマッピングで作った）付箋でしかなかったものを肉付けしていくイメージです。
特に業務アプリは
- 業務全体を通してどういうデータが入出力されるのか
- それが各工程でどのように使われるのか
が重要なため、サンプルデータなどを作りながら重点的に見ていきます。ここでも顧客ヒアリングを行い、想像ではなく、実際に使用しているデータを見ることが大切です。
ここで何度も何度もワイヤーフレームを作成しては、レビューを受け、ボツにしていきました。付箋を書くよりは大変ですが、まだまだ安いコストです。
顧客データ・要望分析を行い、優先度を決める
ストーリーだけではパターンの母数が少なかったり、主観も入ってくるので、データを見て価値検証していきます。
この時点で、AsIs・ToBe を書き、課題・理想も見えているので、ブレイクダウンしていけば KPI は作成可能です。KPI を元に仮説が正しいのか・それは本当に課題か、データ分析を行いました。
また、Loglass には毎日のように営業や CS の方々が上げてくれている顧客要望 DB があります。蓄積された要望をストーリーマップにマッピングすることで、課題やソリューションに価値があるのか確認します。あまりにも古い要望だと取り組む価値があるのかわからないので、過去 3 年分の要望を全て見直し、タグ付けしていきました。
実例マッピングで論点を整理
ワイヤーフレームの作成を繰り返していく内に徐々に UI/UX も詳細化されていきました。そうして、ある程度 UI/UX が明確になってきたタイミングで実例マッピングを行いました。大分、体験が具体化され、既存の機能への影響なども見えてきているので、技術的な観点も入れて UI/UX のレビューと論点の洗い出しを行います。
実例マッピングについても以前 LT を行ったので、もしご興味があれば。
プロダクトの品質に コミットする
洗い出した論点は優先度を決め、また UI/UX の作成を繰り返していきます。
プロトタイプを作成し、体験を操作して確認する
「細かい UI 以外ほとんど確定」という状態まで来たら実際にプロトタイプを作成して、触ってもらえる状態にしていきます。これまではプロトタイプといえば「Figma で紙芝居」だったのですが、このときはデザイナーの方が Cursor などで動くものを作ってくれました。気づいたら自分より実装してた… すごい…（なんなら最近はワイヤーフレームの段階でパッと作ってくれる）。
紙芝居ではないので、実際に自由なデータを作成して、体験を進めることができ、かなり本番に近いイメージで価値検証を行うことができます。
スパイク実装で Proof of Concept
ここまで来たら「価値」、「ユーザビリティー」、「事業実現性」のリスクは解消してきているので、最後の「実現可能性」を最もコストの高い「実装」で検証していきます。
もちろん検討が無駄にならないように、ここまでもある程度の実装イメージはつけながら進めていますが、ここで実際にエンジニアにコーディングしてもらいます。とは言え、全てを実装するわけではなく、「技術的に重要な部分のみ」を「全てのコードを捨てる前提」で実装していき、実現可能であることを確認します。
スパイクに関しては、ryuzee さんのブログにとてもわかりやすく書かれています。
スクラムにおける技術的スパイクの進め方
以上、ディスカバリーでした！ここまで来ると大分リスクは軽減され、デリバリー（本格的な開発）の成功確率が上がっていると思います。
より良くするには
もちろん反省だらけなのですが、一つ挙げると「ドキュメントを書かなすぎた」と感じています。最終的には PRD を書いているのですが、あまり途中の議論をドキュメントに残すことをしていませんでした。
とはいえ、ユーザーストーリーマッピングは残っているので説明可能ですし、ドキュメントではなく、対話を大事にしていたので意識的なものでもあったのですが、
- メンバーの増減で一部リセットされる
- 人は忘れる
という当たり前の反省がありました。なので、今思うと
- 仮説キャンバスを使って現状を簡単に・網羅的に確認できるようにする
- 議論に発展したものは（プロダクトの）ADR を書いて LLM などで参照可能にする
などをやっておくと良かったと考えています。
さいごに
最後まで読んでいただきありがとうございました！
まだ PdM 半年程度で、自分の「プロダクトマネジメントの型」がないので、このブログを機会にやってきたことを振り返ってみました。一つでも参考になるものがあると嬉しいです。
Discussion