プロダクトマネージャーとプログラムマネージャーの共通点と相違点

プロダクト・マネジメント、プロジェクト・マネジメントでは、よく似た役割名がたくさんある。

いくつか挙げよう。

• プロダクト・マネージャー
• プロダクト・オーナー
• プロジェクト・マネージャー
• プログラム・マネージャー
• スクラムマスター

最後の「スクラムマスター」は明らかに名前は違うが、たびたび「プロジェクト・マネージャー」と混同されるので一緒に含めた。

先の4つは、字面は似ているが、異なる役割である。

順番に見ていこう。

まず、プロダクト・マネージャーとプロダクト・オーナーだが、両方とも「プロダクト」に責任がある。役割名にプロダクト～とあるから、当たり前と言えるが、プロダクトのスペックやデザインだけでなく、その根拠を示す役割である。英語なら、”What”と”Why”を担う人物である。

あるコンセプトの製品・サービスを、なぜこのタイミングで投入するのかを決める。マーケット、および顧客ニーズを理解し、課題設定し、その課題を製品・サービスの枠組みで解決していく人物である。

プロダクト・オーナーはビジネスドメインに特化した役割で、利用者の立場から、プロダクトやユーザー体験をデザインし、開発チームやITに作ってもらう。

一方、プロダクト・マネージャーは最新のテクノロジーについても積極的に関わり、利用者として「操作性」や「可用性」など品質要求を定義しつつ、そのソリューションであるつくり方についても関わっていく。

プロダクトオーナーはビジネスドメインに特化しているから、アイデアをカタチにするには、プロダクトのニーズを開発側に伝えなくてはならない。そのため、日々、開発チームと会話し、要求を伝達する。
また、定期的にプロダトインクリメントをチェックし、開発チームにフィードバックを提供する。

プロダクト・マネージャーは、サプライヤーサイドにも関与することから、プロダクト・オーナーより担当する作業範囲は広い。

いずれの役割も、推する製品・サービスの中心的人物で、プロダクトのコンセプト・デザインを明確化し、利害関係者を巻き込み、フィードバックを得て、プロダクトの魅力と投資対効果を最大化する人物である。
組織の中で、推するプロダクトについて、マーケットを深く理解し、誰よりも深く考え、戦略を練り、製品・サービスに対する溢れるパッションをもっていなくては務まらない。

一方、プロジェクト・マネージャーは、英語で言う”How”と”When”を担う役割である。どのようにして、いつデリバリーするかコミットする。予算、期限、スコープ制約の中、バランスをとりながら、アイデアをカタチにしていくのがミッションだ。
PMがコミットするのは、プロジェクトで定義された成果物を期限・予算内に納めることである。
定義されたプロダクトが、実際に顧客価値を創造するかどうかは、プロダクト・オーナやシニアユーザーが担保する。

スクラムマスターは、アジャイルコミュニティ（スクラム）で登場する一般的な役割である。

開発チームが、モチベーションを維持し、持続可能なペースで、ハッピーに、作業に取り組めるよう支援する。

また、スクラムチーム全体のバランスをとる。
プロダクト・オーナーが開発チームに厳しすぎれば、盾になり、チームを守る。開発チームに甘すぎれば、次のスプリントでバックログを多めに依頼してもらい、チームの成長を促す。
チームに命令はしないが、チームとPOに多くの気づきを与える役割である。

また、スクラムのプロセス・ファシリテーターとして、組織全体のスクラム理解を深め、アジャイルチーム（スクラムチーム）に対して、スクラム・プラクティスを徹底するよう促す。
当然なことであるが、スクラムマスターは、アジャイル・マインド、スクラムの価値基準、スクラムセレモニー（イベント）、スクラムの作成物、そしてスクラムのルールに一番詳しい人物でなくてはならない。

最後にプログラム・マネージャーである。
プログラム・マネージャーは「成果」にフォーカスする。
成果を生み出す為、好ましい変化を生み出す為、きっかけとなるモノやサービスを導入する。プログラム・マネージャーが意識するのは、製品やサービスではなく、それらを使って最終的に獲得される、結果としての成果である。

また、プログラムでは成果のベースとなるプログラム・ビジョンを策定する。
なぜ、擁する成果が組織に必要なのか、ビジョンを通して明確にする。

プロダクトと同様に”What”/”Why”を担うという意味で、プログラムはプロダクト・マネジメントに近い要素を含んでいる。
プロダクトがひとつの「製品やサービス」を通してビジョンを実現していくのに対し、プログラムでは「成果」を通してビジョンの実現を目指す。
そして、成果を獲得するため、複数の製品やサービスを導入する。

プログラム・マネージャーも、プロダクト・マネージャー同様、課題のソリューションを提供し、サプライヤー側にも関与する。
使用可能なテクノロジーを評価し、実装戦略についても検討する。
通常、プログラム傘下にプロジェクトや定常業務があり、これらをバランスよく組み合わせ、ベクトルを合わせ、全体を統制する。

共通性があるという意味で、プログラム・マネージャーからプロダクト・マネージャーまたはプロダクト・オーナーへのコンバートは可能である。また、その逆であるプロダクト・オーナーやプロダクト・マネージャーからプログラム・マネージャーへのコンバートも比較的しやすいだろう。

一方、プロジェクト・マネージャーやスクラムマスターからプロダクト・マネージャーやプロダクト・オーナーへのキャリアチェンジは、一般的に困難を伴う。

“How”/”When” から”What”/”Why”への変更になるため、未知の領域を含む。
積極的に学んでいくモチベーション次第だが、横展開するには、ドメインに対する興味とパッションが不可欠だ。

チェンジマネジメント ― 組織と人材を変える企業変革プログラム