職種の求人市場

プロジェクトマネージャーはきつい?追加要望を断れない会社の見分け方

顧客とメンバーの間に立つこと、結果の責任を問われることは、PM を続ける限りどの会社でも付いてきます。一方、見積や再見積を決める権限を渡さずに結果だけ PM の責任にするのは、仕事の性質より、会社が案件をどう受けているかの問題に近いと当サイトは見ています。追加要望を断れない会社の特徴、求人票で読めること、今の会社で上司に聞くことと面接で聞くことを書きました。

公開 2026年9月30日 · 更新 2026年10月9日 · 集計 2026年9月30日 · PREVIO 編集部

この記事で分かること

  • ・顧客とメンバーの間に立つこと、結果の責任を問われることは PM に付いてくる。見積や再見積を決めさせずに結果だけ PM の責任にするのは、会社の案件の受け方の問題に近い
  • ・求人票では、見積や再見積を誰が決めるかまでは読めない。面接では直近の案件で、再見積を決めたのは誰だったかを聞く
  • ・今の会社に残るなら、次の案件の前に上司と吸収してよい範囲を決め、最初の追加要望で案が元請けまで届くかで判断する
目次開く
  1. 01顧客との調整と結果の責任は残る。自分で決めていない見積や納期の責任は会社で変わる
  2. 02追加要望を断れない会社では、何が重なっているのか
  3. 03PM が「変更をコントロールする」とは、どこまでのことか
  4. 04求人票で、追加要望を断れる会社を見分けられる?
  5. 05確かめるには、直近の案件で実際にどうだったかを聞く
  6. 06「コードを書く仕事に戻りたい」のは、手を動かしたいから?責任の取らされ方が嫌だから?
  7. 07よくある質問
  8. 08この記事の数字と見立てについて

受託開発の会社で PM になって 3 年目の人がいるとします(架空の例です)。元請けの下で EC サイトのリニューアルを担当していて、見積と納期は、本人が案件に入る前に営業部長と元請けの間で決まっていました。要件定義の後に追加要望が 3 つ出て、再見積をしたいと部長に相談すると「元請けとの関係があるから飲んで」。リリース直前にまた仕様が変わり、メンバーに休日出勤を頼んで何とかリリースした。振り返りでは「仕様変更をコントロールできなかったのは PM の責任」と言われた。

このうち、顧客とメンバーの間に立って双方の言い分を相手に通じる形に直すことと、結果の責任を問われることは、PM を続ける限りどの会社でも付いてきます。 けれども、見積・要員・再見積を決める権限を渡さずに、結果だけを PM の責任にするのは、PM という仕事の性質というより、その会社が案件をどう受けているかの問題に近いと当サイトは見ています。

この例の会社では、仕様変更をリリース日を動かさずに飲むことと、元請けの下で PM が顧客と交渉できないことが重なっていました。この形だと、PM にできるのは、飲むと何人日増えて何が削られるかを、決める立場の人に記録つきで渡すところまでです。誰が決めるのかは、求人票ではほとんど読めません。今の会社なら次の案件の前に上司に、転職するなら面接で、直近の案件のことを聞いて確かめます。

顧客との調整と結果の責任は残る。自分で決めていない見積や納期の責任は会社で変わる

PM のきつさを場面ごとに見ると、次のようになります。

きつさ場面会社を変えたら
顧客とメンバーの間に立つメンバーが「実装が難しい」と言う仕様を、工数つきの代案にして顧客に出す。顧客の要望は、メンバーが作業に移せる形に直して渡す残る。相手が社外の顧客か社内の部門かは会社で違う
結果の責任を問われる要望を満たせたか、品質や予算は守れたかを PM が問われる残る
答えのない判断をする納期を守るために、誰の作業を増やすか、どの機能を削るかを決める残る
コードから離れる一日の多くが、進捗表と報告資料の作成と会議で終わるPM である限り残る。どこまで手を動かせるかは会社で違う
自分で決めていない見積・納期の責任を取る金額と納期は受注の時に決まっていて、PM はその後で案件に入る会社で変わる。PM が見積作りに加わるか、再見積を誰が決めるかで違う
仕様変更を飲むリリース日は動かせないので、遅れを残業と休日出勤で取り戻す変更が来ること自体は残る。再見積や納期の調整を誰がするかは、会社と商流で変わる
顧客と交渉できない元請けを通さないと顧客と話せない会社と案件で変わる

厚生労働省の job tag は、PM の仕事として、予算・納期・要員・品質の管理、顧客との意見の相違やプロジェクト内の意見の違いの調整を挙げ、要望を満たしたか、品質、予算内に収めたかなどは「すべてプロジェクトマネージャの手腕にかかってくる」と書いています(厚生労働省 job tag「プロジェクトマネージャ(IT) - 職業詳細」、2026 年 10 月 9 日確認)。顧客との調整も、結果を問われることも、PM の仕事の中身そのものです。

ただし job tag は、予算・納期・要員を管理する役として PM を書いています。予算も納期も要員もほかの人が決め、結果だけを PM が引き受ける形は、この説明とは合いません。表の上 4 行は PM である限り付いてきますが、下の 3 行は、会社を選べば軽くできる側です。

追加要望を断れない会社では、何が重なっているのか

最初の例で重なっていたのは、次の 2 つです。

まず、仕様変更が来たときに、リリース日を動かさずに受け入れること。変更が来ること自体は避けられません。厚生労働省は、IT 業界についての過労死等防止対策白書の分析として、過労死等の労災支給決定事案からみられる要因に「厳しい納期」「顧客対応」「急な仕様変更」などがあることを紹介しています(厚生労働省「IT業界の働き方・休み方の推進|IT業界の現状と課題」、2026 年 10 月 9 日確認。PM に限らない IT 業界全体の話です)。会社によって違うのは、変更を受ける代わりに、追加の費用、納期の延長、作る機能を減らすことのどれかと引き換えにする話ができるかどうかです。

次に、元請けの下に入っていて、PM が顧客と交渉できないこと。同じページは、元請け・一次請け・二次請けといった多重下請構造になることもある、と書いています。顧客とは直接話せず、条件を変えたくても相手は元請けで、その元請けとのやりとりは社内の営業や部長が受け持っている。これでは、PM が再見積が必要だと分かっていても、その話を顧客側まで持っていく手段がありません。

ここに、PM が見積作りに加わっていないことが重なると、最初の例のようになります。見積を決めたのは営業と元請け、追加要望を飲むと決めたのは部長、結果を問われるのは PM、という形です。

PM が「変更をコントロールする」とは、どこまでのことか

当サイトの考えでは、変更をコントロールするとは、変更が来るたびに影響を見積もり、どう受けるかを決める立場の人に選んでもらうことです。受けたら作業が何人日増えるか、納期や品質のどこに影響するかを出し、受けるなら何を代わりにするか(追加の費用をもらう、リリース後に回す、別の機能を削る)を示します。そして、決まったことを記録に残します。

最初の例でいえば、追加要望が 3 つ出た時点で、受けると何人日増え、テストの期間が足りなくなるかをまとめて部長に渡し、受けるという判断をメールで残してもらう。リリース直前の変更なら、その変更をリリース後の追加対応(2 次対応)に回す案を作る。元請けとのやりとりを部長が受け持っているなら、PM が部長を通さずに元請けへ案を出すのではなく、この内容で、今週中に部長から元請けに出してもらえないかと期限を付けて部長に渡します。元請けに出すかどうかの判断も、部長に任せる形です。

記録を残したことで振り返りでの言われ方が変わった、という実例はこの記事では示せません。部長が「分かった、でも何とかして」と言えば、現場の負担は変わりません。それでも記録があれば、振り返りは「PM がコントロールできなかった」ではなく、部長が受けると決め、その影響は事前に伝えてあった、という事実から話せます。PM ができるのはここまでです。この先を決める権限が渡されないまま結果だけ問われるなら、それは PM の力量より、会社の案件の受け方の問題に近いと当サイトは見ています。

求人票で、追加要望を断れる会社を見分けられる?

PM が何を決められるかまでは、求人票では分かりません。

当サイトの PM・PL(Web・オープン系)の掲載求人では、予算・見積・要員のどれかを PM の仕事内容に書いている会社は約 35% でした。ただ、これは仕事内容にその言葉があるかどうかで、PM がそれを決める立場かまでは分かりません。

取引の形も同じです。プライム・元請・直取引を書いている会社は約 25% で、二次請けの立場を書いている会社は 5% 未満でした。書いていない会社が下請けとは限りません。仕様変更・変更管理を仕事内容に書く会社は 1 割弱で、変更が来たときに誰が再見積を決めるかは、求人票からはほとんど読めません。

求人票で手がかりになるのは、仕事内容に予算・見積・要員計画があるかと、元請けや直取引を書いているかの 2 点です。追加要望を断れる会社かどうかは、面接で直近の案件のことを聞いて確かめます。

確かめるには、直近の案件で実際にどうだったかを聞く

会社の方針を聞いても、実際に誰が決めているかは見えにくいものです。聞くのは、直近の案件で実際に起きたことです。今の会社に残るか、PM のまま転職するかで、聞く相手が変わります。

今の会社に残るなら、次の案件の前に上司に聞く

次の案件がもう決まっていても、要件定義が始まる前なら、上司と取り決めておけることがあります。大事な順に 3 つです。

  1. 「追加要望が出たら、何人日までは自分の判断で吸収して、どこから上げればいいですか」 いちばん大事なのはこれです。上限が決まれば、それを超える要望をどうするかは上司が決めることになります
  2. 「見積は、どこまで含む前提で出しましたか。内訳を見せてもらえますか」 見積に入っていなかった作業まで、後から PM の責任にされないようにするためです
  3. 「再見積を元請けに言うかどうかは、いつまでに誰が決めますか」 できれば、キックオフで上司にも同席してもらい、要件定義の後の変更をどう扱うかを元請けとも確かめます

今の会社を見切るかどうかは、何か月待つかより、何が起きたかで決めます。この 3 つを聞いて答えが返ってこず、「そんなこと決めなくていい」と言われたら、要件定義を待たずに、案件の受け方は変わらないと考えてよいと思います。答えが返ってきたら、最初の追加要望が出たときに、影響をまとめた案を上司が元請けに持っていくかを見ます。再見積や 2 次対応の案が一度でも元請けに届けば、前の案件とは扱いが違います。そこでもはっきりしなければ、リリース後の振り返りが、また「PM の責任」の一言で終わるかどうかが最後の目安です。

PM のまま転職するなら、面接で聞く

  1. 「直近の案件で、着手後に追加要望が出たとき、再見積を決めたのはどなたでしたか」 PM が決めたのか、営業や部長が決めたのかで、自分で決めていないことの責任まで PM が負う会社かどうかが分かります
  2. 「その案件では、お客様まで間に何社入っていましたか。お客様と直接話すのはどなたですか」 PM が顧客と直接交渉できるかが分かります
  3. 「PM ご自身が設計やテストを持つ割合はどれくらいですか。それは最初から PM の担当ですか、人が足りないときに PM が入る形ですか」 手を動かす量が同じでも、抜けた人の穴を PM が埋める形だと、マネジメントと実務を両方抱えることになります

「コードを書く仕事に戻りたい」のは、手を動かしたいから?責任の取らされ方が嫌だから?

両方が混ざっていても不思議ではありません。この半年で一番きつかった日を思い出すと、見当がつきます。「飲んで」と言われた日や、振り返りで責任を問われた日なら、つらさの中心は責任の取らされ方です。一日中、資料作りと会議に追われてコードに触れなかった日なら、手を動かしたい気持ちのほうです。

もう 1 つの手がかりは、見積や再見積に関われて、追加要望には追加の費用や納期の延長を認めてもらえる会社だったら、PM を続けたいかどうかです。続けたいと思えるなら、それは会社を変えれば軽くなる側のきつさです。それでもコードを書きたいなら、問題は会社選びではなく、PM を続けるかどうかです。コードから離れることは、どの会社でも PM である限り残るからです。job tag も、SE から課長などに昇進して PM と呼ぶ会社が多いと書いています。コードを書いていたかった人が、昇進して PM になることは起こりえます。

コードを書きたい気持ちが少しだけ残っているなら、PM のまま転職して、面接の 3 つ目の質問で手を動かす余地を確かめる道があります。当サイトの PM・PL の掲載求人で、プレイングや自ら手を動かすことを書いている会社は約 5% で、その多くは「可能」「場合によっては」という書き方でした。求人票より面接で聞くほうが確かです。

エンジニアに戻った場合の年収や、何年かコードを書いていない人が書類選考をどれくらい通るかは、示せる資料が手元に無く、この記事では言えません。

よくある質問

プロジェクトマネージャーは激務ですか?

job tag は、労働時間は通常は平日の朝から夕方までで、進捗によっては忙しくなる場合もある、と書いています。当サイトの見立てでは、忙しさを左右するのは、変更が来たときにリリース日を動かさずに受けるかどうかと、リリースや障害のときの夜・週末の体制です。どちらも求人票ではほとんど読めません。

PM に向いていないから、きついのでしょうか?

顧客とメンバーの間に立つことや、答えのない判断をすること自体が苦痛なら、向き不向きの問題かもしれません。自分で決めていないことの責任を取らされるのがつらいなら、向き不向きより、会社の案件の受け方の問題に近いと考えられます。どちらがつらいのかを分けてから、PM を辞めるか、会社を変えるかを考えると判断しやすくなります。

PL や PdM なら楽ですか?

役割が違います。初めて PL を任された人の悩みはプロジェクトリーダーの記事で、何を作るかを決めるプロダクトマネージャーの悩みはプロダクトマネージャーの記事で扱っています。

この記事の数字と見立てについて

  • 当サイトの数字は、2026 年 9 月 30 日時点で当サイト PREVIO に掲載していた PM・PL(Web・オープン系)の求人を、題名で PM・PL の求人に絞り、会社単位で数えました。「書いている会社」は、その内容に当たる求人を 1 件以上出している会社です。割合は 5% 単位に丸めています
  • 数えたのは求人票に書いてあるかどうかで、職場の実態ではありません。書いていなくても、その仕事や取引の形が無いとは限りません。日本の PM の求人全体の数字でもありません
  • 厚生労働省の IT 業界のページは、IT 業界全体についての記述で、PM に限った話ではありません
  • 他社の PM が見積や納期にどこまで関われているか、記録を残して言われ方が変わった例、エンジニアに戻った場合の年収、書類選考の通りやすさは、示せる資料が手元に無く、書いていません
  • 次のものは当サイトの見立てと助言で、会社や上司によって当てはまらないことがあります
    • 決める権限を渡さずに結果だけ問うのは、会社の案件の受け方の問題に近いこと
    • 変更をコントロールするとは、影響と選択肢を決める立場の人に記録つきで渡すことだという考え
    • 元請けとのやりとりを上司が受け持っているときの案の渡し方
    • 上司に聞く 3 つと、見切るかどうかの決め方
    • 面接で聞く 3 つ
    • 「コードを書く仕事に戻りたい」理由の見分け方
    • 忙しさを左右するのは、変更をリリース日を動かさずに受けるかと、夜・週末の体制だという見方
あなたの経歴、最高でいくら?確かめる