PMP取得後、仕事で変わったこと：資格よりも「話し方」が変わった

前回は、PMPを3年間維持するための60PDUの計画を立てました。では、この資格は維持するだけの価値があるのでしょうか。今回は、その問いの半分にあたる実務の話をします。

3行まとめ：PMPが変えたのは、知識の量よりも仕事の順番でした。同じ言葉を同じ意味で使い、課題を前にしたらまず評価し、変更は記録で受け、成果物よりも価値を問うようになりました。ただ、合格してからまだ3か月も経っていませんし、資格が仕事を代わりにやってくれるわけではありません。

まずは私の仕事環境から

今、私はConcentrixでGlobal Tech PMとして働いています。エンタープライズのクライアント向けに、ShopifyShopifyデジタル店舗と実店舗をホスティングし、多言語翻訳、グローバル決済、カスタムアプリのエコシステムを提供する世界的なコマースプラットフォームです。Read More →・MagentoでのEC構築と機能改善を担当し、優先順位の整理からリスク管理、UAT（ユーザー受け入れテスト）、リリース、ローンチ直後の安定化までを見ています。

仕事で関わるのは、クライアント企業の本社チーム、各国の現地法人、グローバルベンダー、海外の技術チームです。規模感をひとつ例に挙げると、あるグローバルなビューティーグループのPDP（商品詳細ページ）生成SaaSを改善し、5つのブランド、27のECサイトへと広げる仕事を担当しました。ひとつの決定が、複数のブランドと複数の国へ一度に広がる構造です。

その前は、HyperhireでSoftware Development PMとして、Web、アプリ、SaaS、ブロックチェーンのプロジェクトを担当していました。一緒に働いた開発者は、インド、パキスタン、インドネシア、ナイジェリア、エチオピアにいました。国は5つ、タイムゾーンもバラバラでした。

こうした環境で仕事がうまくいかなくなるきっかけは、たいてい技術よりも言葉にある、と私は考えています。だから、PMP以後に変わったことも、ほとんどが「言葉」と「順番」でした。

ちなみに、これらはすべてPMPを取る前からやってきた仕事です。資格を取ったから仕事の中身が変わったのではなく、同じ仕事のやり方が少しずつ変わったのです。

最初に変わったのは言葉だった

PMとして働くなかで、scope、change request、riskといった言葉は、PMP以前からずっと使っていました。ところがPMPの勉強を通じて、これらの言葉の境界が格段にはっきりしました。最近、グローバルな会議やメールで意識して使い分けているのは、次の5つです。

用語	私が使っている意味	使い分ける理由
Scope（スコープ）	今回やると合意したこと、そしてやらないと決めたこと	「やらないこと」まで書いておかないと、あとで話が食い違う
Change Request（変更要求）	合意したスコープ・スケジュール・コストを変えようという正式な要求	小さく見えても影響があるなら、決定権者が判断すべき
Risk（リスク）	まだ起きていないが、起こりうる不確実なこと	前もって対応計画を立てられる
Issue（課題）	すでに起きていて、今まさに影響を与えていること	必要なのは計画ではなく、解決と報告
Acceptance Criteria（受け入れ基準）	成果物を「完了」として受け入れる条件	UATで「できたと思う」と「できた」を分ける

このなかで私にとって特に役立ったのは、リスクと課題の区別です。「This is a risk」と「This is an issue」は、聞き手にとってまったく別のシグナルです。前者は「備えよう」、後者は「今すぐ手を打とう」という意味になります。この2つを混ぜて使うと、相手はどれくらい身構えればいいのかわかりません。

母語の違う人たちが英語で一緒に働くとき、正確な単語ひとつが段落ひとつ分の働きをします。そしてPMPは世界中で同じ基準で行われる試験なので、これらの言葉は、国や会社が違っても同じ意味で通じる数少ない共通語に近いものです。

課題と変更を前にして：まず評価、まず記録

正直に言うと、実務での私の本能は「とりあえず直そう」です。試験勉強中、間違いノートに何度も書いたミスもその方向でした。原因を突き止める前に解決策を選び、影響を分析する前に実行してしまうミスです。

勉強中にNotebookLM（現 Gemini Notebook）でつくった韓国語の音声リストを見ても、同じことが言えます。タイトルに「실무 본능」（実務の本能）が2回、「PM도 틀리는」（PMでも間違える）が2回出てきます。通勤中に聴いていたこれらの音声のテーマは、結局のところ、実務の本能とPMPの正解とのギャップだったわけです。音声をどうつくり、どう聴いていたかは第7回にまとめました。

2026年6月、PMPの勉強中にNotebookLMでつくった韓国語の音声要約リストです。タイトルには「実務の本能」と「PMでも間違える」が2回ずつ入っています。

課題が起きたとき

ECでは、課題は予告なしにやってきます。リリース直後に、決済ステップでエラーの問い合わせが入りはじめたとしましょう。私の本能は、まず開発チームに「確認お願いします」と送るほうです。

最近は、そのメッセージを送る前に、まず3つのことを書き出します。

1. 影響：誰が、どこで、どれくらい影響を受けているか。すべての国なのか、特定の決済手段なのか。
2. 性質：すでに起きた課題なのか、まだ可能性にすぎないリスクなのか。
3. 知らせる人と決める人：誰が知っておくべきで、誰が判断すべきか。

書き出すのは数分で十分です。その数分が、開発チームが見当違いの場所を探すのを防ぎ、クライアントと私が同じ絵を見られるようにしてくれます。

もちろん例外もあります。決済がまるごと止まったなら、評価より復旧が先です。合格体験記の第1部で書いたとおり、PMPのマインドセットにも、差し迫った危険のように即座の対応が必要な例外があります。ただ、急ぐときほど「どこまで、なぜ」を確かめる順番だけは手放さないようにしています。

変更要求が来たとき

ECの改善案件では、小さな要望がひっきりなしに来ます。ボタンの文言ひとつ、フィルターひとつ、国をひとつ追加。一つひとつは小さく見えても、QAや翻訳、国ごとのUATにまで響くことが少なくありません。

変更管理は、私が試験勉強で何度も間違えた分野でもあります。上のリストにも「현업 PM도 틀리는 PMP 변경관리 함정」（現役PMでも間違えるPMP変更管理の落とし穴、23分34秒）があります。タイトルのとおり、現場の感覚で解くと間違えやすい分野です。

だから今は、小さな要望ほど口頭だけでOKしないようにしています。最低でも、次の5行は残します。

[変更要求] 例：商品詳細ページに配送案内バナーを追加
1. 要求：誰が、なぜ要求したか
2. 影響：スケジュール / コスト / スコープ / 品質（QA・UATのやり直し） / リスク
3. 選択肢：今回のリリースに含める / 次のリリースに回す / やらない
4. 決定権者：誰が承認するか
5. 決定：何を、いつ決めたか

PMP試験が正解として求める順番も同じです。影響を分析し、正式な手続きで承認を得て、承認されたら計画を直して共有する。最初は、細かすぎると思われないか気になることもあります。それでも記録が残っていれば、クライアントの担当者も自分の組織に変更を説明しやすくなります。変更要求書はPMを守る文書であり、クライアントの担当者を守る文書でもあるのです。

成果物より価値を問う

私の音声リストには、「버그 없는 프로젝트가 인수를 거절당한 이유」（バグのないプロジェクトが受け入れを拒否された理由）というタイトルもあります。タイトルそのものが問いになっています。バグがないのに、なぜ拒否されたのでしょうか。私がこのタイトルから読み取る答えはこうです。つくると決めたものはつくったけれど、顧客がもともと得たかったものは届けられなかった。

PMの仕事をしていると、アウトプット（output）とアウトカム（outcome）を混同しがちです。「リリースした」「機能を公開した」はアウトプットです。クライアントがお金を払った理由は、その先にあります。運用が楽になること、顧客がもっと簡単に買えること、複数の国のサイトが同じ基準で動くこと。

だから最近は、要件を受け取るときに質問をひとつ付け加えます。

これが公開されたら、誰が何を今よりうまくできるようになりますか？　それはどうやって確かめますか？

そして、その答えがUATの受け入れ基準に入っているかを確認します。機能が動くかどうかだけを確かめるUATと、もともと得たかった結果まで確かめるUATは別物です。

PMIも同じ方向に動きました。2026年に改定されたPMP試験の試験内容概要（ECO）は、PMBOKPMBOKプロジェクトマネジメント知識体系：プロジェクトマネジメント協会（PMI）が発行する標準ガイドで、プロジェクトを成功させるための主要なプロセス、ベストプラクティス、標準用語集をまとめたものです。Read More →ガイド第8版のプロジェクトの定義、つまり「価値を創出するために、固有の文脈のなかで行う有期性のある取り組み」をそのまま使っています。プロセス（Process）領域には「価値に基づくデリバリーの確保を支援する（Help ensure value-based delivery）」というタスクが新たに加わり、ビジネス環境（Business Environment）の比重は8%から26%に増えました。詳しい変化は第5回にまとめています。

ベンダーとオフショアチーム：コントロールより支援

白状すると、私の試験結果では人（People）の領域がBelow Targetでした。3つの領域のなかでいちばん低い評価だった人間が「人との接し方が変わった」と書くのは、少し気恥ずかしいものがあります。

それでも、People領域の問題で私が繰り返し間違えたパターンははっきりしていました。チームと話す前にすぐ上にエスカレーションしたり、原因を見る前に人を替えようとしたりする選択です。PMIが求める答えは正反対でした。PMはチームをコントロールする人ではなく、チームを支援し、障害を取り除く人だということです。

この視点は、所属もタイムゾーンも違うチームと働くときにこそ役立ちます。今一緒に働いているグローバルベンダーは、私の直属のチームメンバーではありません。別の会社で、別の契約のもとで働いています。Hyperhire時代には、5か国の開発者たちと、それぞれ異なるタイムゾーンで働きました。こうしたチームに「なぜ遅れたんですか？」と聞く前に、まず「何が妨げになっていますか？」と聞くこと。私は、それがサーバント・リーダーシップの出発点だと考えています。

PMが取り除ける障害は、思っている以上に具体的です。

• あいまいな要件：質問を1日以上放置せずに答えるか、答えられる人にすぐつなぐ。
• 先送りされた決定：クライアントの承認が必要なものは、相手チームの業務時間が始まる前に整理しておく。
• 権限と環境：アクセス権限、テストデータ、ステージング環境など、開発者がひとりでは解決できないものを手配する。
• 揺れる優先順位：何が先なのかを1行にまとめて共有する。

支援するというのは、基準を下げるという意味ではありません。むしろ、受け入れ基準を最初から明確に渡すことが、ベンダーにとってはいちばんの支援です。何をつくれば「完了」なのかわからないまま働くことほど、気力を奪われることはありませんから。

予測型とアジャイル、どこに何を使うかを選ぶ感覚

私が手がけてきたエンタープライズのECプロジェクトは、その性質上ハイブリッドに近いものです。ローンチ日と予算は事前に承認されて固定されることが多く、UATとリリースは決められたゲートを通過しなければなりません。一方で、ローンチ後の改善要望や運用バックログは、優先順位が絶えず変わります。

PMPの勉強を通じて身についた感覚は、ハイブリッドを「両方を少しずつ」ではなく、「どこに何を使うかを選んだ結果」として見ることです。たとえばECのプロジェクトなら、こんなふうに分けてみる価値があります。

予測型で管理するもの	アジャイルで回すもの
ローンチ日程、予算、契約上のスコープ	改善要望のバックログと優先順位
UATの日程と受け入れ基準、リリース承認	スプリント単位の開発とデモ
国ごとのロールアウトの順番	ローンチ後の安定化に関わる課題への対応

2026年に改定されたPMP試験も、約40%が予測型、60%が適応型（アジャイル）またはハイブリッドのアプローチを扱います。PMBOKPMBOKプロジェクトマネジメント知識体系：プロジェクトマネジメント協会（PMI）が発行する標準ガイドで、プロジェクトを成功させるための主要なプロセス、ベストプラクティス、標準用語集をまとめたものです。Read More →ガイド第8版では、テーラリングはもう原則のリストには入っていませんが、テーラリングの指針はそのまま残っています。私はこれを、「テーラリングはスローガンではなく、毎日下す判断だ」という意味だと受け取りました。

履歴書の一行は変わったけれど

PMPを取得してから、履歴書のいちばん上の行を「PMP® | Global Project Manager」に変えました。

2026年7月4日の未明（韓国時間）に届いたPMP取得のメールです。Credlyのデジタルバッジは1〜2週間以内に別途メールで届く、と案内されています。

グローバルな協業では、この3文字が短い自己紹介の役割を果たすと思っています。初めて会う本社の担当者や海外のベンダーにとって、PMPはだいたいこんな意味に受け取られると思います。

• 一定期間以上、プロジェクトを率いた経験がある。学士なら36か月で、PMIは無作為に監査（Audit）も行う
• PMIが定めた共通の用語と判断の枠組みを勉強している
• 3年ごとに60PDUを満たさないと資格を維持できないので、学び続けている人だ

ただ正直に言えば、まだ早いです。合格したのは7月なので、この記事を書いている時点で、まだ3か月も経っていません。だからこの記事には、「資格のおかげで起きたこと」をひとつも書きませんでした。3か月は、そういう話をするには短すぎます。

それに、資格が仕事を代わりにやってくれるわけではありません。私の履歴書に書いてある数字、たとえばグローバルな家電クライアントの運用バックログが104件から48件に減り、課題解決のリードタイムが27%短くなったことは、PMPという文字がつくった結果ではありません。現場でつくった数字です。PMPは、そうした仕事を説明する言葉を少しだけ正確にしてくれたにすぎません。

資格は会話のきっかけをつくってくれます。会話を続けさせるのは、結局のところ仕事です。

次回は、もう一歩踏み込んだ主張をしてみます。この考え方は、むしろPMではない人、つまり開発者やデザイナー、マーケターにこそ強力だという話です。年収や採用が気になる方のために、第14回では数字と韓国国内の求人をもとにまとめています。

次回：PMPは、PMではない人にこそ効く

よくある質問

PMPを取ると、実務はすぐに変わりますか？+

資格を受け取った瞬間に変わることはありません。私の場合に変わったのは、試験勉強で身につけた判断の順番が、仕事の習慣に移ってきた部分です。課題を前にしたらまず影響を評価し、変更要求は記録で受け、成果物よりも価値を問うようになりました。ただし、合格してまだ3か月も経っていない時点での話です。

PMPの正解と現場の感覚が違うというのは本当ですか？+

ある程度は本当です。実務の本能はすばやく直してすばやく決める方向に働きますが、PMPの問題は状況把握と影響分析を先に求めることが多いです。ただ、この順番は実務でも役に立ちました。決済が丸ごと止まったときのように、即座の対応が必要な例外もあるので、公式のように暗記するより、理由を理解するほうがいいでしょう。

アジャイルチームで働いていても、PMPは役に立ちますか？+

2026年に改定されたPMP試験は、約40%が予測型、60%が適応型（アジャイル）またはハイブリッドのアプローチを扱います。固定されたローンチ日程とバックログベースの改善作業が混在するハイブリッドなプロジェクトなら、どの部分を予測型にして、どの部分をアジャイルで回すかを選ぶ基準づくりに役立ちます。

履歴書にはPMPをどう書けばいいですか？+

私は履歴書のいちばん上の行をPMP® | Global Project Managerに変えました。ただ、資格名よりも、その下に書くプロジェクト経験のほうが大事だと思っています。資格は会話のきっかけをつくり、会話を続けさせるのは経験です。

参考資料

• PMI公式：PMPの案内
• PMP Examination Content Outline 2026（PDF）
• PMIブログ：PMP試験の変更について（2026年7月10日）
• PMI：PMBOK®ガイド
• PMI CCRハンドブック：資格維持の要件（PDF）