PMの職務経歴書の書き方｜体制・予算・判断の記載例とPL・PMO経験の書き分けを解説

相談してみる→

監修リメディ株式会社 ヘッドハンター日髙 大志

筑波大学大学院を卒業後、海外駐在を経て、KPMGコンサルティング株式会社に参画。先端技術・DXコンサルタントとして、官民のDX推進・新規事業創出に携わる。その後、リメディからのヘッドハントを受け参画。リメディでは、緻密なキャリア設計・徹底的な選考対策・自身の経験に裏打ちされた深い業務知見を軸とした支援により、コンサルティングファームへの支援に圧倒的な強みを持つ。IT領域を中心に広範な領域で実績を有するが、特にDX領域のエグゼクティブ層支援において業界トップクラスの支援実績を有する。

SIerや事業会社でPM・PLを担ってきた人の職務経歴書は、案件ごとに体制の人数と自分の位置、予算への権限、期間と工程、自分の判断とQCD（品質・コスト・納期）の結果を書くと、募集要項と照らし合わせてもらいやすくなります。2026年10月時点で確認したSIer・事業会社・コンサル3社5件の募集要項も、肩書きより「何を主体的に管理したか」を問う書き方でした。PMOとして支援してきた人や、事業会社で発注側だった人も対象にしています。PLやPMOの経験は肩書きを上げずに管理範囲で書き分け、炎上した案件も外さずに事実・打ち手・結果・再発防止の順で書く。この2つを判断の軸にしてください。

本記事のポイント

迷いやすい6つの判断は、どれも何を管理し、何を決めたかを書類で示すことに行き着きます。

判断したいこと	結論
書く単位	職歴ではなく案件ごと。1案件に体制・予算・期間・工程・判断・結果をそろえる
読み手が確かめる点	体制の規模と自分の位置、QCDを自分が管理したか、関係者とどう合意したか
PL・PMOの経験	PMと書き換えず、管理した範囲と自分が提言・決定した事項を分けて書く
炎上・遅延した案件	外さない。事実、自分の打ち手、結果、再発防止の4点で短く書く
応募先による違い	SIerはQCDと業務知識、事業会社は合意形成と選定判断、コンサルは経営層への報告と業務領域
相談したほうが早い場面	代表案件を絞れない、PL経験でPM枠に応募する、守秘義務で書ける範囲に迷う

PMの職務経歴書で見られるポイント

読み手が最初に確かめるのは、QCDを自分で管理した経験があるかどうかです。PMという肩書きの有無より、計画・体制・品質・コスト・納期のどこまでを自分の判断で動かしたかが問われます。

募集要項は「主体的に管理したか」を見ている

NTTデータ関西のプロジェクトマネージャー（管理職）の募集要項は、必須経験に「品質、スケジュール、コストを主体的に管理した経験」を挙げています（同社採用ページ、2026年10月時点）。KPMGコンサルティングのグローバルPM募集も、職務に「全体管理(SQCD)に責任を持つ」と書いています（同社採用ページ）。

公的な職業定義も同じ範囲を示します。厚生労働省の職業情報提供サイト（job tag）は、PMの仕事を実行計画の作成と予算・要員・進捗の管理と説明し、規模は数人から数百人まで幅があるとしています。同じPMでも案件の大きさが違うため、職務経歴書では規模と管理範囲を書かないと比べてもらえません。

1案件を書く型：体制・予算・期間・工程・判断・結果

案件は次の6項目で書くと、募集要項の管理項目と1対1で照らし合わせられます。「判断」の欄が空く案件は、PMとしての記載が弱い案件です。

項目	書く内容	書き方の例
体制	総人数と内訳（自社・協力会社・顧客側）、自分の位置、直接まとめた人数	体制【人数】名（自社【人数】名・協力会社【社数】社）、PMとして全体を統括
予算	自分の権限（見積り作成・予算配分・追加費用の承認）	見積りと予算配分を担当、追加費用は顧客と協議して決定
期間	開始と終了の年月、自分が関わった期間	【年月】〜【年月】、要件定義から参画
工程	担当した工程と開発手法	要件定義〜稼働後の運用引き継ぎまで
判断	自分が決めたこと、提言して承認されたこと	移行方式を一括から段階移行へ切り替える案を出し、顧客の承認を得た
結果	QCDの計画に対する結果、残った課題	稼働日は計画どおり、工数は計画比【数値】%で着地

【　】の部分には自分の実績を入れてください。数字を出せない項目は、無理に作らずに「計画どおり」「計画より遅れ、【対応】で回復」のように事実で書きます。

職務要約には代表案件と管理範囲を書く

職務要約は、代表案件を1件か2件と、そこで自分が管理した範囲を数行で示す欄にします。厚生労働省のハローワークインターネットサービスは、職務経歴書を応募先企業に応じて作成する考え方を示しています。応募先がSIerか事業会社かで、先頭に置く案件を入れ替えてください。

代表案件を絞るには、応募予定の求人の必須経験と自分の案件を1行ずつ並べ、要件に一番近い案件を要約の1件目にします。それでも絞りきれない場合は、求人の要件を知るエージェントと一緒に決めるのも一つの方法です。

経歴別に強調すべき実績（PM・PL・PMO・発注側）

同じ「プロジェクト経験」でも、立場によって先に書く項目が違います。表で自分に近い行を選び、「先に書くこと」の列から案件を書き始めてください。

現在の経歴	先に書くこと	避けたい書き方	補う情報
PMとして案件を任されてきた	体制規模、QCDの結果、自分の判断	担当案件を年代順に並べるだけ	計画からのずれと立て直し
PL（リーダー）経験が中心	チーム人数、仕様調整、品質の管理	PMと書き換える	PMの判断を支えた範囲
PMOとして支援してきた	管理した範囲、提言して採用された事項	PMの決定を自分の決定として書く	報告先と管理の仕組み
事業会社で発注側だった	ベンダー選定、社内の合意形成、投資の説明	「ベンダー管理」の一言で済ませる	選定の基準と結果

PMとして案件を任されてきた人

PM経験者は案件数が多くなりがちです。全件を同じ分量で書くより、応募先に近い数件を厚く書き、残りは一覧にまとめたほうが読み手は比べやすくなります。厚く書く案件では、計画どおりに進んだ点だけでなく、計画からずれたときに何を決めたかを残してください。

PL（リーダー）経験が中心の人

PLとPMの違いは、同じ会社の募集要項を並べるとよく分かります。NTTデータ関西の開発リーダー募集は、必須経験を「開発経験3年以上」「主体となった仕様調整」「5人程度のチームマネジメント」としています（同社採用ページ）。同社のPM（管理職）募集が求めるのは、管理職経験とQCDの主体的な管理です。

PL経験が中心なら、肩書きはPLのまま書きます。そのうえで、チームの品質や進捗を自分で管理した範囲と、PMの判断のために用意した材料（見積り、リスクの洗い出し、代替案）を分けて書くと、PM枠に届く経験がどこまであるかが伝わります。

PMOとして支援してきた人

PMOの経験は、要項上も評価の対象です。KPMGコンサルティングのグローバルPM募集は歓迎要件に「グローバルPMまたはグローバルPMOの立ち位置でフルサイクル経験」を挙げ、同社の金融PMO募集はリーダー経験かPM経験のいずれかを応募資格にしています（同社採用ページ）。

リメディの見解では、上の2件の要項がPMOの立ち位置をそのまま書いている以上、PMOの経験をPMと言い換える必要はありません。課題管理や進捗報告の仕組みを何件の案件で回したか、どの提言がPMや経営層に採用されたかを書き、最終判断を誰が下したかは正直に残してください。PMOとPMの役割の違いを確かめたい場合は、PMOの仕事内容とPMとの違いが参考になります。

事業会社の情報システム部門で発注側だった人

発注側の経験は、自分で手を動かした量が少なく見えやすい経歴です。LINEヤフーのコーポレートIT向けテクニカルプログラムマネージャー募集は、望ましい経験にSaaS製品などの選定・導入を挙げ、職務に経営層との投資対効果の検証を含めています（同社採用ページ。職種名はPMではなくTPM）。選定の比較軸、社内で合意を取った相手、導入後に何が変わったかを書けば、発注側としての判断が伝わります。

書類選考で落ちやすい書き方

落ちやすい書類に共通するのは、読み手が規模と役割を判断できないことです。表現を少し足すだけで直せるものが多いため、提出前に次の表と照らしてください。

役割と規模があいまいなNG例

NG表現	読み手が判断できないこと	直し方
大規模プロジェクトを担当	何人・何社の体制か、自分はどこにいたか	総人数と内訳、自分がまとめた人数を書く
PMとしてプロジェクトを推進	何を決めたのか	自分が決めた事項と、顧客の承認を得た事項を書く
無事にリリースした	計画どおりだったのか	稼働日・工数・品質を計画と比べて書く
ベンダーを管理した	契約・進捗・品質のどれを管理したか	管理した項目と、問題が出たときの対応を書く
開発経験は省略	技術的な判断ができるか	PMになる前の設計・開発経験も短く残す

最後の行は見落とされやすい点です。job tagは、PMになる人の多くがシステムエンジニアなどとして構築や運用を経験していると説明しています。開発経験を消すと、技術的な判断の土台が書類から読めなくなります。

炎上・遅延案件の書き方

炎上や遅延を起こした案件を、職務経歴書から外す必要はありません。job tagは問題を早期に把握して対策を講じ、関係者に課題と対応策を報告することをPMの仕事に含めています。KPMGコンサルティングの募集も、ステアリングコミッティへの報告内容に「見通し、主要リスク、対応方針、審議依頼」を挙げています。

リメディの見解では、問題が起きた案件こそPMとしての判断を書ける場所です。書くときは4点に絞り、「何が起きたか」「自分が何を決めたか」「結果どうなったか」「次の案件で何を変えたか」を順に書き、原因を顧客や協力会社だけに帰す書き方は避けてください。立て直せなかった場合も、結果を隠さず、そこから変えた進め方を書けば判断の筋道は伝わります。

Before / After の書き換え例

架空の数字を入れないよう、【　】に自分の実績を当てはめる形で示します。

場面	Before	After
体制	大規模な基幹システム刷新でPMを担当	【業界】向け基幹システム刷新。体制【人数】名（自社【人数】名・協力会社【社数】社）、PMとして全体を統括
遅延への対応	スケジュール遅延が発生したが、チーム一丸で乗り切った	結合テストで【件数】件の不具合が集中し、稼働日が危ぶまれた。テスト範囲の優先順位を見直す案を出して顧客と合意し、稼働日は維持。以後の案件では結合テスト前の確認工程を追加
発注側の判断	SaaS導入プロジェクトを推進	【部門】向けSaaSの選定で【社数】社を比較。比較軸を【観点】に定めて社内の承認を取り、導入後は【業務】の処理手順を変更

Afterの共通点は、自分が決めたことが動詞で書かれている点です。「乗り切った」「推進した」のような結果だけの言葉を、「案を出した」「合意した」「比較軸を定めた」に置き換えるだけで、面接で聞かれる内容も絞れます。

募集要項から読み解く成果指標

成果指標は、応募先の募集要項の文言から決めます。確認した3社5件の要項に出てくる経験を、職務経歴書の項目に置き直すと次のようになります。

募集要項で求められる経験	職務経歴書で書く項目	成果指標	NG表現	改善方向
品質・スケジュール・コストの主体的な管理（NTTデータ関西 PM・必須）	計画と実績、自分が下した判断	稼働日、工数の計画比、重大障害の有無	無事に完了	計画との差と打ち手を書く
複数組織にまたがる中・大規模なPM経験（同・望ましい）	体制の内訳、関わった組織数	人数、協力会社数、拠点数	大規模案件	内訳と自分の位置を書く
5人程度のチームマネジメント（NTTデータ関西 開発リーダー・必須）	チームの人数と役割分担	チーム人数、担当工程の品質	メンバーをまとめた	任せた作業と自分の確認範囲を書く
合意形成をリードするスキル（LINEヤフー TPM・必要）	合意を取った相手と論点	合意までの期間、決まった事項	調整力がある	誰と何を決めたかを書く
全体管理(SQCD)への責任、ステコミ報告（KPMGコンサルティング PM・職務）	報告先と審議にかけた事項	報告の頻度、承認された対応方針	上層部に報告	審議事項と結論を書く
10名以上のチームサイズ（同・歓迎）	直接まとめた人数	チーム人数	多人数を管理	直接と間接の人数を分ける

表で目立つのは、必須と歓迎で求める人数の書き方が違う点です。開発リーダー枠は5人程度を必須にし、KPMGコンサルティングは10名以上を歓迎要件に置いています。人数が少ない案件でも、必須側の要件に当たるなら書類から外す理由にはなりません。

表の左列と自分の案件を照らし合わせたら、次は実際の求人で応募条件を確かめる段階です。プロジェクトマネージャーの職種で絞り込み、必須経験の欄に自分の案件で書ける項目があるかを確認してください。

企業タイプ別の見せ方（SIer・事業会社・コンサル）

同じ案件でも、応募先の企業タイプで先頭に置く経験が変わります。前の表が要件ごとの書き方なら、この表は応募先ごとにどの案件を前に出すかの目安です。

企業タイプ	確認した募集要項の特徴	先頭に置く案件	補足する経験
SIer	管理職経験とQCDの管理が必須、公共系などの業務経験が望ましい	体制規模が大きく、QCDの結果を示せる案件	同じ業界での開発・保守経験
事業会社（社内IT）	ライフサイクル全体の管理、合意形成、SaaSの選定・導入	社内の複数部門をまとめた案件	選定の比較軸と導入後の変化
コンサル	全体管理(SQCD)への責任、ステコミ報告、業務領域の知識	経営層への報告と審議を担った案件	SCM・会計・金融システムなどの業務知識

SIerに応募する場合

SIerの要項は、扱う業界の経験を望ましい条件に書くことがあります。NTTデータ関西のPM募集では、公共系のシステム開発経験が望ましい経験でした。案件の見出しに業界と業務名を入れ、読み手が配属先の案件と結び付けられるようにします。

事業会社に応募する場合

確認した事業会社の募集では、関係者との合意形成をリードするスキルが必要な経験に挙がっていました。LINEヤフーのTPM募集は、多様な関係者の議論をファシリテートし合意形成をリードするスキルを必要な経験にしています。受託開発の経験が中心の人も、顧客企業の部門間の調整を担った案件があれば、その場面を1件目に書いてください。

コンサルに応募する場合

確認したコンサルのPM募集では、業務領域の知識が歓迎要件に入っていました。KPMGコンサルティングのグローバルPM募集が挙げていたのは、製造業の業務の流れ（SCM、会計）を説明できることです。SIerとコンサルのどちらを狙うか迷っている場合は、SIer PMとコンサルPMの違いで役割と評価の差を確かめてから書類を分けると、手戻りが減ります。コンサルの職務経歴書全体の書き方は、ITコンサルの職務経歴書の書き方で確認してください。

QCDの結果と業界経験を前に出せる人は、SIerのPM枠と相性がよい書類になります。一方、経営層への報告や業務改革の提言を最優先に書きたい人は、SIerよりコンサルや事業会社の要項と並べて検討したほうが、書いた経験がそのまま要件に当たります。

PL・隣接経験からPM職に応募するときの補強方法

PM経験が少ない人ほど、応募する枠を先に決めると書類が組み立てやすくなります。現在の経験を3つに分けると、応募できる枠と補う書き方は次のとおりです。

現在の経験	応募を考えやすい枠	足りない経験	書類で補う書き方
完全未経験（開発・管理の経験なし）	PM職への直接応募は難しい	システム開発の実務、チーム運営	まず開発やPMOの実務を積み、その案件を書く
隣接経験（PL・PMO・SE）	リーダー枠、PMO枠、PM候補の募集	QCD全体の管理、予算への権限	管理した範囲とPMの判断を支えた材料を分けて書く
経験者寄り（小規模案件のPM）	PM枠	中・大規模や複数組織の体制	体制の内訳と、関わった組織の数を書く

完全未経験の行を「難しい」とした理由は、実務経験が前提だからです。確認した要項は、いずれもプロジェクトの実務経験を求めています。job tagも、PMはシステムエンジニアなどとして構築や運用を経験した人が就くことが多いと説明しています。

隣接経験の人は、PM資格を要件にする求人にも注意してください。NTTデータ関西のPM募集は、PMPかIPAのプロジェクトマネジメント試験の合格、または「それに相当する知識」を必須にしています。資格がなくても、相当する知識を実務の記載で示せるかが分かれ目です。PMの業務範囲を全体として確かめたい場合は、プロジェクトマネージャーの仕事内容で必要なスキルを確認できます。

面接で深掘りされる項目

面接では、書類に書いた数字と判断の理由を順に聞かれると考えて準備します。書類と答えがずれると、記載そのものの信頼が下がるためです。

書類の記載	深掘りされやすい質問	答えの準備
体制【人数】名を統括	直接まとめたのは何人で、誰に何を任せたか	体制図を手元で描けるようにする
工数は計画比【数値】%で着地	計画との差はどこで生まれたか	差が出た工程と、その時の判断を説明する
段階移行への切り替えを提案	他の案と比べて、なぜその案にしたか	比べた案と判断の基準を言えるようにする
炎上案件の立て直し	原因は何で、自分の判断に誤りはなかったか	自分の判断の反省点と、次に変えた進め方を話す
PMOとして管理の仕組みを構築	最終判断は誰がしたか	自分の提言と、PMや経営層の決定を分けて話す

IPAはPMの役割に、フェーズの区切りや終了時に計画と実績を分析・評価することを含めています（IPA「プロジェクトマネージャ試験」）。KPMGコンサルティングの募集も、PMBOKの領域のうち何を重視し、どう実践しているかを説明できることを歓迎要件にしていました。振り返りの内容まで話せるように、案件ごとに1行のメモを用意しておくと答えがぶれません。

提出前に、表の左列にある記載ごとに面接での答えを書き出し、職務経歴書の数字と食い違わないかを確かめてください。

年収交渉で根拠になる実績の書き方

条件の話し合いの前提になるのは、どの枠・職位として採用されるかです。NTTデータ関西のPM募集は管理職としての採用で、配属先のプロジェクトは経歴と本人のキャリアプランを踏まえて決めるとしています。job tagも、SEから課長などのレベルに昇進した人をプロジェクトマネージャと呼ぶ会社が多いと説明しており、PMという呼び名が職位と結び付く場合があります。

リメディの見解として、書類ではPMという肩書きより、QCDを自分が管理した案件を先頭に置くほうが条件の根拠になりやすいと考えます。チーム運営が中心だった案件は、その後ろに分けて書いてください。PLの節で見た2つの募集のように、同じ会社でもリーダー枠とPM枠では必須経験が違うためです。

開発リーダー募集にも、経験によっては運用プロジェクトマネージャを任せる場合があると書かれています。枠の境目は経験の中身で動くため、面談では提示された条件とあわせて、入社後に任される役割と職位を確認してください。書類の役割より上の枠で話を進めると、面接の深掘りで食い違いが出ます。

PMの職務経歴書を相談すべきケース

自分で書き上げられる人と、相談したほうが早い人は、書類のどこで迷っているかで分かれます。

自分で進めてよいケース	相談したほうが早いケース
PM経験があり、応募先と同じ業界の案件を書ける	案件が多く、どれを先頭に置くか決められない
体制・予算・判断・結果を全案件で埋められる	PL・PMOの経験でPM枠に応募したい
応募先が1社で、要項の必須経験がはっきりしている	SIer・事業会社・コンサルを並行して受ける
炎上案件がなく、計画どおりの実績が中心	炎上案件や守秘義務の範囲で書き方に迷う

右の列に並ぶのは、どの案件を先頭に置くか、PL・PMOの経験をPM枠の要件にどこまで当てられるか、守秘義務の範囲でどこまで書くかといった個別の判断です。リメディでは、IT領域の転職を担当するエージェントが、応募先の要項に合わせた職務経歴書の組み立てから相談に応じています。担当者の経歴は、予約の前に見比べて選べます。

PMの職務経歴書でよくある質問