カテゴリ

Powered by Six Apart

PMstyle 12月~2022年3月ZOOM公開セミナー(★:開催決定)

Twitterアカウント(PMstyle)

PMstyle facebook

« 【PMstyleコンセプト No.2】プロジェクトマネジャー2.0 | メイン | 「プロジェクトマネジメントの基本」1章を全部ダウンロードできる »

2011年8月 8日 (月)

【PMstyle Kit No.11(1/2)】メンバーからリーダーに「変化」する(前)《PMstyle》

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
【目的】プロジェクトリーダーとしてのマインドセットを身につける

【用途】プロジェクトリーダーとしての行動規範を考える

【効用】多くのプロジェクトリーダーがメンバーから昇進した初期のプロジェクトで陥っている落とし穴を防ぐ
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Tk 前回までで、カテゴリ「一般」については、主だったものは紹介し終わった。PMstyle Kitは今でも毎月1個くらいのペースで増やしているので、一般、カテゴリーで重要なものが出てきたら改めて紹介することにして、連載記事は、次のカテゴリー「リーダーシップ」に移っていく。

リーダーシップに移っていく前に、番外編(カテゴリー:PMstyle)として、PMstyleが前提にしている「メンバーからリーダーへの変化」とはどういうことかを整理しておきたい。

Visaでプロジェクトマネジャーを務める Tom Kendrick がなかなか、味のある表現をしている。それは、プロジェクトリーダーは、「Staff」と一緒に働き、プロジェクトメンバーは「Stuff」と一緒に働くというものだ。この点も含めて、プロジェクトリーダーとプロジェクトメンバーには以下のような違いがある。

 

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

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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

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

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

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

コメント

コメントを投稿