さぁ、プロジェクトをはじめよう<第４回> 〜PMBOKを知ろう〜

前回の記事でも軽く触れたが、プロジェクトマネジメントは管理技術である。今回は、その技術的な意味合いについて具体的に内容を掘り下げていく。便宜上PMBOKという管理手法に言及するが、記事の対象がプロマネを目指すひとではなく経営者なので、ある程度わかり易さを目指す。厳密性に欠ける部分があることは予めお許しいただきたい。

PMBOKとは？

そもそもPMBOKとは何だろう。
「Project Management Body Of Knowledge」各語の頭文字をとって「プロジェクト管理知識体系」と訳されている。
情報処理機構(IPA)が主催するプロジェクトマネージャ試験のベースになっているため、I T業界の業界標準のように誤解される場合もあるが、PMBOKはあくまでも「プロジェクト管理」のための体系であり、特定の業界に特化されたものではない。建築業界でも、製薬業界でも、医療業界でも商社でもプロジェクトを作る必要があればどんな業界でも適用できるようになっている。よって、良く言うと汎用的であり、悪く言うと抽象的でとっかかりが掴みにくい部分もある。

1996年にPMI(プロジェクトマネジメント協会)から初版が発行され、大体4年に１度を目安に改定。2020年現在、2017年に発行された第六版が最新となっている。PMIが主催する「PMP(=Project Management Professional)」と言う資格のベースとなっており、海外企業でプロジェクトマネージャをやる場合は大体この資格を必須にしていることが多い。

こうした事情を背景に、PMBOKはプロジェクトマネジメントの標準として世界中で活用されており、国をまたいでお互い知らない同士でも、PMBOKを知ってさえいればプロジェクトマネジメントに関しては同じ言葉を使って会話できるようになっている。

 10の知識領域とプロジェクトライフサイクル

PMBOKがプロジェクトを管理する時にどのような考え方をしているのかと言うと、まずは押さえるべき領域を大まかに10個に分割することで、検討するべき観点に抜け漏れなく品質の高い管理ができるようになっている。この押さえるべき領域を「知識領域」と呼び、以下のように構成されている。

ここでは一個一個細かく説明はしないが、プロジェクトを構築・運営する上で例えば「品質」はこうしたことを、「コスト」に関してはこう、「スケジュール」はこの点を…と言った感じでプロジェクトが始める前から検討すべきポイントを提供しているのである。
プロジェクトを旅行に例えるならば、目的地・移動手段・日程・予算・緊急時の対応など、旅行をする上で気をつけなければいけないポイントが10個の領域に分かれてチェックシートとしてまとまっているようなイメージである。
これにより、経験の浅いプロジェクトマネージャでも観点漏れなくある一定のプロジェクト品質を保ちながら、プロジェクトを推進していくことができるのである。

PMBOKの考え方のもう一つ大きな特色はプロジェクトを「ライフサイクル」として捉える点である。
具体的には以下の5つのプロセス群として分け、あたかもプロジェクトが一つの生命体のように生成から終了まで時系列でやらなければいけないことを区分するのである。

これもまた、旅行に例える事ができ、旅行を「企画→計画→実行→状況の管理→帰宅」のように段階的に分割をして、それぞれの局面でやらなければいけない事を整理していくのである。

プロセス

この「10の知識領域」と「プロジェクトライフサイクル」はそれぞれ独立しているわけではない。この「領域」と「時間」の概念を掛け合わせ、さらに「プロセス」に分割してプロジェクトを管理する。
具体的には以下の表のような形である。

プロセスは全部で49個存在する。

「10」の知識領域と「5つ」のサイクルがあるためマス目としては50個あるが、全てのマス目にプロセスがあるわけではなく、また、１つのマス目に１つのプロセスと決まっているわけでもない。ここで言うプロセスとは、何らかのインプットがあって、何らかのアウトプットを出力するような、そんな処理の単位である。

「プロセス」は世界のPMIの会員がプロジェクトマネジメントし、成功事例や失敗事例を分析する中で磨き込まれたものであり、そうしたプロセスを検討＆活用することで手戻りが少なく、精度の高い管理ができるように設計されている。

テーラリング

とはいえ、PMBOKの「プロセス」はあくまでプロジェクトを推進するためのガイドライン(＝標準)に過ぎない。前述したとおり、PMBOKは特定の業界に偏った内容にならないように、記載の仕方もどの業界でもつかえるように抽象的な記述となっている。率直に言うと読んでいるだけで睡眠を誘うような内容である。良質な睡眠導入剤と言ってもいい。加えて49もあるプロセスの全てを真正面に受け止めて、その中に書かれていること全てを網羅しようとすると、かなり大変な作業になる。

PMBOKとしてもあくまでもガイドラインのような位置付けなので具体的な部分に関しては、各プロジェクト事に「テーラリング」(仕立て)なさいよと言う立場を取っている。

「テーラリング」は勝手にプロセスや知識エリアを無視していいとまでは書いていないので、自分のプロジェクトに合わせて一度は各プロセスの内容を検討する必要がある。

ただ、実務に携わっている立場で言うと、立ち上げに予算も時間もかけられるような大規模プロジェクトであれば話は別だが、大抵プロジェクトは時間も予算もかなりタイトで無理な状況で走り始めている場合が多い。そんな中で、49もあるプロセスを一つ一つ丁寧に検討している時間はない。一通りさらっとなめて検討しておくべき勘所を押さえにかかる必要があるが、それ以外は割り切って、辞書的に困ったことがあった時に振り返るような使い方をしてしまってもいいように思う。

杓子定規に使いこなそうとして、プロジェクトを遅延させたり、余計な負荷をかけるのであれば本末転倒であるし、流れの中で何度も必要な場所で読み込んで徐々に精度を上げていくような使い方が現実的である。

プロジェクト管理は技術である

さて、プロジェクトマネジメントは「技術」だと言う意味もわかってもらえただろうか？
「俺について来い」といったノリでやるものではなく、一個一個検討すべき観点を検討してそれに対する対応を決めていくという作業なのである。
リーダーはカリスマ性のようなものが必要になるかもしれないが、マネージャーはあくまで管理者であり、技術者と言ってもいいだろう。だから、マメな人間の方が向いているのである。

プロジェクト管理の考え方は、通常の業務にも応用できる部分も多いので、今後の記事をまた楽しみにしていただきたい。