Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
アンラーニングし続けるプロダクトマネジメント
Search
Yusuke Hisatsu
December 14, 2023
Business
2
940
アンラーニングし続けるプロダクトマネジメント
2023/12/14開催の「プロダクトマネジメント 先達に倣う実践事例 Lunch LT」で登壇した際のスライドです
https://findy.connpass.com/event/303778/
Yusuke Hisatsu
December 14, 2023
Tweet
Share
More Decks by Yusuke Hisatsu
See All by Yusuke Hisatsu
チームで盛り上げる ファシリテーション
yusukehisatsu
19
13k
新卒者向け資料_タスクマネジメント・ドキュメンテーション
yusukehisatsu
0
450
心理的安全性を0から80ぐらいに上げた話
yusukehisatsu
1
750
プロダクトのための地味な動き - 地味PM meetup
yusukehisatsu
7
9.2k
システム思考とプロダクトマネジメント
yusukehisatsu
21
17k
JobsToBeDone/ジョブ理論をまとめてみた
yusukehisatsu
6
6.9k
幅広い経験を活かして PdMになった話@Kiitok meetup
yusukehisatsu
0
260
エンジニアチームビルディングジャーニー
yusukehisatsu
0
540
心理的安全性の高いチームを作ってみた
yusukehisatsu
2
540
Other Decks in Business
See All in Business
イークラウド会社紹介 ~挑戦で、つながる社会へ~
ecrowd
1
3.5k
拝啓、登壇回数0回だった一年前の私へ
natty_natty254
4
160
イグニション・ポイント フォース株式会社/エントランスBook_2025
ignitionpointhr
1
1.6k
「なんとなく使いにくい」を論理的に説明する方法 〜プロダクトエンジニアとしてUXを議論できる第一歩〜
mkitahara01985
0
400
採用ピッチ資料/エアモビリティ株式会社
airmobility_jinji
0
2.2k
セーフィー株式会社(Safie Inc.) 会社紹介資料
safie_recruit
6
370k
【ウェビナー資料】プロダクト組織の成長を定量で可視化するには
muture
PRO
0
110
技術的負債に立ち向かう、 ひとりから始めるチームづくり / From One to Team: Building Momentum Against Technical Debt
yoshiyoshifujii
1
190
EMOOR_ブランド説明資料
yusawada
1
11k
「みんな、笑顔になぁれ」を実現する 職種混合開発組織の目標設定・評価の改善事例
daitasu
0
160
『ふりかえる力』を育み、メンバーの自走力を高める 1 on 1 / 1-on-1 sessions to foster self-reflection
tbpgr
1
860
株式会社ボスコ・テクノロジーズ 採用ピッチ資料
boscotechrecruit
0
1.4k
Featured
See All Featured
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.4k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Mobile First: as difficult as doing things right
swwweet
223
9.9k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
33
2.4k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3k
The Invisible Side of Design
smashingmag
301
51k
Designing for Performance
lara
610
69k
Balancing Empowerment & Direction
lara
2
590
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
900
Designing for humans not robots
tammielis
253
25k
We Have a Design System, Now What?
morganepeng
53
7.7k
jQuery: Nuts, Bolts and Bling
dougneiner
64
7.9k
Transcript
アンラーニングし続ける プロダクトマネジメント @Findy Lunch LT 株式会社グロービス Globis Digital Platform Director
of Product 久津佑介
2 自己紹介 久津 佑介 / Yusuke Hisatsu 株式会社グロービス Globis Digital
Platform 学習サービス事業部 Director of Product @Nunerm プロダクトマネージャーカンファレンス実行委員会もやってます
3 今日話したいこと プロダクトマネジメントにおいて 常に自分たちに疑いの目を向けて、 「その時の正解」を見つけられるようになろう
4 これまでのPMキャリア リクルートテクノロジーズ CAMPFIRE GLOBIS Phase1 GLOBIS Phase2 GLOBIS Phase3
合理的 カオス 決める 整える ↑こういう感じで歩んできたよ、という話をします
5 リクルート:合理的プロセス推進と「数字で決める」 リクルートテクノロジーズ CAMPFIRE GLOBIS Phase1 GLOBIS Phase2 GLOBIS Phase3
• 巨大組織で合理的な文化 • 事業は成熟期でKGI/KPIが明確 • 基本的にソフトウェアプロダクト経験値が高い • 決められたプロセスを早く確実に進める • 時にはプロセスをハックする 前提 意思決定 プロセス 意思決定の 根拠 コミュニ ケーション • KPIに基づく数字やファクトを多用 • 組織が大きすぎて現場には降りられないので、 報告されやすくするために責任の明確化 • しっかり納得させるレポーティング
6 CAMPFIRE:合理的プロセス推進と「数字で決める」…? リクルートテクノロジーズ CAMPFIRE GLOBIS Phase1 GLOBIS Phase2 GLOBIS Phase3
• 新規事業で何も定まっていない • 10人程度の組織 • ソフトウェアプロダクト経験がない人も多い 前提 • 決められたプロセスを早く確実に進める • 時にはプロセスをハックする 意思決定 プロセス 意思決定の 根拠 コミュニ ケーション • KPIに基づく数字やファクトを多用 • 組織が大きすぎて現場には降りられないので、 報告されやすくするために責任の明確化 • しっかり納得させるレポーティング
7 問題解決のためにやったこと • プロダクトロードマップをビジュアライズしてチームへ浸透させた • ユーザーインタビューを100回行って課題を抽出 • ユーザーストーリーマッピングを行い課題を体系化 • データ分析基盤を作ってダッシュボードを量産し、データドリブンで意思決定
• リリース前にA/Bテストを必ず行い、成果への確実性を上げた • アジャイルコーチを呼んで開発プロセスの再構築 無事に解決! 全然あきまへん
8 CAMPFIRE:カオスのまま前に進める リクルートテクノロジーズ CAMPFIRE GLOBIS Phase1 GLOBIS Phase2 GLOBIS Phase3
• 新規事業で何も定まっていない • 10人程度の組織 • ソフトウェアプロダクト経験がない人も多い • プロセスは全く気にしない • プロセスを合理化する時間も勿体無いので、曖 昧なまま進める 前提 意思決定 プロセス 意思決定の 根拠 コミュニ ケーション • 不確実性が高すぎて数字は根拠にならないた め、まず動いてファクトを取りに行く • 基本的に意見も合わないし噛み合わないので、 完璧な合意形成を目指さない • 納得させることを諦める
9 GLOIBS Phase1:これまでの経験の集大成だ…!? リクルートテクノロジーズ CAMPFIRE GLOBIS Phase1 GLOBIS Phase2 GLOBIS
Phase3 • 5つの開発チームが大規模スクラムを実施 • (それ以外はよくわかってない) • カオスのまま進めながら、合理的なプロセスを 作りあげるぞ! 前提 意思決定 プロセス 意思決定の 根拠 コミュニ ケーション • すぐリサーチしてファクトベースの意思決定を する土壌を作るぞ! • 効率的なコミュニケーションフローを作るぞ!
10 問題解決のためにやったこと • プロダクトロードマップをビジュアライズしてチームへ浸透させた • ユーザーインタビューを100回行って課題を抽出 • ユーザーストーリーマッピングを行い課題を体系化 • データ分析基盤を作ってダッシュボードを量産し、データドリブンで意思決定
• リリース前にA/Bテストを必ず行い、成果への確実性を上げた • アジャイルコーチを呼んで開発プロセスの再構築 無事に解決! 何も上手くいかん
11 GLOIBS Phase1:チーム間のハブ役に徹する リクルートテクノロジーズ CAMPFIRE GLOBIS Phase1 GLOBIS Phase2 GLOBIS
Phase3 • チームのサイロ化により、意思決定基準の乱発 • 事業側の要望 vs 技術的負債解消 の対立構造 • 意思決定のプロセスよりも、情報量を揃えるプ ロセス作り 前提 意思決定 プロセス 意思決定の 根拠 コミュニ ケーション • とにかく前に進むこと • 成功体験が積めるもの(信頼関係の構築) • とにかく話を聞いて状況を理解し、必要な人に うまく伝達する • 球を拾いまくる
12 GLOIBS Phase2:任せる リクルートテクノロジーズ CAMPFIRE GLOBIS Phase1 GLOBIS Phase2 GLOBIS
Phase3 • チームのサイロ化問題は解決し新体制に • チャレンジングな中長期の事業目標を設定 • 久津は全体を見るDoPの役割に • 各PMが担当領域の中で意思決定し、各々の判断 で調整・報告するプロセス 前提 意思決定 プロセス 意思決定の 根拠 コミュニ ケーション • ユーザーの本質的な価値になっているかどうか • リサーチや分析など多くの情報を扱って決める • 積極的に権限委譲をして、自身はビジョンを語 る人 + 最終的に決める人に
13 問題解決のためにやったこと • プロダクトロードマップをビジュアライズしてチームへ浸透させた • ユーザーインタビューを100回行って課題を抽出 • ユーザーストーリーマッピングを行い課題を体系化 • データ分析基盤を作ってダッシュボードを量産し、データドリブンで意思決定
• リリース前にA/Bテストを必ず行い、成果への確実性を上げた • アジャイルコーチを呼んで開発プロセスの再構築 無事に解決! 半年でダメダメに
14 GLOIBS Phase3:基準を作る リクルートテクノロジーズ CAMPFIRE GLOBIS Phase1 GLOBIS Phase2 GLOBIS
Phase3 • 目標が曖昧すぎて目線がバラバラに • 意思決定の根拠が多すぎて目線がバラバラに • プロセスの更なる合理化 • 「乗り越えるべき適度な壁」を作る 前提 意思決定 プロセス 意思決定の 根拠 コミュニ ケーション • 数字で語れるものにフォーカスし単純化 • 目線が合っているところは任せる • 目線が合っていないところは積極的に介入し、 落ち着いたら離れる
15 これまでやってきたこと 環境や状況が変わって 何かがうまくいかなくなったら 躊躇わずに今までのやり方を捨てて見直す
16 問題解決のためにやったこと • プロダクトロードマップをビジュアライズしてチームへ浸透させた • ユーザーインタビューを100回行って課題を抽出 • ユーザーストーリーマッピングを行い課題を体系化 • データ分析基盤を作ってダッシュボードを量産し、データドリブンで意思決定
• リリース前にA/Bテストを必ず行い、成果への確実性を上げた • アジャイルコーチを呼んで開発プロセスの再構築 無事に解決! そんなに簡単にやり方を変えられるの?
17 問題解決のためにやったこと • プロダクトロードマップをビジュアライズしてチームへ浸透させた • ユーザーインタビューを100回行って課題を抽出 • ユーザーストーリーマッピングを行い課題を体系化 • データ分析基盤を作ってダッシュボードを量産し、データドリブンで意思決定
• リリース前にA/Bテストを必ず行い、成果への確実性を上げた • アジャイルコーチを呼んで開発プロセスの再構築 無事に解決! めちゃくちゃ大変です
18 どうやって変えるべきことを見つける? • システム思考 ◦ とにかく組織やプロダクトを俯瞰で見て、現状把握を徹底的に行う ◦ 基本的には現場への執拗なヒアリングと構造化の繰り返し ▪ 例:Value
Stream Mapping • 常識・定番を疑う ◦ 世の中で常識・定番となっているものが、今最適なものなのか疑ってみる ◦ 「そもそも我々はそれを活用する準備は整っているのか?」という問いを立てる ▪ 例:データドリブン、JTBD、アジャイル、会議を減らすなど • 他者評価をもらう ◦ 「自分達のプロダクトマネジメントを他者に深掘りしてもらう」は効果的 ◦ もし「うまくいかないことに対する言い訳」をしたら潜在的な改善ポイント
19 どうやって変えるべきことを見つける? https://www.kandc.com/eng/interview/029/
20 どうやって新しいやり方を見極める? • トライアンドエラー ◦ まずは小さくやって素早く評価する ◦ うまくいかなかったら素直に「ごめんなさい」&「次はこうしよう」 • 人の意見を鵜呑みにしすぎず、最後は自分の意思で決める
◦ メンバーやステークホルダーの要望は必ずしも全て叶える必要はない ◦ 正しく見極めるには、判断基準や引き出しを増やす必要はあるので、やはり 日々の情報収集や学習は大事 ◦ 全て1人で抱え込む必要はなく、頼れるプロフェッショナルがいるなら頼る ▪ 「現場に詳しいプロフェッショナルには全力で頼れ」 ▪ 「現場に詳しくないプロフェッショナルの話は聞くな」
21 どうやって新しいやり方を見極める?
22 自己否定の恐怖を乗り越える • 数ヶ月前に決めた方針を変えるのは確かに怖い(無能だと思われる恐怖) • そんな時は「気にしない」のが一番 • 「あのPMダメだな」と思われても、その後プロダクトが良くなれば忘れる • 書籍「プロダクトマネージャーのしごと」より
◦ 守りの姿勢(=自分のやり方に固執すること)に入ってはいけない ◦ だからといって自己卑下をしてもいけない(誰もついてこなくなる) • 「一度決めたら自信を持て、同時に疑いも持て、そして変える勇気も持て」
23 今日話したいこと(再掲) プロダクトマネジメントにおいて 常に自分たちに疑いの目を向けて、 「その時の正解」を見つけられるようになろう
24 宣伝 今日話したような感じで GLOBISのプロダクト開発は まだまだ発展途上です 視点を変えると、もっと良くなる余地があります このような環境で「学びの未来」を作りたい PMやエンジニアを絶賛募集中です!