エンジニアキャリアの「キッカケ」が見つかる情報メディア
produced by
エンジニアキャリアの「キッカケ」が見つかる情報メディア
プロジェクトマネージャーとして転職活動を始めたものの、「職務経歴書に何を書くべきか分からない」と感じていないでしょうか。
採用担当者は単なる業務履歴ではなく、プロジェクトの規模や動かし方、その成果を職務経歴書から読み取ろうとしています。エンジニアとしての開発経験よりも、マネジメントの質と実績が評価軸になるため、書き方ひとつで書類通過率が大きく変わるでしょう。
この記事では、以下の内容を解説します。
PMとして転職活動中の方、または近々転職を検討している方に、書類選考を突破するための具体的な指針をお伝えしています。ぜひ参考にしてください。
職務経歴書のクオリティを上げるには、プロに相談するのもおすすめです。キッカケエージェントに登録すると、IT領域に詳しい転職エージェントが書類完成から面接対策までサポートします。
目次
職務要約は、採用担当者が最初に目を通すセクションです。PM歴・得意な業界・最大プロジェクト規模を3〜4行で端的にまとめ、どんなPMかが一目で伝わるように書きます。
| 【書き方の例】 |
| 新卒でSIerに入社し、Javaを用いた業務系システムの開発に3年間従事しました。その後、プロジェクトリーダーを2年経験したうえでプロジェクトマネージャーに昇格。現在は金融・流通業界向けシステム開発プロジェクトのPMとして、要件定義から納品まで全工程を統括しています。最大規模は20名・予算1.5億円のプロジェクトで、納期遵守率100％・予算達成率98％を維持しています。 |
担当プロジェクトは新しいものから順に記載します。規模感が一覧で把握できるよう表でまとめたうえで、主要プロジェクトの詳細を展開するのが読みやすい構成です。
記載例は下記をご覧ください。
株式会社〇〇システムズ（20XX年4月〜現在）
事業内容：金融・流通系システム開発 従業員数：200名
| 期間 | プロジェクト概要 | 規模 | 役割 |
| 20XX年4月〜20XX年3月 | 地方銀行向け融資審査システム刷新 | 20名・予算1.5億円 | PM（全体統括） |
| 20XX年4月〜20XX年9月 | 大手流通EC基盤構築 | 12名・予算8,000万円 | PM（進捗・品質管理） |
| 20XX年10月〜20XX年3月 | 社内業務管理システム内製化 | 6名・予算1,500万円 | スクラムマスター兼PM |
【プロジェクト詳細：地方銀行向け融資審査システム刷新】
スキル欄はマネジメント系と技術系に分けて整理します。採用担当者がひと目でスキルの全体像を把握できるよう、表形式でまとめるのが効果的です。
PMPやプロジェクトマネージャー試験などの資格は、マネジメントスキルの客観的な証明になります。取得済みであれば必ず記載しましょう。
| 区分 | 内容 |
| マネジメント | 進捗管理、工数管理、予算管理、品質管理、リスク管理、顧客折衝、WBS作成 |
| 開発手法 | ウォーターフォール、アジャイル（スクラム） |
| ツール | MS Project、Redmine、Backlog、Jira、Slack、GitHub |
| 業界知識 | 金融（銀行・融資）、流通・EC |
| 資格 | PMP（Project Management Professional）、プロジェクトマネージャー試験（IPA） |
| 言語 | Java（実務レベル）、SQL（使用経験あり） |
自己PR欄では、PMとしての強みの軸を冒頭で宣言し、具体的なエピソードと数値で裏づけます。職務経歴欄に記載した成果と矛盾しない内容にすることが大切です。
| 【書き方の例】 |
| 私の強みは、課題を早期に可視化し、チーム全体で解決に向かう仕組みを作ることです。 大規模プロジェクトでは、課題の発見が遅れることで手戻りが発生し、納期・予算の両面に影響が出やすくなります。そのため、週次の課題管理ミーティングに加え、Redmineを活用した課題の一元管理と進捗の見える化を徹底しました。結果として、重大な手戻りをゼロに抑えながら、担当した3プロジェクトすべてで納期内リリースを達成しています。 また、顧客との折衝経験が豊富で、要件のあいまいさを早期に解消することを意識しています。要件定義フェーズで認識齟齬を防ぐため、議事録の即日展開と確認事項の明文化をルール化し、手戻りの削減に貢献してきました。新しい環境でも、この課題解決のアプローチを再現できると考えています。 |
採用担当者がPMの職務経歴書を見るとき、最初に確認するのはプロジェクトの規模感です。チーム人数・予算・期間の3点を必ず数字で記載してください。大規模プロジェクトを経験したという記述だけでは、担当者は経験値を判断できません。
記載すべき規模感の情報は、以下の3点です。
規模が大きいプロジェクトは積極的に前面に出しましょう。一方で、規模が小さい案件しかない場合でも、自分が担った役割の深さで補えます。
PMといっても、要件定義から納品まで全工程を担う場合もあれば、特定フェーズに集中する場合もあります。採用担当者は、どの工程を、どんな立場で経験したかを職務経歴書から読み取ろうとしています。
担当フェーズを明示したうえで、そのなかで自分が果たした役割を具体的に記載しましょう。
| 担当フェーズの例 | 役割の記載例 |
| 要件定義〜基本設計 | 顧客ヒアリング、要件の整理・文書化、スコープ管理 |
| 開発〜テスト | WBS作成、進捗管理、課題管理、品質レビュー |
| リリース〜運用移行 | 本番リリース計画の策定、ベンダーコントロール、運用引き継ぎ |
上流工程（要件定義・基本設計）へ関与した経験は、転職市場で高く評価されます。該当する経験があれば、職務経歴書のなかで明確に示しましょう。
エンジニア出身のPMに多い失敗は、職務経歴書に開発者としての経験を書きすぎてしまうことでしょう。採用担当者が見たいのは、プロジェクトをどう動かしたかというマネジメントの実績です。
同じ経験でも、エンジニア視点ではなくPM視点で言語化することが、書類通過率を左右します。
| エンジニア視点（NG） | PM視点（OK） |
| Javaで決済モジュールを実装した | 決済機能の開発タスクを分解し、3名のメンバーに割り振って進捗を管理した |
| バグを修正してリリースに間に合わせた | 品質課題を早期検知する仕組みを導入し、リリース直前の手戻りをゼロにした |
| 顧客に仕様を確認した | 要件の認識齟齬を防ぐため、確認事項を毎回文書化して顧客と合意を取った |
職務要約は、採用担当者が職務経歴書を開いて最初に読む箇所です。3〜4行でどんなPMかが伝わらなければ、その後の詳細を丁寧に読んでもらえない場合があります。冒頭の一文でPM歴・得意な業種・最大プロジェクト規模を記載し、読み手の興味を引くことが大切です。以下の要素を盛り込むことを意識してください。
| 要素 | 書き方の例 |
| PM経験年数 | PMとして5年、うちPL経験を含めると8年 |
| 得意な業種・領域 | 金融系システム開発、製造業向けERP導入 |
| プロジェクトの最大規模 | 20人月・予算1.5億円 |
| 代表的な成果 | 納期遵守率100％を5プロジェクト連続で達成 |
数字を盛り込むことで、採用担当者は経験の重さを客観的に判断できます。「大規模プロジェクトを複数経験」のような抽象的な表現は避け、具体的な数字に置き換えましょう。
職務要約でよくある失敗が、経験してきたことをすべて詰め込もうとすることです。要約が長くなるほど、採用担当者が応募者の強みを把握しにくくなります。職務要約では、自分がもっとも評価してほしい強みを1〜2つに絞り、それが伝わる構成にしましょう。
強みの軸の選び方は、以下を参考にしてください。
たとえば「リスクの早期検知と顧客との合意形成を強みとし、担当した全プロジェクトで納期・予算を守っています」と記載します。そうすることで、リスク管理と顧客折衝を強みとしてアピール可能です。
職務要約は、応募先ごとにカスタマイズすることが書類通過率を上げるうえで効果的です。同じ経験でも、応募先が何を求めているかによって、前面に出すべきポイントは変わります。
| 応募先の特徴 | 職務要約で強調すべきポイント |
| 大手SIer・上流工程重視 | 要件定義・顧客折衝の経験、ステークホルダー管理の実績 |
| 自社開発企業・スピード重視 | アジャイル・スクラムの経験、短期リリースの実績 |
| コンサルファーム | 課題定義力、提案経験、業務知識の深さ |
| 外資系・グローバル企業 | 英語でのコミュニケーション経験、PMP保有の有無 |
職務要約を書き終えたら、応募先の採用担当者の視点で、求めるPM像に重なるか見直してみましょう。
なお、転職エージェントを活用すると、応募先ごとに書類のカスタマイズをエージェントが担当してくれます。企業ごとに何を強調すべきかをエージェントが判断し、書類に反映してくれるため、自分で書き直す手間がかかりません。複数社に並行して応募する場合でも、書類作成の負担を大きく減らせます。
プロジェクト詳細の記載で評価を分けるのは、何をしたかだけでなく、なぜそれをしたかまで書けているかどうかです。採用担当者は、応募者がどんな課題に直面し、どう対処し、どんな結果を出したかを職務経歴書から読み取ろうとしています。
次のように「課題」「打ち手」「成果」の3点セットで書くと、マネジメントの質が伝わりやすくなります。
| 項目 | 記載内容の例 |
| 課題 | 仕様変更が頻発し、開発工数が当初見積もりの1.3倍に膨らむ兆候があった |
| 打ち手 | 週次の工数レビューを導入し、変更影響をその都度スコープに反映するフローを整備した |
| 成果 | 最終的な工数超過を5％以内に抑え、予算内でのリリースを達成した |
課題をプロジェクト構造上の問題として捉え、PMとして仕組みで解決したことを示せると、より説得力が増します。
職務経歴書に数字がないと、採用担当者は経験の重さを判断できません。成果は可能なかぎり数値で表現することが大切です。抽象的な表現ではなく、具体的な数字に置き換えましょう。
数値化しやすい成果の例は以下のとおりです。
| 成果 | 書き方の例 |
| 納期遵守率・予算達成率 | 納期遵守率100％、予算達成率98％ |
| 工数・コストの削減率 | 開発工数を前プロジェクト比で20％削減 |
| チーム規模・管理人数 | 20名・5社のベンダーをコントロールした |
| 売上・契約への貢献 | 追加契約を獲得し、年間売上へ600万円貢献 |
一方で、数値化が難しい成果もあります。たとえばリスク管理の工夫や、チームの雰囲気改善といった取り組みは、具体的なエピソードで補いましょう。「重大インシデントをゼロに抑えた」「メンバーの離脱なくプロジェクトを完走した」といった表現でも、実力は十分に伝わります。
PMキャリアが長くなると、記載すべきプロジェクトが増え、どこまで書くべきか迷いやすくなります。職務経歴書はA4サイズ2〜3枚が目安です。すべてのプロジェクトを均等に書こうとすると、重要な案件の記述が薄くなり、かえって伝わりにくくなります。
プロジェクトの優先順位は、以下の基準で判断しましょう。
直近3〜5年のプロジェクトをメインに据え、古い案件は概要のみの記載にとどめると、読みやすい構成になります。
スキル欄は、マネジメント系と技術系を混在させて書くと、採用担当者が全体像を把握しにくくなります。区分を分けて整理することで、PMとしての強みと技術的な素養の両方が伝わる構成にできるでしょう。
PMの職務経歴書で記載すべきスキルの区分は、以下のとおりです。
| スキルの区分 | 具体例 |
| マネジメント内容 | 進捗管理、工数管理、予算管理、品質管理、リスク管理、顧客折衝、WBS作成 |
| 開発手法 | ウォーターフォール、アジャイル（スクラム）、DevOpsなど |
| 使用ツール | MS Project、Backlog、Jira、Redmine、Slack、GitHubなど |
| 業界知識 | 金融、製造、流通、医療など、携わった業界を記載する |
| 保有資格 | PMP、プロジェクトマネージャー試験（IPA）など |
PMの転職では、マネジメントスキルが評価の中心になります。そのため、スキル欄の先頭にマネジメント系の項目を置き、技術スタックはその後に続けるのが自然な順序です。
スキル欄に記載した技術やツールについて、習熟度を明記することで採用担当者の判断がしやすくなります。「Java」「Python」「SQL」と羅列するだけでは、習熟度が分からず、面接で確認が必要になる場合があります。
習熟度の区分は、以下のように統一して記載しましょう。
| 区分 | 基準 | 記載例 |
| 実務レベル | 業務で継続的に使用し、自己解決できる | Java（実務レベル） |
| 使用経験あり | 業務で使用したことがあるが、補助的な範囲にとどまる | Python（使用経験あり） |
ただし、PMとしての転職では技術の習熟度よりも、マネジメントスキルのほうが評価の比重が高くなります。技術スタックの記載が長くなりすぎると、PMとしてのアピールが薄まる場合があるため、簡潔にまとめることを意識しましょう。
スキル欄の並び順は、応募先が重視する要素を上位に置くことで、書類の読まれ方が変わります。同じスキルセットでも、並び順ひとつで「このPMは自社に合っている」という印象を与えやすくなるでしょう。
応募先ごとの並び順の考え方は以下のとおりです。
| 応募先の特徴 | 上位に置くべきスキル |
| 上流工程・コンサル重視 | 顧客折衝、要件定義、業界知識 |
| 自社開発・アジャイル重視 | アジャイル・スクラムの経験、ツール習熟度 |
| 大規模SIer | 予算管理、ベンダーコントロール、PMBOKの知識 |
| 外資系・グローバル企業 | PMP保有、英語スキル、国際プロジェクトの経験 |
また、求人票に記載されているキーワードと自分のスキル欄の表現を合わせることも効果的です。「進捗管理」と「スケジュール管理」のように、同じ業務を指す言葉でも表現が異なる場合があります。そのため、応募先の言葉に近い表記に揃えることを意識しましょう。
自己PR欄は、職務経歴欄に散らばっている実績を「このPMはこういう人だ」と一言で印象づけるセクションです。採用担当者が読んで「うちで活躍できそう」と感じる自己PRを書くには、以下のような3段構成が効果的でしょう。
| 段階 | 内容 | 記載例 |
| 強みの軸 | PMとしての自分の強みを一言で宣言する | 私の強みは、課題を早期に可視化し、チーム全体で解決に向かう仕組みを作ることです。 |
| 具体エピソード | 強みを発揮した場面を数値で裏づける | 週次レビューとRedmineによる一元管理を導入し、担当した3プロジェクトすべてで納期内リリースを達成しました。 |
| 再現性 | 新しい環境でも同じ強みを発揮できることを示す | 環境が変わっても、この課題解決のアプローチは再現できると考えています。 |
強みの軸は、複数のプロジェクトにまたがって発揮できたものを選ぶことが大切です。特定のプロジェクトだけではなく、どの現場でも再現できる強みを示すことで、採用担当者の信頼を得やすくなります。
自己PRで差がつくのは、どんな考え方でプロジェクトに向き合っているかが伝わるかどうかです。何ができるかに加えて、どう動くかというスタイルや信念を一言で示せると、採用担当者の記憶に残りやすくなります。
PMとしてのスタイルを表現する際は、以下のような切り口で考えてみましょう。
| 切り口 | 書き方の例 |
| リスクに対するスタンス | 問題が起きてから動くより、起きる前に潰す |
| チームへの向き合い方 | メンバーが動きやすい環境を作ることがPMの仕事だと考えている |
| 顧客との関係の築き方 | 認識齟齬をゼロにすることが、プロジェクト成功の前提だと考えている |
ただし、抽象的な信念だけを並べることは避けましょう。「コミュニケーションを大切にしています」のような表現は、どの職種にも当てはまるため、PM特有の強みとして伝わりません。必ず具体的なエピソードとセットで記載してください。
自己PRで書いた強みや実績が、職務経歴欄の記述と食い違っていると、採用担当者に不信感を与えます。「納期管理が強みです」と書きながら、職務経歴欄のプロジェクト詳細に遅延のエピソードがあると、面接で必ず深掘りされます。
自己PRを書き終えたら、以下の観点で職務経歴欄と突き合わせて確認しましょう。
職務経歴書は書いて終わりではなく、面接での会話の出発点です。自己PRと職務経歴欄の内容が一致していることで、面接でも一貫したアピールができます。
「担当したプロジェクトが炎上した」「納期に間に合わなかった」という経験を職務経歴書に書くべきか迷う方は多いでしょう。
結論から言えば、失敗プロジェクトは隠す必要はありません。むしろ、失敗からどう立て直したかを書けると、PMとしての問題解決力をアピールする材料になります。
採用担当者が失敗経験から見たいのは、以下の2点です。
書き方の型は、課題の発生→原因の特定→打ち手と結果です。たとえば、以下の記載方法のように、失敗を学びと改善行動として再定義することで、成長できるPMという印象を与えられます。
| 仕様変更の頻発により納期が2週間遅延した。原因は要件定義フェーズでのスコープ管理の甘さにあると判断し、次プロジェクトからは変更管理フローを整備した。以降、同様の遅延は発生していない |
ただし、失敗の原因をすべてメンバーや顧客のせいにする書き方は避けましょう。PMとして自分がどう動いたかという視点を忘れずに記載してください。
「自分が経験したプロジェクトは規模が小さく、アピールになるか不安」と感じている方もいます。しかし、プロジェクトの規模が小さくても、そのなかで担った役割が深ければ、十分に評価される職務経歴書になります。
規模の小さい案件をアピールする際は、以下の観点で記載内容を深掘りしましょう。
役割の深さを言語化することで、採用担当者に経験の質が伝わります。規模よりも、自分がそのプロジェクトでどれだけ主体的に動いたかを示すことを意識しましょう。
プロジェクトに途中から参加した場合や、短期間しか携わっていない場合も、書き方次第で評価につなげられます。「途中参加なので成果をアピールしにくい」と感じる方も多いですが、参加期間に自分が果たした役割と貢献に絞ることが大切です。
短期間・途中参加のプロジェクトを記載する際のポイントは以下のとおりです。
| 状況 | 書き方のポイント |
| 途中からPMを引き継いだ | 引き継ぎ時点の課題と、自分が就任後に改善した点を明示する |
| 短期間でプロジェクトを離れた | 担当期間中に完了したフェーズと、その成果を具体的に書く |
| 炎上プロジェクトに途中参加した | 混乱した状況をどう立て直したかをエピソードとして記載する |
途中参加であっても、自分が関わった期間に何をどう動かしたかは事実として残ります。全体の成否よりも、自分の貢献ポイントに焦点を当てることで、採用担当者に伝わる職務経歴書になるでしょう。
職務経歴書に書いた数値は、面接で必ず深掘りされます。成果の数値を記載した場合は、達成方法や算出根拠についての質問が飛んでくることを前提に準備しましょう。
手元に用意しておくべき根拠の例は以下のとおりです。
記載した数値があいまいな場合、面接で答えに詰まる場面が生じます。職務経歴書を完成させたら、記載した数値について「これを面接で聞かれたとき、根拠を説明できるか」と自問してみましょう。
説明できない数値は、表現を修正するか削除するかを検討してください。
面接では、職務経歴書と自己PRの内容を横断的に確認されることがあります。それぞれの内容に矛盾が生じると、採用担当者の信頼を損ないます。
一致させるべき内容の確認ポイントは以下のとおりです。
| 確認項目 | チェックの視点 |
| 強みの一貫性 | 自己PRで宣言した強みの根拠が、プロジェクト詳細に記載されているか |
| 数値の整合性 | 自己PRに書いた成果の数値と、職務経歴欄の数値が一致しているか |
| エピソードの重複 | 同じエピソードを職務経歴欄と自己PRで重複して使っていないか |
| 志望動機との関連性 | 自己PRで示した強みが、応募先で活かせる文脈につながっているか |
書類を仕上げたら、職務経歴書と自己PRを並べて読み直し、採用担当者の視点で矛盾がないかを確認する習慣をつけましょう。
職務経歴書を提出する前に、自分が採用担当者になったつもりで自己インタビューをおこなうことをおすすめします。書類の内容を面接官が深掘りしてきたとき、すらすらと答えられるか事前に確認することで、書類と面接の一貫性が高まります。
PMの面接で頻出する想定質問は以下のとおりです。
答えに詰まった質問があれば、その内容を職務経歴書に補足する機会です。面接で話せないことは、職務経歴書にも書かないほうがよいという点を意識しながら、書類全体を見直してみましょう。
職務経歴書には、前職・現職で携わったプロジェクトの情報を記載します。しかし、クライアント名やプロジェクト名、システムの詳細仕様などは、守秘義務の対象になる場合があります。在職中の転職活動であれば、とくに注意が必要です。
機密情報の取り扱いで押さえておくべきポイントは以下のとおりです。
守秘義務への配慮は、採用担当者からの信頼にもつながるでしょう。「この人は自社に入社しても、情報管理を徹底してくれそうだ」という印象を与えられます。
一方で、情報を伏せすぎると経験の実態が伝わらなくなります。開示可能な範囲で具体性を保つことが大切です。
職務経歴書の適切なボリュームはA4サイズ2〜3枚といわれています。PMのキャリアが長い場合、記載したい内容が多くなりがちです。しかし、枚数が増えるほど採用担当者が読むのに時間がかかり、重要な情報が埋もれるリスクがあります。
読みやすさを確保するための工夫は以下のとおりです。
読みやすい職務経歴書を作れるかどうかも、PMとしての情報整理能力の評価につながります。伝えたいことを取捨選択し、相手が読みやすい形に整理する力は、プロジェクト管理の能力と共通しているといえるでしょう。
職務経歴書をひとつ作って使い回すことは、書類通過率を下げる原因になります。応募先が求めるスキルや経験は企業によって異なるのが通常です。そのため、同じ経歴でも強調するポイントを変えることで、採用担当者に「うちに合っている人だ」と感じてもらいやすくなります。
カスタマイズすべき箇所と変え方は以下のとおりです。
| カスタマイズ箇所 | 変え方の例 |
| 職務要約 | 応募先が重視する強みを冒頭の一文に反映する |
| プロジェクトの並び順 | 応募先の業界・規模と近いプロジェクトを上位に置く |
| スキル欄の並び順 | 求人票のキーワードに合わせて優先度の高いスキルを上位にする |
| 自己PR | 応募先で活かせる強みのエピソードを前面に出す |
ベースとなる職務経歴書を作り込んだうえで、応募先ごとに職務要約・スキル欄・自己PRを部分的に書き換える方法が効率的です。毎回ゼロから作り直す必要はなく、強調するポイントを入れ替えるだけで書類の印象は大きく変わります。
PMの職務経歴書は、プロジェクト規模や成果の数値化、PM視点での言語化など、エンジニア職とは異なる書き方が求められます。「自分では書けたつもりでも、採用担当者にどう読まれているか不安」という方は、転職エージェントへの相談が近道です。
キッカケエージェントは、エンジニア特化の転職エージェントとして、PMの転職活動を書類作成の段階から一貫してサポートしています。
職務経歴書の書き方に迷っているPMの方は、ぜひ一度キッカケエージェントに相談してみてください。
この記事では、PMの職務経歴書で評価されるポイントと、各セクションの書き方を解説しました。採用担当者が重視するのは、どんな規模のプロジェクトをどう動かし、どんな成果を出したかというマネジメントの実績です。エンジニアとしての開発経験をそのまま書くのではなく、PM視点で言語化し直すことが書類通過率を左右します。
職務経歴書は一度作って終わりではなく、応募先ごとに強調ポイントを変えながらブラッシュアップしていくものです。「自分では書けたつもりでも、客観的な評価が不安」と感じたときは、プロに添削してもらうことが、書類選考突破の近道でしょう。
PMとしてキャリアアップや年収アップを目指しているなら、キッカケエージェントへ相談するのがおすすめです。
今の時点でご経験をされている言語や技術要素に関係なく、
①技術を通じてユーザーやお客様にとって使いやすいサービスの実現に興味があるエンジニアの方
②興味・関心がある技術について自ら学ぶ意欲をお持ちの方
上記に当てはまる方でしたら、素晴らしい企業とのマッチングをお手伝いできる可能性が高いです。
最近はお住まいの場所に限らず応募ができる企業や経験年数に関係なくフラットにご評価をして下さる企業も増えているため、ぜひ一度モロー宛てにご相談を頂けますと幸いです。
