未経験からわかる！プロダクトマネージャー（PM）とは？仕事内容・スキル・学び方を実体験で解説

PMを目指す私が最初につまずいた「プロダクトマネージャーとは？」問題

現在、私は社内のリスキリング制度を活用して、プロダクトマネージャー（PM）を目指して学習中です。

元々メーカーの技術職としてユーザーとはあまり関わらない仕事をしてきました。

ユーザーに寄り添いもっとプロダクトの本質的な価値を届ける仕事がしたいと考え、PMを志しました。

ITや開発のバックグラウンドがない自分にとって、PMという職種はまさに未知の領域でした。

学び始めた当初、最初につまずいたのが「そもそもプロダクトマネージャーって何をする人なの？」

という素朴な疑問でした。

ネットで「PMとは」と検索すると、「ビジネス・ユーザー・技術の交点に立つ存在」「製品のライフサイクルに責任を持つ」「WhatとWhyに責任を持つ」など、いろいろな説明が出てきます。

でも、具体的に「交点とはどういうこと？」「ライフサイクルに責任を持つって具体的にどんな作業？」といった部分がふわっとしていて、実感を持って理解するのが難しかったんです。

私はその頃、社内のデジタルサービス部門に一時的に配属されており、会議にはPMやエンジニア、デザイナーが集まっていました。

しかし、誰が何を決めているのか、どこからどこまでがPMの役割なのかがよく分からず、ただ黙って議事録をとる毎日でした。

たとえば、会議で「この機能を優先しましょう」と話が進んでも、誰がその決定をしているのか曖昧だったり、エンジニアが「これは実装に時間がかかる」と言ったときに、PMがどのように判断を下しているのかが見えてこなかったり…。

そんな曖昧さに囲まれながら、「PMって、結局なにをしているんだろう…」というモヤモヤだけが残りました。

この記事は、そんな過去の自分と同じように「PMのことがよくわからない」と感じている方に向けて書いています。

一歩ずつ理解を深めながら、プロダクトマネージャーの役割・スキル・働き方について、できるだけやさしく、実務目線でお伝えします

プロダクトマネージャー（PM）とは？簡単に言うとどんな仕事？

プロダクトマネージャー（PM）とは、

「ユーザーにとって価値あるプロダクトを生み出し、継続的に成長させる責任者」です。

たとえば、オンライン学習サービスのPMであれば「学習継続率が低い」という課題に対して、新機能やUI改善を通じてユーザーの継続利用を促すようなアクションを企画・推進します。

もう少しかみくだいて言うと、「なにを・なぜ作るのか」を決める人。

エンジニアやデザイナーと連携しながら、ユーザーに届けるべき機能や体験を企画し、開発チームと共に実現していく。

たとえば、こんな仕事をしています

実際、私が社内で観察したPMの先輩は、次のような業務に取り組んでいました。

• ユーザーインタビューでニーズを把握し、課題を明確にする
• 「この課題に対して、どんなプロダクトなら解決できるか？」をチームで議論する
• デザイナーと一緒にUI/UXを考える
• エンジニアと実装方法や技術的制約をすり合わせる
• 開発スケジュールを整理して、関係者と調整する
• リリース後のKPI（成果指標）をもとに、改善点を見つける

つまり、企画・開発・リリース・改善というプロダクトのライフサイクルすべてに関わるのがPMです。

私が最初に「PM＝リーダー」という言葉を聞いたときは、正直ちょっと身構えました。

でも実際の現場では、“決定する”というより“チームの中で共通認識をつくる”“必要な判断を進めるために橋渡しする”という立ち回りが求められているように感じました。

PMはすごく抽象的な役割にも思えますが、「誰のどんな課題をどう解決するか」を常に言語化し、周囲を巻き込みながら進めていく、そんな仕事なのだと実感しています。

PMの仕事内容は？開発前〜後までの関わりを図で解説

プロダクトマネージャーの仕事は、単なる「思いつきを形にする」ことではありません。
ビジネスとして価値ある製品をつくるために、開発のはるか前から、そしてリリース後の改善まで、広く深く関わる必要があります。

一般的なプロダクト開発フローとPMの関与範囲

以下は、私がPMを学ぶ中でよく目にした「プロダクト開発の基本ステップ」です

この中で、PMが特に深く関わるのが【企画〜要件定義】です。

ユーザー課題を見極め、事業の方向性とすり合わせたうえで、何を作るか・なぜ作るかを言語化するのがPMの役割だからです。

ただし現実には、企画段階から関わり、開発中はチームと並走し、リリース後も改善の指揮を取るのが一般的です。

リクルート社のPM職を参考にした例

たとえばリクルート社では、PM（プロダクトマネージャー）が「プロダクト戦略」と「要求定義」のフェーズを中心にリードする体制が取られています。

しかしそれに限らず、事業戦略に参加したり、リリース後のデータ分析まで携わるケースも少なくありません。

私自身、業務観察の中で印象的だったのが、あるPMの先輩が「売上の数字が伸び悩んでいる理由」を分析して、開発チームに「そもそもKPIの設計を見直そう」と提案していた場面でした。

その後、KPIを「アクティブユーザー数」から「継続利用率」に見直すことで、改善の優先順位や機能追加の方向性も変わり、結果的に翌月以降の利用率が回復傾向に転じたと聞いています。

プロジェクトマネージャーとの違いとは？

「プロダクトマネージャー」と混同されやすい役割に「プロジェクトマネージャー（PjM）」があります。
名前が似ているので、私も学び始めた頃は違いがよく分かりませんでした。

結論から言うと、2つの役割の違いは「目的と手段」にあります。

役割名	主な責任	フォーカスする問い	主な活動領域
プロダクトマネージャー（PM）	なにを作るか、なぜ作るか	Why / What	企画・戦略・要求定義
プロジェクトマネージャー（PjM）	どう作るか、いつまでに作るか	How / When	スケジュール・進行・品質管理

プロダクトマネージャーは「プロダクトが市場やユーザーにとって価値があるか？」を判断し、企画や戦略をリードします。
一方でプロジェクトマネージャーは、「それをどのように実現するか？」「期限通りに完成するか？」といった実行フェーズの管理に責任を持ちます。

私の実体験：線引きが曖昧な現場もある

実際に社内のデジタル部門で見た現場では、PMが開発スケジュールの進行管理まで担っているケースもありました。
そのとき「PMってPjMと同じ？」と思いましたが、先輩に教えてもらったのが以下の言葉です。

PMは“目的を握る人”。

PjMは“達成手段を管理する人”。

役割が重なることもあるけれど、視点が違うんだよ。

この言葉のおかげで、PMの本質は「なぜやるのか」を問い続けることにあると理解できるようになりました。

実際には両方の役割を兼任することも多く、企業によって分け方はさまざまですが、「自分がWhyとWhatを担当しているのか、HowとWhenを見ているのか」を意識することは、PMとして立ち回る上でとても重要だと感じます。

プロダクトマネージャーは「プロダクトが市場やユーザーにとって価値があるか？」を判断し、企画や戦略をリードします。

一方でプロジェクトマネージャーは、「それをどのように実現するか？」「期限通りに完成するか？」といった実行フェーズの管理に責任を持ちます。

エンジニア・デザイナーとの関係性｜PMの立ち位置とは？

プロダクトマネージャー（PM）は、よく「チームのハブ」や「司令塔」と表現されます。
ただし、PMがすべてをコントロールする“上司”というわけではありません。

むしろ実際の現場では、エンジニアやデザイナーとフラットな関係で、プロダクトの成功に向けて伴走する存在です。

---

三者の役割分担イメージ

役割	担当する視点	主な責任
PM	Why / What（なぜ・なにを作るか）	プロダクトの企画・優先順位づけ
デザイナー	How it looks（どう見せるか）	UI/UX設計・ユーザー体験
エンジニア	How it works（どう動かすか）	技術実装・開発・保守

この3者がうまく連携しないと、ユーザーにとって本当に価値あるものは作れません。
PMは“決める人”というより、“つなぐ人”であり、“問いを立ててチームに考えを促す人”だと感じています。

---

私の体験：「知らないことを聞ける」関係づくりが第一歩

私が初めてプロダクト開発の現場に入ったとき、エンジニアの専門用語や、デザイナーがFigmaで何をしているのか、まったく理解できずに焦りました。

でも、PMの先輩がこんなふうに教えてくれたんです。

全部を理解しようとしなくて大丈夫。

大切なのは、相手の仕事に敬意を持ち、「わからない」と言える関係を築くこと

そこからは、Slackで「ここの動きってどうなってるんですか？」と素直に聞いたり、デザインレビューに出て「ここのUIの意図を教えてください」と質問したりするようにしました。

そうすると徐々に、相手も「ここって仕様どうしたい？」と相談してくれるようになり、「あ、これがPMとしての“橋渡し”なんだな」と実感できるようになりました。

---

未経験からPMになるには？おすすめの学習ロードマップ

私自身、完全に未経験からプロダクトマネージャー（PM）を目指しています。
だからこそ、「どこから学べばいいの？」「何を知っておくべき？」という不安や迷いに共感しかありません。

このセクションでは、私が実際にたどっている（＆これからたどる予定の）ロードマップをベースに、未経験からPMになるためのステップをご紹介します。

---

ステップ①｜PMの役割・考え方を知る

まずは「PMとは何をする仕事か？」を理解するところから始めましょう。
基本的な概念・スキル・立ち位置が分かると、その後の学びがぐっと深くなります。

おすすめの参考書籍・コンテンツ

• 『プロダクトマネジメントのすべて』（西口一希さん）
• 『INSPIRED』（Marty Cagan）
• NoteやYouTubeなどのPMインタビュー動画

私の場合、「INSPIRED」の冒頭で「PMは“なぜこれを作るのか”を決める仕事だ」という一文に衝撃を受けて、方向性が定まりました。

---

ステップ②｜プロダクト開発の全体像を学ぶ

次に、プロダクトがどう作られ、どう改善されていくのかを理解します。

学ぶべきテーマ

• 要件定義・ユーザー調査
• デザインプロセス（UX/UI）
• 開発プロセス（アジャイル／スクラム）

おすすめ教材

• Udemy：プロダクトマネジメント基礎講座
• 書籍『プロダクト開発のすべて』
• 実際のプロダクト改善事例を読む（Qiita・Zenn・PMノートなど）

---

ステップ③｜PMに必要なスキルを広く浅く触れてみる

この段階では、「完璧」を目指すよりも「ひと通り知る」ことを意識しましょう。

優先して学びたいスキル

• ユーザーインタビュー／ペルソナ設計
• プロダクト戦略／OKR、KPI設計
• エンジニアとの共通言語（API、DB、技術選定など）
• プロトタイピング（Figmaなど）
• スケジュール・優先順位管理（Notion、JIRA、Backlogなど）

---

ステップ④｜身近なプロダクトを分析・提案してみる

実務経験がなくても、アウトプットで学ぶことはできます。

実践例

• 自分の好きなアプリを使って、改善案を考えてみる
• 想定ユーザーのニーズ→機能案→KPIまで落とし込む練習
• PMコンペやスライド投稿（X、note）でアウトプット

私も実際、あるメルカリアプリの改善提案をスライドにまとめて先輩PMに見てもらったことがあります。

---

ステップ⑤｜現場に近づく経験を積む

• 社内でPMアシスタントを経験させてもらう
• プロダクト開発に関わる部署に異動希望を出す
• 社外のPMスクール・副業・インターンに挑戦する

私の場合、社内リスキリングの一環でPMの勉強会に参加し、そこから少しずつ社内プロジェクトにも関われるようになりました。
“現場に触れる”ことは、何よりの学びにつながります。

---

未経験からPMになるには、時間も努力も必要ですが、「一歩ずつ」で十分です。
大切なのは、常に“ユーザーに価値を届けたい”という想いを持ち続けることだと、私自身感じています。

まとめ｜PMの道は一歩ずつ。まずは「なぜ作るのか？」を考える癖から

この記事では、プロダクトマネージャー（PM）の基本的な役割から、仕事内容、必要なスキル、未経験からの学び方までを、実体験を交えてご紹介してきました。

改めて、私がPMを目指す中で一番大切にしていることは、「なぜそれを作るのか？」を問い続ける姿勢です。

機能を増やすこと、プロジェクトを進めること、リリースすること。
どれも重要ですが、「それが誰のためで、どんな価値を生むのか」を見失うと、プロダクトはただの“自己満足”になってしまいます。

実務の現場では、正解のない選択が続きます。
でも、そのたびに「What」と「Why」に立ち返ることで、チームにとっても自分にとっても、納得感のある意思決定ができるようになってきました。

---

私もまだまだ“PMのたまご”です。
でも、一歩ずつ学んでいくことで、プロダクトを通じてユーザーに価値を届けられる実感が少しずつ持てるようになりました。

この記事が、「PMって何だろう？」と思っているあなたの第一歩につながればうれしいです。
一緒に、プロダクトづくりの面白さを学んでいきましょう！