プロダクトオーナーの役割は、多くのオンライン・フォーラムやブログで定期的に議論されている。この役割の持つ課題と、そこに含まれるさまざまな責任は、議論やアドバイスが生み出される原因になってきた。
最近、プロダクトオーナーという役割と、アジャイルプロジェクトの中でプロダクトオーナーが確実にやるべき重要な活動について、いくつか議論がなされた。
Mary Poppendiek氏は、「プロダクトオーナー問題」について記述し、次のように述べている。
構築するのにふさわしいものを発見するのは、優れたプロダクトを作る上で最も重要なステップです。そこで間違えると、出来上がるものが100%無駄になってしまいます。何を作るべきかということに関する決定を１人のプロダクトオーナーに委譲してしまうと、開発チームが行うべき最も重要な仕事を、本当にすぐれた決定を行うスキルや知識のない人にアウトソーシングすることになります。プロダクトオーナーが多くいる実装に見られる欠点は、プロダクトオーナーが、チームが実装するべき詳細なストーリーを準備するという考え方です。これでは、チームメンバがプロダクトを設計する上でのパートナや協力者になることができません。
氏は、プロダクトオーナーという役割にあるさまざまな側面と、この役割がどれほど多様な責任を含んでいるかということについて論じている。
Scrumプロダクトオーナーは役割であるかもしれませんが、肩書きであってはいけません。プロダクトオーナーには、多くの顔があります。製品マネージャ、システムエンジニア、ユーザインタラクションデザイナ、ソフトウェアアーキテクト、ビジネスアナリスト、品質監理の専門家、テクニカルライタなどです。私たちはこれらのよく知られた肩書きをうまく用いるのであって、新しいあいまいな肩書きを発明したりはしません。そういった肩書きはプロジェクトが滞る場所になりがちで、プロダクトの設計という最も重要な役割を開発チームから奪ってしまうことが多いのです。
似たような傾向として、John Mansour氏は、プロダクトオーナーとプロダクトマネージャという役割の間にある混乱と共通項について話している。「アジャイルプロダクトオーナー - 新しい名前と、昔と変わらない問題」と題されたブログエントリで、氏はチームがカバーする必要のある重要な役割が２つあると言っている。
1. 「どんな」と「なぜ」の役割 - 「どんな」機能をプロダクトに含めるべきか、そして市場やビジネスの観点から見て、それが「なぜ」なのかを決定する責任を持ちます。この「どんな」と「なぜ」の役割は、内部外部を問わずあらゆる入力を受け取って伝達することに従事します。この役割の目的は、プロダクトの方向性を市場の力学や顧客の要望と調整して、利益を増やすことにあります。この「どんな」と「なぜ」という機能は、プロダクトマネージャの典型的な責任です。伝統的な開発であれ、アジャイルであれ、これは必要なことです。誰がやるか、それがどのような肩書きで、どうやられるかは関係ありません。
2. 「どのように」の役割 - ユーザの行うことをサポートするためにプロダクトのフィーチャが「どのように」機能するべきかを決定する責任を持ちます。その最も基本的な形態においては、この役割はユーザの代理であり、話し言葉や書き言葉、あるいは図を使ったかたちで説明する責任や、詳細を詰める責任があります。詳細とは、ユーザが何をどのように行い、そういったユーザをサポートするために、ソフトウェアがどう「機能」しなければならないかということです。こうした役割を持つ人は、ほとんどの時間を開発者と共にすごし、機能のテストを行って設計通りに動作することを保証します。しかも、他にも多くの責任を持っています。そして、この役割に最も適しているのは、元々そのシステムを使っていたユーザや複数の環境でさまざまなユーザと密接に協業していた人です。
氏によれば、アジャイルチームの多くが、２つの役割を組み合わせて、プロダクトオーナーという１つの役割にするという過ちを犯しているという。その結果、しばしば、明確な区別がなされず、混乱が生じているというのだ。
私見によれば、この混乱は２つの領域にまたがっています。第一に、ソフトウェア企業は、プロダクトマネージャと機能的なプロダクトデザイナの責任を組み合わせようと長年試みてきました。これは数多く見てきましたが、どのケースをとっても悪夢でしかありませんでした。さらに、この混乱はアジャイルの世界において、プロダクトマネージャ対プロダクトオーナーというアイデンティティの危機も作り出しています。
開発方法論に関係なく、こうした役割を組み合わせることは、失敗へ向かうレシピです。費やされる時間はもちろん、それぞれに求められるスキルセットや性格がまったく異なるからです。これらの役割が組み合わされると、結果として出てくるのは、ユーザビリティの貧弱な正しい機能性か、誰も必要としないきわめて使いやすいフィーチャのどちらかになってしまいます。これは「今日無くすなら、腕と足どちらがいい？」という問いに匹敵するジレンマです。
プロダクトオーナーという役割から最も多くを引き出すための、アドバイスや提案、構想を提示する解説者も何人かいる。
Monica Yap氏は、「プロダクトオーナーアンチパターン」というテーマで一連の記事を書き始めた。氏は以下のアンチパターンを特定している。
• プロダクトオーナーの不在
• 一番新しいものをコピーする
• バックログをかき混ぜる
• 完了に関するあいまいな定義
• プロダクトオーナーが１人もいない
• ステークホルダが十分にいない
また、Jack Milunsky氏は、「プロダクトオーナーの活動トップ10」において、以下のアドバイスをしている。
1. プロダクトバックログを作り、メンテナンスする
2. ビジネス上の価値かROIに基づいてバックログの優先順位をつけ、順番に並べる
3. 大作を仕上げるのを手伝う。すなわち、テーマやフィーチャを、１回のスプリントで十分実現できるくらいの粒度にする
4. あらゆるリリースとスプリントのはじめに、ビジョンとゴールを伝える
5. 顧客を代弁し、また顧客に対しては窓口となって約束をする
6. デイリースクラム、スプリントプランニングミーティング、スプリントレビュー、ふりかえりに参加する
7. あらゆるスプリントの最後にプロダクトの進捗を調べて、完了した作業を受け入れるか拒否するかを決める権限をすべて持っている
8. あらゆるスプリントの終わりに、プロジェクトの方向性を変えることができる
9. 状況を外部に伝える
10. 方向性を大幅に変えなければならないと決まった時には、スプリントを終わらせる
あなたならプロダクトオーナーにどんなアドバイスをするだろうか？そして、そのアドバイスはプロダクトマネージャに対するものと同じだろうか？