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

神戸大学の金井先生の「働くみんなのモチベーション論」に出てくるエクスサイズです。

６．と７．は別にして、１．～５．はチームビルディングの中で使ってみてはどうでしょうか？試しにあるプロジェクトのキックオフミーティングの試してみたところ、効果抜群でした。

コミュニケーションとは相互理解。適切な指示をするのも必要だが、はやり、相手の本質の理解。相手の本質でもっとも大切な部分ってやっぱりやる気だと思いませんか？

エナジー＆エナジャイズ！

====

１．自分が調子よくがんばれているときと、無気力になってしまっているとき、この両者を分けている要因はなんだと思いますか。具体的な場面を念頭において考えください。

２．自分の身の回りで、概していつもがんばり屋さんのひとと、たいてい手抜きで熱心な姿をあまり見ないひとを比べて、どこに大きな違いがあるのか、考えてください。

３．（１．と関連して）自分が調子よくがんばれているとき、上司はいったいどのような行動を自分に対してとってくれていましたか。行動の特徴を、そのひとの持ち味 や発想法とあわせて振り返ってみてください。

４．（２．と関連して）がんばり屋さんのひとにいっそう励んでもらい、また、手抜きのひとに発破をかけるためには、どのような行動をとりますか。

５．自分がこれまでお仕えした上司のなかで、もっとも信頼できるし、このひとならついていってもいいと思ったひとの、発想、行動の特徴、人間としての持ち味には、 どのような特徴がありますか。

６．（１．と２．をもとに）自分が信じる自分なりのモティベーションの持論を言語 化してみてください。
（a）キーワードを並べるレベル
（b）キーワードを相 互に関連づけるレベル
（c）キーワード間の関連をうまく例示するレベル
（d）自分なりのセオリーとしてもっと整理されているレベル
のうち、出来る限りより上位のレベルに至るような持論を書いてみてください。たとえば、（c）で例 示される方は、例示に先立って、(a-1）キーワードのリストと（a-2）キーワード間の関連の記述を記してください。

７．すでに、これまでなんらかのモティベーションの理論を、学生時代、自己啓発と読書、社内の研修、社外のセミナー・講演等を通じて、学んだことがあるひとは、上記の（６．）の記述が、だれのどのような理論や概念の影響を受けているかについても記してください。

よく、「元気を貰う」、「元気を与える」という言い方をするが、部下（メンバー）に元気を与えることはリーダーとして重要なことだ。

元気なリーダーには２タイプある。一つは、いつも元気で、周りのみんなも元気にするタイプのリーダーだ。もう一つはいつも元気だが、周りは元気のないタイプのリーダーだ。どうも、後者の方が多いような気がしている。

コンサルティングをしているとよく出会うのはこのタイプのプロジェクトだ。プロジェクトマネジャーやプロジェクトリーダーはやたらと元気で、如何にもバリバリと仕事をしている。しかし、プロジェクトはうまく行かない。メンバーに元気がない。失敗するプロジェクトチームの典型である。

かつて、ＧＥのジャックウェルチはリーダーシップでは３つのＥが大切だといっていた。

　Energy：仕事を成し遂げる情熱を持て
　Energize：組織の精神に自信を植えつけろ
　Edge：厳しい決断にもひるむな

Energyは自分が元気になることで、Energizeは周囲を元気にすることだ。もうひとつのEdgeはエッジを切るということで、際立った行動をすることだ。ウェルチはＧＥのリーダーにこの３つを求めた。

ところがこれだけでは成果が出ないことがわかってきた。活性化されているのに成果がでない。そこで、Ｅをもう一つ追加した。

　Execute：場外ホームランをかっ飛ばせ

である。実行性である。一説によると、ジェック・ウェルチは「経営は「実行」」を書いた羽ウェルの元ＣＥＯのラリー・ボシディの影響を受けてこのＥを追加したという説もある。

また、詳しいことは、「プロジェクトリーダーシップの教科書」で書こうと思っているが、プロジェクトマネジャーはこの４つのＥをリーダーシップとして持たなくてはならないと思う。

それはともかく、チームを元気付けるにはどうすればよいか？「笑力」といった話もあるが、少し違うように思う。

ビジョンを明確にし、任せることだ。

この逆をやっている人は多い。ビジョンをろくに示さない。仕事は任せない。しかし、これみよがしに、飲みにいく。プロジェクトワークプレイスに登場し、騒ぎながら、コミュニケーションと称したふれあいを行う。「はしゃいでいる」と周囲をしらけさせる。

これこそ、自分が元気だが、周りの元気を無くするリーダーである。こうはなりたくないものだ。

プロジェクトマネージャー養成マガジンの次の書籍読者プレゼントは

アービンジャー・インスティチュート（金森 重樹監訳、富永星訳）「自分の小さな「箱」から脱出する方法」

の予定だ。自分の箱に閉じこもって、箱に外にいろいろと影響をするようなリーダーシップでは本質的な問題解決にならず、自ら箱の外に出て、影響を与えていくようなリーダーシップと、そのためには、問題の原因はすべて自分にあるという考え方が重要であるということをストーリー形式で書いた本である。

この本の指摘はプロジェクトマネジメントにとって非常に有益である。プロジェクトマネジメントではしばしば、チームビルディングなどでチームに視点が偏りすぎるために、ついつい、箱の中からプロジェクトステークホルダに対応することが多い。極端な場合には、本来、プロジェクトチームに片足入っているはずのプロジェクトスポンサーすら、箱の外から影響を与えようとすることが多い。

これによって、箱の外で付き合えば味方になるステークホルダを敵に回しているようなケースがおおいのだ。

さらに、チーム内でもプロジェクトチームの中でも、プロジェクトマネジャーが箱の中にいてプロジェクトメンバーを動かしているケースが多い。この背景には、スコープ区分やＷＢＳによって分業をしていることと無関係ではない。

分業をして責任範囲を明確にし、その上でチームが一丸となってプロジェクト目標をクリアしていこうという一見矛盾する考え方であるが、この矛盾をとく鍵が「箱から出ること」にあるのではないかと思う。

箱から出る鍵は、自己原因性（Personal Causation）にある。自分原因説を唱える人も少なくないが、これだ。

プロジェクトチームとステークホルダの間、チームメンバー間、チームメンバーとプロジェクトマネジャー間、いずれも、責任転嫁の嵐が吹き荒れているプロジェクトが多い。しかし、責任転嫁は何も生み出さない。問題を先送りするだけである。

例えば、顧客が忙しくて対応してくれない。「顧客が悪いのだから仕方ない」というのは簡単だ。しかし、それでプロジェクトの状況が変わるかというと決してよくならない。

こんなときには、まず、自分たちに顧客が対応してくれない理由がないのかと考えてみる。これはＳＩのプロジェクトで実際にあった話だが、ベンダーの担当者を好きになれないので、忙しさにかまけてついつい対応が遅れるというようなことだってあるのだ。

ステークホルダとの問題においてはプロジェクト側に原因がある、メンバー間においては自分に問題があるという視点を持ってプロジェクトを進めていくと、格段にパフォーマンスはあがるだろう。

PMsytleでは、プロジェクトマネジャー成熟度モデルを作っている。今のところ、あまり公開する必要がないので、公開していないが、１０月からPMstyle.bizで「プロジェクトリーダーシップの教科書」というＷｅｂ連載を始めた。この中で、プロジェクトリーダーシップモデルを公開したので、併せて、公開しておく。

まず、こちらがプロジェクトマネジャー成熟度モデルだ（クリックすれば大きくなる）。プロジェクトマネジャーのスキルが高度化してくるとプロジェクトマネジャーとしての成熟度も上がってくるというパターンを想像された方は半分はずれ。

スキルはどうでもよいとは言わないが、スキルよりはコンピテンシー重視のモデルになっている。

それで、こちらがプロジェクトリーダーシップの５段階モデル。こちらについては、上に書いた連載を読んでほしい。

ＰＭＢＯＫ流のプロジェクトマネジメントは統制のツールであり、言ってしまえば、曖昧性を許容しないマネジメント論である。いわば、「子供のマネジメント」である。いくらリスクという形で不確実性を扱う概念を持ち込んでも、限界だなと思うことが時々ある。

マネジメントの世界でも内部統制が注目されるようになってきたので、そろそろ、このような領域に突入する可能性が高い。

話は変わるが株式市場では、村上ファンドの出現、西武事件、ライブドア事件など、この１０年くらいで多くの出来事が重なり、経営者同士が親しいとか、資本ガバナンスとはかけ離れたわけの分からない株式の持合がだんだん崩れてきて、世界標準ルールに徐々に近づいてきた。これはよいことだと思う。

しかし、マネジメントプラットホームは本当にそうなのか？

内部統制で何をするかを考える前に、この命題を考えてみる必要がある。内部統制を強化しないとエンロンのような不祥事が生じるという単純な理屈だけで米国流に押し切きられてしまうと、根底から競争優位性を失うことになる。ちょうど、外交の世界をみているような感じになると思う。

いくらグローバル化するために共通のプラットホームが必要だからといって、米国流の統制が唯一のプラットホームであるはずはない。米国は人種の坩堝なので、米国流マネジメントはダイバーシティに強いというのは米国の経営学者が言っていることに過ぎない。

米国流が創り上げたグローバリズムに異議を唱える国があってもよいと思う。そのときに担保すべきなのは、公正さであり、ガバナンスや透明性ではないだろう。

プロジェクトマネジメントはダイバーシティ（多様性）が前提になっている。

そもそも、ダイバーシティとは何か？日本語に訳すと多様性という。日本でビジネスの場面でダイバーシティという言葉が良く使われるのは女性の活用に関してである。雇用、職務の割り当て、マネジャーへの登用など、いろいろな場面で、女性の活用の必要が認識されており、それを実現することをダイバーシティという。

女性の活用は、ジェンダーダイバーシティという問題である。ダイバーシティには、性別に関するものだけではない。国籍、宗教、年齢、会社といった比較的明確なものから、専門性、価値観、仕事の仕方といった比較的曖昧なものまでいろいろある。

いつの時代にもある、「最近の若いものは、、、」というのもダイバーシティの一つだといえる。

ダイバーシティのない中でマネジメントを行うのは非常にたやすい。お互いにお互いを理解できている。従って、放っておいてもそれなりの成果がでる。

さすがにいまでは表立った意見としては少なくなってきたが、プロジェクトマネジメント導入の非効率性を指摘する意見は、このダイバーシティが存在しないことから生じている。お互いにそれなりに分かっており、「あうん」の呼吸で協力しあう。このような世界ではプロジェクトマネジメントなど必要ない。プロジェクトマネジャーに女性が少ないのも、おそらく、このことと無関係ではあるまい。

マネジメントオーバーヘッドというのは投資対効果で測るものなので、手間がかかる（投資が大きい）割には、効果が小さいという意見が出てくるのはある意味で必然である。

ところが、何らかの理由でダイバーシティが生じると、そうは行かない。よい例が、システム開発の分野で行われているオフショア開発だ。ここで日本人は最初何をしようとしたか？「同質化」である。つまり、ダイバーシティを殺すことによって、ダイバーシティのないマネジメントをしようとした。ある種の植民地的思想である。

ところがその限界に気がついてきた。それはそうだ。取引というのは相互作用を前提にしたものなので、一方のカルチャーに統一しようという図式は成り立つはずがない。そこで、ダイバーシティを重視する政策を取るようになってきた。彼らのやり方を重視するようになってきた。

ところが、過剰反応して任せっぱなしにするようになった。当然、うまく行かない。また、ガバナンスを渡してはダメだという議論になる。この繰り返しを延々としているように思う。欧米のダイバーシティマネジメントを上手に行う企業がうまく適応しているのとは対象的である。

この問題は意外と根が深いのではないかと思う。この背景には、日本人自身がダイバーシティを認める自らのベースラインを持たないことがあるような気がして仕方ない。

これは別の機会に。

オブジェクト指向開発に従事している人はよくご存知だと思うが、「メタ」という概念がある。メタは英語で

　背後の、後ろの、より包括的な、超えた

といった意味を持つ接頭語である。

オブジェクト指向でなぜメタという言葉が使われているかというと、情報の定義を階層化するためである。例えば、ポチという犬がいたとしよう。ポチは具体的な実体である（これをインスタンスという）。ポチの特徴を説明するために、もちろん、ポチそのものに注目してもいいのだが、ポチは犬なので、犬の持っている特徴（例えば、４本足であるくとか、耳が２つ、目が２つあって、尻尾が１本あり、ワンと鳴くとか）は持っている。そこで、まず、どんな犬でも持っている特徴をまとめておき（これを犬クラスという）、ポチだけが持っている毛の色だとか、尻尾の曲がり具合だとかだけを表現してやればポチの特徴が表現できる。

この犬クラスが持っているを、ポチという実体に対する「メタ情報」という言い方をする。

メタという概念がどういうものかお分かりいただけたと思うが、メタという概念は非常にマネジメントの中でも重要な概念である。プロジェクトマネジメントをうまく行うためには、「メタな計画」というのが非常に重要である。

例えば、スケジュール計画を考えてみよう。スケジュール計画におけるメタな計画とは、スケジュールを作る際に、１日何時間働くのかとか、土日はどうするのかとか、作業単位をどうするかとか、２人で作業を行ったときに１．８人分の仕事をすると見るのか、２．２人分の仕事をすると見るのかとか、そういったことである。つまり、スケジュールの中のすべてのアクティビティに共通する性質、言い換えるとスケジュールを作る際のルールである。

プロジェクトマネジメントには前提条件という考え方があるが、一種の前提条件である。

この構造は一つのプロジェクトの中にかぎった話ではない。プログラムマネジメントの場合には、メタ計画はプログラムとしてつくり、インスタンス計画を各プロジェクトで作っていく。また、このメタ計画は組織として一つに決めておくこともできる。これが標準化である。

計画を作る際には、メタ計画として扱った方がよいものと、インスタンス計画として扱った方がよいものをプロジェクトマネジャーの意志として明確に区別することが重要だ。

プロジェクトマネジメントの中では、このメタ計画のことを「プロジェクトマネジメント計画」と呼ぶ。

プロジェクトマネジメント計画書とプロジェクト計画を混乱している人が多い。

プロジェクト計画とは、ＷＢＳ（スコープ計画）、スケジュール、予算（コスト計画）、品質計画などを指す言葉である。基本的に作業計画である。開発計画だといってもよい。

プロジェクトマネジメント計画は２つの要素に分けることができる。一つは開発計画のマネジメントに関する計画である。

例えば、どのような方針で計画を策定するのか、計画にどのようなリスクがあるのか、計画の変更はどのような（意思決定）手順で行うかといったことを決めるのがプロジェクトマネジメント計画である。

もう一つは、開発計画の実行に対して、そのようなマネジメント的なサポート活動をしていくかに関する計画である。この計画に中には、コミュニケーションの計画、リスクの計画、調達の計画、人的資源の計画などが含まれる。

プロジェクトマネジメントを導入するというのは、計画を作ってプロジェクトを進めていくことだということもできるが、正確にいえば、上に述べた２つの意味でのプロジェクトマネジメント計画を作ってプロジェクトを進めていくことである。

プロジェクトマネジメント計画の中でもっとも重要なのは、リスク計画やコミュニケーション計画ではなく、ＳＱＣＤのマネジメントに対する計画であるにも関わらず、実践ができていない企業が多いのが、マネジメント計画の策定である。

ＰＭ養成マガジンでは、この問題、今まで、２つの視点から議論してきた。

一つは、マネジメントと管理という視点である。

もう一つは、コンピテンシーと（テクニカル）スキルという視点である。

すごく乱暴な議論をすれば、

　プロジェクトマネジメントはテクニカルスキルを駆使してプロジェクト成果の管理行うものだ

と考えている人はプロジェクトマネジメントをサイエンスとして捉えている人である。

逆に、

　プロジェクトマネジメントはコンピテンシーを発揮してプロジェクト成果を出すような人のマネジメントをするものだ

と考えている人はプロジェクトマネジメントをアートとして捉えている人である。

僕自身はプロジェクトマネジメントはアート５０％、サイエンス５０％であると思っている。そして、自身のコミットメントとしては、コンサルティングにしろ、トレーニングにしろ、アートの部分に焦点を当てている。

この両輪のバランスが取れていないと、プロジェクトはとんでもない方向に進んでしまうだろう。

そろそろ、アートというのを全面に押し出していこうかな、、、

プロジェクトマネジメントはサイエンスかアートか。あまり議論されない問題である。

おそらく議論されない理由はみんながサイエンスだと思っているからだろう。

確かに、プロジェクトマネジメントの系譜をたどれば、少なくとも近代プロジェクトマネジメントはＯＲなどの経営工学に立脚しており、まさしくサイエンスである。

しかし、マーケティングがアート５０％、サイエンス５０％といわれるように、マネジメントには何がしかにアートの要素がある。

では、一般的なマネジメントとプロジェクトマネジメントを比較したときに、どちらがアートの要素が大きいのか？これは明らかにプロジェクトマネジメントである。なぜかというと課題解決の不確実性の大きさが異なるからだ。

マーケティングにアートの要素が多いのも同じ理由だ。３Ｃとか、４Ｐのような分析をして、予測をして、満を期して上市した商品が外れる。と思えば、とりあえず、穴埋めに出しておけといった感じの商品が大ヒットする。

この不確実性の要因の多くは市場を形成する消費者の行動にある。一言でいえば、人は思わぬ行動を取る。良いと思っていない商品でも、友達が持っていればほしくなる。三重だけで消費をする、などなど。

プロジェクトマネジメントにおける不確実性も同じような構造をしている。大半の不確実性は「人に纏わること」から生まれている。

メンバーが気まぐれ、顧客がわがまま、上司は自分の出世しか考えていない、などなど。この不確実性をマネジメントするのはサイエンスだけでは無理だ。

アートが必要である。