プロダクトマネジャーとは?クライアント案件で見てきた『プロダクトのCEOの正体』と3つの責務

『プロダクトマネジャー』って、ぶっちゃけ何をする人なのか、説明できますか？

株式会社Cameen 西村温裕ことおんゆーです。

近年、SaaS業界・テック業界・スタートアップ界隈で「プロダクトマネジャー(PdM)」という肩書きが急速に普及しました。日本でも数年前から急速に求人が増え、今では大手SaaSはほぼすべての企業がPdMを置いています。

でも、いざ「PdMって何をする人?」「PMやディレクターと何が違う?」と聞かれると、答えに詰まる方が多いんですよね。「エンジニアとデザイナーの間に立つ人」「ロードマップを作る人」というふんわりした答えになって、本質まで掘り下げて答えられる経営者は意外と少ない。これ、自分だけだと思ってませんか?

うちの事業では自社のSaaS開発でPdM相当の役割を分担運用していますし、クライアント案件のディレクションでPdMチームと並走することも多いです。「PdMを置いたけど何も変わらない」「肩書きはあるけど決定権がない」現場を、何度も見てきました。話を聞くと、ほぼ全員が「PdMの本来の責任範囲」を曖昧にしたまま、雑用係として扱ってしまっている。そういう共通パターンが見えてきたんですよね。

もう1つ繰り返し観察したのは、「PdMという肩書きを若手に与えるが、決定権を上層部が握ったまま」というパターン。これだとPdMの本領が発揮されず、組織的にもPdMという役割が機能しません。形式と実態の乖離が、日本のPdM運用の最大の課題です。

今回はその「今さら聞けないプロダクトマネジャー」を、表面的な解説ではなく、何のために存在する役割かという核心まで深掘りしていきます。読み終わる頃には、自社にPdMを置くべきか、どんな責任範囲を持たせるべきかが、紙に書き出せるレベルになっているはずです。

結論:プロダクトマネジャーの核心は「開発のディレクター」ではない

プロダクトマネジャーの本当の正体は、「プロダクトの何を作るかを決め、その結果に責任を持つ役割」です。「決める」と「責任を持つ」が両方揃って初めてPdMです。

調整役は「決定権」を持っていないので、PdMではありません。プロジェクトマネジャー(PM)は「決まったものを期日内に作り切る」役割なので、これもPdMではありません。PdMは「次に何を作るべきか」「何を作らないか」を意思決定して、その結果に責任を負う立場です。

「決める」中身は何かというと、ユーザー価値(これは欲しい人がいるか)、事業価値(売上・利益・成長に貢献するか)、技術実現性(現実的に作れるか)の3つを同時に成立させること。どれか1つだけ優れていてもダメで、3つの交点を見つけ続けるのがPdMの本業です。

この3つの利害は本質的に矛盾します。ユーザーが欲しがるものは事業として儲からないかもしれない、儲かるものは技術的に難しいかもしれない、技術的に作れるものはユーザーが欲しがらないかもしれない。この矛盾を毎回解きほぐして「交点」を見つけ出すのが、PdMの最大の知的労働です。

形だけPdMを置いて、ロードマップを書かせるだけ、ステークホルダーへの説明係にするだけ、というのが多発します。これだと「PdMという肩書きの調整係」止まりで、本来の意思決定機能が組織に入りません。本物のPdMが置かれた組織は、プロダクトの判断品質が桁違いに高くなります。

なぜ「プロダクトマネジャー」と呼ばれるのか。構造的な理由

もう少し深く掘ります。なぜこの役割は「プロダクトマネジャー」と呼ばれるのか。これには、ちゃんと理由があります。

プロダクトマネジャーという肩書きの起源は、1931年にP&Gの社内メモで提唱された「ブランドマン制度」とされています。Procter & Gambleが商品ブランドごとに責任者を置き、その商品の売上・利益・成長に専任で責任を持たせる仕組みでした。これがソフトウェア時代に入って、シリコンバレーで「プロダクトマネジャー」として再定義された経緯があります。

つまり、PdMという役割は最初から「特定の商品の運命に責任を持つ」ニュアンスを含んでいました。マネジャーという言葉は「管理者」ではなく「経営者(=ミニCEO)」の意味で使われていて、プロダクトを1つの事業として経営する人、というのが本来の語義です。「プロダクトのCEO」と呼ばれることがあるのは、この語源由来です。

SaaS時代のプロダクト系職種を見渡すと、プロダクトオーナー(PO)、プロダクトマネジャー(PdM)、プロダクトマーケティングマネジャー(PMM)、テクニカルプログラムマネジャー(TPM)、エンジニアリングマネジャー(EM)などが並んでいます。PdMはこの中で「何を作るか」の最終意思決定者として位置付けられ、POはスクラム内で優先順位を決める担当、PMMは作ったものをどう売るかの担当、と役割が分かれています。

業界の体感で言うと、日本企業ではPdMという肩書きが採用されているものの、実際の権限はディレクター・調整役レベルにとどまっているケースが多数派です。米国系SaaS企業ほど「プロダクトのCEO」として権限委譲されている例は少ない。これが日本のPdM運用の課題の中心です。

米国のSaaS企業では、PdMの年収はエンジニアと同水準かそれ以上で、上位5%のPdMは年収数千万円〜数億円のレンジに達します。これは「PdMがプロダクトのCEO」として扱われ、その判断品質が事業の運命を左右するという認識が業界に根付いている結果です。日本でも今後、PdMの社会的地位と報酬は、米国型に近づいていく流れが見られます。

近年は、ソフトウェアプロダクトだけでなく、コンテンツプロダクト・教育プロダクト・サービスプロダクトといった非ソフトウェア領域にもPdMの考え方が広がっています。「決める人と責任を取る人を一致させる」という発想自体は、業界を問わず通用するからです。日本のメディア企業・教育企業でもPdM相当の職種が増えてきました。

PdMの仕事は「読者の頭の中」でなく「3つの利害の同時調整」

もう少し解像度を上げます。PdMの仕事の中身を、現場の動きで5つのステージに分けて整理します。

ステージ1:ユーザーの未解決ニーズを発見する

ユーザーインタビュー、サポート対応の傾向分析、利用ログの観察、競合プロダクトの研究。これらから「ユーザーがまだ解決できていない問題」を発見するのがスタート地点です。

多くのPdMがここを飛ばして、社内会議の中で「次に作るもの」を決めてしまいます。それだとプロダクトが内輪向けになって、ユーザーの実需と乖離していく。本物のPdMは、ユーザー接点に多くの時間を使います。「PdMの時間の30%以上はユーザー接点」というのが業界の標準的な目安です。

ステージ2:事業価値で優先順位を決める

ユーザーニーズを発見したら、次は事業価値で並べ替えます。「これを作ると売上が上がるか」「コストを下げるか」「リテンションが伸びるか」。事業数字に紐付かないユーザーニーズは、優先順位が下がります。

ここで「ユーザーが言うから作る」だけの判断をすると、優先順位がカオスになって、開発リソースが分散します。事業の数字で優先順位を引くのがPdMの責任です。

ステージ3:技術実現性をエンジニアと詰める

「これは作れるのか」「どのくらいの工数か」「技術的負債を増やさないか」。エンジニアと議論して、技術実現性の見積もりを取ります。理想だけ追って「あれもこれも」と要求するPdMは、エンジニアに嫌われて長続きしません。

逆に、技術実現性ばかり気にして「できることしか言わない」のもPdMの仕事ではない。エンジニアと対等に議論しながら、技術と事業の交点を探るのが本領です。

ステージ4:作るものを意思決定する

ユーザーニーズ・事業価値・技術実現性が出揃ったら、次に作るもの・作らないものを意思決定します。「やる」と「やらない」の両方を決められるのがPdMの権限です。

「やらない」を決められないPdMはバックログがパンパンになって、結局何も作り切れません。プロダクトのCEOとして、優先順位の低いものはきっぱり「やらない」と宣言する力が必要です。業界では「優れたPdMの90%の決定は『何を作らないか』」という言葉があるくらい、「捨てる判断」がPdMの核心スキルです。

ステージ5:作った結果に責任を取る

リリース後、ユーザーの反応・事業数字への影響を観察します。狙い通りなら継続、外れたら次の意思決定で軌道修正。「決めたこと」の結果を引き受けて、次の決定に学習を反映する。

外したときに「エンジニアが期待通り作らなかった」「マーケが下手だった」と責任転嫁するPdMは、信頼を失います。決定したのは自分、結果も自分の責任、という腹のくくりがPdMの最後のステージです。

身近な話で全体像をつかむ

ちょっと身近な話で、全体像を掴み直しましょう。

個人経営のラーメン屋の店主に置き換えてみます。店主は毎日、こんな判断をしています。「来月の新メニューは、塩か味噌か」「夏に向けて冷やしを増やすか」「常連が言う『辛さアップ版』を出すか」「原価が上がってる素材を変えるか」。

店主はその判断のために、3つの視点を同時に見ています。お客さんの声(「辛いの欲しい」)、店の利益(原価率と単価)、自分の調理力(無理なく作れるか)。どれか1つだけ優れていても、店は回りません。お客さんが欲しがる「カニラーメン」を導入しても、原価が高すぎて赤字なら出せない。逆に、原価が安くても、お客さんが食べたくないメニューは意味がない。

この個人店主の判断こそ、PdMの仕事の本質と同じです。お客さんの声=ユーザー価値、店の利益=事業価値、自分の調理力=技術実現性。この3つの交点を毎日見つけて、メニューに反映するのが店主の責任。外したらお客さんが来ない、売上が落ちる、自分が困る。

「決める」と「結果に責任を取る」が一致しているのが、個人店主とPdMの共通点です。逆に、決める権限はあるけれど結果の責任がない人、結果は問われるけど決める権限がない人、はPdMではありません。両者が分離していると、誰も本気で「次に何を作るか」を考えなくなります。

うちの事業でも、有料コンテンツ商品をプロダクトとして見たときに、毎月「次の改訂で何を加えるか・何を削るか」を判断しています。受講生さんの声、購入率や継続率の事業数字、自分の制作キャパシティ、この3つを同時に見て、優先順位を決める。これはPdMの仕事の縮約版とも言えます。役割としては自分1人で兼ねているけど、判断の構造は同じです。

もう1つの身近な例えは、レストランの料理長です。料理長は単に料理を作る人ではなく、メニュー全体を設計する人。来店客のニーズ・原価のバランス・厨房スタッフの技術レベル、すべてを踏まえて「今期のメニュー」を決定し、外れた料理は削り、当たった料理は深掘りする。PdMもまさにこの料理長型の役割を担っています。

機能するPdMが負っている3つの責務

責務1:何を作るか・何を作らないかを決める権限を持つ

機能するPdMには、開発する機能の優先順位を最終決定する権限が与えられています。経営層・営業からの要望をそのまま受け入れる窓口ではなく、要望を取捨選択して優先順位を引く立場。

権限がないPdMは、本質的にディレクターでありPdMではありません。「決められない肩書きとしてのPdM」が組織に溢れているのが現状です。経営層が「最終判断は俺が下す、PdMは案を持ってくるだけ」という構造の組織には、本物のPdMは育ちません。

責務2:ユーザー価値・事業価値・技術実現性を同時に成立させる

3つの利害は本質的に矛盾します。ユーザーが欲しがるものは事業として儲からないかもしれない、儲かるものは技術的に難しいかもしれない、技術的に作れるものはユーザーが欲しがらないかもしれない。

機能するPdMは、3つの交点を毎回探し続けています。「ユーザーの声をそのまま実装」「数字だけ追って機能を量産」「エンジニアの好みで決める」のいずれかに偏った時点で、PdMの責務を半分しか果たしていません。

責務3:決めた結果に責任を引き受ける

機能するPdMは、自分が決めたことの結果を引き受けます。リリース後の指標悪化、ユーザーからのネガティブなフィードバック、社内の批判。これらを「決定者として」受け止める姿勢があります。

逆に、責任を引き受けないPdMは、何度も同じ意思決定ミスを繰り返します。失敗を自分の判断ミスとして認められないと、学習が起きないからです。学習ループが回らないPdMは、組織内で信頼を失っていきます。

PdMが「機能しない」典型パターン3つ

クライアント案件のディレクションで見てきた中で、PdMが機能不全に陥るパターンはこの3つに集約されます。

クライアント案件と自社事業で見てきた本音

自社のSaaS開発でPdM相当の役割を分担運用してきた経験と、クライアント案件でPdMチームと並走してきた中で、見えてきた本音を少しお伝えします。

本音1:本物のPdMは肩書きでは見分けがつかない

「肩書きがPdM」かどうかで、本物かどうかは判別できません。エンジニアやマーケでも、3つの責務(決める権限・3利害の同時調整・結果責任)を実質的に負っている人は、PdMとして機能しています。逆に肩書きがPdMでも、責務が伴っていなければPdMではない。

採用面接で「PdM経験◯年」と書いていても、実態は調整役だった、というケースは普通にあります。経験年数より「これまでどんな意思決定をして、どんな結果が出たか」を聞くほうが、本物の判別に近づきます。

業界で評価されているPdMは、過去の意思決定の事例を具体的に語れる人物です。「このタイミングでこの機能を作る判断をして、結果として売上が30%伸びた」「この機能を捨てる判断をして、開発リソースを別領域に集中させて成果が出た」、こうした具体的な「決定→結果→学習」のサイクルが豊富なPdMが、本物のPdMです。

本音2:PdMが育つのは、決断と失敗を繰り返した数

PdMはスキルだけで育つ職種ではなく、決断と失敗の経験量で育ちます。「これを作る・これを作らない」を100回決めて、20回失敗して、80回うまくいく経験を積んだPdMは、判断の精度が桁違いです。

逆に、上司や経営層の意思決定の伝書鳩をしてきた人は、何年経ってもPdM筋肉が育ちません。「自分の判断で決めて、結果を引き受けて、振り返って次に活かす」の経験ループの回数が、PdMの実力を決めます。組織がPdMを育てたいなら、判断の機会を与えて失敗を許容する文化が前提条件です。

米国のPdM育成プログラムでは、「Decision Journal(意思決定日誌)」を継続的に書く習慣が標準です。決定した内容・その理由・期待結果・実際の結果・学び、を体系的に記録する。これによって自分の判断パターンを客観視し、判断精度を継続的に改善していくのです。日本のPdM教育でも、この習慣が広まりつつあります。

1人事業主が今日からPdM思考を取り入れる方法

ここまで読んでくださった方、お疲れさまです。最後に、組織にPdMを置けない1人事業主や小規模事業者でも、PdMの思考だけ取り入れる方法を置いておきます。

シンプルですが、1人事業主でもPdM思考の素地を作ることができます。

よくある質問(FAQ)

まとめ

で、結局プロダクトマネジャーとは、こういうことです。

• PdMの核心は「開発のディレクター」ではなく「何を作るか決め、結果に責任を持つ役割」
• 本質は3つの責務(決める権限・3利害の同時調整・結果責任)を一致して持つこと
• 1人事業主でも「自分のプロダクトを定義→3視点で月次判断→振り返り」でPdM思考は取り入れられる

肩書きを置くことが目的なのではなく、「決める人と責任を取る人を一致させる」仕組みを作ること。これがPdMの本来の役割です。導入を検討するなら、まずは責任権限の中身から設計してみてください。

ではでは。