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

事業とプロダクト間のインターフェース作り

 事業とプロダクト間のインターフェース作り

本当に使いこなせてる?プロダクト管理ツールの失敗&改善PMトークの際の登壇資料を改訂したスライドです。

「事業とプロダクト間のインターフェース作り」に関して、プロダクトバックログの部分での自身の取り組みについて解説した資料になります。

Daiki Suyama

May 19, 2023
Tweet

Other Decks in Technology

Transcript

  1. 事業とプロダクト間の
    インターフェース作り
    2023/05/19 改訂版
    陶山大輝

    View Slide

  2. 自己紹介
    ● 2022年4月:株式会社クライド入社
    ○ フルサイクルエンジニア:新規サービス開発など
    ● 2022年11月~
    ○ フルサイクルエンジニア:パフォーマンス改善など
    ○ DevOpsエンジニア:開発生産性向上やビジネスサイドとの連携改善など
    ○ CTO室メンバー:エンジニア向けイベントの企画や新卒採用など
    ● 2023年4月~
    ○ PdM
    ○ PO
    ○ テックリード

    View Slide

  3. 事業部の課題

    View Slide

  4. 事業部の課題
    ➔ 事業戦略がそのままプロダクト戦略になる
    ◆ プロダクト開発が自律的に動いていない
    ◆ ユーザーの解像度が上がらず、あるべき姿が描かれていない
    ➔ エンジニアサイドとビジネスサイドが分断されている
    ◆ DevOps及びビジネスサイドとの連携改善の経験
    ◆ フルサイクルエンジニアとしてプロダクトのパフォーマンス改善提案の経験

    View Slide

  5. 開発チームの役割定義

    View Slide

  6. プロダクト開発チームの役割の再定義
    ● 就任前
    ○ PO:1人
    ○ FEチーム:チームリーダー 1人+チームメンバー 2人
    ○ BEチーム:チームリーダー 1人+チームメンバー 2人
    ● 就任後
    ○ PMM:1人
    ○ PdM:1人
    ○ FEチーム:PO 1人 + テックリード 1人 + チームメンバー 1人
    ○ BEチーム:PO 1人 + テックリード 1人 + チームメンバー 1人

    View Slide

  7. PMMとPdM
    ● 前提
    ○ POと自分でPMの役割を分割する必要がある
    ○ POは営業出身で、自分はエンジニア出身
    ● 課題
    ○ 役割分割の前例が社内にないため適切な役割分割がわからず
    ● 解決策
    ○ PMMとPdMへと役割を分割し、業務を洗い出して分担する
    ■ PMM:事業成長のために売ることに責任を持つ
    ■ PdM:課題解決のために作ることに責任を持つ
    ○ 参考:PdMとPMMはどうやって協働しているか?

    View Slide

  8. POの定義
    ● 前提
    ○ リソースを増やせない
    ● 課題
    ○ チームごとのプロジェクトの進行に責任を持つ人が存在しない
    ● 解決策
    ○ 自分がPOを兼任し、チームごとのプロジェクト進行に責任を持つ
    ■ 元来のPOの定義通り、協働を意識してコミュニケーション量を増やす
    ■ いずれものチームのスプリントイベントに参加する

    View Slide

  9. PdMとPOのインターフェースとしての定義
    ● 前提
    ○ PdMとPOのどちらの役割も自分が背負う必要がある
    ○ PdM:課題解決のために作ることに責任を持つ
    ○ PO:チームごとのプロジェクト進行の責任を持つ
    ● 課題
    ○ 責任の違いはあるが、将来的な拡張性を考慮すると、役割として分割する必要がある
    ● 解決策
    ○ PdMとPOをインターフェースとして定義する
    ■ PdM:事業開発とプロダクト開発とのインターフェース
    ■ PO:プロダクト開発とエンジニアリングのインターフェース

    View Slide

  10. 解決策まとめ
    ● PMMとPdMとPOを明確な役割で定義する
    ○ PMM
    ■ 事業成長のために売ることに責任を持つ
    ■ 事業開発とプロダクト開発とのインターフェース(事業開発側)
    ○ PdM
    ■ 課題解決のために作ることに責任を持つ
    ■ 事業開発とプロダクト開発とのインターフェース(プロダクト開発側)
    ○ PO
    ■ プロダクト開発とエンジニアリングのインターフェース(プロダクト開発側)

    View Slide

  11. プロダクトバックログ

    View Slide

  12. プロダクトバックログ(前提と課題)
    ● 前提
    ○ プロダクトバックログとは開発項目を優先度順で記述したリストのこと
    ○ PdM:事業開発とプロダクト開発とのインターフェース(プロダクト開発側)
    ○ PO:プロダクト開発とエンジニアリングのインターフェース(プロダクト開発側)
    ● 課題
    ○ 開発チームとPOの把握しているバックログが異なる
    ○ それぞれの開発項目の進捗を把握するのにコミュニケーションが必要
    ○ コミュニケーション起因で情報が正確に伝わらない

    View Slide

  13. プロダクトバックログ(解決策)
    ● 考察
    ○ PdMもPOもプロダクト開発に責任を持つ役割である
    ○ プロダクト開発の状況をPdMもPOも把握できるべき
    ○ PdMは事業開発とのインターフェースで、POはエンジニアリングとのインターフェース
    ○ 別々のインターフェースであれば管理すべき情報は異なるはず
    ● 解決策
    ○ PdMとPOで管理するプロダクトバックログをそれぞれで用意する
    ○ PdMとPOで更新したものを定期的に同期させる(暫定で1週間)

    View Slide

  14. プロダクトバックログ (PdM)
    ● Project:実現したいもの
    ● Status:進行状況
    ● Category:種類
    ○ 実現したいものの種類は適切か?
    ● Idea from:発案したステークホルダー
    ○ 適切に実現したいものは分散しているか?

    View Slide

  15. プロダクトバックログ (PO)
    ● Project:開発のタスクの単位
    ○ 1~2週間程度の単位
    ● Status:進行状況
    ● Epic:JIRAのエピック
    ● PRD:仕様書

    View Slide

  16. JIRAの使い方
    ● 過去
    ○ エピックとして作られた開発項目とタスクとして作られた開発項目が混在
    ● 現在
    ○ バグ修正チケットを除き開発項目は全てエピックを作って管理
    ● 未来
    ○ プロダクトバックログの単位の明確化
    ■ プロダクトバックログ (PdM):エピックの単位
    ■ プロダクトバックログ (PO):ストーリーの単位
    ○ JIRAとスプレッドシートを連携
    ○ プロダクトバックログ (PdM)にICEスコア等の優先順位を決定する指標の導入

    View Slide

  17. 参考:Status定義
    ● 作り方
    ○ ChatGPTと仕様を検討
    ○ 運用しながら適宜ステータスを入れ替え
    ● 現状の定義
    ○ Before Preparation : エピックを未作成で、優先度を設定して保留された状態
    ○ In Preparation:優先度が設定され、実行が決定しているがPRD作成中の状態
    ○ ToDo : 優先度が設定され、実行可能であるがまだ開始されていない状態
    ○ In Progress : 実行が開始された状態
    ○ Pending : タスクに進めるための何らかの阻害要因がある状態
    ○ In Review : タスクの完了後、確認や評価を待っている状態
    ○ Done : タスクが完了し、確認や評価も完了した状態
    ○ Cancelled : タスクが中止された状態運用して変更

    View Slide

  18. まとめ

    View Slide

  19. まとめ
    ● 事業開発とプロダクト開発は適切に分離しているか?
    ● プロダクト開発チームの役割は明確に定義できているか?
    ● プロダクトバックログで適切に情報を管理できているか?

    View Slide

  20. 宣伝
    ● noteやQiitaで記事を書いています
    ● Twitterにて適宜投稿しているのでぜひ!
    ○ https://twitter.com/daiki_suyama
    ● 自分または弊社に興味のある方もぜひDMへ!

    View Slide