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

前の記事では、組織の問題を書いたが、プロジェクトマネジャーの孤立という問題に対して、プロジェクトマネジャーの問題はないのかという点についても意見を述べておく。

つい最近、アービンジャー・インスティチュートの箱本の第２弾の邦訳がでた。

アービンジャー・インスティチュート（門田美鈴訳）

「２日で人生が変わる「箱」の法則」
　　

箱本は、自分の殻に閉じこもり人間的な発想を失ったマネジャーが、箱から出て人間力を取り戻していくことを書いた本である。

第１弾はＰＭ養成マガジンの書籍プレゼントの対象になったこともあり、読者の方から話題にされることが多かった本である。

アービンジャー・インスティチュート（金森 重樹監訳、富永星訳）

「自分の小さな「箱」から脱出する方法 」

プロジェクトマネジャーが孤立する理由として、「箱に入りたがる」という理由も指摘しておきたい。スコープに関するトラブルを起こしたプロジェクトを見ていると、必ず、見られる理由のひとつがステークホルダコミュニケーション不足なのだが、その背景に「プロジェクトという箱」に入って出てこないプロジェクトマネジャーという問題があることが多い。

箱から出たがらない理由はさまざまだが、箱の中で見えていることですべてを決めてしまう。せいぜい、決まった様式や、形式的な会議での「コミュニケーションごっこ」をやるだけでプロジェクトを進めていこうとする。

こんなことをやっていれば、スコープの問題が起こらないほうが不思議だ。箱から出て顧客やほかの主要ステークホルダと人間としてしっかりと対峙して、一緒にやっていくことが何より重要である。

にもかかわらず、箱から出ないままで、自分の理屈をいい、相手を非難する。さらに、悪質だなと思うのは、プロジェクト全体を箱にしているのだ。つまり、プロジェクトメンバーは仲間であるので、真摯に向き合う。しかし、外部ステークホルダには向き合わない。メンバーまで、箱の中で自分の理屈をいう。こうなると、箱の中ではお互いに慰めあうのでどうしようもない仲良しグループになってしまう。

プロジェクトマネジャーがアホでも、メンバーにはカシコイのがいて、プロジェクトの窮地を救う。これもプロジェクトの醍醐味のひとつであるが、チームに対する誤ったマネジメントで、そんなダイバーシティを取り除いた仲良しチームを作っているプロジェクトは本当に目に余る。

コミュニケーションというのは諸刃の剣である。コミュニケーションによってチームのパフォーマンスがあがる。これは間違いない。しかし、それは箱の中のコミュニケーションになってしまうと、成果に結びつかない。ここをしっかりと把握しておきたい。

◆プロジェクトマネジメントブームを紐解く

PMstyleの展開を本格的に始めて１年半になる。今年度から過去にPMstyleのセミナーに参加していただいたお客様を対象にプライベートセミナーを開催している。第１回はプロジェクトマネジメントにかかわる諸問題の整理と議論を行った。第２回のPMstyleプライベートセミナーは、プロジェクトマネジメントを成功させる組織のあり方の問題を扱うことになった。今回はこの背景認識を紹介したい。

もう５年くらい前になると思うが、日本でもプロジェクトマネジメントブームが起こった。

誤解のないようにしておきたいが、それ以前は何もしていなかったということではない。もう１０年くらい前、つまり、ＰＭＢＯＫでいえば第１版（９６年版）が出てきたあたりから、先進的な企業はＰＭＢＯＫなどを参考にしながら、体系的なプロジェクトマネジメントの導入に取り組んでいたし、また、９０年代にＰＭＯ（プロジェクトマネジメントオフィス）を作っていた企業も少なくない。日本プロジェクトマネジメント協会（当時の、日本プロジェクトマネジメントフォーラム＝ＪＰＭＦ）もこの時期にはすでに活発に活動をしている。

ライフサイクルでいえば（近代）プロジェクトマネジメントの世界的な動きは

　揺籃期　～１９９０
　成長期　～２０００
　成熟期　２０００～
　衰退期

という感じだと思うが、日本の普及を見ていると、ユーザが

　～1995　Innovator
　～2000　Early Adopters
　～2005　Early Majority
　2005～　Late Majority

といった感じで出てきているのではないかと思う。具体的なユーザとしては

　～1995　Innovator　外資系のＩＴ企業、エンジニアリング業界の一部企業
　～2000　Early Adopters　国内資本ＩＴ系企業、製薬業界の一部企業

といったところではないだろうか。

このような動きの中で、ＰＭブームは、何人かのエバンジェリストが登場し、多くのEarly Majorityを生み出したことによって起こった。彼らは、メディアやコミュニティなどを通じて、プロジェクトマネジメントの必要性を説き、多くの企業にプロジェクトマネジメントの導入の契機を作った。

◆権限委譲は何をもたらしたか

このような普及の中で、ややもすると「プロジェクトマネジメントはプロジェクトマネジャーに権限委譲して、全面的に任せるものだ」というイメージが植えつけられた。むしろ、口出しをすべきではないという風潮ができたのも事実である。これが後に禍根を残している。

これは多分に受け止め側の問題でもあるので、エバンジェリストだけの責任とはいえないが、結果としてそのようなあまり適切とはいえないイメージができたことは事実だ。ただし、このイメージが急速に広まっていったのは、実はエバンジェリストの影響ではないと思う。受け止め側の問題と書いたが、むしろ、これが組織のミドルマネジャーやシニアマネジャーにとって好都合だったということが大きいと思われる。この図式の中では、自分たちはプロジェクトの実施責任をすべて放棄して、成果を求めるという構図ができるのだ。

これにより、プロジェクトマネジャーは「責任が大きくて報いがないあまりやりたくない仕事」という印象がついてしまった。当たり前である。これまでは、失敗も成功も上司の問題という立場から、「失敗すれば自分の責任、成功すれば上司の手柄」という仕事にかわってしまったからだ。もちろん、インセンティブ制度などを取り入れ、報いようとする動きはあるのもの、キャリアに結びつく評価というのはあまりされることがない。

◆孤立するプロジェクトマネジャー

また、もっと深刻な問題はプロジェクトマネジャーが孤立し始めていることだろう。プロジェクトマネジャー自身ではどうしようもないようなリソース関連の問題や、ビジネスの収益確保の問題まで一人で抱え込んでいるプロジェクトマネジャーが増えている。

これらは組織側からは失敗プロジェクトがなくならないという現象に見えた。そこで、やむなく「口出し」をするという施策をとり、うまくいっている企業もある。

◆権限委譲からエンパワーメントに

この議論は根本的な誤りがある。プロジェクトマネジャーにプロジェクトを任せることは「権限委譲」ではなく、「エンパワーメント」である。これが理解されていない。エンパワーメントとは業務の遂行に必要な権限を渡すと同時に、

　・目的・目標の合意
　・自由度の供与
　・補完的な支援

を行うものである。権限は委譲しても、この３つのいずれか、あるいはすべてができていない組織が多いのだ。

情報サービス産業協会（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.

とある。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

これに対する僕の答えは

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

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

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

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

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

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

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

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

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

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

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

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

プロジェクトが満たすべき前提条件
https://mat.lekumo.biz/ppf/2007/07/post_ee2b.html

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

なぜだろうか？

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

　問題はなかったことにしよう
　　https://mat.lekumo.biz/ppf/2007/06/post_3fc7.html

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

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

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

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

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

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

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

これしかない。

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

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

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

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

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

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

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

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

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

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

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

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