アンラーニングし続けるプロダクトマネジメント

2023/12/14開催の「プロダクトマネジメント 先達に倣う実践事例 Lunch LT」で登壇した際のスライドです
https://findy.connpass.com/event/303778/

Transcript

1. アンラーニングし続ける プロダクトマネジメント @Findy Lunch LT 株式会社グロービス Globis Digital Platform Director of Product 久津佑介
2. 2 自己紹介 久津 佑介 / Yusuke Hisatsu 株式会社グロービス Globis Digital Platform 学習サービス事業部 Director of Product @Nunerm プロダクトマネージャーカンファレンス実行委員会もやってます
3. 3 今日話したいこと プロダクトマネジメントにおいて 常に自分たちに疑いの目を向けて、 「その時の正解」を見つけられるようになろう
4. 4 これまでのPMキャリア リクルートテクノロジーズ CAMPFIRE GLOBIS Phase1 GLOBIS Phase2 GLOBIS Phase3 合理的 カオス 決める 整える ↑こういう感じで歩んできたよ、という話をします
5. 5 リクルート：合理的プロセス推進と「数字で決める」 リクルートテクノロジーズ CAMPFIRE GLOBIS Phase1 GLOBIS Phase2 GLOBIS Phase3 • 巨大組織で合理的な文化 • 事業は成熟期でKGI/KPIが明確 • 基本的にソフトウェアプロダクト経験値が高い • 決められたプロセスを早く確実に進める • 時にはプロセスをハックする 前提 意思決定 プロセス 意思決定の 根拠 コミュニ ケーション • KPIに基づく数字やファクトを多用 • 組織が大きすぎて現場には降りられないので、 報告されやすくするために責任の明確化 • しっかり納得させるレポーティング
6. 6 CAMPFIRE：合理的プロセス推進と「数字で決める」…？ リクルートテクノロジーズ CAMPFIRE GLOBIS Phase1 GLOBIS Phase2 GLOBIS Phase3 • 新規事業で何も定まっていない • 10人程度の組織 • ソフトウェアプロダクト経験がない人も多い 前提 • 決められたプロセスを早く確実に進める • 時にはプロセスをハックする 意思決定 プロセス 意思決定の 根拠 コミュニ ケーション • KPIに基づく数字やファクトを多用 • 組織が大きすぎて現場には降りられないので、 報告されやすくするために責任の明確化 • しっかり納得させるレポーティング
7. 7 問題解決のためにやったこと • プロダクトロードマップをビジュアライズしてチームへ浸透させた • ユーザーインタビューを100回行って課題を抽出 • ユーザーストーリーマッピングを行い課題を体系化 • データ分析基盤を作ってダッシュボードを量産し、データドリブンで意思決定 • リリース前にA/Bテストを必ず行い、成果への確実性を上げた • アジャイルコーチを呼んで開発プロセスの再構築 無事に解決！ 全然あきまへん
8. 8 CAMPFIRE：カオスのまま前に進める リクルートテクノロジーズ CAMPFIRE GLOBIS Phase1 GLOBIS Phase2 GLOBIS Phase3 • 新規事業で何も定まっていない • 10人程度の組織 • ソフトウェアプロダクト経験がない人も多い • プロセスは全く気にしない • プロセスを合理化する時間も勿体無いので、曖 昧なまま進める 前提 意思決定 プロセス 意思決定の 根拠 コミュニ ケーション • 不確実性が高すぎて数字は根拠にならないた め、まず動いてファクトを取りに行く • 基本的に意見も合わないし噛み合わないので、 完璧な合意形成を目指さない • 納得させることを諦める
9. 9 GLOIBS Phase1：これまでの経験の集大成だ…！？ リクルートテクノロジーズ CAMPFIRE GLOBIS Phase1 GLOBIS Phase2 GLOBIS Phase3 • 5つの開発チームが大規模スクラムを実施 • （それ以外はよくわかってない） • カオスのまま進めながら、合理的なプロセスを 作りあげるぞ！ 前提 意思決定 プロセス 意思決定の 根拠 コミュニ ケーション • すぐリサーチしてファクトベースの意思決定を する土壌を作るぞ！ • 効率的なコミュニケーションフローを作るぞ！
10. 10 問題解決のためにやったこと • プロダクトロードマップをビジュアライズしてチームへ浸透させた • ユーザーインタビューを100回行って課題を抽出 • ユーザーストーリーマッピングを行い課題を体系化 • データ分析基盤を作ってダッシュボードを量産し、データドリブンで意思決定 • リリース前にA/Bテストを必ず行い、成果への確実性を上げた • アジャイルコーチを呼んで開発プロセスの再構築 無事に解決！ 何も上手くいかん
11. 11 GLOIBS Phase1：チーム間のハブ役に徹する リクルートテクノロジーズ CAMPFIRE GLOBIS Phase1 GLOBIS Phase2 GLOBIS Phase3 • チームのサイロ化により、意思決定基準の乱発 • 事業側の要望 vs 技術的負債解消 の対立構造 • 意思決定のプロセスよりも、情報量を揃えるプ ロセス作り 前提 意思決定 プロセス 意思決定の 根拠 コミュニ ケーション • とにかく前に進むこと • 成功体験が積めるもの（信頼関係の構築） • とにかく話を聞いて状況を理解し、必要な人に うまく伝達する • 球を拾いまくる
12. 12 GLOIBS Phase2：任せる リクルートテクノロジーズ CAMPFIRE GLOBIS Phase1 GLOBIS Phase2 GLOBIS Phase3 • チームのサイロ化問題は解決し新体制に • チャレンジングな中長期の事業目標を設定 • 久津は全体を見るDoPの役割に • 各PMが担当領域の中で意思決定し、各々の判断 で調整・報告するプロセス 前提 意思決定 プロセス 意思決定の 根拠 コミュニ ケーション • ユーザーの本質的な価値になっているかどうか • リサーチや分析など多くの情報を扱って決める • 積極的に権限委譲をして、自身はビジョンを語 る人 + 最終的に決める人に
13. 13 問題解決のためにやったこと • プロダクトロードマップをビジュアライズしてチームへ浸透させた • ユーザーインタビューを100回行って課題を抽出 • ユーザーストーリーマッピングを行い課題を体系化 • データ分析基盤を作ってダッシュボードを量産し、データドリブンで意思決定 • リリース前にA/Bテストを必ず行い、成果への確実性を上げた • アジャイルコーチを呼んで開発プロセスの再構築 無事に解決！ 半年でダメダメに
14. 14 GLOIBS Phase3：基準を作る リクルートテクノロジーズ CAMPFIRE GLOBIS Phase1 GLOBIS Phase2 GLOBIS Phase3 • 目標が曖昧すぎて目線がバラバラに • 意思決定の根拠が多すぎて目線がバラバラに • プロセスの更なる合理化 • 「乗り越えるべき適度な壁」を作る 前提 意思決定 プロセス 意思決定の 根拠 コミュニ ケーション • 数字で語れるものにフォーカスし単純化 • 目線が合っているところは任せる • 目線が合っていないところは積極的に介入し、 落ち着いたら離れる
15. 15 これまでやってきたこと 環境や状況が変わって 何かがうまくいかなくなったら 躊躇わずに今までのやり方を捨てて見直す
16. 16 問題解決のためにやったこと • プロダクトロードマップをビジュアライズしてチームへ浸透させた • ユーザーインタビューを100回行って課題を抽出 • ユーザーストーリーマッピングを行い課題を体系化 • データ分析基盤を作ってダッシュボードを量産し、データドリブンで意思決定 • リリース前にA/Bテストを必ず行い、成果への確実性を上げた • アジャイルコーチを呼んで開発プロセスの再構築 無事に解決！ そんなに簡単にやり方を変えられるの？
17. 17 問題解決のためにやったこと • プロダクトロードマップをビジュアライズしてチームへ浸透させた • ユーザーインタビューを100回行って課題を抽出 • ユーザーストーリーマッピングを行い課題を体系化 • データ分析基盤を作ってダッシュボードを量産し、データドリブンで意思決定 • リリース前にA/Bテストを必ず行い、成果への確実性を上げた • アジャイルコーチを呼んで開発プロセスの再構築 無事に解決！ めちゃくちゃ大変です
18. 18 どうやって変えるべきことを見つける？ • システム思考 ◦ とにかく組織やプロダクトを俯瞰で見て、現状把握を徹底的に行う ◦ 基本的には現場への執拗なヒアリングと構造化の繰り返し ▪ 例：Value Stream Mapping • 常識・定番を疑う ◦ 世の中で常識・定番となっているものが、今最適なものなのか疑ってみる ◦ 「そもそも我々はそれを活用する準備は整っているのか？」という問いを立てる ▪ 例：データドリブン、JTBD、アジャイル、会議を減らすなど • 他者評価をもらう ◦ 「自分達のプロダクトマネジメントを他者に深掘りしてもらう」は効果的 ◦ もし「うまくいかないことに対する言い訳」をしたら潜在的な改善ポイント
19. 19 どうやって変えるべきことを見つける？ https://www.kandc.com/eng/interview/029/
20. 20 どうやって新しいやり方を見極める？ • トライアンドエラー ◦ まずは小さくやって素早く評価する ◦ うまくいかなかったら素直に「ごめんなさい」＆「次はこうしよう」 • 人の意見を鵜呑みにしすぎず、最後は自分の意思で決める ◦ メンバーやステークホルダーの要望は必ずしも全て叶える必要はない ◦ 正しく見極めるには、判断基準や引き出しを増やす必要はあるので、やはり 日々の情報収集や学習は大事 ◦ 全て１人で抱え込む必要はなく、頼れるプロフェッショナルがいるなら頼る ▪ 「現場に詳しいプロフェッショナルには全力で頼れ」 ▪ 「現場に詳しくないプロフェッショナルの話は聞くな」
21. 21 どうやって新しいやり方を見極める？
22. 22 自己否定の恐怖を乗り越える • 数ヶ月前に決めた方針を変えるのは確かに怖い（無能だと思われる恐怖） • そんな時は「気にしない」のが一番 • 「あのPMダメだな」と思われても、その後プロダクトが良くなれば忘れる • 書籍「プロダクトマネージャーのしごと」より ◦ 守りの姿勢（＝自分のやり方に固執すること）に入ってはいけない ◦ だからといって自己卑下をしてもいけない（誰もついてこなくなる） • 「一度決めたら自信を持て、同時に疑いも持て、そして変える勇気も持て」
23. 23 今日話したいこと（再掲） プロダクトマネジメントにおいて 常に自分たちに疑いの目を向けて、 「その時の正解」を見つけられるようになろう
24. 24 宣伝 今日話したような感じで GLOBISのプロダクト開発は まだまだ発展途上です 視点を変えると、もっと良くなる余地があります このような環境で「学びの未来」を作りたい PMやエンジニアを絶賛募集中です！