職務経歴書 プロジェクトマネージャー

プロジェクトマネージャーの職務経歴書が答えるべき問いは、「このプロジェクトを任せたら、同じように回せそうか」です。開発スキルの一覧ではなく、不確実性の高い状況で意思決定と調整を担った証跡を示す書類だと考えると、書く中身が定まってきます。読み手はたいてい採用担当者と現場のマネージャーで、前者は要件に合うかを、後者は一緒に働けるかを見ています。

そのため、記載の軸は三つに整理できます。

• 任された範囲
  要件定義から参画したのか、既存プロジェクトの火消しに入ったのかで、求められる力は変わります。関与した工程（企画・要件定義・設計・開発・テスト・リリース・保守）のどこを主導したかを書き分けます。
• 動かした制約
  QCD（品質・コスト・納期）やスコープのうち、どれが厳しく、どこを守るために何を調整したかを示します。全部を完璧に守ったという書き方より、トレードオフの判断を書くほうが説得力が出ます。
• 関わった相手
  社内の事業部門、協力会社、エンドユーザーなど、利害が異なる相手をどうまとめたかが、PMらしさの核になります。

職種名としてのPMはプロジェクトマネージャーを指し、プロダクトマネージャーとは役割が異なります。応募先がどちらを求めているかを確認してから書き始めると、ずれを避けられます。

一般的な職務経歴書は、職務要約・活かせる経験スキル・プロジェクトごとの詳細・保有資格という順で構成されます。プロジェクトマネージャーの場合、プロジェクト詳細をどう書くかがほぼ評価を決めると言ってよいでしょう。

各プロジェクトは、同じ枠組みで並べると読み手が比較しやすくなります。たとえば、プロジェクト概要（目的・業界・システムの種類）、体制とあなたの役割、期間、使用技術や手法、担当業務、成果、という項目をそろえます。体制では、チーム人数だけでなく、自分が何人を見て、協力会社が何社関わったかまで書くと、マネジメントの幅が伝わります。

成果の書き方には、つかみやすいコツがあります。

• 課題から書く
  「納期が逼迫していた」「要件が固まらないまま開発が走っていた」など、着任時の状況を先に示すと、自分の打ち手の意味が伝わります。
• 打ち手を具体的に書く
  WBSを引き直した、ステアリングコミッティで優先順位を再合意した、といった具体的な行動を、工程名や成果物名とともに記します。
• 結果を検証可能な形で書く
  出典を示せる数値があれば添え、なければ「遅延していた工程を計画線に戻した」のように言葉で状態の変化を書きます。社内の非公開データや脚色した数字は避けます。

複数プロジェクトがある場合は、応募先に近いものを前に、似た内容は役割の違いが分かるように差をつけて並べると、冗長さを抑えられます。

プロジェクトマネージャーの職務経歴書でよく起きるずれは、いくつかの典型的な形に分けられます。いずれも、本人の実力ではなく書き方の問題で評価を下げてしまうもったいないケースです。

• 参加記録になってしまう
  「〜の開発に携わった」という書き方が続くと、担当者なのか管理者なのかが読み取れません。意思決定や調整の主語が自分だった場面を選んで書く必要があります。
• 技術の列挙に寄りすぎる
  使用言語やツールを並べること自体は問題ありませんが、それだけだとエンジニアの経歴書と区別がつきません。マネジメントで何を動かしたかが薄いと、PMとしての評価材料が足りなくなります。
• 規模感が伝わらない
  「大規模プロジェクト」とだけ書いても、読み手の想像と食い違います。体制人数や工程範囲、関係者の広さで輪郭を示すほうが誤解を減らせます。
• 守秘と誇張の線引きが甘い
  顧客名や固有の数字をそのまま書くと守秘に触れることがあります。一方で、根拠のない「売上を大幅改善」といった表現は裏付けを問われます。業界や規模を一般化しつつ、検証できる範囲で書くのが無難です。

面接では経歴書の記述を起点に深掘りされます。自分で説明しきれないことは書かない、という方針で見直すと、整合性のある一枚になりやすいでしょう。

職務経歴書は、似た書類や概念と混同されがちです。役割の違いを押さえておくと、どの情報をどこに書くかの判断がしやすくなります。

• 履歴書との違い
  履歴書は学歴・職歴・資格などを定型で記す書類で、人物の基本情報を扱います。職務経歴書は、その職歴の中身を実績として説明する書類で、自由度が高い分だけ構成力が問われます。
• プロジェクト計画書との違い
  計画書は、これから動かすプロジェクトの体制・スケジュール・リスクを定義する業務文書です。職務経歴書はすでに完了した仕事を振り返って書くため、計画どおりに進まなかった局面でどう判断したかこそが読みどころになります。
• 職務要約との違い
  職務要約は経歴書の冒頭に置く数行の要点で、全体の縮図です。詳細に書いた実績のうち、応募先に響きそうなものを先出しする位置づけだと考えると書きやすくなります。

また、PMのキャリアは、SIerのPM、社内のDX推進、コンサル寄りなど幅があります。自分がどの職域に近いかを意識して書くと、応募先とのすり合わせがしやすくなります。経歴書はその職域の中での現在地を示す地図のような役割も果たします。

職務経歴書を書く作業は、転職のためだけのものではありません。担当したプロジェクトを、課題・打ち手・結果の順で言語化する習慣は、自分の強みと手薄な領域を見つめ直すきっかけになります。要件定義から主導した経験が多いのか、火消しで評価されてきたのかが見えると、次に取りに行く経験の方向も定めやすくなります。

定期的に書き足しておくと、記憶が新しいうちに実績を残せて、いざというときに慌てずに済みます。プロジェクトが一区切りついたタイミングで、体制や自分の判断を数行メモしておくだけでも、後から経歴書に起こす負担が軽くなります。経歴書は、PMとしての現在地と次の一歩を確かめる道具として使えます。

開発経験が長くPM歴が浅い場合、どう書けばよいですか

PM歴が浅くても、小規模なチームのとりまとめや、課題の洗い出しと優先順位づけを担った場面があれば、それを管理の実績として書けます。開発経験は土台として触れつつ、意思決定や調整を主語にした記述を増やすと、PM志向が伝わりやすくなります。

守秘の都合で数字が出せないときはどうしますか

出典を示せない数字は無理に書かず、状態の変化を言葉で表すのが安全です。たとえば遅延していた工程を計画線に戻した、要件の認識差を整理して合意に至った、といった形です。業界や規模は一般化し、顧客名や固有の金額は避けます。

複数プロジェクトをどこまで載せるべきですか

すべてを同じ密度で載せる必要はありません。応募先に近い案件や、役割の幅が伝わる案件を厚く書き、似た内容は簡潔にまとめます。古い案件は概要にとどめ、直近で担った意思決定や調整を詳しく書くと、現在の力が伝わりやすくなります。