TOPプロジェクト管理> PMBOKの広がり
PMBOK第3版
PMBOK2000と比べて覚えるPMBOK第3版

第1回:アーンド・バリュー法の解説書であるPMBOK

著者:イマジンスパーク  深沢 隆司   2006/8/17
1   2  3  次のページ
PMBOKの広がり

   IT業界を主として、ここ3年ほどの間にPMBOK(注1)やPMP(注2)は大きな広がりを見せました。またPMI(プロジェクトマネジメント協会)の会員数とPMPの資格取得者は急激に増加しています。
※注1: PMBOK:
アメリカの非営利団体PMI(Project Management Institute)が策定したプロジェクトマネジメントの知識体系を記述したものであり、事実上の標準として世界中で広く受け入れられている。

※注2: プロジェクトマネジメントに関する経験/教育/知識をはかり、プロフェッショナルとしての確認を目的とした資格

   官公庁や大手の開発においても、PMP資格取得者によるプロジェクトマネジメントを義務づける場合も多くなってきました。また顧客側情報システム部の担当者などもPMPを取得するようになり、営業担当者が顧客側の情報システム部と開発企業側の開発部との初期段階の橋渡しを行うためにPMP資格を取得するということもあります。筆者が講師をしている大手SIerのPMP試験対策講座でも、営業担当者の参加は珍しくありません。

   このようなPMPの広がりに伴って計画の重要性や品質保証の考え方、そしてリスクマネジメントなどの「高品質なプロジェクト・スコープを実現するためのプロジェクト・マネジメント・ライフサイクル」についての認識が高まり、大きくIT業界の仕事の進め方が変化しています。これは歓迎すべきことではないでしょうか。


PMBOKはHow toではない

   しかし一方で、否定的な言葉が聞こえる場合もあります。

   IT業界に長くいる人であれば幾度となく経験していると思いますが、何かしら新しい考え方が「流行」すると、その真意とは無関係に持ち上げられて、またその反動で悪くいわれたりすることがあります。

   最初に明確にしますが、PMBOKに記述されていることは「誰かの新しい考えや手法」ではありません。主に「複数の人間の共同作業によって何かしら物事を成し遂げるにあたっての事実」と、「実際にうまくいっている考え方や活動」であり、これらを分類/整理して、(受け入れられやすい形で)文書化しているものなのです。ですから、「PMBOKを導入しても、ダメだった」という表現でPMBOKを否定するのは、すでにPMBOKを理解していなかったり、たいして読んでいなかったりすることのあらわれなのです。つまり、How toを示すものとは違います。


PMBOKに関する誤解の一例

   ここでPMBOKに関する誤解の一例をあげます。

   PMBOKでは計画を非常に重要視していますが、そのイメージのみを大きく捉えすぎていることから、業務システム開発において、顧客業務の現状を現場見学やインタビューなどもしていない中、文書などの提示だけによる情報提示(RFP含む)で「微に入り際に入り徹底的に計画を立てる」ことを要求される場合があるようです。そしてこれを従来通りの「計画に少しでも変更があるとパニックになる」「何らかの変更自体が問題視される」という、昔ながらの組織文化から外れないまま行われたりする場合も多く見受けられます。

   RFPなどの文書のみで、いったいどれほどのことが伝わるでしょうか。さらに、微に入り細に入り「本当に文書通りに」行われている業務がどれほどあり、誰がそれを証明できるでしょうか。ちょっとした違いはほっといてよい、開発対象として考慮しなくてよいということはまずありません。実際に作る側には、まさにそのような、一見して小さな所がとても重要であったりします。実際の物作りは「小さくても、確実なこと」を積み上げないと、いつか基礎からくずれてしまいます。「何が確実か」わからないままで先に進める(つまり、終わりまでの計画を立ててしまって変更できない)という考え方は、物作りをする上では致命的なのです。

   これは、プロジェクトの大きな特長といえる「段階的詳細化」という事実を無視した状態です。事実の無視ほどプロジェクトのバランスを壊すことはありません。「無意識のうちに計画が重要視されていないプロジェクト」という従来ありがちだった問題より、かえって悪い状況を生み出している可能性すらあります。もちろん計画に変更がないに越したことはありませんが、変更を問題視するのではなく、協力し合って正面から対処していこうという関係者全員の前向きな気持ちが重要です。

   過去に見聞きした限りでは、計画の精度よりも「変更などに対するパニック」や「ズレた問題視」をする組織文化の方が、よほどプロジェクトを破壊している要因となっている場合が多いと思います。このような考え方そのものが、過去の様々な問題を引き起こしてきたように思います。


識別や改善がされにくい組織文化

   「プロジェクトマネジメント計画書をしっかり作成する」というような具体的な行動については理解やイメージがしやすいのですが、表1の例のようにPMBOKの記述の対象となっている組織文化については当該組織の中の人には極めて理解しにくく、加えて話題にしにくいためになかなか識別や改善はされません。

  • リスク状態はプロジェクトの組織環境の側面である。例えば稚拙なプロジェクトマネジメント実務慣行、統合マネジメント・システムの欠如、並列して実施されている複数プロジェクトの兼務、コントロール不可能な外部要員への依存、などがプロジェクト・リスクの一因となる(238ページ)
  • 個人、およびその延長である組織は、リスクに対する姿勢をもっており、この姿勢はリスクを認識する正確さとその対応方法の両方に影響を及ぼす(240ページ)
  • 成功するためには、プロジェクト全体を通して、率先かつ一貫性をもってリスクに取り組むという態度を組織として明らかにすべきである(240ページ)

表1:プロジェクト・リスク・マネジメントに記述されている組織文化に関連する記述

   元々目標としている成果物やサービスを実現するにあたっての事実(必要とされるノウハウ、資源など)があって、それは本来は変わるものではありません。段階的に詳細化しているのは成果物そのものではなく、それを実現しようとしている人々の理解の方なのです。そしてこれは実際に進めていく中ではじめて得られることであって、そもそも「取りかかる前に計画に変更がないことがわかる/証明できる」ということは通常ではあり得ません。

   そして何か新たな理解が得られて、その結果としてそれまでの計画では実現できないことが判明した場合に、変えようがない「事実」を曲げて、そのままの計画で進めるのではなく、「計画を含んだ変えられる部分」をいかに上手く変化・適応させて当初の目標を達成するということがプロジェクトマネジメントなのです。

1   2  3  次のページ


イマジンスパーク 深沢 隆司
著者プロフィール
株式会社イマジンスパーク   深沢 隆司
株式会社 イマジンスパーク 代表取締役
陸上自衛隊少年工科学校第25期生。対空戦闘指揮装置の修理要員として自衛隊に勤務。退職後に一部上場企業や官庁でのシステム開発等で仕様策定、プロジェクトマネジメントに従事し、独自の手法で成功に導く。著書は『SEの教科書』他。

INDEX
第1回:アーンド・バリュー法の解説書であるPMBOK
PMBOKの広がり
  PMBOKに必要な肝所
  全面書き換えされた統合マネジメント