スクラムにおけるプロダクトマネジメントについて考える

Transcript

1. dmatsu スクラムにおけるプロダクトマネジメントについて考える
2. 最近学んだことをベースに普段の仕事で感じたことを交え、アウトプットすること が目的です 本資料の記載内容は所属する組織・チームに関係なく、すべて個人の見解です 内容は検討中の仮説、未検証の事項を含みます 初めに
3. プロダクト及びプロダクトマネジメントについて理解する ソリューション中心・プロジェクトマネジメントのスクラムからプロダクト主体に なる方法を考える 自分の役割（スクラムマスター）として何をやるべきか考える 目的
4. スクラムガイドにはプロダクトマネジメントの記載は少ない イベントの目的が希薄化しがち 価値の検証が行われない スクラムの課題
5. スクラムガイドにはプロダクトマネジメントの記載は少ない スクラムガイドはフレームワークの記述に絞っており、 プロダクト戦略／市場発見／販売・展開の具体論は扱わない どう作ると良いかは書いてあるが、何を作ればいいか、 作るものをどのように見つけるかは書いていない 「スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、 ⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワークである。 」 スクラムの課題
6. イベントの目的が希薄化しがち イベントの目的が失われ学習が進まない 「形式を守る」ことが目的になる レビューがデモ会／進捗報告会に寄る リファインメントが「仕様詰め」だけになる スクラムの課題
7. 価値の検証が行われない 価値の検証が弱い状態でスクラムを回すと 「速く作れる」だけが強化される 高品質でも正しくないものを作る 結果として、高速かつ高品質で無駄を量産する スクラムの課題
8. 原因 意思決定の型がない（仮説／指標／検証） 検査と適応が機能していない（学習が起きない） 組織の仕組みと乖離（評価／予算／承認がアウトカムを要求しない）
9. 意思決定の型がない（仮説／指標／検証） 仮説がない（誰の、どんな課題を、どう変えるか） 指標がない（成功／失敗の判定ができない） 検証がない（作ってから祈る） → "作る"が意思決定になってしまう 原因
10. 検査と適応が機能していない（学習が起きない） 仮説／指標／検証がないので、探索と学習が行われない イベントが儀式化、決まった内容を実行するだけとなる レビューのアウトプットが「次の作業」だけに → 学習のループがない 原因
11. 組織の仕組みと乖離（評価／予算／承認がアウトカムを要求しな い） 予算・承認が「作るもの／工数／スケジュール」中心 評価が「納期／機能を出した量（アウトプット） 」中心 "指標の改善"や"作らない判断"が評価され辛い構造 原因
12. プロジェクト管理に回帰する 結果として、意思決定が慣れているかつ管理しやすい「期限と進捗」中心に回帰 する ※ プロジェクトマネジメントは不要だ！という主張ではありません。 プロジェクト・プロダクトの両輪 が必要だけど、プロジェクト優位（あるいはプロジェクト片輪）になっている点を問題視していま す。
13. プロダクトマネジメントの核 価値を最大化するための意思決定 その意思決定は、学習で更新される 学習は「正しさ」を証明するものではなく 仮説が支持／反証され 次の意思決定が変わること プロダクトマネジメントは、不確実性の中で意思決定し続けること。 「何が価値か」 「何が成功か」を仮説として置き、検証して学習し、優先順位と方針を 更新する。 プロダクトマネジメント
14. 学習とは何か 学習：仮説に対して、意思決定を更新できるだけの証拠を得ること 例） 「この課題は本当に存在するのか？」 「この解決策で行動は変わるのか？」 「想定した価値（アウトカム）は起きたのか？」 プロダクトマネジメント
15. 学習を支える成功指標 成功指標は成功／失敗の判定基準であり、学習を進めるために必須 学習（仮説検証）のために、指標を利用する 仮説が支持／反証されたかを判定できる 次のアクション（継続／変更／撤退）の合意 議論を好み・推測からデータに基づいた意思決定に プロダクトマネジメント
16. 良い指標の条件 行動・成果に近い（アウトカム寄り） 操作可能（チームが改善で動かせる） 早くわかる（学習サイクルが回る） 副作用を抑える（ガードレールがある） ユーザ数、ページビュー、リリースした昨日数、完了したポイントなどの数字では行動や優先順位は 変わらない。 先月よりも今月はどうか？などコンテキストや意味を加えなければならない。 プロダクトマネジメント
17. 学習のためのMVP MVP = 「最小の機能」ではない MVP = 学習のための最小のコスト 重要なのは「作る量」ではなく「検証できる量」 学びたいことは何か、そのためには何が必要かを考えてMVPを設定する プロダクトマネジメント
18. ソフトウェアに頼らないMVP コンセプトテスト 顧客にアイデアやコンセプトを提示（プロトタイプ／モック／説明資料）し、フィードバッ クを収集 判定基準（成功／失敗）を先に決める コンシェルジュ 手作業で最終的な成果を顧客に提供 コーディングなしで始められる最短の学習 オズの魔法使い 顧客には自動化されたシステムのように見える バックエンドは手作業などで実施するが、顧客は手作業であることを知らない 学習のカタ 引用：プロダクトマネジメント ビルドトラップを避け顧客に価値を届ける
19. 3つの型をどう使い分けるか コンセプトテスト：問題／価値／方向性の検証 コンシェルジュ：価値提供の成立性 オズ：自動化の見せ方を含む体験検証 学習はあくまでもソリューションの探索、学習のために何かを作るのと価値提供のた めに何かを作るのを混同してはいけない。 学習のカタ
20. 1. 方向性を理解（ビジョン／ミッション／戦略／目標） 2. 現状を分析（どこが詰まっているか） 3. 次の目標を設定（アウトカム＋指標） 4. ステップ選択 問題の探索 ソリューションの探索 ソリューションの最適化 プロダクトのカタとスクラム
21. チームビルディング初期からの支援 戦略的意図 → プロダクトビジョンの接続を支援 組織・プロダクトの特性上、問題の探索は出来ない（と思い込んでいる）状 態となっているプロダクトオーナを支援し、プロダクト計画の策定を支援す る （当たり前だが）プロダクトオーナーはプロダクトのことを常に考えて参画し ているので生半可な理解だと打ちのめされる リサーチを支援 仮説の立て方 実験の選び方 学びの記録と意思決定 プロダクトのカタとスクラム
22. スクラムに埋め込む スクラムマスターの仕事は"意思決定"ではなく、"意思決定が継続的に改善される仕組 み"を作ること リファインメント：仮説と実験を設計 スプリント内：最小実験を回す レビュー：学びと意思決定を更新 プロダクトのカタとスクラム
23. 学習からソリューション、そして成功目標 学習で得た知識を基に、ソリューションを改善・最適化 ソリューションが成功指標を満たすか評価 必要に応じて反復（ピボット／継続／撤退） 成功目標： 作業時間 X% 減少／予測誤差 Y% 改善／差し戻し率 Z% 減少 など プロダクトのカタとスクラム
24. SMとしての介入 「問いの質」を上げる（Why / Who / How measured） この機能は何のために存在する？ 誰の何がどう変わる？ 結果は何で計測する？ ガードレール 指標がないアイテムはリファインメントを通さない 判定基準がない実験は開始しない プロダクトのカタとスクラム
25. 実験と学習の支援 「設備連携は制約（安全・工事・規制・契約）があるから実験は出来ない」 本当にそうだろうか？ 現地接続で学ぶのはコストが高いからこそ段階的な学習を設計する プロダクトのカタとスクラム
26. 「何を学びたいか」を分析する どの指標が価値か 現場（運用者）の意思決定フローを可視化（業務フロー・判断基準） ユースケース/失敗（通信断、時刻ズレ、計測欠損）は？ 何が改善（作業時間、差し戻し、予測誤差 等）されたら価値になる？ この情報で意思決定できるか 画面モック、運用手順書、アラート通知の文面、ダッシュボード案 インタビュー＋タスクシナリオ（ 「この情報で判断できるか？」 ） 想定するシナリオで不要な機能はないか 欠損/遅延データで動くか アルゴリズム・意思決定が成立するか 欠損・遅延・異常値を混ぜたても成立するか プロダクトのカタとスクラム
27. スクラムマスターとして 目的（アウトカム／指標） 実施した実験（何を、誰に、どの型で） 結果（指標はどう動いたか） 学び（仮説は支持／反証？ 何が分かった？） 意思決定（継続／変更／撤退） 次の実験（何を検証する？） プロダクトのカタとスクラム
28. アジャイルプロダクトオペレーティングモデル Scrum.org が提示するプロダクト運営モデル（Operating Model）のガイド スクラムの「チーム運用」だけでなく、組織の意思決定と投資の仕組みまで対象 イベント運用の改善ではなく、KPI・予算・権限・ガバナンスを価値中心に再 設計するための指南書 スクラム指南ではなく、不確実性下で価値を出す運営設計を提示 プロジェクトとプロダクトの違いとして、マインドセットがしばしば指摘されるが、まさにこ れこそが最も重要な違いである。プロダクトを全体的に捉えることで、チームはより広い文脈と 深い理解を得ることができる。プロダクトとは、価値の創出を目指してステークホルダーに貢献 するものだからだ。 より実践的なプロダクト運用モデル
29. ご清聴ありがとうございました
30. プロダクトマネジメント ― ビルドトラップを避け顧客に価値を届ける アジャイルプロダクトオペレーティングモデル Input