PMI審査員に実務経験（プロジェクト経歴）を伝える重要性
PMPを受験するための申請で、多くの人がつまずくのが「実務経験（プロジェクト経歴）」の記述です。正しく書けていないと、審査で差し戻されるリスクも。
本記事では、PMPの申請要件を押さえつつ、実際に合格者が使った記述例や注意ポイントを交えて解説します。この記事を読むだけで、あなたのプロジェクト経験をPMI審査員に伝わる形に整理できます。
PMP申請における実務経験とは何か
PMP受験条件と実務経験の定義
PMP申請には、PMIが定める「プロジェクトマネジメント経験」が必須で、単なる業務ではなくプロジェクトらしい構成が求められます。
PMP受験には、学歴に応じて一定の月数・時間の経験が必要とされているからです。 たとえば大学卒業者の場合、36か月以上／4,500時間以上の「リードかつディレクション（主導・指揮）」経験が必要です。具体的には、申請時にプロジェクト単位で「開始 → 計画 → 実行 → 監視・コントロール →終結」の各プロセスに関与した経験を記載する必要があります。
審査・監査のポイント
PMP申請は自己申告ですが、ランダムに監査（Audit）が実施される可能性があります。これは、PMIは申請内容の信頼性を担保するため、監査を実施する制度がある為です。過去申請者の声では、「プロジェクト説明が曖昧」「まとめて経験を書いた」などで却下された例もあります。監査を見越して、各プロジェクトを明確に、かつ具体的に記述することが重要です。
受験準備で読むべき内容も整理していますので、是非ご確認ください。
実務経験の具体例（PMP申請用）
IT開発プロジェクト（ウォーターフォール型）の例
ウォーターフォール型プロジェクトでも、PMBOKのプロセスを意識した記述が有効です。その理由は、審査員がプロジェクトらしさを判断しやすくなるからです。
具体例（例文形式）：
- プロジェクト名：社内基幹システム刷新プロジェクト
- 期間：2022年1月～2023年6月（18か月）
- チーム規模：8人
- 役割：プロジェクトマネージャー（PM）
- 目的：旧システムの老朽化対応、新機能追加による業務効率化
- 実施内容：
- プロジェクト立ち上げ（ステークホルダーを特定、目的・範囲を定義）
- 詳細計画（WBS作成、スケジュール策定、予算見積もり）
- 実行（開発、テスト、品質管理）
- 監視・コントロール（進捗報告、リスク管理、変更管理）
- 終結（成果物引き渡し、ユーザー教育、プロジェクト評価）
- 成果：納期通りで稼働を開始。運用開始後、手作業を50％削減。
この例は、プロセス各段階に自分が関与した点を明示しており、PMP申請でも通りやすい構成です。
下記の記事で49個のプロセスについて解説していますので、ご確認ください。
アジャイル開発プロジェクト（スクラム型）の例
アジャイル型でも、PM経験として評価される記述が可能です。PMIもアジャイル手法を重視しており、実践経験が評価対象になるからです。
具体例（例文形式）：
- プロジェクト名：新規モバイルアプリ開発（スクラム）
- 期間：2023年4月～2024年3月（12か月）
- チーム規模：6人（開発＋テスト＋UX）
- 役割：スクラムマスター兼プロジェクトリード
- 目的：ユーザーエンゲージメント向上のため、アジャイルによる迅速開発
- 実施内容：
- プロダクトバックログ構築（顧客ヒアリングを基に要件整理）
- プランニングポーカーで見積もり （ 初期ベロシティ算出）
- スプリント実施（2週間単位）、デイリースクラム、レビュー、レトロスペクティブ
- リスク発生時の即時エスカレーション、チーム外ステークホルダーとの調整
- 成果分析（KPI：ユーザー継続率、リリースサイクル）
- 成果：アプリリリースから3か月でユーザー継続率＋20%。平均スプリントベロシティが10 → 15に向上。
アジャイル手法を使ってプロジェクトを管理した経験を明確に書くことで、PMP申請でも強みになります。
実務経験記述のコツと注意点
PMIが期待するキーワード・観点を押さえる
PMBOK用語・プロセス用語を適切に使うと説得力が増します。審査員にとって、用語がPM理論に紐づいているかが判断材料になるからです。
具体的には、立ち上げ（Initiating）、計画（Planning）、実行（Executing）、監視・コントロール（Monitoring & Controlling）、終結（Closing）などを自然に文中に組み込みます。ただ列挙するのではなく、どの作業でどう使ったかを説明しましょう。
各プロジェクトを分けて記載
経験は「1プロジェクト＝1エントリ」が望ましいです。それは、申請審査時に審査員がそれぞれのプロジェクトを明確に評価できるからです。
複数の小さな案件をまとめて書くのではなく、主要な3～5案件を選び、それぞれ分けて記述しましょう。
監査や審査を通過しやすくするには、プロジェクトごとの構成が重要です。
未プロジェクトマネージャーでも記載可能な経験
正式なPMタイトルがなくても、PMとしての責任を持った経験があれば記載できます。理由は、審査では役割が重要であり、職名よりも実際の活動が見られます。
- PMOの一員としてプロセス改善をリード → 各プロセスを「プロジェクト」と定義して記載。
- チームメンバーとしてWBSやスケジュール管理、進捗報告などを担当 → 自分が主導したプロセスを強調。
自分の役割を正しく定義し、PMBOKプロセスとの関連を示すことで、PMとしての経験として認められます。
よくある失敗パターンとその回避策
曖昧な役割記述
問題点：自分の役割が「支援した」「手伝った」だけになっている。
回避策：自分が「leading and directing（主導・指揮）」した具体的なタスクを明記。過去の申請者からは、「I assisted the project manager（私はPMを補佐した）」ではなく、自分主体で実行した経験を書くべき、という声があります。
プロセス用語の羅列だけ
問題点：単に「スコープ定義、リスク管理、品質管理」と並べるだけ。
回避策：それらの用語をどのように使ったか（例：リスク管理 → 定期リスクレビューと緊急対応で影響を最小化）をストーリー形式で記述。
1つにまとめすぎる経験
問題点：たくさんの小さな案件を1つの大きな枠でまとめてしまう。
回避策：主要な案件を分け、各案件で開始～終結までのフェーズを個別に記述。過去にこれをしないで拒否された例があります。
まとめ
PMP申請において、実務経験（プロジェクト経歴）の記載は非常に重要です。本記事では、PMBOKプロセスに沿った具体例（ウォーターフォール／アジャイル）とともに、審査を通すためのポイントを整理しました。
まずは自分のプロジェクトを洗い出し、1案件ずつ「目的・あなたの役割・アクティビティ・成果」を明確に書いてみてください。監査リスクも考慮しつつ、明確で信頼性のある申請を目指しましょう。
