まいどおおきに、ASAKURAの朝倉です。

今日はPMBOK（ピンボック）の話を書きます。

プロジェクトマネジメントの知識体系をまとめた、世界標準とされているガイドです。

なぜ今この話かというと、2025年11月に第8版の英語版が出たからです。第7版が2021年ですから、わずか4年での改訂になります。しかも中身がかなり変わりました。

日本語版については、2026年4月14日にPMI会員向けの日本語デジタル版が出ています。ただし一般向けの正式な書籍としての流通時期については情報が分かれており、9月以降になるという見方もあります。私が読み始めた時点では英語版しかなかったので、必要な部分を訳しながら読みました。

この記事は、その作業で気づいたことの記録です。加えて、私自身がクライアントの現場でPMBOKをどう使っているか、そしてどこは使っていないかを書きます。

先に立場を明かしておきます。私はPMBOKを、そのまま中小企業に持ち込むべきものだとは思っていません。あれは大企業の、専任のプロジェクトマネージャーがいて、数十人規模のチームが動く前提で書かれた本です。従業員12人の会社にそのまま適用したら、資料を作るだけで案件が終わります。

PMBOKとは何か、そして第8版で何が変わったのか

まず前提を揃えます。

PMBOKは、米国のPMI（Project Management Institute）が発行しているプロジェクトマネジメントの知識体系ガイドです。正式名称は A Guide to the Project Management Body of Knowledge。PMPという国際資格の参考図書としても知られています。

版によって構成が大きく違うので、そこを押さえないと話が噛み合いません。

版	発行	構成の考え方	一言でいうと
第6版	2017年	10の知識エリア × 5つのプロセス群	手順が細かく書いてある
第7版	2021年	12の原理・原則 × 8つのパフォーマンス領域	手順を捨てて考え方だけにした
第8版	2025年	6つの原則 × 7つの領域 ＋ フォーカスエリアとプロセスの復活	6版と7版の統合

第7版は、それまでのプロセス中心の構成を廃止して、原則ベースの構成に一新した版です。かなり思い切った改訂でした。ところが現場からは「抽象的で実務に落としづらい」という声が多く出ていました。

第8版は、この第7版の原則ベースを維持しつつ、第6版までのプロセスベースの実用性を再統合した改訂です。分かりやすく言えば、第7版が「なぜ」で、第6版が「どうやって」。第8版はその両方を1冊にした、ということになります。

主な変更点は3つです。

原則が12から6に集約されました。第7版の12原則は網羅的である一方、相互の重複が指摘されていました。第8版では実務の判断に使いやすい6つに統合されています。

パフォーマンス領域が8つから7つに再定義されました。

そして、プロセス群がフォーカスエリア（Focus Areas）と名称を変えて再導入されました。立上げ、計画、実行、監視・コントロール、終結という5つの区分自体は変わっていません。第6版にあった対応表も、プロセス群とパフォーマンス領域の対応表として復活し、そこには40のプロセスが設定されています。

もう1つ、地味ですが大きい変更があります。プロジェクトの定義そのものが変わりました。「成果物を作る」から「価値を生み出す」という目的重視の表現になっています。これは第2版から第7版まで27年間変わっていなかった箇所です。

訳して、引っかかった言葉

ここからが本題です。個人的に引っかかった言葉を挙げます。

Value（価値）

第8版の中心概念です。ところが、これほど訳しやすくて理解しにくい言葉もありません。

「価値」と訳せば1秒で済みます。しかし日本語の「価値」は、日常だと「価値がある／ない」という漠然とした善し悪しの意味で使われます。PMBOKが言っているのは、もっと具体的な「誰にとっての、何の便益か」です。

現場で「このプロジェクトの価値は何ですか」と聞くと、たいてい「業務効率化です」という答えが返ってきます。これは価値の記述ではありません。手段の記述です。価値の記述にするなら、「経理担当者の月次締め作業が3日から半日になり、その分を請求漏れのチェックに回せる」まで具体化する必要があります。

訳しながら思ったのは、第8版が定義を変えてまでValueを前面に出したのは、この混同が世界中で起きているからだろう、ということです。

Outcome と Deliverable

これも日本語だとどちらも「成果」で片づけられがちですが、まったく別のものです。

Deliverableは納品物。作って渡すもの。システム、報告書、マニュアル。 Outcomeは、それによって起きた変化。使われた結果、何がどうなったか。

日本のシステム開発の現場で「納品して検収されたら終わり」という慣行が根強いのは、この2語が区別されていないことと無関係ではないと思っています。納品物は完成しているが、成果は出ていない。この状態を指す言葉が、日本語の商習慣の中に用意されていないのです。

私はクライアントとの打ち合わせで、この2つを意図的に言い分けています。「納品物としてはこれ、変化としてはこれ」と。訳語としては「納品物」と「もたらされる変化」くらいに開いて言うほうが伝わります。

Stewardship から Accountable Leader へ

第7版の原則にStewardshipという語がありました。日本語版では「スチュワードシップ」とカタカナのままだった箇所です。管理を任された者としての責任、くらいの意味ですが、日本語に定着した訳語がありません。

第8版では、6原則の中に「責任あるリーダーであること（Be an Accountable Leader）」という形で整理されています。こちらのほうが行動として何をすべきかが読み取りやすい。

Accountabilityも訳しにくい語です。「説明責任」と訳されますが、本来は「結果に対して負う責任」であって、説明することそのものが責任なのではありません。日本語の「説明責任」は、どこか「聞かれたら答える義務」というニュアンスに寄っていて、能動性が抜け落ちています。

Empowered Culture（自律的な文化）

第8版の6原則の1つに、チームの信頼と心理的安全性に関わる原則が入っています。

正直に書くと、私はこの手の言葉に対して、やや醒めた見方をしています。「心理的安全性のある組織を作りましょう」と提言して実現するなら、誰も苦労しません。

ただし、訳しながら考えが少し変わりました。この原則が言っているのは、文化を作れという指示ではなく、「文化が悪い状態で、手順だけ整えても成果は出ない」という警告として読むほうが正確です。それなら実務的です。実際、報告が上がってこない現場に週次報告のフォーマットを配っても、空欄が増えるだけです。

Tailoring（テーラリング）

これが、中小企業支援をしている人間にとっては最重要の概念です。

意味は、プロジェクトの状況に合わせて手法や手順を調整すること。洋服の仕立て直しと同じ語源です。

PMBOKは「全部やれ」とは一度も言っていません。テーラリングして使え、と明記されています。ところが、これが日本の現場では驚くほど実行されていない。理由は単純で、削る判断には、全体を知っている必要があるからです。知らない人は削れないので、全部やるか、全部やらないかの二択になります。

Focus Areas（フォーカスエリア）

プロセス群の名称変更です。これは訳語というより、名称変更の意図が興味深い。

「プロセス群」だと、順番に通過するゲートのように見えます。「フォーカスエリア」なら、その時期に重点的に注意を向ける対象、というニュアンスになります。同じ5区分（立上げ、計画、実行、監視・コントロール、終結）でも、受け取られ方が変わります。

ウォーターフォールを前提とした読まれ方を避けたかったのだろう、と私は解釈しています。実際、反復型の開発でも、それぞれの反復の中に5つの重点は存在します。

持論：PMBOKをどう評価しているか

ここは完全に私見です。

良いと思っている点

網羅性が抜群です。プロジェクトで起こりうる問題が、ほぼすべて分類されています。自分の抜け漏れをチェックするリストとして、これに勝るものを私は知りません。

そして共通言語になります。これが実は最大の価値だと思っています。「ステークホルダー」「スコープ」「リスク登録簿」といった語彙が共有されていると、議論が驚くほど速く進みます。語彙がないと、同じことを毎回説明することになります。

限界だと思っている点

そのままでは重すぎます。第8版で40のプロセスが復活しましたが、これを全部回せる中小企業のプロジェクトはまずありません。回そうとした瞬間に、管理コストがプロジェクト本体を超えます。

もう1つ、これは批判というより構造の問題ですが、PMBOKは「プロジェクトが承認されている」ところから始まります。しかし中小企業の現場で最も難しいのは、そのプロジェクトをやるべきかどうかの判断です。そこはPMBOKの守備範囲の外にあります。

そして、資格と実務の乖離という問題もあります。PMPを持っていることと、実際にプロジェクトを立て直せることは、まったく別の能力です。これはPMBOKの責任ではなく、資格というものの性質ですが、発注側は知っておいたほうがいい話です。

第7版から第8版への揺り戻しについて

私が第8版でいちばん興味深いと思ったのは、この改訂が事実上の方向転換だという点です。

第7版はプロセスを捨てました。理想としては正しかったと思います。手順に縛られず、原則に立ち返って考える。しかし現場は「抽象的で使えない」と反応しました。そして4年で戻ってきた。

ここから学べることは、PMBOKの中身以上に大きいと思っています。

抽象度の高い原則は、それを具体に落とせる人にしか使えません。落とせる人は、たいていすでにできている人です。つまり、原則だけを提供する支援は、支援が必要な人には届かない。

これは私たちの仕事にもそのまま当てはまります。クライアントに「顧客視点で考えましょう」と言って何かが変わることはありません。「明日、この3人に電話して、この3つを聞いてください」まで下ろして初めて動きます。第8版は、PMI自身がそれを認めた版だと私は読んでいます。

コンサルティングでどう使っているか

場面1：発注前の見積レビュー

いちばん多い使い方です。クライアントがベンダーから受け取った見積書を一緒に見ます。

このとき、PMBOKの知識エリアやパフォーマンス領域を、抜け漏れのチェックリストとして頭の中で走らせます。

見る観点	具体的に確認すること
スコープ	何を作るかだけでなく、何を作らないかが書いてあるか
スケジュール	発注者側の作業（原稿提供、テスト、承認）の期間が入っているか
コスト	保守、追加開発の単価、期間終了後の費用が見えているか
品質	検収の基準は何か。誰がどう判断するのか
ステークホルダー	誰の承認が必要か。それは誰が調整するのか
リスク	遅延したときの扱い、仕様変更の手続きが定義されているか
調達	契約形態は請負か準委任か
コミュニケーション	定例の頻度、報告の形式、緊急時の連絡先

見積書に書かれていない項目を見つけるのが目的です。書かれていないものは、後で揉めます。

実際、いちばんよく抜けているのはスケジュールの「発注者側の作業」です。3か月で完成という見積の中に、クライアントが原稿を用意する2週間や、テストする1週間が含まれていない。そして遅れると、なぜか発注者のせいになります。

PMBOKを読んでいなくてもこれには気づけますが、体系があると漏れなく、しかも短時間で確認できます。会議中に思い出せるかどうかは、体系を持っているかどうかで決まります。

場面2：キックオフでの前提合わせ

案件が始まるとき、最初の打ち合わせで決めることをPMBOK由来の枠組みで整理します。ただし、使う道具は思い切って絞ります。

私が中小企業の案件で実際に作るのは、この6つだけです。

作るもの	PMBOKでの対応	中小企業版の形
プロジェクト憲章	Project Charter	A4半ページ。目的、完了の定義、体制、予算枠、期限
ステークホルダー一覧	ステークホルダー登録簿	表1枚。名前、役割、承認権限の有無、関心事
スコープの線引き	スコープ記述書	やることリストと、やらないことリスト
リスク一覧	リスク登録簿	上位5件だけ。影響、対応方針、担当
課題管理表	Issue Log	スプレッドシート1枚。起票日、内容、担当、期限、状態
教訓の記録	Lessons Learned	案件終了時に30分。次回に効くことだけ

これ以上は作りません。作っても更新されないからです。更新されない管理表は、存在しないより有害です。「管理している」という誤った安心を生むので。

とくに効くのは、上から3つ目の「やらないことリスト」です。

日本の商習慣だと、やらないことを明示するのは失礼だという感覚があります。しかし実際には、これを最初に書いておくと信頼が増します。「ここまではやります、ここからは別途です」と明確に言われたほうが、判断できるからです。曖昧にしておいて後から「それは別料金です」と言うほうが、よほど関係を壊します。

場面3：止まっている案件の立て直し

途中で止まってしまった案件に、途中から入ることがあります。

このとき最初にやるのは、原因の分析ではありません。用語の統一です。

止まっている案件では、ほぼ例外なく、同じ言葉が違う意味で使われています。「完了」が、ベンダーにとっては「実装が終わった」で、クライアントにとっては「本番で使える」だったりする。「テスト」が、片方は動作確認で、もう片方は業務での試用だったりする。

議論が噛み合わないまま何往復もして、双方が相手を不誠実だと思い始めた頃に、私が呼ばれます。

ここでPMBOKの語彙が効きます。中立的で、どちらの立場のものでもない定義が既に存在しているので、「PMBOKではこう定義されています」と言うだけで、感情から切り離して議論を再開できます。

これは知識の価値というより、第三者の共通基準を持ち込める価値です。私がその場で作った定義だと「朝倉さんの解釈」になりますが、国際標準なら「決まっていること」になる。実務上、この差は大きいです。

使わないと決めていること

逆に、私が中小企業の案件で使わないものも書いておきます。

WBSを何階層にも展開すること。人数が少ないプロジェクトでは、階層を深くするほど管理コストが跳ね上がります。2階層で止めます。

アーンドバリューマネジメント（EVM）。進捗と予算を数値で管理する手法ですが、成立には正確な工数の記録が必要です。兼務だらけの現場では工数が正確に取れないので、数値が意味を持ちません。

各種の詳細な計画書。品質マネジメント計画書、コミュニケーションマネジメント計画書、リスクマネジメント計画書。大企業なら必要ですが、12人の会社で作れば、読む人が誰もいない文書が増えるだけです。必要な要素は、プロジェクト憲章のA4半ページに畳み込みます。

これがテーラリングです。そして削る判断ができるのは、全体を知っているからです。だから読む価値があります。

架空のA社で説明すると

当社のコラムで一貫して登場していただいているA社（三重県のリフォーム会社、年商1.2億円、従業員12名）に、また出てきてもらいます。

A社が工程管理アプリを外注するとします。見積は600万円、期間は6か月。

PMBOKをそのまま適用したら、計画フェーズだけで数十の文書ができます。A社の担当者は現場監督との兼務です。無理です。

私が実際にやるのは、次のことです。

まず、A4半ページの憲章を一緒に書きます。この案件の完了とは何かを1文で定義します。たとえば「職人7名が全員、毎日アプリで進捗を入力している状態」。納品ではなく、使われている状態を完了と定義するのがポイントです。第2章のOutcomeの話がここに効いています。

次に、承認できる人を確定します。A社の場合、社長と、現場の責任者と、事務担当。この3人以外の要望は、いったん3人を経由させます。これをやらないと、職人さん一人ひとりの「こうしてほしい」が直接ベンダーに届いて、収拾がつかなくなります。

やらないことリストを書きます。「今回は見積機能を含まない」「既存の会計ソフトとの連携は次期」。ここが最も揉める箇所なので、契約前に書面にします。

リスクは5件だけ挙げます。A社なら、たとえば職人さんがスマートフォンの操作に不慣れであること、繁忙期にテストの時間が取れないこと、現場が電波の弱い場所にあること。それぞれに対応方針を1行ずつ書きます。

そして、4週間ごとに動くものを触る会を設定します。これはPMBOK由来というよりアジャイルの発想ですが、第8版はハイブリッドを許容しているので、堂々と混ぜて構いません。

作る文書は、合計でスプレッドシート2枚とA4半ページ。これで足ります。

中小企業がPMBOKに触れるときの注意点

3つあります。

1つ目。原著を最初から読む必要はありません。分厚いです。第8版は第7版よりさらにページが増えています。目次を眺めて、いま困っている領域だけ拾い読みするのが実用的です。

2つ目。資格取得と実務は分けて考えてください。PMPの取得を目的にするなら試験範囲（ECO）に沿った学習が必要ですが、実務で使うだけなら、語彙と枠組みを知っていれば十分です。

3つ目。導入すると決めた瞬間に、目的がすり替わりやすい。「PMBOKに準拠する」ことが目的になると、文書作成が仕事になります。目的はプロジェクトを成功させることであって、準拠することではありません。

私自身の使い方を一言でまとめると、辞書として使う、になります。通読して暗記するものではなく、必要なときに引く。そして引いた内容を、目の前の会社の規模に合わせて削って渡す。

まとめ

体系を学ぶ価値は、その体系を実行することにあるのではありません。何を捨てていいかを判断できるようになることにあります。

全部やろうとする人は、たいてい全体を知りません。知らないから削れない。逆に、全体を知っている人ほど、目の前の状況に対して大胆に削ります。

国際標準を読んで、12人の会社にはスプレッドシート2枚で足りますと言えるのは、その2枚が何を代替しているかを知っているからです。何も知らずに2枚で済ませるのとは、見た目が同じでも中身がまったく違います。

これはあくまで、僕の解釈ですが。