さぁ、プロジェクトをはじめよう<第5回> 〜PMBOKあれこれ〜

もう少しだけPMBOKにお付き合いいただこう。
今回は、PMBOKの細々（こまごま）した内容を五月雨的にお伝えしたい。
魂は細部に宿る。特に前後のつながりなくメモ的な書き方になるが、PMBOKに通底する大きな思想・輪郭のようなものが浮き上がれば幸いである。

プロジェクトライフサイクルとフェーズの違い

前回、プロジェクトライフサイクルの紹介をしたが、システム開発などで使用する「フェーズ」とは一致しないので注意が必要だ。システム業界では「企画・検討」→「要件定義」→「開発・テスト」→「本番切り替え」→「運用・保守」と段階的に工程を切ってサービスを構築するのだが、このフェーズの中に複数のプロジェクトを立ち上げるのが一般的だ。

具体的には、要件定義プロジェクトと開発プロジェクトを別物として立ち上げる。なぜかと言うと、運営主体が違うからだ。
要件定義は「やりたいこと(=要件)を確定させる (＝定義する)」作業であるがために、作業のスコープが決まっていない。やればやるだけ時間がかかる。よって、発注元のユーザ企業はこの段階でパートナーとなるシステム開発会社とは準委任契約を結んで「成果物は決めないけど、一緒に考えるのを手伝ってね」と言う立場で要件定義作業を行う。
一方、開発フェーズでは要件定義により開発スコープが確定しているので、発注元のユーザ企業はシステム開発会社へ一括請負契約して「んじゃ、後お願いね」で業務の完遂を待つ立場となる。

要するに、要件定義フェーズでは発注元のユーザー企業が「要件定義プロジェクト」を立ち上げ、開発フェーズでは発注を受けた開発会社が「開発プロジェクト」を立ち上げるので、必然的に運営主体が別となり、プロジェクトとしても別ものとなるのである。

ある一業界が使っている工程（＝フェーズ）とPMBOKでいうところの「プロジェクトライフサイクル」は全く別のものとして捉える必要がある。

「実行」と「監視・コントロール」の違い

PMBOKの各プロセスで使われている言葉についても注意が必要だ。

「実行」と「監視・コントロール」の違いはなんだろうか？
実行は、「計画プロセス」で計画した内容をその名の通り「実行」すること。「監視・コントロール」は、実行した結果を測定し、その結果に基づきプロジェクトの動きを調整する働きを持つ。「実行」がアクセルだとするならば、ブレーキの役割をしているのが「監視・コントロール」である。

ついでに「監視」と「コントロール」の違いはなにかと言えば、自分の意思で制御することができるものは「コントロール」で、出来なければ「監視」となる。
「スコープ」「スケジュール」「コスト」「品質」「調達」は制御できるので「コントロール」だが、「コミュニケーション」「リスク」「ステークホルダーエンゲージメント」は制御できないので「監視」となる。

マネージメントとコントロールの違い

「マネージメント」と「コントロール」の違いに関しても知っておこう。
意味だけ単純に捉えると「マネージメント」は経営とか管理とか、総合的な結果責任を自らに求める言葉である一方、「コントロール」は他者を制御する意味合いが強い。他者とは、プロジェクトマネージャの立場から見た、スタッフやメンバー、協力会社になる。

これは余談なのだが、ある著名なプロジェクトマネージメントの専門家から聞いた話によるとこの「コントロール」と言う言葉は割とキツ目で、性悪説に基づいて制御するようなそんな意味合いも含んでいるとのこと。遊牧民の文化で羊を管理するイメージに近い。西欧や中国人にはこの「コントロール」という言葉のニュアンスが伝わるのだが、農耕民で性善説を好む日本人には伝わりづらい言葉のようである。

PMBOKの変遷

PMBOKの変遷もざっくり、振り返ろう
ここは筆者の記憶に基づく部分が多いので、多少認識齟齬や漏れがあるかもしれないのであらかじめお断りしておく。
PMBOKは当初、成果物主義的な傾向が強かった。

各プロセスからアウトプットされる成果物の品質を高めることにより、プロジェクトの品質を上げていくと言う考え方だ。「しっかりプロジェクトを運営していれば、それなりの品質の成果物が出てくるよね」と言う発想なのだが、結果、成果物の品質を上げることにエネルギーが向いて、プロジェクトそのもの品質がなおざりになる本末転倒な結果になってしまった。

その後、「成果物よりもプロセスが大事じゃね？」と言う考え方になって「プロセス主義的」なものに変わっていった。ただ、とは言え49プロセスもあるのでは、大規模プロジェクトじゃなければ対応できない部分も大きく、もっと短いサイクルで柔軟に開発できる方法が模索されるようになる。

そもそもプロダクトにせよサービスにせよ、必ずしも完成イメージが明確なものばかりではない。例えばゲームを作るプロジェクトがあった時に、ガチガチにプロセスを重視するよりも雛形を作りつつ、トライアンドエラーを繰り返して良いもの作る方法の方がよっぽどしっくりくる。こうした走りながら考える的なプロジェクトの進め方を「アジャイル方式」というのだが、PMBOKもその影響を受けて、アジャイル方式を追記するようになった。

また、これまであくまでもマネジメントに限定していた管理の範囲を、リーダーシップやビジネスの分野までPMが関与するべきであるという方針に転換するような動きも目立ってきているのが現在の状態である。

PMBOKはこうして様々な観点を加えながら今もなお、発展していっているのである。

PMBOKあれこれ

どうだろうか？
PMBOKを勉強するとプロセスに目が向いてどうしても知識が断片的になりやすいが、このような背景やニュアンスを知っているのと理解の深度が変わってくるのではないだろうか？

ただ、個人的にはPMBOKはなにか西欧的な管理ツールだなぁという感想をもつ。
PMBOKは「部分集合を足し合わせれば全体になる」的なアプローチである。モジュール（部品）を組み合わせてピックアップトラックを完成させるような発想に基づいている。あるいは西洋医学が人の体を、器官の集合のように捉えるようなそんな考え方にも似ている。

あながち否定もできないが、質の高い部品を組み合わせれば質の高い製品ができるという捉え方は、少しインテグラルなスマートさが足りないようにも感じる今日このごろである。