第9章 プロダクトオーナー

プロダクトオーナーとは、プロダクトの統括を認められた中心的な存在

POは少なくとも以下の2つの方向に同時に目を向ける必要がある

• 組織内のステークホルダー・顧客・ユーザー
  • ニーズや優先順位について、深く理解しなければならない
  • POはPMとして行動し、正しいソリューションが開発されていることを保証
• 開発チーム
  • どの順番に構築するのかを伝える
  • 機能が完成しているかどうかを判断できるように、受け入れ条件を明確にしてその条件を満たすテストを実行されるようにしなければならない
  • POが詳細レベルのテストを書くことないが、抽象的なテストは書く
    • ビジネスアナリスト兼テスター

プロダクトオーナーの責任

• 経済性の管理
  • リリースレベルの経済性
    • プロダクト開発中に生じる経済的に重要な情報に対応して、スコープ、納期、予算、品質との間で継続的にトレードオフを行う
      • リリース開始時に決定したトレードオフが、リリース途中に判明した新しい情報によって不適切になる可能性があるため
  • スプリントレベルの経済性
    • スプリントごとに投資収益率(ROI)が高まるようにする
  • プロダクトバックログの経済性
    • 経済状態が変わると、プロダクトバックログの優先順位も変わる
• プランニングへの参加
  • 各種プランニング(ポートフォリオ・プロダクト・リリース・スプリント)の主要参加者
• プロダクトバックログのグルーミング
  • プロダクトバックログの作成・洗練・見積もり・並び替え
  • 見積もりはしないが、見積もりに関する疑問や質問には答えられるようにする(見積もりは開発チームがする)
• 受け入れ条件の定義と検証
  • POはPBIの受け入れ条件を定義する責任がある
    • 機能要求や非機能要求が満たされていると納得できる条件
• 開発チームとの協力
  • 開発チームと頻繁かつ密接に協力する
  • 積極的に関与することが飛鳥で、毎日果たすべき
• ステークホルダーの協力
  • 内外のステークホルダーの声を代表する

一人の人間でプロダクトオーナーの役割は果たすことは可能で、果たすべきである。
しかし、場合によってはプロダクトオーナーチームやプロダクトオーナープロキシが有効な場合がある

プロダクトオーナーのスキル

大きく4つに分けられる

• ドメインスキル
  • ビジョンの作成や実施を行うには、ビジネスとドメインの知識が必要
  • 知識がなければ機能の優先順位を設定できるはずもない
• 対人スキル
  • ステークホルダーと良い関係を気づく必要がある
    • ステークホルダーの要望は衝突することが多いので、交渉し、合意形成しなければならない
  • ステークホルダーとスクラムチームの橋渡し役
    • 両方とうまく協力して、それぞれに適切な言葉で伝える
  • 周囲のモチベーションを高める事ができる
• 意思決定力
  • 難しい意思決定を進んで行う
    • スコープ・日付・予算などの制約のトレードオフ
  • ビジネスニーズと技術的な実現性のバランスを取って意思決定を行う
• 説明責任力
  • ビジネス結果を届けることに対する説明責任がある

その他の役割と組み合わせ

• プロダクトオーナーチーム
  • スクラムを正しく適応するには一人の人間がプロダクトーオーナーとなる
  • 最終的な意思決定は一人の人間が行い、委員会による設計に成り下がることがないなら、プロダクトオーナーチームを認めても良い
• プロダクトオーナープロキシ
  • 特定の状況でプロダクトオーナーの代理になれる人
  • POではないことを知っており、同時にPOの代わりに戦術的な意思決定をする人である
• チーフプロダクトオーナー
  • 大規模なプロダクトのときに作られる
  • プロダクトオーナーの役割を階層的にスケールする必要がある

ここまでの感想や実際の現場との差異

• POの圧倒的中間管理職感…
  • ステークホルダーとスクラムチームの橋渡しは、板挟みになってつらそう
• 現場ではどちらかというと、チーフプロダクトオーナーの形式になっている気がする
  • だが、POが複数いるのに対してスクラムチームは一つという現状
• テクマで機能開発が開始してないという不安があったが、そのあたりと折衝をするのもPOの役割なのかなと思う