図説:Showcase Gigのプロダクト開発サイクル
プロダクトマネージャーのかみゅーです。
現在働かせていただいている Showcase Gig という会社で、「プロダクト開発サイクル」を整備したので紹介したいと思います。
プロダクト開発サイクルではSmartHRさんの記事が有名です。
これを参考にして、自分たちなりのものを作っていったので…未読であれば先に読んだほうが理解が早いかも知れません
💻 プロダクトの構成
Showcase Gigは、飲食業界で「モバイルオーダー」のシステムを作っている企業です。10年以上の飲食システム開発経験を糧に、飲食システム全般のプラットフォームとなる「O:der Platform」を作り上げました。
現在のプロダクト構成は下記のようになっています。
これを開発チーム8つ、プロダクトマネージャー3人で開発しています。
「テーブルオーダーサービス」「テイクアウトサービス」として単体のプロダクトを作っていく道と比べると、「プラットフォームを作る」という道はかなり開発難易度が高く…さらに、B2B (正確にはB2B2C) の業務システムであることから、いわゆるSales Led Growthの側面も強い。
これまでは、「営業案件がきたら、必要な機能を作る」「VOCは温度感が高いものを対応」という…かなり場当たり的な対応をしてきましたが、
「SLGからPLGへ」
「VOCベースから事業戦略ベースへ」
「社内受託から強いプロダクトチームへ」
というテーマを盛り込みながら、あたらしいプロセスをつくりました。
Showcase Gigの開発サイクル
開発サイクルを下図のように整備し、運用をはじめています。
「サイクルを定義したから守らなければならない」というものではなく、
「チーム全員の頭を整理するためのツール」という立ち位置です。
画像が大きく、拡大しても見づらくてすみません
こちらのほうが見やすくなるかな
以下、4つの領域に分けて説明します。
1/ ロードマップをつくる
2/ リリーススケジュールをつくる
3/ 案件管理(プロダクトバックログ)
4/ デリバリー
🗺️ 1/ ロードマップをつくる
何をつくるか考える部分です。特徴的なのは、「事業収益」「ユーザー価値」を明確に分けているところ。
「要望(VOC)一覧」だけからロードマップを作ってしまうと、使っているユーザーは喜ぶものの…プロダクトとしての方向性が定まらず、何を目指しているのかわからなくなってきます。
そこで、プロダクトマネジメントクライテリアを参考に、"事業収益" "ユーザー価値" ("プロダクトの世界観") の軸から整理。事業収益ベースの開発テーマを重視する考え方に切り替えました。
事業収益エリア
中期経営目標/計画の策定→ 事業方針としてPhase分けするところまでをPMMとVPoPが担当し、その後各PhaseごとにPdMがそれぞれ担当を持ってプロダクト戦略を検討していきます。
Phaseごとにロードマップができます。現在は複数のPhaseを同時進行しているのでロードマップが2つできることになりますが、通常は1つ。
ロードマップ上の開発テーマ(場合によっては機能)が、「開発テーマ一覧」に集まっていきます。
弊社では、「PdMの仕事のメインはStrategy領域である」とし、
Strategic Product Manager と Technical Product Managerを分けて考えています。
ユーザー価値エリア
各所から出た要望やインタビュー結果を、VOCリストとしてまとめていきます。
「要望に機能は書くな！」というのはPdM界隈だとよく言われることですが…現実的には「○○機能が欲しい」と言われがち。我々は「ドリル/穴判別」というフェーズを設け、真因を特定できるようにしています。
その後、小さめの機能は"Product Inbox"、大きめの機能/案件は、ロードマップに入っていきます (「すでに入っている」という事が多いですが)。
直接 案件として扱うのではなく、一旦ロードマップに入れ込むというのもポイントで…その際、「その機能はどこのセグメントに必要なものなのか？」を考えることが重要です。
下記のLayerXさんのスライドのイメージが近いです。
その他エリア
事業収益/ユーザー価値以外にも、技術的負債の解消などを目的とする「テクノロジーロードマップ」や、弊社特有の事情ですが「プラットフォームに載せたい個別案件」の話が入ってきます。
開発案件は「開発テーマ」という形で一箇所に管理することで、「緊急の案件によりロードマップが崩壊する」というのを防ぐようにしています。
📅 2/ リリーススケジュールをつくる
開発テーマと、各ロードマップが出揃ったところから、各案件の精緻化とスケジューリングを行っていきます。
統合ロードマップ
プロダクトロードマップ、テクノロジーロードマップ、個別プロジェクトのスケジュールなどを集めてアラインメントしたものです。時期のコミットはなく、「ざっくりした流れ」がわかるようになっています。
ベースとなるのはプロダクトロードマップですが… Enterprise企業もターゲットに入るB2B SaaSですので、各案件の進捗状況によって 開発テーマの時期は調整することになります。
「プロダクトロードマップにあるものしかやらない。が、その中に入っているなら各機能の実装時期は調整可能」という形で、Product Led GrowthとSales Led Growthを融合させているイメージです
リリーススケジュール
"開発テーマごと"にPRDを作成します。
PRDの内容からある程度の工数感がわかってくるので、リリース日を決め、「リリーススケジュール」を作ります。「開発テーマに期日がついたものがリリーススケジュール」くらいのイメージです。
だいたい リリーススケジュールは半年間、統合ロードマップは3年間くらいのものになります。
要求仕様
PRDの作成までが PdMが主体となっていくところ。それ以降は、「プロダクトチーム」が主体になっていくところ…という考え方を採用しています。
エンジニア側のService Lead (一部はTechnical Product Manager) が「プロダクトオーナー」の役割となり、PRD(要求定義) → 要求仕様定義 → 要件定義 と進めていきます。
なお、ロールの定義はOpen Product Management Workflowで定義されている Technical Teamのものとほぼ同じです = スクラムのPOとは違います
この「要求仕様をPdM主体ではなくプロダクトチーム主体で考える」というのは、今回のプロセス整備の肝になっているところでもあります。"言われたことを迅速にやるチーム"から、"自分でやることを考えられる筋肉質なチーム" に変えていくことで、長期的に見て強い組織になっていこうとしています。
このあたりの詳細は、 弊社VPoPが書いた下記の記事を参照ください。
👩💼 3/ プロダクトバックログで管理
細分化ができたら、プロダクトバックログに起票して管理していきます。
我々の場合、一つのプロダクト案件に対し実働が複数のチームに分かれることが多いため、プロダクト用のバックログと チーム用のバックログに分けて運用しています。
この段階から、不具合タスクなども入ってきて、プロダクトオーナーの守備範囲になります。
Product Backlog と Product Inboxに分けているのは、下記のような意味をもたせているためです。
Product backlog → エンジニアが実装できる状態にあるもの / 時期が決まっているもの。プロダクトオーナーは、アサインとプロジェクトマネジメントを行う。
Product Inbox → 必要な機能だが、もう少し精緻化が必要なもの。ここの要件定義はプロダクトオーナーの仕事。
なお、ツールは、全般的にclickupを使っています。
backlogに限らず、VOCの処理やonboardingのタスクなど…このプロセスに入っている事柄は大抵のことがclickupです。
タスク管理にはclickupは優秀ですが、ドキュメントはnotionなどのほうが良さそう。
👩💻 4/ デリバリー
最後に、デリバリーの領域です。ここまで来ると、PdMが関わることはあまりなくなってきます。進め方はチームごとに少しずつ違います。
特別なことといえば、CREチームを作っていることでしょうか。
「事業収益」のための流れが最重要される…と書きましたが、VOCベースから事業戦略ベースに切り替えると、逆に既存顧客との関係性がネックになってきます。
CREは「顧客との関係性に影響が大きい課題が出てきたときに、ロードマップも関係なく、担当チームのスケジュールに入れ込む調整もせず、CREチームが直接対応する」という。
まとめ
👉ポイント
・事業戦略パートとVOCパートを分けて考えた
・ロードマップは領域ごとに複数あり、時期は強くコミットされていない。→統合ロードマップとしてまとめる
・ロードマップにより「何を作るか」は決まっているが、「いつ作るか」は案件によって調整可能
・PdMは「要求」、プロダクトチームが「要求仕様」
弊社の特殊事情が存分にはいったものではありますが、B2B SaaSプロダクトではみなさん悩むところだと思うので、参考になれば嬉しいです。
Twitterは 「1日1回なにか意識高いことを」と頑張っているのでぜひフォローお願いします🙏
Meety空けております、おしゃべりしたいだけなのでぜひお気軽にどうぞ。競合の方も歓迎します◎