「スクラムを活用したアジャイルなプロダクト管理」はおすすめです。

本書はドイツのRoman Pichler氏の本で、有名な本です。プロダクトオーナーの教科書としてお勧めします。特に、"スクラムのプロダクトオーナー"として、実際に開発チームとどのように働くのかについて、コンパクトに説明しています。「塹壕よりScrumとXP」は、チーム側がどのように動くかの教科書ですが、本書はプロダクトオーナー側がどのように動くべきかの明確な定義を与えてくれます。

スクラムを活用したアジャイルなプロダクト管理―顧客に愛される製品開発

作者:ローマンピヒラー
ピアソン桐原

Amazon

「2.4 シンプル」で触れられていますが、シンプルであること、現在やるべきでないことを削ぎ落とすことは、プロダクトオーナー最大の腕の見せ所だと思いますが、その意味で、本書自体が極めてシンプルにまとめられており、それが価値になっています。日本語もこなれていると思います。翻訳者とレビュワーの皆さんの努力と経験値が垣間見える気がしました。

冒頭の推薦文でLinda Risingさんも言っていますが、「よくある間違い」の節がいくつかあり、これが素晴らしいと思います。これが日本語で、紙の本で読めるなんて幸せです。

一方で、例えば、プロダクトのビジョンの作り方、については核心を紹介するにとどめていますので、実際の作り方や効果的な伝え方については、UXや要件定義の手法を参照して、適切なものを組み合わせる必要があると思います。この「適切なものを補完して使う」というのが、またスクラムらしくていいですね。

以下は私の読書メモです！本書内の訳語と合わない部分もありますが、ご容赦をー。

第1章プロダクトオーナーの役割を理解する

プロダクトオーナーに望ましい人はどういう人であるかを紹介しています。
必ずしも全てを現在持っている必要はないかもしれませんが、重要な素養について解説しています。

明確なビジョンを持った実行家
リーダーであり、プロダクトについてのファシリテーターでもあること
様々なステークホルダーとのコミュニケーション、ネゴシエーションを行えること
適切な権限を持っており、それでいて献身的に環境を整える能力もあること
プロダクトと向き合える十分な時間を持っていること
要件を説明できる能力、予算管理能力
チームとコラボレーションできること。「私たちと彼ら us and them」ではなく、チームの一員として
全員が同じ場所にいることが理想的。少なくとも毎日1時間を同じ部屋で過ごす
スクラムマスターとの協働
規模が大きくなった場合のプロダクトオーナー組織について
よくある間違い
- 力不足 (分かってない人ね)
- 働きすぎ (会議にこない人困るね)
- 権限が限定的 (分担されるとコミュニケーションロスがね。過剰なほうれんそうとかね)
- 遠隔地 (会うこと重要ね。いつでも声かけられること重要ね。危機のとき特に。)
- 代理 (最悪ね)
- 委員会 (合議制ね。即答ない上に、だれも責任取らない。ころころ変わる)

第2章製品を想像する

プロダクトオーナーがメインで担当する製品(プロダクト)について説明しています。

製品ビジョンを試す質問
製品ビジョンの望ましい品質
- ゴールイメージを共有できること
- 魅力的で、意欲をかき立てる
- 簡潔さ
- MMF (Minimal Marketable Feature) 最小の需要があるフィーチャーセット
シンプルさの価値
- オッカムの剃刀 (私は統計学で初めて学びましたが重要なメタファーだと思います)
- Less is more (少ない方が多くのことをもたらす)
- シンプルなユーザーインタフェース
顧客ニーズと製品属性、優先順位、最良の解決策
ビジョンの作成 (のさらっとした説明)
- ビジョン作成をするスクラムチームという例
- プロトタイプとモックアップ
- ペルソナとシナリオ
- プロダクトボックス
製品ロードマップの作成
最低限の製品
よくある間違い
- ビジョンがない (だめじゃん)
- 予言ビジョン (夢ね)
- 分析麻痺 (調査結果に引っ張られすぎるときは注意ね)
- 顧客にとって良いものは自分たちが一番よく知っている (バリデーション不足ね。ただしこれは製品特性によると思います)
- 大きいことは美しい (最悪ね。「次世代を担う完璧な製品」的ななにか)
おわりに: "スクラムチームが将来の製品に関して共通のビジョンをもっていることを確認してください"

第3章プロダクトバックログの使い方

プロダクトバックログのDEEP特性 (適切な詳細さ、見積り済み、emergent: 後発的な技術要求をチームが発見した場合にあとから進化させられる、優先順位付け)
プロダクトバックログの手入れ (Backlog glooming)
プロダクトバックログ項目(PBI)の発見と記述は継続的に行うこと
項目の記述はユーザーストーリーを使うのが好き
バックログの構造化 : テーマごとにグループ化
優先順位付けの要因: 価値、知識/不確実性/リスク、リリースの実現可能性、依存関係
スプリント計画の準備: スプリントゴール、バックログの粒度(適切な量とタイミング)、バックログ項目の分割、明確性/テスト可能性/実現可能性
各バックログ項目の規模の把握(ストーリーポイントとプランニングポーカー)、時間のないときどうするか
非機能要件への対応を、受入基準やDoneの定義に入れる
プロダクトバックログの規模を拡大するときどうするか
よくある間違い
- 偽装した要求仕様 (よくある！)
- サンタへの要望リスト (夢ね、よくある！)
- チームへの要件の強要 (営業さんが偉い人や顧客を盾に取ってプレッシャーかけてくるね！)
- プロダクトバックログの手入れの放置 (私がよくやるケース！)
- 複数のプロダクトバックログの競合 (すりあわせ不足ね。本質的な課題だと思う)

第4章リリース計画

ここはプロダクトマネージャー的性格と、プロジェクトマネージャー的性格がミックスされるところ。「スクラムの」プロダクトオーナーであればこれは知っていないと話にならないやつです。

時間、コスト、機能、品質の固定 ( Iron Triangle の説明)
早期からの頻繁なリリース
四半期サイクル (ビジネスのタイミングを確認して、リリースのマイルストーンを定期的に行うのは重要です)
ベロシティ
リリースバーンダウン
リリース計画
大規模プロジェクトでのリリース計画
よくある間違い
- リリースバーンダウンやリリース計画がない (「アジャイル」って言って始めるときよくあるね。先を考えてないだけ)
- 受け身のプロダクトオーナー (これはもう素養がないとしか..)
- ビックバンリリース (リーンスタートアップ勉強すべき)
- 品質の妥協 (ユーザーにそんなもの提供しちゃうの？？？)

第5章スプリントミーティングの協働

本章も「スクラム」のプロダクトオーナーであれば当然おさえるべき項目です。

スプリント計画
Doneの定義
デイリースクラム
スプリントバックログとスプリントバーンダウン
スプリントレビュー
スプリントのふりかえり (レトロスペクティブ)
大規模プロジェクトでどうするか
よくある間違い
- バンジープロダクトオーナー (忙しい人ね)
- 受け身のプロダクトオーナー (素養がないとしか...)
- 持続不可能なペース (精神論ね)
- ごまかし (見抜いてあげないとね)
- スプリントバーンダウンによる報告 (進捗しか興味ないのはだめね)