プロダクトマネージャーとは？テクノベート時代のリーダーの役割を考える #2

第1回では、全ての企業が「顧客中心主義」であるために、ユーザーやマーケットとコミュニケーションをし続け、プロダクトを最適な形へ進化させ続けなければならないとお伝えした。成功しているテック企業は、この役割をプロダクトマネージャー（以下、PDM）というリーダーに担わせている。シリコンバレーの企業をはじめ、日本国内でも成功しているテック企業は、共通してPDMを設け、キーマンと位置づけている。では、PDMとは具体的に何なのか。その役割を考えたい。

ここでは、PDMを「テクノロジーを活用してプロダクトの価値を創出し続ける人」と定義する。「プロダクト」とは、企業が顧客に販売する製品のことを指し、ソフトウェアやデータなどの物理的実体のない無体物も含んでいる。「価値を創出し続ける」とは、従来の開発をして終わりのプロダクトではなく、開発に終わりがなく常にアップデートさせ続けて価値を作り出し続けることを意味している。

ポイントは、プロダクトに長期的にコミットして価値を上げ続けることである。プロダクトの価値を上げ続けるには、単に開発業務だけに責任があるのではない。顧客とプロダクトに関わる全てに責任を持つ。それゆえに、プロダクトマネージャーに関する多くの著書を持つジェームズ・ルイス氏は、『The Product Manager’s Desk Reference』でプロダクトマネージャーのことを「miniCEO」とまで呼ぶ。

今までに日本で言われてきた「プロマネ」とは、プロジェクトマネージャー（PM）であった。しかしPMとPDMは似て非なる。

PMは、担当するプロジェクトが納期を超過しないかといった、スケジュールの不安を減少させるように物事を進める。一方、PDMは、プロダクトが顧客やマーケットに受け入れられず、継続的に提供できなくなってしまう不安を減少させるように物事を進める。この前提には、プロダクトに対する考え方の違いが存在する。

これまでプロダクト開発は、時間をかけて企業が思う最高品質のプロダクトを開発していた。そのため、リリース時点での品質が一番高かった。しかし、外部環境は変化したことでプロダクト開発に対する考え方は変わった。不確実性が高く、変化のスピードも速い環境下では、リリース段階では、最小限の機能でスタートさせ、そこから継続的にアップデートさせて進化させ続ける方法へ変わったのである。そのため、プロジェクトはリリースした時点で終わるのではなくなり、常にアップデートし続けるPDMが必要となった。

■時系列でみる責任範囲
時系列で見ると、PDMはプロダクトライフサイクル全てにおいて責任を持つ。プロダクトを生み出すところから始まり、どの段階でどのユーザーを対象にどのように機能を拡充させていくかを考えていくのだ。逆にPDMがいない組織では、プロダクトの成長を継続的に考えることができず、プロダクトの継続的進化が非効率になる。

■領域でみる責任範囲
良いプロダクトは、BTD（ビジネス、テクノロジー、デザイン）の3領域を考えなければならない。簡潔にいうと、価値があって（ビジネス面）、使いやすくて（デザイン面）、実現可能（テクノロジー面）なプロダクトである。領域で見ると、PDMはこの3つの中心部分に責任をもつ。

もしPDMがいなければ、バランスを欠いたプロダクトになるだろう。例えば、ビジネス寄りの立場が強い場合、声の大きな要望を重視して機能拡充し、一貫性のない場当たり的な開発や、無理なスケジュールが続きエンジニアが疲弊する。

一方、エンジニアの立場が強い場合、ユーザーが欲しいものではなくエンジニアが作りたいものを優先したプロダクトになり、なかなか収益化できない場合もある。

デザイン領域が弱い場合は、ユーザー視点の操作フローになっていないなどUIが悪いものができてしまう。この3つを幅広く理解してバランスを取ることがPDMの役目である。

また、シリコンバレーで10年以上PDMをしている曽根原春樹氏は、PDMの責任範囲は「WhyとWhatを決め、How、Who、Whenを関係各所と決め、Doで常に状況を把握して意思決定する」ことだと言う。

BTD全ての領域は専門性が高く、１人で最適な意思決定ができるわけではない。むしろ関係各所の得意なメンバーと調整して決めるのだ。PDMが意思決定するのは、ユーザーが何に困り、それをどう解決できるのかというWhyとWhatに限るのだ。

ここからは、PDMをより理解するために、PDMと役割を分ける職種を説明していきたい。肩書きや役割の名称については、各社で、さまざまな呼び方をしているため、同じ呼び方でも同じ役割を担っているとは限らない。ただ、呼び方はどうであれ、成功している企業は共通して、こうした役割を担当する人を置いて、それぞれの役割を果たして良いプロダクトができている。

なお、スタートアップ企業はCEOやCTO自らが全ての役割を担うこともあるし、組織の状況によって異なる。しかし、ある一定フェーズが大きくなると役割を分けていくことが多い。以下は一般的に成功している企業に見られる役割分担である。

（1）プロジェクトマネージャー（PJM）とプロダクトマネージャー（PDM）
シリコンバレーではプロジェクトマネージャーをプロダクトマネージャーと区別するためにPJMと呼ぶこともある。この違いは上記で説明した通り、時間軸や責任の範囲が違う。PDMはプロダクトに責任を持ち続け、PJMは期日がある1つのプロジェクトにのみ責任を持つ。

PDMが必要でPJMが不要というわけではない。開発の要件が決まれば、チーム単位でPJMが開発作業のスケジュールや進捗管理を行う。そのため、1人のPDMに対して、複数のプロジェクトが動き、複数のPJMがいることが多い。専任のPJMが置かれることがあれば、PDMが担うこともある。エンジニアマネージャーが兼務することもある。

（2）プロダクトマーケティングマネージャーとPDM
プロダクトマーケティングマネージャーは、マーケティング活動を指揮するもので、市場浸透に責任をもつ。販売チャネルから売り込むためのツール提供、オンラインマーケティングなど。マーケティングだけでも専門性が高いことから、役割を分けることが多い。PDMとの連携でいうと、マーケティングマネージャーは、顧客からの声をPDMへフィードバックして製品改善に役立てる。

（3）エンジニアマネージャーとPDM
エンジニアマネージャーは、エンジニアチームの生産性を最大化することに責任をもつ。具体的には、エンジニアとの1on1などでモチベーションを考えたり、チーム文化や評価制度を考えたり、採用や解雇も担うこともある。PDMと比較すると、エンジニアマネージャーはWhoに責任を持つ。

（4）ソフトウェアエンジニアとPDM
ソフトウェアエンジニアは、HowとWhenに責任を持つ。プロダクトマネージャーは、自分自身がコードを書くことはほとんどなく、具体的にどのように作り、どれくらいの時間、コストがかかるのかについては、ソフトウェアエンジニアの方がより正確に決めることができる。そのため、PDMはエンジニアたちと主従関係があるわけではなく、対等な関係で協力し合う。

（5）デザイナー
デザイナーは、ユーザーの立場に近い視点で、プロダクトの使いやすさを実現する。操作フローやビジュアルデザインといったUIや、ユーザーのプロダクト利用前後の価値まで考えていくUXについて、PDMと議論をしてデザインする。そのため、PDMはエンジニアと同じくデザイナーとも主従関係ではなく、対等な関係で進める。

組織上PDMの位置付けは各社さまざまだが、分類すると大きく3パターンあった。1つは開発部門に入りエンジニアと近いパターン。もう１つは、マーケティング部門に入りマーケターと近いパターン。最後は、独立した部門として設けられているパターン。どこに位置づけるのが最適なのかを考えると、その会社の事情やフェーズ、事業特性によるだろう。

例えば、あるB2BのSaaSを提供している会社は、セールスが重要なため、PDMはマーケティング部門に入り、ビジネス視点の意見をより広く吸い上げていた。一方B2C向けのアプリで、UI、UXが重要となることから開発部門に入っているPDMもいた。PDM部が独立した部門でない場合は、BTDのバランスが欠けないよう注意が必要である。

実際のところ、多くの企業はこういった事業特性以外に、そのPDM自身の人間特性や組織内の人間関係などの配慮があり、組織上の位置付けは個別事由が多かった。組織上何が最適かは、自身の会社内の事情やフェーズなどを踏まえて決めるのがよい。しかし、重要なことは、どの部門にPDMを位置付けようが、BTDのバランスをとり、プロダクトの継続的な進化に責任を持ち、PDMとしての役割を遂行できる環境を用意することである。

以上述べてきたが、PDMの責任の範囲はあまりにも広い。この責任という言葉も解釈があり、餅は餅屋に任せ、責任というよりはその領域を配慮するレベルが多かった。しかし、外資系企業のPDMは、プロダクトの売上に責任を持ち、自身で事業計画を描くPDMもいて、まさにminiCEOという印象を持つことが多かった。責任という言葉をどう解釈するかは各社さまざまだが、PLCのすべてのフェーズと、BTD3領域の中心部分の責任を負うことは共通する。

では、このプロダクトマネージャーになるための方法や、必要とされるリーダーシップとは何なのか。第3回から述べていきたい。

（調査協力）松浦 卓哉／石井 紀穂