スキップしてメイン コンテンツに移動

Reading: スクラムを活用したアジャイルなプロダクト管理

そう遠くないうちに、自分の仕事上の役割が変わって、Product Owner(以下、PO)をやることになりそうな流れとなっている。
これまでもチームにPOはいたし、なんとなくやっていることは分かっていたつもりだけど、改めて、きちんと抑えたい気持ちになった。
何冊か関連する書籍を買ってみたけれど、まずは1冊目。


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

プロダクトオーナーとして望ましい特性:

- 明確なビジョンを持った実行家:最終的な製品を心に描いて明確に伝えることができる
- リーダーとチームプレイヤー:権限が与えられている一方でチームメンバーでもあるあるため、両立して、判断を強制しないようにしなければいけないし、異論を唱えるメンバーと議論をしなければいけない
- コミュニケーターとネゴシエーター:顧客の声を代表してチームと会話したり、必要に応じて妥協の交渉をしたりする
- 権限が付与された献身的な人物:リリースの一部として提供される機能を決定する権限を持っている持っており、開発の向上に献身的でなければならない、情熱的で信頼できる人物であることが必要
- 可用性と資質:過剰な負荷がかかると成果物が最適ではなくなる、顧客と市場に対する深い理解があり、ニーズを伝え、要件を説明できる能力が必要


よくある間違い(≒アンチパターン):

- 力不足のプロダクトオーナー:権限不足だったり十分な信頼や支援を得られていない
- 働きすぎるプロダクトオーナー:負荷がかかりすぎて質問に即答できない、会議を欠席するなど、役割を全うできない、可用性の裏返し
- 限定的なプロダクトオーナー:役割を組織の都合などで分解し、プロダクトマネージャーが外向きの活動を、プロダクトオーナーが内向きの活動を担うなど、この場合プロダクトオーナーはバックログの書き手に役割を少し追加しただけの存在になってしまう
- 遠隔地のプロダクトオーナー:同じ建物の違う場所、別のタイムゾーン他、様々だが、遠隔地で対応すると不信感、伝達ミス、認識などのズレ、進捗遅延といった問題を繰り返す
- 代理のプロダクトオーナー:本来のプロダクトオーナーが忙しすぎるため、十分な権限は付与されずに代理でプロダクトオーナーがやるような活動をし、最終決定・判断は本来のプロダクトオーナーが実施する、というようなことが起きると遠隔地のプロダクトオーナーと同じようなことが発生する
- プロダクトオーナー委員会:1人も責任者がいないため、結果として具体的な進捗がないままとなる


第2章 製品を想像する

効果的なビジョン:

- 購入するのは誰?想定ユーザーは誰?
- どのようなニーズに対処する?どのような価値を提供する?
- 成功するために欠かせない属性は何?どのような見栄えで何ができる?
- 競合他社や自社の他の既存製品と比べて何がどうすごい?目標価格は?
- どのようなビジネスモデル?収益の獲得の方法は?
- 実現可能?販売できる?


ビジョンの望ましい品質:

- ステークホルダーが共有してお互いにコミットする
- 製品のビジョンは、メンバーが想像的に参加する余地を十分に残すことで、最高の成果をもたらす
- エレベーターピッチで紹介し切れるくらいに簡潔にする


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

バックログの構造化:

- プロダクトバックログは関連する項目をグループ化し「テーマ」と称する。スプリントのゴールや優先度の設定にテーマを使うことで、個別のバックログごとでの優先度づけのようなことに陥らないようになる。

優先度付け:

- 優先度は価値順......の「価値」は製品の開発に必要かどうか
- 価値があるかが不確実な時は、あえて不十分なままリリースし、フィードバックを得てから確実性を高め、実装する、という手立てもある(Google Newsの事例)
- 知識がない、不確実性が高い、リスクが高い、という場合には製品の成功に影響を及ぼすため優先順位を高くする
- 依存関係のあるものは早めに解決する、ただし、依存関係がある場合にそれを混合してまとめて対応しようとすると大きなストーリーとなり魅力が損なわれるので、ストーリーの分け方を工夫することで対処した方が望ましい

他:

- 非機能要件と機能要件は別々には見積もらない、Doneの定義に含めた上で見積もる
- 非機能要件は全部の機能要件に関連するものとそうでないものがあるので区別する、また特に前者はプロダクトの成功に大きく影響するため早い段階で記述する
- バックログを要求仕様のように書いてしまうのは誤り、ビジョンとの結びつきがプロダクトバックログとしては重要
- 要望を単に書き出す、というのも適切ではない、それではバックログが要件データベースになってしまう


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

よくある間違い:

- 協働が限定的、例えばプランニングやレビューの時だけ現れる、普段は連絡が取りづらい
- 質問などもなく傍観者としてスプリントレビューに参加する
- 持続不能なペースをチームに要求する(「どのようにチームはリカバーするのか?」「しない」=リカバーしないでも良い、持続可能なペースで取り組む)