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

【補助線】価値観はあるか

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

◆クールビズはなぜ、難しいか

チェンジマネジメントの難しさを例えるのによく使われる例がある。みなさんの会社でもクールビズをやっている会社は多いと思うが、「冷房を入れる」のと、「冷房を切る」という２つの行動の違いである。単純な話だが

　暑い
　　→　冷房を入れる
　　　　　　→　涼しくなって気持がよい
　　　　　　　　　⇒　【繰り返し行われる】

　涼しい
　　→　冷房を切る
　　　　　　→　暑くなって能率が下がる
　　　　　　　　　⇒　【やらなくなる】

という話で、冷房を入れる習慣（？）はすぐに身につくが、冷房を切る習慣はなかなか身につかないということを示す例だ。チェンジマネジメントとは、冷房を切るような習慣を作るマネジメントであることが多い。

このためには「クールビズ」といったルール（仕組み）を作ることも必要だが、ルールだけでは不十分で、地球環境を守ろうといった「価値観」が定着されて始めて冷房を切る習慣ができるという話だ。この価値観の定着にこそ、チェンジマネジメントの本質がある。

◆プロジェクトマネジメントが定着しない２つの理由

これをプロジェクトマネジメントに例えてみると、なぜ、定着しないかがよくわかる。大きな理由は２つある。

一つ目は、繰り返しが行われるループの経験、つまり、成功経験がないことだ。プロジェクトマネジャーのＡ氏は、プロジェクトマネジメント批判の先鋒だった。しかし、あるプロジェクトでしぶしぶやったリスク識別と、リスク対策の策定が、窮地を救った。この中で、リソース調達のリスクについて言及しており、その計画をレビューした上司が密かに根回しをしていてくれた。これで、実際にショートし、相談したら、すぐに「Ｂさんに相談しろ」といわれ、簡単にリソースが確保できた。これまでだと、期待せずに一応相談はするといった感じだったのだが、目からウロコだったそうだ。これを契機にＡさんは、計画の共有を主眼にきちんとした計画を書き、いろいろな人の意見を聞くようになった。

もう一つはやらなくなるループがあること。例えば、「作っても使わない」というのが多い。苦労して計画書を作るにも関わらず、自らも含めてほとんど計画書を使うことはない。実際にスケジュールがずれてもマイルストーンでつじつまを合わせればよいし、上司もそれ以外のタイミングではプロジェクトの状況を聞くくらいで、進捗として計画を使うことがない。それでも最初はルールがあるので形式的にも計画書を作っているのだが、顧客の都合ですぐにプロジェクトを立ち上げたいといった状況に遭遇するのを機に、計画を作るのをやめてしまった。

◆問題を解決するには

うまく一番目のような成功経験ができれば、二番目の問題は解決する。というか、実際に計画を使っていることが実感できる。しかし、成功経験がないと、二番目の問題を解決するのは冷房の例と同じくやっかいである。プロジェクトマネジメントを行うことへの価値が必要だ。

このためにはまず、価値観を明確にする必要がある。プロジェクトマネジメントを行うことが自社や自組織にとってどういう意味があるかを明確にし、それをやらないと何が起こるかを明確にする。

できれば、これを支持するストーリーなどがあるとよい。

その上で、７月９日のコラムで述べた定着化のサイクルの中で、「教育」と「奨励」の中で、価値観を実感できるような工夫をしていく。教育では、特にトラブルマネジメントの教育を価値観を埋め込んで行うことが効果的である。奨励では、価値観に沿った行動をとった人を誇らしい気持にさせるような報奨を与えるといった方法が考えられる。

【補助線】プロジェクトが満たすべき前提条件

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

ＰＭＢＯＫの概念の中にプロジェクトの「前提条件」というのがある。たとえば、

・プロジェクト計画書に定義されてる通りにプロジェクト組織が構成される
・顧客はプロジェクトの遂行に協力する
・組織や顧客に関する課題解決はタイムリーに行われる

といったものだ。実はこれらは、誰もが疑おうとしないが、多くのプロジェクトで成立していない前提条件である。最近ではだいぶ知恵がついてきたので、これらをリスクとして扱うことが多い。前提条件の崩壊というのはそれこそ、プロジェクトを崩壊するリスクになりかねない。

多くの場合、前提条件というのはプロジェクトマネジャーは無関係なところで構成される話だ。従って、成り立つかどうかも、ある意味でプロジェクトマネジャーはコントロールできないことが多い。せいぜい、リスク要因としてあげて、監視しておくことが精一杯であるが、監視したところでコントロールできないのだから、どうにかなるものでもない。

では、かくも重要なプロジェクトの前提条件に対してもっとも影響を与える人は誰か。上の例を見てもらうとわかると思うが、上位管理者、顧客、および、ステークホルダである。

さて、逆の視点でみてみよう。プロジェクトをうまく進めるためには、「常識的に考えて必要な前提条件」というのがある。例えば、「プロジェクト要員は必要に応じて確保できる」という前提条件がある。これもなかなか、成立が難しい前提条件の一つだが、このような前提条件が崩れてしまうと、ＰＭＢＯＫというプロジェクトマネジメントの手法そのものの有効性が崩れてしまう。

そんなことはない。リスクとして考えておくべきだという意見もあるだろう。確かに、「十分なスキルを持った要員が必要に応じて確保できる」ということを前提条件にするのであればそれは前提条件が成立しないことをリスクとして考えておくべきだ。しかし、上の例は、前提条件の不成立を受け入れるということはプロジェクトマネジメントをしないということに他ならない。

言い換えると、目標を設定し、目標を達成するためのマネジメントが機能するためには一定の条件がある。実は、一番の前提条件は、「目標が達成可能である」ということなのだ。ここすら前提条件になっていないプロジェクトがときどきある。この議論を見積もりの議論だと思うと間違いだ。背景にある程度の見積もりがあることは間違いないが、見積もりというのは所詮「過去の実績に基づく推定」に過ぎない。従って、目標が達成できるかどうかと、見積もり上のつじつまがあうかどうかはそんなに一致しているものではない。「一致しないのでプロジェクトだ」という言い方もできる。むしろ、重要なのは、できそうだという点について主要ステークホルダの合意があることだ。これが「目標が達成可能」という状態の他ならない。

そのような意味で目標を捉えたときに、「目標が達成可能である」は不可欠の前提条件である。

これ以外の前提条件は、むしろ、不成立があったときにカバーすべき条件だといえなくもないが、ただ、プロジェクトマネジメントではやはり、前提にしているものがある。例えば、
　「計画書は実行されるようにメンバーも含むすべてのステークホルダが努力する」
　「計画通りに実行されればプロジェクトは企業に利益をもたらす」
といった前提条件がある。これが成り立たなければ、ＰＭＢＯＫ流のプロジェクトマネジメントなど成り立たない。こういうのがマネジメントが機能するための一定の条件であり、マネジメントが機能しないというのはリスク以前の問題だ。

そのように考えると、このような前提条件のかなりの当事者は「プロジェクトスポンサー」や「組織の上位管理者」である。交渉責任や指導責任までを入れると、ほぼ、すべてについて責任を持つべきなのはこの２者になるだろう。例えば、ＳＩの受注プロジェクトで当初から顧客に全く協力の意志がないとすればこれはプロジェクトマネジャーの責任とはいえない。受注をしてきた組織の上位管理者の責任である。

このようにマネジメント上、不可欠だと思われる前提条件をクリアするのがプロジェクト環境創りである。ここをしっかりとやっていくようなプロジェクト支援体制を作ることが急務である。

【補助線】管理者は失敗から学び、マネジャーは成功から学ぶ。

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

拓真さん（２９歳）から戦略ノート５５回にメッセージを戴いた。以下に、引用させていただく。

===
先日、とあるセミナーを聴講した際、講師の方がこんなことを言っておりました。
「失敗から学ぶようでは二流。一流は成功から学ぶ」と。
===

※　戦略ノート５５回「失敗は繰り返す」
　　　　http://www.pmos.jp/honpo/note/note55.htm

この違いだと思う。拓真さんが話を聞かれた講師さんの言われていることに賛成である。失敗から学んでいる限り、一流にはなれないと思う。失敗をしなくなるだけだ。それだけでは一流とはいえない。

僕は、１０のプロジェクトを全部失敗しないでできる（期待どおりにできる）プロジェクトマネジャーは、高く評価すべきだと思うが、一流だとは思わない。このような人は、たぶん、永久に期待を上回る成果を結果を残すことはないだろう。失敗しない方法は知っていても、成功する方法はしらないからだ。

１０のうち、９つ失敗してもいいので、ひとつだけでも、意図して期待をはるかに上回る結果を出せる人こそ、一流だと思う。成功する方法を知っているからだ。組織は必ずしも成功を求めていないので、評価はされないだろうが、、、

ただし、ひとつ、付け加えたい。自身の失敗から学ばないのは三流以下だ。

さて、メルマガで、管理とマネジメントの違いという議論をずいぶんしてきた。最近、しなくなったのは、僕なりに結論にたどり着いたと思ったからだ。

　　管理は失敗から学ぶ。マネジメントは成功から学ぶ。

【補助線】定着化サイクルの作り方

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

◆定着化サイクル

前回、プロジェクトマネジメントの普及においてマーケティングの発想が重要だと述べた。今回は、もう少し、話を進めて、どのようなマーケティング活動を行い、定着化サイクルを構築していくかを考えてみたい。

ＰＭＯによる定着化のサイクルはどこでもやっているように

　通知　→　教育　→　奨励

という３つのステップが基本になる。程度の差はあっても、これはどこの組織でもやっていることだろう。おそらく多くの方は、サイクルを見て、

　標準やツールの開発　→　通知　→　教育　→　奨励

という流れを思い浮かべられたのではないかと思う。

◆プロダクトアウトでは標準は定着化しない

前回も述べたが、手法や標準の展開をする際に、まず、作って、それを組織内のプロジェクトやあるいは機能組織に知らせていくというやり方はあまり適切とはいえない。製品でいえばプロダクトアウトというやり方である。これでは関心が高まらないばかりか、「また、勝手にやることを増やした」などということで反感を買うのが関の山である。

通知や教育は標準を開発する中で展開していく。つまり、

　通知　→　教育　→　奨励
　↑　　　　↑↓
　標準やツールの開発

という進め方をしていくことが必要である。これはマーケットインの発想である。

◆タウンミーティングで通知と教育を行う

もっとも重要なのは通知を行うタイミングと内容である。これは、開発をすることを決めた段階で第一報を行うことが望ましい。この段階で、なぜ、その開発アクティビティを行うのか、それがどのようにメリットをもたらすのかといったことを明確にしておく。

と同時に、その段階から教育を行う。ここにもうひとつのポイントがある。ここでいう教育は標準の使い方そのものではない。この段階では、その標準が入ったときにプロジェクトマネジメントがどのように変わって行くかを教えるような教育である。従って、長時間をかける必要はない。１時間でもいいので、プロジェクトマネジャーに集まってもらい、背景説明を行い、また、方向性について意見を求める。このためには「タウンミーティング」を開催するとよい。

日本では、タウンミーティングというと小泉内閣のときに開始されたが、やらせ問題や不適切な経費使用であまりよいイメージがないが、タウンミーティングは米国のニューイングランド地方で実施されている

各州によって形態は異なるが、概ね「町」単位で1年に1度開催され、住民の参加により予算、法律、その他自治体に関わる今後1年間の事項を採決する（Wikipedia）

という地方自治体の意思決定方式である。

◆自己決定の形を作ることがポイント

つまり、プロジェクトマネジメントに関する標準を策定することは組織ガバナンス上はＰＭＯの仕事であるが、その定着や効果を考えた場合には、特にプロジェクトマネジャーの「自己決定」の形を作ることが極めて大切である。

従って、もし社内にコミュニティがあればコミュニティを徹底的に利用することが重要であるし、なければタウンミーティングのような場を作る。これにより、通知と教育を行うと同時に、パイロット実施も含めて標準の評価をして、洗練させていく。このサイクルをまわしていかない限り、いくらツールを準備しても、いくらレギュレーション化をしても、その標準が有効に機能する ことはないだろう。

◆マーケットアウトを目指して

このような仕組みが定着してくれば、継続的改善の仕組み作りの可能性も見えてくる。継続的改善の仕組みを作るためのポイントはマーケットアウトの発想にある。これは次回。

◆マーケティング用語の説明
プロダクトアウト：自分たちが持っている技術などでできる商品をつくり、市場に出す
マーケットイン：市場の声を聞いて商品にして市場に出す
マーケットアウト：自分たちが顧客の立場で一般顧客が想像しない商品を考え、市場に出す

【補助線】祇園・「置屋」のマネジメントに学ぶ

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

◆はじめに

２年くらい前に、ある講演でしゃべって、後日、主催者に電話で抗議をしてきた聴講者が出てきたので、封印している話がある。

　置屋発想で、プロジェクトマネジメントはうまく行く

という話。このメルマガの発刊を機に、封印を説きたい。

◆置屋とは何か

置屋というのは祇園にいけば普通に使っている言葉だが、一般にはなじみがないかもしれないので、ちょっと説明しておく。

置屋とは芸者が生活する場所である。置屋は部屋と食事を提供する「おかみ」と呼ばれる女主人によって仕切られている。芸者は１５歳くらいでこの世界に入ってくると、まずは置屋に身を置き、そこで生活をしながら、芸や座敷でマナーを身に付けていく。置屋に入り、１年くらいたつと、舞妓になる。舞妓になると、先輩である芸子（芸妓）と一緒にお茶屋に呼ばれてお座敷に出て、お座敷での振る舞いを覚えると同時に、お客さんに顔を覚えてもらう。そして、５年もすれば芸子になっていく。

この過程で、舞妓時代の生活費、稽古代などを一切合財面倒を見るとともに、芸子になった後のマネジメントをするのがおかみである。特に芸子になったあとは、おかみは芸子の付加価値を高めることに全力を尽くすそうである。お客を選ぶ、お客や御茶屋との間にトラブルが発生すれば仲裁すると同時に、芸者としてのあり方を指導し続けていくらしい。

芸子全員というわけではないが、芸子の中には、いずれは自身の置屋を持って生きてこの世界で生きていく人もいる。つまり、次世代のおかみの育成に全力を尽くすそうだ。もちろん、そのことが自身の利益を最大化する方法に他ならない。

◆日本型経営は置屋経営である

日本組織では、従来、置屋のような経営が行われてきた。それが人を育て、また、事業や企業の成長、利益をもたらしてきた。高度成長期という構造的な成長時期が終わった際にこの経営の弊害が強調され、否定してきた。しかし、冷静に考えてみれば、単なる疲労制度であって、それが経営環境の変化と同時にやってきたのではないか？ここをもう一度、考え直してみる必要がある。

そのような思いが強くなってきたのは、米国式の経営の中で、スポンサーシップがだんだん重視されるようになってきたからだ。リーダーシップからスポンサーシップに重心が移ってきているといっている人も少なくない。日本企業ではリーダーシップの不足が叫ばれ、この１０年くらい急速に関心が高まってきたが、置屋を見ればわかるように、日本の社会はリーダー社会ではなく、スポンサー社会である。リーダーシップよりスポンサーシップを重視してきた社会だ。今後、欧米型の経営もこちらに進んでいくのではないかと思われる。

置屋システムを

　　芸者＝プロジェクトマネジャー
　　おかみ＝プロジェクトスポンサー

と考えてみると、まさに、これからのプロジェクトマネジメントの考え方そのものだ。

◆置屋システムは専門力を高めるシステム

こういうスポンサーシップを中心にしたやり方は生ぬるいと思う人もいるかもしれない。しかし、それは大きな間違いだ。プレジデント社の「ビジネススクール流知的武装講座」の中に、神戸大学の加護野忠男教授の「京都・祇園に学ぶアンバンドリングという手法」という記事がある。これによると、多くの花街が衰退していく中で、祇園が残っているのは２つの秘密があるという。

ひとつは加護野先生がアンバンドリングと呼ぶコンセプトで、接客のサービスを徹底的に分解（アンバンドリング）し、アウトソーシングしている。京都は大阪や東京とは違って、御茶屋と置屋を分離している。一緒にすると一流の料亭に所属している芸子は芸を磨かなくても客が来るので、芸を磨かなくなる。ところが分離されていると、御茶屋（料亭）から声をかけてもらうために芸子でいるうちはずっと芸を磨くというのだ。

そして、もうひとつの秘密が、教育、特に基礎教育の充実だという。教育の中心におり、継続的に芸を磨くための支援をするのがやはりおかみである。舞やお囃子、お茶などのお稽古に行って夜はお座敷を務める忙しく動き回る芸子や舞妓の時間管理や雑務の代行などをしているのだ。

米国型の経営を見ていると、勝つまでは努力するが、勝ってしまえば果実の摘み取りにかかる。これも製品開発競争など全うな手段で行われている分にはよいが、Ｍ＆Ａでどんどんやっていると顧客には全く利益がない。ゆえにいつかは見捨てられる。この典型が自動車業界だろう。これに較べるとスポンサーシップを基盤として、常に顧客の方を向いている日本型経営はより進んだ経営だといえよう。

◆芸者遊びでベンチマーキングしてみよう！

このほかにも置屋にはプロジェクトマネジメントの成熟のために学ぶべきマネジメントがたくさんある。

例えば、置屋にはメンタリング制度があることだ。舞妓にはめいめい、修業中に手助けをしてくれる「姉さん」がついている。こうして芸者としての伝統的な知識は受け継がれていくのである。これも置屋という母娘、姉妹といった家族制度を基礎とした関係でもって成り立つ組織ならではのことだといえる。プロジェクトマネジャーはこのように育てたいものだ。

もうひとつ、置屋には面白い要素がある。幇間（「たいこ」）もやはり、置屋で属している。幇間は宴席やお座敷などの酒席において主や客の機嫌を取り、自ら芸を見せ、さらに芸者・舞妓を助けて場を盛り上げる専門職。これをＰＭＯだといったら怒られるだろうか？
興味があれば、ぜひ、一度、祇園で遊んでみましょう。ちなみに、京都のしきたりで有名な「一見さんお断り」というのは、御茶屋の文化です。紹介者が必要です。

【補助線】タレント獲得競争

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

プロジェクトマネジャーで、組織、あるいはリソースマネジャーからの要員の供給に不満を持っていない人は珍しいだろう。プロジェクトマネジャーにインタビューすれば、大抵はここに不満を持っている。

しかし、突き詰めて考えれば、チームマネジメントのスタートは要員の獲得から始まるのだ。どれだけいい人材が取れるかはどう考えても競争だろう。

組織から供給されるメンバーは制約条件である。というのは、どう考えてもおかしい。制約条件であってはならない。他のプロジェクトに負けないように、必要な人材を奪いとってくる。これが普通の感覚ではないかと思う。

ただ、この人材獲得競争にはとてつもないエネルギーが必要だ。だから、人材は与えられるものだと考えたくなっているのではないか。こんな覚悟でプロジェクトをやっても、成功するとは思えない。

覚悟をし、まずは人材獲得競争に勝つ。これはプロジェクトマネジャーの真っ先にすべきことである。

「そんなことをしたら他のプロジェクトが困るんじゃないか」と思う人もいるだろう。それはあなたの考えることではない。組織の中でそのような発想をするのはある意味で偽善である。あなたの考えるべきことは、自分のプロジェクトを成功させることである。

そのためには、他のプロジェクトは頓挫してもよいので、自分のプロジェクトに必要な人材を獲ってくることだ。

【補助線】プロジェクトマネジメントの定着化

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

◆問題を複雑に考えていないか？

仕事柄、多くのＰＭＯとお付き合いをしている。その中で常々感じているのが、プロジェクトマネジメントの導入という問題を複雑に考えすぎているのではないかということだ。

導入した手法や標準が使われないという問題と、マネジメントとして何をすればよいかという問題を混乱していため、どんどん深みにはまっているようなケースをよく見かける。

典型的パターンに

　手法を導入した
　　　→　なかなか実践されない
　　　　　→　原因を分析すると確かに一理ある
　　　　　　　→　では、その原因を解消する手を打とう

というパターンがある。例えば、

　見積もり標準を作った
　　　→　あまり使われていないようだ
　　　　　→　精度がイマイチだというのがプロマネの評判
　　　　　　　→　もっと精度の高い方法を取り入れよう、ツールも準備しよう

というような感じ。

◆確認すべきこと

このパターンは山ほどあるのだが、だいたい、この手の話を聞くと、プロマネに以下の２点を確認することにしている。

・標準を知っているか
・標準の使い方（内容）を知っているか、あるいはマニュアルの存在を知っているか

最初の方はだいたい、６０～７０％は知っているというケースが多い。ところが、後者の方はせいぜい３０％である。最近、ちょっとかかわりのあったある企業などは１０％に満たなかった。だから、いくら標準の質を上げたところで、使われないという状況が変わるはずがないのだ。

これはある種の思考の罠みたいなところがある。問題分析の仮定で、デリバブルズ（ＰＭＯとしての成果物、標準など）の品質にしか、関心が行っていない。標準の質がよければみんなが使ってくれるという仮定を持って展開している。だから、そのような問題解決思考に入ってしまうのだ。

◆仮定の間違い

これは明らかに仮定が間違っている。いくらよいものを作っても、その存在が知られない限り、その標準は使われることがないという自明の理を前提にしなくてはならない。

そうすると、「使われない」という問題の分析として上のような分析を真っ先に行うだろう。仮に、使い方を知っているにも関わらず使われなかったら、これはデリバブルズの問題である。あるいは、一度、使って二度と使わないというのも同じ。

速やかに改善しなくてはならない。しかし、知らなければ、まず、知らしめるために何をすればよいかを考えなくてはならない。次に、今のものを使わせるために何をしなくてはならないかを考えなくてはならない。当たり前の話である。問題は単純なのだ。

この単純な問題を、「知らない」という単純な事実を無視して、こねくり回して複雑にしている。こんなことが起っているのではないかと思う。ストレートにいえば、単純な問題を複雑にしている。

◆プロジェクトマネジメントの導入は難しくない

こんな言い方をすれば、投げやりに聞こえるかもしれないが、プロジェクトマネジメントの導入が難しいのは、マネジメント手法そのものが難しいからではないし、また、何をすればよいかが難しいからでもない。ほとんどのケースはそれ以前の問題で引っかかっている。「知られていない」という問題だ。この問題をプロジェクトマネジメント手法の問題に転嫁している点に最大の問題がある。

これをやっている限り、どんな手法を入れようと定着しない。これは、チェンジマネジメントの問題の中核である定着化の問題だ。

よいプロセスを作ればみんなが使う。みんなが使えば、よい製品ができる。よい製品ができれば顧客が買ってくれる。今、買ってくれない顧客も製品を改善すれば買ってくれるだろう。

こんなマーケッティングレスな発想から早く抜け出したいものだ。

【補助線】プロジェクトの問題はあってはならないという考え方にこそ問題がある

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

６月８日に

問題はなかったことにしよう

という記事を書いた。この続き。

ぼくが仕組み作りの相談を受けるような企業はプロジェクトが、そうそう、うまく行くとは誰も思っていない。ところが、この現実に対する組織（マネジメント）の反応は微妙な温度差がある。

典型的な反応は、

「本来、問題はあってはならない」

という反応である。たとえば、スケジュールが遅れていることを問題視する、コストがオーバーすることを問題視する。要するに見たくない、聞きたくない。だから、一時も早く、何とかしろということになる。管理はするが、マネジメントをしないマネジャーの典型的な反応である。

これで、話が収まればよいのだが、残念ながらそうはならない。

問題があることを心情的に認めない。だから、根本的な対応を嫌がる。とりあえず、応急処置で問題を見えなくする。スケジュールが遅れれば、どの作業が遅れているかを分析し、人を投入する、スコープが膨らめば、どのくらい必要かを分析し、予算を増やすように努力する。つまり、現象を分析し、応急処置をする。これがマネジャーの仕事だと思っている。

ここまででも十分な考え違いだが、もっとまずいことがある。問題など見たくもないので、とりあえず、応急処置をすれば、その問題は片付いたとことにする。フォローすらしない。
この影響は他にも出てくる。プロジェクトマネジャーがマネジャーに報告しても、いい顔をされない。じゃあ、報告しないでおこうとなる。すると、プロジェクトマネジャー自身も問題はないと思いたくなる。リーダーの報告に耳を傾けない。なにか言ってきたら、リーダーなんだから責任を持って解決をしてくれと逃げてしまう。この構図がプロジェクトマネジャーからリーダー、リーダーからメンバーと下達され、結局、実作業をしているメンバーが全てのしわ寄せを受ける。

こうなると最悪である。

これに対して、少数派ではあるが、プロジェクトには問題があるものだと思っている組織もある。問題を解決しながら、目標を達成するのがプロジェクトであると思っている。このように考える組織やマネジャーは決して応急処置をしない。スケジュールが遅れれば、現象の分析に留まらず、その原因を考える。そして、原因に対して可能な限りの手を打とうとする。

この２つの対応は初期段階ではたいした違いはない。ものの見方、考え方程度の違いかもしれない。実際に、問題に対して、応急処置と根本原因の解決策はあまり変わらない場合も多い。しかし、結果が大きく違う。

ものの見方、考え方が違うから結果に大きな違いがでてくるのだと考えるべきだろう。

【補助線】なぜ、日本には女性ＰＭが少ないのか（その２）

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

ＰＭＩ東京の女性事務局長・永谷裕子さんに先月からメルマガの記事を書いていただいている。

ＩＴプロジェクトでのDiversity
http://www.pmstyle.biz/column/list.htm

今月の記事の中で、ご自身の欧米でのコミュニティの参加経験から、日本は女性プロジェクトマネジャーが少なく、それを増やすにはどうすればよいかを提案されている。

第２回「ジェンダー（男性・女性）の課題」
http://www.pmstyle.biz/column/diversity/diversity2.html

実は、永谷さんにこの連載をお願いしたきっかけは、１年くらい前になにかの打ち合わせのついでに、ジェンダーダイバーシティの話をしたことだった。

その後で、ブログにこんな記事を書いていた。

なぜ、日本には女性ＰＭが少ないのか
http://people.weblogs.jp/ppf/2006/08/post_08b3.html

記事は単なる問題提起だが、この問題に対する見解を書いてみる。

プロジェクトマネジャーが少ない原因は大きく分けると２つある。ひとつは、そもそもプールにいないことであり、もうひとつはプールにいても選ばれないことである。永谷さんも書かれているが、前者の問題は組織としての問題であり、現場マネジメントとしては人事施策の効果を待つしかない。

ここでは、後者の選ばれないという問題について考えてみる。女性がプロジェクトマネジャーに選抜されない理由は大きくは３つあると思われる。

（１）プロジェクトスポンサーが使わない
（２）本人がやりたがらない
（３）顧客やエグゼクティブが歓迎しない

の３つ。

（１）はまさにジェンダーダイバーシティの問題であるが、プロジェクトマネジメントにおいては、この問題は解消されている。プロジェクトマネジャーの選抜の仕組みができていれば、これは問題にならない。むしろ、（２）や（３）の問題が絡むのでややこしい。

（２）の問題が意外と多い。ただし、この問題も女性だから云々という問題ではない。男性でもプロジェクトマネジャーになりたがらない人は少なくない。その意味で、これも男女に関係なく、プロジェクトマネジャーになりたいような環境を作っていくことが先決である。これも、まずは、プロジェクトマネジメントをプロジェクト、組織ともきちんと行うことが先決であろう。

もちろん、その段階で女性特有の問題が出てくる可能性がないとはいえないが、今はその段階ではない。

（３）もっとも厄介なのは、実は（３）ではないかと思う。このような場面に今まで何度も遭遇してきた。この問題は根が深い。実は、組織のダイバーシティが最も問われるのはこのような局面ではないかと思う。ダイバーシティのある組織は、顧客やエグゼクティブに対して、リスクをとってでもスポンサーシップを持ってサポートしていく。

そう考えると、結局のところ、現場でのダイバーシティの問題は、リスクをとりたがらないという問題に帰着するのではないかと思われる。

今日は、こんなところにしておく。

【補助線】延期戦略のプロジェクトマネジメント

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

プロジェクトは有期である。ものごとの先送りはダメ。プロアクティブに取り組みなさい

プロジェクトマネジメントの教科書にもこのようなことが書いてある。できているかどうかは別にして、いまや、常識になっているといってもよいだろう。さらには、

分からないこと、決まらないことがあれば、仮説を作って進めていきなさい。

といったことを書いている本も少なくない。

昨日のＰＭ養成マガジン戦略ノートに「プロジェクトにおける投機と延期」について書いた。この視点でいえば、プロジェクトマネジメントはできるだけ投機的にやりなさいということになる。これは本当に正しいのだろうか？これがこの記事のテーマ。

ただし、裏記事。表記事は、来週の戦略ノートで書く。

プロジェクトマネジメントには２つの顔（視点）がある。ひとつはガバナンスマネジメントであり、もうひとつはチームマネジメントである。

プロジェクトマネジメントは投機的であるべきだというのは、ガバナンスマネジメントの視点から発想である。ガバナンスマネジメントを中心にプロジェクトマネジメントを捉えると、アカウンタビリティの実行がもっとも重要になる。

アカウンタビリティは事後報告では達成できない。アカウンタビリティの実行は手が打てるうちに報告する場合にはじめて意味を持つ。従って、報告も含めて、すべてのプロジェクトマネジメントアクティビティをプロアクティブに実行することが非常に重要になる。

プロジェクトは有期である。ものごとの先送りはダメ。プロアクティブに取り組みなさい

つまり、これは、ガバナンスマネジメントを前提にしたものである。また、仮説は、リスクとして管理できるので、

分からないこと、決まらないことがあれば、仮説を作って進めていきなさい。

という話になる。

しかし、チームマネジメントの視点からいえば、延期が正しい選択であることは十分に考えられる。その典型的なケースが、戦略ノートで書いている顧客のニーズを中心にプロジェクトを進めていく場合である。この場合には、延期戦略をとり、段階的な詳細化を行っていくことが望ましい。

「段階的詳細化はプロジェクトマネジメントの基本じゃないか」と思われた方も多いだろう。段階的詳細化というのは、投機戦略の苦肉の策である。しかし、ここで言いたいのは、延期戦略としての段階的詳細化、つまり、詳細化を意図的に遅らせるというプロジェクトマネジメントである。

一般的な段階的詳細化は戦略的ではない。しかし、詳細化を意図的に遅らせることは戦略的である。

別の言い方をすると、決めないことにより、スコープに対する自由度が上がる。これがプロジェクトにおける延期の意味である。

ガバナンスを重視するか、チームを重視するかによって、延期戦略の是非は変わるのだ。