PMstyleプロデュース

【相違点１】プロジェクトメンバーは立派な解を求め、プロジェクトマネジャーは現実的な解を求める

この問題はいろいろな解釈ができるが、代表的なものは「正解を求める」ことである。エンジニアリングにおいても、必ずしも正解があるとはいえないが、完璧さを求めれば求めるほど、それは付加価値になる。

エンジニアリングにおける正解のなさは、完璧にはできないという意味あいが強く、時間をかければ正解に近づくことは間違いない。あとは品質とコスト（時間）のトレードオフの問題である。

しかし、マネジメントにおいては、時間をかけても正解に近づけるとは限らず、むしろ、「時間をかけることが価値を減らす」ことが多い。その典型が意思決定である。もう少し、早く手を打っておけばと後悔するケースのほとんどは、状況を把握していたにも関わらず意思決定をためらったケースである。マネジメントにおいて求められるのは、できるだけ早く、現実的な対応をすることである。

たとえば、ＩＴのプロジェクトでプロジェクトスコープの決定という問題がある。プロジェクトスコープに正解はない。発注者が承認すればよい。にも関わらず、発注者が正解を持っているように考え、時間をかけて丁寧に要求分析を行う。これはエンジニアリング的なアプローチである。

こういうやり方をすれば、大抵の発注者は途中で揺らぎ、要求がぶれる。マネジメント的には、要求が一定のレベルに達したところで、それでいいのだと顧客に刷り込むことだ。


【相違点２】プロジェクトメンバーはモノを相手にし、プロジェクトリーダーは人を相手にする

これが、 Tom Kendrick の「Project term member works with "stuff", Project leader works with "staff"」という有名な言葉である。もっと有名なのは、ドラッカー博士がよくいう「マネジメントとは人にかかわるものである」という指摘だ。

メンバーとして優秀な人がプロジェクトリーダーになって失敗するケースの多くは、この違いが理解できていないことが多い。この問題を「任せられない」という問題だととらえる人が多いが、必ずしもそうではない。むしろ、この問題の根源は、相違点１の立派な解を求めたがる点にある。

【相違点３】プロジェクトメンバーは専門家であり、プロジェクトリーダーはジェネラリストである

多くの企業では、プロジェクトマネジャーはプロジェクトマネジメントの「専門家」であると位置づけている。キャリア制度上、仕方のない面もあるが、日本企業でプロジェクトマネジャーが専門家であるという考え方は成り立ちにくいのではないかと思う。よく、ＰＭＢＯＫ（Ｒ）について、日本になじまないという人がいるが、なじまないのは、むしろ、プロジェクトマネジメントの専門家という考え方の方ではないだろうか。理由は２つある。一つは、プロジェクトマネジメントを専門家として位置づけ、プロジェクトマネジメント「だけ」やっていればよいとすると、組織が回らなくなる。従来、日本企業は、米国の企業ほど、ガバナンスが明確でなく、権限や責任があいまいであり、現場の裁量主義がとられてきたからだ。

この問題は、ＩＴプロジェクトで、プロジェクトリーダーが顧客の要求に対して、「それは契約外なので、私は知らない。しかるべき人に相談してほしい」といったと想像してみてほしい。何が起こるかすぐに分かるだろうし、実際にそんな対応をするプロジェクトリーダーは皆無だろう。

前置きが長くなったが、プロジェクトリーダーはプロジェクトマネジメントの専門職ではないのだ。メンバーのときの感覚で、今度はプロジェクトマネジメントの専門職だと考えた瞬間に失敗が始まる。

プロジェクトリーダーは、プロジェクト業務を推進する「ジェネラリスト」である。


【相違点４】プロジェクトメンバーは個人の目標達成を目指し、プロジェクトリーダーはチームの目標達成を目指す

この相違点は言葉ではいう人が多いが、本当に理解できている人は決して多くない。多くの人がはまっている落とし穴は、プロジェクトを任せられていることで、自分で（周囲と相談して）決めた目標がチームの目標だと考えていることである。

チームビルディングをして、「正しく」チームのゴールを決めているプロジェクトで、メンバーに個別にゴールを聞くと、「リーダーは××がゴールだと考えている」という答えが返ってくることが実に多い。合意するとは、「チームでは××を達成したい。そのために私は△△を目標にして頑張る」という状況を作ることである。

チームのゴールはチームの総意である。プロジェクトリーダーが目指すのは、チームの総意としてのゴールである。


【相違点５】プロジェクトメンバーは個人の成果を評価され、プロジェクトリーダーはチームの成果を評価される

相違点４の背景にあるのが、この問題だ。プロジェクトリーダーであるにも関わらず、個人の成果を中心に考える。自分は直接作業をしないのだし、そんなことはないと思う人は多いと思うが、実は違う。

たとえば、スケジュールが遅れてきて、このままのペースでは納期に間に合いそうにない。メンバーも疲れ気味だ。ここで、手綱を緩めず、さらに要員投入をしようとするプロジェクトリーダーは少なくない。個人の成果を上げようとしているからだ。

ここで本当にチームとして成果を上げようとするのであれば、とりあえず、休ませる。そして、みんなでパフォーマンスを上げる方法を考え、実行していく。要するに、チームとしての成果を上げることは、チームが主体的に成果を上げることであって、プロジェクトリーダーが自分の手腕をひけらかすことではない。

以上の５つが、PMstyleで考えるメンバーとリーダーの違いである。うまくいかない、多くのプロジェクトリーダーはメンバーのマインドセットや行動慣行のままで、プロジェクトをリードしている。

これを変えていくにはどうすればよいか。長くなったので、後編で解説する。