プロジェクトマネージャー（PM）がきつい理由は？しんどいときの対策を解説
2026年06月29日更新
「PMはきつい」「責任が重すぎる」と感じながら、毎朝の仕事に向かうのがつらくなっていませんか。
クライアントの無理難題と現場の疲弊、終わりなき調整に追われ、限界を感じているなら、一度立ち止まって冷静に原因を切り分ける必要があります。なぜなら、苦しみの根本原因が職種にあるのか、労働環境にあるのかによって、選ぶべき解決策は異なるからです。
もし原因が環境にあるのなら、PMというキャリアを捨てずとも、サポート体制の整った他社へ転職するだけで状況は大きく改善します。
本記事では、あなたが今抱えているきつさの正体を突き止め、キャリアと心身を救う具体的な判断基準と、後悔しないキャリアパスを解説します。
著者
川村 莉子
(Kawamura Riko)
名古屋工業大学卒業後、新卒でDirbatoに入社。通信会社に対する業務改善プロジェクトや次世代ネットワーク移行案件のPMOなどに従事。自身のコンサルタント経験を活かした、IT系コンサルファームへの開発支援を得意とする。
プロフィール詳細を見る
監修者
笠原 英樹
(Kasahara Hideki)
法政大学を卒業後、開発企業での技術職経験を経て、サイバーエージェントの子会社へ転職。技術領域に深くコミットしてきた経験を武器に、入社半年でプロジェクトリーダーを兼任する。「圧倒的なコミットメント力」、そして培ったリーダーとしての専門性をもって一貫して高い成果と信頼性を証明してきました。 この確かな技術的バックグラウンド、そして「誰かを支え、その人の強みを最大限に引き出すリーダー」としての経験を活かし、求職者の方々が心から納得できる「次の挑戦」をサポートしたい、という思いで転職エージェントMyVisionに入社しました。
プロフィール詳細を見る
目次
CONTENTS
プロジェクトマネージャー（PM）は構造上きつい仕事になりがち
日々の業務に追われて「きつい」「つらい」と感じたとき、自分のマネジメント能力が足りないからだと抱え込んでしまう人も多くいます。しかし、PMが疲弊してしまうのは個人のスキル不足だけではなく、役割の構造上どうしても過酷になりやすいポジションであることも大きな要因です。
PMはプロジェクトを統括する性質上、立場や考え方がまったく異なる人たちの間に立ち、複雑な意見を統合して意思決定を下さなければなりません。
常に正解のない中で重大な決断を求められるため、構造的に負担が一人に集中してしまう立場だといえるでしょう。だからこそ、どれほど優秀で経験豊富な人であっても重圧を避けられず、心身ともにきつい状態になりやすいのが実情です。
プロジェクトマネージャー（PM）が「きつい」「病む」といわれる7つの理由
PMが限界まで追い詰められてしまう背景には、現場で直面するマネジメント職特有の過酷な要因が存在しています。
ここでは、多くのPMが精神的・肉体的に疲弊しやすい7つの理由を、詳しく見ていきましょう。
クライアントと開発現場の板挟みでどちらの味方にもなれない
プロジェクトマネージャーの仕事は、クライアントと開発側双方の要求による板挟みになりやすいポジションです。
たとえば、クライアントから「少し機能を追加してほしい」と依頼された際、PMは現場のエンジニアを説得して動かすことが必要です。しかし当然ながら、エンジニア側からはリソースの不足や影響範囲など、現実的な理由で反発を受けることも多くあります。
両者の利害はどうしても対立しがちであり、妥協点が見つからないと、行き場のない不満がすべてPMに集中します。立場上どちらの味方にもなりきれず、クライアントと現場の双方に対して、常に矢面に立たされて謝っているような感覚に陥る人もいるでしょう。
日々の進捗管理に加えて、こうした調整業務に多大なエネルギーを消費するため、ストレスが蓄積しやすい構造です。
開発中盤や終盤に仕様変更の依頼が来る
開発が中盤から終盤に差し掛かったタイミングで、クライアントから急な仕様変更の依頼が来ることは珍しくありません。
作成された画面やテスト環境を見てから修正や機能変更の要望が出るのは、システム開発において日常茶飯事です。しかし、仕様変更を受け入れたとしても、リリース日は絶対に変えられないケースが多いのが現実です。
結果的に、追加された作業量を無理やりスケジュールにねじ込むため、PM自身や現場メンバーの残業・休日出勤でカバーせざるを得なくなります。常にスケジュール遅延の恐怖に追われながらの綱渡りとなるため、プロジェクトが完了するころには、心身ともに激しく消耗してしまいます。
責任が重く現場をコントロールしにくい
PMは、プロジェクトの遅延や赤字といった最終的な責任をすべて背負う立場です。一方で、それを防ぐために必要な「人事権」や「予算の決定権」など、実質的な権限を持たないケースが多くあります。
とくにメンバーがほかのプロジェクトと兼務している場合、PMの立場はさらに弱くなります。PMには彼らの業務の優先順位を指示したり、人事評価でモチベーションを管理したりする権限がないためです。
責任はPMが負うのに、現場を動かす権限はないという歪な構造が、PMを精神的に追い詰めます。
現場がうまく回らないと、自分のマネジメント能力を責めてしまいがちです。しかし、権限と責任のバランスが崩れている状況は、個人の努力でどうにかなるものではないでしょう。
必要な権限を与えず、結果の責任だけを押し付ける組織体制に責任がある可能性を認識しておく必要があります。
正解を見極める選択が難しい
システム開発の現場において、関係者全員の要望を完全に満たせるような「完璧な正解」は存在しません。納期のために現場へ無理な残業をお願いするか、品質を守るためにスケジュールの延長を頼み込むかなど、PMは常にトレードオフの決断を迫られます。
どちらの選択をしても必ず誰かに負担を強いることになり、結果として不満をぶつけられるのは避けられないでしょう。場合によっては、「誰に一番我慢してもらうか」という泥臭い意思決定を日々繰り返さなければなりません。
PMは、こうした正解のない選択を1人で背負い続ける重圧を日々受けることもあります。
積み上げてきた開発スキルを無駄にしていると感じる
PMは技術力を評価されて抜擢されたにもかかわらず、自らコードを書く機会は激減するケースが多いです。1日中ExcelやPowerPointと向き合い、進捗管理表の更新やクライアント向けの報告資料を作る必要があります。
現場の若手メンバーが新しい技術を使って開発を進めている横で、自分はひたすらExcelでスケジュールの線を引く。そんな日々が続くでしょう。こうした事務作業や顧客折衝ばかりに追われていると、「積み上げてきた技術力が錆びついてしまうのでは」と強い焦りを感じるものです。
最前線の技術トレンドから取り残され、エンジニアとしての市場価値が下がってしまうという喪失感も、PMを精神的に追い詰める要因のひとつです。
技術力がなく必要な工数や人員を割り出せない
PM自身に技術力がなく、必要な工数や人員が割り出せないこともあります。
とくに経験したことのない技術や、未知の領域のプロジェクトを担当した際、各タスクの難易度や見えないリスクを把握することは難しいです。結果的に、正確な工数や必要な人員を見積もれず、実態からかけ離れた非現実的なスケジュールを引いてしまうこともあります。
こうした状況下では、案件が炎上状態に発展するケースも多く、エンジニアから「PMの技術力がないせいだ」と、不満をぶつけられることもあるでしょう。
技術力がないことで、信頼関係まで一気に失い、激しく自信を喪失してしまいます。
激務による慢性的な疲労を感じやすい
ITの開発現場では、PMがマネジメントと現場の実務を兼任するケースが多いです。
日中は定例会議や進捗管理などに追われるため、自身が担当する設計やコードレビューを定時後に持ち越さざるを得ない場面もあります。
「定時を過ぎてからが自分の本番」という働き方が常態化すれば、慢性的な睡眠不足や疲労に悩まされてしまいます。休みなく稼働し続けた結果、うつ病をはじめとするメンタル不調を引き起こすリスクも高まるでしょう。
PMがつらいときの即効性の高い対策
PMとして限界を感じたときは、個人の努力や精神論だけで無理に乗り切ろうとするのは危険です。
心身が完全にすり減ってしまう前に、まずは現場の負担を物理的に減らせる対策から実行していきましょう。
ここでは、PMがつらいときに使える、即効性の高い対策を解説します。
PMOの導入やエスカレーションルールを設ける
まずは、すべてを自分で抱え込むという過度な責任感を手放し、タスクを組織へ切り出す交渉からはじめてみましょう。
たとえば、日々のスケジュール更新や議事録作成などの事務作業は、PMOやアシスタント要員に切り出せないか会社に打診します。これだけでも、PM本来の役割である意思決定と折衝に集中する時間が生まれ、精神的な余裕が大きく変わります。
また、プロジェクトを守るために、「エスカレーションルール」を事前に設定しておくことも有効です。「無茶な仕様変更や予算交渉が発生したら、部門長に引き継ぐ」といった基準を関係者間で合意しておきます。
自分一人で意思決定を抱え込むのではなく、権限を持つ上層部を計画的に巻き込み、組織全体で対応する防衛線を構築してみてください。
QCDの優先順位や変更要求ルールを合意しておく
PMを苦しめる「正解のない決断」の重圧は、ルール作りによって大幅に軽減できます。具体的にはプロジェクト開始時に、クライアントおよび開発チームと最優先する「品質・コスト・納期（QCD）」について、必ず合意しておきましょう。
たとえば「今回は納期が絶対である」と握っておけば、現場で判断に迷った際も、機能変更よりも納期を最優先とする決断が可能です。
また、このQCDの合意は、開発中盤以降に出やすい、急な仕様変更への対応策としても役立ちます。
納期最優先という前提があれば、新たな要求に対しても「納品後に別途見積もり」「運用フェーズでのアップデート」など、柔軟に切り返すことが可能です。
さらに、現場を守るためにも気軽な口約束での変更要求は避け、必ず変更要求書として文書化する運用を徹底してください。変更に伴う納期の延長や費用の追加もセットで明記する仕組みにすれば、無責任な仕様変更の連発を未然に抑止できます。
QCDの優先順位や変更要求ルールを合意しておく
かつては、PMが自らコードを書くことは否定されていました。しかし、AI時代においてはマネジメントと技術の両立が可能です。まずは、PMだからこそ担える「アーキテクチャ設計」や「技術選定」といった、上流の技術課題にフォーカスする時間を確保しましょう。
そのうえで、AIを使った「バイブコーディング」を、日々の業務に取り入れることをおすすめします。バイブコーディングとは、AIに対して自然言語で指示を出し、対話を通じてコードを生成していく新しい開発手法です。自らコードを記述する必要がないため、環境構築やタイピングの手間を省き、頭の中にあるアイデアを即座に形にできる魅力があります。
要件定義の段階でクライアントと認識を合わせるためのPoCを作成したり、現場の業務を効率化する社内ツールを開発したりする場面で役立ちます。最新のAIを活用して自ら手を動かしモノを作る欲求を満たせる仕組みを作れば、技術から離れてしまうという焦りや不安も払拭できるでしょう。
テックリードや現場メンバーと共同で要件定義や見積もりをおこなう
進化し続けるすべての技術要素を、PM一人で完璧に把握することは不可能です。そのため、素直に現場の専門家を頼るスタイルへ切り替えることが重要です。
たとえば、要件定義の打ち合わせにテックリードを同席させることができれば、状況は大きく変わるでしょう。その場でクライアントに対して技術的な対応可否やコストを議論できるため、無理な仕様合意を持ち帰ってしまうリスクを減らせます。
また、WBSを作成して工数を引く際も、PMの勘と独断だけでスケジュールを決めるのは非常に危険です。
必ずテックリードや各領域の担当エンジニアにヒアリングをおこない、現場の感覚に基づいた根拠のある「共同見積もり」を作成してみてください。
さらに、過去の類似案件の実績データを参考にしつつ、不確実な技術要素が含まれるタスクには、意図的に予備工数を積むルールを設けることも有効です。あらかじめリスクを見越したスケジュールでクライアントと交渉することで、技術理解や経験の浅さをカバーできます。
PMの限界サインチェックリスト
プロジェクトですでに限界を感じている場合は、まずは自分が抱えている全タスクを可視化する時間を作ってみてください。洗い出したタスクの中から「PM以外でも対応できる業務」を明確にし、強制的にでも現場メンバーへ委譲する決断が必要です。
もし業務を切り出しても長時間労働が改善しない場合や、すでに心身へ不調のサインが現れているなら、迷わず有給休暇を取得して現場から離れましょう。プロジェクトの進行やクライアントへの責任よりも、あなた自身の心と体を守る行動を何よりも最優先にしなければなりません。
とくに、以下の状態が見られる場合は、早急に休職などの手続きが必要です。
【心身の限界サインチェックリスト】
- イライラする
- 不安だ
- よく眠れない
- 物事に集中できない
- することに間違いが多い
- やる気が出ない
取り返しのつかない状態に陥る前に、速やかに心療内科を受診するなど、自分を守るための具体的な対処を強くおすすめします。
なお、より詳しいチェックリストで心身の状態を確認したい場合は、厚生労働省が提供する「疲労蓄積度自己診断チェックリスト」を受けてみてください。
PMがきつい原因は「環境」か「適性」かを見極める基準
PMとしての毎日に限界を感じたとき、PMという職種が合っていないのか、会社の労働環境や体制が悪いだけなのかを冷静に切り分ける必要があります。
同じ「きつい」でも、経験を積めば越えられる壁なのか、個人の努力では動かせない環境の問題なのかで、取るべき行動はまったく変わります。次の4つの観点から、自分の状況を確かめてみてください。
今のつらさは経験不足による一時的な壁ではないか
もし現在感じているきつさの根本原因が、単なる知識や経験の不足にある場合、職種や環境のせいにして転職すべきタイミングではありません。むしろ、学習と場数で乗り越えられる、成長フェーズの壁にぶつかっている状態だといえます。
とくに、PMに就任してまだ1〜2年目の場合、どんなに優秀なエンジニア出身者であっても、プロジェクトで戸惑うことは必ずあるものです。自らのアプローチを変えることで解決できる余地が残っていないか、一度冷静に振り返ってみてください。
具体的には、以下のような行動を取ることがおすすめです。
- プロジェクトマネジメントの体系的な知識である「PMBOK」を学び直す
- 修羅場をくぐり抜けてきた先輩PMに相談する
経験不足による一時的な壁を「適性がない」と早合点してキャリアを降りてしまうのは、非常にもったいない選択です。
そもそも適正なリソースが割かれているか
プロジェクトの開始時点で、適正な予算や人員、納期が確保されていたかを冷静に見直してみましょう。今、プロジェクトがうまくいっていないのは、担当した案件のそもそものスケジュールやメンバーに問題があるケースもあります。
最初からリソースが不足しており、前提条件に無理があるプロジェクトを予定どおりに納品することは、どれほど経験豊富なPMであっても難しいです。このような案件を任されてプロジェクトが炎上した場合、必ずしもPMのマネジメント能力だけが原因とは限りません。適正な体制を整えないままプロジェクトを進めている、会社側の責任も大きいといえます。
現場が回らない状況を「自分の力不足だ」と抱え込む必要はありません。まずは、今の職場の体制や環境要因に問題がないかを切り分けることが大切です。
トラブル発生時に上司や経営陣が助けてくれるか
プロジェクトの炎上やクライアントとのトラブルが発生した際、上司や経営陣がどのように振る舞うかは、今の会社を見極める重要な指標です。組織としてPMを守る体制が整っている会社であれば、役員クラスが自ら矢面に立って、現場のPMを物理的・心理的にバックアップしてくれます。
しかし、いざ問題が起きた途端にPMへ全責任を押し付け、上層部が一切助けてくれない組織も残念ながら存在します。組織が壁となって現場を守ってくれない環境であれば、心身を削ってまで働き続ける価値はありません。
自分の能力を責めるのではなく、早急に見切りをつけて他社へ移るべき決定的なサインといえます。
PM1人にあらゆる仕事を押し付けられていないか
営業段階の予算交渉から要件定義や基本設計、日々の進捗管理に至るまでを、PM1人に丸投げするような体制になっていないかも確認しましょう。本来であれば役割を分担して進めるべき業務までPMに依存している状態は、組織として決して健全とはいえません。
PMOのような分業体制やサポートが存在しない環境で感じる限界や過労は、PM個人の努力やスキルアップで解決できる範疇を超えています。「自分がもっと頑張れば回るはずだ」と思い詰める必要はありません。
なんでも屋のようにあらゆる仕事を押し付けている会社の体制が異常であると判断し、自分を守るための行動に移るべきです。
【テックゴー編集部の見解】 一般公開されている情報だけを見ると、「プロジェクトが回らないのは、自分に原因がある」と責めてしまうかもしれません。しかし、テックゴー編集部が多くのPMのキャリアを分析すると、①人員・納期設定、②上層部のサポート体制、③PMへの業務集中などで、組織的な問題を抱えているケースもあります。
この判断を間違えて「自分が無能だからだ」と思い込み無理を続けると、うつ病などで今後のキャリアに致命的な傷を負ってしまうケースもあります。これらが機能していない場合は、個人のスキル不足ではなく「環境」に原因があると、自分の中で言語化できるレベルまで落とし込んでおくことが重要です。
PMを続けるべきか辞めるべきかの判断基準
PMを続けるべきか思い悩んだときは、自分のスキル不足なのか、会社の組織構造や環境に問題があるのかを見極める必要があります。
ここでは、PM職そのものから離れるべきか、あるいは環境を変えてキャリアを続けるべきかを判断する客観的な基準を解説します。
職場を変えれば解消する問題ならPMを続けながら転職する
日々つらいと感じる原因が職場環境にある場合は、PM職を辞めるのではなく、他社への転職を検討すべきです。たとえば、以下のような状況であれば、個人の努力で改善するのは極めて困難です。
- 会社がプロジェクトに適正な人員や予算を割いてくれない
- クライアントから無茶な要求が出ても、組織がPMを守ってくれない
こうした構造下での苦労は、決してあなたのマネジメント能力が不足しているからではなく、単純に環境側の問題であるケースが多くあります。PM業務にやりがいを感じており、環境に疑問があるのなら、健全な体制が整っている他社でPMのキャリアを続けることをおすすめします。
心身の回復が追いつかずやりがいも感じられないなら別職種に転職する
休日になっても疲労が抜けず、プロジェクトを納品しても達成感ややりがいを感じられない場合は、PMという職種が自分に合っていない可能性があります。
また、関係者の板挟みになる調整業務に強いストレスを感じる際は、会社を変えるだけでは根本的な解決につながりません。環境を変えてもPMとして求められる役割が変わらなければ、同じような悩みを抱えてしまう可能性があるためです。
そのような状況であれば、無理にPMというポジションに固執せず、別職種へのキャリアチェンジを考えてみましょう。
たとえば、マネジメントや調整業務から距離を置きたい場合、技術力で開発現場をリードするテックリードの道がおすすめです。ほかにも、進捗管理などを専門に担い、PMと責任を分担するPMOは、これまでの経験を活かしやすいです。
心身が限界を迎える前に「自分により合った役割」へ移行することも、前向きなキャリア選択といえます。
PMのスキルが活かせてきつさを変えられるキャリアパス5選
PMとして培ったマネジメントスキルや高度な調整力は、ほかのキャリアや職種でも強力な武器として高く評価されます。
これまでの経験を無駄にすることなく、責任の重圧から解放されて労働環境を変えられる5つのキャリアパスを紹介します。
社内SEなど「自社開発・発注側」のPMへ転職する
受託開発に見られる納期の厳しさや、急な仕様変更などに限界を感じている場合は、社内SE部門や自社開発企業のPMに転職するのがおすすめです。大きなメリットは、開発を依頼する「発注側」に回ることで、スケジュールの主導権を自分たちで握れる点にあります。
たとえば、社内から急な追加要望が出ても、「予算内に収まらないので、運用フェーズで実装する」など、自らの裁量でスコープをコントロールできます。受託時代のように、顧客の無理難題に過度な残業などで、無理やり対応するような事態は起こりにくいです。
PMとしての武器を活かしながら、精神的な余裕とワークライフバランスを取り戻せるキャリアパスのひとつです。
【テックゴー編集部の見解】 テックゴー編集部では現状への不満から、「PM以外のポジションなら何でもいい」という基準だけで、転職先を選ぶことを推奨しません。
なぜなら、自己分析が不十分なまま転職し、「勢いで開発現場に戻り、年収が下がった」「PMOになったが、やりがいを見失った」と失敗している人がいるからです。
そのため、今のきつさの原因を細かく分析し、自分の強みが最も活きるキャリアパスを考慮した方が、納得のいく転職になりやすいです。自分一人での判断が難しい場合は、テックゴーのようなIT領域に強い専門エージェントを活用し、客観的な適性診断を受けることをおすすめします。
テックリードやスペシャリストとして開発に専念する
顧客などとの調整や予算管理よりも、手を動かして技術に向き合いたい思いが強いなら、テックリードやスペシャリストへ回帰する道がおすすめです。PMとして培ったプロジェクト全体を俯瞰できる力は、単なるプログラマーとは比較にならないほど高い市場価値を持ちます。
現場で最新の技術に触れ続けられるため、「自分の技術力が錆びついていく」という、エンジニア特有の焦りからも完全に解放されます。ビジネス側との橋渡しができる技術的支柱として組織に貢献しつつ、モノづくりの純粋な楽しさを取り戻せるでしょう。
▼以下の記事では、テックリードについて解説しています。仕事内容や年収、将来性に関しても言及しているので、参考にしてください。
テックリードとは？仕事内容・年収・将来性・必要なスキルと「やめとけ」と言われる理由を徹底解説
PMOとしてマネジメントの直接責任を軽くする
プロジェクトを計画どおりに進めること自体は得意でも、責任を負うことに心が折れそうになっているなら、PMOへの転身が最適な解決策です。
PMOはスケジュール管理や、品質管理などのマネジメント業務を支援するポジションです。PMのようにクライアントとのヒリヒリする仕様交渉や、最終的な意思決定の矢面に立つことはありません。そのため、ダイレクトな重圧から解放されて、精神的な余裕を持って業務に取り組めます。
PM経験者であれば、PMが抱える孤独や事務作業の苦労を痛いほど理解でき、先回りして動ける優秀なPMOとして現場から重宝されるでしょう。これまでの知見や炎上回避のノウハウを活用できるため、キャリアチェンジであっても高年収を維持しやすい選択肢です。
▼以下の記事では、PMOについて解説しています。PMとの違いや具体的な仕事内容を紹介しているので、参考にしてください。
PMO（プロジェクトマネジメントオフィス）とは？PMとの違いや組織における役割、将来性をエンジニア向けに解説
事業会社のPdMに転換して板挟み構造から抜け出す
受託開発のPMとして板挟みの構造に限界を感じているなら、事業会社のPdMへ転換するのも有効な選択肢です。事業会社のPdMは、自社プロダクトの成長やユーザーへの価値提供を軸に意思決定していきます。
自社内でプロジェクト進行の優先順位やスケジュールを調整でき、受託開発特有の板挟み構造から距離を置けます。
また、PMとして培ってきた要件定義力や、開発現場と調整してきた経験は、PdMの仕事でも活かすことが可能です。曖昧な要望を整理し、実現可能な形に落とし込んできた経験は、プロダクト改善や企画立案において大きな強みになるでしょう。
ITコンサルタントへシフトして上流から関わる立場に移る
開発現場における「顧客折衝」や「課題解決」にやりがいを感じていた場合は、ITコンサルタントへの転職がおすすめです。
ITコンサルタントは、開発プロジェクトの前段階である「経営・業務課題をどうITで解決するか」という、最上流工程にかかわれるのが魅力です。
システムの企画や要件定義までを担い、実際の開発フェーズで発生する進捗遅延のカバーやバグ対応などは、開発担当のPMに任せられます。そのため、現場特有の終わりの見えない激務からは、解放されやすい環境です。
システム開発現場のリアルな難しさや痛みを知っている元PMのコンサルタントは、実現不可能な提案をしません。地に足の着いた提案力があるため、クライアントからも信頼されやすく、結果として大幅な年収アップも狙えるでしょう。
「今の環境から抜け出したいが、自分の経験がどのキャリアパスで一番活きるかわからない」と悩んでいる方は、ぜひ一度、テックゴーにご相談ください。
PMとしてのリアルな苦労や培ってきた知見を棚卸しし、あなたが精神的な余裕を持って活躍できる最適な次のステージを一緒に見つけ出します。
▼以下の記事では、コンサルとエンジニアの違いについて解説しています。年収や向き不向きなどを紹介しているので、参考にしてください。
コンサルとエンジニアはどっちが高年収？仕事内容や働き方、向き不向きを徹底比較
PMのキャリアに迷ったらテックゴーに相談する
「環境が悪いのか、自分に向いていないのか」を一人で切り分けるのは、思っている以上に難しい作業です。渦中にいると、どうしても「自分の力不足では」という方向に判断が傾きます。だからこそ、現場を知る第三者の目を借りる価値があります。
テックゴーは、ITエンジニアの転職支援に特化したエージェントです。メガベンチャーのIT部門出身者やITコンサル出身のアドバイザーが在籍しているため、PMが抱える板挟みの構造や、権限と責任が釣り合わない苦しさを、表面的にではなく現場の肌感覚で理解したうえで相談に乗ってくれます。
強みは、提案できる選択肢の幅広さです。 社内SEや自社開発企業のPM、PMO、PdM、テックリード、ITコンサルタントまで、本記事で紹介したキャリアパスをほぼ網羅する1万件以上の求人を扱っています。「PMを続けたいが環境だけ変えたい」のか「別職種に移りたい」のか、方向性が固まっていない段階でも、適性を一緒に棚卸ししながら進められます。
年収交渉に強いのも見逃せません。30代エンジニアで平均160万円、20代で平均120万円の年収アップ実績があり、キャリアチェンジで収入を落としたくない人ほど効いてきます。
相談はすべて無料です。 すぐに転職する気がなくても、自分の市場価値や、環境を変えたときにどんな働き方ができるのかを知るだけで、次の一歩がかなり見えやすくなります。
まとめ
PMがきついといわれる背景には、クライアントと開発現場の板挟み構造や、適切なリソースが割かれないなど、環境特有の問題があります。とくにPM個人へ全責任を押し付けるような企業では、心身を消耗しやすい傾向があります。
一方で、PMとして培ってきたマネジメントスキルや調整力は、非常に市場価値の高い武器です。自社開発のPMやPdM、ITコンサルタントなどへキャリアチェンジすることで、精神的な余裕を取り戻して活躍している元PMも多く存在します。
そのため、限界を迎えて倒れてしまう前に、「環境の問題」か「自身の適性」かを冷静に見極めることが大切です。自分の心身を守ることを最優先にしながら、強みを活かせる次のステージを探してみましょう。
よくある質問
Q
PMに向いているのはどんな人ですか？
A
PMに向いているのは、適度に感情を切り離して割り切れるタフさを持つ人です。 また、職人気質で自身の技術に強いこだわりを持つ人よりも、チーム全体でプロジェクトを完遂し、成果を出すことに喜びを見出せる人が向いています。 プレッシャーや状況に対する柔軟性が重要です。
Q
PMは鬱になりやすいですか？
A
PMは、ほかの職種と比較して、うつ病などのメンタルヘルス不調に陥るリスクはどうしても高い傾向にあります。 クライアントと開発現場の板挟みによる強烈なストレスや、慢性的な長時間労働が重なりやすい職種であるためです。とくに、責任感が強く真面目な人ほど、「自分がもっと頑張れば回るはずだ」と一人でプレッシャーを抱え込んでしまいます。 心身が壊れてしまう前に、早めに周囲へSOSを出したり、休職などの自分を守る防衛策を取ったりすることが不可欠です。
Q
ダメなPMの特徴とはどのようなものですか？
A
よく挙げられる特徴は、以下のとおりです。 ・細かい作業まで手を出してしまい、仕事をメンバーに振れない ・クライアントからの無理な要求を精査せず、そのまま現場に流してしまう ・重大なトラブルが発生しても決断を先送りして問題を放置する ただし、これらの行動は、PM個人の資質が低いだけで片付けられるものではありません。そもそもPMをサポートする体制がなかったり、管理職の訓練を受けていなかったりと、会社の支援体制が原因であるケースも多い点には注意が必要です。
Q
PMに技術力は必要ですか？
A
PMに一定レベル以上の技術力は必須です。PM自身が最前線でコードを書く必要はありませんが、工数やリスクなどを正確に見積もり、判断するための技術的知見が不可欠だからです。 現場のエンジニアが抱える課題を理解し、それをクライアントに論理的に説明できなければ、両者からの信頼を失いプロジェクトは炎上してしまいます。すべての技術要素を完璧に網羅する必要はありませんが、現場のスペシャリストと対等に議論できるレベルの技術リテラシーが強く求められます。