コンセプチュアル・マネジメント

学習院大学の内野崇先生の著書「変革のマネジメント」の中に次のような指摘がある。

組織における階層、ルール、ならびに、ルーチン等によって人間は自然状態における「万人の万人による戦い」をまぬがれ（内外のリスクを回避）、その時々の状況および偶発性のみに左右される意思決定を行うことが可能になります

表現が難しいが、難しいことを言っているわけではない。要するに、組織の階層がなかったり、あるいはルールがなければ、組織の成員はすべてのことを全部自分で処理し、問題を解決しなくてはならないが、組織階層やルールによってこれが回避され、節目のところだけをマネジメントしておけば済むようになっているというのが内野先生の言われていることだ。

これは、組織に標準を導入する最も本質的な目的である。

ところが、必ずしも、これを良しとしない文化がある組織が多い。組織も、その成員も、「万人の万人による戦い」をしなくては気がすまないのだ。これはルールに限らず、ものづくりなどでも同じような文化があることが多い。原理的な部分から検証していかないと気がすまない。「使えるものは使う」というのは最終手段であって、できるだけ自力で作ってみる。したがって、恐ろしく時間がかかる。

ただし、これを非効率的だといって否定するというのは少し、違う。トップダウンですべてをものごとを動かしていく覚悟であれば、それでもよいが、このやり方を否定するとボトムアップ力が弱ってくる。つまりは足腰が弱ってくるのだ。

バブル経済の時代にこのようなやり方を否定してきた。ちょうど、今、否定してきたツケが回ってきている時代だと思うが、やはり、機運としては、もう一度、再構築する必要があるという認識が強い。

ちょっと河岸を変えて、ＩＴの世界に目を移すと、この議論は米国でパッケージソフトウエアが登場してきた８０年代から延々と続いている。パッケージを使うか、一から作るかという議論だ。この議論にしても、一から作る、あるいはカスタマイズをすることへの非難めいた意見の矢面に立ちながら、カスタマイズをすることをやめようという気配はない。

この議論の本質は、何を目的にしているかにある。米国人にとってはソフトウエアは単なる道具である。問題は道具を使ってどのくらいの付加価値を生むかにあると考えている。

しかし、日本人は「使いこなす」ことを目的にしている。神は細部に宿るという発想があるのだ。つまり、細部にこだわらない限り、価値創造はできないと思っている。この違いはどちらが正しいという次元の違いではない。両方ともそれで成果をあげているからだ。

マネジメントでも同じだ。神は細部に宿ると考えている人は多い。そのような人は、標準に乗っかることは良しとしない。というよりも、「万人の万人による戦い」によって初めて価値創造ができると考えているのだ。

あなたはどう思いますか？

今日はちょっと軽めの話題。

松本人志の初監督作品「大日本人」を見られた方は多いと思う。ビジネスの世界にも、怪獣とその怪獣の退治方法を書いた本がある。

ジーニー・ダックが書いた「チェンジモンスター」にチェンジモンスターという本だ。変革を実現しようとしたときに、抵抗する、新しい動きをぶち壊すといった「活躍」をするモンスターの退治方法を書いた本だ。日本語でいえば、さしむき、「抵抗勢力」といったところだろう。

パロディーではないが、プロジェクトマネジメントの導入、定着化をするときに登場してくるチェンジモンスターの行動を整理してみた。

ＰＭＯがプロジェクトに対して、支援、指導をしようとしたときに、こんなチェンジモンスターに出会うことはないだろうか？ちなみに、ジーニー・ダックはボスコンのコンサルタント（出版当時）。論理的なアプローチの一方で、感情的・心理的なアプローチもしなくては変革は成し遂げられないということなのだろう。

■タコツボドン
得意技：自分の担当を超えた視野を持つことを拒否し，「よそ者」の関与を否定する
叫び声：「プロジェクトマネジメント自体がプロジェクトの仕事ではない」、「標準を使えというご忠告はありがたいですが、我々もプロジェクトの成功を第一に検討してみますので、後はお任せください」

■ウチムキング
得意技：社内で何が評価されるかを重視し，顧客等の外部ではなく社内にすべての行動の焦点をあわせ，社内外のズレに目を閉ざす
叫び声：「顧客はいろいろと言っていますが、社内の雰囲気は悪くないし、協力的ですので、このままでうまく行きます！」

■カコボオウレイ
得意技：従来のやり方はどんなに効率が悪くても中止をできない，決断できない
叫び声：「これまでのやり方で、うまくやってきたのだから、直すべきところは直し、このやり方でやるほうが顧客も社内も安心だよ」

■ミザル・キカザル・イワザル
得意技：３匹セットになって，見ざる，聞かざる，言わざるを通し，嵐が過ぎるのを首をすくめてやり過ごす
叫び声：「また、ＰＭＯが新しい仕組みを作ろうとしているけど、どうせ今回もまた掛け声だけだ。しばらくすれば、忘れてしまう。動くだけ損に決まっている。様子見だ」

■ノラクラ
得意技：様々な言い訳を使いあの手この手で変革を回避しようとする
叫び声：「顧客の進捗を管理するというのは前例がない。前例のないやり方をすると、社内も顧客も混乱するだけだ。それで協力を得られなくなったらどうする。百歩譲って、社内や顧客が受け入れるとしても、うちのプロジェクトは人手がたりない」

■マンテン
得意技：すべての可能性をリスクを潰して１００点満点の報告書がないと動き出せず，結局，具体的なアクションは取れない，あるいは遅れてしかとれない
叫び声：「本当にリスクはこれだけだろうか？まだ検討不足じゃないだろうか？プロジェクト開始前にもう少しじっくり検討しなくては！」、「この計画で絶対に失敗しないといえるだろうか？やるからにはパーフェクトでなければ！」

■カイケツゼロ
得意技：課題の指摘やできない理由の説明は巧みだが，解決策の提言は出せない
叫び声：「協力会社以外からのリソースの調達は何度も検討したが無理なんです。その理由は５つあって．．．」

【参考資料】
モンスター名は「チェンジモンスター―なぜ改革は挫折してしまうのか? 」が出典。
得意技は「チェンジモンスター―なぜ改革は挫折してしまうのか? 」を一部編集。

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

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

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

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

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

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

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

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

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

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

◆問題を解決するには

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

◆定着化サイクル

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

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

　通知　→　教育　→　奨励

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

◆はじめに

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

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

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

◆置屋とは何か

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

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

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

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

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

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

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

置屋システムを

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

典型的パターンに

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

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

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

というような感じ。

◆確認すべきこと

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

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

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

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

◆仮定の間違い

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

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

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

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

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

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

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

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

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

６月８日に

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

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

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

典型的な反応は、

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

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

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

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

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

こうなると最悪である。

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

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

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