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

Web担当者Forumミーティング2024春　B2-1オープニング基調講演

Transcript

1. その失敗から何を学ぶ？ 不確実性をマネジメントして 目標達成するための心得 飯沼亜紀
2. Aki Iinuma 飯沼亜紀 Head of Product Design / Product Manager, CADDi Inc. 𝕏: @LoveIdahoBurger 経歴 ソフトウェア開発企業 経営企画→新規事業のプロダクトマネージャー アパレル企業 プロダクトマネージャー、プロジェクトマネージャー、新規事業 飲食企業 プロダクトマネージャー 2022年9月よりキャディのプロダクトマネージャー やっていること オペレーションとテクノロジーの両方を使って世の中を良い方向に 変えていこうとしている
3. © CADDi Inc. © CADDi Inc. About CADDi
4. © CADDi Inc. サプライチェーンにまつわる上流‧下流のデータを相互に補完し合う キャディとは：サプライチェーン変⾰のパートナー 部品調達プラットフォーム 調達‧⽣産機能の⼀括 請け負いによる モノづくりの変⾰ 図⾯データ活⽤クラウド 図⾯データの アセット化による 社内システムの変⾰ 設計 調達 製造 販売 Technology Knowledge
5. © CADDi Inc. 承認フロー 権限コントロール バージョン管理 etc 主要機能 CADDi Drawer ＝ 図⾯データ活⽤クラウド 図⾯ etc.. 品質 設計 ⾒積 受注 発注 図⾯を 貯める 検索する 情報を 抜きだす 情報を 関連づける ⾏動する 分析する CADDi Drawer 図⾯を中⼼とした データ‧ナレッジを 活⽤して未来に⽣かす 図⾯解析 キーワード/類似検索 関連データの⾃動紐付 etc 主要機能 ⽬的 ⼀般的な図⾯管理 システムの対象範囲 過去の図⾯データを 正しく保存する ⽬的
6. なぜ私が今日ここにいるのか Web担当者ForumになぜSaaSの開発をしているプロダクトマネージャーが？ Webやアプリの設計・UXの構築、キャンペーンの運用にもプロダクトマネジメントのアプ ローチは応用できるという仮説を持っている そして、まだプロダクトマネジメントに詳しい人が多くない
7. Agenda 01 02 03 04 プロダクトマネジメントの考え方を適用する 失敗とは何か 小さな失敗から学ぶ ステークホルダーとの コミュニケーション
8. 01 プロダクトマネジメントの考え方を適用する
9. プロダクトマネジメントとは プロダクトマネジメントとは • User （顧客、市場） • Business（事業） • Technology（技術） の3要素の交差領域に立ち プロダクトを成功に導くための あらゆるいとなみ User Business Technology
10. プロダクトマネジメントとプロジェクトマネジメント プロジェクト プロダクト 期限がある 特に期限がない （一部例外を除く） プロダクトの改善活動としてプロジェクトをリードした経験がある人も多いはず • ウェブサイトのリニューアル • アプリの新機能開発 などはプロダクト（ウェブサイト、アプリ）における改善プロジェクト活動 プロジェクト プロジェクト プロジェクト プロダクトの継続的な成長のための活動
11. ぶっ飛んだアイディアを早く実現することより、奇をてら わずよく検証されたアイディアを実現することが重要に 構築そのもののハードルが低くなり「構築できる会社 が強い」から「いかに手早く価値に到達できるか」の世 界へ 最近のWebまわりの潮流 前提： Web・アプリ・キャンペーンはデジタル依存度が高く「構築」「仮説検証」と切り離せない 外部環境：生成AI・ノーコードツールの普及 • 仮説を検証し続けること　　　　　　　　　 • 開発効率性（無駄なものを作らない）の追求 　　　　　　　　　　の重要性が増している 業界内の環境：ベストプラクティスの飽和 本日のキーワードは仮説検証です。
12. 02 失敗とは何か
13. X億円をつぎ込んだ 大規模プロジェクトの末 に リリースしたアプリが 鳴かず飛ばず
14. この失敗の何がいけないのか • 取り返しがつかない（ここからの逆転 が難しい） • リスク許容度を超えている
15. 人は常に成功への道を知っているわけではない 失敗はつきもの 重要なのは失敗しないことではなく 最終的に大きな成功を掴むこと 失敗しても引き返せるようにするためには 早く小さく失敗することが重要 ダメだったら 引き返せばいい
16. プロダクトマネジメントとは プロダクトマネジメントとは • User （顧客、市場） • Business（事業） • Technology（技術） の3要素の交差領域に立ち プロダクトを成功に導くための あらゆるいとなみ User Business Technology
17. 特に避けたい失敗とは何か 　失敗の定義： 　計画どおりに物事が進まない 　目標を達成できない 　ネガティブな影響が発生する　 etc. 　この中でも特に避けたい失敗： 　次に繋がる学習ができない状態 　誰にも使われない 　これまでと同じ要因での成功・失敗 　得た知見が活用できない　 etc. この状態で突っ走ると大きな失敗に繋がる 小さな失敗をプロセスの一部に組み込む ことが 大切（これが仮説検証） 影響の大小により 大きな失敗・小さな失敗に分類
18. いろんな人の要望に応 えまくっていたら、 尖 っ ていたはずのキャン ペーンが 丸くなっちゃった
19. 今日覚えてほしいこと 仮説立案 検証・振り返り 土台としての組織文化： • ステークホルダーとのコミュニケーション • 学習を続ける文化の推進 • 仮説設定 • スコープの限定 • 優先順位付け • 検証と分析 • フィードバック
20. 今日本当に覚えてほしいこと 仮説立案 検証・振り返り
21. 03 小さな失敗から学ぶ
22. なぜ小さい単位で仮説検証をするのか リスクの低減 01 小さな単位で仮説検証を行うことで失敗の影響を最小限に抑える 例）大規模キャンペーン実施前に小規模なターゲットグループでテストを実施 する 迅速な フィードバック 02 フィードバックを迅速に得ることができ学習サイクルが早まる 例）限定的な機能で素早くリリースし短期間で結果を評価する コスト効率の向上 03 小規模な仮説検証によりコストを低く抑える 例）プロトタイプを限定顧客に対して提供し低コストで顧客の反応を確認する 軌道修正の しやすさ 04 計画外の結果に柔軟に対応する 例）うまくいかなかったものをすぐに取りやめ新たな仮説を立てて次の検証に 移る 学習の積み上げ 05 学習の累積により最終成果に向けて確度の高い結論に達する 例）A/Bテストを継続的に実施しWebサイトのUXを改善し続ける（次のリ ニューアルへの学びとする） 検証のしやすさ 06 変数を少なくすることで成否の要因を特定しやすくする 例）特定の要素を個別にテストしその影響を明確にしてから次に進む
23. クソデカ仮説検証を小さく分解した例 MAU ◯千万のアプリに　　　　　　　　　　　　新たなコア機 能を搭載したい！ いきなりそんな巨大機能を 追加するなんて怖くてできない 天の声 社内テスト オペレーション影響確認（仮想店舗） 最低限のUXフィードバック Closed Beta 地域限定 テスト リリース 機能の不足がないか確認 オペレーション影響確認（実店舗） （アップデートを繰り返しつつ徐々に対象地域を拡大し最終的に全国へ） 負荷試験結果の検証 マーケティング施策の売上影響確認 この期間に徐々に検証項目を検証 • コールセンター負荷確認 • イレギュラーオペレーション確認 • 機能追加の社内コミュニケーション • 地域を絞ったCMの配信 テスト期間中はテスト専用アプリで運用
24. 今日本当に覚えてほしいこと 仮説立案 検証・振り返り
25. 今日本当に覚えてほしいこと 仮説立案 検証・振り返り
26. 仮説を設定する 現状 目標 現状と目標とのギャップを埋める手段の仮説を 考える 仮説 = 検証可能な予測・推測 仮説の構成要素： • 条件 ◦ どのような状況・環境で検証 するか • 結果 ◦ どのような結果が期待されるか • 測定方法 ◦ どのように結果を測定・評価 するか 仮説：新しいメールキャンペーンを実施すると、流入数 が10%増加する 条件：ターゲットリストに対して週に 1回、3週間連続で メールを送る 結果：流入数が10%以上増加する 測定方法：メール開封率と流入数のデータを分析する
27. 検証のスコープを限定する 検証スコープ = 仮説を検証する際に対象とする範囲や条件 スコープを限定する重要性： • 変数の管理 ◦ 複数の変数を同時に扱うとどの要因が結 果に影響を与えたかわかりにくくなるため 変数を管理する • 効率的なリソース利用 ◦ 限られたリソースを効率的に活用する • リスクの最小化 ◦ 小さなスコープで失敗の影響を最小化 する 　仮説を絞る 　一度に検証する仮説の数を減らし、 　個別の検証を行う 　対象を絞る 　特定のターゲットグループや市場セグメ 　ントに限定して検証する 　時間軸を絞る 　短時間での検証により迅速にフィード 　バックを得る
28. クソデカ仮説検証を小さく分解した例 MAU ◯千万のアプリに　　　　　　　　　　　　新たなコア機 能を搭載したい！ いきなりそんな巨大機能を 追加するなんて怖くてできない 天の声 社内テスト オペレーション影響確認（仮想店舗） 最低限のUXフィードバック Closed Beta 地域限定 テスト リリース 機能の不足がないか確認 オペレーション影響確認（実店舗） （アップデートを繰り返しつつ徐々に対象地域を拡大し最終的に全国へ） 負荷試験結果の検証 マーケティング施策の売上影響確認 この期間に徐々に検証項目を検証 • コールセンター負荷確認 • イレギュラーオペレーション確認 • 機能追加の社内コミュニケーション • 地域を絞ったCMの配信 テスト期間中はテスト専用アプリで運用
29. 今日本当に覚えてほしいこと 仮説立案 検証・振り返り
30. 仮説に優先順位をつけて検証を実施し、得 られたデータを分析します
31. 検証結果のフィードバックをする ユーザーの行動 データやフィードバッ クなど データ収集 重要インサイトの抽 出 データ分析 結果に基づき改善 策を実行 アクション 改善策の結果を評 価し次のサイクルに 反映 評価 フィードバックループの構築 • 目標設定：改善したい具体的な目標や KPIを 設定する。 • データ収集計画の策定 ：どのデータをどのよ うに収集するか計画する。 • 定期的なデータ収集 ：設定した計画に基づい てデータを収集する。 • データの分析とインサイトの抽出 ：収集した データを分析し、改善のためのインサイトを 得る。 • 改善策の実施：得られたインサイトに基づい て具体的な改善策を実施する。 • 結果の評価とフィードバック ：改善策の効果を 評価し、次のフィードバックループに反映す る。
32. 04 ステークホルダーとのコミュニケーション
33. 今日覚えてほしいこと 仮説立案 検証・振り返り 土台としての組織文化： • ステークホルダーとのコミュニケーション • 学習を続ける文化の推進 • 仮説設定 • スコープの限定 • 優先順位付け • 検証と分析 • フィードバック
34. いろんな人の要望に応 えまくっていたら、 尖 っ ていたはずのキャン ペーンが 丸くなっちゃった
35. 何をやらないかを決めることの重要性 なぜ「何をやらないか」を決めるのか？ リソースの最適化：限られたリソースを最大限に活用するためには、全てのアイデアを実 現するわけにはいかない→優先順位を付け、重要なことに集中することが必要 フォーカスの維持：会社やプロダクトのビジョンやミッションに沿ったことに集中することで、 ブレない方向性を保つ 市場のニーズに応える：顧客のニーズや市場の要求に的確に応えるためには、不要なも の（＝わかりにくさの原因）を省き、価値の高いものを提供することが重要
36. Noを伝える話について詳しくはこちら https://speakerdeck.com/aki_iinuma/nowochuan-eruji-shu-number-pmconf2021 Speakerdeckで「Noを伝える技術」で検索してください ⭐pmconf2021 　参加者アンケート 　満足度1位セッション🎖 ⭐Speakerdeck 　2021年に最も読まれたスライド 　トップ10入り🎖 ※前職時代に作成した資料です
37. 出典：Amazon 要望を全て叶えるということ コンパクトにまとまったツール群 コンパクトにまとまったツール群
38. 誰も悪意を持っていないし個別に見れば効果的なものもある プロダクトの進化を願って要望をあげるケースがほとんどで、個別に見るとリーズナブル なものが多いしROIも出るかもしれないが… よさそう = やるべき？
39. できることの多さは必ずしもプロ ダクトの価値と 直結しない 出典：Amazon
40. でもYesと言うのはNoの何倍も容易 だめです え？？？ わたし ステークホルダー というわけでこ れをやろう え？？？ わたし プロダクトチーム 比較的遠い関係性 比較的近い関係性 ステークホルダーよりもチームからネガティブなリアクションを受けるほうが 気分的に楽 →全てにYesと言いチームの敵になりながら全て実現するのが最も楽かもしれない
41. こちらの立場を理解してもらうためのステップ 相手の話をよく聞く 「ずっと言ってるのにちゃんと話を聞いてくれない」 を防ぐ どのような価値があるかについての 共通理解を持つ 「ちゃんと理解していないくせに断られた」 を防ぐ これを実現するために必要なコストについて 説明する 「簡単な話なのにやってくれない」を防ぐ 共感する・可能であれば数値化する 費用以外のトレードオフもコストとみなす 内容が予測できてもまず聞く姿勢を見せる ここまでのステップで依頼者が要求を取り下げることはよくある
42. Noと思ったらまずNotで考える 正しい課題 正しくない課題 Not Now 今じゃない • 他に優先順位が高 いものがある • 開発の前提条件が 揃っていない など Not That Way その方法じゃない • 提案されたWhyは 正しいがWhatや Howはもっと良いも のがありそう • 技術的に対応でき ないので workaroundを考え る必要がある など Not This Project このプロダクトじゃない • このプロダクトでは なく別のプロダクト に対する変更で対 応するべき問題 • そもそも開発が必 要ではないかも など Not Aligned with the Vision ビジョンと合ってない • プロダクトや会社の ビジョンや戦略と合 致していない • お客様のために なっていない など
43. 正しい課題にはポジティブなNoを 正しい課題 正しくない課題 Not Now 今じゃない ◦月に着手できます / ◦◦が終わった後にやりま す Not That Way その方法じゃない ◦◦という方法はどうです か？ Not This Project このプロダクトじゃない ◦◦プロダクトによる解決 がよさそうです Not Aligned with the Vision ビジョンと合ってない これははっきりNoと言っ たほうがいい場合が多い ここで相手が鈍感力を発揮してきたらはっきりと Noと言う
44. まとめ 仮説立案 検証・振り返り 土台としての組織文化： • ステークホルダーとのコミュニケーション • 学習を続ける文化の推進 • 仮説設定 • スコープの限定 • 優先順位付け • 検証と分析 • フィードバック
45. まとめ 仮説立案 検証・振り返り
46. Thank you!