監修：山根一城（株式会社ポテンシャライト代表取締役CEO ／ 業界20年）
職務経歴書 PMとは、プロジェクトマネージャーが転職や社内異動の選考に向けて、自身が担ってきたプロジェクトの範囲と役割、進め方、成果をまとめた応募書類を指します。履歴書が経歴の事実を並べる書類であるのに対し、職務経歴書は「何を任され、どう判断し、何を動かしたか」を読み手に伝える書類です。PMの場合は、作業そのものより、計画・調整・意思決定の中身をどう示すかが中心になります。
職務経歴書の第一の読み手は、採用側のPMやマネージャー、そして人事担当です。彼らが知りたいのは「自社のプロジェクトを任せたとき、同じように回せそうか」という一点に近いものです。したがってPMの職務経歴書は、作業一覧の羅列ではなく、担当したプロジェクトの輪郭と、その中で自分が握っていた責任の範囲を伝えることが目的になります。
ここで混同しやすいのが、メンバーとしての作業実績とPMとしての管理実績の区別です。設計書を書いた、テストを実施したといった作業は、PMの職務経歴書では背景情報にとどまります。読み手が見たいのは、スコープをどう定め、スケジュールとコストをどう引き、ステークホルダーの間に立ってどう合意を作ったか、という管理側の動きです。
つまずきやすいのは、関わった工程を広く書こうとして焦点がぼやけることです。要件定義から本番移行まで一通り触れていても、どの判断を自分が下したのかが書かれていないと、読み手は役割の大きさを測れません。工程の広さより、責任の所在を明確にする方が伝わります。
構成は、冒頭の職務要約から入り、保有スキル、プロジェクト別の経歴、資格の順に組むのが読みやすい並びです。職務要約は、これまで何年どんな領域のプロジェクトを、どの規模・どの立場で担ってきたかを数文でまとめる部分で、ここだけで全体像が伝わるように書きます。
プロジェクト別の経歴では、一つのプロジェクトごとに軸をそろえて書くと比較しやすくなります。具体的には、プロジェクトの目的と概要、体制と自分の役職、担当したフェーズ、使ったマネジメント手法や成果物、そして結果、という並びです。成果物の例としては、プロジェクト計画書、WBS、ガントチャート、課題管理表、ステコミ向けの報告資料などが挙げられ、これらを「作った・運用した」と書くことで管理実務の実在感が出ます。
PMの職務経歴書で差が出るのは、技術の広さではなく、判断と調整をどう言語化するかです。同じ「スケジュール管理をした」でも、遅延の兆候をどこで捉え、誰と何を調整して立て直したかまで書けると、再現性のある能力として読めます。QCDのどれを優先してどう折り合いをつけたか、といった取捨選択の記述は、PMの思考を映す部分です。
領域による書き分けも意識したい点です。SIer系のPMなら発注者とベンダーの間に立つ調整やプライムベンダーとしての統括が、社内DX寄りのPMなら業務部門を巻き込む変革の推進が中心になります。応募先がどちらを求めているかで、同じ経歴でも前面に出す側面が変わります。経歴の事実は変えずに、強調の重心を応募先に合わせる、という調整です。
また、ステークホルダーとの関わり方は具体的に書くほど伝わります。経営層へのステコミ報告、業務部門との要件調整、開発ベンダーとの進捗折衝など、相手ごとに立場が違うことを示すと、PMとしての立ち回りの幅が見えてきます。相手の役割まで書かず「関係者と調整した」とだけ書くと、せっかくの経験が平板に見えてしまいます。
よくあるのは、プロジェクトの説明ばかり厚くなり、自分が何をしたかが薄くなるパターンです。システムの機能や業務内容を詳しく書いても、それは会社の仕事の説明であって、応募者自身の実績ではありません。プロジェクト概要は数文に抑え、自分の判断と行動に紙幅を割く配分が読みやすい形です。
次に多いのが、作業と成果を混ぜてしまうことです。「進捗会議を毎週開催した」は作業であって成果ではありません。会議を通じて何を早期に拾い、どうリスクを抑えたかまで書いて、はじめて管理の成果として読めます。開催した事実と、それが何に効いたかを分けて書くと整理しやすくなります。
もう一つは、守秘への配慮が抜けることです。具体的な企業名や固有の内部情報を書くと、選考以前に問題になりかねません。業界・業態・規模感といった一般化した表現に置き換えつつ、プロジェクトの性質は伝わるように書く、というバランスが求められます。固有名を消すと具体性が失われると感じる場合は、役割や工程の記述を厚くして密度を補うとよいでしょう。
職務経歴書を書く作業は、自分のPMとしての経験を棚卸しする機会でもあります。どのプロジェクトで何を判断したかを書き出していくと、自分が得意としてきた領域や、逆に関わりが浅かった工程が見えてきます。これは次にどんなプロジェクトを狙うか、どのスキルを補うかを考える材料になります。
書類は一度作って終わりにせず、応募先の求める役割に合わせて重心を調整していくものです。SIer寄りか社内DX寄りか、プレイングを含むか統括中心かで、前面に出す経歴は変わります。日頃からプロジェクトごとに役割と成果を記録しておくと、更新のたびに思い出す負担が減り、キャリアの節目で動きやすくなります。経歴書の精度は、そのまま自分の市場価値を言葉にする力につながっていきます。
PMの職務経歴書で最も重視されるのは何ですか
担当したプロジェクトでの役割の範囲と、自分が下した判断の中身です。工程を広く触れた事実よりも、スコープ・スケジュール・コストをどう握り、ステークホルダーとどう合意を作ったかが伝わる書き方が重視される傾向があります。作業の列挙より管理の実績に焦点を当てるとよいでしょう。
プロジェクトの規模は数字で書くべきですか
正確に書けるなら体制人数や期間を示すと規模感が伝わりますが、記憶が曖昧な数字を無理に書く必要はありません。その場合は小規模・大規模といった言葉や、体制の層の厚さで表すこともできます。出典のない割合や金額を書くより、確かな事実だけを選ぶ方が信頼されます。
作業実績しかない場合はどう書けばよいですか
メンバーとしての作業でも、進捗の調整役を担った、課題を拾って上位者に上げたなど、管理に近い動きがあれば切り出して書けます。PMとしての経験が浅い段階では、その経験を正直に示しつつ、調整や段取りに関わった部分を前に出す構成にすると、志向と適性が伝わりやすくなります。