PMBOK入門

新版 プロジェクトマネジメント標準 PMBOK入門

PMBOKについて学んでおきたかったので、購入した。
PMBOK（ピンボック）とは、プロジェクトマネジメントに関する知識（ナレッジ）を体系化したものである。この本によると、とくに言葉の理解の共通化に使うことができるという。確かに、システムの開発プロセスに限定すると、日本では各社ベンダーがもつ特有の開発手法や、「共通フレーム2007」とよばれている国が決めたものなど、決して統一されているとは言いがたい。PMBOKはシステムの開発プロセスには限定していないが、適用は可能である。
プロジェクトとは有期の独自性のあるプロダクトやサービスを作ることであると定めている。つまり、「経費削減」はプロジェクトの目標にはならない。１つ以上の関連あるプロジェクトをまとめた活動を「プログラム」とよび、このプログラムは先ほどのような「経費削減」といった経営戦略を目的とした単位となる。「プログラム」を管理することを「プログラムマネジメント」とよぶ。すこし、プログラムの意味に違和感があるが、教育プログラムと行った時の使い方と同じである。
さて、次にPMBOKの各プロセスを紹介している。全部で４２あるのだが、これらを５つの群に分けている。それぞれの群に割り当てられているプロセスの数は以下のとおり。

プロセス群	プロセス数
立ち上げプロセス	2
計画プロセス	20
実行プロセス	8
監視・コントロールプロセス	10
終結プロセス	2

もう一つ、９つの知識エリアでプロセスを分類している。プロセス群が役割からの分類であるとすると、知識エリアはマネジメントの対象からの分類であるといえる。主にプロジェクトの制約である「スコープ」や「コスト」などが対象となっている。具体的なプロセス数は以下のとおり

エリア	プロセス数
統合	6
スコープ	5
タイム	6
コスト	3
品質	3
人的資源	4
コミュニケーション	5
リスク	6
調達	4

なぜプロセス数を示したのかは後ほど述べる。
さて、エリアに注目すると、ほぼ同じ内容である。当たり前だが、各エリアに相当する対象について、計画し、実施し、監視・コントロールする、といったことがプロセスとして定義されている。各プロセスには使うことのできる手法がいくつか紹介されている。たとえば、QC7つ道具のようなものである。これらがPMBOKに含まれているかどうかはわからない。この本が独自に提供してくれているだけなのかもしれない。
この中で、特徴的なのをいくつかあげる。
まず、立ち上げプロセスで作成するという「プロジェクト憲章」である。これは、実現すべき機能・要求とともに、先に上げた各エリアの対象について基本的な方針を示すものである。たとえば、スコープであれば、おおまかなスコープを示したり、コストであれば、予算はだいたいいくらかといった内容である。つまり、プロジェクトを立ち上げ段階におけるプロジェクトを成功するための必須条件を列挙したものといえる。このプロジェクト憲章を元に作成されるのが、プロジェクトマネジメント計画書である。これは、計画プロセス群全体の計画を文書化したものである。計画書は大まかには「要求事項収集」→「スコープ定義」→「タイム定義」（「アクティビティ定義」→「スケジュール作成」）→「コスト見積り」「人的資源」「調達」という流れで作成する。
次に、特徴的なのは「スコープ定義」プロセスである。単にプロジェクトのスコープ、つまり範囲を示すものではない。具体的にどのような成果物を作り、何をするのかを示すとともに、何を前提条件した計画とするのかといったことも記述する。このスコープ定義においてこのプロジェクトで実施すべき作業を定義するが、これが複雑な場合はWBSとして階層化して示す。これらをもとにさらに詳細化し、実際にコントロールを行う単位となるのが、アクティビティである。
本書では、このあと具体的なシステムの構築プロジェクトの例を示しながら、説明を行なっている。
さて、PMBOKについて感じたことは以下のとおり。

• PMBOKの目的はコミュニケーションである。本書で定義しているように、語彙の統一化が目的である*1。wikipediaではPMBOKはベストプラクティスであると書いているが、決してベストプラクティスではない。そもそも、すべてのプロジェクトにおけるベストプラクティスを定義することは、当たり前だが、絶対に不可能である。つまり、PMBOKに準拠したプロジェクトマネジメントを行なっていたとしても最善であるとはいえない。ただし、プロセスの一覧が定義されているので、作業の漏れの確認にはなるといえる。
• PMBOKは計画重視の体系である。プロセス数を見ても明らかである。ただし、これらを厳密に、かつ実施前に実施するとなると、かなりの時間を必要とする。どこまでやればよいのだろうか？まあ、それを決めるのはプロジェクトマネージャーの仕事なのかもしれないが。
• PMBOKに準拠したプロジェクトがそうでないプロジェクトに対して、成功する確率が上がるということはあまりいえない。確かに作業の漏れの確認にはなると思うが、それ以上でもそれ以下でもない。例えば各アクティビティの作業見積もりの精度を上げる手法は何も言及していない。類推見積りというのが紹介されているが、これは単に類推して決めているということである。この見積に名前をつけているということには意味がある。しかし、類推することの精度を上げていることには寄与していない。ただし、プロジェクトの成功要件を厳密に決めようとする方針を掲げているのは、利害関係者がプロジェクトが成功したかどうかを明確に認識できるということにつながっているといえる。
• PMBOKさまざまなプロセスを定義しているが、すべてのプロジェクトがすべてのプロセスを必要としていない。そういう意味ではやや冗長であるため、プロセスごとになぜそのプロセスを実施する必要ながあるのかを明確にし、取捨選択するためのある程度の目安、基準を理解しなければならないが、今ひとつこの本ではわからない。

*1:語彙の統一化が目的であるという点からすると、いわゆるデザインパターンに近い。