プロダクトマネージャーvsプロダクトオーナー(ほぼ翻訳)
オリジナルはこちらのRoman Pichlerさんのブログから。
今回は、プロダクトマネージャーとプロダクトオーナーの違いが書いてあるピヒラーさんのブログを翻訳していきます。
■序
何年もの間、人々は「プロダクトマネージャー」と「プロダクトオーナー」の違いについて討論を重ねてきた。それが同時に存在しうるか、どちらが使われるべきか。
この記事は私(ローマン・ピヒラーさん)がこの話題にプロダクトオーナー(以降PO)の役割の起源について思うことやそのふりかえりの記事を共有したものです。
■What？
ご存知かもしれませんが、POの起源はスクラムから来ています。そこには、"プロダクトの価値の最大化"に責任を持つと記載されています。
これはまるで、プロダクトマネジメントのテキストのように私には聞こえます。にも関わらず、戦略的なタスクを持った役割のPOですがプロダクトバックログアイテム(以降PBI)管理、要求の詳細化や開発チームとの交流に関係づけられています。なぜでしょうか？
そこには2つの大きな誤解から生まれる理由があります。スクラムにおける自然とSAFeにおける使い方です。SAFeとは有名な拡張アジャイルのフレームワークです。スクラムはチームが複雑なプロダクトを開発するのことの助けになることに集中したシンプルなフレームワークです。これは、プロダクトマネジメントのフレームワークではありません。
結果的に、スクラムは一般的なプロダクトマネジメントのプラクティスをカバーしていません。例えば、プロダクト戦略、開発、プロダクトロードマップ、ビジネスモデリングや財務的なフォーキャストです。スクラムにおける唯一のプロダクトマネジメントのツールはプロダクトバックログのみです。
さらに追加すると、SAFeはPOのロールを使っていてそれはスクラムにおけるPOの役割とは違います。
後者はフルスタックのオーナーシップを持っていると考えてください。ある個人が全ての側面におけるプロダクトの責務を負っています。例えば、プロダクトのbジョンや戦略・戦術です。
しかしSAFeのPOでは戦略的なプロダクトの意思決定と結果的に部分的なオーナシップしか責務として負っていません。結果的にこのロールはSAFeのプロダクトマネージャー(以降PdM)により補完されています。SAFeのPdMは形式上の戦略的な決定を担っている。下記の図の状態。
このように、プロダクトのオーナーシップの責任を分離することはよくある拡大のテクニックです。しかし、戦略的なロールとして”PO”呼武ならばSAFeがすることは不幸にもミスを犯していることになります。
2人のPOを2つの階層で存在させ権限や責任を持たせることは、混乱を生みさらに誤解を与えることを増加させます。
覚えておいてほしいことは、私はスクラムのPOのロールを常にアジャイルプロダクトマネージャーとして見ているということです。
つまり、私はPdMのロールをただ、外見上の戦略的に自然に存在させることに同意しかねるということです。慣習的なやり方としては、PdMは戦略や戦術的な決定に責任がありました。例えば、プロダクトロードマップや要件定義です。
■So What?
つまり、なぜスクラムはPOを最初に紹介しているのかということです。なぜ、このフレームワークはPdMという用語を使用していないのでしょうか？最初のバージョンのスクラムでは、実際には、使用されていました。1995年のOOPSLAカンファレンスで語られたことによると、ケン・シュエーバー、スクラムの創始者の1人でスクラムなどの造語を作った人、はPdMという用語を使用していました。
次第にその名前はPOに変更されました。以下がその変更の3つの理由です。
・1つ目
1990年代にスクラムが開発されたとき、プロダクトマネジメントは今日とは違っていた。当時のPdMはマーケットリサーチやプロダクト計画や要件定義をしていました。PdMは要件をプロジェクトマネージャー(以降PjM)に引き継ぎ、PjMはプロダクトの開発やテスト、デリバリーを行いました。
PdMは要件変更などが発生した場合にのみ帰ってきてプロダクトのローンチのヘルプを行いました。
これはアジャイルな文脈で物事がどう進んでいくかということと明確な対比です。プロダクトに関係ある人々は常に開発チームと協働することを求められます。内部のステークホルダーやユーザーを放置することなしにそれが求められます。
・2つ目
スクラムはプロダクト開発やソフトウェアをどう売っていくのかという商業的な範囲も適応させていきます。多くの組織、銀行やリテール、メディアはスクラムを採用していき、従来のPdMのグループを持たないようにしPdMを雇わないというようなことを行いました。しかし、実際にはそれらの企業はデジタルのプロダクトには採用しています。マーケット調査や収支を作り込む中でバンキングアプリや内部のソフトウェア開発のアセットのビジネスプロセス自動化、生産性の向上、コスト削減などにあたります。
POロールをオファーすることによりこれなろ組織はPdMグループや初期の組織変更を伴わずにアジャイルなやり方を始めることができます。適切なビジネスユニットの雇用をする代わりに、いくつかのトレーニングとコーチングを受け、プロダクトオーナーとしてふるまいます。(長期的には、しかしながら、PdMという機能を追加することは利益をもたらすこともあります。他の記事で紹介)
・3つ目
用語としてのPOはアイディアである1人の人がプロダクトの責任を得ることで尊敬や強化されることを強めるものです。これは特にアジャイルのコンテキストのようなコラボレーションが価値、開発チームメンバーやステークホルダーが頻繁にプロダクトの決定に貢献する、というような場面で重要です。それは例えば、スプリントレビューの最後のインクリメントの話の議論の際に現れます。もし仮に、同意がない場合、POは何日も何時間もその場にいる人が議論というデッドロックを起こし、新しいアイディアを試す実験をする場がなくなることを避けて、必要な議論決断をします。
Now What?
つまりこのことから何を残すべきでしょうか？私の願いとしては過去のPdMとPOを分けて討論する過去から進み人々をラベリングするのをやめて欲しいです。私が働いている組織では、PdMが最先端のアジャイルPOになることに必死だったり、経験したのは逆にPOがPdMになることを待ちきれず最終的には戦略的なプロダクトの決定を担ったりしました。1人としてはRich Mirnovの進めているプロダクトピープル(Product People)という用語をフォローしようと決めている。
短期的には私たちはPOはPdMのロールだと考えてましょう。その人々は役割としてプロダクトマネジメントに関係のあるスキルを体得するべきだからである。それは、必要な戦略や戦術のスキルとリーダーシップも含みます。プロダクトマネジメントは複雑で、複数の訓練が必要で、時間と労力をかけやっとプロダクトのプロになれます。これは何日や何週間という話ではなく、何ヶ月や何年という時間がかかる話です。
付け加えると、私は用語としてPOかPdMのどちらかを会社内や資格で使うことを薦めています。例えばシニアやジュニアPdMもしくはジュニアやシニアPOという感じで雇用するなどです。これにより、混乱を減らし人々の結束の手助けになります。(6つのタイプのPOという記事を読むといいかもしれません）
最後に、顧客やビジネスの本質的なことをやれる、それが仕事のロールやタイトルのためじゃないことが良いと思っています。