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

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

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

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

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


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

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

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

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


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

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

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

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


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

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

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

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


◆標準再考

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

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

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


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

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

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

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


◆関連セミナーを開催します
━【開催概要】━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆戦略を実行するプログラムマネジメント　　　　　　　◆3.5PDU's
　 　　日時・場所：【Zoom】2024年 11月 26日（火）13:30-17:00（13:20入室可）
　　　　　　　※Zoomによるオンライン開催です。
　　　　　　　※少人数、双方向にて、演習、ディスカッションを行います
　　講師：鈴木道代（プロジェクトマネジメントオフィス，ＰＭＰ，ＰＭＳ）
　　詳細・お申込　https://pmstyle.biz/smn/program30.htm
　　主催　プロジェクトマネジメントオフィス、ＰＭＡＪ共催
　※Youtube参考動画「プロジェクトマネジメントの基礎」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　【カリキュラム】
　　　１．プログラムマネジメントとは
　　　２．戦略サイクルとプログラムデザイン
　　　３．ベネフィットのマネジメント
　　　４．ステークホルダーマネジメント
　　　５．プログラムにおけるプロジェクト間の調整
　　　　・プロジェクト間のコンフリクトの調整
　　　　・スケジュール管理とリソース管理
　　　　・リスク管理
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━