第２０回（2004.05.10）　 強みと弱み（フィードバック）
◆復習 　ゴールデンウィーク前（４月２６日）にセッティングしたコメント募集記事に多くのご意見を戴いた。この記事に再録しているので、最初にもう一度、目を通してほしい。 　結論からいえば、状況の変化で、Ｋ氏の強みが弱みに変わっている。それだけの話である。大久保さんのコメントにあるとおりだ。 ◆役割の違い 　問題はなぜ、そんなことになるのかである。ここを理解しておく必要がある。「役割」が違うのだ。 　今回の話の本論と外れるが、事業において情報システムを競争力として位置づける方法は２つある。一つは、大規模な投資を行い、他者が容易には作りえないような規模のシステムの導入をすることである。この典型的な例は金融業界における８０年代からの一連のオンラインと取り扱い時間延長の流れである。もう一つは、卓越した技術を適用することによって、他社にはまねのできないような機能を実現することである。このような例は非常に多い。古くは国鉄のオンラインであり、最近だとメールマガジンのシステムや、楽天のようなモールのシステムも一つの例だといえる。 　いずれにしても、そのようなシステムの上に、卓越したビジネスモデルを実現することによって、事業における優位性を作っていくことができる。 ◆錯覚 　前者のパターンはエンジニアリングであり、プロジェクトに組織的な活動が不可欠になるのであまりないが、後者のパターンでは、特定の人の持つ技術が卓越しており、その技術を使わない限り、プロジェクトは成立しないというケースは決して少なくない。その場合、自然にその技術を持つ人がプロジェクトのリーダーになり、顧客もそれを望む。 　そのようなプロジェクトにおいて、よく、プロジェクトリーダーになろうと、プロジェクトマネージャーになろうと、自分の技術力がなければプロジェクトはできないのだから、自分の役割は変わらないと考える人がいる。これはとんでもない錯覚である。 　確かに、分担する「作業」は変わらないかもしれない。しかし、「役割」は違う。プロジェクトマネージャーになれば、システムをうまく動かすことだけではなく、プロジェクトをうまく動かすことが求められる。「一人プロジェクト」という言葉がある。一人で作業から管理まですべてを行うプロジェクトである。一人プロジェクトでも成果物をうまく作ることと、プロジェクトをうまく進めることは違う。いうまでもなくステークホルダの存在があるからだ。 ◆強みが弱みに変わる 　役割が変わるということは、求められるものが違うということである。このことすら理解できない人がいるが、多くの人は気づく。問題はその後だ。求められるものが変われば強みと弱みが変わる。前回、書いたように、ＳＷＯＴ分析というのは特定の戦略や環境のもとで分析であり、普遍的な組織能力の分析である。プロジェクトマネージャー養成塾が提案している自己ＳＷＯＴ分析も同じである。求められるものの中での自分の強みと弱みが決まる。 　Ｋ氏の場合、プロジェクトマネージャーになることにより環境が変わり、強みが弱みになってしまったのだ。具体的には、大木豊成さん、敏さん、「Ｍ氏に近いＰＭ」さんの指摘されているようなことがある。 　ここで考えておかなくてはならないことは、逆に、これらの人材特性がエンジニアとして強みかというと必ずしもそうではないだろうという点だ。ここが難しい点だ。 ◆エンジニアからＰＭへのキャリアパスは意外と難しい 　大体、エンジニアからプロジェクトマネージャーというキャリアパスがうまくいかないのは、圧倒的にこのケースが多い。逆に、エンジニアとして評価されない人は、このような問題にひっからずにすんなりとよいプロジェクトマネージャーになれる可能性を秘めているのだが、プロジェクトマネージャーを任されることが難しい。周囲も、顧客も納得しない。難しいものである。 　さらにもっと難しいのは、本来的なプロジェクト制度のインプリとしては、プロジェクトマネージャーはラインマネージャーのように常にマネージャーであるとは限らない点だ。マネージャー（リーダー）になったり、メンバーになったりすることがありうる。これも上に述べた後者のエッジ型のプロジェクトではよく起こる。このようなローテーションを成長機会に変えていく必要がある。 　このあたりの議論は、pmstyle.comの方で行いたい。ぜひ、こちらのメルマガもご購読ください！
スポンサードリンク
読者からのコメント
顧客の満足度＝ロジカルなスキルとは限らない 私たちの会社でもあるが、顧客がロジカルを好む、とは限らないといった、我々からするとやりにくいこともたびたび発生する。 こちらが作りたいものを作るのか、顧客が喜ぶものを作るのか、と狭間で悩むのがＰＭだと思います。 またそれを調整し切るのがＰＭのスキルでもあるでしょう。 そもそも技術スキルの高い人間＝優秀なＰＭ、ではないことが多いです。 自分の経験でものを考え、それを顧客やプロジェクトメンバーに押し付ける、ことはよくあるケースです。 稲穂は実るほど垂れる、と言いますが、経験が豊富になり、多くの実績が出来るほど、人の言葉、顧客の言い分・希望に耳を貸す余裕を持つ必要がある、と思っています。うまくマネジメントしないと成果は得られないのではないでしょうか。 大木豊成（４４歳・ＰＭＯ部長） M氏が開発リーダーからプロジェクトマネージャーの立場になった時に、自分のコンピテンシーの強み弱み度が変化したことに気付かなかったこと。 大久保 明彦（３８歳） 「Ｍ氏の脱線」に対する意見 マネジメントで一番重要なのはメンバを信用しているかという事に限る。Ｍ氏は内容を見る限りメンバを信用せずすべてを自分がコントロールしている。悪く表現すると間違いなく見下している。信用というのは技術力ではない。 究極の理想的なプロジェクトとはＰＭが何もしなくてもメンバが自主的に運用する状態を言うのではないか。という事はＰＭが活躍すればするほどそのプロジェクトは問題があるということに他ならない。 ＰＭのノウハウなんて二の次で「メンバ及びユーザーとの信頼関係」を築く事が第一。お互い信頼していれば喧嘩も普通にできるはず。 Ｍ氏に近いＰＭより（３７歳） 「コンセンサスと協調性を重んじる企業の風土と合わず」という点がポイントだと思います。すごい技術レベル、卓越した技術スキル、業界でも名が通っているという、多くの優れた点がＭ氏を独断に陥らせ、協調性の欠落が、組織内、対顧客との調和を欠き、ビジネスで最も重視すべきことを見えなくしてしまっていると感じます。 敏（３７歳、(株)日立製作所）
■本稿に対するご意見，ご感想をお聞かせください．■ ■は必須入力です ■コメント 自由にご記入ください ■氏名またはハンドル名 ■会社名または職業 ■年齢 才
このコンテンツは「プロジェクトマネージャー養成マガジン」としてメルマガで配信されています．メルマガの登録はこちらからできます．