プロダクトのための 地味な動き @地味PM meetup 株式会社グロービス Globis Digital Platform CPO/PM 久津佑介

2 自己紹介 久津 佑介 / Yusuke Hisatsu 株式会社グロービス Globis Digital Platform 学習サービス事業部 CPO 兼 法人開発チーム PM @Nunerm プロダクトマネージャーカンファレンス実行委員会もやってます（今年もがっつり計画中）

3 今日話したいこと 「PMがやるべきこと」ではなく 「プロダクトのためにやるべきこと」に フォーカスしよう

4 プロダクト開発の当時の状況 学習サービス 事業部 事業 開発 国内toC 国内toB 海外toC/toB コンテンツ 決済 受講者体験 法人 組織の特徴 ● 事業と開発でチーム分けの軸が異なる ＝コミュニケーションパスが複雑 ● 一部を除き、事業チームから依頼する/ される関係が残る CPO PM 開発依頼

5 法人開発チームの当時の問題 Discovery ● ユーザーの解決すべき課題の解像度が粗い ● ユーザーストーリーが整理されておらず、思いつきドリブン ● データよりステークホルダーの経験や主観で優先度が決まる Delivery ● リリースした機能でなかなか成果が出ず、その原因もわからない ● 期待される開発パフォーマンスが出ず、リリースペースが遅い 解決に向けてアクション！　

6 問題解決のためにやったこと Discovery ● ユーザーインタビューを100回行って課題を抽出 ● プロダクトロードマップをビジュアライズしてチームへ浸透 ● データ分析基盤とダッシュボードを作り、データドリブンで意思決定 Delivery ● リリース前にA/Bテストを必ず行い、成果への確実性向上 ● デュアルトラックアジャイルを導入しリリースへのリードタイム短縮 無事に解決！　

7 問題解決のためにやったこと ● プロダクトロードマップをビジュアライズしてチームへ浸透させた ● ユーザーインタビューを100回行って課題を抽出 ● ユーザーストーリーマッピングを行い課題を体系化 ● データ分析基盤を作ってダッシュボードを量産し、データドリブンで意思決定 ● リリース前にA/Bテストを必ず行い、成果への確実性を上げた ● アジャイルコーチを呼んで開発プロセスの再構築 無事に解決！ うそです

8 実際に問題解決のためにやったこと Discovery ● 他チームのNotionページを全探索＆インデックス作り ● カスタマーサクセスチームとの定期ミーティング設定＆明るいファシリ ● アジェンダを日英併記ルール策定 ● 経営会議に参加するために上司に根回し Delivery ● 全チケットと突発的に発生するタスクのトラッキング＆グルーピング ● 一部のタスクをやらない理由を資料にまとめてプレゼン＆根回し ● 他開発チームのミーティングやランチに乱入して状況把握

9 問題解決のためにやったこと ● プロダクトロードマップをビジュアライズしてチームへ浸透させた ● ユーザーインタビューを100回行って課題を抽出 ● ユーザーストーリーマッピングを行い課題を体系化 ● データ分析基盤を作ってダッシュボードを量産し、データドリブンで意思決定 ● リリース前にA/Bテストを必ず行い、成果への確実性を上げた ● アジャイルコーチを呼んで開発プロセスの再構築 無事に解決！ 地味

10 なぜ地味なことばかり行なったのか？ 問題の原因の大半がこの２つであることがわかったから 　①周りとの情報の格差 　②役割定義の曖昧さ 例：ユーザーの解決すべき課題の解像度が粗い →カスタマーサクセスが持っているユーザーに関する貴重な情報がシェアされていなかった →これを無視してゼロからリサーチしても時間の無駄だし、サクセスと一枚岩になれず価値を最大化できない →まずは一致団結できる関係性づくりと情報の透明性を！ 例：期待される開発パフォーマンスが出ず、リリースペースが遅い →単純にやることが多かった →チームの役割定義が曖昧だったので、隙間にあるこぼれ球がガンガン投げられる →まずは役割の再定義をし集中できる環境づくりを！

11 実際に問題解決のためにやったこと Discovery ● 他チームのNotionページを全探索＆インデックス作り ● カスタマーサクセスチームとの定期ミーティング設定＆明るいファシリ ● アジェンダを日英併記ルール策定 ● 経営会議に参加するために上司に根回し →周りの情報を取りやすくする動き Delivery ● 全チケットと突発的に発生するタスクのトラッキング＆グルーピング ● 一部のタスクをやらない理由を資料にまとめてプレゼン＆根回し ● 他開発チームのミーティングやランチに乱入して状況把握 →「やらない」の説得力を上げて周りにパスしやすくする動き

12 どう考えているか

13 どう考えているか

14 問題解決のためにやったこと ● プロダクトロードマップをビジュアライズしてチームへ浸透させた ● ユーザーインタビューを100回行って課題を抽出 ● ユーザーストーリーマッピングを行い課題を体系化 ● データ分析基盤を作ってダッシュボードを量産し、データドリブンで意思決定 ● リリース前にA/Bテストを必ず行い、成果への確実性を上げた ● アジャイルコーチを呼んで開発プロセスの再構築 無事に解決！ それはPMがやるべきことなの？

15 問題解決のためにやったこと ● プロダクトロードマップをビジュアライズしてチームへ浸透させた ● ユーザーインタビューを100回行って課題を抽出 ● ユーザーストーリーマッピングを行い課題を体系化 ● データ分析基盤を作ってダッシュボードを量産し、データドリブンで意思決定 ● リリース前にA/Bテストを必ず行い、成果への確実性を上げた ● アジャイルコーチを呼んで開発プロセスの再構築 無事に解決！ 知らん

16 プロダクトのために誰かがやるべきことではある こういう地味な仕事は、プロダクトの価値を最大化するために必要になる場合がある ただ、面白くないし直接的な成果も見えづらいから誰もやりたがらない それが「PMがやるべきこと」かどうかは知らない でも誰もやる人がいないなら自らやった方がいい なぜならPMは「プロダクトの価値の最大化に誰よりもコミットする人」だと思うから

17 今日話したいこと（再掲） 「PMがやるべきこと」ではなく 「プロダクトのためにやるべきこと」に フォーカスしよう

18 宣伝 このような取り組みもあり GLOBISのプロダクト開発組織は 目に見えて成長しています ただ、まだまだ課題も多いしPMも足りません 一緒に「学びの未来」を作りませんか まずはカジュアル面談しましょう！ Twitterで「久津 PM」と検索したら出てきます→