peer-quest.connpass.com
に参加してきたのでメモ。
投稿時点で公開されていた資料は記載しましたが、順次追記予定です。
個別最適のSaaSと上手く向き合うプロダクトロードマップ
- プロダクトロードマップとは
- 「やることリスト」ではなく「ありたい姿」への最短ルート
- 2軸で伝える「ありたい姿」
- 将来プロダクトが実現していたいユーザーの姿を描いた「よげんの書」
- 提供したい価値を抽象化したプロダクトビジョン
- ロードマップの策定
- 具体化するフェーズと抽象化するフェーズを行き来する
- 事業計画を因数分解し、優先順位を付ける
- やらないことを明確に
- バリュープロポジション内でも優先順位を決める
- ロードマップの課題とそれに対する運用
- 関係者が多く、プロダクトの在り方や目指す姿、最新のロードマップがわからない
- 最新のロードマップの場所を固定化し、月1回の全部署誰でも参加可能な議論タイムを設けた
- プロダクトが大きくなり、異なる目標を追いかけるチームの要望をうまく扱う必要が出てきた
- セールス・CSそれぞれバックログを分けた
- POがそこから実際に取り扱う順番を決めている
- 関係者が多く、プロダクトの在り方や目指す姿、最新のロードマップがわからない
エンタープライズSaaSの初期成長戦略
- POが思い描く世界観を実現したい顧客を探す
- 通常の受託開発とは異なることを理解してもらう
- 個別要求に答える場合もある
- 汎用的な機能はSaaSに取り込む
- 個社に特化したものはあくまで機能外のものとする
- 一旦個社の機能として対応してから汎用機能化する場合などもある
- 個別要求に答える場合もある
- 通常の受託開発とは異なることを理解してもらう
急成長なフェーズでの成長戦略
- ロードマップで実現したいことはコンテキストで変わる
- 未来予想
- 工数管理・リソースの可視化
- 計画を立てて機会損失をなくす
- ロードマップ文化が定着した背景
- メンバーが増えたことで難しくなった事業・部署間連携のため
- ビジネスチームが売りたいものとエンジニアが作りたいものが乖離していた
- 成長ファクターが一部の人間に集中し、リスクとなっていた
- 新規開発、追加開発、改善や技術的負債回収のいずれかによって異なるスケジュール感
- メンバーが増えたことで難しくなった事業・部署間連携のため
- ロードマップ作成の流れ
- 達成するべき売上・リリース日がトップダウンで決まる
- 事業課題を小課題に分解し、コスト計算
- ステークホルダーとの意思決定、スケジュールの打診
- Qが始まる3ヶ月前から、Qの開始から半年分のロードマップを引き始める
- 20%のバッファを設けた状態で引く
- 運用時に出た課題
- 差し込みが入って進まない
- 予想可能なものはロードマップに組み込む
- 予測不能なものはその内容によっていくつかの対応がある
- 次に同じことが起きた場合に備えたドキュメント化
- バッファを一定設けておく
- マイルストーンやスケジュールが引けない
- はじめてだと精度は50%くらい
- 実際に発生した工数を管理して運用しながら精度をあげる
- ある程度の係数を設けて見積もる
- 複数人で見積もりをする
- 差し込みが入って進まない
アルプのロードマップ変遷
- 仮説検証フェーズではロードマップはあまり参照されなかった
- 半年くらいの目標はあったが、顧客のニーズに合わせて変化していた
- 追いかけるための目標としての信頼感がなかった
- エンジニアはあまり気にしていなかった
- 作ってみないとわからないフェーズではロードマップよりもなぜ作るのか？が知りたい
- 半年くらいの目標はあったが、顧客のニーズに合わせて変化していた
- プロダクトの方向性が定まった上で、それを伝える手段としてのプロダクトビジョン
- プロダクトビジョンからトップダウンでロードマップを決める
- 組織間でプロダクトビジョンを達成するための共通認識としてのロードマップ
- ハイインテグリティーコミットメント
- わかる/できる前に求めない
- 誠実な時期を伝えるための情報収集・整理
- 開発チームに驚きがない状態で方針を決める
- できるだけ納期はコミットしない
- コミットメントを小さく、納得感のあるサイズにする
- わかる/できる前に求めない
感想
- プロダクトのビジョンとロードマップの接続がわかりやすいかで組織の納得感が変わってきそう
- 組織が方向性を揃えて連携するためのロードマップ
- 現在のビジョン・ロードマップから未来の姿を思い描けているか？
- 必要としているロードマップのコンテキストについてあまり意識したことはなかった
- 複数のコンテキストを統合して1枚のロードマップとして表現する場合もありそう
- ロードマップの精度を上げるために開発に提供してほしい情報はどういうものなんだろう
- 予測不能なものから予想可能なものを切り出して、わからないものを小さくするとか
- やはり実工数の計測は必要かもしれない
- 仮説検証フェーズでのロードマップは引いても気にされないし、信頼もされないのはなんとなくわかる
