【補助線】プロセス、行動規範、仕組み

※本ブログは移転しています。こちらをご覧ください。

エンジニアはプロセスが好きである。ある意味で当り前だ。工業製品であっても、ソフトウエアであっても、工芸品であっても、作り上げるまでのプロセスは必ずあるからだ。逆にいえば、プロセスがないとすれば再現性がなく、エンジニアリングとはいえない。

エンジニアからプロジェクトマネジャーになっていくとき、一皮むけるというのは、この信仰ともいってよいプロセスへのこだわりを捨てることだろう。

たとえば、ＰＭＢＯＫの４３のすべてのプロセスはインプットとアウトプットでつながっている。つまり、プロジェクトマネジメントを一つのプロセスで表現することが可能だと言っているようにも思える。たしかに、プロセスの「インプット→処理→アウトプット」の定義には当てはまっている。しかし、処理の内容をみればそうではないことは一目瞭然だ。処理の内容は思いっきり属人的なものがふんだんにある。というか、属人的ではない処理（ツールと手法）はほとんどない。したがって、形式的にはプロセスにしているが、再現性はほとんどない。

ＰＭＢＯＫはまだしも、プログラムマネジメント標準となると、技法とツールはすべてのプロセスに対してひとつである。つまり、インプットとアウトプットを明確にしているだけで、他は何も定義していない（これは、次のバージョンでは変わるらしいが、ＰＭＢＯＫレベルのツールと技法を指定するのは不可能だろう）。

したがって、ＯＰＭ３やＰＭＣＤＦといったメトリクス系の標準を使って、プロセスの品質を均質化させることを目指しているのだ。

これがマネジメントであり、正解がないということだ。ここで、よく認識しておくべきはこのような背景であるにも関わらず、ＰＭＩがプロセスに拘る理由はアカウンタビリティの確保だと思われる。仮に処理がなくても、インプットとアウトプットを明確にしておけば、アカウンタビリティを高めるには大変有用である。

これに対して、ＩＰＭＡはコンピテンシーを中心に標準化をしようとしている。プロセスを決めるのではなく、マネジメント行動として何をすべきかということを標準化しようとしている。

結果として、ＰＭＩとＩＰＭＡの標準というのは同じところに落ち着くのではないかと思うが、このポリシーの違いは大きいし、重要だ。トップダウンの管理をするために最も重要なポイントはアカウンタビリティの確保である。アカウンタビリティを確保した上で、あとは状況を見ながら指示していく。これが米国流プロジェクトマネジメント。（マネジメントの）行動規範を作っておき、それを実行させることで成果を生み出す。これが欧州流プロジェクトマネジメント。

もちろん、どちらの地域でも多くの企業はグローバル化されており、こんなステレオタイプの議論ができるような状況ではないのだが、なんとなく、イメージに合うのではないだろうか？

さて、日本はどうか？僕は米国流でも、欧州流でもないように感じている。日本には日本流がある。それは、何か。仕組みを作って成果を出すことだ。仕組みとはシステムである。システムとはプロセスと行動規範を合わせたものである。これが日本人の智慧だと思う。

プロセスでも行動規範でもなく、仕組み作りのプロジェクトマネジメント。エンジニアからプロジェクトマネジャーに脱皮するとはこの脱皮ではないだろうか？