PM(プロジェクトマネージャー)のスキルシートの書き方|面談で評価される実績の見せ方
公開 2026-10-29 監修:株式会社エージェントベスト
PM(プロジェクトマネージャー)のスキルシートは、プロジェクトの説明より「どの立場で、何に責任を持ち、何を決めたか」を先に読ませるのが基本です。1件ごとに「立場・体制・局面・管理した対象・主な判断・結果」をそろえて書くと、読み手は任せられる範囲をすぐに判断できます。
エンジニアのシートのように使った技術を並べても、PMの力量は伝わりません。この記事では、PMのシートに固有の書き方を、例を使って紹介します。全体の構成やプロジェクト欄の基本の型はフリーランスのスキルシートの書き方で解説しているので、あわせてご覧ください。
PMのシートはどう読まれるか
PMの案件のスキルシートを読むのは、発注元のプロジェクトの責任者や部門の管理職であることが多く、読み手自身がPMの経験を持っています。そのため、「PMを担当」「進捗管理を実施」といった言葉だけでは評価されにくく、次のような点を行間から読み取ろうとします。
- 発注側と受託側のどちらの立場で、誰に対して責任を負っていたか
- どのくらいの体制を、直接か間接かで動かしていたか
- どの局面(立ち上げ、実行中、立て直し、移行)を担ったか
- 問題が起きたときに、自分で決めたのか、上に上げたのか
PMに求められるスキルの全体像はPMの案件で求められるスキルで整理しています。ここでは、それをシートの上でどう表すかに絞ります。
要約欄は「PMとしての型」を3行で
要約欄は、シートの中で最も読まれる部分です。PMの場合は、経歴を年代順にまとめるより、自分がどんな型のPMかを先に書きます。型は、立場、得意な局面、扱ってきた規模、業界や領域の4つで表すと伝わりやすくなります。
例:
- 受託側のPMとして、業務システムの刷新を要件定義から移行まで担当
- 協力会社を含む数十名規模の体制で、複数のチームのリーダーを束ねた経験あり
- 遅延したプロジェクトに途中から入り、計画を引き直した経験あり。製造業の生産管理の業務に詳しい
これは書き方を示すための例です。実際には、応募する案件で求められる局面や規模に近い行を一番上に置き、案件ごとに並べ替えます。
プロジェクト欄に入れる項目
PMのプロジェクト欄は、基本の型にPM固有の項目を足して書きます。
| 項目 | 書き方のポイント |
|---|---|
| 期間 | 年月で書く。プロジェクトの全期間と、自分が関わった期間が違う場合は分けて書く |
| 案件の概要 | 業種と目的で書く(例:小売業向けの受発注システムの刷新)。社名やプロジェクトの名称は書かない |
| 立場 | 発注側か受託側か、受託側なら元請けか協力会社か。肩書きと実際の役割 |
| 体制 | 全体の人数、関わった会社の数、自分の直下のリーダーやメンバーの人数 |
| 局面 | 立ち上げ、要件定義、開発中、立て直し、移行・稼働後など、参画した時点と抜けた時点 |
| 進め方 | ウォーターフォール、アジャイル、両者の組み合わせなど |
| 管理した対象 | 進捗、課題、品質、要員、協力会社、予算、変更のうち、自分が責任を持った範囲 |
| 主な判断 | 自分が決めた、または決定を主導したことを1〜3行で |
| 結果 | 伏せられる範囲での結果(リリースの時期、稼働後の状況、関係者の評価など) |
記入例
期間:(例)約1年半。うち自分の参画は要件定義の後半から稼働後3か月まで
案件の概要:(例)製造業向け 生産管理システムの再構築
立場:受託側の元請け。肩書きはPM、実際の役割も同じ
体制:協力会社2社を含む約20名。直下にチームのリーダー3名
局面:要件定義の後半〜移行・稼働後の安定化
進め方:ウォーターフォール。一部の画面は試作を重ねて仕様を固めた
管理した対象:進捗、課題、品質、要員、協力会社との調整。予算は上長と分担
主な判断:結合テストの遅れを受け、稼働の範囲を2段階に分ける案を発注元に示し、合意を得た
結果:第1段階を予定どおり稼働。第2段階は合意した新しい日程で稼働
これは項目の埋め方を示すための架空の例です。実際の経験に置き換えて書いてください。
「主な判断」の書き方
PMのシートで差が出るのが「主な判断」の欄です。読み手は、この欄から「この人に任せたら、問題が起きたときにどう動くか」を想像します。
書くときは、状況、取った手、結果の3つを1文ずつで表すと、短くても伝わります。
| 書き方 | 例 |
|---|---|
| 伝わりにくい | 進捗管理と課題管理を実施し、プロジェクトを成功に導いた |
| 伝わりやすい | (例)要件の追加が続いたため、変更の受付と判断の会議を週1回に決め、追加の要件を優先度で振り分けた。当初の範囲で稼働した |
「成功に導いた」「円滑に推進した」といった言葉は、どのPMのシートにも書かれているため、読み手の目に留まりません。自分が決めたことを、名詞と動詞で具体的に書くほうが伝わります。
判断の例が思い出せないときは、PMがフリーランスになるにはで紹介している「判断の場面」の表を使って棚卸しをしてみてください。
肩書きと実際の役割がずれるとき
PMの経歴では、肩書きと実際の役割が一致しないことがよくあります。その場合は、肩書きと役割を分けて書くのが誠実です。
- 肩書きは「リーダー」だったが、計画づくりと発注元への報告、協力会社との調整を自分が担っていた場合は、その範囲を役割として書けば、PMの経験として伝わります
- 肩書きは「PM」だったが、判断は上長が行い、自分は情報をまとめて報告していた場合は、PMOに近い役割として書くほうが、面談での食い違いを防げます
- 発注側の担当者として、受託側のPMと向き合っていた場合は、発注側のプロジェクトの責任者として何を決めていたかを書きます
PMOとしての書き方はPMOのスキルシートの書き方で解説しています。PMとPMOの両方の案件を探す場合は、シートを2種類用意し、要約欄と「主な判断」の欄を書き分けると、それぞれの読み手に合わせやすくなります。
数字の扱い
PMのシートでは、規模を示す数字が任せられる範囲の目安になります。ただし、書いてよい数字と伏せるべき数字があります。
- 書きやすい数字:期間、全体の人数、関わった会社の数、直下の人数、拠点の数
- 伏せることが多い数字:予算や契約の金額、売上や利益への影響、取引先の固有の数値
予算の規模を伝えたいときは、金額を書かずに体制の大きさで示す、幅で表す、といった方法があります。どこまで書いてよいかの考え方は、スキルシートに書いてよいこと・いけないことで詳しく解説しています。
成果の数字は、自分で測れた範囲のものだけにします。「遅延を解消」と書くなら、どの時点の遅れを、いつまでに戻したかを面談で説明できるようにしておきましょう。説明できない数字は、かえって信頼を下げます。
進め方や関わり方が特殊なときの書き方
アジャイルの体制
スクラムなどの体制では、PMという役割が置かれないこともあります。その場合は、プロダクトオーナーの支援、複数のチームの調整、発注元との予算や範囲の合意など、自分が担った責任を具体的に書きます。役割の名前だけでなく、何を決める権限を持っていたかを添えると伝わります。
複数のプロジェクトを並行していた
同じ期間に複数のプロジェクトを担当していた場合は、それぞれを別の行に分け、関わり方の濃さ(専任か、兼務か)を書いておきます。並行していたことが分からないと、期間が重なっていて不自然に見えることがあります。
途中から参画した、途中で抜けた
立て直しのために途中から参画した、移行の前に契約が終わった、といった経歴は、参画した時点と抜けた時点を書いておくと、成果の範囲が正しく伝わります。途中で抜けた理由が体制の変更や予定どおりの終了なら、一言添えておくと面談での説明が楽になります。
資格欄の書き方
資格は、知識の裏付けとして書いておくと読み手の安心材料になります。PMの案件でよく見られるのは、IPA(情報処理推進機構)のプロジェクトマネージャ試験と、PMIが認定するPMPです。
プロジェクトマネージャ試験は、情報処理技術者試験の高度試験の一つです。IPAによると、現行の制度は2026年度の実施で終わり、2027年度から新しい制度に移る予定です(2026年10月時点)。シートには、合格した試験の名前と合格した年を、そのまま書いておけば問題ありません。
PMPは、資格を取ってから3年ごとに更新が必要で、その間に所定の単位(PDU)を取得して報告する決まりです。シートには取得した年月を書き、更新して有効な状態かを面談で聞かれたら答えられるようにしておきましょう。
資格の位置づけや、実務とあわせた示し方はPMの案件で求められるスキルで解説しています。
提出前に見直したいこと
- 要約欄の1行目に、応募する案件の局面や規模に近い経験が来ているか
- すべてのプロジェクトに「立場」と「体制」が入っているか
- 「主な判断」が、状況・取った手・結果の形で書けているか
- 肩書きと実際の役割がずれる経歴は、分けて書いているか
- 期間の重なりや途中の参画・離脱が、読み手に分かる形になっているか
- 通称や部署の名前など、発注元が特定できる情報が入っていないか
よくある質問
PMの経験が1件しかありませんが、どう書けばよいですか?
1件でも、立場・体制・局面・主な判断をそろえて書けば、任せられる範囲は伝わります。そのうえで、リーダーやサブPMとして計画や調整を担った経歴も、役割を正確に書いて並べると、経験の厚みを補えます。
うまくいかなかったプロジェクトも書くべきですか?
関わった期間と役割は、事実のとおり書きます。結果が思わしくなかった場合でも、自分が取った手と、その後の学びを面談で説明できれば、評価につながることがあります。結果を実際よりよく書くことはしないでください。
体制の人数には、協力会社のメンバーも含めてよいですか?
含めてかまいません。ただし、自分が直接指示を出していた人数と、全体の人数を分けて書くと、読み手が実際の管理の範囲を判断しやすくなります。
参考にした公的情報・資料
記事の内容は公開日時点の情報にもとづきます。制度や税率は変わることがあるため、手続きの前に必ず各機関の最新情報をご確認ください。