プロダクトオーナー

営業は新機能を求め、サポートは問い合わせの削減を求め、開発者は障害の原因を直したいと考えているとします。
どれも必要でも、同時にすべてへ取り組めるとは限りません。
プロダクトオーナー（Product Owner）は、スクラムチームの仕事から生まれるプロダクトの価値を最大化することに責任を持つ人です。

目指す状態と仕事の順番を決める

プロダクトオーナーは、プロダクトが将来どういう状態を目指すかを、プロダクトゴールとして明確に伝えます。
その実現に必要な仕事をプロダクトバックログに並べ、内容と順番を関係者が理解できる状態にします。
バックログの管理は、依頼を受け付けて記録するだけでは終わりません。
限られた時間の中で何を先に進めるかという判断を含みます。

たとえば「初めて使う店舗が、自力で営業開始の設定を完了できる状態」を目指すとします。
新しい分析画面の要望があっても、初期設定で多くの店舗が止まっているなら、設定の改善を先にする判断が考えられます。
そのときは、問い合わせや利用状況を確かめ、どの問題を先に解くつもりなのかを関係者へ説明します。

価値の判断を結果から見直す

どの仕事が価値を生むかは、作る前には仮説を含みます。
先ほどの例で設定画面を改善したとしても、公開しただけでゴールへ近づいたとは判断できません。
利用者が設定を完了できたか、どこで止まったか、問い合わせがどう変わったかを確かめます。

その結果、画面よりも設定に必要な情報の入手が問題だとわかるかもしれません。
プロダクトオーナーは、開発者や関係者と結果を検討し、次に扱う仕事を見直します。
一度決めた順番を守り続けると、当初の仮説が外れても同じ開発を続けることになります。
何を完成させたかと、利用者にどんな変化があったかは、分けて確認する必要があります。

開発者と分担する判断

プロダクトオーナーは一人ですが、調査、項目の記述、内容の整理をすべて一人で行う必要はありません。
仕事を他の人に任せても、価値の最大化と効果的なバックログ管理への責任は残ります。
利用者や専門家と直接話す機会を開発者にも設ければ、依頼の受け渡しだけでは得られない判断材料を共有できます。

一方、実現方法や作業量の見積もりは、実際に仕事をする開発者が判断します。
スプリントプランニングでは、チーム全体でスプリントゴールを作り、開発者がプロダクトオーナーと話し合って取り組む項目を選びます。
プロダクトオーナーが一方的に作業量を割り当てると、開発者が実際に完成できる量についての判断を反映できません。

一人に責任を置くための組織の支援

複数の関係者が要求を持っていても、プロダクトオーナーは委員会ではありません。
要求の変更を望む人は、プロダクトオーナーと話し合います。
組織がその判断を尊重し、開発者へ別々の指示を出さないことが、仕事の順番を機能させる条件になります。

任命時には、扱うプロダクトの範囲、判断できる事項、相談が必要な制約を確かめます。
肩書だけを与え、すべての順番を上位者が後から変える運用では、任された責任と判断権限が一致しません。
プロダクトオーナーとスクラムマスターは、こうした制約を組織と話し合う必要があります。

参考資料