プロジェクトマネージャーはきつい？会社を移っても調整は残る。仕事は求人票、決め方と残業は面接

プロジェクトマネージャーがきついと感じたら、最近「辞めたい」と思った場面を3〜5個、人数・回数・時間・決める人と一緒に書きます。会社を移ってPMを続けても、予算・納期・要員・品質の管理、関係者の調整と報告は残ります。これは厚生労働省job tagの「プロジェクトマネージャ（IT） - 職業詳細」がPMの仕事として挙げる内容です。変わりうるのは、誰が見積や体制を決めるか、顧客までに何社入るか、チームの内訳、実残業など。仕事は求人票で手がかりを読み、決め方と残業は面接で聞きます。

例にするのは、中堅SIerで官公庁システム更改の二次請け案件を担当する、PM3年目の架空の社員です。手順を示すための例で、後で示すWeb・オープン系の求人集計と同じ範囲とは限りません。

プロジェクトマネージャーがきつい場面を3〜5個、今の職場の値と一緒に書く

「責任だけ重い」「板挟み」「残業が多い」のままでは、応募先との違いを比べられません。最近の場面を選び、誰が何を決めたか、何人で何時間かを添えます。

例の社員については、次の5場面を書きます。数値はすべて架空ですが、後で求人票を読むときと面接で聞くときも同じ単位を使います。

辞めたい場面	今の職場の値	比べる単位	今の職場で確かめる場所
見積と要員確保は元請けが決めるのに、納期と品質を管理する	見積と要員確保は元請けが決定。本人は納期・品質・進捗を管理	決める人、再提案できる相手	見積記録、体制表、変更記録
進捗資料と元請けへの報告で週の半分を使う	社内会議と元請け会議へ同じ進捗を報告。資料作成と会議で週の約半分	報告先、週の時間、資料の種類	予定表、会議体一覧
仕様変更は元請け経由で再調整する	顧客と直接話せず、元請け経由で見積と納期を再調整	間に入る会社、顧客窓口、決める人	変更記録、契約関係図
平常月35時間、リリース前70時間になる	実残業は平常月35時間、直近のリリース前月70時間	配属案件の実残業、対象月	勤怠、リリース計画
12人のうち協力会社8人を含むチームをまとめる	自社4人、協力会社8人。本人は評価権限なし	自社・協力会社の内訳、評価する人数	体制表、評価分担

人数は合計だけで終えません。自社社員、協力会社、顧客側の誰を含むかを分けます。「12人のチーム」と書くだけでは、自社社員12人と、協力会社を含む12人を同じように比べてしまいます。

今の職場で実際に残業した時間と、給与に含まれる固定・みなし残業の時間は分けて書きます。分からない値は推測せず、「未確認」と残します。

「PMの役目に残る側」「案件・職場で変わる側」「分からない側」へ置く

表へ置く前に、3区分を決めます。

PMの役目に残る側: 予算・納期・要員・品質を管理する、関係者の意見を調整する、進捗・課題・対応策を報告する、といった仕事そのものです。
案件・職場で変わる側: 見積・要員確保・仕様変更を誰が決めるか、その人までに何社入るか、報告先と回数、実残業、チーム内訳、並行案件、自分で開発する割合、相談相手、育成、評価など、案件や職場ごとに値が変わる部分です。
分からない側: 相手・出来事・現在の値がなく、前の2区分へまだ置けない場面です。相手・出来事・値を書けたら、前の2区分へ置き直します。人間関係や将来の配属案件のように、面接で聞いても確かめきれないものは、値を書いた後もここへ残します。

一つの場面に二つの原因があれば、原因ごとに行を分けます。要員を管理することはPMの役目ですが、要員確保やアサインを誰が決めるかは案件・職場の値です。決める人が社内か社外かを問わず、誰が決め、PMからその人までに何社入り、PMがその人へ直接再提案できるかを一組で記録します。顧客までに入る会社数と、社内外の誰が決めるかを別々の原因にはしません。

例の社員は、仕事そのものと実際の量を分ける

最初の表の場面名を変えず、原因ごとに分けると次のようになります。

最初に書いた場面	原因ごとの行	置く区分	根拠
見積と要員確保は元請けが決めるのに、納期と品質を管理する	納期・要員・品質を管理する	PMの役目に残る側	job tagがPMの仕事に挙げる
見積と要員確保は元請けが決めるのに、納期と品質を管理する	見積と要員確保を元請けが決める	案件・職場で変わる側	役目と決める人を分ける、この記事の整理
進捗資料と元請けへの報告で週の半分を使う	進捗・課題・対応策を報告する	PMの役目に残る側	job tagがPMの仕事に挙げる
進捗資料と元請けへの報告で週の半分を使う	社内と元請けへの報告で週の半分を使う	案件・職場で変わる側	報告する役目と報告量を分ける、この記事の整理
仕様変更は元請け経由で再調整する	進捗・課題・対応策を管理して報告する	PMの役目に残る側	job tagがPMの仕事に挙げる
仕様変更は元請け経由で再調整する	顧客と直接話せず、元請け経由で再調整する	案件・職場で変わる側	厚生労働省がIT業界にある受発注の仕組みとして説明
平常月35時間、リリース前70時間になる	進捗を管理する	PMの役目に残る側	job tagがPMの仕事に挙げる
平常月35時間、リリース前70時間になる	平常月35時間、リリース前70時間の実残業	案件・職場で変わる側	時間数はjob tagから決まらないため
12人のうち協力会社8人を含むチームをまとめる	チームを作り、メンバーの負担に配慮する	PMの役目に残る側	job tagがPMの仕事・配慮に挙げる
12人のうち協力会社8人を含むチームをまとめる	自社4人・協力会社8人で、本人に評価権限がない	案件・職場で変わる側	人数の内訳と評価権限は個別の体制だから

この例では、5場面を10行に分けました。場面を増やしたのではなく、PMを続ける限り残る仕事と、応募先で比べる値を分離しています。残業の場面から進捗管理の行も分けたのは、残る役目と、案件・職場で変わる実残業を混ぜないためです。例の社員は「平常月35時間、リリース前70時間の実残業」を一番変えたい値として選びます。

ほかのPMによくある場面は、別の早見表へ置く

例の社員にない場面は、次の表から自分の場面に近い行を探し、最初の区分と、次に確かめる値・問いを決めます。

場面	最初に置く区分	置く根拠	次に確かめる値・問い
顧客と開発側の意見を調整する	PMの役目に残る側	job tagがPMの仕事に挙げる	調整する相手
社内部門の要件がぶつかって決まらない	PMの役目に残る側	job tagがプロジェクト内の意見の調整をPMの仕事に挙げる	関係部門数、決める人、決定までの日数
発注側で複数のベンダーを管理する	案件・職場で変わる側	ベンダーの社数と決める人は個別の体制だから	ベンダーの社数、予算と要件を決める人
顧客と直接話せず、営業や元請けを経由する	案件・職場で変わる側	厚生労働省がIT業界の受発注の仕組みを説明	間に入る会社、直接話す人
複数案件を同時に担当する	案件・職場で変わる側	同時担当数は個別の配属だから、この記事の整理	同時案件数、各案件の人数
管理に加えて自分でも開発する	案件・職場で変わる側	開発時間の割合は個別の担当だから、この記事の整理	開発に使う時間の割合
教わらずにPMを任された	案件・職場で変わる側	教える人・前任者・相談相手は個別の体制だから	上長・PMO・前任者、確認の頻度
赤字や遅延だけで評価される	案件・職場で変わる側	評価項目と評価者は職場の仕組みだから	評価項目、赤字・遅延時の扱い
上司との人間関係がつらい	分からない側	求人票の記載から関係を予測できないため	相手、出来事、相談後の変化
炎上案件ばかりに感じる	分からない側	求人票では炎上の多さを測れないため	直近1年の大幅遅延案件数

リリース延期への対応は、進捗・課題を管理して報告する役目と、直近1年に延期が何回あったかという案件の値に分けます。大幅遅延の件数が分かれば「案件・職場で変わる側」へ置き直し、将来の延期の多さは「分からない側」に残します。

会社を移っても、管理・調整・報告は残る

「PMの役目に残る側」は、別の会社へ移れば消えるとは見込みません。厚生労働省job tagの「プロジェクトマネージャ（IT） - 職業詳細」は、IT分野のプロジェクトチームの責任者として、実行計画を作り、予算・要員・進捗を管理する仕事だと説明しています。必要な人員やリソースを調達して体制を作り、予算・納期・要員・品質を管理することも挙げています（2026年9月30日確認）。

同じ職業説明には、顧客などの関係者へ進捗・課題・対応策を報告し、顧客との意見の相違や、プロジェクト内の意見の違いを調整する仕事もあります。調整や報告そのものが一番つらいなら、決める人や残業が変わっても、PMを続ける限り残ります。

一方、job tagからは、同じ内容を何か所へ報告するのか、資料作成に週何時間かかるのか、PMが見積や要員確保をどこまで決めるのかは分かりません。同ページは、進捗によって忙しくなる場合があるとも説明していますが、平常月とリリース前の残業時間は示していません。仕事が残ることと、実際の量が同じことは別です。

プロダクトの優先順位やロードマップを決めるプロダクトマネージャーの悩みは、プロダクトマネージャーを続けるときの確かめ方で扱っています。

求人票で仕事の手がかりを読み、実際の値は面接で聞く

「案件・職場で変わる側」に置いた場面から、一番変えたいものを1つ選びます。求人票は仕事と案件の手がかりを読む場所です。誰が決めるか、応募する人がどの案件へ入るか、実際に何時間働いたかは、書かれていなければ面接へ回します。

求人票は欄の名前だけで読みません。勤務地・在宅・フレックス・組織・募集背景の欄が空でも、同じ情報が福利厚生のその他、PRポイント、仕事内容の中の見出しに書かれる場合があります。ページ全文から、次の順に語を探します。

題名、会社と案件の説明、仕事内容
応募資格の必須条件と歓迎条件
チーム、担当案件、相談相手の説明
勤務時間、休日、給与、福利厚生、その他

別の場所も探した後で見つからなければ、「確認できず」として面接へ回します。

仕事内容と案件の説明は、業務の記載まで読む

まず探すのは、予算、収支、原価、コスト、見積、要員計画、開発体制、チーム編成、リソース管理、進捗、課題、スケジュール、仕様変更、変更管理、スコープです。

進捗・課題管理も、予算・見積・要員も、どの対象求人にも書かない会社は約50%でした。これは仕事の有無ではなく、業務名を求人票に書いているかを数えたためです。仕事内容に予算や要員があってもPM本人が決めるとは限らないため、面接では見積・要員確保・仕様変更を誰が決めるかまで聞きます。この割合は、2026年9月30日時点で当サイトPREVIOに掲載中のPM・PL（Web・オープン系）の求人から、題名がPM・PL・プロジェクトマネージャー・プロジェクトリーダー・開発リーダーなどの募集と読めるものを、勤務地を限定せず全件集計した結果です。PdM・EM・PMO・コンサル・デザイナー・マーケティング・新卒、エンジニアのPL候補、会社名が伏せられた掲載は除きました。会社単位で、その会社の対象求人のどれか1件に書く場合を「書いてある」、どの対象求人にも書かない場合を「書いていない」とし、割合は5%単位に丸め、5%を下回るものは「5%未満」とします。以降の数字は求人票の記載率で、実際の権限・働き方の割合ではありません。

仕様変更、変更管理、スコープの管理・調整を仕事内容に書く会社は約10%でした。書かれていない会社に変更対応がないという意味ではありません。誰が再見積し、範囲と納期を顧客と再合意するかは、求人票からほとんど読めません。

次に、プライム、元請け、一次請け、直取引、客先常駐、常駐先、二次請け、発注側、ベンダーコントロール、SES、準委任を全文から探します。

プライム・元請け・一次請け・直取引を書く会社は約25%、客先常駐・常駐先を書く会社は約10%、題名・仕事内容に発注側・ベンダーコントロールを書く会社は約10%、SES・準委任を書く会社は約5%でした。二次請けの立場を書く会社は5%未満です。これは少なくとも1件の対象求人に語がある会社の割合で、書かない会社を下請けと分類する数字ではありません。

客先常駐の記載は、案件によってはという可能性の書き方が多くありました。会社単位の記載があっても、応募する案件で常駐するか、顧客までに何社入るかは別です。厚生労働省の「IT業界の働き方・休み方の推進｜IT業界の現状と課題」も、IT業界では客先常駐や、元請け・一次請け・二次請けなどの多重下請構造になる場合があると説明しています（2026年9月30日確認）。同ページが扱うのはIT業界全体で、PMやWeb・オープン系だけの割合ではありません。

同ページは、平成30年版過労死等防止対策白書の分析として、労災支給決定事案からみられる要因に厳しい納期、顧客対応、急な仕様変更などを、労働者アンケートで所定外労働が発生する理由にトラブル等の緊急対応などを紹介しています。顧客までの位置と決め方は、残業と切り離さず、同じ案件について聞きます。

応募資格の必須・歓迎は、配属後の仕事と分ける

応募資格にプライム案件の経験、見積経験、ベンダーコントロール経験などがあれば、企業が求める経験の手がかりにはなります。ただし、入社後の案件がプライムであることや、本人が見積・体制・仕様変更を決めることまでは示しません。仕事内容や案件説明にも同じ語があるかを見ます。

1件を読むときは、プライムSIerでの開発経験だけなら入社後の案件がプライムだとは読みません。経験に応じたアサインを想定も、プロジェクトの要員計画とは分けます。どちらも応募者の過去や配属方針の説明だからです。要員計画の手がかりにするのは、プロジェクトに必要な人を確保・配置する記載です。すでにいる開発メンバーへタスクを割り振る記載とは分けます。

PM・PL・リーダー未経験可と明記する会社は5%未満でした。研修の語を書く会社は約40%、資格取得支援を書く会社は約30%ですが、多くは全社共通の制度の説明です。研修制度や資格支援の記載から、入社後にPMを教える人や相談相手がいるとは読めません。上長・PMO・前任者の誰が、どの頻度で確認するかを面接で聞きます。

チームの人数は、自社社員と協力会社の内訳まで聞く

担当するプロジェクトやチームの人数を書く会社は約15%でした。この数字は担当チームの人数と読める記載を数えたもので、会社・部署全体の人数や、応募条件にある人数は除くようにしましたが、一部は残ります。人数があっても、自社社員と協力会社の内訳までは分からない場合があります。

複数案件の並行担当を書く会社は約5%でした。プレイング、自ら手を動かすといった語を書く会社も約5%ですが、多くは希望すれば可能、場合によっては、といった書き方です。PMが必ず開発も担う割合ではありません。面接では、配属予定の案件について、自社社員・協力会社・顧客側の人数、同時に持つ案件数、自分で開発する時間の割合を分けて聞きます。

PMOの支援や組織があると仕事内容に書く会社は5%未満でした。書いていない会社に支援がないとは決めず、上長・PMO・前任者の誰へ相談できるか、赤字や遅延が出たとき誰と判断するかを聞きます。

実残業・固定残業・年収例の計算時間を混ぜない

求人票にある時間は、次の3種類に分けます。

時間の種類	何を示すか	今の実残業と比べるか
実際の残業時間	会社・部門・職種などが実際に残業した平均・実績	対象と期間が配属予定先とそろえば比べる
固定・みなし残業の時間	給与に含む時間外手当の計算	比べない
年収例・手当計算の想定時間	年収例や手当を計算する前提	比べない

実際の残業時間の数字を書く会社は約30%でした。その会社の中では、月10～30時間程度のような範囲を上端で数えると、20時間以下が約80%、30時間以上が約15%です。この割合は実際の残業時間を書く会社だけが対象で、PM求人全体の残業分布ではありません。また、会社が書いた平均・実績であり、リリース前や障害時の時間を表すとは限りません。

固定・みなし残業の時間を数字で書く会社は約25%でした。その中では30時間以上が約70%、45時間が約25%です。これは給与計算に使う時間の分布で、実際に残業した時間ではありません。裁量労働制・管理監督者を書く会社は約20%でしたが、制度名から実際の労働時間は読めません。

さらに、想定時間外勤務手当（30時間相当）や上記は20時間相当で計算のように、年収例や手当の計算だけに時間を使う書き方があります。固定残業とも実残業とも決めず、賃金の計算方法と、配属予定の案件・チームの実残業を別々に聞きます。

夜間作業・休日対応・オンコールを書く会社は5%未満でした。書いていない会社に対応がないとは言えないため、直近のリリースと障害対応について、夜間・休日に動いた人数と回数、代わりの休みを聞きます。

空欄と食い違いを、今の職場と同じ単位の質問にする

求人票を読んだ後は、「多いですか」「裁量はありますか」ではなく、今の職場と同じ対象・期間・単位で聞きます。

例の社員が、全社の月平均残業が書かれた求人を1件開いたとします。全社の平均までは読めますが、配属予定に近い案件の平常月とリリース前月は読めません。そこで面接では、配属予定に近い案件の直近1年について、平常月とリリース前月の実残業を聞きます。

次の表は、例の社員がほかの場面も確かめるときの質問です。

変えたい場面	今の職場の値	求人票で探す手がかり	面接の質問
見積と要員確保は元請けが決めるのに、納期と品質を管理する	見積と要員確保は元請けが決定	仕事内容に見積・体制構築の記載	直近の案件で、見積と要員確保は誰が決めましたか。着手後に範囲・納期を再提案した例では、誰が決めましたか
仕様変更は元請け経由で再調整する	顧客までに元請け1社が入り、本人は顧客と直接話さない	案件説明にプライム・直取引などの記載	配属予定に近い直近の案件では、顧客までに何社入り、PMは誰と直接話しましたか
12人のうち協力会社8人を含むチームをまとめる	自社4人、協力会社8人。本人は評価権限なし	チーム人数の記載	直近の同規模案件は、自社社員・協力会社・顧客側が何人ずつでしたか。本人が直接評価するのは何人ですか
進捗資料と元請けへの報告で週の半分を使う	社内と元請けへ同じ進捗を報告。週の約半分	報告先・会議体の記載なし	直近の案件では、PMは誰へ週何回報告し、資料作成と会議に週何時間使いましたか
平常月35時間、リリース前70時間になる	平常月35時間、直近のリリース前月70時間	全社の月平均だけ記載	配属予定に近い案件の直近1年で、平常月とリリース前月の実残業は何時間でしたか。障害対応があった月は何時間でしたか

発注側の社内PMは別の例として、今の職場の値を混ぜずに質問を作ります。

変えたい場面	今の職場の値	求人票で探す手がかり	面接の質問
社内部門の要件がぶつかって決まらない	予算は部長決裁。関係部門の要件が衝突	仕事内容に部門調整・ベンダー管理の記載	直近の刷新案件では、何部門の要件を誰が決め、合意まで何日かかりましたか
発注側でベンダー3社を管理する	ベンダー3社。予算は部長決裁	仕事内容に発注側・ベンダーコントロールの記載	直近の同規模案件では、何社を管理し、予算と仕様変更は誰が決めましたか

仕事内容と応募資格で記載が食い違う、会社説明ではプライム中心でも案件説明には常駐の可能性がある、全社平均の残業しかない、といった場合は、都合のよい方を選びません。両方を示して、応募するポジションと配属予定の案件について聞きます。

評価や相談相手も同じです。案件が赤字・遅延したときの評価項目と評価者、上長・PMO・前任者へ確認した直近の頻度を聞きます。求人票の研修制度や役職名から、PMの相談先があるとは推測しません。

この見分け方で分からないこと

当サイトの集計は、日本のPM・PL求人全体を示すものではありません。職種名がコンサルの募集は除きましたが、PM・PLを募集する大手SIer・コンサル系企業の正社員求人は含み、掲載中の求人では目立ちます。多重下請けの下位にいる会社が少ないかどうかは数えていません。題名でPM・PLの募集に絞っても、職位の幅がある求人など境界の募集が含まれます。

会社単位の集計は、対象求人を多く出す会社ほど、少なくとも1件が「書いてある」に入りやすい数え方です。一方、顧客までの位置、常駐、決める人は同じ会社でも案件ごとに変わる場合があります。会社の記載率を、その会社の全案件の割合としては読めません。

求人票と面接で分かるのは、書かれた内容と説明時点の案件・実績までです。入社後も同じ決める人、顧客までの位置、チーム内訳、残業、相談相手、評価が続くとは限りません。大企業かスタートアップかという規模だけで、決め方や忙しさも判断できません。

人間関係や、将来どの案件が大きく遅れるかは、求人票と面接だけでは予測できません。「分からない側」に残った場面があることを理由に、会社を移れば全部解けるとも、PMを辞めるしかないとも決めません。

よくある質問

プロジェクトマネージャーはなぜきついと言われるのですか？

PM向けの解説記事では、納期・予算・品質を管理する重さ、顧客と開発側の意見の調整、仕様変更や障害対応、長時間労働、決める権限がないことなどが挙がります。ただし、管理・調整・報告という仕事と、誰が決めるか、報告量、実残業は同じではありません。原因ごとに3区分へ置いて考えます。

プロジェクトマネージャーを辞めたいなら、会社を変えるべきですか？

一律には決められません。見積や要員確保を決める人、顧客までの位置、社内と元請けへ同じ進捗を報告する量、チーム内訳、並行案件、実残業、相談相手、評価が主因なら、案件・職場で変わる余地があります。管理・調整・報告そのものが一番つらいなら、会社を移ってPMを続けても残ります。

プロジェクトマネージャーはやめとけと言われますが、辞めたほうがよいですか？

この記事では一律に判定しません。最近辞めたいと思った3〜5場面を、仕事そのものと実際の量・決め方に分けます。「案件・職場で変わる側」に置いた場面について、求人票と面接で今の職場との差を確かめてから判断します。

求人票に予算や要員があれば、自分で決められますか？

業務として担当することと、最終的に決めることは別です。求人票では予算・見積・要員の記載まで読み、面接で、直近の案件では誰が見積と要員確保を決めたか、着手後に範囲・納期を再提案したとき誰が決めたかを聞きます。

客先常駐や二次請けは求人票で見分けられますか？

記載があれば手がかりになりますが、書いていないだけでは否定できません。客先常駐を書く会社は約10%、二次請けの立場を書く会社は5%未満でした。これは会社単位の記載率で、応募する案件の実態を示す割合ではありません。面接では、配属予定に近い直近の案件について、顧客までに何社入り、誰と直接話したか、常駐した期間を聞きます。

プロジェクトマネージャーに向いていない人は？

性格だけで向き不向きを決めません。管理・調整・報告そのものが一番つらいのか、実際の量や決める人がつらいのかを分けます。管理・調整・報告そのものが一番つらいなら、PMを続けるかを考えます。実際の量や決める人がつらいなら、案件・職場の値を変えられるかを考えます。

まず1件、「案件・職場で変わる側」の場面から確かめる

最初に書いた3〜5場面を3区分へ置いたら、「案件・職場で変わる側」から一番変えたい場面を1つ選びます。PM・PL求人を1件開き、欄名に頼らず全文から仕事内容・応募資格・働き方の記載を探してください。

空欄や食い違いがあれば、今の職場と同じ対象・期間・単位の質問を1つ作ります。見積と要員確保なら決める人と再提案の直近例、残業なら配属予定に近い案件の平常月とリリース前月、人数なら自社社員と協力会社の内訳です。その1問を面接で聞ける形にしたところで、最初の確認は終わりです。