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

職務経歴書の第一の目的は、書類選考の担当者が「このPMに自社のプロジェクトを任せられそうか」を数分で判断できるようにすることです。読み手は人事担当とPMOや開発部門の責任者に分かれ、前者は経歴の整合性や在籍期間を、後者はプロジェクトの難易度と自分の関与度を見ています。この二者を同時に満たす記述が求められます。

採用側が読み取ろうとする軸は、おおむね次の三つに整理できます。

• プロジェクトの規模と性質
  開発か業務改革か、新規構築か保守か、関わったベンダーや部門の数など、難易度を推し量る材料を見ています。
• 担当した役割の深さ
  PMとして計画を立てたのか、リーダーの補佐だったのか、要件定義から参画したのかといった関与の実態を確認します。
• QCDへの効き方
  品質・コスト・納期のどこに、どんな打ち手で貢献したかを見ています。

この三軸に沿って情報が配置されていないと、経験が豊富でも「何をする人か分かりにくい」という理由で通過しにくくなります。まず軸を決めてから書き始めるのが近道です。

一般的な職務経歴書は、冒頭の職務要約、保有スキル・資格、プロジェクトごとの職務経歴、自己PRという順に並びます。PMの場合は、このうちプロジェクトごとの記述が選考の中心になります。

プロジェクト単位の記述では、次の順で書くと読み手が状況を再構成しやすくなります。

1. プロジェクト概要
   目的、対象システムや業務、期間、体制規模、使った方式（ウォーターフォールかアジャイルか）を数行でまとめます。
2. 自分の役割と担当フェーズ
   要件定義・基本設計・結合テストといった工程名を使い、どこを主管したかを明示します。
3. 具体的な取り組み
   WBSの作成、進捗会議の運営、ベンダーコントロール、課題・リスク管理など、実際に動かした作業を書きます。
4. 成果
   納期やQCDへの寄与を、確認できる事実の範囲で記述します。

冒頭の職務要約は、全体を読む前の見取り図です。何年PMを務め、どの業界・規模のプロジェクトを得意とするかを三〜四文に凝縮します。ここで方向性が定まると、後続の個別記述が頭に入りやすくなります。

PMの職務経歴書でつまずきやすいのは、作業の列挙に終始して「自分の判断」が見えなくなることです。進捗管理をした、会議を開いた、だけでは誰がやっても同じに読めます。状況・課題・自分の打ち手・結果の流れで書くと、判断の質が伝わります。

たとえば「遅延が発生していたため、クリティカルパス上のタスクを洗い直し、要員の配置とレビュー順序を見直して回復を図った」のように、何を根拠にどう動いたかを一続きで示します。これなら読み手はPMとしての思考を追えます。

避けたい表現としては、次のようなものがあります。

• 役割をあいまいにする語
  「携わった」「サポートした」は関与度が読み取れません。主管か補佐かを言い切ります。
• 根拠のない定量表現
  確認できない削減率や短縮日数を書くと、裏取りで崩れます。数字が曖昧なら、打ち手と変化を言葉で具体化します。
• 抽象的な強み
  「調整力があります」だけでは伝わりません。どの立場の相手と、何について合意形成したかを添えます。

守秘の観点から、顧客名や社内固有の情報をそのまま書けない場合もあります。その際は業界・規模・システム種別に置き換えると、具体性を保ちながら配慮できます。

職務経歴書と混同されやすいものに、履歴書とスキルシート（職務要約シート）があります。軸を分けて理解しておくと、それぞれに書く内容を取り違えずに済みます。

履歴書は学歴・職歴・資格といった事実を定型で記す公的な書類で、人物の基礎情報を確認するものです。これに対し職務経歴書は、経験の中身と再現性を伝える自由記述の書類で、PMとしての動き方を語る場になります。

スキルシートは、SESや常駐の現場で参画可否を判断するために、使用技術や工程経験を一覧化したものです。職務経歴書より機械的な表形式が多く、文脈よりも「どの工程・どの技術を経験したか」の網羅性が重視されます。職務経歴書が物語的に役割を語るのに対し、スキルシートは条件照合のための索引に近い位置づけです。

応募先によっては両方の提出を求められることもあります。その場合、スキルシートで経験の広がりを示し、職務経歴書で代表的なプロジェクトを深掘りすると、網羅性と深さの両方を伝えられます。役割を書き分ける意識があると、同じ経験でも通りやすい書類になります。

職務経歴書を書く作業は、転職活動のためだけのものではありません。プロジェクトごとに役割・打ち手・成果を言語化していくと、自分がどの工程やどの規模で力を発揮してきたかが見えてきます。これは次に目指すポジションを考えるうえでの材料になります。

たとえば、要件定義や上流の合意形成に強みが集まっているなら、より企画寄りの役割へ、ベンダーコントロールや進捗回復の記述が厚いなら、大規模プロジェクトの統括へ、という方向が見えてきます。書類を定期的に更新する習慣があると、経験の棚卸しが自然に進み、キャリアの選択肢を具体的に検討しやすくなります。応募の直前にまとめて書くより、節目ごとに追記していくほうが、精度の高い記述になりやすいでしょう。

プロジェクトの規模はどう書けばいいですか

期間、体制の人数、関わった部門やベンダーの数、対象システムや業務の範囲といった要素で表します。すべてを数値化できなくても、新規構築か保守か、単一部門か複数部門横断かといった性質を言葉で示せば、難易度は十分に伝わります。確認できない数字は無理に書かず、事実の範囲でまとめるのが安全です。

PM経験が浅くても職務経歴書で見せられますか

リーダー補佐やサブリーダーとしての関与でも、担当した工程と自分の判断を具体的に書けば評価材料になります。要件定義での論点整理、進捗の見える化、課題管理の運用など、PMに近い動きを工程名とともに記すと、役割の広がりが伝わります。関与度を正直に書くことが信頼につながります。

複数プロジェクトをどう並べればよいですか

新しいものから時系列で並べるのが基本ですが、応募先に近い経験を冒頭の職務要約で先に触れると、関連性が伝わりやすくなります。件数が多い場合は、代表的なプロジェクトを深く書き、残りは概要を簡潔にまとめる濃淡のつけ方が有効です。すべてを同じ密度で書く必要はありません。