# プロダクトの課題発見及び解決 ## はじめに Wantedlyでは全てのエンジニアやデザイナーがプロダクトを通してユーザに向き合い、プロダクトに関わる全てのことにオーナーシップを持っています。強いプロダクトビジョンを維持し価値提供を行う源泉はここにあります。Wantedlyにおけるプロダクトマネージメントはこういった組織的機能を指すと考えています。つまりエンジニアやデザイナーがプロダクトマネージメントについて学ぶことは非常に重要なことです。 本章ではプロダクトマネージメントの中でも、PMF後のプロダクトを対象に継続的に成長させる方法ついて紹介します。前半ではプロダクトの課題をどのように見つけるのかについて説明します。後半では具体的な解決アイディアを作って実行していくことや経験を次に活かすためにできることを説明していきます。 ## 成長させるためのサイクル 成長させるためのサイクルは次の4ステップから構成されます。次節よりこの4ステップについて順を追って説明していきます。 1. 課題発見/解決の考案 2. 優先度判断 3. 取り込む/実験 4. 結果検証/学習 ![Discovering and Solving Service Issues - 成長させるためのサイクル](/files/-MhWAMwZO8uW5MWpfsfR) ## 課題発見 課題発見には大きく定量的アプローチと定性的アプローチがあります。定量的アプローチではユーザ行動に関する数字を見て課題を発見します。一方で定性的アプローチではユーザ視点の感覚で課題を発見します。 また、別軸として探索型と検証型があります。探索型ではさまざまな可能性を見つけるために模索します。一方、検証型ではある仮説を持ってその正しさを確認します。 まずおすすめの方法は**探索型の定性的アプローチ**と**検証型の定量アプローチ**です。定性的なアプローチではアイディアを発散して探索することはそこまで難しくはありませんが、仮説を持って検証するには曖昧で取り扱いづらいことが多いです。定量的アプローチでは仮説を持って分析をすることは比較的容易ですが、発散すると分析のコストの割にあまり情報が得られなかったということが起きがちです。もちろん全てのケースでこの限りではありませんが、留意して取り組むと良いです。 ## 定性的アプローチ 定性的アプローチには大きく分けて「本当のユーザを観察する」方法と「ユーザになり切る」方法があります。「本当のユーザを観察する」方法はリスト1.の通りです。ユーザ自身やその課題について習熟していないケースやユーザビリティの課題がないかなどを確認したいケースでは有効です。 リスト1. * ユーザインタビュー * ユーザテスト 「ユーザになり切る」方法はリスト2.の通りです。本当のユーザを観察することに比べ比較的コストが低くすぐに始められます。 リスト2. * ドッグフーディング * ストーリーマッピング (カスタマージャーニーマップ) * CREATEアクションファネル (“行動を変えるデザイン”) * Hookedモデル (“Hooked ハマるしかけ”) さて、ここからは上記で紹介した方法についてもう少し詳しく説明していきます。 ### ユーザインタビュー ユーザインタビューは、実際にプロダクトを利用しているユーザに対して実施し、ユーザの課題やニーズを引き出します。具体的に検証したいことがない場合でなくても、まず大雑把に知りたいことをまとめるが重要です。知りたいことからインタビューを行うユーザの条件や人数を決めます。次に質問事項を用意する。このとき聞き方や順番を推敲します。最後に、目的や質問事項インタビューガイドとして1ページにまとめます。 また、ユーザインタビューにおける重要ポイントは質問をオープン・エンドにして自由に答えてもらうこと、自分自身のバイアスを外して誘導を避けることです。他にも重要な心構えがたくさんあります。「ユーザーインタビューをはじめよう - スティーブ・ポーチガル」を参考にしてください。 ### ドッグフーディング ドッグフーディングは、自社のプロダクトを自身で使ってみると言う意味です。まずこの奇妙な名前の起源は諸説ありますが、有名なものとして[「Kal Kan Pet Foodの社長が、株主総会で毎回自社のドッグフードを食べていた」](https://www.computer.org/csdl/magazine/so/2006/03/s3005/13rRUygBwg0)と言う説があります。人間が犬向けの食べ物を食べるという表現からも分かるとおり、開発者自身がフォーカスしているユーザ属性と全く異なる可能性があります。最も開発者は誰よりもプロダクトを知りすぎていると言う点は無視できないです。しかし、それでもドッグフーディングが重要であると言えるのはユーザとそのプロダクトについてリアリティを持って共感できる方法だからです。特に、ユーザのストーリーを持って使うことが重要です。それは機能するということ以上に課題を解決したいという意図を持って使うということです。ストーリーを持ってプロダクトを使うことってどういうことだろうと思ったのであれば、次に紹介するストーリーマッピングを合わせて実行してみると良いかもしれません。 ### ストーリーマッピング ストーリーマッピングは、ユーザの行動と感情をフェーズごとにまとめる手法です。この手法は「カスタマージャーニマップ」と呼ばれていることも多いです。対象がカスタマー(顧客)に限らないため、Wantedly ではストーリーマッピングという呼び名が一般的です。 この手法ではユーザが見ているプロダクトの状態とユーザの心境を時系列でグラフィカルに表現します。実践的な手法としてはMiroでスクリーンショットを貼っていき、具体的な状況や心境を書き込んでいきます。ここからギャップ分析を行っていきます。理想と比べて思ったより優れていない箇所がまさに見つけるべき課題です。 SlackやTwitterなど優れたプロダクトの具体例が知りたい場合は「ストーリーマッピングをはじめよう - ドナ・リシャウ」が参考になります。 ### CREATEアクションファネル CREATEアクションファネルは、ユーザがとりうる行動が実行されるために通過しないと行けない5つのステージで構成されてます。「行動を変えるデザイン ―心理学と行動経済学をプロダクトデザインに活用する - Stephen Wendel」で紹介されています。ユーザは下の図の順番に思考し離脱する可能性があると考えます。各ステージでどのようなことを考えなければならないかについてまとめます。 **ステージCue**では、プロダクトやその機能を使うことを思い出すためのきっかけがあるかどうかを考えます。思い出してもらうための印象づけ、導線や通知などがあるでしょうか。 **ステージReaction**では、ユーザが本能的に嫌っていないかを確認します。イライラするような体験がないかを思い出してみましょう。 **ステージEvaluation**では、ユーザがその機能に十分な価値があるのかを考えます。価値がありそうだと思ってもらえる情報を提示できているのかについて考えてみましょう。 **ステージAbility**では、その機能の利用するための環境が整っているのかを考えます。ユーザがその行動を容易に実行できないと感じるのであればすぐに離脱します。多くの場合クリック数やタップ数が少ないことが重要です。さらにいうと少ないだろうと**推測できる**ことも重要です。 **ステージTiming**では、今である必要を示す必要があります。常にユーザはそれをどのくらい先延ばしにしても良いかと考えています。この問題は非常に厄介ですが、今やるべき理由があるのであれば提示するべきです。 ![Discovering and Solving Service Issues - CREATEアクションファネル](/files/-MhWAMwaVCTvfFZCxmgw) ### Hookedモデル Hookedモデルはユーザがプロダクトの利用を習慣化するためのモデルです。「Hooked ハマるしかけ - Nir Eyal」で紹介されている手法です。繰り返しの利用を期待し、新しく習慣を作る必要があるプロダクトや機能にはうってつけの考え方です。HookedモデルではTrigger, Action, Reward, Investimentの4つのプロセスに分けられます。 ![Discovering and Solving Service Issues - Hooked サイクル](/files/-MhWAMwbV7j13AMSTjbz) Triggerでは、内的・外的な動機でプロダクトを思い出してもらいます。これはCREATEアクションファネルにおけるCueと同じです。ユーザ自身がプロダクトや機能について思い出す心理的な結びつきを作れているか、適切なタイミングで通知を送れているのかを思い出してみましょう。 Actionでは、報酬を期待させ単純な行動をしてもらいます。行動してもらうためにはモチベーションや能力が十分にあるかを確認します。つまりCREATEアクションファネルにおけるEvaluationとAbilityと同じです。 Rewardでは、実際に報酬を与えます。ここからがHookedモデルでは重要なポイントになってきます。社会からの承認、新しい刺激的な情報、スキルの獲得などが報酬に当たります。行動前にどのくらいの報酬かがわからない方がよりハマる可能性が高くなります。あなたのプロダクトにとってユーザに与える報酬が何かを考えてみましょう。 最後にInvestimentで小さな投資をしてもらいます。投資とは時間や行動をプロダクトに費やすことを指します。投資は将来得られる報酬の期待から行われます。投資をすることで行動一貫性の原則や投資効果により次のTriggerにつながっていきます。このプロセスではユーザに自分自身の情報を入力してもらえないかと考えてみると良いです。 ## 定量的アプローチ 問題となっているユーザ行動が複数のステップに分解できるのであれば分解してみましょう。ここで言うステップとはトラッキング可能なユーザの最小行動です。多くの場合はクリックやスクロールといったユーザアクションです。最初に想定した課題で大幅に離脱しているかどうかを確認します。他にも大幅に離脱しているポイントがないか、直感的におかしな箇所がないかを見つけます。 **セグメントに分ける** 問題だと思ったユーザ行動は、特定のユーザセグメントだけで起きている可能性もあります。もしユーザセグメント(例えば、ユーザは学生である、など)が仮定できるのであれば、検証してみる価値があります。ただ、あまりにも小さなセグメントで起きている可能性があるときは注意が必要です。計測結果はノイズが多く偶然起きている可能性が高くなり、改善できたとしても影響が限定されます。 ## 解決方法の考案 課題発見で見つけた課題から解決方法を考えて施策としてまとめていきます。施策にはリスト3.の情報を含めます。 * 解決方法 (誰にいつどのように何を提示するか) * 価値仮説 (想定している、ユーザの欲求とプロダクトのギャップ) * 結果の想定 * 評価方法 * 優先度指標 ### 解決方法 解決方法はできるだけ具体的に書きます。どんなユーザを想定しているのか、どのページにどんな条件で何を示すのかなどです。また、任意期間でどれくらいのユーザ数に表示されるかを把握すると良いです。このユーザ数は、この後の優先度判断や評価方法で利用します。さらに、もしUIが自明でない場合、ワイヤーフレームなどを利用しプロトタイピングすると良いです。多くの場合、UIを言葉だけで100%理解してもらうのは思ったより難しいので、プロトタイピングは常にお勧めです。 ### 価値仮説 ユーザに対してどんな価値があると考えているのかを説明します。課題発見で発見した「課題」から「価値」に接続させ「解決方法」の正当性を支持します。具体的には、ユーザの欲求とプロダクトのギャップを説明します。 ### 結果の想定 解決方法が**本当の意味で正しかった**と言えるには、成功シグナルを見つける必要があります。良い成功シグナルには次の条件があります。 * 実際のユーザの行動指標である * 成功/失敗するとき、必ず影響する指標である * 計測しやすい指標である * 短い期間で反映されやすい指標である 指標が見つかったら成功と失敗の閾値を決めましょう。具体的にどれくらいに設定するべきかは一概には言えないですが、プロダクトの主な指標から逆算して「どれくらいなら気に掛けるか」と言う点は重要です。指標の変化に対する感度はチーム全体で共有されていると良いです。 最後に、重要なのが**この想定が事前に**必要な理由です。このプロセスが回避するのは次の惨事です。 * 実は計測できない指標であった * チーム内で結果の賛否が別れて、数字いじりに陥る ### 評価方法 評価方法とは、「結果の想定」で示した指標の変化をどのように計測するかです。比較的簡単に取れるのは、A/Bテストと前後比較です。最初にA/Bテストを検討し、難しい場合に前後比較を検討します。なぜなら、A/Bテストは解決方法の影響のみを評価できますが、前後比較は解決方法以外の影響も受けるため非常に厄介だからです。 ### A/Bテスト A/Bテストを含むランダム化比較試験では、ユーザをランダムに選び実験群と対照群に分けます。実験群に対して解決方法を取り込み、対照群には取り込みません。その結果、計測指標に対して各群の差を比較すれば解決方法の影響を示せます。 さらに、各群の差が偶然でないことを示すためには、十分なサンプル数が必要です。必要最低限のサンプル数はベースライン、最小検出可能効果、信頼水準から計算します。Optimazlyが提供するCalculatorを使うことで簡単に計算できます。「必要最低限の合計サンプル数」を「任意期間あたりのアクセスユーザ数」で割ると必要な実験期間がわかります。実験期間は2週間以内が望ましいです。2週間より多くかかりそうな場合、A/Bテストを断念するか実行後に期間を区切って終了することをお勧めします。A/Bテストを長期化する場合は改悪するリスクが増えることを念頭に置く必要があります。 * [A/B Test Sample Size Calculator](https://www.optimizely.com/sample-size-calculator/) * 『A/Bテスト実践ガイド 真のデータドリブンへ至る信用できる実験とは』 - Ron Kohavi他 ### 前後比較 前後比較では、解決方法を取り込む前の期間と後の期間での指標を比較します。非常にシンプルに見えますが、解決方法以外の因子があるので厄介です。前後比較をしたときに、結果指標に十分な差があり、解決方法以外の因子を全て検討した上でどう考えても解決方法の影響だったと言える必要があります。ここで最も気をつけるべき因子は、**季節性の変化**や**同時期に実施された他の変更**です。多くの場合はこの簡易方式で十分ですが、もう少し形式的には多変量解析があります。詳しく知りたい場合は「効果検証入門～正しい比較のための因果推論/計量経済学の基礎 - 安井 翔太」が参考になります。 ## 優先度判断 優先度判断のためのフレームワークは様々なものがありますが、ここでは社内で最もよく使われるICEスコアについて解説します。ICEスコアは多角的に評価できシンプルであると言う意味で優れています。他のフレームワークも知りたいのであれば[プロダクトマネジメントの優先順位付けフレームワークの究極ガイド](https://zenn.dev/pm_translate/articles/054e6e384062f4#優先順位付けフレームワーク)を参考にしてください。 ICEスコアの定義は下の式で表すことができます。各項目は1-10の10段階で評価します。各項目の定義は下の通りです。具体的な基準はチーム内で話して作ると良いです。 ![Discovering and Solving Service Issues - ICEスコアの定義](/files/-MhWAMwc4bucQhUlWoKD) * Impact: 主要な指標に対してどれくらい影響するか * Confidence: どのくらいの確率で成功すると考えているか * Ease: どれくらい簡単に実装可能か 優先度を判断するには誰もが見えるところにリストを作成します。どのツールを使っても良いですが、ICEスコアで簡単にソートできることが重要です。内容としては、タイトルとICEスコアと詳細リンクがあれば最低限は問題ないです。ICEスコアを高い順番に並べ違和感がないかをチームで議論します。ICEスコアを調整して妥当だと感じたのであれば、上から順に取り組みます。 ## 効果検証/学習 ### 結果をまとめる A/Bテストの場合、各群の指標の値とp値を示します。Rで母比率の比較をする場合`prop.test`を用います。次の例では対照群でのCVRが`120/7000`で、実験群のCVRが`161/7000`の場合の結果です。p値が`0.01593`で有意水準`0.05`を下回っているので有意な変化だと言えます。 ```r > prop.test(c(120, 161), c(7000, 7000)) 2-sample test for equality of proportions with continuity correction data: c(120, 161) out of c(7000, 7000) X-squared = 5.8106, df = 1, p-value = 0.01593 alternative hypothesis: two.sided 95 percent confidence interval: -0.010645214 -0.001069072 sample estimates: prop 1 prop 2 0.01714286 0.02300000 ``` この例だと次のようにまとめられます。 ``` ## 結果 p値が0.015のため、CVRの32.5%増加は有意だと言える。 - 対照群CVR: 1.7% - 実験群CVR: 2.3% ``` 前後比較の場合、前期間と後期間それぞれの指標の値と指標に影響しうる他の変更や要因がないかをまとめます。例えば次のような文章です。 ``` ## 結果 変更前と比べて変更後ではCVRが32.5%増加している。昨年同時期の変化率は5.4%であり季節的な変化の影響より今回の変更の影響が支配的だと考える。また、同期間に同一ページでの変更は行われていない。 - 前の2週間CVR: 1.7% - 後の2週間CVR: 2.3% ``` ### 考察をする 議論の余地がある点を明確にする必要があるため、結果と考察を分けることが重要です。結果ではなるべく事実のみを述べ、考察では発見したことや自身の考えを述べます。想定した結果に対して実際はどうだったのか、つまり成功したのか失敗したのかを言及します。成功した場合と失敗した場合では次のようなことを軸にして考えをまとめると良いでしょう。 * **成功した場合** * ユーザが本当に意図通りの行動をしているか他のシグナルを調べる(追加証明) * 追加でわかった事実はないかを探す * 別の問題が発生していないかを探す * **失敗した場合** * 意図通りにユーザが行動しない可能性をリストアップする * 実際に行動が阻害した結果がないかを調べる * 次の仮説を作る ### 結論 最後に結論をまとめます。後から見返したとき最も重要なパートです。結論では成功の可否、結果と考察の要約が3行程度で記載されていると良いでしょう。 ## まとめ プロダクトの改善プロセスを「課題発見/解決の考案」「優先度判断」「取り込む/実験」「結果検証/学習」というフェーズに分解し活用できるテクニックを紹介してきました。課題発見では定性的アプローチと定量的アプローチがあります。特に定性分析ではドッグフーディング、ストーリーマッピング、CREATEアクションファネル、Hookedモデル、などさまざまなモデルがあるのでぜひ色々試してみてください。解決方法の考案では、解決方法、価値仮説、結果の想定、評価方法、優先度指標の項目に分解してまとめていきます。優先度判断では、ICEスコアをつかってチームで効果的だと思える施策から取り組めるようにします。実験をした後の効果検証/学習では結果と考察を分けて述べます。考察では失敗しても成功しても学びを深めます。このように施策を回していけば、必ず次の施策につながります。サイクルを回せば回すほどチームの集合知が高まっていき効率良く改善できているのを感じるでしょう。この漸進的な活動こそが改善フェーズにおけるプロダクトマネージメントです。全てのエンジニアがプロダクトマネージメントに興味を持ってもらい、ぜひどんどんチャレンジしてもらえたら嬉しいです。 #### 話を聞きに行きたい * Slack: [#product\_management](https://wantedly.slack.com/archives/C01SYNKAC3W), [#products\_products](https://wantedly.slack.com/archives/C028QUT3NQ7) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.wantedly.dev/fields/dev-process/discovering-and-solving-service-issues.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.