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

【補助線】品質絶対は思考停止

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

情報サービス産業協会（JISA）の浜口友一会長が興味深い発言をされている記事が日経ＢＰ社のサイトに掲載されていた。

http://itpro.nikkeibp.co.jp/article/NEWS/20070831/280932/

一部を抜粋すると

「止めてはいけない重要なシステムは、世の中にどれだけあるのだろうか。ベンダーや顧客、マスコミも交え、もっと議論すべきだ」

という発言。浜口会長の意見を好川流に解釈すれば、情報システムの品質マネジメントは「思考停止に陥っている」という問題提起である。浜口会長のような立場の方がよくぞ、言ってくれたと思う。拍手喝采！

プロジェクトマネジメントの方針を決める場合に、「品質は絶対」だとよく言う。これは正すべきである。コンサルティングや研修などの機会に口をすっぱくしていっているのが、「品質絶対だというな！言った瞬間に思考停止に陥る」ということだ。

実際に、コンサルにしろ、研修にしろ、書かれたプロジェクトマネジメント計画書を見ると例外なくプロジェクトマネジメント方針として品質絶対と書いている。気持ちはわからないでもないが、これは明らかにおかしい。

「プロジェクト品質絶対」

だと書くのであれば、まだわかる。プロダクト品質絶対などありえない。これはプロジェクトのスコープを決めていないに等しい。まさに、思考停止である。

プロジェクトマネジメントを少し離れるが、顧客満足について考えてもらうときに使うエピソードに、「ある会社で壁に「顧客絶対主義」だと書いてあった。顧客絶対主義では顧客は満足しないだろう」というのがあるが、品質の話もこの話に通じる。

品質絶対で顧客が本当に満足するのか？もっと大きく言えば、浜口会長の発言にあるように社会的コンセンサスとして社会が求めているものなのか？

結論を出す前に、まず、なぜ、こんな状況に至ったかを述べておく。一般的にいえば、品質コストは

　予防コスト＜評価コスト＜不良品対応コスト

という順序になる。従って、できるだけ不良品を出さないようにすることが品質コストを下げることに通じる。従って、まずは不良品を出さないプロセスや設計に力を注ぐ。それが難しい場合にはテストや検査を徹底する。それでも、どうしようもない場合にはアフターフォローに力を注ぐ。当然、順に利益が小さくなる。

ただし、この構図は商品ライフサイクルが短い場合の話であって、一定のサイクルより短くなると成立しなくなる。もちろん、「知覚品質」やブランドイメージの問題があるので一定の品質の保証は必要だが、それ以上は、不良品が出たときに対応する方が品質コストが安くなる。この典型が携帯電話のソフトウエアである。最近の携帯電話は、発売時にパッチが出ていることは珍しくない。商品の特殊性もあるが、それを顧客もそんなに大きな問題だとは思わない。むしろ、早く対応してくれる、誠実に対応してくれる方が重要だと考えているユーザが多い。

つまり、顧客が求めていない（基本）品質を提供していれば顧客満足には結びつかない。提供者はこのことをよく知るべきである。

ここで注意すべきことは、商品価格が変わらなければ、「必要のないものでも求める特性がある」ことだ。顧客満足にとって、何よりも大切なのは、余計なものを捨てることによって価格は下がるという事実を顧客に伝えることである。

プロジェクトの品質の問題に戻るが、ＳＩプロジェクトの品質にはこの視点が抜けていることが多い。テストは重要であるが、ユーザにとって重要なのはテスト結果ではなく、稼動の保証を如何にしてくれるかだ。そんなに難しいことではない。品質絶対のために、形骸化してしまった、MTBF、MTTRなどの概念を昔どおりにスコープに明確に入れることだ。

もちろん、そこでは、品質絶対などといった思考停止をせずに、仕様、コスト、納期、ライフサイクルマネジメントとの関係をきちんと検討し、バランスをとり、ステークホルダを納得できる答えを導くことが肝要である。

◆セミナー

こんなことを背景に、要求の問題なども取り入れたセミナーを開催します。

〓【開催概要】〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
　◆顧客中心プロジェクトマネジメント　　◆１４ＰＤＵ取得可能
　　日時：2007/11/12（月）10:00-18:00，2007/11/13（火）9:30-17:30
　　場所：ヴィラフォンテーヌ汐留（東京都港区）
　　講師：好川哲人、鈴木道代（プロジェクトマネジメントオフィス）
　　詳細・お申込　http://www.pmstyle.biz/smn/cdpm.htm
〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓

【補助線】プロジェクト・エグゼクティブ

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

こういう言葉が、あちこちで見られるようになってきた。ＰＭ養成マガジンでも、「エグゼクティブ版」を作った。

非常に単純に定義すれば、プロジェクト（マネジメント）エグゼクティブは、経営的な立場、あるいは組織的な立場で、プロジェクトマネジメントやプロジェクトを統制する立場の人である。例えば、プロジェクト予算の決定権を持つ人、デッドラインに決定権を持つ人といった意味合いである。つまりは、上位組織のマネジャーだということになる。

しかし、そもそもエグゼクティブとは何かと考え出すと話はややこしくなる。ドラッカー博士の本に「経営者の条件」という本がある。多くの著作を残したドラッカー博士の代表作といえる論文集だ。この論文のオリジナルタイトルは「The effective executive」である。

日経ＢＰ社の谷島宣之さんにお聞きした話だが、多くのドラッカー作品を翻訳した上田 惇生先生によると、会社役員などをさす言葉ではなく、「人（上司）に言われたこと以上の仕事をする人は新人であろうとエグゼクティブという」というところにドラッカーの真意があるという。従って、日本語では、「できる人」という言葉が適切なのではないかというのが上田先生の解釈だそうだ。

コウビルドには、executiveは

An executive is someone is employed by a "business" at a senior level. Executives decide what the business should do, and ensure that is done.

と説明されている。この説明の中のキーワードはsenior levelである。同じく、

The senior people in an organization or profession have the highest and most important jobs.

とある。

この説明をみればドラッカー博士や上田先生の言っていることはよくわかる。

さて、では、プロジェクトエグゼクティブとはどういう人か？プロジェクトに関して、言われた以上のことをやる人ということになる。この意味は多様である。

　・言われた目標以上の成果を達成する人
　・言われたスコープの範囲を超えて活動する人

となる。プロジェクト作業はともかく、プロジェクトマネジメントの作業は自分が担当範囲だといわれている範囲を超えないとなかなかうまく行かない。一般的なプロジェクトにおいて、プロジェクトマネジメントを行っているのは、プロジェクトマネジャー、プロジェクトスポンサー、プロジェクトマネジメントオフィス、シニアマネジャー、プロジェクトメンバーである。プロジェクトマネジメントがスムーズにいくためには、これらのプレイヤーのそれぞれが、自分の担当範囲を超えて、言われた以上のことをやる必要がある。

そのような動きができるプロジェクトステークホルダ（ＰＭＢＯＫでいうところの意味）をプロジェクトエグゼクティブというのだろう。

【補助線】所与の課題ではなくなってきたプロジェクト

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

よく「優等生」という言い方をされるタイプのビジネスマンがいる。問題解決能力が高いビジネスマンである。かつては、企業は優等生をほしがった。今の時代でも優等生が必要なことは間違いないのだが、優等生だけではどうしようもなくなってきた。

優等生では何が足らないのか？

課題を創る能力、課題設定力である。あるいは問題発見能力だといってもよい。先生（上司）が答えが見えないままに前に進まなくてはならなくなってきたのだ。一本被りする商品もあれば、まったく売れない商品もある。ヒット要因を分析してみてもよくわからない。わかった頃には市場のニーズが変わっていて、役に立たない。こんなビジネスの環境の中で、業績をあげる方法が見えなくなっており、走りながらいろいろなことを感じ、考え、先に進んでいくことが求められるようになってきた。

プロジェクトマネジメントでもこの現象は起こっている。プロジェクトというのは基本的には上位組織が課題を作って、プロジェクトマネジャーを中心としたプロジェクトチームに問題解決をさせるものである。

ところが、上に述べた商品開発プロジェクトのように、課題設定の後に、方針が揺らいだり、変わったりすることが多くなってきたし、方針すらも明確にできないようなプロジェクトも多くなってきた。このようなプロジェクトは「背景」と「要求」のみを与えて、プロジェクトマネジャーにバトンタッチする。

また、やたらと制約条件の厳しいプロジェクトが増えてきた。納期が現実的ではない、予算が現実的ではないといったプロジェクトだ。このようなプロジェクトは一見、課題設定ができて、その課題解決をプロジェクトマネジャーに任せているように見えるが、実際は違う。現実的な制約ではないということは、多少の工夫や改善で何とかなるといった話ではない。

つまり、課題設定そのものをしなおさないと課題の背後にある（組織としての）要求を満たすことができない。この手のプロジェクトが実に多くなっている。

いずれの場合も、「優等生」タイプの問題解決に優れたプロジェクトマネジャーではプロジェクトを成功させることはできない。課題設定ができなくては話にならない。

課題を設定するというのは、やれといわれた以上のことをやることに他ならない。いよいよい、プロジェクトマネジャーもやれといわれた以上のことが問われるようになってきたのだ。そのようなプロジェクトマネジャーを目指したいものだ。

【補助線】プロジェクトマネジャーである前にビジネスマンであれ

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

プロジェクトマネジャーはプロジェクトマネジャーである前に、ビジネスの目標、経営者や事業マネジャーの役割、マーケティングなどを十分に理解した「ビジネスマン」であるべきだ。

メルマガの創刊以来、プロジェクトマネジャーに対して、ずっと言い続けてきたことだ。最近、気になりだしたのは、プロジェクトマネジャーとしてはプロフェッショナルな人が増えてきた反面、ビジネスマンとしての自覚がある人が少なくなってきたことだ。

先日、ある中堅企業の経営者の４年ぶりくらいにあった。５～６年前にプロジェクトマネジメント導入のコンサルティングをやった企業の経営者である。

コンサルティングをした当時は、プロジェクトの遅延率が下がり、効果があったと喜んでいた。ところが、この２年くらい、決められていることをやればいいんだろという態度が目につくようになってきたという。

特に困っているのが、決められたとおりにやるとマネジメントコストがかかるのは当たり前だということを平然という人が増えてきたことと、プロジェクトの予算や納期が、無理なものはプロジェクトマネジャーを引き受けたがらない人が目立つようになってきたそうだ。

前者で一番困っているのが、厳しい納期でも、計画期間の必要性を訴える人が増えてきたこと、後者では技術的な新規制の高いプロジェクトは管理が大変だとみんなが逃げ腰で、結果としてうまく行かないことが増えたことだという。

常々、感じていることだが、エンジニア感覚でプロジェクトマネジャーをやる人がどんどん、増えている。プロジェクトマネジメントのスキルを身に付けることによってエンジニアリング業務がスムーズに進むという点においては、一定の評価はできるし、シニアなエンジニアを目指す人には不可欠なスキルだともいえよう。

しかし、エンジニアとしていくらプロジェクトマネジメントスキルを身につけたところで本物のプロジェクトマネジャーにはなれない。エンジニアも本来は、エンジニアである前にビジネスマンであるべきだと思っているが、百歩譲ってそうではないとしても、プロジェクトマネジャーは必ず、ビジネスマンでなくてはならない。

ここに大きなハードルがある。このハードルを越えた人だけが「できる」プロジェクトマネジャーになれる。ＰＭＢＯＫブームはこのハードルを乗り越えられないプロジェクトマネジャーを大量生産しているが悪いことではない。ここから、仮に１割でもハードルを乗り越える人材が出てくれば大成功だといえよう。

【補助線】プロジェクトマネジャーになるということ

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

プロジェクトマネジメントをやってプロジェクトマネジャーは何かいいことがあるのだろうか？計画書を作るとか、リスクを考えながら仕事をするとか、面倒なことは山ほどある。では、その見返りに何があるのか？

これは多くの人がプロジェクトマネジメントに出会ったときに考えることだ。僕は常に、以下のように答えることにしている。

多くのマネジメントがそうであるように、プロジェクトマネジメントも現場の人に便宜を図るためにあるのではない。いうまでもなく、経営的な目的で導入される。

従って、今まで、自己流でプロジェクトを運営していた現場マネジャーが組織の方針でＰＭＢＯＫ流プロジェクトマネジメントを始めたからといって直接的には何もよいことはないだろう？ドキュメントワーク、ミーティングの増加により、タダでさえ忙しかったのがますます忙しくなることは明らかだ。

もちろん、自身できちんと仕事をすることを信念にしている人であれば、適用することによって満足感、達成感はあるかもしれない。しかし、１回、２回のプロジェクトであればともかく、延々と１０年もそんなことを続けられる人がどれだけいるだろうか？

この問題に対するひとつの答えは散々言われているように、

「プロジェクトがうまく行けばプロジェクトマネジャーは楽になるじゃないか！みんなが同じ方法で研究すればうまく行く確率も高くなる、頑張ろう」

というものだ。これはウソだ。

そろそろ、このウソに気付く人たちが多発してきた。いつまでたっても楽にならない。どころか、成功率を上げるためと称してだんだん、マネジメントワークが増えてきている。

この１年だけでも、１０人くらいの人から、「これなら、トラブルを起こしてばたばたしているほうが楽だし、第一、仕事をしているという充実感がある」というような意見を聞いた。この問いにどう答えるのか？

これに対する僕の答えは

多くのマネジメントがそうであるように、プロジェクトマネジメントも現場の人に便宜を図るためにあるのではない。いうまでもなく、経営的な目的で導入される。

だ。つまり、現場マネジャーは、経営側に立たない限り、プロジェクトマネジメントを導入してもメリットがことがあると感じられないだろう。あなたの会社ではプロジェクトマネジャーは職位でいえばまだ組合員なのかもしれない。しかし、そういう問題ではない。

プロジェクトマネジャーになるということは経営側の視点を持つということを求められるのだ。現場のリーダーだという発想は捨てた方がよいだろう。

【補助線】サイエンスとアート

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

プロジェクトマネジャーのスキルの中で、見落とされがちなのが、「想像力」である。プロジェクトマネジメントだけではなく、マネジメントは一般的に、５０％がサイエンスで、５０％がアートであるといわれる。

サイエンスだけでは決してうまく行かない部分がたくさんある。一つの例。リスクマネジメントである。リスクマネジメントとは可能性のマネジメントである。リスクを識別するというのは、経験知があれば分析的にできると考える人も多い。

確かに、プロジェクトマネジメントの先進的企業ではリスクチェックリストを作り、機械的にリスク識別を行うような取り組みをしている。この部分はサイエンスである。

そのような取り組みをしているあるＳＩ企業のＰＭＯマネジャーに聞いた話。その企業では、リスクチェックリストを使って、リスクを回避し、それに併せて、各プロジェクト独自のリスクを識別するようにしている。すると、プロジェクトマネジャーとしての成績と、独自リスクの洗い出しの数は明らかに相関があるというのだ。もちろん、洗い出す独自リスクが多いプロジェクトマネジャーが成績がよいそうだ。

興味深い話である。たぶん、この話はリスクマネジメントがうまく行くからという話でない。想像力の問題だと思う。つまり、いろいろなシナリオを描くことができ、そこで何が起こるかということが明確なイメージとして頭に浮かんでくるのだろう。

実はこのような能力は、リスクマネジメントだけはなく、計画作業全般に必要だ。著者の知っているプロジェクトマネジャーの中に、計画をものすごく細かく書く人がいる。その人と他のプロジェクトマネジャーを比較してみるとわかるのは、その人はアクティビティのイメージがすごく明確なのだ。だから、細かな計画もかける。

計画をどの程度詳細に書くとよいかという議論は別途あるとしても、計画に対する「リアリティ」をどれだけもてるかは歴然とした違いがある。見てきたような計画を書くのと、テンプレートをさわって計画を書くのでは、その後のスムーズさ、とりわけ、トラブルに陥ったときの対応などが違うことは想像に難くない。

これは想像力の賜物であろう。このような部分がアートなのだ。プロジェクトマネジメントが普及してくるにつれて、アートの部分が軽んじられるようになってきたと思うのは、著者だけだろうか？

この議論は、組織の成熟度が上がってくればサイエンスの部分が増えるというほど単純な議論ではない。成熟度が上がれば、サイエンスの部分の質は上がってくる。これは間違いない。しかし、やはり、一定の割合でより高度がアートが求められるようになるだろう。

【補助線】前提条件を合意する

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

プロジェクトが満たすべき前提条件
http://people.weblogs.jp/ppf/2007/07/post_ee2b.html

の続き。プロジェクトが満たしているべき前提条件が実は満たされていなくて、プロジェクトでひどい目にあったことがある人は多いと思う。しかし、意外なことに多くの人は、同じ過ちを繰り返す傾向がある。

なぜだろうか？

はっきりしているのは、「問題はなかったことにしよう」という態度だ。

　問題はなかったことにしよう
　　http://people.weblogs.jp/ppf/2007/06/post_3fc7.html

プロジェクトが満たすべき前提条件で述べたように、前提条件の崩壊の多くはプロジェクト環境の問題である。つまり、本来、整備されているべき環境が整備されていない。社内調整ができていない、ベンダーとの調整ができていない、顧客との調整ができていない、などなど。

これらはいずれもかなり本質的な問題である。言い換えると、組織にとって「大問題」なのだ。にも関わらず、組織としての問題はなかったことにし、「プロジェクトマネジャー」の問題として済ませてしまう。しらっとして

　「弊社の問題の一つはプロジェクトマネジャーのコミュニケーション能力不足です！」

などといっているわけだ。

例えば、社内で特定の人材のプロジェクト配置の調整がつかないという事態が、プロジェクトマネジャーのコミュニケーションの方法で解消するはずがないことくらいすぐにわかる。というより、そういっているプロジェクトマネジャーの上司自身、そんなことはよくわかっているのだ。ところが、プロジェクトの前提条件の崩壊の原因というのはパンドラの箱だ。あけてはならないのだ。それで「コミュニケーションの悪いプロマネ」という犠牲者が作られるのだ。

では、このような問題に対して、プロジェクトマネジャーはどう対応すればよいのか？

　前提条件を明確にし、上司（プロジェクトスポンサー）と合意する。

これしかない。

【補助線】ＰＭＢＯＫはハコモノ、ＰＭＯが魂を入れる

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

◆ＰＭＯブーム！？

ＰＭＩ東京事務局の永谷裕子さんに聞いた話だが、永谷さんがＪＵＡＳ（日本情報システムユーザ協会）で初めてＰＭＯのセミナーをやったところ、あっという間に１００名の応募があったそうだ。

この話を聞いてもそんなにびっくりしないくらい、ＰＭＯへの関心は高まっている。PMstyleでも昨年からＰＭＯリーダー養成講座というＰＭＯスタッフ育成の体系的講座（全６回）をやってい る。今年４月からの第４期ではほとんどのセッションが満席になっている。

◆米国のある企業＠１９９６

なぜ、こんなにＰＭＯが注目されるようになってきたのだろうか？プロジェクトマネジメントは米国から１０年遅れているといわれる。「プロジェクト的な性格を持つ業務の管理方法の唯一解がプロジェクトマネジメントだ」というのは少し違うと思うので、これがそのまま「プロジェクトのマネジメント」が遅れていることと意味しないが、「モダンプロジェクトマネジメント」ということであれば、１０年以上だと思う。僕はちょうど、１９９６年は米国の企業と一緒に仕事をしていたが、今のＳＩ企業と較べると、たぶん、その企業のプロジェクトマネジメントの方が進んでように思う。

この会社にはかなりしっかりとしたＰＭＯ組織があった。プロジェクトマネジメントのオーナーシップを持つだけではなく、プロジェクトへの支援活動も実践的なもので、我々のプロジェクトもずいぶん助けられた。特に、米国の拠点にプロジェクト本体があって、日本にも部隊がいるようなバーチャルチームだったが、チームのコミュニケーションの支援はまさに、「プロフェッショナルの業」だったような印象がある。

◆定着に１０年かかる

実は最近、ＰＭＯの仕事をするようになって、改めて、この企業のＰＭＯマネジャーとコンタクトをしていていろいろなことがわかったが、設立は８０年代前半だそうだ。１０年くらいはうまく機能しなかったそうだ。ただ、うまく行きだしたら、加速的にうまくいくようになったそうで、このあたりは定着化の話としてたいへん、興味深い。

さて、日本の企業はプロジェクトマネジメントに関心を持つようになってきて、まず、何をやったかというと多くの会社がＰＭＢＯＫの導入を行った。そして、多くの企業がうまく行かずに苦しんでいる。理由ははっきりしている。ＰＭＢＯＫというのは多くの企業がやっていることを標準化したものだが、その背後にはＰＭＢＯＫそのものではあまりフォーカスされていないプロジェクトマネジメントの推進体制というのがある。

◆ＰＭＢＯＫはハコモノ、ＰＭＯで魂を入れる？

つまり、多くの企業は「ハコモノ」としてＰＭＢＯＫを入れている。まあ、ハコモノを入れて、後で中身をつめていくというのは日本型マネジメントの特技だといえるので、失敗だとは言い切れないが、あまり感心したことではない。

それはそうとして、我々がＰＭＢＯＫの導入コンサルティングをやったクライアントのＰＭＯは例外なく、「これだけのことはできないし、プロジェクトマネジャーにやれとも言えない。できる範囲でやればいいよね」という。できなくて当たり前である。プロジェクトマネジャーにやらせることを前提にしているからだ。もちろん、ＰＭＯとしても何らかの支援はしなくてはならないと考えるが、そもそも、前提が間違っている。

ＰＭＢＯＫはプロジェクトマネジャーのやることを示したものではない。プロジェクトマネジメントとしてすべきことを示したものだ。

ＰＭＢＯＫを採用する、しないに関わらず、プロジェクトマネジメントはプロジェクトマネジャーだけがやるものではないことに多くの企業が気がついてきた。そこで、とりあえず、ＰＭＯを作ってプロジェクトマネジメントの一端を担うようにし始めた。ハコモノにやっと少し、中身ができてきたわけだが、これが、今、ＰＭＯが注目されている理由である。

【補助線】「万人の万人による戦い」は不要か？

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

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

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

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

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

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

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

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

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

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

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

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

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

【補助線】チェンジモンスター

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

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

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

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

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

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

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

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

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

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

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

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

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

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