その失敗から何を学ぶ？不確実性をマネジメントして目標達成するための心得 #webtan

by Aki / @LoveIdahoBurger

Slide 1

Slide 1 text

その失敗から何を学ぶ？不確実性をマネジメントして目標達成するための心得飯沼亜紀

Slide 2

Slide 2 text

Aki Iinuma 飯沼亜紀 Head of Product Design / Product Manager, CADDi Inc. 𝕏: @LoveIdahoBurger 経歴ソフトウェア開発企業経営企画→新規事業のプロダクトマネージャーアパレル企業プロダクトマネージャー、プロジェクトマネージャー、新規事業飲食企業プロダクトマネージャー 2022年9月よりキャディのプロダクトマネージャーやっていることオペレーションとテクノロジーの両方を使って世の中を良い方向に変えていこうとしている

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

© CADDi Inc. 承認フロー権限コントロールバージョン管理 etc 主要機能 CADDi Drawer ＝図⾯データ活⽤クラウド図⾯ etc.. 品質設計⾒積受注発注図⾯を貯める検索する情報を抜きだす情報を関連づける⾏動する分析する CADDi Drawer 図⾯を中⼼としたデータ‧ナレッジを活⽤して未来に⽣かす図⾯解析キーワード/類似検索関連データの⾃動紐付 etc 主要機能⽬的⼀般的な図⾯管理システムの対象範囲過去の図⾯データを正しく保存する⽬的

Slide 6

Slide 6 text

なぜ私が今日ここにいるのか Web担当者ForumになぜSaaSの開発をしているプロダクトマネージャーが？ Webやアプリの設計・UXの構築、キャンペーンの運用にもプロダクトマネジメントのアプローチは応用できるという仮説を持っているそして、まだプロダクトマネジメントに詳しい人が多くない

Slide 7

Slide 7 text

Agenda 01 02 03 04 プロダクトマネジメントの考え方を適用する失敗とは何か小さな失敗から学ぶステークホルダーとのコミュニケーション

Slide 8

Slide 8 text

01 プロダクトマネジメントの考え方を適用する

Slide 9

Slide 9 text

プロダクトマネジメントとはプロダクトマネジメントとは ● User （顧客、市場） ● Business（事業） ● Technology（技術）の3要素の交差領域に立ちプロダクトを成功に導くためのあらゆるいとなみ User Business Technology

Slide 10

Slide 10 text

プロダクトマネジメントとプロジェクトマネジメントプロジェクトプロダクト期限がある特に期限がない（一部例外を除く）プロダクトの改善活動としてプロジェクトをリードした経験がある人も多いはず ● ウェブサイトのリニューアル ● アプリの新機能開発などはプロダクト（ウェブサイト、アプリ）における改善プロジェクト活動プロジェクトプロジェクトプロジェクトプロダクトの継続的な成長のための活動

Slide 11

Slide 11 text

ぶっ飛んだアイディアを早く実現することより、奇をてらわずよく検証されたアイディアを実現することが重要に構築そのもののハードルが低くなり「構築できる会社が強い」から「いかに手早く価値に到達できるか」の世界へ最近のWebまわりの潮流前提： Web・アプリ・キャンペーンはデジタル依存度が高く「構築」「仮説検証」と切り離せない外部環境：生成AI・ノーコードツールの普及 ● 仮説を検証し続けること　　　　　　　　　 ● 開発効率性（無駄なものを作らない）の追求　　　　　　　　　　の重要性が増している業界内の環境：ベストプラクティスの飽和本日のキーワードは仮説検証です。

Slide 12

Slide 12 text

02 失敗とは何か

Slide 13

Slide 13 text

X億円をつぎ込んだ大規模プロジェクトの末にリリースしたアプリが鳴かず飛ばず

Slide 14

Slide 14 text

この失敗の何がいけないのか ● 取り返しがつかない（ここからの逆転が難しい） ● リスク許容度を超えている

Slide 15

Slide 15 text

人は常に成功への道を知っているわけではない失敗はつきもの重要なのは失敗しないことではなく最終的に大きな成功を掴むこと失敗しても引き返せるようにするためには早く小さく失敗することが重要ダメだったら引き返せばいい

Slide 16

Slide 16 text

Slide 17

Slide 17 text

特に避けたい失敗とは何か　失敗の定義：　計画どおりに物事が進まない　目標を達成できない　ネガティブな影響が発生する　 etc. 　この中でも特に避けたい失敗：　次に繋がる学習ができない状態　誰にも使われない　これまでと同じ要因での成功・失敗　得た知見が活用できない　 etc. この状態で突っ走ると大きな失敗に繋がる小さな失敗をプロセスの一部に組み込むことが大切（これが仮説検証）影響の大小により大きな失敗・小さな失敗に分類

Slide 18

Slide 18 text

いろんな人の要望に応えまくっていたら、尖っていたはずのキャンペーンが丸くなっちゃった

Slide 19

Slide 19 text

今日覚えてほしいこと仮説立案検証・振り返り土台としての組織文化： ● ステークホルダーとのコミュニケーション ● 学習を続ける文化の推進 ● 仮説設定 ● スコープの限定 ● 優先順位付け ● 検証と分析 ● フィードバック

Slide 20

Slide 20 text

今日本当に覚えてほしいこと仮説立案検証・振り返り

Slide 21

Slide 21 text

03 小さな失敗から学ぶ

Slide 22

Slide 22 text

なぜ小さい単位で仮説検証をするのかリスクの低減 01 小さな単位で仮説検証を行うことで失敗の影響を最小限に抑える例）大規模キャンペーン実施前に小規模なターゲットグループでテストを実施する迅速なフィードバック 02 フィードバックを迅速に得ることができ学習サイクルが早まる例）限定的な機能で素早くリリースし短期間で結果を評価するコスト効率の向上 03 小規模な仮説検証によりコストを低く抑える例）プロトタイプを限定顧客に対して提供し低コストで顧客の反応を確認する軌道修正のしやすさ 04 計画外の結果に柔軟に対応する例）うまくいかなかったものをすぐに取りやめ新たな仮説を立てて次の検証に移る学習の積み上げ 05 学習の累積により最終成果に向けて確度の高い結論に達する例）A/Bテストを継続的に実施しWebサイトのUXを改善し続ける（次のリニューアルへの学びとする）検証のしやすさ 06 変数を少なくすることで成否の要因を特定しやすくする例）特定の要素を個別にテストしその影響を明確にしてから次に進む

Slide 23

Slide 23 text

クソデカ仮説検証を小さく分解した例 MAU ◯千万のアプリに　　　　　　　　　　　　新たなコア機能を搭載したい！いきなりそんな巨大機能を追加するなんて怖くてできない天の声社内テストオペレーション影響確認（仮想店舗）最低限のUXフィードバック Closed Beta 地域限定テストリリース機能の不足がないか確認オペレーション影響確認（実店舗）（アップデートを繰り返しつつ徐々に対象地域を拡大し最終的に全国へ）負荷試験結果の検証マーケティング施策の売上影響確認この期間に徐々に検証項目を検証 ● コールセンター負荷確認 ● イレギュラーオペレーション確認 ● 機能追加の社内コミュニケーション ● 地域を絞ったCMの配信テスト期間中はテスト専用アプリで運用

Slide 24

Slide 24 text

今日本当に覚えてほしいこと仮説立案検証・振り返り

Slide 25

Slide 25 text

今日本当に覚えてほしいこと仮説立案検証・振り返り

Slide 26

Slide 26 text

仮説を設定する現状目標現状と目標とのギャップを埋める手段の仮説を考える仮説 = 検証可能な予測・推測仮説の構成要素： ● 条件 ○ どのような状況・環境で検証するか ● 結果 ○ どのような結果が期待されるか ● 測定方法 ○ どのように結果を測定・評価するか仮説：新しいメールキャンペーンを実施すると、流入数が10%増加する条件：ターゲットリストに対して週に 1回、3週間連続でメールを送る結果：流入数が10%以上増加する測定方法：メール開封率と流入数のデータを分析する

Slide 27

Slide 27 text

検証のスコープを限定する検証スコープ = 仮説を検証する際に対象とする範囲や条件スコープを限定する重要性： ● 変数の管理 ○ 複数の変数を同時に扱うとどの要因が結果に影響を与えたかわかりにくくなるため変数を管理する ● 効率的なリソース利用 ○ 限られたリソースを効率的に活用する ● リスクの最小化 ○ 小さなスコープで失敗の影響を最小化する　仮説を絞る　一度に検証する仮説の数を減らし、　個別の検証を行う　対象を絞る　特定のターゲットグループや市場セグメ　ントに限定して検証する　時間軸を絞る　短時間での検証により迅速にフィード　バックを得る

Slide 28

Slide 28 text

Slide 29

Slide 29 text

今日本当に覚えてほしいこと仮説立案検証・振り返り

Slide 30

Slide 30 text

仮説に優先順位をつけて検証を実施し、得られたデータを分析します

Slide 31

Slide 31 text

検証結果のフィードバックをするユーザーの行動データやフィードバックなどデータ収集重要インサイトの抽出データ分析結果に基づき改善策を実行アクション改善策の結果を評価し次のサイクルに反映評価フィードバックループの構築 ● 目標設定：改善したい具体的な目標や KPIを設定する。 ● データ収集計画の策定：どのデータをどのように収集するか計画する。 ● 定期的なデータ収集：設定した計画に基づいてデータを収集する。 ● データの分析とインサイトの抽出：収集したデータを分析し、改善のためのインサイトを得る。 ● 改善策の実施：得られたインサイトに基づいて具体的な改善策を実施する。 ● 結果の評価とフィードバック：改善策の効果を評価し、次のフィードバックループに反映する。

Slide 32

Slide 32 text

04 ステークホルダーとのコミュニケーション

Slide 33

Slide 33 text

Slide 34

Slide 34 text

いろんな人の要望に応えまくっていたら、尖っていたはずのキャンペーンが丸くなっちゃった

Slide 35

Slide 35 text

何をやらないかを決めることの重要性なぜ「何をやらないか」を決めるのか？リソースの最適化：限られたリソースを最大限に活用するためには、全てのアイデアを実現するわけにはいかない→優先順位を付け、重要なことに集中することが必要フォーカスの維持：会社やプロダクトのビジョンやミッションに沿ったことに集中することで、ブレない方向性を保つ市場のニーズに応える：顧客のニーズや市場の要求に的確に応えるためには、不要なもの（＝わかりにくさの原因）を省き、価値の高いものを提供することが重要

Slide 36

Slide 36 text

Noを伝える話について詳しくはこちら https://speakerdeck.com/aki_iinuma/nowochuan-eruji-shu-number-pmconf2021 Speakerdeckで「Noを伝える技術」で検索してください ⭐pmconf2021 　参加者アンケート　満足度1位セッション🎖 ⭐Speakerdeck 　2021年に最も読まれたスライド　トップ10入り🎖 ※前職時代に作成した資料です

Slide 37

Slide 37 text

出典：Amazon 要望を全て叶えるということコンパクトにまとまったツール群コンパクトにまとまったツール群

Slide 38

Slide 38 text

誰も悪意を持っていないし個別に見れば効果的なものもあるプロダクトの進化を願って要望をあげるケースがほとんどで、個別に見るとリーズナブルなものが多いしROIも出るかもしれないが… よさそう = やるべき？

Slide 39

Slide 39 text

できることの多さは必ずしもプロダクトの価値と直結しない出典：Amazon

Slide 40

Slide 40 text

でもYesと言うのはNoの何倍も容易だめですえ？？？わたしステークホルダーというわけでこれをやろうえ？？？わたしプロダクトチーム比較的遠い関係性比較的近い関係性ステークホルダーよりもチームからネガティブなリアクションを受けるほうが気分的に楽 →全てにYesと言いチームの敵になりながら全て実現するのが最も楽かもしれない

Slide 41

Slide 41 text

こちらの立場を理解してもらうためのステップ相手の話をよく聞く「ずっと言ってるのにちゃんと話を聞いてくれない」を防ぐどのような価値があるかについての共通理解を持つ「ちゃんと理解していないくせに断られた」を防ぐこれを実現するために必要なコストについて説明する「簡単な話なのにやってくれない」を防ぐ共感する・可能であれば数値化する費用以外のトレードオフもコストとみなす内容が予測できてもまず聞く姿勢を見せるここまでのステップで依頼者が要求を取り下げることはよくある

Slide 42

Slide 42 text

Noと思ったらまずNotで考える正しい課題正しくない課題 Not Now 今じゃない ● 他に優先順位が高いものがある ● 開発の前提条件が揃っていないなど Not That Way その方法じゃない ● 提案されたWhyは正しいがWhatや Howはもっと良いものがありそう ● 技術的に対応できないので workaroundを考える必要があるなど Not This Project このプロダクトじゃない ● このプロダクトではなく別のプロダクトに対する変更で対応するべき問題 ● そもそも開発が必要ではないかもなど Not Aligned with the Vision ビジョンと合ってない ● プロダクトや会社のビジョンや戦略と合致していない ● お客様のためになっていないなど

Slide 43

Slide 43 text

正しい課題にはポジティブなNoを正しい課題正しくない課題 Not Now 今じゃない ○月に着手できます / ○○が終わった後にやります Not That Way その方法じゃない ○○という方法はどうですか？ Not This Project このプロダクトじゃない ○○プロダクトによる解決がよさそうです Not Aligned with the Vision ビジョンと合ってないこれははっきりNoと言ったほうがいい場合が多いここで相手が鈍感力を発揮してきたらはっきりと Noと言う

Slide 44

Slide 44 text

まとめ仮説立案検証・振り返り土台としての組織文化： ● ステークホルダーとのコミュニケーション ● 学習を続ける文化の推進 ● 仮説設定 ● スコープの限定 ● 優先順位付け ● 検証と分析 ● フィードバック