PdM（プロダクトマネージャー）とは（仕事・歴史・向いている人）

PdM（プロダクトマネージャー）は、プロダクトの「何を・なぜ作るか」を決め、作ったものが成果につながるまで責任を持つ仕事です。「どう作るか」はエンジニア・デザイナーと、「いつまでにどう進めるか」はチームと一緒に決めます。

PdM は部下に命令する権限を持たないことが多く、権限ではなく根拠と合意で人を動かすのが特徴です。範囲は会社によって大きく違い、要件を決めるだけの PdM もいれば、売上や利益まで責任を持つ PdM もいます。求人では「何に責任を持つか」を確かめます。

1日の流れは、朝に指標・問い合わせ・障害の連絡を確かめ、日中は打ち合わせとエンジニアからの相談への回答、その合間に仕様書を書く、という形が多いです。相談にすぐ答えられることは開発の速さに直結します。「PdM の返事待ち」で作業が止まらないよう、決めるべきことの一覧と期限を持っておきます。

PdM は職種名、PO はスクラムの中の役割名です。小さな会社では1人の PdM が PjM・PO・PMM を兼ね、大きな会社では分かれています。名前より「誰が何を決めるか」で考えると混乱しません。

日本では、受託開発の現場でプロジェクトマネージャーを「PM」と呼ぶことが多かったため、プロダクトマネージャーは PdM と略されることが多いです。2010年代の後半から、Web・SaaS 企業を中心に PdM の求人が増え、エンジニアやデザイナー出身の PdM も多くなりました。

必要なスキルは大きく、ユーザー理解（インタビュー・観察）、データ（指標・SQL・A/B テスト）、ビジネス（市場・収益・価格）、技術（仕組みと制約）、言葉にする力（仕様書・説明）、合意を作る力の6つです。全部が最初から得意な人はいないので、出身の職種の強みを軸に、足りないところを補っていきます。

営業や大口の顧客から「この機能をいつ出す？」と聞かれたときは、確定していない日付を約束しないのが基本です。約束が先に決まると、エンジニアの見積もりや品質の判断が後回しになります。

PdM は「何を・なぜ作るか」を決める役割です。技術を知らなくても仕様は書けますが、実現の難しさ・リスク・コストが想像できないと、議論が「できる／できない」の押し問答になりがちです。仕組みが分かっていると「どこが難しい？」「何を諦めれば早い？」と、選択肢の話に変えられます。

知りすぎて口を出しすぎる問題もあります。「Redis で作って」「このライブラリを使って」と実装方法まで指定すると、エンジニアの判断の余地を奪い、うまくいかなかったときの責任もあいまいになります。PdM が渡すのは目的と制約（期限・品質・予算・許せる遅れ）で、方法はエンジニアに任せます。技術の知識は「質問の質を上げる」ことと「リスクに早く気づく」ことに使う、と考えるとちょうどよい距離になります。

エンジニアへの良い質問

このサイトの ★ は職種ごとに意味が少し違います。エンジニアの ★ は「作れる・直せる」深さですが、PdM の ★ は「判断に使える」深さです。

使い方：まず PdM の章を通して読み、各トピックの末尾にあるリンクから、SRE や Web の詳しい解説へ必要なときだけ進みます。全部を読む必要はなく、「エンジニアの話に出てきた言葉を引く」辞書として使うのがおすすめです。SQL やネットワークの図はラボで実際に動かせるので、手を動かすと理解が早くなります。

技術の学び方