2007年度FUJITSUファミリ会 秋季大会
開催日：2007年11月1日 開催地：リーガロイヤルホテル広島

今回我々は、プロジェクトマネジメントの知識として、PMBOKを一つのデファクト・スタンダードと考え、これをベースに今回の成果物を作ってまいりました。なぜデファクト・スタンダードかということをご説明しますと、PMP、PMBOKのプロフェッショナル資格の取得者が、2007年には2万462人ということで、年々増加しています。実際に仕事に従事している人数と比べると、PMBOKの資格を取得している人はまだまだ少ないのですが、かなり急速にPMの資格取得者が増えている傾向にあることが、こちらのグラフ（図表5）からもわかっていただけると思います。世界的にもPMBOKは広く認知されており、現在、PMBOK適用ガイドラインの第3版が翻訳されています。さまざまな会社のシステム関係の教育にも、PMBOKが採用されているのではないかと思います。

PMBOKの構成について、まず簡単にご説明しますと、縦軸には、統合から調達まで、マネジメントの知識エリアが9つ並べられています。横軸には、立ち上げから終結まで、マネジメントのプロセス群が5つ並べられています。この中に44個のプロセスを配置して、どのようなマネジメントの知識で、どう立ち上げ、計画するかなどを規定していきます。（図表6）

例えば、立ち上げのプロセスでは、統合マネジメントでまず、プロジェクトの承認を行います。承認してもらうためのプロジェクト検証を作るなど、ほかの8つのマネジメントは、統合マネジメントの配下で、個々の計画を司っています。リスク・マネジメントは、計画・監視をして、その状況を把握し、他の知識エリアにフィードバックをかけて、あらためて計画のやり直しを図るので、実際に実行するフェーズはありません。

そして、プロジェクトが立ち上がると、横軸にあるように計画を実行し、監視・コントロールしながら進み、プロジェクトが終結するクロージングに入ります。しかし、ただそれだけでプロジェクトが済むわけではありません。当然、PDCAのサイクルがあります。個々の知識エリアに関しては、分析をした結果、統合マネジメントのPDCAサイクルの中に、残り8つの知識エリアがそれぞれ独立してPDCAサイクルを実行しながらマネジメントを行うということがわかりました。

従って、このかたちでは、今までの開発工程、例えば要件定義や、設計・開発・テストといった工程と単純には結びつかないということ。それが、PMBOKを実際の開発の実務に適用することを難しくしているのではないかということがわかってきました。

それでは、PMBOKを実際のプロジェクトに活用するためには、何が足りないのか？PMBOKはシステム開発に限定したものではなく、ビルを建てたり、ロケットを打ち上げたり、ダムを建設したりという全世界のさまざまなプロジェクトを総括して、知識体系にまとめたものです。従って、これを単独で取り上げても、システム開発にどう結びつくのかということがなかなか理解しにくい。解説本もありますが、マネジメントの体系と開発工程とがすぐには結びつかず、なかなかフィットした説明本がないということがあります。今申したのは、PDCAサイクルですので、開発工程のどこに当てはまるかという概念は、当然、PMBOKの中では一切説明されておりません。タイム・マネジメントでは、そのプロジェクト全体の工程を規定し、管理していくという記述はあるにしても、では、要件定義では何をするか、開発工程では何をするかということには触れられていません。従って、我々はこれを実践的に使うために、開発工程の時間的な流れごとに、それぞれのマネジメントプロセスがどう変化するのかを定義すれば、システム開発にPMBOKを応用できるのではないかと考えました。（図表7）

その方針が決まってからの作業としては、PMBOKと、我々が研究した2006年度版の富士通のSDEMをベースに、これを融合するようなものができないかということで、さまざまな議論を重ねてきました。PMBOKそのものは、経験者が読むと、「自分が今まで経験したプロジェクトで、自分のマネジメントは確かに正しかった。ここに、このように書いてある」と読み取れるのですが、経験の少ないPM初心者にとっては、「何を言っているのかよくわからない。具体性がない」など、どのタイミングで何をすれば良いかということが書かれていないので、体得することが非常に難しいということがありました。そうしたところを融合し、なおかつ実際的なノウハウを取り込んで行こうと研究を続けました。（図表8）