- Alp開発日誌 Day10 「開発手法史2020」 https://blog.kaelae.la/entry/2020/12/14/094532 - ビジネスとプロダクトの意思決定の共通基盤、プロダクトビジョンを設定した話 https://note.com/sakaguchithealp/n/n77486a9e7e1b - 「超」 自律性を追求してプロダクトチームを分割した話 https://note.com/showmant/n/nc74e7a119352
アルプのロードマップ変遷
View Slide
Maekawa Yuichi@_kaelaelaSoftware EngineerProduct [email protected]ツイートしてね: #開発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