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

◆プロジェクトの３大ステークホルダはそれぞれ、対立する目的を持つ

プロジェクトには多くのステークホルダがいる。プロジェクトマネジャーからみた場合の三大ステークホルダは、チーム、上位組織、顧客である。ここで言う顧客は、プロジェクトの成果物を活用して何らかの活用する人たちである。

プロジェクトの始まりには、プロジェクト憲章を作って、目的や成果目標、前提、制約を明確にしなさいという。たとえば、ＳＩベンダーのＳＩプロジェクトを例にとって考えてみよう。顧客はプロジェクトを起こした目的があるはずだ。それは、最終顧客に対するサービスの向上かもしれないし、あるいは、原価の低減かもしれない。いずれにしても、単純に考えれば、ＳＩベンダーに支払う費用が少なければ少ないほど、顧客の目的達成の度合いは大きくなることだけは間違いないだろう。

しかし、ベンダーにはベンダーの目的がある。利益を上げること、あるいは顧客との取引額を大きくするといったことだ。ここで早くも思惑が食い違う。顧客はお金を払いたくない。ベンダーは１円でもたくさんのお金をもらいたい。

さて、ここで視点を変えてプロジェクトチームのメンバーにはどのような目的があるのだろうか？プロジェクトをうまくやることによって、目標を達成し、評価を上げることが目標かもしれない。そのプロジェクトに新技術を適用し、習得することによって、その後のキャリアにプラスにすることが目的かもしれない。

いずれにしても、そんなに簡単に両立するようなものではない。

◆プロジェクトデザインとは結局のところ、目的の整合である

しかし、プロジェクトの目的は、このようにすべてのステークホルダの目的を満たすものでなくてはならない。プロジェクトのデザインをする中で、最も難しいのが、プロジェクトの目的の設定である。

多くの場合にはこれができないので、力関係で、まず、組織が顧客に対してなき、メンバーや下請けのベンダーが組織に対してなくという構図が描かれることが多い。これではだめだということで、なんとかしてみんなが満足する目的を見つけようという話になる。いわゆるＷｉｎ－Ｗｉｎの関係というやつだ。

ここでよく考えなくてはならないのは、目的の整合のさせ方には２つがあることだ。ひとつは文字通り、Ｗｉｎ－Ｗｉｎである。もう一つは共通点だけ取るという目的の設定の仕方だ。実は日本人は後者がとても得意である。

典型的な例を示そう。ＳＩプロジェクトで、「ユーザが満足する品質の○○システムを作ろう」という目的の設定である。このような目的が１００％プロジェクトの目的であるということはあり得ない。顧客もベンダーも戦略上の目的というのが必ずある。これだけで戦略上の目的が達成できればほとんど戦略などないと言ってもよい。

◆共通部分だけすり合わせするのはナンセンス

もうお分かりだと思う。このような部分的な目的設定をしておいて、あとは、属人的、あるいは場当たり的に適当にやっていこうというのが日本流なのだ。この場合、まず、戦略など顧みられることはない。ひたすら、当事者の満足やメンツといったものが重視される。要はそれで現場は丸く治まるのだ。何も目的の合わないところを公式にやりあって、勝ち負けをつける必要もないし、Ｗｉｎ－Ｗｉｎなどどうでもよいという感覚である。

ただし、これをやると、間違いなく、最もつらい思いをするのはプロジェクトである。一生懸命にやっても評価されない、責任は全部押し付けられるなど、悲惨なことになる。非公式な意思決定をするのだから弱いものが泣くのは当然である。

これではどんなにチームビルディングをやってみても、チームの一体感は生まれてこない。プロジェクト初期の緩い間はまだよいが、後半を迎え、本来チームワークがもっとも重要な修羅場になってくると、間違いなく、チームは崩壊する。チームの一体感を引き出すためには、まず、目的設定のところにとことんこだわり、目的が合意できない限り、プロジェクトは開始しないくらいの覚悟を持つことが必要である。