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

ＷＥＤＧＥの９月号に製造業の品質問題の記事が掲載されている。

「電子化偏重・人間軽視」開発現場から崩れる製造業

という記事だ。なかなか、興味深い記事なので、機会があれば目を通して見られるとよいだろう。

この中に、プロジェクトマネジメントの立場からは気になる指摘が書かれている。

トヨタでは、この１年くらい、過去に市場に送り出した商品の品質問題に頭を痛めている。マスコミでも何度も取り上げられているように信じられないようなリコールが多発しているのだ。それを受けて、品質担当の副社長を１名増やして２名にし、さらには担当専務まで設置したが、それでも思ったような効果がでない。なぜか？

これがこの記事の問題提起である。その上で効率とコストを追求するために起こっている「開発プロジェクトでのコミュニケーション不足」があると指摘している。これはトヨタに限らない。僕のコンサルティングをしたプロジェクトでもこの問題はよく直面する。

この種の問題は極めてやっかいである。プロジェクトスコープの中に現れてきにくいからだ。自動化された設計上の問題はない。品質基準も満たしている。そのような中でも、設計者同士が議論をしていると気づく問題も多い。しかし、効率追求・コスト優先の中ではその時間がままならない。

この問題は今に始まったことではない。僕が三菱重工で仕事をしていた頃に、ＣＡＥのシステムの自動設計の開発に携わっていたことがある。このときに多くの設計エンジニアにインタビューしたことがあるが、多くの人はこの問題を指摘していた。僕流に言えば次のようなことを言っていたように思う。「設計というのは形式化できない。ナレッジベースを作っても無理。コラボレーションの中で生まれてくる部分が多い」

さて、この問題、トヨタも気づいていなかったわけでも、手をこまねいていたわけではない。記事によると、早くから問題の所在に気がつき、手を打ってきた。２００３年くらいから、開発段階における設計、生産、調達の横断的なすりあわせを強化してきたという。タラレバになるか、だから、この程度で済んでいるともいえよう。

この問題、プロジェクトマネジメント的にはどうすればよいのだろうか？

難しいのはコストと時間の制約が極めて大きいために起こっている問題で、コミュニケーションマネジメントをきちんとすればよいといった単純な問題ではない。かといって、いまさら、リードタイムや製品原価を緩くする方向に向かうというのはできない相談だろう。

このような状況で唯一の解になりうるのは、今まで真剣に考えてこなかったチームマネジメントではないかと思う。ただし、自動車メーカは製品アーキテクチャーから組織を作りこんでいるので、チームマネジメントを何とかしようといってもそう簡単にはいかないだろう。そこは悩ましい点だ。

一方で、他の業界ではこの矛盾に満ちた問題を解消できるようなチームマネジメントは比較的容易に実現できるように思うのだが、如何だろうか。

実は、この問題、マスプロダクションだけに限った話ではなく、受注生産製品でも起こっている。その典型がＳＩプロジェクトである。ＳＩプロジェクトでは、顧客コミュニケーションの悪さは目に見える形で品質の問題として出てくる。しかし、システム内部の不適合はそう簡単には出てこない。そこで、要件定義や設計時のプロセスマネジメントで品質の作りこみを行うのだが、短納期化やエンジニアのスキルの問題などでコミュニケーションの品質が落ちてきて、それが製品の品質問題になっているケースが増えている。

ＳＩの場合であれば、チームマネジメントを丁寧に行うことで、納期と品質のコンフリクトという問題は解消できる。

日本の現場の強さは、コミュニケーションの強さであるし、上流工程のさまざまな問題のバッファになってきた。実際に「現場あわせ」という言葉が象徴するように、上流工程のコミュニケーション不足を現場のコミュニケーションで解消してきた。

それができなくなってきたのだとすれば、ある意味で転機だといえる。製品開発プロセスにプロジェクトマネジメントを導入し、コミュニケーションマネジメント、リスクマネジメントなどをチームマネジメントで統合していくようなマネジメントが求められるようになってきたといえる。

自民党の総裁選挙が近づいてきて、マスコミがこぞって特集番組を放映し始めた。小泉という首相は非常に面白いことを見せてくれた。それは、議員内閣制でもここまでできるという限界である（本当に限界か、まだできるか、常識的限界を超えて属人的に許される限界かは分からない。おそらく次の首相が方向を決定付けることになるのだろう）。

なぜ、こんな話題を持ち出したかというと、これまでずっと述べてきた組織によるプロジェクトマネジメントのイメージは、ある意味で議員内閣制に似ているからだ。プロジェクトマネジャーは首相である。プロジェクトチームは内閣。スポンサーは与党。ステークホルダは野党や国民。

小泉以前の内閣は少なくともこのフォーメーションであった。ところが、小泉はこのフォーメーションをひっくり返した（と表面的には見える）。世論の支持を背景に、カリスマリーダーのごとく行動した。彼の行動がよいか悪いかはまだしばらく答えがでないと思うが、少なくとも、今までの首相ではフォーメーションをひっくり返すことにより今まではできなかったことをやってのけた。

プロジェクトマネジャーにはあまり権限がないと思っている人が多い。内閣総理大臣もそうだった。しかし、やればこれだけできた。問題はやり方と意志である。

大志あるプロジェクトマネジャーは小泉的を目指せ！

岡野工業の社長（正確には代表社員）である岡野雅行さんが新しい本を書かれた。

岡野 雅行「世界一の職人が教える仕事がおもしろくなる発想法―結果が出ない人はいない」、青春出版社（2006）

岡野さんは今までに４～５冊出版されているが、どの本を読んでも元気付けられる。特に今回の本は、岡野さんの仕事の仕方、考え方のエッセンスを抽出されているので、非常に啓蒙的内容が濃い本だ。

岡野さんの仕事のモットーはこの本にあるとおり、誰も無理だ、できないという仕事をやるのが最高に楽しい、アドリブで仕事をするからこそ楽しいなど、「技術屋」が聞くと涙を流しそうなものばかりだ。

岡野さんは僕の尊敬する経営者の一人だ。大企業に勤める「サラリーマン」と岡野さんの話をすると、決まって返ってくる答えが、社長だからできるとか、中小企業だからできるである。

こんな話は自分が岡野さんの立場になった想像をしてみて１０秒考えれば間違いだと分かる。要するに、違う点を言い訳にしたいだけに過ぎない。岡野さんと彼らの違いは、岡野さんややる方法を考えるが、そのような言い方をする人はやらない言い訳を考える。言い尽くされた話だが、まさにそのもの。

まあ、それは人生観も折込の話になるので、どうでもよい。生涯サラリーマンの人はその人なりの価値観があるだろう。

ただ、考えてほしいことは、顧客や上司から「無理難題」を吹っかけられることは中小企業であろうと、大企業であろうとある。何にしても顧客はエライのだ。

例えば、痛くない注射針を作ってほしいというのに匹敵するような、あるいはそれ以上の無理難題な要件を言われたことのあるＳＩプロジェクトのプロジェクトマネジャーは少なくないと思う。

このときに、「あ～、だから何もわかっていない顧客とはやってられない。営業を巻き込んでから断るか」と考える人と、「お～！、面白い、なんとかしてやろうじゃないか」と考えれられる人では、しんどい目をするのは、間違いなく前者である。

サラリーマンをやっている人に、トム・ピーターズや岡野さんのように、あえて積極的にリスクをとって面白いプロジェクトを作ろうと呼びかけるつもりはない。しかし、おかれた境遇から逃げれないのもまたサラリーマンだ。まさか、公務員のように不作為というわけには行かないだろう。

であれば、そんな人こそ、岡野さんのような考え方をできるようになってほしいなと思う。プロアクティブなプロジェクトマネジメントはそこから始まる。

プロジェクトマネジャーの人にこの本は読んでほしいな。

「失敗学会」の副会長を勤められている飯野謙治さんが最近ソフトバンク新書から

「失敗をゼロにする」のウソ

という本を出 された。大変、よい本だと思うので、ぜひ、読んでほしいのだが、この本のまえがきに、「失敗学」を活用するためのポイントを３つ書いている。

三つ目は

　「失敗を繰り返さないための仕組みづくり」

という失敗学のメインストリームの主張なのだが、その前の２つが非常に興味深い。

一つ目は

「人は失敗をやらかすもの」だと意識すること

だという。そして、二つ目は

「失敗を隠そうとするのは自然の心理」だと素直に認めること

だという。この２つが組織の風土となって、最初に書いた三番目の仕組みづくりが可能になるという指摘をしている。

リスクマネジメントというのは、この

「失敗を繰り返さないための仕組みづくり」

に他ならない。リスクマネジメントの効果が出ないのは、飯野謙治さんが指摘する２つの風土に問題がある。

多くの企業、特に、大手企業でプロジェクトリスクマネジメントのコンサルティングをしているときにこれをひしひしと感じる。つまり、

　自分たちは失敗はしない

という思い。この背景には当然、組織として失敗は許されないという風土がある。この意識がある限り、リスクマネジメントはできない。問題はあってもよいのだが、その問題によって失敗をすることは１００％ないと考える。リスクというのはその問題における失敗行動を取る可能性であるので、当然、失敗しないという前提であれば、リスクはないことになる。

このように考えると、基本的にはプロジェクトを開始する前にすべてのリスクを回避できていなくてはならないということになる。これは、プロジェクトマネジャーと上司の間、また、プロジェクトメンバーとプロジェクトマネジャーの間の両方に言えることである。

ただ、プロジェクトであるのでデッドラインがある。そのため、事前にすべてのリスクを回避できないことがある。このような場合には、その問題は確実に解決できるという仮定の上にプロジェクトを進めることになる。「よきに計らえ」である。当然、失敗するとは思っていないので、その対応で問題が生じると責任問題になる。

この問題と関係するのが二番目である。失敗はないという前提であるが、当然、人間であるので失敗することもある。そこで、失敗した場合には隠すことになる。

リスクマネジメントの枠組みでいえば、リスクモニタリングを公正に行わないことになる。仮に、リスク識別をしていても、そのリスクは発生していないという報告をすることになるのだ。

リスクマネジメントを効果的に行うためには、失敗を隠すことが自然だという認識が重要だ。これはプロジェクトメンバーを信じるとか信じないという視点で捉えてはならない。隠すことは自然なことであり、特定のメンバーの固有の問題ではないと考える。そのような前提でリスクモニタリングをしていく必要がある。

プロジェクトマネジャーがプロジェクトリスクマネジメントを行う際には、一番目のポイントの

「人は失敗をやらかすもの」だと意識すること

を徹底的に意識付けする必要がある。このためには、原理を重視する。正しいことと正しくないことを明確にするのだ。それをしないと失敗を失敗だと認めない（リスクの発生を無視した）ままで前に進んでしまう危険がある。

これがクリアできれば、隠す必要性が小さくなる。つまり、リスクへの早期の対応が可能になる。そのとき初めてリスク対策が意味を持ってくる。

そんなプロジェクト組織の作り方を議論するセミナーを開発した。

リスクに強いプロジェクトと組織を作る（リンクあり）

ＰＭコンピテンシーの仕事をしているうちに、だんだん、プロジェクトマネジャーに足らないと思われるものがはっきりしてきた。

　コアマネジメントスキル

である。

プロジェクトマネジメントというのはどちらかといえば、テクニカルな色彩の濃いマネジメントである。ＰＭＢＯＫはその象徴でもあるが、「ツール」や「技法」に依存する割合が多い。

確かに、建設の仕事だとかを考えてみると、このようなマネジメントは必要なのだと思う。延べ人数で数万～数十万人の人を動かして一つの目標を達成する。このような仕事では今のようなプロジェクトマネジメントの枠組みは不可欠だろう。

一方で、今、盛んにコミュニケーションやネゴシエーションといったヒューマンスキルが注目されるようになってきている。これらに注目が集まる理由をよくよく聞いていると、マネジメントスキルの欠如をヒューマンスキルでカバーしようとしているようだ。正しいかどうかは別にして、この感覚はちょっと違う。

家を建てることに例えてみると、以下のような比喩ができる。

　基礎：コアマネジメントスキル

　デザイン（機能性）：プロジェクトマネジメントスキル

　デザイン（快適性）：ヒューマンマネジメントスキル

今、行われていることは、基礎工事が悪くて、ドアの立て付けが悪くなったときに、ドア枠をフレックスな構造にしておくことにより隙間風が入らないようにする仕掛けを作っているようなものだ。要するに、「ギミック」なのだ。

もっといえば、コアなマネジメントスキルを持たない人材がもつプロジェクトマネジメントスキルというのもギミックだという気もしなくもない。これは少し言いすぎかな、、、

「ギミック」が悪いどうかは別問題だ。

組織としての評価のポイントは２つある。一つは、その家にどれだけ住み続けるかだ。仮住まいで１０年ほど住んだら取り壊してしまうのであれば、それも一つの選択だ。

その際のもう一つのポイントは、コスト。基礎をしっかりするのと、このような「ギミック」を施すためのコストを比較し、「ギミック」の方が安いとすればそれでもいいのかもしれない。

個人のとして評価は言うまでもない。その会社が潰れても生きていかなくてはならない。基礎が大切だ。基礎がしっかりとしていれば、「ギミック」など必要ない。

「ギミック」を身につける前に、本物のマネジメントスキルを身に付けたいものですね。

新・ＰＭコンピテンシー強化術（スキル編）～プロジェクトマネジメント実践を強化するマネジメントの原理原則（リンクあり）

プロジェクトマネジメントのあり方について

プロジェクトマネジャーにとって技術や分野の専門知識は必要である

という命題がある。

この命題が真だという人は、プロジェクトの成功が技術リスクに強く依存しているため、技術の素養がないとプロジェクトはうまくマネジメントできないという意見が多い。特に、管理職とは違うという言い方をする人が多い。

逆に偽だという人は、プロジェクトは専門家を集めて、彼らに権限委譲して行うのだから、マネジメントスキルがあればよいという意見の人が多い。

この議論はキャリアの議論としては意味があると思うが、プロジェクトマネジャーの任命やプロジェクトマネジメントの中ではほとんど無意味な議論だと思う。神学論争である。

この命題よりもはるかに重要なのは、

一人の技術者が技術者としていい仕事をするためにはマネジメントの資質が必要

だという命題である。

僕自身のコンサルタントとしてのキャリアの中で１５年間、多くのエンジニアに出会ってきたが、この命題を否定するような人材に出会っていない。この命題は明らかに真だと思う。

この理由は２つある。

一つは最近、エンジニアにもプロジェクトマネジメントのスキルが必要だという指摘の根拠になっている組織で仕事をしているからである。ただ、これはそんなに大きな問題ではないように思う。

もう一つは、自分が満足すればよい仕事だという人は別にして、はやり、自分が満足し、人からも評価されるためには、マネジメントの資質が必要になるという事実である。これは、組織に認められるからとかいったレベルではない。エンジニアの取り組む仕事で絶対的に価値のある仕事は残念ながら少ない。プロジェクトＸのような大きな仕事を見ていてもそんな数はない。

すると、すばらしい発見やアイディアを出す以前の問題として、分野の選定が極めて重要である。シーズにさえならないような分野で何をやってもそんなに認められるものではない。ニーズだけではなく、シーズもある意味で市場である。つまり、市場の認めない仕事をしても意味がないということになる。

ここでいう市場を商品市場のような狭い意味で捉えないでほしい。例えば、社内で技術開発をする場合には、自分の所属する組織なり、企業なりが市場を持っている。この市場に適応できなくては話にならない。

もう一つ、僕が持っている命題がある。それは、マネジメントの資質がある人はセルフマネジメントがきちんとできる。自らの目標発見、動機の維持、タイムマネジメントなど。これはいずれも、マネジメントの基本である。

この命題は逆も真である。セルフマネジメントができている人はマネジメントの資質もある。

このように考えていくと、画期的な仕事をできる人は市場を見つける活動と、セルフマネジメントにおいて、マネジメントの資質を持った人であるといえる。

さすがに１５年くらいの仕事をしているだけでは、イノベータに出会う機会はそんなになく、事例は少ない。それでも１０人程度はイノベーッティブな仕事をしたと評価されている人に出会ったことがある。最近の例で言えば、ウィルコムのＷ－ＺＥＲＯシリーズを開発したエンジニアは長い付き合いだが、抜群のマネジメントセンスを持っていた。

エンジニアがプロジェクトマネジメントのスキルが必要だから身につけるというよりは、エンジニアとして自らの仕事を大きく花を咲かせるためにどのようなマネジメントスキルが必要かを考えてほしい。

それがプロジェクトの成功にもつながるし、エンジニア自身の成功にもつながる。

プロジェクト（マネジメント）の議論をするときに、スコープを仕様というニュアンスで使っている人が多いが、ご存知の通り、これは正しくない。スコープというのは成果物と役務の相対を指す言葉だ。ＰＭＢＯＫではこれをさらに明確にし、

●プロジェクトスコープ：規定された特性や機能を持つプロダクト、サービス、所産等を生み出すために実行しなくてはならない作業

●プロダクトスコープ：プロダクト、サービス、所産に特有の機能や特性

と区別して使えと書いている。

ここまではいいと思うが、では、スコープマネジメントというのは何をすることなのか？問題はこちらだ。仕様管理、構成管理、変更管理だと思っている人が多い。これが冒頭の話。

実は、ＷＢＳがうまくかけない悩みを持つＰＭは極めて多いが、ＷＢＳは両方のスコープを統合するツールであるので、このスコープマネジメントの認識がないとまず、上手に作れない。

実際には、ここに工法（仕事の進め方）が絡む。建築プロジェクトを考えてみると分かりやすいが、ある仕様の建築物を作ろうとすれば、必ず、工法を決める必要がある。これがプロダクトスコープとプロジェクトスコープである。プロジェクトスコープとプロダクトスコープは１対１の場合も少なくない。

逆にソフトウエアなどでは自由度が高く、プロダクトスコープは厳密に管理する必要があるが、プロジェクトスコープはあまり真剣に考えない。プロジェクト見積の中でも、プロダクトスコープをベースにして見積もり、それにプロジェクトスコープの配慮を入れるというのが普通である。

実際にはプロダクトスコープとプロジェクトスコープはもっと微妙な関連にある。プロジェクトの目的を達成するためにプロダクトスコープだけを調整するのではなく、プロジェクトスコープを調整することを考える必要もある。つまり、工法の工夫だ（要員数の調整もこの中に含まれる）。

このマネジメントを一口でいえば、プロジェクトスコープで調整するか、プロダクトスコープで調整するかを工夫することより、プロセスをシンプルにし、それによって生産性を上げること。

プロジェクトスコープとプロダクトスコープの両方をマネジメントする方法を説明することは非常に難しいが、よい本を見つけた。経営工学の大家で、良い仕事をされている慶応大学の中村善太郎先生のご本だ。

この本は、仕事を「もの」と「こと」に分けて、整理し、調整することにより、プロセスがシンプルになり、生産性が上がることを書かれた本。

先生の言われている「もの・こと」分析は、例えば

　「素材」を「製品」に変える「こと」

　はじめの「もの」をおわりの「もの」に変える「こと」

として捉え、この変換過程を、「もの・こと」図として書くことによって、スコープがきれいに整理でき、仕事の最適なプロセスを見つけるという発想。これは非常に分かりやすい。

この問題、結構、重要なのに考えられていない。

計画することをデスクワークだと考えているプロジェクトはだいたい失敗する。

　計画をするとは段取りをすること

である。つまり、計画の対象になる作業を実施する準備をすることである。

こんな例を考えてみて欲しい。

システムの受注開発をする。「計画書」に顧客から仕様が出てくると書く。その計画に基づいて、顧客にそのように対応してもらえるようにお願いをする。当然、顧客には顧客の都合があるので、素直にはウンを言わないが、そこを何とかしながら計画を実行していく。これをステークホルダマネジメントだという。ステークホルダマネジメントの甲斐なく、顧客からはお願いした通りのアウトプットは出てこない。結果として、スケジュールが遅れる。

このような状況はよくあるだろう。どこに、問題があるのだろうか？おそらく、多くの人はステークホルダマネジメントの問題をいうのだと思う。

しかし、このトラブルの本当の問題は、「計画ができていない」ところにある。計画を作るというのは、計画書に書くことのすべてについて、裏づけを取るという作業である。

どうもリスクマネジメントを導入するようになって、裏づけを取らずに、書いたことが実行できないのはリスクだと扱いたがる傾向がある。これはトンでもない間違いだ。

例えば、上の例で、顧客との間で、顧客側の具体的なスケジュールも含めて、合意をし、その通りにやってくれるという確約を取る。これは計画作業に他ならない。段取りだといってもよい。それでも、顧客の方に不測の事態が発生し、できないかもしれない。これがリスクだ。

確かに、ステークホルダマネジメントだとか、コミュニケーションマネジメントだとかが必要だというのはその通りなのだが、本当に必要なのは、計画の実行の中ではなく、計画を作るところである。

このような考え方で、pmstyle のプロジェクトマネジメント（ＰＭＢＯＫ準拠）はコミュニケーション計画を立ち上げプロセス群の中で、ステークホルダ分析を行うと同時に策定すべきだとしている。

これがプロアクティブなプロジェクトマネジメントである。

コミュニケーションに関心を持ち、コミュニケーションをトレーニングしようと考える人は多い。自分の失敗を振り返ってみると、そこにコミュニケーションの失敗があるというのがその理由だと思う。

左の図を見てほしい。ある組織で行ったトラブルの分析結果である（クリックすれば大きくなります）。過去のプロジェクトに対して、プロジェクトで発生したトラブルを大きいほうから３つ抽出し、その主要原因を２つまで上げていき、結果をＰＭＢＯＫの知識領域とプロセスのマトリクスを作り、分析したものだ（原因はほとんど２つ上がった）。

見て戴ければ分かるとおり、コミュニケーションが圧倒的に多い。

理由は、表面上は他のトラブルなのだが、分析するとコミュニケーションの問題もあるというケースが圧倒的に多かったためだ。

「犯罪の影に女あり」と同じくらい、「問題の影にコミュニケーションあり」は確率が高い。

ここでいうコミュニケーションって何かという問題。例えば、「口べたで相手にうまく自分の考えを伝えることができない。それゆえに問題になった」。こんなケースは、そうそうあるものではない。

コミュニケーションというのは車の運転と同じ。下手な人が、下手な人とであったときに初めて問題が生じる。それが顧客とベンダーという立場であったにしろ、丸く収まるのがコミュニケーションである。

昔に較べてコミュニケーションが問題になるというのは確かにスキルが低い人間が増えているということは間違いない。したがって、交通事故の可能性も高くなる。

じゃあ、みんなで車の運転を上手になりましょうという方向にいくかというと、そうは行かない。車の運転なんか個人の資質の問題があって、どんなに練習しても下手な人は下手だ。

では、どうするか？交通ルールを作るのだ。車線、信号、標識などなど。作っても、無視する輩がいるという問題はあるものの、ない状態に較べると、ずいぶん、まし。

でも、交通ルールだけでは解消できないような微妙な状況もある。例えば、山道を下っている。対向車が上ってきた。さて、問題。どちらが道を譲るか。道路交通法では規則はないが、上り優先という規範を作り、警察とか安全協会がそれをドライバーコミュニティで常識化している。

ここでさらに問題。そのときに谷側が崩れ落ちそうとか、あるいは、山側から落石がありそうだったらどうするか？これにしても、実際に警察が配っている教則には

「片側が転落のおそれがある崖になっている道路で、安全な行き違いができないときは、崖の側の車は一時停止して道をゆずりましょう。」

「山道では、路肩がくずれやすくなっていることがあります。このような場合の行き違いでは、路肩に寄り過ぎないよう注意しましょう」

と書いてあるらしい。これも規範なのだが、「上り優先」という規範とはずいぶん質が違うことが分かる。ドライバーの判断力が試される。つまり、ここでスキルが必要になるのだが、逆にいえば、ここまでは規範を決めることによってカバーできるという言い方もできる。

今のプロジェクトコミュニケーションを見ていると、スキルにばかり目が言っているが、規範はせいぜい、会議体だけである。これは交通ルールでいえば、道路交通法だけを決めているレベルだ。山道では上り優先というレベルの規範は決めていないし、さらに、その上のレベルの規範はまったく決めていないケースがほとんどだ。

なぜそんな状態となっているかいうと、規範も含めてコミュニケーションスキルだと考えていて、マネジメントとスキルの区別がついていないからだ。これは、みんなＦ１ドライバーになって行動を走ろうといっているに等しい。ありえない。

ルール・規範として決めるべきことは決める。そして、その規範を守る風土を作る。その上で、まだ、コミュニケーションの問題が発生するようなら、スキルベースを上げる。

そんなシステマティックな取り組みが必要なのではないかと思う。これがコミュニケーションマネジメントだし、そこまでできて、初めてコミュニケーションがマネジメントの基盤になる。

コミュニケーションが問題だ、重要だといっている人にこの議論を吹っかけると、１０人中９人まではそこまでしなくてもという。複雑性、新規性の高いプロジェクトで成功するのは、１人である。

まず、一冊の本を紹介しよう

ＭＢＡが会社を滅ぼす
https://mat.lekumo.biz/books/2006/07/__3d22.html

オビにこうある。

業績不振の米国企業のエグゼクティブのＭＢＡ取得比率　９０％
業績好調の米国企業のエグゼクティブのＭＢＡ取得比率　５５％

この本の原題は、　MANAGERS NOT MBAs　だ。

この数字を出した出版社の意図はよく分かる。まさに本書のタイトル。しかし、米国企業では半数以上のエグゼクティブがＭＢＡの保有者であるという風にも読める。

それはさておき、この本、マイケル・ポーターと並ぶマネジメント論のグル　ヘンリー・ミンツバーグが書いただけあって、マネジャーを育成することの難しさを的確に指摘し、それに対する彼独自の大胆な提案をしている。いろいろと共感することはあるが、一つあげると、マネジャーの教育はマネジャー経験があり、問題意識を持つものを対象にしないと意味がないと述べている。プロジェクトマネジャーもそうだ。

日本の教育はここを間違えているのではないだろうか？まず、問題意識がない。「まず、プロジェクトを失敗してはならない」という問題意識すらも怪しい。これは、プロジェクトマネジメントのガバナンスを明確にせず、集団牽引体制を取っているのが原因。

組織的にプロジェクトマネジメントをするという発想は悪くないと思うが、組織でプロジェクトマネジメントを行うことと、ガバナンスを曖昧にしておくというのは別の次元の話。いくら集団マネジメントをしていても、プロジェクトに関わるメンバーの一人ひとりに自分の責任と義務を聞いて具体的な答えが出てこないようであれば、話にならない。

だから、プロジェクトマネジャーは自分自身に問題意識を持たない。組織の方に目が行くので、仕組みや制度の問題指摘や改善に終始する。

そんなはずはない。どう少なめに見ても、プロジェクトマネジメントの失敗原因の８０％はプロジェクトマネジャーの個人の資質にある。組織的な取り組みをした場合には、求められるリーダーシップの質が変わってくるので、この数字は９０％とかに上がってくるだろう。

だからこそ、経験を通して、自分の足らないところを見つけ、育成プログラムの助けを借りながら開発していくことが必要。

このサイクルを作ることが、ＰＭＩの掲げるプロフェッショナルプロジェクトマネジャーのエシックスであるし、ドラッカーをはじめ、多くのプロフェッショナル論で真っ先に語られていることである。

このサイクルができなければ、

　　「 PROJECT MANAGERS NOT PMPs　」

といわれるようになってもおかしくない。現に、事例としては少ないが、ＰＭＢＯＫの適用の不適切さが原因でプロジェクトそのものを失敗させて事例を２～３知っている。

日本企業の課題は、組織的なプロジェクトマネジメントと個人のプロフェッショナリズムの滋養を如何に両立させていくかだ。

これがミンツバーグのこの本、全体の問題指摘でもある。