✅この記事はこんな「疑問・悩み」を持つ方に向けた記事です
・PMP申請時の「実務経験（プロジェクト経験）」を、どう英語で表現すればいいか分からず手が止まっている方
・「もし監査（Audit）に選ばれたら…」という不安から、嘘偽りなく、かつ承認されやすい書き方を知りたい方
・現場の泥臭いインフラ構築経験を、PMBOK用語にどう「変換」すべきか悩んでいるベテラン技術者の方
✅この記事を読めば、こんな解決策が分かります
30年インフラ屋が実践した、「PMIの監査官に疑念を抱かせない、整合性の取れた実務経験の記述メソッド」が分かります。日本語→英語の翻訳でよくある誤りを正し、一発で審査をパスするための具体的な英文構成案と、監査を恐れずに済む「品質管理」の考え方が分かります。
✅30年インフラ屋の「ここだけの話」（独自視点）
PMPの申請書類作成は、「システムの納品図書」の作成と同じです。 嘘をつくのではなく、「事実（実績）を、相手（PMI）が理解できるプロトコルに翻訳して提示する」。これが重要です。 30年現場で「品質（エビデンス）」を扱ってきた我々にとって、監査は恐れるものではなく、正当性を証明する「検収作業」に過ぎません。テクニックに走らず、インフラ屋のプライドを持って「整合性」で勝負する書き方を伝授します。
PMI審査員に実務経験（プロジェクト経歴）を伝える重要性
「30年、数え切れないほどのプロジェクトを回してきました。しかし、いざPMP申請の画面を前にした時、自分の経験をどう表現すべきか、手が止まったんです。
私は長年インフラの現場で、情報の正確性と整合性が何より重要だと叩き込まれてきました。だからこそ、申請時点から石橋を叩き壊すほど慎重に、30年のキャリアを棚卸しして完璧な書類を作り上げました。
その後の試験で一度不合格という苦い経験をしたからこそ、今、確信を持って言えます。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申請でも通りやすい構成です。
【私ならこう書く】アジャイル開発プロジェクト（スクラム型）の例
アジャイル型でも、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案件ずつ「目的・あなたの役割・アクティビティ・成果」を明確に書いてみてください。監査リスクも考慮しつつ、明確で信頼性のある申請を行う事が重要です。
最終的には英語で提出する為、日本語→英語へgoogle翻訳等で変換が必要です。英語に変換されたものは、再度、日本語に変換する事をお勧めします。私が申請した際は、再度日本語に変換するとオカシナ文章になっていた事がありました。その際には、該当箇所の日本語の言い回しを少し変えて再度、英語に翻訳したところ、意図する文章になりました。
繰り返しますが、英語に変換されたものは、再度、日本語に変換して文章がおかしくないかをチェックしてください。
