アルプの ロードマップ変遷

Maekawa Yuichi @_kaelaela Software Engineer Product Manager@ ツイートしてね: #開発PM勉強会

今日のお話 創業期から今までのフェーズでどのようにロードマップと関わったか こんな一例もあるという紹介です - これまでのアルプ - 課題や状態 - 開発手法やツール - これからのアルプ - チームの変化とプロダクトビジョン - ハイインテグリティーコミットメント ※注意 プロダクトマネジメントに答えはないので参考程度に受けとってください...

これまでのアルプ ロードマップ<<<開発手法

開発黎明期 - ロードマップなし！ - プロダクトオーナーという役割なし - 概念図設計とモデリング - 何を作るべきか？模索段階 ツール - Notion - Cacoo

ユースケース期 - ユーザーストーリーマッピング作成（開発優先度決め） - ユースケースのバックログ管理 - DDD(Domain Driven Design)実践 - PdM役割がゆるくできた ツール - Notion - Miro(RealTimeBoard)

スクラム開発期 - 小さな開発チームを二つで回してみた - タスクの差戻し、デザイン相談が増え混乱 - このタイミングでβ版のリリース - 作るべきものが少しずつ見えてきた - フロー効率 <リソース効率になってしまった - なぜ？を明確にするPRD書き始めた ツール - Notion - Miro - hatjitsu(プランニングポーカーツール) https://hatjitsu.toolforge.org/

カンバン開発期 - 導入社数も増え「運用/サポート」が開始 - 開発メンバーも増加(6 -> 十数名) - バックログが複数 - POレビューがとにかく大変 - PO/開発チームの間にPjMが板挟み構造 ツール - Notion - figma/figjam - JIRA

あれ... 全然ロードマップ出てこない

ざっくり半年ごとくらいの目標はあった - N月までにxxx(顧客)さんへの導入に必要な差分開発を完遂しよう！ - 都度顧客のニーズも変わるのであったとしても信頼がなかった - スケールしない＆エンジニアはあまり気にしてなかった

仮説検証時にロードマップは不要説？ 市谷 聡啓著 「正しいものを正しくつくる」より

仮説検証時にロードマップは不要説？ 市谷 聡啓著 「正しいものを正しくつくる」より この段階では作るものが根本的に変わる可能性がある アルプは開発者が多いチーム 誰もロードマップが見たいと言わなかった なぜなら、作ってみないとわからないから それよりもなぜ作るのか？を知りたがった

これからのアルプ ビジョン駆動開発

僕らのプロダクトはなんなのか？ - 最初は見えなかったプロダクトの輪郭が見えてきた - 目指しているところはどこなのか？ - メンバーが増えたときにそれを伝えていけるか？

プロダクトビジョンの策定 ビジネスとプロダクトの意思決定の共通基盤、プロダクトビジョンを設定した話 | 坂口 恵太 : https://note.com/sakaguchithealp/n/n77486a9e7e1b

ロードマップについて構造化 Product Roadmaps are Hard | C. Todd Lombardo : https://speakerdeck.com/iamctodd/product-roadmaps-are-hard

チームの変化 「超」 自律性を追求してプロダクトチームを分割した話 | Shoma Takeo https://note.com/showmant/n/nc74e7a119352

チームの分割 「超」 自律性を追求してプロダクトチームを分割した話 | Shoma Takeo https://note.com/showmant/n/nc74e7a119352

プロダクトチーム誕生(開発チーム分割)期 - 反省を踏まえてチームを分割 - PO1名/PdMも3名でチーム化 - 個々が考える「いいプロダクト」が出てくる - ビジョンからの逆算でこの方向性を揃えていく必要がある ツール - Notion - JIRA - ProductBoardの導入

WIP: 開発手法と一緒に改善中

ロードマップで組織間の共通認識を持つ

プロダクトボードでチームとオブジェクティブを一致

でも一番重要だと考えているのは...

ハイインテグリティーコミットメント - 禁断のワード: で、いつ出るの？ (コミットメント) - 問題は聞くタイミングが「早すぎる」こと 以下のことがわかる/できる前に求められがち - ビジネスとして成果を期待できますか？ - どのように作れるのですか？ - プロトタイプはできましたか？ - 品質に問題はありませんか？ - 作ったものは本当に顧客を満足させますか？ - コミットメントはなくせないが、小さくすることはできる - 納得できるコミットを INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント | マーティ・ケーガン

Thank you! - 仮説検証期間にロードマップは要らないかも - スケジュールを決めるツールではない - ロードマップはプロダクトビジョンからのトップダウン - ハイインテグリティーコミットメントするには - とにかくより誠実な時期を伝えるための情報整理と集めを行う - 開発チームに驚きがない状態で方針を決める - できるだけ納期はコミットしない Link - Alp開発日誌 Day10 「開発手法史2020」 https://blog.kaelae.la/entry/2020/12/14/094532 - ビジネスとプロダクトの意思決定の共通基盤、プロダクトビジョンを設定した話 https://note.com/sakaguchithealp/n/n77486a9e7e1b - 「超」 自律性を追求してプロダクトチームを分割した話 https://note.com/showmant/n/nc74e7a119352