ネットで「プロジェクト」と検索すると数多くのプロジェクトが存在していることが分かります。「商品開発プロジェクト」「町おこしプロジェクト」「〇〇ビル建設プロジェクト」等の行政や民間が行っている多くのプロジェクトが出てくると思います。

私たちの身近な所でも、「学園祭運営委員」「懇親旅行企画員」や「飲み会の幹事」も、プロジェクトと呼べるものが数多くあります。

突然ですが、質問です。

もし、あなたがプロジェクトマネージャに任命された場合、どのようにプロジェクトを進めればいいでしょうか？

プロジェクトに参画した人は、何を意識して業務を行うことが大切でしょうか？

このような質問をされた時に、会社員の方は、上司や先輩に習いながらプロジェクトを遂行すればいいと考えている人もいるかもしれません。既に多くのプロジェクトマネージャの経験がある方は、自身の経験値でうまく遂行できるかもしれません。

しかし、プロジェクトマネージメントについてきちんと知識を持っておかなければ、目的を見失い、路頭に迷ってしまうことが、プロジェクトではよく起きてしまいます。

では、そのプロジェクトマネージメントの知識をきちんと理解するための「教科書」といえる物があるのをご存じでしょうか？

それは、「PMBOK（ピンボック）」と呼ばれているプロジェクトマネージメントの知識体系です。

この記事では、その知識体系である「PMBOK」とは何かについて紹介していきます。

プロジェクトは何か？

そもそもプロジェクトとは何かについて、根本的に知っておかなければ、「なんでもプロジェクトで進めればよい」ということになってしまいます。

プロジェクトの定義とは、「独自のプロダクト、サービスを創造する為に実施する有期的な業務」と言われています。

つまり、プロジェクトとは以下の3つを満たすことが必須事項となります。

①何かを結果として生み出すもの（知識や企業価値や感動等も含む）があること

②期限があること。

③過去に同じ業務がない独自性の業務であること。（環境、手順、人員の違いなども独自性につながる）

この3つのいずれかが該当しない場合は、それはプロジェクトとは言いません。日常業務（生産管理・出荷業務や作業効率業務等）であったり、周期性のある決まった業務（決済業務や定期試験）である場合は、プロジェクトではないので注意が必要です。

ＰＭＢＯＫはあらゆるプロジェクトのガイドライン

ＰＭＢＯＫ（ピンボック）は、プロジェクトのガイドラインであり知識体系を表しています。

具体的にどんなことを説明しているかを紹介します。

プロジェクトの制約条件

プロジェクトには成功と失敗があります。その判断を下す為のルールが3つあるとＰＭＢＯＫでは説明しています。

ルール１：品質・・・プロジェクトの成果物が要求を満たしているか

ルール２：スケジュール・・・成果物を期限内に完成させること。

ルール３：コスト・・・プロジェクトの為に用意した費用（予算）を超えることなく完成させること。

この3つが主軸となってプロジェクト運営を行うことが、プロジェクトの目的であるとされています。

PMBOKの知識

プロジェクトを遂行するための、「12個の原理原則」と「8個のパフォーマンス領域」をPMBOKでは説明をしています。

12個の原理原則とは

プロジェクトは、チーム戦です。そのプロジェクトに関わる一つ一つの用語に対して、原理原則と呼ばれる「〇〇とは～～とあるべきである」といった心得のようなものを示しています。一見当たり前の内容に見えますが、この原理原則にチーム全体がしたがっていくのだ！と認識しておかなければいけません。

さもなければ、「なんで私がそんなことをしないといけないのか」といったチームメンバーの不満に、いちいち対応を余儀なくされ、プロジェクトが遂行出来なくなるからです。

その為、この原理原則は、プロジェクトマネージャのみにおける心得ではなく、プロジェクトチームメンバ全体も含めている為、プロジェクトチーム全員でこの知識を共有しておく必要があると考えるべきでしょう。

特にこの数年で新たに加わった考え方には下線で示しています。近年重要視されていることである為注目してください。

【12個の原理原則】

項目	内容
価値	顧客に提供する利便性や満足度だけでなく、スポンサーにもたらす売上やブランド力、プロジェクトによって得られた技術力を重視すること。
品質	要求された品質だけでなく、その成果物を使用することで得られる成果を満たすことができるかを追及すること。
ステークホルダー	人間関係のスキルを活用し、適切な働きかけを行うこと。
変革	ステークホルダーが変革を受け入れる様に適切な働きかけを行うこと。
チーム	チーム活動によって適切な成果を出せるように、組織体系や合意形成のルール、作業手順が適切になるように調整を行うこと。
リーダーシップ	プロジェクトチームメンバーは、各人が主体的にリーダーシップを示すこと。
煩雑さ	人の行動、技術革新の煩雑さに対処すること。
リスク	リスクを特定し、最小の脅威となるように進めること。
システム思考	互いに影響し合う要素をシステム要素と捉え、全体の影響をみながら、問題解決を行うこと。
テーラーリング	作業手順やステークホルダーへの働きかけを影響度を判断しながら積極的に行うこと。
スチュワードシップ	プロジェクトメンバー全員が、堅実さ、面倒見の良さ、信頼を兼ね備えた人間でなければいけないこと。
適応力と回復力	計画の変更に前向きでなければならず、その適用力と失敗による叱咤（しった）等に落ち込まない回復力を備えておくこと。

※ステークホルダーとは、プロジェクトに関わる人やそのプロジェクトに影響を受ける人の全体を指しています。

この原理原則を「私には関係ない」と感じているメンバーがいたら、その人はプロジェクトメンバーとしてふさわしくない人物になってしまうかもしれません。

8個のパフォーマンス領域

パフォーマンス領域と聞いて、「何それ？」と思うのが一般的かなと思います。

プロジェクトにはステークホルダーと呼ばれる、すべての関係者とのコミュニケーションで進めていきます。

PMBOKでは、そのコミュニケーション（＝書類や成果物のやり取りも含む）で何をするかで区切ったものを「パフォーマンス領域」と解釈しています。「実際に活動する場面」と言い換えた方が分かりやすいかもしれません。

具体的な活動内容を以下の表に示します。

【8個のパフォーマンス領域】

パフォーマンス領域	活動内容
デリバリー	スポンサーやユーザー（顧客）が成果物が価値をもたらすことができるようにする活動。
開発アプローチとライフサイクル	プロジェクトマネージャーとそのチームメンバーでプロジェクト活動の進め方を決める活動。予測型アプローチや適応型アプローチの選択を行う。また、成果物の提供やその頻度を決める活動も行う。
計画	プロジェクトマネージャーとそのチームメンバーでプロジェクト活動の進め方を決める活動。予測型アプローチや適応型アプローチの選択を行う。また、成果物の提供やその頻度を決める活動も行う。
プロジェクト作業	具体的な作業内容や手順を決め、必要に応じてルールや作業環境を整備する活動。プロジェクトチーム内の作業効率が最大化となるように、人的資源や物的資源の獲得をする。また、コミュニケーションや変更の管理も行う。
測定	プロジェクトの状態監視や情報収集を行う活動。予算との差異や工程進捗、顧客の満足度、費用対効果、成果物の価値指標などのプロジェクトの状態を分かりやすく表示する。
ステークホルダー	顧客から賛同を得て、各種協力をしてもらうための活動。協力的なステークホルダーとコミュニケーションや分析を行い、エンゲージメントを得るための活動である。
チーム	プロジェクトチームメンバーへの指導や育成を行い、プロジェクトチーム全体が目的に向かうようにするリーダーシップ活動。メンバーのモチベーション向上やチーム成長も促す対策が必要である。
不確かさ	リスクを回避し、そのダメージを最小にするための活動。

PMBOKの経歴と最新7版でどう変わったのか

PMBOKの起源は、幅広く利用可能なプロジェクトマネジメントの情報や実践方法の文書化と標準化を目的として、1987年に米国のPMI（Project Management Institute：PM協会）から発表されたのが始まりです。

その後、1996年に初版、2000年に第2版、2004年の大幅変更(第3版)が行われました。その後、2008年に第4版、2013年に第5版、2017年に第6版と更新が続き、2021年に最新の第7版が発行されています。

現在はPMBOKガイド第7版（2021年）が最新です。

PMBOKガイド第7版では、これまでのプロセスベースの考え方から大きく変わり、プロジェクトマネジメントの原理・原則を重要視することに徹する内容に変更されています。

その大きな内容の違いは、プロジェクト進行の考え方がより柔軟になるように改変されているのです。

変更内容を以下の図に示します。

従来はウォーターフォール型と呼ばれる「事前の計画に決定した事項」を最重要とするプロジェクト進行のみでした。しかし7版では、計画や実行をしながら段階的に重要事項を決定していくアジャイル型にも適用する内容に変更となっています。

その為、仕様変更などのプロジェクトの計画変更による、意思決定や意思疎通をプロジェクトマネージャー1人に任せるのではなく、メンバー全員で達成することが大切であるという内容に書き換わっているのです。

モノづくりの考え方が変わる

下に示すプロジェクトフロー図は、ある新規装置を製作し、運用するまでのフェーズをPMBOKにしたがって描いています。

一見すると、何の変哲もないステップに見えるかもしれませんが、一番下の「計画書の見直し」がすべてのフェーズに入っていることに注目してください。

計画書の見直しは、何かを開発する際は「当然発生するもの」として考えるのが一般的です。

しかし、PMBOK6版までのプロジェクトでは、この見直しが最小限となるよう努力し、大幅な見直しとなった場合は、最初の計画フェーズに戻って初めから計画を練り直す必要があるとされてきました。始めに引いたレールから逸脱することが、許容されていなかったように私は感じていました。

その為、かつては失敗を繰り返し行いながら開発する事業（新規製品開発）を立ち上げる場合、プロジェクトを組んで開発を進めることが難しいとされてきました。その理由は、失敗をするたびに大幅な変更が伴うからです。

従来のプロジェクトでは、計画の変更により、品質、期限、コストが未達成となればプロジェクト自体が失敗とされてしまってたのです。

その為、失敗しながら日進月歩する商品開発はプロジェクトに不向きであるとされてしまいがちでした。（実際は、プロジェクトマネージャが大変な思いをしながら遂行していたのだと思います）

たとえ開発が前向きに進んでいたとしても、品質、期限、コストが未達成であれば、プロジェクトは失敗となり、それによってスポンサーも、依頼しているプロジェクトメンバーの開発力が損なわれてしまったように錯覚して、離れてしまうといったデメリットも生じてしまうのです。

PMBOK第7版によって、プロジェクト進行に、アジャイル型の様な考え方が取り入れられることで、そういったマイナス面を解消することができるようになります。

さらに、より迅速な意思決定や社会のニーズを素早く取り入れた成果物を、プロジェクトで創造しやすい環境が整っていくことが期待されています。