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

◆神は細部に宿る＝レバレッジ

実は、あるＥＲＰベンダーが日本に進出してきたとき、少し仕事を手伝っていたことがあるのだが、彼らは、日本ほど、パッケージが向いている国はないと認識していた。

これは半分正しくて、半分誤解である。マクロにみれば、日本では同じ業界であれば企業のビジネスシステムや経営管理システムはよく似ていた。その意味で、日本の市場に容易に導入できると考えたことは正しい。

ただし、一つ、見落としていたことがあった。それは、当時の日本人には「神は細部に宿る」というマインドがあったことだ。ワークフローの大枠は同じでも、末端のユーザから直接見える部分のワークフローが異なるとか、ユーザインタフェースが使いにくいという問題が、全体をひっくり返すような問題だったわけだ。

確かに、このレベルに目を向けると、自分たちは特殊性があると考えるのは自然である。というよりも、一社一社が違う。細部を大切にすることの重要性はある。ただし、それは、その細部が「レバレッジ（テコ）」である場合に限られる。レバレッジにならない細部は、単なる枝葉末節である。やり方（プロセス）にこだわるあまり、この感覚があまりない。


◆プロジェクトマネジメントにおけるレバレッジ

この議論は、プロジェクトマネジメントの導入にもそのまま当てはまる。プロジェクトマネジメントの導入に抵抗するケースで、はやり、神は細部に宿るという発想が背景にあることが多い。たとえば、ＰＭＢＯＫ（Ｒ）を導入すると、ドキュメントの作成に時間がとられ、肝心の顧客との交渉とか、チームへの目配りとか、上位組織との連携が十分にできなくなるという節がある。

これらがプロジェクトマネジメントのレバレッジであれば、その主張は正しい。そのような活動をするプライオリティを高くすべきである。

ここで気を付けなくてはならないのは、だから、ＰＭＢＯＫは不要だという議論にはならないことである。あるいは、「役立つところだけを使う」という発想をするのも、あまり適切だとはいえない。


◆リスクマネジメントのつまみ食い

たとえば、多くの企業が採っているアプローチに、従来の手法は残し（形式的にだけ、ＰＭＢＯＫを導入し）、リスクマネジメントだけをしっかりと行うというアプローチがある。このアプローチでは、大きなリスクでプロジェクトが失敗していたケースは改善される。ゆえに、失敗はそれなりに防げる。しかし、要素成果物レベルの手戻りや失敗の改善はあまり期待できない。

ＰＭＢＯＫのリスクマネジメントは、プロジェクトレベルのリスクの分析と対応はプロジェクト憲章で行い、ベースラインレベルのリスクの分析と対応はＷＢＳをベースにして行うようになっている。したがって、ＷＢＳをしっかりと作成し、丁寧に分析しないと問題の発生はなくならない。プロジェクトの失敗を防ぐという目的ではなく、プロジェクトのパフォーマンスが挙げ、収益を向上するという目的では後者が必ず必要になる。

つまり、リスク分析だけをいいとこどりしても、効果は小さいということだ。


◆これからは「体系的な」独自のやり方が重要になる

自分たちに特別な事情があるときに特別なやり方をすることは悪いことではない。むしろ、これまでのような現場オペレーションの範囲だけではなく、経営オペレーションの範囲にプロジェクトマネジメントを適用する場合、競争力を持つためにはさまざまな工夫をすべきである。マネジメントのプロセスのイノベーションが求められている。

そこで見落としてはならないことは、いいとこどりをせずに、「体系的（システマティック）」にアプローチしていくことである。個々の手法だけではなく、システムそのものを「独自」に構築していかなくてはならない。

その際に、今のやり方を整理して、レバレッジがどこにあるのかをしっかりと見極める必要がある。そして、レバレッジを活かすようなシステムを作っていくのだ。


◆標準再考

そのように考えたとき、ＰＭＢＯＫに限らず、標準的なアプローチをするメリットは、システムが内包されていることにある。ＰＭＢＯＫの第１版はそのような方向性を目指さず、コンピテンシーを目指したが、結局、第４版では相当しっかりしたシステムを内包する標準になっている。特に、ＰＭＢＯＫの統合マネジメントのプロセス化というのは、卓越した発想である。また、欧州においてもＩＰＭＡの提唱するＩＣＢも同じような経緯をたどっている。

その意味で、業界標準を導入するのであれば、全面的に導入しなくては意味がない。すべてのプロセスを体系的に導入し、その中でプロジェクトカテゴリーを決め、カテゴリー単位で不要なものは実施を省略する。それによって初めて、システムを維持しながら、自社の事情にあった手法を導入できる。

たとえば、大規模なプロジェクトには特別なマネジメントが必要だという誤解がある。気持ちは分かるのだが、システムとしてデザインされた手法をすべて行えば、どのようなプロジェクトに対しても対応できる。小規模のプロジェクトでは何が不要であるかを見極め、省略することによって、マネジメントのコストパフォーマンスを上げていく必要がある。


◆プロジェクトインフラストラクチャー

以上のように考えてみると、今後、重要になってくる一つの概念がある。それは、プロジェクトインフラストラクチャーという概念である。プロジェクトインフラストラクチャーはプロジェクトにおける意思決定の枠組みであり、プロジェクトの仕組みをカスタマイズするためには不可欠なものである。

詳しい説明は、PMstyle Kitで取り上げているので、そちらを参照してほしい。

プロジェクトインフラストラクチャー（グランドデザイン）


◆関連セミナー

プロジェクトインフラストラクチャーのセミナーをやります。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆プロジェクトリーダーのための意思決定力講座◆（7PDU's）
日時：2011年09月15日（木）　 10:00-18:00
場所：ヴィラフォンテーヌ汐留（東京都港区）
講師：好川哲人（プロジェクトマネジメントオフィス）
詳細・お申込　http://bit.ly/ejK0hc
主催　プロジェクトマネジメントオフィス、共催：ＰＭＡＪ
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【カリキュラム】
１．計画とは何か
１．なぜ、意思決定がプロジェクトの成功に影響を与えるのか
２．マネジメントにおける意思決定の局面
３．意思決定と組織承認の関係
３．プロジェクトマネジメントサイクルと意思決定
４．意思決定プロセスを理解する
５．プロジェクトマネジメントで使う代表的意思決定手法
６．プロジェクトマネジメントにおける意思決定
６．１　プロジェクトの目的の決定
６．２　リスクの特定と代替案の発案
６．３　見積もりの心理学と政治学
６．４　プロジェクト評価
６．５　見通しをつける
７．まとめ～プロジェクトマネジャーの意思決定力を高める
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━