プロジェクトの「補助線」

【補助線】リーダーになるとは

本ブログは移転しました。こちらをご覧ください。

リーダーを職責、あるいは、職務化している企業が多いが、これはマネジャー職の別称に他ならない。本来、リーダーというのは結果である。それも、人が認める、つまり、フォロワーができたときに結果としてリーダーになる。

ＩＳＬの野田智義理事長、神戸大学の金井壽宏先生の言い方を借りるとこうなる

社長になろうと思ってなった人はいても、リーダーになろうと思ってなった人はいない。リーダーは自らの行動の中で、結果としてリーダーになる。はじめからフォロワーがいるわけではなく、結果としてリーダーになるプロセスの中でフォロワーが現れる。

（野田智義、金井壽宏「リーダーシップの旅」より）

ひとつ上のプロマネ。はマネジャーであると同時に、リーダーである。プロジェクトマネジャーとしては、組織がプロジェクト憲章で任命してくれる。しかし、リーダーとしては誰も任命してくれない。

多くのプロジェクトマネジャーがマネジャーとしての権限に依存し、リーダーにならないままにプロジェクトを終えている。プロジェクトマネジャー１０人にメンバーの指揮は何に基づいて行うかと聞くと、９人はリーダーシップだという（業務命令ではない）。しかし、リーダーになっていると思えるプロジェクトマネジャーは１０人に１人といったところだろう。

この現実をどう考えればいいのだろうか？

【補助線】「マネジメントには正解がない」とはどういうことか？

本ブログは移転しました。こちらをご覧ください。

「マネジメントには正解がない」

とよく言われる。これはどういうことだろう。

ある人は、山に登るのに、いろいろなルートがあるのと同じだという。天候などの不確実性があり、選択したルートが正しかったかどうかは、後になってきないと分からない。

ある人は、マネジャーの信念の問題だという。

ある人は、そもそも、正しい答えがないのだという。山登りでいえば、ルートを作りながら登るのがマネジメントなのだという。

あなたは、どう思いますか？コメントお待ちしています。

【補助線】なぜ、優秀なエンジニアが優秀なマネジャーになれないか？

本ブログは移転しました。こちらをご覧ください。

二者択一という発想（「か」の発想）がある。

二つの中からひとつを選ぶ。多くのエンジニアは嬉々としてこの仕事をする。技術者としての手腕に見せ所になることが多いので、気持ちはよく分かる。WindowsかLinuxか、接触式か非接触式か、技術Ａか技術Ｂか。エンジニアの仕事とは選択の積み重ねであるといってよいし、選択の適切さこそが、エンジニアの能力だと言ってもよい。

さて、では、ＰＭＢＯＫ「か」従来方式の管理かという技術の議論と同じように議論は意味があるのだろうか？

これはあまり意味がない。なぜか？

この答えを考える前にまず次のようなことを考えてみたい。

何か製品を構成する技術で、技術Ａを選ぶと４０％くらい、技術Ｂを選ぶと５０％くらいの可能性で製品が思ったような機能を持つとしよう。言い換えると、どちらを選んでも５０％以上の確率で、思ったものができない可能性が高い。

この状況でどちらの技術を「選ぶ」かという議論が意味があるか？多くの場合はないだろう。というよりも、このようなレベルの技術はまだ、技術とはいえず、どのように確率を上げるかという議論をしなくてはならない。新しい技術を探す、技術を改良するなど。

技術の選択が議論になるのは、８～９０％の確率でそれらの技術がソリューションになるときである。そのときに、どちらがソリューションとしてより確実に製品機能の実現に繋がるか、技術そのものの実現はどちらが容易かなどを考える。だからこそ、議論も白熱する。

では、ＰＭＢＯＫはどうか？ＰＭＯＢＫを選ぶと５０％くらいの確率でプロジェクトが成功するようになるかもしれない。従来のプロジェクト管理方法だと３０％くらいだ。この状況でどちらを選ぶかを議論しても同じくあまり意味がない。ただし、答えは違う。従来方式「も」ＰＭＢＯＫも選ぶしかない。

マネジャーの人材育成でも同じような問題がある。経験か、理論かといった議論だ。冷静に考えれば、どちらかだけで１００％人材を育てられるようなら苦労しないとみんな思っている。ところが、人材育成のコンサルをやると、必ずといってよいくらい、この問題を持ち出す人が出てくる。経験「も」理論も大切なのだ。

マネジメントと技術の違いの本質はここにある。つまり、マネジメントでは二者択一はほとんど意味を持たない。ＡもＢもという発想（「も」の発想）が大切だ。この発想ができる人がマネジャーになれる人であり、口ではいろいろといっても、結局、Ａか、Ｂかとしか考えれらない人はマネジャーにはなれない人だ。

エンジニアとマネジャーの間の、高く、乗り越えがたい壁はこの二者択一の発想を捨てられるかどうかだ。

ただし、エンジニアも高度なエンジニアになってくると、マネジメントに近い判断を求められることを忘れてはならない。技術のソリューションとしての確実性が減少するからだ。そういう意味で、Ａクラス人材ではこの壁はないといえる。逆にいえば、この壁を感じないのがＡクラス人材だといえるかもしれない。

さて、最後に問題をひとつ。二者択一では、問題発見（あら捜し）が重要だ。二者択一でない場合では、何が大切か分かるだろうか？

今週のＰＭサプリはアップルＣＥＯのジョブスに学び、このテーマを取り上げている。

この話に興味がある人はこちらからご購読を！

【補助線】第８の習慣

本ブログは移転しました。こちらをご覧ください。

第８の習慣

５年来、プロジェクトマネジャーのＰＭコンピテンシー（行動特性）として

第１：プロジェクトの目的を常に考える
第２：ステークホルダと共通認識を作る
第３：チームを成長させる
第４：常にゴールまでの道筋を示す
第５：リスクを楽しむ
第６：顧客視点で品質を考える
第７：主体的に行動する

を言ってきた。これは、いろいろな仕事や取材の中で、１０００人くらいの「できる」プロジェクトマネジャーにお会いして、調査したり、インタビューしたり、分析する中で創り上げてきたコンピテンシーモデルである。

いわばこれが、好川の「ひとつ上のプロマネ。」像である。

昨日、ＰＭＡＪで佐藤義男さんが主宰される「プロジェクトマネジャー成功の条件」というベンチマーキングのＳＩＧのミーティングに参加して議論しているときにも改めて感じたのだが、そろそろ、第８の習慣というのが必要になっているのではないかと思う。

昨日の議論でも話題になったが、プロジェクトの成功を語るときに組織、特にプロジェクトスポンサーとＰＭＯの存在や能力が無視できない現実がある。同じプロジェクトマネジャーが同じような難易度のプロジェクトに向かうときに、組織の対応でうまくいったり、行かなかったりするケースが出ているというのだ。僕も同じ事例を把握している。

組織成熟度という考え方への関心も高まってきているし、これからは組織でプロジェクトをサポートする時代だということだろう。

が、ことはそう簡単ではない。僕はプロジェクトマネジャーという「ひと」に注目してみているせいもあって、少し違った感想がある。それは、仕組みがあっても、ＰＭＯがあってもそれをプロジェクトマネジメントにうまく活用できるかどうかはプロジェクトマネジャーの資質の問題だというものである。

「巻き込む」という言葉があるが、これだ。活用できるかできないかの違いは、習慣７で言っていることに近く、主体性の問題である。つまり、プロジェクトで自分なりの絵を書いて、その中にスポンサーやＰＭＯを位置づけられるかどうかである。

その位置づけは、「レバレッジ（梃子）」でなくてはならない。つまり、十分にできないことがあってそれを補ってもらうのではなく、巻き込むことによって、より高い目標を目指す。このようなスタンスが必要である。

そこで、第８の習慣として

第８：組織をレバレッジとして使う

を追加することにした。

【補助線】なにかいいもの

本ブログは移転しました。こちらをご覧ください。

ＡクラスのプロマネとＢクラスのプロマネの違いは、おそらく、スキルではない。Ｂクラスの上半分に関していえば、コンピテンシーもでないように思う。

何か？

　　「何かいいもの」

なのだ。

３～４年前から、機会があればこの話をしている。実際に、エグゼクティブの人たちとプロマネ談義をすると、説明できないものがあると考える人は多い。また、PMstyleではかなり精度の高いアセスメントプログラムを持っているが、アセスメントでスキルやコンピテンシーが高いと判定された人の中でも、説明できない違いがあるものだ。

これをわたくしたちは「何かいいもの」と呼ぶことにしている。正体が何か分からないけどいいもの。何かいいもののキーワードはある。「期待に応える」ことだ。プロジェクトマネジメント的に、つまり、スコープだとかで定義された成果を生み出すだけでは、おそらくＢクラスのプロマネにしかなれない。Ａクラスは、多くの人の期待に応えている人だろう。

ただし、あくまでも結果としてであり、期待に応えること自体を目標にしているプロマネはやはりＢクラスなのだと思う。

こういう話を理不尽だと思う人は多いだろう。しかし、人材というのはそういうものだと思う。だから、人は最後は人に期待をするのだ。

【補助線】Ａクラスのプロマネ。

本ブログは移転しました。こちらをご覧ください。

Ａクラスのプロマネ。

大手のＳＩ企業だとどこの企業でも、プロジェクトマネジャー認定制度がある。企業によって差はあるが、おおむね、３～４段階で、段階は実績のあるプロジェクト規模というのが普通だ。

さて、人材マネジメントの世界に目を移すと、Ａクラス社員、Ｂクラス社員、Ｃクラス社員という区分がある。これもプロジェクトマネジャー認定制度を同じ発想で、能力に着目した区分である。

ところが日本ではこの考え方は合わないのではないかと思うことがよくある。日本の人間観の中には、Ｂクラスがいるから、Ａクラスがいるという人間観は根強くある。つまり、「能力の違いは役割の違いに過ぎない」という人間観がある。さすがに、最近では、ＣクラスがいるからＢやＡがいるというのは消えてきたが、僕が就職した頃は、それもアリだったように思う。

ここで言っているＣクラスとは「いくら指導しても業績が改善されない」社員のことをいうので、それはもうこのような議論では論外だとしても、ＡクラスとＢクラスは、役割だと考えることが間違いだと言えない部分がある。

一般企業でいえば、Ａクラスの集まりだと思われているコンサルティングファームでも、やはり、Ｂクラスはできる。Ｃクラスもできるそうだ。そう考えると、組織の中ではＢクラスにはＢクラスの役割があると考えるのが自然である。

日本の組織の考え方で、強い組織を作るにはＢクラス（二番手）が優秀な組織を作るとよいという考え方がある。この一番手、二番手は能力のことを言っているのではないのは明らかだ。能力のことを言っているのであれば、みんながＡクラスを目指せばよいからだ。能力以外の何かで優秀なＢクラスを必要としているのだ。

という風に考えると、そもそも、バリバリの能力を持った人材がＡクラスという定義そのものが怪しくなる。

ここでふと思うのが官僚という人種のことである。明治にできた制度だが、官僚というのは、国を成長させることに目覚めた人たちである。結果として、よく勉強し、優秀な人材が集まるようになった。が、決して優秀なのは官僚だけではない。民間にも優秀な人材はいる。違いは、民間の優秀な人材が自分（自社）の発展だけを考えるのに対して、官僚は国家のことを考えていることだ（皮肉にも、その官僚が自社のことだけを考えるようになって、民間人と同じようになりつつあるようだが、、、）。

これは立場の違いである。

ＡクラスとＢクラスの人材の違いもこれではないかと思う。話は、少しスケールダウンするが、Ａクラスの人材は自分の成長の発展を考える。Ｂクラスの人材はＡクラスの人材の描いたビジョンを実行するために自分の成長を考える。能力だけでいえば、Ａクラスの人材に勝るとも劣らない人もいる。組織からみて、Ａとか、Ｂとかいうのはそういうことではないかと思う。

さて、そこで、Ａクラスのプロマネ。とはどういう人材か？少なくとも、１０億のプロジェクトができるのがＡクラスで、１億のプロジェクトができるがＢではないだろう。もし、本気でそう思っている組織があるとしたら、その組織には明日はないと思う。単なる個人の集まりのような組織に過ぎない。

では、何か？あとは、あなたが考えて、コメントしてほしいと思うが、ヒントは２つあると思う。ひとつは、プロジェクトマネジメント自体を成長させることに目覚めた人だ。もうひとつは、プロジェクトマネジメントを企業の競争優位源泉にしていくことに目覚めた人だ。

来年度のPMstyleオープンセミナー

本ブログは移転しました。こちらをご覧ください。

年明けから、来年度のオープンセミナーの構想を練っています。

このメルマガにちなんだ「ひとつ上」シリーズを計画中です。

こんなセミナーっていうところで、何か希望とかありましたら、教えてください！

【補助線】責任の感じ方、とり方

本ブログは移転しました。こちらをご覧ください。

僕の愛読しているメルマガのひとつである経営コンサルタントの吉田繁治さんの「ビジネス知識源」で、だいぶ昔であるが、責任について面白いことを書かれていた記憶がある。

「ビジネス知識源」
http://blog.mag2.com/m/log/0000048497/

バックナンバーを探しても見つからなかったので、うろ覚えのままで紹介しておく。

「日本人は責任というのをネガティブに捉えすぎる。責任を取ると言った時は、「個人が不利益を蒙ること（例えば、会社を辞める）」を意味する。つまり、責任という言葉を持ち出すときにはそこまでの覚悟を問われることになる。このように責任というのを捉えると、誰も容易には責任は取れないので、みんなが責任を回避することに精力を費やす。また、逆に責任の追求をあいまいなままで済ますという図式ができあがった」

といったような話だった。

プロジェクトにおいても、責任回避や、責任追求をあいまいにしているプロジェクトは少なくない。トラブルプロジェクトにコンサルティングに入ると必ずといってよいくらい、責任転嫁の構図がある。さすがに名指しで誰が悪いといった露骨なものはめったにないが、プロジェクト自身に問題があるというスタンスのプロジェクトはあまりないが、要員が見つからない、顧客側に問題があるとか、組織のサポートが悪いとかいう話はしょっちゅう耳にする。

特に困るのは、自分の失敗を認めておきながら、プロジェクトは悪くないというプロジェクトマネジャーだ。「スケジュール遅延を速やかに上司に報告しなかったのは自分の責任だ。しかし、スケジュールが遅れているのはプロジェクトの問題というよりも、人の確保ができないことが問題で、メンバーは今の陣容でよくやっていることは認めてほしい」といったことを平気でいう。一見、潔いようにも見えるが、究極の責任転嫁である。

また、このような状況を嫌い、責任をあいまいなままでプロジェクトを進めている企業も少なくない。プロジェクトメンバーが互いに助け合ってプロジェクトを進めていく。責任を明確にしてもプロジェクトの中の人間関係がギクシャクするだけで、プロジェクトにとってメリットはないという言い方をする人も珍しくない。

このような状況の背景には、「責任」というのをネガティブに捉える文化がある。ネガティブに捉えていては捉えていてはプロジェクトマネジメントは成り立たない。

いずれの場合も、プロジェクトにおける責任というのを必要以上に重く考えているからだと思う。ＲＡＭを考えてもらえば分かるが、プロジェクトで言っている責任というのは、できなければそんな転地がひっくり変えるような話ではない。少なくとも、個人が不利益をこうむるべき筋合いのものではない。もちろん、責任を持ってやってもらうことは重要なのだが、仮に、任されたことをできなかったときには、「最後までやり遂げることによって責任を取る」という程度のものだ。

こういう話で思い浮かぶのは、日本の国務大臣の責任のとり方である。５年前に小泉が首相になるまでは、何か問題があれば「やめて責任を取る」というパターンだった。つまり、個人が不利益を蒙ることによってみんな納得してねというパターンだ。しかし、５年間で完全に変わった。「業務を全うすることにより責任を取る」ということを堂々と言うようになってきた。これである（安部首相になって先祖がえりしているのが気になるが、、、）
難しいプロジェクトのマネジメント、あるいは、リスクのマネジメントを適正化するためには「責任」に対する意識改革が急がれる。

この記事を書いていてふと思い出したことがある。岡部幸雄という偉大な競馬のジョッキーがいる。競馬では、Ｇ１レースの１番人気の馬に乗って騎乗ミスでもしようものなら、１００億円もの賭け金が泡に帰す。我々には想像もできないようなプレッシャーだと思うし、日本人的責任感覚でいえば、Ｇ１で１回騎乗ミスをすれば騎手を辞めなくては収まらないだろう。ところが彼は、「たかが競馬、されど競馬、Take it easy」といっていた。騎乗ミスしたら、その後のレースできちんと責任を果たすことにより騎手としての責任を果たす。

こういう責任の感じ方、とり方が必要なのではないだろうか？これがプロフェッショナルでもある。

【補助線】マネジメントできないプロジェクトマネジャーたち

本ブログは移転しました。こちらをご覧ください。

ドラッカーが発明したというマネジメント。ドラッカーは

マネジメントをその役割によって定義しなければならない

とし、役割として

　・組織に特有の使命、目的を果たすこと
　・働く人を人間的存在として活かす
　・社会的問題の解決に貢献すること

の３つをマネジメントの役割だと定義した。以来、マネジメントは、さまざまな学者、実務家によってさまざまな形で語られているが、大枠でドラッカーの定義の範囲での議論になっている。

中でも興味深いのは、戦略論のグル（大家）の一人である、ミンツバーグのエスノグラフィー（民族誌学）

ヘンリー・ミンツバーグ（奥村哲史、須貝栄訳）「マネジャーの仕事」

である。この本を読んでみても、はやり、マネジメントとは、ドラッカーの定義した役割を果たすためのさまざまな活動だという印象が残る。

ミンツバーグのエスノグラフィーを参考にしつつ、ドラッカーの定義をもう少し、具体化してみると、マネジャーの仕事というのは

　（１）ビジョンを策定し、課題、目標を設定する
　（２）メンバー全員で目標達成のためのプラニングをする
　（３）プラン実行のための組織の運営方法を決める
　（４）メンバーとコミュニケーションをし、一人ひとりの能力を発揮させる
　（５）プロセスマネジメントを強化する
　（６）目標達成に立ちはだかる問題を解決する
　（７）メンバーを評価する

の７つの集約されるのではないかと思う。成果を生み出すためにこれらを効果的に行うのがマネジメントである。

プロジェクトマネジメントはマネジメントである。プロジェクトに対してこれらの７つを行うことが仕事である。プロジェクトマネジャーはプロジェクトを任され、これらの仕事をしなくてはならない。

マネジメントはプロセスではできない。コンピテンシーを以って行うべきものである。しかし、ＰＭＢＯＫの標準プロセスなるものが膨張してくるとともに、プロジェクトマネジャーの中にはプロセスを指向するものが増えている。これが幻想だといわざるを得ない。マネジメントができないプロジェクトマネジャーになる可能性が大きい。

「ひとつ上のプロマネ。」はプロジェクトマネジャーを目指すのではなく、マネジャーを目指さなくてはならない。プロセスではなく、コンピテンシーを指向しなくてはならない。そのような視点を持って自分の能力を開発していかなくてはならない。

【補助線】プロジェクトは山登りか？

本ブログは移転しています。こちらをご覧ください。

マーケティングコンサルタントの阪本啓一さんが、メールマガジン電脳市場本舗～Marketing Surfin'で、「マネジメントの３Ｄ」ということを言われている。３Ｄとは

「意思決定（Decision Making)」

「デザイン（Design）」

「実行（Do）」

の３つのＤであり、マネジメントにはこの３Ｄが重要だというのが阪本さんの考えだ。

そして、阪本さんは「エベレストに登る」のと、会社経営をすることはどちらが難しいかという問題提起をする。

＜エベレストに登る＞

・意思決定＝エベレストに登ることを決める

・デザイン＝ルートや使う道具を決める

・実行＝実際に登る

ところが会社を経営する場合には、そこに山はないので、山を作ることから始めなくてはならない。すると、次のような感じになる。

＜会社を経営することの比喩＞

・意思決定＝山をつくることを決める

・デザイン＝どんな山をつくるかを決める

・実行＝山をつくり、登る

このように会社経営は登るだけではなく、山をつくるところから始めなくてはならない。だから会社経営の方が難しいというのが阪本さんの考えだ。

このメルマガを読んでいるうちに、僕が今までうまく表現できていなかったことがはっきりした。

プロジェクトというのはどちらなのだろうか？

この比喩でいえば、プロジェクトは山登りであると思っている人が多い。そして、エベレストに登れるか、その辺の山に登れるかがプロジェクトマネジャーの能力であると思っている人も多い。

たしかに、どんな山を作るかは決まっている。山頂が見えていることも多い（最近は、見えないことも多いが）。

しかし、プロジェクトは山登りだと言い切ってしまうと、

　誰が山をつくるのか

という問題が残ってしまう。プロジェクトは経営（戦略）の実行部分である。これは、阪本さんの比喩を使うと、

　プロジェクト＝山をつくりながら、登る

ということを意味している。

もちろん、つくるという程度はいろいろあると思う。もろい地盤があり、それを固めながら登っていけばよいプロジェクトもあるかもしれないし、ひょっとすると、一から土を盛りながら登っていかなくてはならないプロジェクトもあるかもしれない。

このときに、山を作るのは「経営の責任だ、山ができてから登れといってほしい」と行ってみても何も変わらない。

「普通の優秀なプロマネ」がエベレストに登れる人だとすると、「ひとつ上のプロマネ。」は、経営がデザインした山を創りながら登れる人である。