製品マネージャー: 役割と初心者向けのベスト プラクティス

プロダクトマネージャーの役割と責任、仕事を進めるうえでのヒントなどを詳しく紹介します。

Sherif Mansour 作成者 Sherif Mansour
トピック一覧
ロゴ: Jira Product Discovery。

Jira Product Discovery 無料トライアル

新製品のアイデアの優先順位付け、コラボレーション、デリバリーを行い、最大の効果を創り出します。

最初に打ち明けますと、10 年前、アトラシアンのプロダクト・マネージャー職に応募するようにすすめられたとき、私はプロダクト・マネジメントが何であるかを知りませんでした。当時、これは珍しいことではありませんでした。プロダクト・マネジメントは何十年もの間、何らかの形では存在していましたが、「プロダクト・マネージャー」の肩書きが使われ始めたのは、ここ 20 年の話です。いまだに、「プロダクト・マネージャーの役割は何ですか」と会議で尋ねられることもあります(この話題を講演で取り上げたこともあります)。

プロダクト・マネージャーとは

プロダクト・マネージャーとは、顧客のニーズ、製品や機能が満たす大きなビジネス目標を特定し、製品の成功とは何かを明確にし、そのビジョンを実現するためにチームをまとめる人のことです。プロダクト・マネジメントを 10 年間研究し続けた結果、プロダクト・マネージャーになることの意味を深く理解できるようになりました。

プロダクト・マネージャーの概念が明確でないのは、その役割がまだ新しいことも一因でしょう。設計やエンジニアリングなど、確立された分野の実務担当者であればその専門分野で自らを分類できますが、プロダクト・マネージャーはまだその役割がどうあるべきかを定義しているところなのです。

ProductTank の優秀なプロダクト・リーダーであり創設者である Martin Eriksson 氏は当初、シンプルなベン図でプロダクト・マネジメントをまとめました。この図では、ビジネス、テクノロジー、ユーザー・エクスペリエンスの交わる場所にプロダクト・マネージャーが配置されています。Opsware の CEO である Ben Horowitz 氏は 15 年前、プロダクト・マネージャーを「製品の CEO」と呼んでいました。

私は Eriksson 氏と Horowitz 氏の両方に同意しますが、定義の解釈については常に同意できるわけではありません。Eriksson 氏の図を見た人は、プロダクト・マネージャーが 3 つの分野すべて(UX、テクノロジー、ビジネス)で製品を管理していると考えるでしょう。しかし実際には、プロダクト・マネージャーは 3 つすべてのニーズのバランスを取り、難しい決断とトレードオフを行う必要があると Eriksson 氏は述べています。Horowitz 氏の言葉を聞いた人は、プロダクト・マネージャーは何らかの特別な権限を持つと考えるでしょうが、実際にはそのようなことはありません。ただし、プロダクト・マネージャーは CEO のように目標を設定し、成功を定義し、チームの意欲を高め、成果に責任を負います。

プロダクト・マネージャーの責務と、UX、テクノロジー、ビジネスの重複を表したベン図 | アトラシアン・アジャイル・コーチ

プロダクトマネージャーの責務

具体的な責務は、組織の規模によって異なります。たとえば、大規模な組織であれば、プロダクト・マネージャーは専門家のチームに組み込まれます。研究者、アナリスト、マーケティング担当者が情報収集をサポートし、開発者と設計者が日々の実行、設計案の作成、プロトタイプのテスト、バグの発見を管理します。こうした組織のプロダクト・マネージャーはより多くのサポートを受けられますが、特定のビジョンの下で関係者の調整に多くの時間を費やします。

一方、小規模な組織のプロダクト・マネージャーは、全員の同意を得るまでの時間は短くなりますが、ビジョンの定義とその理解を伴う実作業により多くの時間を費やすことになります。

大まかに言って、優れたプロダクト・マネージャーは、次のような少数のタスクに時間を費やします。

  • ユーザーのニーズを理解し、説明する。

  • 市場を監視して、競合分析を開発する。

  • 製品のビジョンを定義する。

  • 製品のビジョンに合わせて関係者を調整する。

  • 製品の特徴と機能に優先順位を付ける。

  • 大規模な複数のチーム間で共通の理念を築き、独立した意思決定を促す。

プロダクト・マネージャーと製品所有者

チームが特定のアジャイル プラクティスに従っているかどうか (およびどのようなプラクティスか) によって、プロダクト マネージャーの役割がさらにわかりにくくなることがあります。たとえば、チームがスクラムを実践する場合は、プロダクト所有者も必要になります。

付箋とペンを使用してコラボレーションするプロダクト・マネージャーと製品所有者 | アトラシアン・アジャイル・コーチ

プロダクト・マネージャーは、調査、ビジョンの設定、調整、優先順位付けを通じて製品の方向性を定義しますが、製品所有者は、開発チームとより緊密に連携して、プロダクト・マネージャーのサポートの下に定義される目標に向けて実行していく必要があります。

一般的な分類:

日々のアクティビティに関与

クラウド アプリの概要 製品所有者

外部の関係者と協力

社内関係者と協力

製品ビジョンの定義をサポート

共有するビジョンの下でチームの実践をサポート

成功の概要を説明

成功を達成するための計画の概要を説明

ビジョン、マーケティング、ROI への責任

チームのバックログとフルフィルメント作業への責任

概念レベルで作業

日々のアクティビティに関与

しかし、チームの構成や慣行が変わると、責務が多少変わることもあります。たとえば、チームがスクラムを行わない場合(カンバンその他を採用しているなど)は、プロダクト・マネージャーが開発チームの優先順位付けを行い、全員の足並みを揃えるためにより大きな役割を担うことがあります。一方、チームがスクラムを行うがプロダクト・マネージャーがいない場合は、通常、製品所有者がプロダクト・マネージャーの責務の一部を引き受けます。

これらはすべてあっという間に非常にあいまいなものになってしまうことが多いため、チームは責務を明確に定義する必要があります。定義できなければ、あるグループが要件を書いて別のグループに丸投げし、そのグループが構築を行うという、ソフトウェア構築の旧来のやり方に戻ってしまうことにもなりかねません。そうすると、お互いの想定に不整合が生まれ、時間が浪費され、チームは顧客のニーズを満たさない製品や機能を作るというリスクを冒すことになります。

優れたプロダクト・マネージャーになるためのベスト・プラクティスとヒント

チームの種類が 1 つだけではないように、プロダクト・マネージャーの役割を遂行する方法も 1 つではなく、それこそがプロダクト・マネージャーの役割の最もエキサイティングな一面でもあります。過去 20 年の間に、もの作りは人気とアプローチの両方で大きく進歩しました。インタラクション・デザイナー、グラフィック・デザイナー、モーション・デザイナーなどに巧みに細分化されていったデザイナーとは異なり、プロダクト・マネージャーは全体として、いまだにそれぞれの強みのラベル付けに苦労しています。

問題を複雑化させているのは、人が領域としてのプロダクト・マネジメントを志し始めたばかりだということです。古い世代はエンジニアリング、設計、財務、マーケティングなどの領域から「プロダクト・マネジメントに配属された」のに対して、若い世代はプロダクト・マネジメントを念頭に置いてキャリアを開始しています。

どのような状況であれ、優れたプロダクト・マネージャーが伸ばすべきスキルや実践はいくつもあります。

強制的に優先順位を付ける

最近、ある同僚がプロダクト・マネジメントを政治家になぞらえていました。たしかにそう遠いものではないでしょう。プロダクト・マネージャーも政治家も、一定のリソースが割り当てられます。ともに、すべての人々のニーズを満足させることはできないことを知っているものの、そのリソースを使用してより大きな目標を達成するように実務担当者に要求します。

どのような段階においても、プロダクト・マネージャーには選択が必要になります。1 人の大口顧客を幸せにするが、100 人の小口顧客は不満を感じる機能にするかという選択、製品の現状を維持するか、新しい方向に進路を変えて範囲を拡大し、より大きなビジネス目標に合わせるのかという選択、きらびやかで光り輝くものに焦点を合わせるか、退屈だが重要なものに焦点を合わせるかという選択などです。

プロダクト・マネージャーがそれぞれの選択肢のコストとメリットを明確に理解しておけば、適切な判断を下せます。

状況を把握する

プロダクト・マネージャーは、他の誰よりも状況をよく把握しておく必要があります。まっさらな状態から始められることはほぼありません。おそらく、プロダクト・マネージャーはすでに勢いがあるところに放り込まれることになります。自分の現在地を知るための時間を取らずに始めると、誤った決断を下すことになります。

優れたプロダクト・マネージャーはブレーキをかけ、質問をすることから始めます。プロダクト・マネジメントの仕事を始めたばかりであれば、最初の数か月はできるだけ多くの顧客と話してください。できるだけ多くの社内関係者にも相談しましょう。ビジネス・モデルを把握し、歴史を把握し、さまざまな人がどのように影響を受けるかを把握します。そしてどのように決定が行われるのかを把握します。そうすることによって初めて、自分自身の決定を下すことができます。

チームが自ら意思決定できるようにする

プロダクト・マネージャーがすべての意思決定を行えるわけではありません。信じてください。実際に試したことがあるのです。一日の終わりには、ほぼいつも未読のメッセージが残り、予定は 2 つ、3 つと重なっていました。丸一日を質問への解答に費やしてもまだ終わらない、ということもありました。

しかし、すべての意思決定にかかわるのはプロダクト・マネージャーの仕事ではありません。少なくともそうすべきではありません。優れたプロダクト・マネジメントの鍵の 1 つは、共有の理念、あるいは、意思決定の方法とそれをエスカレーションするための一連の基準を作成することによって、チームが独自の意思決定を行えるようにすることです。自分自身で下すことができる意思決定であるにもかかわらずプロダクト・マネージャーに質問してくる人がいる場合、十中八九、自分で意思決定を行うために必要なコンテキストが与えられていないことが原因です。優れたプロダクト・マネージャーはそのようなコンテキストを構築します。

権威を振りかざすことなく影響を与える方法を学ぶ

私が知っているジュニア・プロダクト・マネージャーは、今ではチームのほぼ全員から尊敬されていますが、多くのメンバーは当初、もし選べるのであればより経験豊富なリーダーに替えてもらいたいと思っていました。彼女はメンバーの心をどのように変えたのでしょうか?彼女は 30 人で構成されるチームの 1 人ひとりをコーヒーに誘い、皆の話を聞いたのです。

影響力にはさまざまな形があります。まずは人々の声に耳を傾けて、彼らがどのように影響を受けているのかを理解することが先決です。自分の視点に彼らを引き入れる方法を考えるのは、その次です。自分の考えを裏付けるデータがないときでさえ、優れたストーリー・テラーになるには長い道のりが必要です。人によっては、あなたの仕事振りを見るまで納得しないこともあります。直接的な権限がなくてもリーダーを務めていくためには、誰にどのような手段を使うのが効果的かを理解することが大切です。

神経質にならない

トレードオフを行うことは、必然的に人を不幸せにします。最初に適切なトレードオフを行い、その後に、意思決定の経緯を説明することをお勧めします。意思決定について上手に説明できたとしても、全員が納得するとは限りません。しかし、多くの場合、意思決定の方法については尊重してくれるでしょう。たとえ尊重されない場合でも、優れたプロダクトマネージャーであればそれに対処する方法を見つけることができます。

優れたプロダクト・マネージャー

私個人の考えですが、本当に素晴らしいプロダクト・マネージャーというのは、100 万人に 1 人しかいません。そのようなプロダクト・マネージャーは、ここまでに述べてきたことをすべて実行し、信じられないほどの製品ビジョンを設定できる人です。先進的な考え方を持ち、非常に影響力があり、意思決定の背後にある理論的根拠を人々に説明し、データがなくても説得できるまれな存在です。Steve Jobs や Elon Musk を思い浮かべてもらうとよいでしょう。

我々はこのような人々を偶像化します。ひとつには、偉大な功績に顔と名前を付けることで満足感を得られるという理由があります。しかし、ほぼ間違いなく、優れた製品は 1 人の優れた思想家によって作られたものではありません。そのような製品は、実際に良い仕事をしている優れた人々のチームによって作られています。プロダクト・マネージャーの仕事は、その仕事を導く独自の方法を開発することです。

関連リソース