[読書メモ]プロフェッショナルプロダクトオーナー
[読書メモ]プロフェッショナルプロダクトオーナー
はじめに
最近、プロダクトオーナーとしての役割に興味を持ち始め、より深く理解したいと感じていました。そこで、「プロフェッショナルプロダクトオーナー」という書籍を手に取りました。この本を通じて、プロダクトオーナーの戦略的・戦術的なアプローチについて学ぶことができるのではないかと思い、読んでみることにしました。以下、その読書メモをまとめます。
各章読書メモ
第1章：戦略
プロダクトマネジメントのすきま
経営層が考える「戦略（WhyとWhen）」と、開発者が関心を持つ「戦術（WhatとHow）」の間には「すきま」が存在することを知りました。このギャップを埋めるのがプロダクトオーナーの役割であり、ビジョン、価値、検証がその鍵を握っていると感じました。
プロダクトのビジョン
ビジネスモデルキャンバスやリーンキャンバスといったツールを活用して、プロダクトのビジョンを具体化する方法が紹介されていました。これらの手法を使うことで、ビジネスの全体像を把握しやすくなると感じました。
価値
「プロダクトはリリースされるまでは価値がない」という指摘は印象的でした。価値は最終的に収益と費用で表され、指標にインセンティブを設けてもパフォーマンスや士気は改善しないとのこと。グッドハートの法則を踏まえ、指標を目標そのものにしないことの重要性を理解しました。
検証
市場でテストするまではすべてが仮説に過ぎないという考え方に共感しました。ステークホルダーからのフィードバックを積極的に取り入れることで、プロダクトの方向性に対する責任感を持ってもらえると感じました。
第2章：スクラム
スクラムのフレームワークについて、プロダクトオーナーの視点から詳しく解説されていました。特に以下の点が印象に残りました。
- スクラムはフレームワーク：その形を変えてしまうと本来の効果が得られない。
- 変更と追加：スクラムチームがフレームワークを変更するのは望ましくないが、追加するのは良い。
これを踏まえ、スクラムの基本を尊重しつつ、チームに適した方法を模索する必要があると感じました。
第3章：戦術
プロダクトバックログ
プロダクトバックログは、機能要求や非機能要求、実験、バグ修正など、あらゆる種類の作業を受け付けることを再確認しました。スプリント内で完了できない大きすぎるアイテムは、適切なサイズになるまでリファインメントが必要であると理解しました。
スパイク
チームの知識が不十分な場合、スパイクを活用して調査を行う手法が紹介されていました。しかし、スパイク自体は直接的なビジネス価値を生まないため、乱用は避けるべきだと感じました。
プロダクトバックログの並び順
優先順位を決定する際の指標として、以下の公式が紹介されていました。
優先順位 = （ビジネス価値 + リスク） ÷ サイズ
ビジネス価値、リスク、コスト/サイズ、依存関係を総合的に考慮することで、より効果的な優先順位付けが可能になると感じました。
完成
「完成」を定義する重要性を学びました。バリー・オーフレイムの例では、設計の適切さ、ドキュメントの更新、テストの実施、プロダクトオーナーの受け入れ、デモ手順の明確化などが挙げられており、チーム全体で共有すべき基準だと感じました。
プロダクトのスケーリング
プロダクトの規模に応じて、以下のようなチーム体制の検討が必要であると理解しました。
- 一つのプロダクトに1つの開発チーム：スクラムの基本形態。
- 複数のプロダクトに一つの開発チーム：効率が低下するため避けるべき。
- 複数のプロダクトに複数の開発チーム：各プロダクトに専任チームを配置。
- 一つのプロダクトに複数の開発チーム：大規模プロダクトへの対応策。
気づき
- ビジョンの共有：ビジョンを明確にし、チーム全体で共有することの重要性を改めて感じました。これにより、全員が同じ方向を向いて開発を進められると考えます。
- 価値の測定と指標の扱い：指標を目標にするのではなく、価値の検証手段として活用する姿勢が大切だと気づきました。
- ステークホルダーの巻き込み：フィードバックを通じてステークホルダーの責任感を高めることで、プロダクトの成功につながると感じました。
- スクラムの原則の遵守：基本を崩さずに、必要な追加を行うことで、スクラムの効果を最大化できると理解しました。
まとめ
「プロフェッショナルプロダクトオーナー」を読んで、プロダクトオーナーとしての役割や責務について深く学ぶことができました。特に、ビジョンの重要性や価値の最大化、ステークホルダーとの関係構築において、新たな視点を得られたと感じています。この学びを活かし、今後のプロダクト開発に貢献していきたいと思います。
Discussion