本ブログは移転しました。こちらをご覧ください。
◆プロセスが好きな人と、嫌いな人がいる
ＰＭＢＯＫ（Ｒ）のプロセスの複雑さとか、ドキュメントの多さなどもやっと受け入れられて、なんとなく落ち着いてきた感がある。
一方で、ＰＭＩの今のトピックスはアジャイルである。今年の４月から、プロフェッショナル認定制度（Agile PMP）のトライアルが始まり、北米の年次大会でも年々、発表が増えている。アジャイルの活動は興味深い。ＰＭＩとしてはプロジェクトマネジメント、プログラムマネジメントやポートフォリオマネジメントのような標準を持たずに展開している。さし向き、アジャイルウェイのようなとらえ方をしているように見える。
世の中には、プロセスが好きな人と、嫌いな人がいる。プロセスが適したプロジェクトとプロセスは適さないプロジェクトがある。トラディッショナルなプロジェクトマネジメントとアジャイルの境界はここにあるのかもしれない。
そもそも、標準とは何かという議論もある。標準というのは、それを適用することによって確実にうまく行くメソドロジー（方法論）である。プロセスを標準にするということは、メソドロジーの適用の仕方を限定しているということで、たいへん、勇気のいることだ。
◆プロジェクトマネジメント標準とオーナーシップ
もう少し正確にいえば、標準があるということは、プロジェクトマネジメントのオーナーシップが存在し、オーナーシップがガバナンスを持つということだ。たとえば、会計のオーナーシップはＣＦＯにある。人事のオーナーシップはＣＨＯにある。これと同じで、プロジェクトマネジメントの場合、ＣＰＭＯ（Chief Project Management Officer）と呼ばれる。ＣＰＭＯが指示する通りにプロジェクトマネジメントを行い、それでプロジェクトがうまく行かなければ、ＣＰＭＯの責任である。プロジェクトの成功率を目標として設定し、達成できなければ責任を取ることになる。標準を作るというのはそういうことだ。
ところが、そのような標準をプロジェクトマネジメントでそう易々と作れるわけではない。その中で、ＰＭＢＯＫは本当に叡智である。ＰＭＢＯＫの原型が出てきたのは、１９８７年、第１版はそれから１０年後の１９９６年である。第１版の時代には、ＰＭＢＯＫはその名称からもプロジェクトマネジメントのツールと手法のベストプラクティス集だと考えられていた。現に、ＰＭＩの方針説明で、プロセスに傾倒していくことはないという話を聞いたこともある。ところが、２０００年版では一挙にプロセスが増えた。その後は、組織標準にはしにくいようなプロセスも含めて増え続けている。上に述べたような意味で標準になり得るプロセスを増やしているということだと思うが、プロセス指向がどこまで続くかは興味深いところである。
◆プロセスは個人的な問題であると考える人もいる
一方で、プロセスが嫌いな人もいる。日本にＰＭＢＯＫが入ってきたときにもそのような反応をした人が少なくなかったが、プロセスを押し付けられることによって、モチベーションが下がる人という人もいる。標準がうまくいく方法であっても、それが一通りではないことは周知のとおりである。標準を策定するときに、ある程度平均的なスキルレベルを配慮することが多いことを考えると、標準よりはむしろ、うまく行く方法があってもおかしくない。
このような人たちはプロセスを「個人的な問題」であると考えている。つまり、好みの問題であり、習慣の問題である。このようにとらえると、プロセスは使いやすいように変えて初めて機能する。テーラリングである。
そしてテーラリングのツールとなるのが、（ベスト）プラクティスである。このようなプロジェクトマネジメントの構築方法もある。多くのアジャイルプロジェクトマネジメント手法では、このような考え方を取っている。
◆プロセスはＰＤＣＡだけでよい
マネジメント手法であるので、本質的にＰＣＤＡのサイクルはあり、ＰＤＣＡのサイクルを実現するための基本プロセスは必要である。ＰＭＢＯＫであれば、立上げ、計画、実行、コントロール、終結のプロセス群でＰＤＣＡのサイクルを構成している。
代表的なアジャイルプロジェクトマネジメント手法の一つで、ＰＭＩの認定制度の参考図書にもなっているジムハイスミスのＡＰＭでは、構想、思索、探索、適応、終結というプロセスでＰＤＣＡを実現している。
そして、ＰＤＣＡのプロセス以外はプラクティスを使って、自由に自分のプロセスを構成していく。この自由度がプロジェクトの創造性の鍵を握っており、プロジェクトに求められてるイノベーション実現の生命線になる。
◆プロセスをプラクティスにするには自己完結が必要
ここで興味深いのは、プロセスはプラクティスになり得るかという議論だ。上に述べたように、ＰＭＢＯＫは知識体系、プロセス群という言葉から分かるように、最初はプロセスもプラクティスとして取り扱おうとしていたのではないかと思う。しかし、２０００年版では、すべてのプロセスがつながり、プロセスを欠かすとつじつまが合わなくなってきた。２００８年版では、プログラムマネジメントとの関係で、統合マネジメントの位置づけが見直され、多少プロセス指向から変わってきた。同時に、ここにアジャイルが入るので、ＰＭＢＯＫ自体がこのあと、どう変わっていくかは不明である。
少し、話が脱線したが、普通に考えるとプロセスはプラクティスになる可能性がある。ただし、それは、あるプロセスの目的が明確で自己完結していることが条件である。自己完結していないと、つまり、他のプロセスへの明示的な影響があると、結局、ＰＭＢＯＫのように実質的にテーラリングができなくなる。
◆組織的管理の視点
さて、プロセスにまつわるもう一つの視座は、組織的管理である。日本の企業のプロジェクトマネジメント導入の目的がそうであるように、組織の立場からは管理が目的である。管理には２つの意味があり、一つはプロジェクトの管理であり、もう一つはプロジェクトマネジメント活動の管理である。
これまで組織の管理の目的は品質であった。極論すれば、品質を保証するために、プロダクト品質管理、プロセス管理に続く第３の道としてプロジェクトマネジメントを導入してきたと言ってもよい。品質保証のためには、プロジェクトマネジメントがプロセス化されていることは都合がよかった。
これからも品質が重要であることは間違いないが、品質は不満足要因であり、実現できないと問題になるが、品質がよいだけでは顧客満足は得られない。プロジェクトで顧客満足を獲得し、顧客ロイヤリティを実現していくには別の価値提供が必要である。その価値は品質のように一元的なものではないが、共通しているのは顧客からの要求があれば、これまでに経験したことのないこともやらなくてはならないことだ。これはイノベーションだともいえるし、プロジェクトの本来の姿だといってもよいだろう。
このような課題に対して、組織が管理したいものは変わってくる。価値である。プロジェクトの当初に計画した価値が、どの程度実現されているかを管理し、不足があれば、介入していくことが求められるようになる。このような管理は、プロセス化してもできない。
プロセスではなく、プラクティスの中に組織が関わり、組織的な支援を投入していけるようなプラクティスを設定していくことが求められる。これができて初めて、イノベーションマネジメントが可能になる。
もう少し正確にいえば、標準があるということは、プロジェクトマネジメントのオーナーシップが存在し、オーナーシップがガバナンスを持つということだ。たとえば、会計のオーナーシップはＣＦＯにある。人事のオーナーシップはＣＨＯにある。これと同じで、プロジェクトマネジメントの場合、ＣＰＭＯ（Chief Project Management Officer）と呼ばれる。ＣＰＭＯが指示する通りにプロジェクトマネジメントを行い、それでプロジェクトがうまく行かなければ、ＣＰＭＯの責任である。プロジェクトの成功率を目標として設定し、達成できなければ責任を取ることになる。標準を作るというのはそういうことだ。
ところが、そのような標準をプロジェクトマネジメントでそう易々と作れるわけではない。その中で、ＰＭＢＯＫは本当に叡智である。ＰＭＢＯＫの原型が出てきたのは、１９８７年、第１版はそれから１０年後の１９９６年である。第１版の時代には、ＰＭＢＯＫはその名称からもプロジェクトマネジメントのツールと手法のベストプラクティス集だと考えられていた。現に、ＰＭＩの方針説明で、プロセスに傾倒していくことはないという話を聞いたこともある。ところが、２０００年版では一挙にプロセスが増えた。その後は、組織標準にはしにくいようなプロセスも含めて増え続けている。上に述べたような意味で標準になり得るプロセスを増やしているということだと思うが、プロセス指向がどこまで続くかは興味深いところである。
◆プロセスは個人的な問題であると考える人もいる
一方で、プロセスが嫌いな人もいる。日本にＰＭＢＯＫが入ってきたときにもそのような反応をした人が少なくなかったが、プロセスを押し付けられることによって、モチベーションが下がる人という人もいる。標準がうまくいく方法であっても、それが一通りではないことは周知のとおりである。標準を策定するときに、ある程度平均的なスキルレベルを配慮することが多いことを考えると、標準よりはむしろ、うまく行く方法があってもおかしくない。
このような人たちはプロセスを「個人的な問題」であると考えている。つまり、好みの問題であり、習慣の問題である。このようにとらえると、プロセスは使いやすいように変えて初めて機能する。テーラリングである。
そしてテーラリングのツールとなるのが、（ベスト）プラクティスである。このようなプロジェクトマネジメントの構築方法もある。多くのアジャイルプロジェクトマネジメント手法では、このような考え方を取っている。
◆プロセスはＰＤＣＡだけでよい
マネジメント手法であるので、本質的にＰＣＤＡのサイクルはあり、ＰＤＣＡのサイクルを実現するための基本プロセスは必要である。ＰＭＢＯＫであれば、立上げ、計画、実行、コントロール、終結のプロセス群でＰＤＣＡのサイクルを構成している。
代表的なアジャイルプロジェクトマネジメント手法の一つで、ＰＭＩの認定制度の参考図書にもなっているジムハイスミスのＡＰＭでは、構想、思索、探索、適応、終結というプロセスでＰＤＣＡを実現している。
そして、ＰＤＣＡのプロセス以外はプラクティスを使って、自由に自分のプロセスを構成していく。この自由度がプロジェクトの創造性の鍵を握っており、プロジェクトに求められてるイノベーション実現の生命線になる。
◆プロセスをプラクティスにするには自己完結が必要
ここで興味深いのは、プロセスはプラクティスになり得るかという議論だ。上に述べたように、ＰＭＢＯＫは知識体系、プロセス群という言葉から分かるように、最初はプロセスもプラクティスとして取り扱おうとしていたのではないかと思う。しかし、２０００年版では、すべてのプロセスがつながり、プロセスを欠かすとつじつまが合わなくなってきた。２００８年版では、プログラムマネジメントとの関係で、統合マネジメントの位置づけが見直され、多少プロセス指向から変わってきた。同時に、ここにアジャイルが入るので、ＰＭＢＯＫ自体がこのあと、どう変わっていくかは不明である。
少し、話が脱線したが、普通に考えるとプロセスはプラクティスになる可能性がある。ただし、それは、あるプロセスの目的が明確で自己完結していることが条件である。自己完結していないと、つまり、他のプロセスへの明示的な影響があると、結局、ＰＭＢＯＫのように実質的にテーラリングができなくなる。
◆組織的管理の視点
さて、プロセスにまつわるもう一つの視座は、組織的管理である。日本の企業のプロジェクトマネジメント導入の目的がそうであるように、組織の立場からは管理が目的である。管理には２つの意味があり、一つはプロジェクトの管理であり、もう一つはプロジェクトマネジメント活動の管理である。
これまで組織の管理の目的は品質であった。極論すれば、品質を保証するために、プロダクト品質管理、プロセス管理に続く第３の道としてプロジェクトマネジメントを導入してきたと言ってもよい。品質保証のためには、プロジェクトマネジメントがプロセス化されていることは都合がよかった。
これからも品質が重要であることは間違いないが、品質は不満足要因であり、実現できないと問題になるが、品質がよいだけでは顧客満足は得られない。プロジェクトで顧客満足を獲得し、顧客ロイヤリティを実現していくには別の価値提供が必要である。その価値は品質のように一元的なものではないが、共通しているのは顧客からの要求があれば、これまでに経験したことのないこともやらなくてはならないことだ。これはイノベーションだともいえるし、プロジェクトの本来の姿だといってもよいだろう。
このような課題に対して、組織が管理したいものは変わってくる。価値である。プロジェクトの当初に計画した価値が、どの程度実現されているかを管理し、不足があれば、介入していくことが求められるようになる。このような管理は、プロセス化してもできない。
プロセスではなく、プラクティスの中に組織が関わり、組織的な支援を投入していけるようなプラクティスを設定していくことが求められる。これができて初めて、イノベーションマネジメントが可能になる。
最近のコメント