PM・PL（プロジェクトマネージャー・リーダー）の職務経歴書の書き方｜採用担当に伝わる記入例と無料テンプレート

PM・PL（プロジェクトマネージャー・プロジェクトリーダー）の職務経歴書で評価されるのは、関わったプロジェクトの数ではありません。「どの規模のプロジェクトを、どこまで任され、計画どおりに進めたか」が伝わるかどうかです。案件名と期間を並べただけでは、採用担当は「自社のプロジェクトを任せられるか」を判断できません。

PM・PLの仕事は、自分で手を動かす量よりも、計画を立て、人を動かし、問題を先回りして片づける部分が中心です。そのため、成果が見えにくいと感じる人も多いでしょう。しかし、規模・役割・QCD（品質・コスト・納期）の結果の3点をそろえて書けば、マネジメントの実力は十分に伝わります。

この記事では、SIerでPLからPMになった15年半の経験者の記入例をもとに、項目ごとの書き方と、なぜそう書くと評価されるのかを解説します。SIerのPM、事業会社・Web系のPdM寄り、PMO、PLからPMへのステップアップという立場別の書き分け方と、AI活用の書き方も紹介します。開発者としての技術の書き方は、SE・開発職の記事で扱っています。

PM・PLの職務経歴書の記入例

まずは完成イメージです。金融・保険業界向けのSIerで、SE・PLを経て2020年からPMを務めている人を想定しています。画像をタップすると拡大できます。

この記入例と同じ形式のテンプレートを無料で用意しています。Word・Excel・PDFの3形式で、それぞれ空欄テンプレートと記入見本の2点セットです。

データで見る：PM・PLの職務経歴書で「結果」と「進め方」が問われる理由

書き方の前に、システム開発プロジェクトの実態と、PMに求められる仕事・スキルをデータで確認しておきましょう。何を強調して書くべきかが見えてきます。

大規模プロジェクトの約半数で、工期が「予定より悪化」

日本情報システム・ユーザー協会（JUAS）の「企業IT動向調査2026」分析レポートでは、ユーザー企業に開発プロジェクトの結果を聞いています。500人月以上のプロジェクトでは、工期が「予定より悪化」した割合が47.8%にのぼりました。予算は42.2%、品質は29.6%です。

出典：「企業IT動向調査2026」分析レポート②（日本情報システム・ユーザー協会）（2026年5月20日・図1）

100〜500人月でも、工期の悪化は38.8%でした。一方、「予定通り」と答えた割合は、規模や項目を問わず約2割にとどまります。規模が大きいほど、工期と予算は計画どおりに進みにくいことがわかります。

この調査はシステムを発注・利用するユーザー企業の回答で、SIerの立場から見た数字ではありません。それでも、計画どおりに終えること自体が簡単ではないという実態は、受託側にも共通すると考えられます。だからこそ、採用担当は「予定どおり終えた」ことと、「崩れかけたときにどう立て直したか」の両方に注目します。

PMの仕事で重要度が最も高いのは「進捗とコストの管理」

厚生労働省の職業情報提供サイト（job tag）では、「プロジェクトマネージャ（IT）」のタスクごとに、就業者が答えた重要度（1〜5点）を公開しています。最も高いのは「進捗状況やコストの管理」で4.2点でした。要件定義と実行計画の作成が4.1点で続きます。

出典：職業情報提供サイト（job tag）「プロジェクトマネージャ（IT）」（厚生労働省）（タスク・2023年度委託調査に基づく）

上位には、計画を立てる・資源を集める・進捗とコストを管理する、というマネジメントの中核が並びます。SE・プログラマーの指導（3.1点）も多くの人が担っていますが、重要度は相対的に低めです。

つまり、PMの職務経歴書の中心は、計画・予算・進捗の管理で何を守ったかです。担当した工程や使った技術を詳しく書くより、どんな計画を立て、どの数字を管理し、どう着地させたかを書くほうが、仕事の核が伝わります。

求められるスキルの上位は「傾聴力」と「他者との調整」

同じjob tagでは、職業ごとに必要なスキルの水準も比べられます。プロジェクトマネージャ（IT）で最も高いのは「傾聴力」（5.4）と「他者との調整」（5.1）でした。時間管理・説明力・交渉も5.0で続きます。

出典：職業情報提供サイト（job tag）「プロジェクトマネージャ（IT）」（厚生労働省）（スキル）

一方、プログラミングは3.7でした。PMには技術の知識も必要ですが、より高い水準で求められるのは、人の話を聞き、利害を調整する力です。顧客との折衝、協力会社との調整、メンバーとの対話が、PMの仕事の大きな部分を占めていることがうかがえます。

採用担当がPM・PLの職務経歴書で見ている3つのこと

ここまでのデータと、PM・PLの採用の現場でよく言われる傾向を踏まえると、採用担当は書類を読みながら次の3つを確認しています。どの項目を書くときも、このどれかが伝わるかを意識しましょう。

1. 任せられる規模と役割予算・期間・人数・ステークホルダーの数と、PLとしてチームを率いたのか、PMとして全体に責任を持ったのか。自社のプロジェクトと同じ規模を任せられるかを判断します。
2. QCDの結果と、そこに至る打ち手納期・予算・品質を計画と比べてどう着地させたか。遅延や問題が起きたときに、何を判断し、どう立て直したかも見られます。
3. 人を動かす力顧客との折衝、協力会社を含むチームの統率、メンバーの育成。成果を一人で出したのではなく、チームで出したことが伝わるかどうかです。

項目別の書き方：OK例とNG例の違い

ここからは項目ごとに、NG例とOK例を並べて解説します。同じ経験でも、書き方ひとつで「案件に参加した人」にも「プロジェクトを任せられる人」にも見えます。

職務要約：任された最大の規模と、代表的な結果を3〜5行で

職務要約は、採用担当が最初に読む部分です。業界・PL／PMの期間・最大規模・代表的な結果を入れて、どのクラスのプロジェクトを任せられる人かを短く伝えます。

職務経歴：プロジェクトごとに「規模・役割・成果」をセットで書く

職務経歴は、PM・PLの職務経歴書でいちばん重要な項目です。プロジェクトごとに区切り、規模・役割・成果の3点をそろえて書くと、マネジメントの実力が格段に伝わりやすくなります。下の画像の3つのポイントを押さえましょう。

規模は予算／期間／人数／開発手法を1行にまとめると読みやすくなります。人数には、協力会社のメンバーを含むかどうかも添えましょう。PLの場合は、全体の人数と自分が担当したチームの人数を分けて書きます。

特に差がつくのが、成果の書き方です。

活かせる経験・知識・スキル：「どんなプロジェクトを任せられるか」を3つに

経験したことを全部並べるのではなく、応募先のプロジェクトで再現できる経験を3つ程度に絞って箇条書きにします。規模や手法を添えると、採用担当が自社の案件に当てはめやすくなります。

マネジメント手法・ツール：PCスキル欄を「管理の道具」に置き換える

PM・PLの場合、PCスキル欄を「マネジメント手法・ツール」として、開発手法・管理手法・ツールに分けて整理すると読みやすくなります。開発の経験は職務経歴で触れていれば、ここでは1行にまとめるか省いてもかまいません。マネジメントの道具を中心に書きます。

資格は、IPAの「プロジェクトマネージャ試験」やPMI（米国の団体）の「PMP」が代表的です。必須とする求人は多くありませんが、体系的な知識の裏付けになります。取得年月と正式名称で書きましょう。

自己PR：強みは2つまで。プロジェクトの場面で示す

自己PRは「強み → それを発揮したプロジェクトの場面 → 結果の数字」の順に書くと説得力が出ます。PM・PLでは、問題を早くつかんで手を打つ力と、チームを育てる力の2つが定番です。

立場・プロジェクト別：職務経歴書の書き分け方

同じPM・PLでも、立場によって採用担当が見るポイントと、強調すべき経験は大きく変わります。まずは全体像を表で確認し、そのあと自分や応募先に近い立場の解説を読んでください。

立場	採用担当が見るポイント	強調したい経験・数字
SIerのPM	受託案件を契約どおりに完遂し、利益を守った経験	予算・人数・期間、原価率、顧客折衝の相手
事業会社・Web系（PdM寄り）	事業の目標に向けて、作るものの優先順位を決めた経験	リリースの頻度、KPIの変化、関係部署の数
PMO	複数のプロジェクトを横断して、管理の仕組みを整えた経験	支援した案件数、標準化した手順、遅延の減少
PLからPMへのステップアップ	チームを率いた経験と、PMの仕事をどこまで担ったか	担当チームの人数、PMの補佐として担った範囲

SIerのPM

SIerのPMは、顧客と契約した範囲・金額・納期でシステムを完成させる責任を負います。採用担当が見るのは、契約の枠の中でQCDを守り、会社の利益も確保できたかです。

事業会社・Web系のPM（PdM寄り）

事業会社やWeb系企業のPMは、自社のサービスやシステムをつくる立場です。PdM（プロダクトマネージャー）に近い役割を求められることも多く、「何を、どの順番でつくるか」を事業の目標から決めた経験が評価されます。

PMO

PMO（プロジェクトマネジメントオフィス）は、PMを支え、複数のプロジェクトの管理を標準化する役割です。自分が責任者ではないため成果を書きにくいと感じがちですが、仕組みを整えて、プロジェクト全体の状態をどう良くしたかを書けば十分に評価されます。

PLからPMへのステップアップ

PLからPMを目指す場合、採用担当は「PMの仕事をどこまで経験しているか」を見ています。PMの肩書きがなくても、見積もりや顧客折衝の一部を担っていれば、それは立派な準備の経験です。

あわせて読みたい：Webディレクターの職務経歴書の書き方

2026年のPM・PLとAI：職務経歴書にどう書くか

最初にお伝えしたいのは、AIの使い方や、AI経験を求める度合いは応募先によって大きく違うということです。IPAの「DX動向2026」では、AIを導入している企業は従業員1,001人以上で8割近くにのぼる一方、101人以下では16.6%でした。金融や官公庁の案件では、顧客との契約でAIの利用が制限されていることもあります。

まずは求人票に「生成AI」「AIツール」「AI導入」などの言葉があるかを確認しましょう。記載があれば、AIの活用やAI導入プロジェクトの経験を具体的に書く価値があります。記載がなければ、マネジメント手法・ツール欄に1行添える程度で十分です。

PM・PLの仕事で現実的なAIの使い方

PM・PLの仕事は、会議と文書が多いのが特徴です。総務省の情報通信白書でも、企業の生成AIの利用で多い業務は「議事録・メール作成補助」（約7割）でした。2026年時点で現実的な使い方には、次のようなものがあります。

使い方	具体例	職務経歴書で示したいこと
議事録・報告のたたき台	会議の要点と決定事項の整理、週次進捗報告の下書き	削減した時間と、決定事項は自分で確認したこと
計画づくりの補助	WBSの作業の洗い出し、見積もりの前提条件の整理	たたき台を、チームの知見でどう直したか
リスクの洗い出し	過去の課題一覧や議事録から、似たリスクを挙げさせる	見落としを減らした例と、最終判断は人がしたこと
チームのAI活用の管理	開発メンバーのAIコーディング支援ツールの導入とルールづくり	品質や生産性をどの指標で確かめたか
AI導入プロジェクトのPM	社内のAIチャットボットやAI-OCRの導入	精度の評価方法、利用部署の広がり、業務の変化

上の3つは、多くのPM・PLが日常的に使える方法です。会議の記録や報告に使う時間が減れば、そのぶん顧客やメンバーとの対話に時間を回せます。AIで浮いた時間を、PMにしかできない仕事にどう使ったかまで書けると、マネジメントの視点が伝わります。

4つ目と5つ目は、マネジメントそのものにAIが関わる場面です。開発チームにAIツールを入れると、コードを書く速さは上がっても、レビューの負荷が増えたり、品質のばらつきが出たりすることがあります。速さと品質の両方を測り、ルールを整えた経験は、これからのPMにとって大きな強みになると考えられます。AI導入プロジェクトでは、通常のシステム開発と違い、精度が事前に確定しません。評価の基準をどう決め、顧客とどう合意したかを書きましょう。

職務経歴書での書き方：業務・使い方・変化をセットで

AIの経験は「AIを活用した」と書くだけでは伝わりません。どの業務で・どう使い・何が変わったかの3つをセットで書きます。

AI活用を書くときの注意点

• 顧客の機密情報や個人情報をAIに入力していないことがわかるように書く。受託開発では、顧客との契約で情報の扱いが決まっています。「社内承認済みの環境で」「顧客名は伏せて」と一言添えましょう。
• 会社や顧客のルールに従って使ったことを前提に書く。ルールが決まる前に、個人の判断で案件の資料をAIに入れた経験は書かないほうが無難です。
• AIの出力を自分で確認したことを書く。議事録の決定事項や見積もりの数字をそのまま使った、と読める書き方は避けます。
• 盛らない。「AIでプロジェクト管理を自動化」と書いて実際は一部の作業だけだった場合、面接で具体的な手順を聞かれて答えに詰まります。

AIを使っていない・使えない職場だった人は

AIを使っていない、または顧客との契約で使えない案件が中心だった人も、それだけで評価が下がると考える必要はありません。PMの評価の中心は、今も規模・役割・QCDの結果です。

代わりに、報告の書式を統一して作成時間を減らした経験や、課題管理のルールを整えて対応漏れを防いだ経験を書きましょう。どれも、AIを業務に組み込むときに必要になる「業務の整理」の経験です。セキュリティ要件の厳しい案件で情報管理を徹底した経験も、AIを安全に使う前提として評価されます。

実績の数字が書けないときの対処法

「守秘義務で金額を出せない」「プロジェクトがうまくいかなかった」という人も、書き方を工夫すれば十分に評価されます。

あわせて読みたい：アピールできる実績がない人の職務経歴書の書き方

提出前のチェックリスト

書き終えたら、提出前に次の項目を確認しましょう。

• 職務要約に、業界・PL／PMの期間・最大規模・代表的な結果が入っている
• プロジェクトごとに「規模（予算・期間・人数・手法）・役割・成果」が書かれている
• 成果を、納期・予算・品質の計画と比べた結果で書いている
• PLとPMの経験、自分が責任を持った範囲と補佐した範囲を書き分けている
• AIを使った業務は「業務・使い方・変化」で書き、顧客情報の扱いにも触れている
• 顧客名・正確な金額など、守秘義務に触れる情報を書いていない
• A4で1〜2枚（多くても3枚以内）に収まり、誤字脱字がない

よくある質問

担当したプロジェクトが多すぎて書ききれません。どう選べばいいですか？

応募先の案件に近いものを中心に、直近の3件程度を詳しく書きます。古い案件や小さな案件は「その他、〇〇業界向けの開発案件を約10件担当」のように1行にまとめましょう。規模の大きい案件と、立て直しなど判断力が伝わる案件を優先すると効果的です。

PMの経験が1件しかありません。PMとして応募できますか？

1件でも、規模・役割・結果を具体的に書けば十分なアピールになります。PLとしての経験や、PMの補佐として担った見積もり・顧客折衝もあわせて書き、PMの仕事をどこまで経験しているかを示しましょう。

炎上したプロジェクトのことは書かないほうがいいですか？

途中から立て直しを任された場合は、むしろ積極的に書きたい経験です。自分が最初から担当して遅延させた場合も、原因の分析と再発防止の取り組みまで書ければ評価につながります。ただし、前任者や顧客の責任を強調する書き方は避けましょう。

職務経歴書を生成AIで作ってもいいですか？

構成の相談や文章の推敲に使うのは問題ありません。ただし、規模・年月・成果の数字は必ず自分で確認してください。生成AIはもっともらしい表現で実績を盛ることがあります。顧客名や案件の詳細など、守秘義務のある情報はAIにも入力しないようにしましょう。

実績を少し大きめに書いても大丈夫ですか？

事実と異なる内容は書いてはいけません。PMの面接では、予算の管理方法や遅延時の判断を細かく聞かれることがよくあります。チームの成果を書くときは「チームで」と書き、自分の役割を正確に添えましょう。