スクラムにおけるプロダクトオーナーの役割は強力ですが、それを適用するのは能力が試されることがあります。れに成功した企業は、顧客（製品管理）と開発との間の新しい健全な関係の恩恵を受けるでしょうし、競争上の優位性を経験しやすいでしょう。これには相当な代償が必要です。この役割を効果的に応用するためには、しばしば組織的な変化が必要とされます。この記事では、プロダクトオーナーの役割を上手く適用する方法に対する洞察を提供します。本稿はプロダクトオーナーとして成功するために必要なものを皆さんが理解するのを支援します。
強力な接着剤
スクラムのプロダクトオーナーは重要な役を演じます。決して昔からある役目につけた新しい名前ではなく、この役割はビジネスと開発/ITとの間の関係を再定義します。もはや要件がプロジェクトの最初に完全に述べられ、凍結され、それから開発へと引き渡されることはありません。顧客担当者がプロセスから切り離されてプロジェクト管理がプロジェクトマネージャに委譲されることは、もはやありません。その代わりに、プロダクトオーナーが顧客の要求を伝え、リリースを導き、そしてチームやステークホルダと継続的に協調して取り組みます。プロダクトオーナーは、みんなが同じ目標に向かっていることを確かめることによって一致協力しながら、エンドカスタマーや製品管理、開発、ステークホルダの間をつなげる接着剤として振舞うと言えるでしょう。
この役割は一般的に顧客または製品マネージャが担いますので、ビジネスもスクラムを採用する必要があり、それに適応するためには変化を起こすことが必要です。これは困難なことかもしれませんが、ビジネスと開発/ITとの間のより健全な関係という結果をもたらすだけではなく、競争上の優位性をもたらすこともあります。顧客の要求は効果的に伝えられます。一人の人物がリリース目標の決定とデリバリーを行うことについて責任を持ちます。意思決定のプロセスはスピードアップし、誤解や調整の失敗は防がれます。
仕事内容
プロダクトオーナーの責務について、もっと詳しく見ていきましょう。主に３つの領域があります：顧客の要求、プロジェクトの成功、そしてコラボレーションです。
スクラムのプロダクトオーナーは、顧客の要求を理解しコミュニケーションをとる責任があります。プロダクトオーナーを起業家と考えてもよいでしょう：ソフトウェアの価値ある提案とともに製品のビジョンを策定し、伝える人です。プロダクトオーナーはプロダクトバックログを記入し、継続的にその内容の精度を上げていきます：新たな要件は追加され、既存のものについては、その精度が上げられます - 一般的にはジャストインタイムで、次のスプリント計画ミーティングの前に行います。さらに、プロダクトオーナーはプロダクトバックログの優先順位をつけ、確実に最も重要な要件に必ず取り組むようにします。
プロジェクトの成功はプロダクトオーナーの責務の２つめの領域です。これにはプロジェクトの目標と投資利益率（return on investment：ROI）のような財務上の目標を達成することが含まれます。プロダクトオーナーは顧客満足とROIを最大化するため、機能性やリリース日、予算を決定します。プロダクトオーナーはリリース計画やリリース報告の作成、更新も行います。
最後に重要なこととして、プロダクトオーナーはリリース全体を通してチームと協力し、ステークホルダと調整します。プロダクトオーナーとチームは、一般的には一緒に要件を詳細化します。プロダクトオーナーはまた、疑問が生じたときには要件を明らかにし、合意した「完了」の基準を用いて作業の結果をレビューします。最後に、プロダクトオーナーはスプリント計画ミーティングの準備をします。これには、ミーティングに先立って徐々に要件を分解する活動も含まれますが、それによってスムーズな作業の流れを作ります。
プロダクトオーナーの役割を果たすことは一般的に、特にプロジェクトの技術革新あるいは複雑さの度合いが高い場合は、フルタイムの仕事です。プロジェクトの性質やサイズ次第で、エンドカスタマーまたは製品マネージャ、マーケティング担当者、あるいは顧客がこの役割を務めるかもしれません。
よくある落とし穴
正直に言いましょう。プロダクトオーナーの役割を果たすことは、能力が試されることがあるでしょう。結果として、どのようにプロダクトオーナーの役割を実行するかについて、私はいくつかのよくある落とし穴を知っています。以下に示すのは、私のお気に入りを選んだものです。
一人でこの役割を果たす人物を見つけるのが難しい組織もあるでしょう。この問題に取り組むためには、プロダクトオーナーの責任を複数の人で分け、たとえば、製品マネージャが顧客の要求に対する責任を持ち、スクラムマスタがプロジェクトの成功やコラボレーションに関する責任を負います。私はこの落とし穴を仮想プロダクトオーナ症候群と呼んでいます。この罠に陥ると、企業はプロダクトオーナーの役割が持つ力の大部分を失い、改善に向けた大きなチャンスを逃します。何人かの人がプロダクトオーナーとなるプラクティスが理にかなっているのは、複数のチームが同じプロジェクトに取り組んでいる場合だけです。この場合は、どちらかといえば、プロダクトオーナーのチームがプロジェクト全体を管理する人（チーフ・プロダクトオーナーと呼ばれることもあります）と連携します。
もう一つのよくある落とし穴は、ITまたは開発メンバがプロダクトオーナーの役割を果たすというものです。これは、製品管理あるいはエンドカスタマーが変化を望んでおらず、プロダクトオーナーの責任を負いたくないというサインであることが多いのです。ITプロダクトオーナーは技術者とビジネスの仲介者に過ぎません。この役割が持つ本来の力は失われます。顧客の要求が一人の人物によって理解され伝えられることは、もはやありません。ビジネスと開発/ITとの間のコラボレーションで必要とされる変化は起こりません。関係は改善されません。ビジネスは要件をゆだね、次に開発プロセスから切り離される可能性が高いでしょう。（このようなことを言いましたが、構成チームから成る複数チームのプロジェクトを運営している場合は、プロダクトオーナーの役割を果たすアーキテクトが構成チームの責任を持っているのは理にかなっています。）
最後に、バンジー・プロダクトオーナー（この名前はもちろんDilbert氏から着想を得たものです）があります。ほとんど体があいておらず、ほぼスプリント計画とレビューのミーティングに出席するだけのプロダクトオーナーです。そのようなプロダクトオーナーは、積極的にプロジェクトの舵を取り導くのは難しいと感じるでしょう。たくさんの未解決の問題は、単にスクラムマスタあるいはチームの推測や仮定で答えられるでしょう。他のものはプロジェクトの進捗を阻むでしょう。例え理由が何であっても - 働きすぎであったり、あるいは他に優先事項があっても - きちんと体のあいていないプロダクトオーナーは、リリースにマイナスの影響を与えます。
成功の秘訣
どのようにすれば、上述したような落とし穴を避け、プロダクトオーナーの役割の実行に成功することができるのでしょうか？私が極めて重大であると思ったことが３つあります。
- プロダクトオーナーには自由裁量権が与えられなければなりません。
- その人には仕事をするための十分な時間がなければなりません。そして
- プロダクトオーナーは適切な能力がなければなりません。
私の経験では、これらの要因は重大です。自由裁量権があって体のあいている能力のあるプロダクトオーナーと、成功した健全なスクラムプロジェクトとの間の強い相関性に、私は気付きました。
権限を与えることは、決定する権限を持ち、その結果に対して責任を負うことを意味します。これにより、決定が必要になるたびに経営者の承認を得ることなく、素早く適切な決定をすることができるようになります。私は企業がプロダクトオーナーの役割の重要性を過小評価しているのをしばしば見かけます。結果として、プロダクトオーナーには十分な権限が与えられません。もしプロダクトオーナーが重要なプロジェクトをリードするのであれば、その人は上層部によって直接支援されるべきです。さらに、プロダクトオーナーはリリース目標の設定に積極的に関わらなくてはなりません。これにより、その人は目標の達成に全面的な責任を持てるようになります。
体があまりあいていないと、最終的にはプロジェクトの生産性に影響を与えます。必要な予備作業が行われず、決定は遅れます。上記で指摘したように、スプリント計画とレビューのミーティングにしか参加できないバンジー・プロダクトオーナーは、迅速かつ完全に質問に答えるのは難しいと感じるでしょう。彼らはチームとの継続的なコラボレーションのチャンスを逃すでしょうし、プロジェクトの舵を取って導く能力は落ちるでしょう。
適した能力を持つということには２つのことが含まれます：顧客の要求を完全に理解することと、アジャイルやスクラムに関する実際上の知識です。後者には、プロダクトバックログを効果的に記入したり精度を上げること、あるいはユーザストーリーの形式で要件を述べることのような、実際的な価値のあるプラクティスを実行できることが含まれます。プロダクトオーナーは仕事をそつなくこなすために - スクラムマスタと同様に - きちんとスクラムの訓練を受けている必要があります。Certified Scrum Product Owner（認定スクラムプロダクトオーナー）のコースとオンザジョブトレーニング/コーチングの組み合わせが最もうまくいくことがよくあります。
プロダクトオーナーが効果的な作業をすることを可能にするためには、次のことを試したいと思うかもしれません。確実に、経営陣がこの役割の重要性を十分理解し、プロダクトオーナーを注意深く選び出すようにします。さらに、ほとんどの時間をプロダクトオーナーとして過ごせるようにし、その人から他の仕事を取り除きます。最後に重要なこととして、長期的な視野でとらえます：プロダクトオーナーを成長させて下さい - プロダクトオーナーの役割を引き受ける用意が出来るように、そうした人たちに投資するのです。これには、組織内でトレーニングやコーチングの能力を確立することも含まれるかもしれません。
古いニュース
プロダクトオーナーはやりがいのあることですが、多くの場合、能力が試される仕事です。有能なプロダクトオーナーとして働くことの出来る人を育成することは、同じように手腕を問われることです。面白いことには、トヨタや本田、その他のリーンな企業は、かなり以前からプロダクトオーナーの役割をうまく採用しています。実際に、トヨタはほとんど半世紀にわたってこれを行ってきました。トヨタではプロダクトオーナーを「チーフ・エンジニア」と呼んでいますが、これは、この役割を果たす人が高く評価されるシニアエンジニアだからです。チーフ・エンジニアは上述のプロダクトオーナーの責務の大部分を共有しますが、それに加えて開発プロジェクトのチーフ・アーキテクトでもあります。チーフ・エンジニアであることは、スクラムのプロダクトオーナーであることよりもさらに能力が試されることですが、トヨタはこの役割をうまく使用し、強力なリーン開発システムの要となりました。トヨタの例が示すように、企業が必要な変化を起こすことを望んでいるのであれば、プロダクトオーナーの役割は競争上の優位性となり得るのです。
まとめ
確かなこと。プロダクトオーナーの役割を適用することは難しいことがありますが、その適切な利用はスクラムを成功裏に適用するためには絶対に必要なことです。この役割を少し変えたい、弱めたいという誘惑に耐えて下さい。そうすれば、より簡単に適用できます。むしろ、企業が進歩するのを促進する、必要な組織的変化を推進するため、どんな問題や障害でも利用して下さい。この役割を利用している企業は、競争上の優位性を手に入れることができます。全ての必要な変化を起こすことは困難な仕事になる可能性が高いですし、どちらかというと、ある程度時間がかかるかもしれません。残念ながら、私はまだ魔法のように変化をもたらすスクラムの妖精の粉を見つけていません。もし見つけたら、皆さんにお知らせするつもりです。約束します。
リソース
James M. Morgan, Jeffrey K. Liker. The Toyota Product Development System: Integrating People, Process and Technology. Productivity Press. 2006 （邦訳：トヨタ製品開発システム、日経ＢＰ社、2007年）
Roman Pichler. Scrum - Agiles Projektmanagement erfolgreich einsetzen. dpunkt. 2007
Ken Schwaber. Agile Project Management with Scrum. Microsoft Press. 2004 （邦訳：スクラム入門-アジャイルプロジェクトマネジメント、日経BPソフトプレス、2004年）
Allen C. Ward. Lean Product and Process Development. Lean Enterprise Institute. 2007
経歴
Roman Pichler氏はリーン思考とスクラムを専門にする経営コンサルタントとして働いています。氏は「Scrum - Agiles Projektmanagement richtig einsetzen」（dpunkt 2007）という本の著者です。Roman氏は何年にも渡ってプロダクトオーナーとともに仕事をしています。彼はCertified Scrum Product Owner（認定スクラムプロダクトオーナー）のコースを含む、プロダクトオーナーのための専門のトレーニングやコーチングを提供しています。詳細についてはwww.romanpichler.com をご覧下さい。
原文はこちらです：http://www.infoq.com/articles/agile-product-owner
（このArticleは2008年5月14日に原文が掲載されました）