実際のプロジェクトでどう活用する？PMBOKとの上手な付き合い方

Masataka Muto
2021.12.10

※本記事は、基本的にPMBOK®ガイド第6版の内容をもとに記載しています。

こんにちは、プロジェクトマネージャーの武藤です。

プロジェクトマネージャー（以下PM）やディレクターの方は、PMBOKについて学んだり実践する機会があるかと思います。しかし実際の業務の中でプロジェクトマネジメントを行っていると、どれくらい忠実にPMBOKに沿ってプロジェクトを進めるべきか、迷ったことはないでしょうか？

PMBOKはプロジェクトマネジメントにおいて基礎であり有効なフレームワークです。一方で、実際のプロジェクトを進める際に、PMBOKを意識的に活用することは意外と難しいです。

本記事では、自分自身の経験も踏まえ改めてPMBOKについて再整理しつつ、PMBOKをどのように扱うべきかをまとめてみました。

PMBOKとの出会い

私自身のことを少しお話しすると、この業界で仕事を始めた頃はWebディレクターとして広告代理店系の案件を中心に仕事をしていました。時代の変化とともにプロジェクトの規模も大きくなり、いつのまにかPMという職種に変わり、当時はとにかく根性と勘で乗り切っていました。そんな中、「Webプロジェクトマネジメント標準」などPMBOKについて分かりやすく整理された書籍をいくつか見つけました。そのとき、「自分がやろうとしていることはこれなのだ」と、一つの目指す方向性を見つけたことで、とても安心した記憶があります。

また誰かに、どんな考えでPMをしているのかと問われれば「PMBOKを基本に」と答えていましたが、それはPMの合言葉のようなものでもあり、決してPMBOKに沿ってプロジェクトマネジメントをしているということではありません。

実際のプロジェクトは有機的であり生モノですから、フレームワークに沿った仕事はほとんど存在しません。私自身もフレームワークにとらわれすぎて逆にプロジェクトを管理しにくくなった経験もあったので、改めてPMBOKの扱い方や距離感について意識するようになりました。

QCDとPMBOKの関係

プロジェクトマネジメントの考え方やナレッジの中にQCDとPMBOKは頻繁に出てくるため、混同してしまうこともあると思います。
どちらも重要ですが、QCDとPMBOKの関係性は、プロジェクト管理のゴールであるQCDという結果を達成するために、PMBOKというフレームワークで網羅的に管理して、成功に導くことだと言えます。

また、QCDの項目Quality（品質）・Cost（コスト）・Delivery（納期）自体も、PMBOK内に品質マネジメント・コストマネジメント・タイムマネジメントという、QCDと同じ項目を意味するものがあります。そのため、PMBOK内でも特に重要度が高い項目になっています。

QCDについてはこちらの記事でも詳しく紹介しています。

QCDを達成するための、5個のプロセス群と10の知識エリア

PMBOKには、QCDを達成するための5個のプロセス群と10の知識エリアがあります。

最新の第7版では大幅に項目が変更になっていますが、当然ながら、今までの考えがいきなりなくなるわけではありません。これまでとこれからを合わせて確認することで、ビジネス変化によって、どういった考え方や能力が求められているかをより理解しやすくなると思います。

5個のプロセス群

PMBOKでは、5個のプロセス群によってプロセスをいつ実行するかを定めています。5つのプロセス群は、開始から終了までの流れを表しており、その間にマネジメントで実行すべきことを表しています。

プロジェクトの立上げプロセス群
プロジェクトの計画プロセス群
プロジェクトの実行プロセス群
プロジェクトの監視・コントロール・プロセス群
プロジェクトの終結プロセス群

10の知識エリアに目が行きがちですが、5個のプロセス群もプロジェクトマネジメントにおいて非常に重要なポイントなので、押さえておきましょう。

10の知識エリア

プロジェクト統合マネジメント

プロジェクト統合マネジメントとは、10の知識エリアを立ち上げ、計画、実行、監視・管理、終結の5つのプロセス群から統合的に管理することを求められます。プロジェクトマネジメントそのものであり、各プロセスに対する司令室のようなイメージです。
ここでは、それぞれの知識エリアを個別で管理しながらも、連動して全体として効果的に機能するために連結しなががら、調整をすることになります。

プロジェクト・スコープ・マネジメント

プロジェクトの範囲を言語化・可視化して、「やることとやらないこと」をステータスホルダー間で認識のズレがないように定めることが求められます。
個別の知識エリアで見ると、絶対におろそかにしてはならない最重要項目と言えます。

プロジェクト・スケジュール・マネジメント

「いつまでに誰がなにをやるのか」を、論理的に作業分解した上で、依存関係を把握し、期間を見積り、プロジェクトメンバーと相談しながら、現実的なスケジュールと作業担当者を決めていきます。

プロジェクト・コスト・マネジメント

プロジェクトの現実的な予算を設定し、予算内に目標を達成できるように稼働実績を把握することが必要です。主な算出方法には、類似プロジェクトに基づく見積法や要素分解プロセス分解による見積法などがあります。

プロジェクト品質マネジメント

クライアントの要求を的確に捉え、その要求通りに作れているかを管理します。また、バグやエラーなどの欠陥がないかをどうやって保証するかをプロセスとしてあらかじめ考えることも重要になります。

プロジェクト資源マネジメント

アサイン計画とリソース管理のみならず、メンバーの能力や特性を理解して、プロジェクトチームとしてどういった配慮が必要なのかを考えることが求められます。メンバー間のモヤモヤをなるべく解消し、チームワークとパフォーマンスを高めていくことがポイントになります。

プロジェクト・コミュニケーション・マネジメント

異なる立場のステークホルダー間で認識の相違が発生させないために、どのようにコミュニケーションの交通整理をするかを考えます。
関与するメンバーの人数が多い場合には、パターンが複雑化し情報量が多くなるため、より明確なルール化が必要になります。
後から必要な情報にアクセスしやすいように考えることも重要です。

プロジェクト・リスクマネジメント

問題になりそうなことをあらかじめ検知して対策しておくことで、いざ問題が起こったときに備えていきます。
すべての可能性に対して考えると非効率なので、起こる可能性と起こった場合の影響度が高いものから優先度をつけて考えることになります。

プロジェクト調達マネジメント

プロジェクトを進める上で必要なパートナーやサービス・ツールを外部から仕入れることを意味します。
ただ調達するだけでなく、パートナーがしっかりと活動できるような状況を事前につくることが求められます。

プロジェクト・ステークホルダー・マネジメント

本来必要のない手戻りの発生など、無駄な作業を最小限に抑えるために、プロジェクトに関わる利害関係者の役割を整理していきます。
さまざまな立場の人をすべて満足させることは現実的に難しく、落とし所や妥協点を見つけるために、関係者と柔軟かつ誠実な話し合いを必要とされます。
そういったことから、プロジェクトマネージャーの人間力を試される側面でもあります。

優先度をつけて対応することが大切

すべての項目に対して常に同じ程度で注視し続けることは、非効率かつ現実的ではないので、優先度をつけることも必要です。
プロジェクトによりケースバイケースですが、判断がつかない状況下で優先度をつける場合、下記の「常にウォッチ」グループについては、おろそかにしてはならない項目と考えられるでしょう。
※統合マネジメントは、総合的な位置づけになるために省略します。

常にウォッチ

何をいつまでに誰がつくるのかを決めること。これが最低限決まっていなければプロジェクトとして成立しない。

スコープマネジメント
スケジュールマネジメント
資源マネジメント

必要に応じて確認

プロジェクト管理のゴールであるQCDを成功に導くために必要になる項目。立ち上げ〜終結まで注視せずとも、経験的な勘所も必要になるが、要所で確認することで成立することが多い。

コストマネジメント
品質マネジメント
コミュニケーションマネジメント
リスクマネジメント
調達マネジメント
ステークホルダーマネジメント

なぜ、実行段階でPMBOKから意識が離れていくのか

実際のプロジェクトを進める際に、PMBOKを意識的に活用できている人はかなり少ないのではないでしょうか。計画段階で各プロセスを網羅的に想像するために活用することはできますが、実行段階に入るとPMBOKを意識することは少なくなってしまいます。

なぜ実行段階ではPMBOKから意識が離れてしまうのでしょうか。

ひとつは、フレームワークに沿って網羅的に注視しつづけることは、予算との兼ね合いで現実的でないことが挙げられます。小規模のプロジェクトで常に網羅的に注視していると、効率が悪く柔軟性の低いPMになってしまいます。

もうひとつは、実行段階でさまざまな事情や人間性など固有の変数が強く影響していることによって、フレームワーク通りに進めることができないシーンが多いためです。PMBOKの中には「こんな性格やスキルの人にはどう対応するのか」といった部分はあまり語られていません。しかしこれもプロジェクトマネジメントにおいて重要な要素です。実際のプロジェクト実行段階ではクライアントやチームメンバー、そして自分自身の人間性によってガイドをどうアレンジし、ときには無視するという判断をすることも求められます。セオリー通りに考えても、「こうすべきだよね」ということが相手によって変わってくるため、さじ加減がとても難しい部分でもあります。

こういったプロジェクトの予算やメンバーにあわせて、勘所を働かせているうちに、PMBOKへの意識が薄れていってしまうことが多いのではないでしょうか。

KKD（勘・経験・度胸）とのバランスが大切

ただ、PMBOKとの距離感としては、そのくらいが程良いのかもしれません。
先人たちが築き上げた知識をもとに作り上げられたこのフレームワークを常に傍らに持ち、ことあるごとに開いて参考にしていては、実行のスピード感に対応できません。どちらかというと、家の本棚に置き、プロジェクトマネジメントの基本的な考え方として定期的に取り出すというようなイメージが近いように思います。

そこで必要とされるのが、KKD（勘・経験・度胸）と言われるような勘所なのかと思います。
それぞれの事情や人間性に対応するときに、KKD（勘・経験・度胸）が必要であるということを理解していると、ガイドブックに頼りすぎずに、自信とスピード感を持って進めることができると思います。

当然ながら、KKDだけに頼るのは危険なので、PMBOKというフレームワークに立ち返り、両方のバランスを意識することが大事になります。

更新されるフレームワーク（第７版について）

PMBOKは実案件からのフィードバックによってその時代のビジネスにあった内容に修正されていくことから、過去のフレームワークに頼らず、新しいものも追い求める意識が必要とされます。古いフレームワークと知らずに盲目的に信じ込んでしまうと場合によっては、プロジェクトをミスリードしてしまう危険性もあるためです。

3〜5年周期で更新されているPMBOKですが、2021年8月には第7版が英語版で発表されました。今回の変更はかなり大きく、今までとはまるで違うもののように見えます。今までが古めかしくありがたい経典のようなものだとしたら、より現代的な指南書に大きく方向転換したようなイメージでしょうか。

どうやら、賛否両論あるようですが、人間性を考慮された実践的な項目になっているように見えます。また、これまでKKDに頼っていた部分の一部が含まれているのではないかと期待しています。

第6版までがウォーターフォールのためだけにあったわけではないですが、よりアジャイルやスクラム、準委任契約という現在のビジネス潮流を強く意識した内容になっているのは間違いないようです。

PMBOK®︎ガイド第７版の概要

PMスタンダード（プロジェクト・マネジメント標準）

イントロダクション
価値提供システム
12のプロジェクトマネジメント・プリンシプル（原則）
スチュワードシップ（Stewardship）
チーム（Team）
ステークホルダー（Stakeholders）
価値（Value）
システム思考（System Thinking）
リーダーシップ（Leadership）
テーラリング（Tailoring）
品質（Quality）
複雑さ（Complexity）
リスク（Risk）
順応性と柔軟性（Adaptability and Resilience）
チェンジ・マネジメント（Change Management）

PMBOKガイド（プロジェクト・マネジメント知識体系）

8つのパフォーマンス・ドメインステークホルダー（Stakeholders）
チーム（Team）
開発アプローチとライフサイクル（Development Approach and Life cycle）
計画（Planning）
プロジェクトワーク（Project work）
デリバリー（Delivery）
測定（Measurement）
不確実性（Uncertainty）
テーラリング
モデル、メソッド、ツール

主な変更ポイント