Upgrade to Pro — share decks privately, control downloads, hide ads and more …

アウトカム志向な組織になるためのプロダクトオーナーの取り組み / RettyBeerBash#8

Retty
January 25, 2022

アウトカム志向な組織になるためのプロダクトオーナーの取り組み / RettyBeerBash#8

2022/01/25にオンライン開催した自社イベントのスライドです
https://retty.connpass.com/event/234373/

Retty

January 25, 2022
Tweet

More Decks by Retty

Other Decks in Business

Transcript

  1. 大規模スクラム(LeSS)
 15 BackLog SM Engineer Engineer めいじ SM Engineer Engineer

    きりん SM Engineer Engineer ももてん SM Engineer Engineer はらみ PO=VPoP PM Planner Designer デジタル マーケティング PM Planner Designer 投稿体験 PM Planner Designer ネット予約 PM Planner Designer 飲食店向け プロダクト部門 エンジニアリング部門 WhatとWhyに責任を持つ Howに責任を持つ 全員で ユーザーに価値を届ける プロダクトバックログを作る Feature Team (上記含め全5チーム) User Story Team (上記含め全5チーム)
  2. LeSSにおけるPM組織の概観
 16 Retty飲食店事業 開発 to B:お店さん向け to C:ユーザーさん ネット予約 投稿・コミュニティ

    カスタマーサポート PM ロードマップ バックログ ロードマップ バックログ Manager 決定者 PO 決定者 PO 承認者 Planner PM Planner マーケティング PM Planner
  3. 4. PMの育成
 2021年 アウトカム志向な組織になるためにうまくいった話
 17 2. リファインメントが
 良くなった
 1. アウトカムが共通言語に


    3. 試行錯誤中だが、
 ロードマップを作り始めた
 5. 進め方おかしくない?
 の振り返りができるように

  4. PM内で工数見積もりしてもらうことが目的化し、開発物が洗練されていない中で見積もりを依頼される エンジニアとPMが険悪なムードに。 工数見積もりを行わないと開発ラインに載せるこ とができないため、開発物を洗練することよりも工 数を見積もることが目的化。 PMの状況 ① 必要性 解決するべき問題なのか わからない

    ② 妥当性 最適な解決策なのか わからない ③ 実現性  最適な詳細要件なのか わからない PMは急いで見積もりを要求するが、実際は上記い ずれかのパターンで認識が揃わず、見積もりの段 階にまでに到達できない。 認識が合わない3つのパターン 絶対見積もりして もらうぞ!! 2. リファインメントがよくなった (課題編)
  5. 問題整理& 解決策の検討 仕様書を書く 施策相談 ←ここが工夫ポイント 施策相談や仕様書を書く前に、問題の整理や解 決策を広く検討する。 解決するべき問題の必要性や解決策の妥当性を 整理することに注力。 ①

    必要性 解決するべき問題の定義 ② 妥当性 最適な解決策の導き方 ③ 実現性  最適な詳細要件なのか わからない 施策相談の前段階の準備 工夫した準備ポイント 2. リファインメントがよくなった (解決編)
  6. 社内でのロードマップ目線合わせスライド • 売上目標・プロダクトビジョンを実現するためのロードマップ ◦ 毎週のゴール→Qのゴール→通期のゴール • 適宜必要に応じて、見直しを行っていく • 事業・ビジネスとして、リリース日を約束するものではなく、 目線合わせするためのもの

    • 1イテレーションの中で完結する小規模の施策・運用・不具合対応は バックログの中で都度判断していく • ターゲットに対して提供価値は異なるので、 ターゲット毎に実現したいゴールを定めていく • 検証の結果プロセスが異なる場合もあるので、 マイルストーンよりゴールを重視する
  7. Retty PMスキル 5大要素を定義し、各要素の下に2〜3の小スキル要素が紐づく形式。 各スキル要素(横)×グレード(高さ)を作り、評価に組み込む。 5つのPMスキル ディスカバリー力 意思決定 推進力 最後の砦 英知

    ・開発のWhyとWhatを明確にするための仮説検証力 問いを立てる力 / 検証設計力 / 検証実行力 ・課題を突破するための意思決定 判断材料の準備力 / 優先度判断力 / ロードマップ構築力 ・信頼を受けながら、周りを巻き込み、推進する Ready力 / リリースマネジメント力 / 合意形成力 ・プロダクトを守る最後の砦 リスク管理力 / 障害対応力 ・課題を的確に発見し、周りを巻き込むことができる ユーザー・マーケット理解・ Rettyに関する知識 / 開発知識 / 設計・デザイン力
  8. 32 5. 進め方おかしくない?が言えるようになった PMがWhy〜Howまで全てビジネス側とまとめて しまっているため、より良いHowを議論する余地 が少なかった。実装段階で揉めることも、、、 Why PMが中心となってまとめる What PMエンジニアと相談しながらまと

    める How エンジニアが中心となってまとめ る PMはWhy&Whatを中心に。Howはエンジニアが 中心でまとめるようになることになり、この課題に 対してこの打ち手はおかしくない?という話が事前 にできるようになった 過去(2,3年くらい前) 現在 Why PMが中心となってまとめる What PMが中心となってまとめる How PMが中心となってまとめる ※たまにエンジニアに相談する
  9. 2022年 これからRettyが頑張りたい話
 33 4. 顧客解像度を高め、
 Rettyを外食業界に
 再PMFする
 2. 何だかんだ2〜3に
 分離していたバックログ


    ついに一本化
 1. 営業も含めた
 全社アジャイル組織
 売れるプロダクトを新たに創って いく
 
 3. 大規模PJを少なくして
 ディスカバリーしたい
 5. こんなPMを採用したい

  10. 35 大規模PJを少なくしてディスカバリーしたい ずっと規模感の大きいPJをやっている =ディスカバリーがおざなりに、、、 Go To Eat対応 6ヶ月 ネット予約 PayPayボーナス付与

    3ヶ月 請求システムの新規機能 6ヶ月 広告ロジック改修 4ヶ月 直近のPJ 工数 お店管理画面リニューアル 1年6ヶ月 ネット予約バックエンド システムのリニューアル 1年9ヶ月
  11. 37 取り組みの背景 開発要望を もらう 必要な機能の 判断が できない なんでも 開発する 受託開発ループ

    要望を作ることが目的化してしまうので アウトカムどころじゃない!! プロダクトのあ るべき状態が ない プロダクトディスカバリーに時間を避けなていなかったため、常にアウトカムが不明瞭な 要件定義の無限ループ プロダクトの あるべき状態を 考えられない