Ron Jeffries氏は先日 プロダクトチャンピオンの必要性についての記事を書いた。プロダクトチャンピオンとは、顧客の業界を知り、成功を最大限にする責任を負うことのできる人物だ。記事の中で彼は、スクラムにおけるプロダクトオーナーとXPにおける顧客は、プロダクトチャンピオンの実装だと述べている。最新刊 となる The Nature of Software Development の中でプロダクトチャンピオンという用語を用いたのは意図的であり、一般的にスクラムチームが持つよりもっと多くのことがその役割にはあるというのが、その名の意味するところだという。
理想的なプロダクトへの取り組みがこのように紹介されている。
理想的なプロダクトの状況と聞くと、皆が対等で一致団結しているのを想像するかもしれません。プロダクトの構想があって、皆が積極的に協力しあって作っていきます。必要なスキルをすべて備えた人たちがFlying Karamazov Brothersのように流れるように協働し、アイディアとプロダクトのかけらの間を行きつ戻りしながら、美しいプロダクトを紡ぎだしていくのです。
しかし現実はもっと複雑でやっかいになりがちだと言う。
プロダクトへの取り組みではたいがいこのような問題が起こりがちです。
- どこかの誰かもしくは組織がお金を出してくれています。
- 時間とお金については予算が限られています。
- 管理させろと要求する主ステークホルダーがいる、もしくはそういう幻想があります。
- 全員が等しく市場を知っているわけではありません。
- 全員が等しく技術を知っているわけではありません。
- 全員が等しく良いデザイナーなわけではありません。
- やるべきことを明確にしてもらえればいいだけの人もいます。
- もっと他にやるべきことがないか探したい人もいます。
- …などなど
プロダクトチャンピオンにはプロダクトの成功を最大限にする説明責任があるのであり、権限と知識を持つことが必要だと彼は主張する。プロダクトを作るにあたってすべてのスキルを持ち合わせている必要もないし、細部について熟達している必要もないのだ。
チャンピオンは、成功するプロダクトを作るための一部始終について熟達しているわけではないものです。たとえばアニメ映画の制作であれば、絵コンテ作りやトゥイーン、キャラクター開発、ストーリーテリング、ダイアログ、その他映画を作りあげるための諸々を知っているわけではありません。ソフトウェアプロダクトであれば、UXやデータベース、コーディング、テストなど、いいプロダクト作りにつながる創作活動のすべてを知っているわけではないのです。
プロダクトチャンピオンという役割がいかにしてスクラムを補完しより良くするのか、彼は説明を続ける。
多くの組織で認識されている “バックログリファインメント” のやり方と、実際のプロダクトチャンピオンのふるまい方を比較して彼が言うには、
チャンピオンが課題を持ち込み開発チームがそれを解決するというのであれば、それはまったく問題のないスクラム – もっというと素晴らしいスクラム – です。 課題についての融通がきくほど、チームはより多くの力を注ぐことができます。会話が行われ、いくつかのストーリーが生み出され、開発チームのテストをするメンバーは実行可能な受け入れ項目をいくつか提案し、スプリントゴールは “この問題を解決する” になります。
それから彼は多くのスクラムチームがこの理想的な状況に到達しない理由について論じ、組織に影響を及ぼしたり偉大なプロダクトチャンピオンを育てるために、スクラムにしろXPにしろ何かしら自分たちが使っている “アジャイル” なやり方を使うように要求している。
- 隔週ごとにプロダクトインクリメントを作れるようにします。スクラムのスプリントレビューを利用して、プロデュースオーナー（育成中のチャンピオン）や、知る限りすべてのステークホルダーにプロダクトを見せます。
- バックログリファインメントの集まりに積極的に参加します。ストーリーがあまりにも具体的すぎるようなら、ストーリーの背後にある課題について尋ねます。可能であれば –まあいつだって可能だが– 課題を解決するためのより良いアイディアを提案します。
- 潜在顧客やユーザーが言ったことに対して質問をします。彼らと会話をさせてもらいます。必要であれば自分たちで相手を見つけて話します。そこで学んだことをチャンピオンを助けるために活かすのです。
- プロダクトチャンピオンには、組織のヒーローになってもらいます。自分たちの功績が認められないのではと心配しなくても大丈夫。彼らをヒーローにしてしまえば、彼らは私たちを支援し喜ばせてくれることでしょう。
- スクラムマスターを使って、プロダクトチャンピオン、ひいては組織に影響をあたえるようにします。彼らはこのために存在します。他のチームメンバーも同様です。エレベーターピッチを作れるようになりましょう。コネをうまく使うのです。
似たような話だが、Roman Pilcher氏は、彼のプロダクトオーナーシップ研修に来る人の多くがプロダクトオーナーの役割を果たせていないことを知った。その役割に実際必要とされるものは何か、かつてのプロダクトオーナーたちに理解してもらえるように、彼はプロダクトオーナーシップテストを公開した。このテストを受けた人には、自分がそのプロダクトにとって正真正銘のプロダクトオーナーであるかどうかがわかるようになっている。 真のプロダクトオーナーシップの属性の中でもっとも重要なものについて、彼はこうまとめている。
自分のプロダクトをあなたが本当に所有しているかを知るために、心に問いかけてみましょう。フィードバックを無視したり要求を拒否したりする権限は自分にはあるのだろうか？ たとえ相手が権力のあるステークホルダーだったとしても、ノーと言えるのだろうか？ アジャイルなプロダクトオーナーシップを行使するということは、どちらの質問にも肯定的な答えが要求されるものなのです。