コンセプチュアル・マネジメント

プロセスがすべてつながるというのはどういうことかを考えてみるとよくわかる。マネジメントにおいては、Ａという事実とＢという事実があって、「洞察」によりＣという事実が導かれることが少なくない。「ロジック」ではない。たとえば、プロジェクトマネジャーが

Ａ：スケジュールが遅れている
Ｂ：メンバーがつかれている

という２つの事実から、

Ｃ：放っておくとどんどん状況は悪化する

という判断を導いたとしよう。一見、ロジカルに見えるが、風が吹けばおけ屋が儲かるような筋の悪いロジックで、ロジックであるとは到底言えない。しかし、現実にはこれは正しいことが多い。つまり、ＡとＢという事実に加えて、プロジェクトマネジャーのこれまでの経験から新たなロジックを追加したり、あるいは直感を加えるなど、総合的に判断をしているからだ。これを確率だけでロジックにしようとすると大けがをする。たとえば、疲れているのだが、目は死んでいないことを見逃すようなことになる。

話が脱線するが、最近、ある研修で「総合的に判断する」というのは政治家とか、経営者といった偉い人のごまかし言葉だと言い切った若者がいた。ロジック以外はごまかしだというのは不見識も甚だしい。洞察というのはロジックや五感すべてで行うものだ。第六感も重要である。

◆マネジメントプロセスは本質的につながらない

話をもとに戻す。マネジメントで行う判断というのは上のような洞察が入るものがほとんどである。いくら、メトリクスを細かくして客観化しようとも、必ず、ロジックだけでは構成できない。

プロセスは決まって手順を表現したものであり、再現性があるものだ。したがって、基本的にロジックで構成できないものをプロセス化すると「ごまかし」がある。大抵は再現できないものをプロセスとして定義している。ＰＭＢＯＫではもともと、再現性のない部分はツールと技法として扱ってきた。

それから１２年後に出た第４版を見ると、プロセスである必要のないものをプロセスに仕立てて、全体をつないでいる感があるのは否めない。どこだという指摘はしないが、少なくとも２か所はある。

◆ＰＭＢＯＫの枠組みはアジャイルに適している

話が長くなったが、ＰＭＢＯＫはプロセスはあるが、プロセスも含めて知識体系、つまり、プロジェクトマネジメントのプラクティスだとみるのが自然である。

ＰＭＢＯＫがアジャイルに向いている一つ目の理由は、このような作りにある。ツールと技法、あるいは、プロセスにアジャイル的プラクティスを取り込んでしまえば、アジャイルプロジェクトマネジメントのフレームワークを作ることはそんなに難しくない。

ただし、いくつかのポイントがあると思われる。これについては、また、今度。