PMBOKの知識エリアとは？第6版の10領域一覧と第7版への移行【2026年版】

『PMBOKの知識エリアって、いまも10個なの？第7版で変わったと聞いて混乱している』——事業会社のPMや情シスの方から、こうした相談をよく受けます。

結論から言うと、検索で多く探されている「10の知識エリア」は、主にPMBOKガイド第6版までの枠組みです。第7版では本編の中心が「12の原理原則」と「8つのパフォーマンス領域」へ移りました。版を付けずに「PMBOKでは」と語ると、ここで噛み合わなくなります。

この記事では、第6版の10エリアを一覧で押さえ、第7版への移行を版付きで整理します。あわせて、外注やオフショア開発の発注者が「どのエリアを誰が持つか」を週次に落とす観点まで書きます。クリティカルパスの計算やWBSのテンプレートそのものは、すでに別記事があるため要点と別記事へのリンクに留めます。

私は人材業界出身で、2018年からホーチミンを拠点に、日系企業を中心に約100社の開発体制づくりを支援してきました。現場で効くのは用語の暗記より、「スコープの境界」「受入の基準」「意思決定者」を版の地図に載せて共有することです。

読み終わるころには、10エリアの一覧と第7版との関係を説明でき、発注側として確認する観点が手元に残ります。自社の体制と要件が合うかも整理したい方は、記事の後半のチェック観点を先に眺めてみてください。

PMBOKの知識エリアとは——第6版までの「何を管理するか」の地図

「知識エリア」という言葉だけ聞くと、いまのPMBOKでも同じ枠組みが続いているように聞こえます。実情は違います。検索で多く求められている知識エリアは、主に『PMBOKガイド』第6版までで使われた、「プロジェクトで管理する分野を10に分けた地図」です。

私は2018年からホーチミンを拠点に、日系企業の開発体制づくりを支援してきました。現場の会議でも、「知識エリアの話」と「パフォーマンス領域の話」が同じ机に並び、版が共有されていないまま議論が空転することがあります。用語の正しさより先に、どの版の地図を開いているかを揃える——ここが出発点です。

知識エリアは「分野」、プロセス群は「いつやるか」——2軸で読む

第6版までの整理では、プロジェクトマネジメントを次の2軸で捉えます。

知識エリアは「分野の棚」、プロセス群は「時間の流れ」です。同じ「リスク」でも、計画段階で洗い出す作業と、実行中に監視する作業はプロセス群が異なります。資格学習ではこのマトリクス(知識エリア×プロセス群)がよく出てきますが、発注者にとっては「棚の名前」が分かれば、まず週次の議題を揃えられます。

第6版では、知識エリアごとに複数のプロセスが定義され、プロセス単位で実務を組み立てる構成になっていました(第6版の枠組みとしての整理。第7版本編の中心構成とは別です)。

なぜいまも「10の知識エリア」で検索されるのか——第7版以降とのズレ

第7版(2021年)では、本編の中心が「12の原理原則」と「8つのパフォーマンス領域」へ移りました。それでも「pmbok 知識エリア」「pmbok 10の知識エリア」の検索が続く理由は単純です。社内研修・過去の教材・ベンダーの説明資料が第6版語彙のまま残っているからです。

ここで失敗のもとになるのが、「PMBOKでは知識エリアが10個」と版なしで言い切ることです。第7版本編を開いている相手には通じません。逆に、第6版の地図を共有したい相手に第7版の原則だけを並べても、チェックリストが作れません。版を必ず付ける——これが本記事の約束です。

この記事の範囲——一覧と版の整理。計算やテンプレは既存記事へ

本記事が扱うのは次の3つです。

1. 第6版の10知識エリアの一覧と意味
2. 第7版への移行(8パフォーマンス領域・12原理原則)
3. 発注者(事業会社のPM・情シス)が外注・オフショアで使う読み方

次の各論は、既存記事に譲ります。要点だけ触れて別記事へ送ります。

• 工程ネットワーク上の最長経路の計算 → 『クリティカルパスとは』の記事
• WBSの列設計や記入例 → 『WBSテンプレート』の記事
• 進捗の測り方・報告の粒度 → 『進捗管理とは』の記事
• 体制図の書き方 → 『プロジェクト体制図』の記事

では、第6版の10エリアの中身に入ります。

第6版の10の知識エリア——一覧と、発注者が最初に見るポイント

第6版までの知識エリアは、次の10です。名前の揺れ(「プロジェクト・」の有無、中黒の有無)は資料によってありますが、指している分野は同じです。ここでは発注者が週次で使いやすい短いラベルと、着眼点を並べます。

10エリアの一覧表(名称・ひとこと・発注者の着眼点)

この表が「地図」です。次に、発注の現場で詰まりやすい塊ごとに補足します。

統合・スコープ・スケジュール・コスト——QCDの骨格

統合マネジメントは、他のエリアを横断して計画・実行・変更を一つのプロジェクトとして束ねる領域です。発注側で起きやすいのは、現場は仕様を直し続けているのに、契約上のスコープや予算の更新手続きが後追いになることです。変更の入口を一本化しないと、あとから「いつ決まったのか」が追えない——要注意です。

スコープ・マネジメントは「何を作るか／作らないか」の境界です。発注者が最初にやるべきは、合否を判定できる言葉に落とすことです。「使いやすく」では判定できません。「ログイン後3秒以内に一覧が表示される」のように測れる形へ寄せます。作業の分解(WBS)はスコープを具体化する道具ですが、列の設計や記入例は『WBSテンプレート』の記事に譲ります。

スケジュール・マネジメントは、作業の順序・見積もり・進捗の期限を扱います。ここでよく出てくるのがクリティカルパス(最も長い経路が最短期間を決める、という考え方)です。計算の手順やフロートの出し方は『クリティカルパスとは』の記事に譲り、本記事では「遅れが全体に効く依存を、発注者と開発側で同じ図で見ているか」だけを確認ポイントにします。

コスト・マネジメントは、予算の計画と実績の差です。システム開発の外注では、費用＝人月×人月単価×期間＋諸経費、という構造で読むのが実務的です。単価の深掘りは相場記事に任せ、ここでは「前提(人数・期間・役割)が見積もり間で揃っているか」を見ます。

品質・資源・コミュニケーション——人と成果物のつなぎ

品質マネジメントは、要求を満たす成果物と、そのためのプロセスです。発注者が握るべきは受入基準です。UAT(受入テスト)は発注側の工程である、という整理が現場では効きます。開発会社側では、設計レビュー、プルリクエストによるコードレビュー、リリース前のダブルチェックなど、「人の頑張り」ではなく仕組みで品質を見るのが実情です。

資源マネジメントは、人財・機材・環境の確保です。オフショアでは「何名が、どのスキルで、いつから稼働するか」が資源の本体になります。名前のない「チーム一式」だけだと、交代が起きたときに影響が見えません。

コミュニケーション・マネジメントは、誰に・何を・どの頻度で・どのチャネルで伝えるかの設計です。時差がある拠点では、同期会議を増やすより、決定事項の文書化とチケット上のやり取りの型を先に決めた方が崩れにくいです。進捗の測り方や報告粒度そのものは『進捗管理とは』の記事へ送ります。

リスク・調達・ステークホルダー——外に開く3領域

リスク・マネジメントは、起こりうる脅威と機会を特定し、対応を決める領域です。発注側で最低限ほしいのは、「上位リスクにオーナーの名前が付いている」状態です。一覧だけあって担当がいないと、週次で誰も動かないままになります。

調達マネジメントは、外部からの製品・サービス・人財の獲得と契約です。システム開発の外注そのものが調達です。請負なのか準委任(ラボ型など)なのか、完成責任の有無、再委託の扱い——ここが曖昧だと、あとから「誰の責任か」で揉めます。契約類型の比較は既存の契約系記事に譲り、本記事では「調達＝外注の条件を、スコープと品質の言葉と揃える」ことだけ強調します。

ステークホルダー・マネジメントは、影響を与える／受ける個人・組織との関わりです。第6版では独立した知識エリア(第13章)として置かれ、第7版でもステークホルダーは原則・領域の双方に残る重要なテーマです。発注者が最初に書くべきは、意思決定者・業務の当事者・拒否権を持つ部署の名前です。箱だけの体制図は『プロジェクト体制図』の記事で直すとして、ここでは「名前と権限」を先に置く、と覚えます。

10エリアは覚えるための暗記カードではなく、週次で穴を見つける棚です。次に、第7版でこの棚がどう再編されたかを版付きで見ます。

第7版への移行——8つのパフォーマンス領域と12の原理原則

第7版で何が変わったかを一文で言うなら、「『何のプロセスを実行するか』中心から、『どんな原則で振る舞い、どのパフォーマンス領域で成果を出すか』中心へ移った」です。知識エリアの中身が無意味になった、という意味ではありません。本編の見出しの立て方が変わった、と読むのが実情です。

第7版本編で知識エリアはどう扱われるか

第7版の本編では、第6版のような「10の知識エリア」を章立ての主軸にしていません。代わりに次が前面に出ます。

• 12の原理原則(Principles)
• 8つのプロジェクト・パフォーマンス領域(Project Performance Domains)
• テーラリング(状況に合わせて合わせ込む考え方)
• モデル・手法・作成物の例示

プロセスの詳細な一覧は、第7版の時代には別冊の『プロセス群実務ガイド』(Process Groups: A Practice Guide)側で扱われる、という整理が一般的です。したがって、「第7版を読んでいるのに知識エリアが出てこない」のは異常ではなく、版の設計どおりです。逆に、社内がまだ第6版の地図で動いているなら、無理に第7版語だけに寄せず、対応関係を併記するのが安全です。

8つのパフォーマンス領域(PMI公開資料の名称)

PMIが公開しているパフォーマンス領域の説明資料では、プロジェクト・パフォーマンス領域を「成果の効果的なデリバリーに不可欠な、関連する活動のグループ」と定義しています。8つの名称は次のとおりです(英語表記はPMI資料に合わせます)。

第6版の知識エリアとの対応は一対一ではありません。例として、ステークホルダーは領域としても残り、スケジュールやコストの論点はデリバリーや計画・測定の側に散らばって見える、といった読み方になります。対応表を暗記するより、「第6版の棚の中身は、第7版では領域をまたいで再配置された」と捉える方が実務では崩れにくいです。

12の原理原則とテーラリング——「全部やる」から「合わせる」へ

第7版の原理原則は、規範のチェックリストというより、振る舞いの指針です。日本語資料でよく併記される12は、おおむね次の方向性です(細部の訳語は版・訳本で揺れるため、学習時は公式・認定教材の表記に合わせてください)。

1. 誠実で敬意あるスチュワードであること
2. 協働的なチーム環境をつくること
3. ステークホルダーと効果的に関わること
4. 価値に焦点を当てること
5. システムの相互作用を認識し対応すること
6. リーダーシップを示すこと
7. 状況に基づきテーラリングすること
8. プロセスと成果物に品質を組み込むこと
9. 複雑さに対処すること
10. リスク対応を最適化すること
11. 適応力と回復力を持つこと
12. 目指す将来状態に向け変革を可能にすること

発注者にとって効くのは、特に「価値」「ステークホルダー」「テーラリング」「品質」です。アジャイル開発では、予測型の全プロセスをそのまま外注先に押し付けるとオーバーヘッドになります。手法そのものは『スクラムとは』『ウォーターフォール開発とは』『アジャイル開発の外注』の記事に譲り、ここでは「第7版は、やり方をプロジェクトに合わせることを正面から求めている」と押さえます。

第6版の語彙は消えない——対応の考え方(概念対応)

現場では、次の併記が一番トラブルが少ないです。

• 学習・社内共通言語が第6版なら、10知識エリアの棚で週次を切る
• 相手が第7版語なら、同じ論点をパフォーマンス領域の言葉に言い換える
• 「PMBOKでは」と言わず、「第6版では」「第7版では」と言う

第8版(PMIストア表記では2025年11月刊行)以降も枠組みは進化していますが、検索者がいま求めている主戦場は、依然として第6版の10エリアと第7版への移行です。本記事もそこに紙幅を使います。第8版の細部(ドメイン数やプロセスの再掲など)は、公式の最新版と学習教材で確認してください。

では、発注者として知識エリア(と第7版の領域)を、外注の現場でどう使うかを見ます。

発注者が知識エリアを使う場面——外注・オフショアでの読み方

用語を暗記しても、週次の議題が「進捗どうですか」だけなら、知識エリアは仕事になりません。発注者に必要なのは、第6版の棚(または第7版の領域)を、確認項目に落とすことです。

週次で確認する5点——スコープ境界、優先順位、依存、受入、意思決定者

オフショアやラボ型で並走するとき、発注側の週次は次の5点で足りることが多いです。

優先順位の判断を発注側が手放すと、開発側は「全部大事」のまま進みます。介護SaaSの事例でも、週次で優先順位を決める運用が効いた、というのが当社の現場感です。依存の話が出たときにクリティカルパスの計算までその場でやる必要はありません。図の共有と「どこが最長経路か」の合意があればよく、計算手順は『クリティカルパスとは』の記事へ送ってください。

誰がどのエリアを持つか——発注側に残す判断と、任せてよい作業

全部の知識エリアを発注側の一人が持つ必要はありません。向かない持ち方を正直に書くと、次のとおりです。

• 発注側に残しやすい: スコープの優先順位、ステークホルダーの意思決定、受入の合否、予算の上限
• 開発側に任せやすい: 資源の詳細アサイン、実装品質のレビュー運用、日々のコミュニケーション設計の実行
• 両方で持つ: リスク(オーナーは名前付き)、調達(契約条件は発注、作業分解は開発)

丸投げで判断まで渡すと、検収で揉めます。逆に、実装の細部まで発注側が指揮すると、準委任でも運用が壊れます。指揮命令の線引きは契約記事に譲り、ここでは「判断は発注、作り方の実行は開発」を知識エリアの言葉で固定します。

体制の箱と線の引き方は『プロジェクト体制図』の記事、進捗の単位は『進捗管理とは』の記事を参照してください。

当社の位置づけ——日本人PMが統合・コミュニケーションの窓口、向く案件と向かない案件

TALENTBASE VIETNAMでは、推奨体制として日本人PM/BrSEをフロントに置き、ベトナムのエンジニアが実装を担う形を取ることが多いです。知識エリアに落とすと、次の分担になります。

• 日本人PM: 統合・コミュニケーションの窓口、要件の文書化、週次の優先順位の整理、品質レビューの設計
• エンジニア: 資源としての実装、品質のコードレビュー運用への参加
• 発注者: ステークホルダーとしての意思決定、スコープの優先順位、受入

時差はベトナムと日本で2時間です。同期会議を増やしすぎず、決定を文書に残すコミュニケーション設計と相性がよい、というのがホーチミン拠点での実感です。最小構成の目安としては、日本人PMフロント＋エンジニア数名から始める形が多く、継続的な改修・機能追加がある案件と相性がよいです。

向く案件: 要件が動き、同じチームで継続開発したい。発注側に優先順位を決める担当がいる(またはPM付きで補える)。

向かない案件: 要件が完全に固まった単発の請負向き案件を、知識エリアの勉強のためにラボ型へ無理に載せる場合。用語の学習だけが目的で、開発の発注意図がない場合。

知識エリアは、発注の会話を「同じ棚」に載せるための地図です。次に、よくある質問で版と役割の残りを整理します。

PMBOKの知識エリアでよくある質問

ここでは、検索と現場で繰り返し出る疑問に絞って答えます。版の扱い、覚え方、外注での役割分担、アジャイルとの関係、第8版をどう見るか——の5問です。

Q1. 第7版でも「10の知識エリア」はそのまま使いますか？

第7版の本編では、知識エリアを主軸にしていません。中心は12の原理原則と8つのパフォーマンス領域です。一方で、第6版の語彙は社内・ベンダー・教材に残っており、実務の会話では併記が普通です。「第7版だから10エリアは禁止」ではなく、「どの版の地図で話すかを先に決める」が答えです。

Q2. 10の知識エリアは、どの順番で覚えればよいですか？

発注者なら、統合→スコープ→ステークホルダー→品質→スケジュール→コスト→リスク→コミュニケーション→資源→調達、の順が現場に落ちやすいです。資格試験の学習順は教材に従ってください。暗記より、週次の5点(境界・優先順位・依存・受入・意思決定者)に結び付ける方が忘れません。

Q3. 外注するとき、知識エリアは発注者と開発会社のどちらが持ちますか？

両方です。判断(優先順位・受入・意思決定・予算)は発注側、実行(資源の詳細・日々のコミュニケーション運用・実装品質の仕組み)は開発側、が基本です。統合とコミュニケーションの窓口を日本人PMに置く体制なら、発注側は優先順位と受入に集中しやすくなります。全部を片方に寄せるのは失敗のもとです。

Q4. アジャイル開発でも知識エリアは使えますか？

使えますが、第6版の全プロセスを予測型のまま押し込む必要はありません。第7版のテーラリングの考え方がここで効きます。スクラムのイベントや作成物の詳細は『スクラムとは』の記事、外注での回し方は『アジャイル開発の外注』の記事を参照し、知識エリアは「何を管理するかの棚」として軽く使います。

Q5. 第8版が出たあと、第6版の10知識エリアは学ぶ意味がありますか？

あります。検索と現場の共通言語として、第6版の10エリアはまだ広く使われているからです。第8版の詳細構成は公式の最新版で確認し、本記事では第6版の一覧と第7版への移行を主戦場にした、という整理。

まとめ: 第6版の10エリアを地図にし、第7版は原則と領域で読み替える——発注者は「誰が持つか」まで落とす

PMBOKの「知識エリア」は、主に第6版までの「何を管理するか」の10分野です。いま検索されている人も、まずはこの一覧を求めています。第7版では本編の中心が12の原理原則と8つのパフォーマンス領域へ移ったので、「PMBOKでは」と版なしで語らないことが、混乱を防ぐ最短ルートです。

発注者にとっての使い方は、暗記ではなく週次です。スコープの境界、優先順位、依存、受入、意思決定者——この5点を、第6版の棚(または第7版の領域)に載せて共有してください。計算やテンプレートの各論は、すでに整理した記事へ送るのが効率的です。

クリティカルパスとは WBSテンプレート

現在の体制と要件をお聞かせいただければ、知識エリアの分担が自社に合うかも含め、概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。