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

◆正しいプロジェクトマネジメントは、プロジェクト成功の必要条件

このようなベストプラクティスは、テンプレートやプロセスに反映されている。たとえば、ＰＭＢＯＫはこのようなベストプラクティスの実現をするためのマネジメントのプロセスや手法をまとめたものになっている。

そのため、ＰＭＢＯＫのプロセスや手法を忠実に実行していくとうまく行くと思っている人たちが多い。実際に、ＰＭＢＯＫ（Ｒ）のプロセスを忠実に実行していくと、プロジェクトマネジメントはうまく行く。

しかし、プロジェクトがうまくいくというものではない。上に述べたとおりだ。

たとえば、コミュニケーションマネジメントを忠実にやっていると、情報共有齟齬はできるだろう。しかし、良好なコミュニケーション関係が構築できるとは限らない。たとえば、組織内のコミュニケーションはうまくできるが、顧客とのコミュニケーションがうまく行かないというのはそういうケースが多い。

二番目の問題解決については、形式化すらあまりできていないところだ。変更管理などで、問題解決のプロセスは形式化されているが、実際にどのような考え方で問題を解決すればよいかは、プロジェクトマネジメントの問題ではない。

このようにプロジェクトマネジメントをきちんと行うことは、プロジェクトを成功させるための必要条件であっても、十分条件ではない。ひょっとすると、必要条件ですらない可能性もある。プロジェクトは現場のマネジメントであり、与件の問題解決だと割り切るのであればプロジェクトマネジメントをきちんとすればよいわけだが、経営に貢献しようと思っているのであれば、それでは不十分である。

◆プロジェクトの定義が根源的な成功要因

この点に関して、３つ目の成功要因がきわめて興味深い。プロジェクトの定義である。たとえば、フォードがトーラスを開発したときの文献を見ると、プロジェクト定義の「客観性」を問題にしている。客観的なプロジェクト定義とは、プロジェクトの目的とその完成に必要な諸活動の内容・必要性・スケジュールについて、メンバーとの間で合意をし、ドキュメント化することである。

いろいろな成功要因があっても、最終的にプロジェクトの成功はここに立ち返る。

もう一つ、考えておきたいことは、プロジェクトを定義する際に、プロジェクトマネジメントの成功とプロジェクトの成功では、考えるべき深さが違ってくることだ。

プロジェクトマネジメントの成功を追い求めたいのであれば、プロジェクト定義として、成果物を中心にして考えればよい。商品開発であれば、ある機能を持つ商品の開発そのものを目的だとすればよいし、ＩＴだとシステム開発そのものを目的だと考えればよい。

ところが上に述べたように、この目的が達成できてもプロジェクトが成功したといえるとは限らない。プロジェクトは思い通りにいかないことが多いことを考えると、プロジェクトにとっては、商品を開発したり、システムを開発することは、手段（あるいは一つの目標）であって、目的ではないことの方が圧倒的に多い。

プロジェクトの目的とは、何のためにその商品を開発するのか、何のためにそのシス
テムを開発するかである。

現場が強い企業とはそこを的確に設定できる現場を持つ企業である。いくらものづくりがうまくても、そこができない企業が現場が強い企業とはいえなくなってきた。現場が強い企業になるには、プロジェクトの成功要因を深いレベルで理解し、実践していかねばならない。