本文へスキップ

イノベーション実践、コンセプチュアルスキル、プログラムマネジメント、プロジェクトマネジメント、PMOについての最先端の情報、研修、セミナー、コンサルティングをお届けします。

開催決定セミナー

(本社)0774-28-2087

(携帯)080-2441-0805

No11. メンバーからリーダーに「変化」する《PMstyle》(2011.08.10)

プロジェクトマネジメントオフィス 好川 哲人

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

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

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

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

前回までで、カテゴリ「一般」については、主だったものは紹介し終わった。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で考えるメンバーとリーダーの違いである。うまくいかない、多くのプロジェクトリーダーはメンバーのマインドセットや行動慣行のままで、プロジェクトをリードしている。

これを変えていくにはどうすればよいか。

◆コミュニケーションに意識を集中する

プロジェクトリーダーにとってもっとも重要な仕事は何か?多くの人はコミュニケーションだと答えると思う。メンバーからリーダーになったときに、まず心がけるべきことは、コミュニケーションに意識を集中することである。

プロジェクトリーダーのコミュニケーションの重要性を示すデータに以下のようなデータがある。

あるIT企業でプロジェクトマネジャーの仕事時間の調査をしたところ、調査対象の80%以上のプロジェクトマネジャーが70%以上の時間をコミュニケーションに費やしていた。

ただし、70%の時間の配分はプロジェクトの特性や本人の考え方によってまちまちだった。ある人は、70%のうちの80%を顧客とのコミュニケーションに費やし、あるプロジェクトマネジャーは70%のうちの60%を上司や他部門の部門長とのコミュニケーションに費やしていた。全体的に、50%以上の時間をメンバーとのコミュニケーションに費やしているプロジェクトマネジャーはほとんどいなかった。多くのプロジェクトでは、プロジェクトマネジャーとメンバーの間に中間層になるチームリーダーがいるというのがその理由だった。

この組織では、生産性の観点からこの点を問題視しており、この後、コミュニケーションの比率を変えていった。生産性、顧客対応、社内調整のバランスがよいのは、「プロジェクトの特性にほとんど関係なく」

・チーム:50%
・顧客対応:30%
・組織対応:20%

くらいだというところに落ち着いている。


◆プロジェクトリーダーが行うべきコミュニケーション

コミュニケーションは、いくつかに分けることができる。

一つは、情報管理である。状況の収集、情報配布、実績報告などが該当する。情報管理の中には、データを情報にし、重要な情報だけを伝えるフィルタリング、データの要約、一見して意味が分かるデータへの変換といった情報編集も含まれている。

二つ目は、指導である。指導はメンバーの行動を正すことを目的としたコミュニケーションで、

・フィードバック
・コーチング

などが含まれる。

三番目は、動機づけやストレス解消などを行うコミュニケーションである。この種のコミュニケーションは上の2つとは少し異なり、結果として動機を持たせることができたり、ストレスが解消したりする。その意味で、これらを目的としてコミュニケーションをしているわけではない。


◆リーダーシップと動機付けの方法を身につける

つぎに、メンバーを牽引する方法と、動機づける方法を習得する必要がある。前半に述べたように、プロジェクトリーダーは人間指向である必要がある。たとえば、リーダーシップを考えてみよう。人間指向でなければ、自分のリーダーシップスタイルをもち、そのリーダーシップスタイルでメンバーと接していけばよい。これはスキルを持った技術者がモノに対する接し方と同じだ。

このようなスタイルをとるリーダーは、結局のところ、メンバーに自分のワークスタイルを押し付けていることが多い。重要なことは、自分がどのようなスタイルが得意かではなく、チームのパフォーマンスを上げるには、どのようなスタイルをとるべきかである。たとえば、新入社員を集めたチームと、会社に入って全員20年以上たっているメンバーを集めたチームを同じように扱って、同じだけの動機を持って仕事をしてくれることはありえないというのはすぐに分かると思う。

リーダーシップスタイルは、極論すれば、チームに動機を与えるにはどうすればよいかを考えて決める。たとえば、技術的に非常にたけたリーダーが、技術的な介入をし、メンバーのモチベーションを下げてしまう例は枚挙にいとまがないが、これはどのような事情があっても好ましくない。メンバーにレスポンシビリティをゆだねたからには、メンバーの動機を高めることによって、苦境を乗り越えていかなくてはならない。

また、プロジェクトリーダーによっては実務的な理由、つまり、放っておいても一人で仕事ができるかどうかでリーダーシップのとり方を判断しようとするが、これもある意味で適切ではない。たとえば、ベテランのチームでも、燃えやすいチームであれば、煽るべきだ。

どのようなスタイルを取ろうと意識しておくべきことは、権限によらない影響力を与えることが必要だということだ。そのために有効な方法が、コーチングやメンタリングである。これらの手法はプロジェクトリーダーになったからには身につけていくべきである。


◆「計画」を重視する

三番目は、計画を重視すべきである。メンバーにとって計画は、自分に与えられる課題になる。そのため、最終的に納期どおりにできればいいんだろうと考え、計画を軽視する傾向がある。

プロジェクトリーダーになってもこの感覚を残したままで、結局、最後はモノ(成果物)ができればよいと考えてしまう。この発想を捨て去らないとリーダーにはなれない。

計画はメンバーを動かすための手段である。従って、自分としては、メンバーにどのように動いてほしいかを練り上げ、それを計画に落としていくべきである。

同時に、プロジェクトの状況を客観的に図るツールでもある。その意味でも、精緻に考えて、計画を策定すべきである。


◆ビジネス的な理解と洞察

最後に、リーダーはビジネス的なプロジェクトの背景をしっかりと把握しておかなくてはならない。これは、プロジェクト要求、プロジェクトスポンサーの持っている見通し、ステークホルダの期待マネジメントなどで可能である。

そして最終的には、プロジェクト投資や、予算にそれらがどのように反映されているかを洞察して置くことが必要である。

◆関連するセミナーを開催します
━【開催概要】━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ コンセプチュアルなチームを創る           ◆7PDU's
  日時:2017年 09月 26日(火)  10:00-18:00(9:40受付開始) 
  場所:ちよだプラットフォームスクウェア(東京都千代田区)
  講師:好川 哲人(株式会社プロジェクトマネジメントオフィス)
  詳細・お申込 http://pmstyle.biz/smn/conceptual_term.htm
  主催 プロジェクトマネジメントオフィス、PMAJ共催
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【カリキュラム】
  1.チームを作る
  2.コンセプチュアルなチームは本質にこだわる
  3.コンセプチュアルシンキングで創造的かつ生産的なチームを作る
  4.コンセプチュアルなリーダーシップ〜チームの質のマネジメント
  5.コンセプチュアルなチームワークエクスサイズ

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

著者紹介

好川哲人、MBA、技術士
株式会社プロジェクトマネジメントオフィス代表、PMstyleプロデューサー
15年以上に渡り、技術経営のコンサルタントとして活躍。プロジェクトマネジメントを中心にした幅広いコンサルティングを得意とし、多くの、新規事業開発、研究開発、商品開発、システムインテグレーションなどのプロジェクトを成功に導く。
1万人以上が購読するプロジェクトマネジャー向けのメールマガジン「PM養成マガジン(無料版)」、「PM養成マガジンプロフェッショナル(有料版)」や「プロジェクト&イノベーション(無料」、書籍出版、雑誌記事などで積極的に情報発信をし、プロジェクトマネジメント業界にも強い影響を与え続けている。

メルマガ紹介

本連載は、PM養成マガジン購読にて、最新記事を読むことができます。

コンセプチュアルスキル診断

サイト内検索

お薦めする書籍

メルマガ購読

公開セミナー(カテゴリー別)
日付順  カレンダー

すべてのセミナーが企業研修に対応できます。お問合せください。

ブログ

PMstyleプロデューサー

プロジェクト・イニシアチブ

Facebook

Facebook

Twitter

PMコンピテンシーとは