> For the complete documentation index, see [llms.txt](https://docs.wantedly.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.wantedly.dev/fields/dev-process/discovering-and-solving-service-issues.md). # プロダクトの課題発見及び解決 ## はじめに ウォンテッドリーでは全てのエンジニアやデザイナーがプロダクトを通してユーザーに向き合い、プロダクトに関わる全てのことにオーナーシップを持っています。強いプロダクトビジョンを維持し価値提供を行う源泉はここにあります。ウォンテッドリーにおけるプロダクトマネージメントはこういった組織的機能を指すと考えています。つまりエンジニアやデザイナーがプロダクトマネージメントについて学ぶことは非常に重要なことです。 本章ではプロダクトマネージメントの中でも、PMF後のプロダクトを対象に継続的に成長させる方法ついて紹介します。前半ではプロダクトの課題をどのように見つけるのかについて説明します。後半では具体的な解決アイディアを作って実行していくことや経験を次に活かすためにできることを説明していきます。 ## 成長させるためのサイクル 成長させるためのサイクルは次の4ステップから構成されます。次節よりこの4ステップについて順を追って説明していきます。 1. 課題発見/解決の考案 2. 優先度判断 3. 取り込む/実験 4. 結果検証/学習 ![Discovering and Solving Service Issues - 成長させるためのサイクル](/files/-MhWAMwZO8uW5MWpfsfR) ## 課題発見 課題発見には大きく定量的アプローチと定性的アプローチがあります。定量的アプローチではユーザー行動に関する数字を見て課題を発見します。一方で定性的アプローチではユーザー視点の感覚で課題を発見します。 また、別軸として探索型と検証型があります。探索型ではさまざまな可能性を見つけるために模索します。一方、検証型ではある仮説を持ってその正しさを確認します。 まずおすすめの方法は**探索型の定性的アプローチ**と**検証型の定量アプローチ**です。定性的なアプローチではアイディアを発散して探索することはそこまで難しくはありませんが、仮説を持って検証するには曖昧で取り扱いづらいことが多いです。定量的アプローチでは仮説を持って分析をすることは比較的容易ですが、発散すると分析のコストの割にあまり情報が得られなかったということが起きがちです。もちろん全てのケースでこの限りではありませんが、留意して取り組むと良いです。ただしAIの活用によって定量的アプローチの探索コストは下がりつつあり、この前提は変わってきています(後述の「AI を活用した定量分析」を参照してください)。 ## 定性的アプローチ 定性的アプローチには大きく分けて「本当のユーザーを観察する」方法と「ユーザーになり切る」方法があります。「本当のユーザーを観察する」方法はリスト1.の通りです。ユーザー自身やその課題について習熟していないケースやユーザビリティの課題がないかなどを確認したいケースでは有効です。 リスト1. * ユーザーインタビュー * ユーザーテスト 「ユーザーになり切る」方法はリスト2.の通りです。本当のユーザーを観察することに比べ比較的コストが低くすぐに始められます。 リスト2. * ドッグフーディング * ストーリーマッピング (カスタマージャーニーマップ) * CREATEアクションファネル (“行動を変えるデザイン”) * Hookedモデル (“Hooked ハマるしかけ”) さて、ここからは上記で紹介した方法についてもう少し詳しく説明していきます。 ### ユーザーインタビュー ユーザーインタビューは、実際にプロダクトを利用しているユーザーに対して実施し、ユーザーの課題やニーズを引き出します。具体的に検証したいことがない場合でなくても、まず大雑把に知りたいことをまとめるが重要です。知りたいことからインタビューを行うユーザーの条件や人数を決めます。次に質問事項を用意する。このとき聞き方や順番を推敲します。最後に、目的や質問事項インタビューガイドとして1ページにまとめます。 また、ユーザーインタビューにおける重要ポイントは質問をオープン・エンドにして自由に答えてもらうこと、自分自身のバイアスを外して誘導を避けることです。他にも重要な心構えがたくさんあります。「ユーザーインタビューをはじめよう - スティーブ・ポーチガル」を参考にしてください。 ### ドッグフーディング ドッグフーディングは、自社のプロダクトを自身で使ってみると言う意味です。まずこの奇妙な名前の起源は諸説ありますが、有名なものとして[「Kal Kan Pet Foodの社長が、株主総会で毎回自社のドッグフードを食べていた」](https://www.computer.org/csdl/magazine/so/2006/03/s3005/13rRUygBwg0)と言う説があります。人間が犬向けの食べ物を食べるという表現からも分かるとおり、開発者自身がフォーカスしているユーザー属性と全く異なる可能性があります。最も開発者は誰よりもプロダクトを知りすぎていると言う点は無視できないです。しかし、それでもドッグフーディングが重要であると言えるのはユーザーとそのプロダクトについてリアリティを持って共感できる方法だからです。特に、ユーザーのストーリーを持って使うことが重要です。それは機能するということ以上に課題を解決したいという意図を持って使うということです。ストーリーを持ってプロダクトを使うことってどういうことだろうと思ったのであれば、次に紹介するストーリーマッピングを合わせて実行してみると良いかもしれません。 ### ストーリーマッピング ストーリーマッピングは、ユーザーの行動と感情をフェーズごとにまとめる手法です。この手法は「カスタマージャーニマップ」と呼ばれていることも多いです。対象がカスタマー(顧客)に限らないため、ウォンテッドリーではストーリーマッピングという呼び名が一般的です。 この手法ではユーザーが見ているプロダクトの状態とユーザーの心境を時系列でグラフィカルに表現します。実践的な手法としては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につながっていきます。このプロセスではユーザーに自分自身の情報を入力してもらえないかと考えてみると良いです。 ## 定量的アプローチ よく使う分析の型として、ステップ分解、セグメント分割、コホート分析を紹介し、あわせて分析の組み立て方と陥りやすい落とし穴をまとめます。最後に、これらの分析を加速させる手段としてAIの活用を扱います。 ### ステップ分解 問題となっているユーザー行動が複数のステップに分解できるのであれば分解してみましょう。ここで言うステップとはトラッキング可能なユーザーの最小行動です。多くの場合はクリックやスクロールといったユーザーアクションです。最初に想定した課題で大幅に離脱しているかどうかを確認します。他にも大幅に離脱しているポイントがないか、直感的におかしな箇所がないかを見つけます。こうしたステップと各ステップの通過率をまとめたものはファネルと呼ばれます。ファネルにすると、どのステップで離脱が集中しているかが一目でわかります。どんなステップに分解できるかを考えるときは、前述のCREATEアクションファネルが手がかりになります。 ### セグメント分割 問題だと思ったユーザー行動は、特定のユーザーセグメントだけで起きている可能性もあります。もしユーザーセグメント(例えば、ユーザーは学生である、など)が仮定できるのであれば、検証してみる価値があります。ただ、あまりにも小さなセグメントで起きている可能性があるときは注意が必要です。計測結果はノイズが多く偶然起きている可能性が高くなり、改善できたとしても影響が限定されます。 ### コホート分析 同じ起点(例えば、登録した週が同じ、初めて特定機能を使った週が同じ、など)を共有するユーザーの集団をコホートと呼びます。コホートごとに時間経過に沿った行動を追うと、単純な合計値では見えない変化が見つかります。特に、施策や外部要因の前後で「新しく入ってきたユーザー」と「以前からいるユーザー」の振る舞いを混ぜずに比較できるのが利点です。時間の経過とともにどれだけのユーザーが利用を続けているか(リテンション)を見るときにも、このコホートの考え方を使います。継続率の裏返しである解約(チャーン)率や、コホートがNヶ月後にどれだけ残っているかという生存率も、同じ枠組みで捉えられます。ただし、コホートを細かく切りすぎるとセグメント分割と同様にノイズが増えるため、意味のある粒度に留めましょう。 ### 分析の組み立て方 1つの定量分析は、おおむね次の順序で進めると手戻りが少なく解釈もぶれにくくなります。 1. **指標の定義を固める**: 何を1件と数えるのか、どのデータを正解とするのかを最初に決めます。定義が曖昧なまま数字を出すと、後述の「結果の想定」で触れる数字いじりに陥りやすくなります。ウォンテッドリーではBI上の指標定義を Looker (LookML) に集約しているため、既存の指標の意味は [Looker 入門](https://docs.wantedly.dev/fields/data/looker) で、テーブルがどこから来たデータかは [データ基盤入門](https://docs.wantedly.dev/fields/data/data-infra) で確認できます。 2. **対象を絞り、現状を掴む**: 分析する期間・セグメント・母集団(分母)を決め、まずは分布や代表値で現状を把握します。 3. **セグメント軸で層別する**: 前述のセグメントやコホートの切り口で数字を分け、特定の集団だけで起きている現象かどうかを確かめます。 4. **時系列で変化を見る**: 月次推移や前年同月比(YoY)で、変化とその大きさを確認します。季節性の扱いは後述の「前後比較」も参考になります。 5. **事実と解釈を分けてまとめる**: 「結果(事実)」と「考察(解釈)」を分けて示唆を書きます。後述の「効果検証/学習」の「考察をする」で述べる、結果と考察を分けて書くのと同じ考え方です。 ### 分析の落とし穴 定量分析では、集計そのものは正しくても解釈を誤らせる罠がいくつかあります。代表的なものを挙げます。 * **生存者バイアス**: 「今も残っているユーザー/企業」だけを見ると、すでに離脱した対象が抜け落ち、実態より良く見えることがあります。特に解約分析では、離脱した対象を母集団に含められているかを確認します。 * **過去の属性の取り違え**: ユーザーや企業の属性(プランや所属など)は時間とともに変わります。今は有料プランの企業でも、分析対象の当時は無料プランだったかもしれません。過去を振り返るときは、現在の属性ではなく当時の属性で結びつけます。 * **計測単位の不一致**: 同じ「募集の閲覧」でも、イベント数で数えるかユニークユーザー数で数えるかで数字は大きく変わります。特にファネルは、あるステップを表示回数、次のステップをユーザー数で数えると通過率が意味を持ちません。比較する数字の間で単位を揃えます。 * **公平な比較**: 期間を比べるときは経過日数を揃えます(月の途中同士を比べるなら同じ経過日数で比較する)。また、複数の期間やセグメントをまたいで全体のユニークユーザー数を求めるときは、単純合算せず重複を除いて数えます。 * **ロジック変更による不連続点**: 推定モデルや集計ロジックが途中で変わると、その前後で数字が不連続になります。時系列で見るときは変更の前後を分けて解釈します。 ### AI を活用した定量分析 定量的アプローチの弱点は「発散させると分析コストの割に情報が得られない」点にありました。AIはこの**探索のコスト**を下げてくれます。つまり「定性/定量 × 探索/検証」のフレームで言うと、AIは定量的アプローチが苦手としてきた探索型の使い方を現実的にしてくれるツールです。ただし、AIの役割はあくまで**分析の加速と仮説の量産**です。どの仮説を検証するか、結果をどう意思決定に使うかという責任は人間に残ります。 **AIが効く場面** 前述の分析の型に対応づけると、AIは次のような場面で効きます。いずれも、指標の定義・対象セグメント・期間・プロダクトの前提といった文脈を明示的に渡すほど出力の質が上がります。また、まず広く出させてから人間が絞り込むこと、出てきた仮説がトラッキング可能な最小行動の粒度まで落ちているかを確認することが重要です。 * 集計・分析の実行補助: 自然言語で依頼するとクエリの作成だけでなく実行・集計まで任せられ、試行回数を増やせます。ステップ分解でファネルを組むときにも向いています。社内ではDevinを使ってこの用途を運用しています。安全に任せるには、AIが参照できるデータを個人情報を含まない集計済みのテーブルに絞っておくことが前提です。 * 異常・離脱ポイントの発見候補出し: 大幅に離脱しているステップや、直感的におかしな箇所の候補を挙げてもらう。ステップ分解で「見つけるべき箇所」の初期リストになります。 * セグメント探索: 人間が思いつかない切り口のセグメントを提案してもらう。セグメント分割の幅が広がります(小さすぎるセグメントに注意する原則はそのままです)。 * 仮説の発散: ある数字に対する解釈の候補を複数出させ、検証すべき仮説リストの初期案にする。 **注意点・落とし穴** AIは探索を速くするぶん、誤った方向にも速く進めてしまいます。前述の「分析の落とし穴」に、AIを使うと踏みやすい罠が加わると考えてください。 * ハルシネーション / 数字の捏造: AIは実在しない数字やそれらしい集計結果を出すことがあります。意思決定に使う数字は必ず一次データで裏取りしてください。 * 前提の見落としを加速する: AIは生存者バイアスや当時の属性(前述)を意識せずにクエリを書くことがあります。出てきた集計が、含めるべき対象や正しい時点を踏まえているかを人間が確認します。 * 相関と因果の取り違え: AIが挙げるのは「相関しそうな仮説」に過ぎません。効果はA/Bテストや対照群付きの比較で検証します。単純な前後比較しかできない場合は、季節性や外部要因などの限界を明記し、因果効果と断定しません(詳しくは後述の「評価方法」)。 * 「数字いじり」(p-hacking)の加速: 切り口を無限に試せるようになるぶん、後から都合の良い有意な指標を探すことに陥りやすくなります。だからこそ、後述の「結果の想定」で述べる、指標と成功/失敗の閾値を事前に決めておくことがより重要になります。 * 再現性: AIとの対話は同じ問いでも出力が揺れます。意思決定に使った分析は、手順や実際に叩いたクエリを残し、後から再現できるようにしてください。 ## 解決方法の考案 課題発見で見つけた課題から解決方法を考えて施策としてまとめていきます。施策にはリスト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モデルなどさまざまなモデルがあり、機会があれば試してみると新しい発見につながります。定量分析ではステップ分解、セグメント分割、コホート分析といった型を使います。AIは探索を速くしますが、検証と意思決定は人間が担うことが重要です。解決方法の考案では、解決方法、価値仮説、結果の想定、評価方法、優先度指標の項目に分解してまとめていきます。優先度判断では、ICEスコアをつかってチームで効果的だと思える施策から取り組めるようにします。実験をした後の効果検証/学習では結果と考察を分けて述べます。考察では失敗しても成功しても学びを深めます。このように施策を回していけば、必ず次の施策につながります。サイクルを回せば回すほどチームの集合知が高まっていき効率良く改善できているのを感じるでしょう。この漸進的な活動こそが改善フェーズにおけるプロダクトマネージメントです。全てのエンジニアがプロダクトマネージメントに興味を持ってもらい、ぜひどんどんチャレンジしてもらえたら嬉しいです。 #### 話を聞きに行きたい * Slack: [#product\_management](https://wantedly.slack.com/archives/C01SYNKAC3W), [#products\_products](https://wantedly.slack.com/archives/C028QUT3NQ7)