プロダクトマネージャー（PM）の基本｜仕事の中身と1日の動き、PjM・PMMとの違い
- 最終更新日：2026/10/27
プロダクトマネージャー（PM）の基本を調べると、プロジェクトマネージャーとの違いや「ミニCEO」といった表現が出てきて、結局何をする人なのか分かりにくいと感じる方は多いはずです。この記事では、プロダクトマネージャー（PM）の基本を、役割の定義、ある平日の動き、隣接する職種との線引き、仕事で使う用語の順に整理します。読み終えるころには、求人票の「PM」が自分の想像する仕事かどうかを見分けられるようになります。
プロダクトマネージャー（PM）の基本は「何を、なぜ作るか」を決める役割
プロダクトの成果に責任を持つ職種
プロダクトマネージャーは、自社のサービスや製品が顧客にとって価値を持ち、事業としても成り立つように、企画から改善までを通して方向づけを行う職種です。転職メディアの解説でも、プロダクトのライフサイクル全体を管理し、顧客、ビジネス、開発の三者のバランスを取る役割として説明されています。作る人ではなく、作るべきものを決めて、決めた理由を関係者に説明できる人だと捉えると、全体像がつかみやすくなります。
この記事で「PM」と書くときの範囲
日本の求人では「PM」がプロジェクトマネージャーを指す場合もあります。この記事でのPMは、プロダクトマネージャー（PdMと表記されることもあります）です。求人票では、業務内容に「ロードマップ」「ユーザー課題の特定」「KPI設計」があればプロダクト側、「工数」「進捗」「ベンダー管理」が中心ならプロジェクト側と読み分けられます。
架空のBtoB SaaS企業で追う、ある平日の動き
ここでは、請求書管理のクラウドサービスを運営する架空の会社を例に、PMの1日を追います。実際の動きは会社の規模や体制で大きく変わるため、あくまでモデルケースとして読んでください。
朝は数字と問い合わせを見る
始業後すぐに、前日の利用状況のダッシュボードを開き、新規登録からの初回請求書作成率や解約の兆しを確認します。続けてカスタマーサポートに届いた問い合わせの傾向を見て、「請求書の取引先一覧が探しにくい」という声が先週より増えていないかを見ます。数字と声の両方を見るのは、片方だけでは原因を取り違えやすいためです。
昼は開発チームと仕様をすり合わせる
スプリントの計画会議では、エンジニアとデザイナーに対して、取引先一覧の検索改善を今回の開発に入れる理由を説明します。「何を」「なぜ」はPMが示し、「どう作るか」は開発チームの見積もりや技術判断を尊重します。ここで技術的な制約を理解していないと、実現できない仕様を求めてしまうため、開発の基礎知識が役立ちます。
夕方は取捨選択と社内への説明
営業からは「大口顧客が承認フローの追加を求めている」という要望が届きます。要望をそのまま開発に回さず、同じ課題を持つ顧客が何社いるか、既存機能で代替できないかを確かめ、優先度を決めます。見送る場合も、理由を営業に伝えて納得を得ることが仕事の一部です。
リリース後に効果を確かめる
先月出した機能が、狙った行動を増やしたかを検証します。利用率が上がらなければ、導線なのか機能そのものなのかを調べ、次の改善案を立てます。作って終わりにしない点が、プロダクトを担当する職種の特徴です。
プロジェクトマネージャーやPMMとの線引き
プロジェクトマネージャーとの違い
プロダクトマネージャーは「何を」「なぜ」作るかに責任を持ち、プロジェクトマネージャーは「いつまでに」「どうやって」作るかを担うと整理されます。ただし、小さな会社では一人が両方を兼ねることも多く、求人票の職務内容で実際の比重を確かめる必要があります。
PMMとの違い
プロダクトマーケティングマネージャー（PMM）は、市場への届け方や訴求、販売面を主に担う職種です。PMが開発側との距離が近いのに対し、PMMは営業やマーケティングと近い位置で動きます。
プロダクトオーナーとの違い
プロダクトオーナーはスクラムで定められた役割で、スクラムガイドではプロダクトバックログの管理などを通じてプロダクトの価値を高める責任を持つとされています。PMがいる会社では、PMがプロダクトオーナーを兼ねる場合もあれば、別の人が担う場合もあります。
仕事で使う言葉と成果物の基本
ロードマップとバックログ
ロードマップは、数か月から1年程度のプロダクトの方向性を示す計画で、細かい機能名より「どの課題を解決するか」を軸に書くのが一般的です。バックログは、これから作る機能や改善を優先順に並べた一覧で、開発チームが日々参照します。
KPIと検証の仕組み
KPIは、プロダクトの状態を測る指標です。たとえば請求書サービスなら、初回の請求書作成率や月次の継続率が候補になります。指標は多いほどよいわけではなく、今回の施策で動かしたいものを1つ決めておくと、リリース後に成否を判断しやすくなります。
仕様や要件をまとめる文書
課題、対象ユーザー、成功の基準、やらないことを1つの文書にまとめ、開発チームと共有します。形式は会社ごとに違いますが、「なぜ作るか」と「何をもって成功とするか」が書かれていることが共通の要点です。
必要とされる力を、場面に結びつけて確かめる
決める力と、説明する力
優先順位をつける場面では、論理的に考える力と、見送る案の関係者に理由を伝える説明力が同時に問われます。解説記事でも、マネジメント、コミュニケーション、市場の調査と分析、技術面の知識が主なスキルとして挙げられています。
技術とデザインの知識は、深さより会話の成立
コードを書けることが条件になる会社は多くありませんが、APIやデータベースの基本を知らないと、開発チームの見積もりの妥当性を判断できません。UIの良し悪しを語るには、デザイナーが何を根拠に提案しているかを聞き取れる程度の知識が助けになります。
会社の規模で、仕事の幅が変わる
数十人規模のスタートアップでは、PMが顧客インタビューから要件整理、時にはサポート対応まで担うことがあります。大企業では、担当領域が機能単位に分かれ、調整相手が多くなる代わりに、一つの領域を深く扱えます。応募前に、担当する範囲を面接で確かめておくと入社後の食い違いを減らせます。
資格より先に整えたい基礎と向き不向き
必須の資格はなく、実績が見られる
PMになるために必須の資格は一般にないとされ、企画、開発、営業、デザインなど、どの経験からでも入口はあります。具体的な道筋はプロダクトマネージャー（PM）になるための入口で整理しています。
向いている人の傾向
関係者の意見が割れたときに、感情ではなく根拠で優先順位をつけられる人は向いています。一方で、自分で手を動かして作ることだけに喜びを感じる人は、決める役割との間にギャップを感じるかもしれません。収入面の目安はプロダクトマネージャー（PM）の年収に、その後の進み方はキャリアパスにまとめています。
身近なサービスの改善案を1つ書いてみる
まず、普段使っているアプリを1つ選び、「誰の、どんな困りごとを、どの指標で測るか」を3行で書いてみてください。その3行を、エンジニアの友人や同僚に見せて、作る側から見た難しさを聞くと、PMの仕事の半分を疑似体験できます。