こんにちは！とも（@tomo_ITBizBlog）です！
本記事はこんな悩みを解決！
- PM（プロジェクトマネージャー）に興味はあるけど、未経験からなれるのか分からない
- PM・PdM・PMO・テックリードの違いが、求人を見てもよく分からない
- PMPなどの資格を取ればPMになれるのか、順番を知りたい
この記事で分かること
- プロジェクトマネージャーの仕事内容と、近接職種との違い
- PMが「未経験からなる職種」ではない理由と、現実的な就き方
- 必要な経験の積み方と、資格（PMP・プロジェクトマネージャ試験）の位置づけ
- 年収の考え方と、転職・フリーランス・副業それぞれの現実
まず筆者の立ち位置を、正直に書いておきます。
筆者はPM専任ではありません。運用監視の現場でサブリーダーとして約10名のメンバーの進捗管理や新人教育を担い、インフラやAWSの案件では進捗・課題管理に触れてきました。SES企業の立ち上げでは、経営と採用も経験しています。
つまり「PMとして何年もプロジェクトを回してきた人」ではありません。マネジメントの接点から見える範囲と、求人情報や公開資料をもとに、PMという職種の実像を整理します。
この記事の結論を先に言うと、PMは「未経験からなる職種」ではなく、「実務経験の集大成として就く職種」です。その理由と、就くまでの順番を解説します。
【プロジェクトマネージャー（PM）とは？期限・予算・成果物に責任を持つ役職】
プロジェクトマネージャー（PM）は、決められた期限・予算・スコープ（やることの範囲）の中で、プロジェクトを完遂させる責任者です。
自分で手を動かして作るのではなく、「何を・誰が・いつまでに作るか」を決め、進捗と課題を管理し、顧客や関係者との調整を引き受ける。その全体の成否を握るのが仕事です。
ここで混同しやすいのが、名前の似た職種です。詳しくは後の章で整理しますが、まず一言ずつ押さえてください。
- PM：プロジェクトという「期間限定の取り組み」を、期限と予算の中で完遂させる役職
- PdM（プロダクトマネージャー）：プロダクトそのものの価値、「何を作るか」に責任を持つ役職
- PMO：PMを横断的に支援し、進捗管理の型や報告の仕組みを整える組織・役職
- テックリード：技術面のリーダー。アーキテクチャや実装方針の意思決定を担う役職
需要の背景には、人材不足があります。経済産業省「IT人材需給に関する調査」（2019年公表）の試算では、2030年にIT人材は中位シナリオで約45万人、需要が高く生産性が伸び悩む前提では最大約79万人不足するとされています。
ただし、この不足の中心は即戦力の経験者です。PMはその最たるもので、求人の多くが「プロジェクト経験」を前提にしています。
全職種を「入りやすさ×沼リスク」で整理したカオスマップの記事では、PMは「入りやすさは低いが、到達できれば需要が厚い」ゾーンに置いています。図で見たい方は、エンジニアキャリアマップもあわせてどうぞ。
【プロジェクトマネージャーの仕事内容と1日の流れ】
PMの仕事は、プロジェクトの段階ごとに中身が変わります。
立ち上げ期は、要件の整理、体制づくり、スケジュールと予算の計画です。「何を作るのか」を顧客と合意し、見積もりと進め方の型を決めます。
実行期に入ると日常は、進捗会議の運営、課題・リスクの管理、顧客や他部門との調整が中心になります。遅れが見えたら、原因を切り分け、計画を引き直す。問題が起きたときの判断と報告も、PMの仕事です。
終盤は、受け入れテストの調整、納品、振り返りです。成果物そのものはエンジニアが作りますが、PMの成果物は計画書・進捗報告・課題管理表といった「プロジェクトを前に進めるためのドキュメント」と、最終的な納品の完遂そのものです。
日常的に触るのは、スケジュール管理や課題管理のツール、表計算、資料作成ツール、そして大量の会議とチャットです。コードを書く時間は、基本的にありません。
現場の形態は、SIerや受託開発の会社で顧客のプロジェクトを担う形が中心です。自社プロダクトの会社では、開発チーム側のPMとして働く形もあります。
筆者の接点で言うと、運用監視のサブリーダー時代にやっていた進捗の取りまとめや、障害時の関係者調整は、この仕事の「一部」です。ただし、予算やスコープまで含めたプロジェクト全体の責任は、PM専任の領域です。その線引きは、この記事全体で守ります。
【プロジェクトマネージャーのメリット・デメリット】
良い面と厳しい面を、対にして整理します。ここでは「条件・性質」の話に絞り、具体的な苦悩は次の章で扱います。
メリットは次のとおりです。
- プロジェクト全体を見る立場のため、裁量が大きく、仕事の進め方を自分で設計できる
- 「完遂させた実績」がそのまま市場価値になる。規模の大きい案件ほど評価に直結しやすい
- 技術職の延長線上にあるキャリアの到達点の1つで、マネジメント側への転身の足場になる
- 顧客の業務や経営層と接する機会が多く、ビジネス側の視点が身につく
デメリットは次のとおりです。
- 成否の責任が集中する。遅延やトラブルが起きれば、矢面に立つのはPMです
- 会議と調整が仕事の大半を占め、「手を動かす楽しさ」とは距離ができる
- 技術の手触りが薄れていく。コードやインフラから離れる期間が長くなるほど、技術職への復帰は難しくなりやすい
- プロジェクトの規模や顧客の性質に、働き方の負荷が大きく左右される
「裁量が大きい」は事実ですが、それは「責任も一手に引き受ける」という意味でもあります。この両面が、PMという職種の要点です。
【PMの苦悩と沼ポイント｜「調整役の便利屋」で終わる構造】
PMの苦悩は、一般に次のような形で語られることが多いようです。
1つ目は、板挟みの常態化です。
顧客からは「もっと早く、もっと安く」、現場からは「その条件では無理」という声が届きます。両方の正しさの間で調整し続けるのがPMの日常で、どちらか一方に寄れば、もう一方との信頼が崩れます。
2つ目は、「決められないPM」になる危うさです。
進捗会議を開き、課題を一覧化し、報告資料を作る。こうした「管理の作業」だけを回していると、肝心の意思決定――スコープを切る、優先順位を付ける、時には「やらない」と言う――が置き去りになります。調整役の便利屋で止まってしまうのが、この職種の沼だと言われます。
3つ目は、成功が「当たり前」として扱われることです。
プロジェクトが滞りなく終われば、それは計画どおりという評価で終わりがちです。逆に炎上すれば、真っ先に責任を問われます。成果が見えにくく、失敗だけが目立つ構造は、運用監視の「止まらなければ当たり前」と似ています。
4つ目は、最初の「PMになるまで」の壁です。
求人の多くは「PM経験者」を求めます。しかし、PMになるにはプロジェクトを率いた経験が必要で、その経験を積む席自体が限られています。この鶏と卵の構造が、PMへの道を狭くしています。
筆者の接点の範囲で言えば、サブリーダーとして進捗を取りまとめていた頃、「報告のための報告」に時間を取られ、本来考えるべき段取りに手が回らない感覚はありました。専任PMの責任の重さはそれ以上のはずで、この記事では一般論として扱います。
大事なのは、この沼も個人の努力不足ではなく、役割の構造から来ているという点です。だからこそ、次の章の「手順」では、調整作業だけでなく「意思決定の実績」をどう作るかを軸にします。
【プロジェクトマネージャーに向いている人・向いていない人】
H2-4の苦悩を読んだうえで、自分に合うかを照らしてみてください。
向いている人は、次のようなタイプです。
- 人の話を聞き、利害の違う相手の間に入って落としどころを作るのが苦にならない
- 先の見通しを立て、計画と実績のズレを数字で追うのが得意
- 「自分で作る」より「チームで完遂させる」ことに達成感を感じる
- 問題が起きたときに、感情ではなく段取りで対処しようとする
向いていない人は、次のようなタイプです。
- コードを書いたり、インフラを触ったりする「手を動かす仕事」そのものが好きで、手放したくない
- 会議と調整で1日が終わる働き方に強いストレスを感じる
- 自分の専門技術を深めることこそがキャリアだと考えている
向いていない側に当てはまったからダメ、という話ではありません。
手を動かす技術を深めたいなら、PMではなくテックリードのような「技術側のリーダー」が合うことが多いです。マネジメントに進むかどうかは優劣ではなく、進路の選択です。技術を軸にしたリーダーの道は、後の章で紹介します。
【プロジェクトマネージャーになるための手順と取るべき資格】
PMに就くまでの手順を、段階で示します。核心は「資格から入るのではなく、経験の上に資格を乗せる」ことです。
Lv1：エンジニアとしての実務を積む
- 学ぶこと：開発でもインフラでも構いません。まずは「作る側」の実務で、プロジェクトがどう進むかを体で知ることです
- 目安：担当者として複数のプロジェクト（または案件）を完遂まで経験すること
PMの判断は、現場の実態を知っていることが前提になります。実務のないマネジメント知識だけでは、見積もりも調整も机上の空論になりがちです。
Lv2：リーダー経験で「進捗と人」を見る
- 担うこと：数名規模のチームの進捗管理、タスクの割り振り、新人教育、顧客との定例報告
- 作るもの：進捗報告や課題管理の記録。「誰に・何を・いつまでに」を言語化した実績
ここがPMへの実質的な入口です。筆者の場合も、運用監視のサブリーダーとして約10名の進捗管理と新人教育を担ったのが、マネジメントの接点の中心でした。肩書きがPMでなくても、この経験は「率いた実績」として積み上がります。
Lv3：マネジメントの型を学ぶ
- 学ぶこと：スケジュールの引き方（WBS＝作業の分解）、リスクと課題の管理、見積もり、スコープ管理といった、プロジェクトマネジメントの基本の型
- 作るもの：自分の案件で実際に使った計画書や管理表。学んだ型を現場で回した記録
Lv4：資格で裏付ける
マネジメントの経験を資格で示すなら、代表格は次の2つです。
- PMP（プロジェクトマネジメント・プロフェッショナル）：PMIが認定する国際資格。受験には、プロジェクトをリードした実務経験そのものが要件に含まれます。つまり「未経験が最初に取る資格」ではなく「経験を証明する資格」です
- プロジェクトマネージャ試験：IPA（情報処理推進機構）の情報処理技術者試験の1区分。国内の開発プロジェクトを題材にした、マネジメントの知識を問う試験です
資格の全体像と取得の順番はIT資格まとめで確認してください。なお筆者はPMPを保有していません。この記事では「取るべき資格」としての紹介に留めます。
参入口の現実
「PM・未経験OK」の求人は、ほぼ存在しない前提で考えてください。
現実的な就き方は、今いる現場でリーダーやサブリーダーの役割を引き受け、率いた実績を作ってから、PM・PL（プロジェクトリーダー）の求人に移る形です。いきなり肩書きを狙うのではなく、役割を先に担う順番です。
そもそも「未経験からエンジニアになる全体の流れ」から確認したい方は、別記事もあわせてどうぞ。
【転職・フリーランス・副業で変わるPMの現実と年収の考え方】
まず転職（正社員）です。
PMの求人はSIer・受託開発・事業会社のいずれにもありますが、中心は経験者です。求められるのは「プロジェクトを完遂させた実績」と、その規模（人数・期間・金額感）です。若手のうちはPL（プロジェクトリーダー）やサブリーダーの肩書きで実績を作り、そこからPMへ進むのが一般的な流れとされます。
次にフリーランスです。
フリーランスのPM案件は実際に存在し、要件定義やプロジェクト推進を担う形が中心です。ただし、案件側が求めるのは即戦力のマネジメント経験で、実績のない状態から受けられるものではありません。筆者自身も、フリーランスとしてはAWSや生成AIの「手を動かす側」の案件を受けており、PM専任の案件ではありません。
最後に副業です。
PMの副業は、顧問的な関わり方や小規模プロジェクトの支援といった形が一部にあるものの、数は限られます。責任の重い役職である分、本業での実績が前提になる点は、他の形態と変わりません。
そして、タイトルにも入れた「年収の現実」です。
この記事では、具体的な金額を断定しません。年収は業界、企業の規模、任されるプロジェクトの規模で大きく変わり、一律の数字には意味がないためです。
傾向として言えるのは、エンジニア職の中では経験者層の年収レンジは高めに位置しやすいこと。ただしそれは「PMという肩書き」への対価ではなく、「任される規模と責任」への対価です。
また、PMPなどの資格を持っているだけで年収が跳ね上がるわけでもありません。資格は経験を裏付ける材料であって、評価される本体は「何を・どれくらいの規模で・完遂させたか」の実績です。肩書きと資格を先に求めるのではなく、実績の後に付いてくるものとして捉えるのが現実的です。
なお、マネジメントに進むことだけが「上」ではありません。技術を深める側にも、チームの技術的な意思決定を担うリーダーの席があります。
＼ マネジメントではなく、技術でリードする道もあります ／
【PMの次に進むステップ｜PdM・PMO・テックリードとの違い】
PMの周辺には、名前の似た役割が4つあります。「次のステップ」を考える前に、違いを整理しておきます。
- PM（プロジェクトマネージャー）：見る対象は「プロジェクト」。期限・予算・スコープの中で完遂させることが責任。プロジェクトが終われば、役割も一区切りになります
- PdM（プロダクトマネージャー）：見る対象は「プロダクト」。期限で区切らず、「何を作れば価値が出るか」を継続的に決める役割です。PMからPdMへ移る人もいますが、問われるのは完遂力より「作るものの選定眼」になります
- PMO：見る対象は「プロジェクト全体の仕組み」。個別のプロジェクトを率いるのではなく、進捗管理の型、報告のフォーマット、ガバナンスで複数のPMを支える役割です。PMの経験を活かして、支援側に回る進路です
- テックリード：見る対象は「技術」。アーキテクチャや実装方針の意思決定を担い、手も動かすリーダーです。PMが「進め方」に責任を持つのに対し、テックリードは「作り方」に責任を持ちます
PMを到達点として次に進むとすれば、方向は大きく3つです。
1つ目は、より大きな規模のプロジェクトや、複数プロジェクトを束ねる立場へ進む方向です。
2つ目は、PdMのようにプロダクト側へ寄せる方向。
3つ目は、PMOや組織の仕組みづくり側へ寄せる方向です。
逆に、「マネジメントに入ってみたが、手を動かす技術のほうが合っていた」と気づく人もいます。その場合は、テックリードのような技術側のリーダーに戻る選択肢があります。詳しくはテックリードの記事で整理しています。
どの方向にも共通するのは、PMの席が「経験の集大成」だという点です。進む方向を選べるのは、実務とリーダーの実績を積んだ後になります。
【まとめ｜PMは「なる」職種ではなく「就く」職種】
要点を3つにまとめます。
- PMは、期限・予算・スコープの中でプロジェクトを完遂させる責任者。未経験から直接就く職種ではなく、実務経験の集大成として就く職種
- 道順は、エンジニア実務→リーダー経験→マネジメントの型→資格での証明。PMPも「経験を証明する資格」であって、入口のチケットではない
- PM・PdM・PMO・テックリードは別の役割。年収や評価を決めるのは肩書きではなく、任された規模と完遂の実績
これから目指す方は、まず今の現場で「率いる役割」を1つ引き受けるところから始めてください。
職種全体の地図に戻りたい方は、カオスマップの記事で、PMと他の職種の位置関係を確認してみてください。
