PMP申請の経験の書き方｜英文の記入例と差し戻されやすい例【2026年版】

申請書の経験欄には、プロジェクトごとに基本情報と説明文を入力します。基本情報は、プロジェクト名、組織名、自分の役職、開始と終了の年月などです。

説明文の中身は、PMIの公式ブログ（2026年8月28日）が参考になります。プロジェクトごとに説明できるようにしておく点を、6つ挙げています。当サイトの言葉で整理すると、次のとおりです。

この順に書くと、読み手が迷いません。各観点に1〜3文が目安です。長く書くほど通りやすくなるわけではありません。

説明文には語数（字数）の制限があります。ネットでは「200〜500語」などの数字も見られますが、PMIのハンドブックやECOに具体的な数字の記載はありません。変わることもあるので、入力画面に表示される条件に合わせてください。

肩書きが「プロジェクト・マネジャー」である必要はありません。PMIのブログは、肩書きより仕事の中身が大事だとしています。リーダーやコーディネーターの立場でも、プロジェクトを率いて方向づけていれば対象です。

逆に、プロジェクト・マネジャーの肩書きでも、定型の運用業務は数えられません。ECOとPMIのブログをもとに、書ける経験と書けない経験を整理しました。

無給の経験でもかまいませんが、仕事の場でのものに限られます（ECO）。経験は申請前の10年以内のものだけを数えます。

期間が重なるプロジェクトは、重なった月を1回だけ数えます。たとえば4〜9月と7〜12月のプロジェクトなら、重なる7〜9月を二重に数えず、合計は9か月です。

PMPの受験資格は「プロジェクトを率いて方向づけた経験」です。審査では、説明文から「この人はプロジェクトを率いていたか」を判断します。

そのため、専門の作業（設計、コーディング、施工、分析など）を詳しく書いても、評価にはつながりません。書くべきは、計画を立てた、関係者を調整した、リスクに手を打った、進捗を報告した、といったマネジメントの動きです。

書くときは、PMPの出題範囲の言葉を手がかりにしましょう。たとえば、スコープの定義、スケジュールの作成、リスクの特定、ステークホルダーとの調整、変更の管理、終結と教訓などです。26タスクの全体は新ECOの26タスク一覧で確認できます。

予測型（ウォーターフォール）のプロジェクトでは、立ち上げから終結までの流れに沿って書くと自然です。以下は当サイトが作った架空の例です。そのまま使わず、自分の経験に置き換えてください。

記入例（予測型・社内システムの更改）

Objective: The objective was to replace the company's legacy order management system within 12 months and a budget of 80 million yen. As the project manager, I led a team of eight internal staff and two vendors. I defined the scope with business departments and created the work breakdown structure and the baseline schedule. I identified risks in data migration and arranged a rehearsal as a response. I held weekly status meetings and reported progress and cost performance to the steering committee. When the sales department requested additional reports, I submitted a change request and obtained approval before updating the plan. Outcome: The new system went live one week ahead of schedule within budget, and I documented lessons learned for future projects.

この例には、予測型の代表的なマネジメントの動きが入っています。スコープ、WBS、ベースライン、リスク対応、報告、変更管理、教訓です。

アジャイルで進めたプロジェクトでは、スプリントやバックログなど、実際に使った言葉で書きます。スクラムマスターやプロダクトオーナーの立場だった場合も、チームを導いた経験なら対象です。

記入例（アジャイル・顧客向けアプリの開発）

Objective: The objective was to release a mobile application for customer appointments and improve it based on user feedback. I served as the project lead for a cross-functional team of six members using two-week sprints. I facilitated sprint planning, daily stand-ups, reviews, and retrospectives, and worked with the product owner to prioritize the backlog by business value. I removed impediments such as delayed access to test environments by escalating to the infrastructure manager. Outcome: The first release was delivered in four months, and the online booking rate increased in the following quarter.

記入例（ハイブリッド・新工場の生産ライン立ち上げ）

Objective: The objective was to set up a new production line, including equipment installation and the development of control software. I managed the equipment installation with a predictive plan and fixed milestones, while the software team used iterative development to reflect feedback from operators. I integrated both plans, managed procurement of equipment, and coordinated safety inspections required by regulations. Outcome: The line started operation on the planned date and met the target for initial production quality.

ハイブリッドでは、どの部分を予測型で、どの部分を反復で進めたかを書き分けると、実態が伝わります。

英語が得意でなくても、型を決めれば書けます。ポイントは3つです。

• ✓主語はI（私）にする：「The team did ...」ばかりだと、自分の役割が見えない。
• ✓過去形の動詞で始める：led, planned, defined, coordinated, managed, monitored, resolved, reported, closed など。
• ✓数字を入れる：期間、人数、予算、成果の数値があると、規模と結果が伝わる。

語数が足りないときは、リスクへの対応や関係者との調整の具体例を1文足します。多すぎるときは、技術の説明や背景を削ります。マネジメントの動きは削らないでください。

翻訳ツールを使うのは問題ありません。ただし、出てきた英文が自分の実態と合っているかは必ず確かめてください。大げさな表現になっていないかも見直しましょう。

次のような書き方は、追加の説明を求められたり、経験として認められなかったりしやすい例です。

経験を実態より大きく書くのは避けてください。監査になると、各プロジェクトの確認者に内容を見てもらい、署名をもらいます。確認者が「この人はそこまでやっていない」と感じれば、署名は得られません。監査の流れはPMPの監査に当たったらで解説しています。

申請の手順の全体はPMPの申請方法に、研修時間の書き方は35時間研修の解説にまとめました。

送信した後で書き直すのは手間がかかります。提出の前に、次の7点を確かめてください。

1. 1経験は申請前の10年以内か。重なった月を二重に数えていないか。
2. 2定型業務・学校の課題・私的な活動が混ざっていないか。
3. 3各プロジェクトに、目的・期間・率い方・関わった相手・率いた活動・成果がそろっているか。
4. 4主語がI（私）で、マネジメントの動詞で書いているか。
5. 5期間・人数・予算・成果の数字が実態どおりか。
6. 6各プロジェクトに、内容を確かめて署名できる上司などがいるか。
7. 7顧客の機密情報など、外に出せない内容を書いていないか。