楽天で法人営業、NTTデータでシステム開発を経験。アクセンチュアでは業務要件定義から設計、UX/CX改善、生成AIを活用した業務効率化に従事。現在はリメディで、若手からエグゼクティブ層までの転職を支援。
SIerのPM経験は、ITコンサルのプロジェクトマネジメント職でも生かせます。要件定義、顧客への提案、予算・品質の管理、関係者の調整は双方にある仕事です。転職先を選ぶときの違いは肩書きよりも、担当する案件でどこから関わり、何を成果として求められるかにあります。
本記事で比べる「コンサルのPM」は、コンサルティング会社で顧客の変革案件やシステム導入を率いる人です。社内の職位名としての「マネージャー」とは区別します。
SIerのPMとITコンサルのPMは何が違いますか？
SIerのPMとITコンサルのPMは、顧客との調整やプロジェクト推進に共通点があり、役割の違いを比べる軸は担当工程や成果物です。厚生労働省のjob tag「プロジェクトマネージャ（IT）」は、予算・要員・進捗・品質の管理だけでなく、顧客の要件を明確にする仕事や開発計画の提案、関係者の意見調整も挙げています。
一方、job tag「ITコンサルタント」が扱う仕事は、IT戦略への助言から課題分析、システム方針の検討、導入まで広範囲です。構想に特化する人も、開発に近い仕事まで担う人もいます。コンサルティング会社の仕事を構想だけに限定する説明も、実態に合いません。
両職種は、要件定義や顧客との合意形成、導入推進で重なります。所属企業だけで役割を線引きするより、応募先の募集要項にある「担当する工程」「成果物」「顧客と社内チームの役割分担」を見る方が、転職後の仕事を具体的に捉えられます。
案件の担当範囲で変わる三つのPM業務
たとえば「基幹システムを刷新する」案件でも、着手前の構想、導入計画、複数の開発チームを束ねる工程では、PMに期待される仕事が変わります。次の表は雇用先による固定的な分類ではなく、募集要項を読むための整理です。
| 案件で担う範囲 | 主な仕事 | PM経験との接点 |
|---|---|---|
| 構想・投資判断 | 現行業務の課題を整理し、複数案の費用・効果・実現性を示す | 提案や要件定義で、選択肢と判断材料を作った経験 |
| 導入・移行 | 要件、体制、品質基準、移行計画を決め、稼働まで進める | 開発PMとしての計画、リスク管理、顧客・ベンダー調整 |
| 複数案件の横断PMO | 案件間の依存関係と意思決定事項を整理し、責任者へ報告する | 多部門・多ベンダー案件を束ね、優先順位を調整した経験 |
アクセンチュアのテクノロジーコンサルタントの募集例には、戦略・構想、要件定義・選定、システム構築・実行支援まで記載されています。PwCコンサルティングの中途採用部門紹介も、構想から運用までの実装力を説明しています。両社の記載から分かるのは、コンサルのPMにも導入と実行を率いる仕事があることです。個別の求人に記された担当範囲を基準にします。
上記のアクセンチュアの求人は管理職向けで、応募要件の一例として、5年程度以上のシステム構築経験も挙げ、望ましい経験に要件定義・システム構築と第三者ベンダーを含むプロジェクトマネジメントを記載しています。アビームコンサルティングの募集職種一覧には、製造業向けのIT企画・PMO支援と、消費財・小売流通・ヘルスケア向けのシステム導入PMが別の職種として並びます。PM経験があるという共通点だけで応募先を決めず、本人が率いた仕事と各職種の担当範囲を対応させます。
募集要項でPMの担当範囲を読む
募集要項は職種名より先に、仕事内容の動詞を読みます。「構想を策定する」「投資判断を支援する」とあれば、現状分析と選択肢の比較が仕事に含まれます。「要件定義から移行まで率いる」とあれば、顧客と開発チームの間で計画を実行する役割です。「複数案件を横断して課題を管理する」なら、個別チームの進捗だけでなく、案件間の依存関係や責任者への報告が中心になります。
次に、必須経験と望ましい経験を分けて読みます。たとえば前述のアクセンチュアの管理職求人は、システム構築経験を応募要件の一例に含め、第三者ベンダーを含むPM経験を望ましい経験に挙げています。PM経験が長くても、全ての工程を本人が担当したと見なしてよいわけではありません。要件定義を主導したのか、決まった要件を受けて計画を動かしたのかを、求人の言葉と照らします。
最後に、入社後に作る成果物を見ます。企画書や投資判断資料、移行計画、横断課題の管理表では必要な経験が異なります。募集要項から読み取れない場合は、面談で最初の配属案件の工程と、本人が責任を持つ成果物を聞くと、肩書きだけでは見えなかった仕事の輪郭がはっきりします。
SIerのPM経験を応募先の仕事に結び付ける
職務経歴書では、工程名とプロジェクト規模に加え、応募先と重なる判断や調整の場面を書きます。経験を別の言葉に置き換えるだけでは、担当した仕事は増えません。本人が実際に作った資料、提案した選択肢、合意後に動かした体制を具体的に示すことが必要です。
| 経験 | 応募書類で示す事実 | つながる仕事 |
|---|---|---|
| 要件定義・顧客提案 | 誰の要望を調べ、複数案を何で比べ、どの範囲を合意したか | 構想、業務・システム方針の検討 |
| 開発・移行PM | 体制と品質基準をどう決め、遅延や障害にどう対応したか | システム導入、実行支援 |
| 複数ベンダーの管理 | 会社間の責任範囲と依存関係をどう整理したか | 横断PMO、ベンダー管理 |
| 稼働後の改善 | 利用部門の課題をどう把握し、手順や運用体制をどう変えたか | 定着支援、業務改善 |
たとえば「100人規模の案件で進捗を管理」と書く場合、人数は規模の情報です。応募先が導入PMを募集しているなら、計画から稼働までの責任範囲、問題が起きた時に示した代替案、顧客が選んだ方針まで書くと実務が伝わります。構想職へ応募する場合は、投資や業務方針の検討に参加した事実があるかを先に確かめます。参加していなければ、導入PMの実績として正確に示します。
経験別に選ぶ応募先の入口
大規模なシステム開発を率いたPMは、導入推進や横断PMOの募集と経験が重なりやすくなります。ベンダー管理に加え、発注側の責任者へ判断材料を示した経験があれば、顧客との調整も説明できます。応募先の募集要項では、単一案件のデリバリーを担うのか、複数案件を横断するのかを見分けます。応募先の企業タイプや求人にある担当範囲を比べるなら、ITコンサル大手8社の主な領域と担当工程も参考になります。
要件定義や業務改革を主導したPMは、業務・ITの構想を扱う職種も候補に入ります。顧客の要望を受け取っただけか、現行業務を調べて選択肢を提案したかで、示せる経験は異なります。社内SEを兼ねたPMなら、利用部門との調整やIT投資の判断材料を作った範囲を示せます。
進捗管理や運用管理が中心だった人は、導入PMOや運用改善の募集から仕事の接点を探せます。構想職を希望する場合は、現職で提案や要件定義の担当を増やす道もあります。募集職種と担当実績の対応で判断します。30代・40代SEからコンサルへの移行では年代別の経歴整理を扱っています。
職務経歴書と面接で説明する順序
まず案件の目的と本人の担当範囲を分けます。次に、予算・納期・品質の制約下で起きた問題、提示した選択肢、判断した人、実行後の結果を書きます。チームの成果を本人だけの判断として書かず、役割を正確に示した方が面接で深掘りされたときも説明できます。
記載例を挙げると、「基幹システム更新のPMとして、利用部門の要望を整理。追加要件による移行延期と段階稼働の二案を、費用・業務影響・必要人員で比較し、顧客責任者の判断に必要な資料を作成。決定後は関係する二社の工程を変更し、稼働まで進めた」という形です。案件規模や成果は実際の事実に置き換えます。自分が最終決裁者でなかったなら、判断材料を作った役割として書きます。
面接では、書類に記した判断の前提と、自分が担った仕事を同じ順序で話します。PMPなどの資格は経験を補う材料です。資格そのものを主題にする前に、PMPとコンサル転職の記事で募集職種との関係を確かめられます。
応募職種に合わせた面接準備
導入PMを希望する場合は、計画が崩れた場面を一つ選びます。遅延の原因をいつ把握し、代替案を誰に示し、どの判断を受けて工程を変更したかまで話せるようにします。単に「関係者を調整した」と言うより、合意前に残った論点と、合意後に変わった仕事を示した方が担当範囲が伝わります。
横断PMOを希望する場合は、複数案件の共通課題をどう集め、責任者が何を決められる形にしたかを準備します。会議の運営や進捗集計を担当しただけなら、その役割を正確に説明します。課題の優先順位や予算配分を提案した経験があれば、判断の根拠と自分の権限を分けて話します。
構想・業務改革の職種を希望する場合は、提案前の調査が問われます。現行業務のどの問題を調べ、何案を比較し、費用や現場の負担をどう示したかが材料です。本人が構想を担当していない場合は、導入段階で顧客へ提示した選択肢や、稼働後に改善した業務を材料にします。応募先の仕事内容と距離がある部分は、経験がないまま言い換えで埋めません。
転職先の職位・報酬と仕事の範囲
同じ「PM」でも、管理する案件の規模、顧客との接点、部下の有無で職位は変わります。オファーを見る際は、基本給と賞与など変動する金額、初年度の担当範囲、評価される成果を並べて考えます。報酬の資料はSIer業界の年収とコンサル業界の年収に分けてあります。
求人票に「上流から携わる」とあっても、構想から入るのか、要件定義から入るのかで仕事は変わります。面談では、最初の案件で担当する工程、顧客側の意思決定者、PMが作る成果物を聞くと、現在の経験との距離が明確になります。
SIerのPMからコンサルへ移る際のよくある疑問
QCD管理の経験だけでも応募できますか
導入PMやPMOの募集では、計画、予算、品質、進捗を管理した経験は直接関係します。担当した案件の規模に加え、問題が起きた場面で何を決め、誰と調整したかを示します。構想職では提案や方針検討の経験を求める場合があるため、募集要項の要件で見分けます。
コンサルのPMはコードを書かなくなりますか
担当職種によります。構想や横断PMOでは実装を直接担わないこともあります。導入支援では、技術上の制約を理解したうえで設計や移行の判断に関わる仕事があります。求人票の担当工程と、実装チームとの分担を見ます。
PM経験を生かせる職種をどう絞りますか
直近の案件から、要件・投資判断、導入・移行、複数案件の横断管理のうち、本人が責任を持った仕事を選びます。応募先の募集要項で同じ仕事が求められている職種を先に探すと、志望理由と職務経歴書の内容をそろえられます。
案件経験を応募職種に当てはめる段階で迷う場合は、担当範囲を整理した職務経歴書を基に、ITコンサルへの応募先と伝え方を転職支援の担当者に相談できます。
関連記事
- SEからITコンサルへの転職：PM以外の経歴も含めた移行ルート
- PMPとコンサル転職：資格と実務経験の位置づけ
- ITコンサルの職務経歴書：担当した仕事を文章にする方法
- SEからITコンサルで変わること：役割や働き方の違い
「課題解決」という言葉だけでは、構想を練る仕事か、導入後の定着まで担う仕事かは分かりません。過去の案件も、意思決定の材料を作った経験や、現場の運用を変えた経験に分けると、応募職種ごとに何を前に出すか決めやすくなります。