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

◆Ｘチームとは

先月、本屋さんで本を見ていたら、見慣れない言葉を目にした。「Ｘチーム」という言葉だ。著者はＭＩＴスローンビジネススクールの教授であるととにも、ＭＩＴリーダーシップセンターのファカルティ・ディレクターである、デボラ・アンコナ。

それよりも目を引いたのが、帯。「学習する組織」のピーター・センゲと、「組織文化とリーダーシップ」のエドガー・シャイン。学習とリーダーシップのグルである。

Ｘチームとは何か？一言でいえば、つねに外部との接触のあるチームのことだ。詳しくは、このビジネス書の杜の記事を読んでほしい。

イノベーションが必須とされる競争社会で生き残るためのチーム

◆ビジネスチームでは、１＋１＝２は理想

前の記事で、チームは２人で３人以上の仕事をする集団であると述べたが、これは本当にそうなのか？という問題を提起しておきたい。

１＋１＞２なのか、１＋１＝２なのかという議論はある意味、どうでもよい。ここで考えたいことは、ビジネスにおいては、自然な状態では

　１＋１＜２

であるということだ。

創造性云々はともかく、プロジェクトチームで人数分のパフォーマンスが出ているチームというのはまず、お目にかからない。もっとも生産性のトリックで、１人の生産性を１人仕事の生産性より小さくしてしまえばそういうことはありうるわけだが、その場合その生産性の定義そのものが、１＋１＜２を前提にしていることになる。

だとすれば、チームの理想論のような浮ついた議論をする前に、如何に１＋１を２にするかを真剣に考えるべきである。

◆米国流チームと日本流チーム

チームの書籍が目立つようになってきた。なぜ、今という気もするが、出版業界の戦略としては、そろそろ、個人向けの啓蒙本にかげりが見えてきたので、しばらくは別のところでといったところなのだろう。

チームといえば、ＰＭＩの示しているプロフェッショナル責任の中に「チームや利害関係者との協調関係」という項目があるように、プロジェクトマネジャーにとっては苦手の一つである。

以前、日経ＢＰ社の谷島編集委員に弊社のセミナーに出ていただいたときに、「日本人はチームワークを小学校のときから教え込み、チームワークがよいとされてきたが、プロジェクトをやってみるとそうでもないということがわかってきた」といわれていたが、さしむき、こんなところだろう。

なぜ、このような勘違いが生じるのか？一言でいえば、米国人の考えるチームは個ありき、日本人の考えるチームは集団にもかかわらず、それがチームだと考えているからだ。

ＰＭＢＯＫの功罪はいろいろだと思うが、最大の「罪」はプロジェクトマネジメントを現場の管理技術に限定してしまい、プロジェクトの経営への貢献をないがしろしてしまっていることではないだろうか？もっとも、厳密にはＰＭＢＯＫに罪はない。むしろ、罪があるのはＰＭＢＯＫを管理手法だと理解して、そのようにしか使わなかった人たちにあるというべきだろう。

◆あるメルマガ読者からの質問

お盆休みにあるメルマガ読者から次のような質問を戴いた。質問の中では、プライベートなことも含めて、いろいろなことが書かれているので、編集して、質問だけを再構成する。

定型業務で改善をすることが重要なのはよく分かる。しかし、プロジェクトにおける改善というのはどのような意味があるのか？改善によって本来の達成できないような作業を可能にするというのはそれなりに分かるが、それはリスクを伴うことであって、一概によいとはいえないのではないか？（実際はもっと柔らかい文面でした）

メルマガやブログに、

　カイゼンによって、通常はできない目標にチャレンジしよう

ということをよく言っているが、こういう受け止め方をされているのかと知ってちょっと驚いた。なぜ、このように受け止めるのかと考えていて、あることに思い当たった。

◆仕事と作業

仕事と作業の違いがあまりきちんと認識されていないのではないか？

話は変わるが、ＷＢＳの「work」という言葉は日本では仕事という意味でも使うし、作業という意味でも使う。このためか、若干、混乱しているように思える。

言葉の定義としては、仕事というのは、解決すべき課題に対して答えを出すことであり、仕事を成し遂げるための手段が作業である。たとえば、

・市場調査をし、商品の機能を設計する

というのは仕事である。これに対して、

・収集されたデータの指定された分析方法で分析する

というのは作業である。ここで注意すべきことは、仕事と作業の間にも仮説があることだ。たとえば、市場データを収集してこういう方法で分析しようというのは、その分析方法によって市場ニーズが抽出できるという仮説を持っているからだ。仮説がないのは定型業務であり、仮説があるのが非定形業務であるといってもよいだろう。

◆成果とはなにか？

さて、もう一つ、考える要素がある。成果だ。成果というのは仕事によってもたらされる。つまり与えられた課題をどの程度解決したか、言い換えると仕事の品質が成果である。ここにも仮説が重要な役割を持っている。

仕事をしてどれだけの成果を上げるかどうかは、この仮説の妥当性によるといってもよい。たとえば、上で引き合いに出した商品開発で、市場調査をしなくても商品を作って市場投入することはできなくはない。しかし、それでは期待する成果が得られないと分かっているので、市場調査という仕事を行うのだ。

ＷＢＳというのは成果、仕事、作業（ワークパッケージレベル）の仮説を作るためのツールである。

※仮説について勉強したい人はこちら

仮説を制す者はマネジメントを制す

◆プロジェクトにおける改善の考え方

さて、改善の話に戻る。

この構造を考えればわかるように、カイゼンには２つのレベルがある。ひとつは、作業レベルの改善である。仕事を行うために、できるだけ無駄なく、作業を組み立てられるように改善をする。ここでは仕事として設定された課題を効率よく解決することが目的であるので、基本的にはリスクは小さくなることはあって、大きくなることはあってはならない。
ここで作業時間が減るので、時間ができる。プロジェクトの場合、この時間の使い方が問題なのだ。どのような仕事を組み合わせれば成果が最大化されるか、この仮説を徹底的にブラッシュアップするためにこの時間を使わなくてはならない。

それによってはじめて、期待以上の成果を上げることが可能になるし、成果目標をストレッチしても実現が可能になる。

プロジェティスタという考え方が注目を浴びている。きっかけになったのは、この本だ。

野田 稔+ミドルマネジメント研究会「中堅崩壊―ミドルマネジメント再生への提言」、ダイヤモンド社（2008）

プロジェティスタはイタリアで存在している職業で、一言でいえば、中小企業がプロジェクトを実施するときに、そのプロジェクトマネジメントを引き受ける。これにはイタリア独特の背景がある。イタリアでは、95％以上の企業が従業員9人以下という中小企業で、中小企業の輸出比率は60％に達する。イタリア企業の全体としての強みは、各企業間で縦横に張り巡らされた水平ネットワークであり、ネットワーク環境で活躍し、ある意味でこのネットワークを支えているのがプロジェティスタという職業だというわけだ。

日本もイタリアと同じように中小企業産業を支えている国であるが、大企業がビジネス中核を担い、中小企業はそこに対して技術を中心に部分的なコミットをするという産業構造を持つ日本ではプロジェティスタは成り立ちにくい職業である。しかし、その発想は大いに参考になる。実際に、野田先生が提案されているのも、企業内において、ミドルマネジメントのロールとしてプロジェティスタを位置づけることである。

このプロジェティスタという形は、プロジェクトマネジャーのロールモデルとして非常に卓越したものではないかと思う。

ＰＭＩがＰＭＢＯＫやＰＭＣＤＦ（Project Managemet Competency Development Framework）だけを提示していた時代は、プロジェクトマネジャーは独立性の強い仕事だという風に感じていた人も多いと思う。現に日本企業でＰＭＢＯＫに関心を持った企業のほとんどはそのようなプロジェクトマネジャー観を持っていたと思われる。

しかし、それは米国においてもあまり現実的な姿ではなく、また、ＰＭＩの標準を見ていてもその後、プログラムマネジメントやポートフォリオマネジメントにおける標準、さらには、これらすべてを束ねるＯＰＭ３という組織成熟度の標準が登場するに当たってはだんだん、見え方もプロジェクトマネジメントは組織ぐるみで行うものだという方向に変わってきている。

つまり、ガバナンスのマネジメントをきちんとして、プロジェクトマネジャー、プログラムマネジャー、ポートフォリオマネジャーといった「ロール」に、「プロジェクトマネジメント」、「プログラムマネジメント」、「ポートフォリオマネジメント」という「ツール」を使ってプロジェクトを組織としてマネジメントしていくという合理的なマネジメントシステムを構築し、戦略実行をしていこうという考え方が明確になってきた。

このような価値観は、従来からある日本の価値観に合わない点が出てきている。大きな問題は２つあるように思える。ひとつは、プログラムマネジメントやポートフォリオマネジメントといった組織マネジメントが含まれてくる部分は日本型経営の強みであった。ここを標準化してしまい、競争の対象から外してしまうのは、あまりにももったいない。米国は違うが、日本企業はこの部分のマネジメントに付加価値の源泉があるからだ。

そもそも、なぜ、こういう話になっているかと考えてみると、戦略経営が必要だということに尽きる。では、なぜ、戦略経営かと考えてみると、これはいくつかの理由はあるが、最大の理由はグローバルな競争である。グローバルな競争のためには戦略が必要である。これは事実だと思う。

ただし、では、日本型の組織では戦略経営が成り立たないかというとそんなことはない。トヨタがなによりもそれを証明しているし、たとえば、京都には日本市場に関心を持たず、いきなりグローバル市場に出ていき、マネジメントシステムを構築している会社がいくつもあるが、そのような企業の経営を見ていても、日本型経営のスタイルで戦略展開している。要するにこの議論は、戦略を持つべきであるということだけが問題であるにもかかわらず、抱き合わせ販売のように戦略達成のマネジメントをそこに押し付けられているところにあるのは明らかである。

つまり、戦略を作り、戦略実行ができるのであれば、どのような形でも構わないことになる。

二つ目の違和感は、個人にとってのやりがいの問題だ。米国のマネジメントシステムはキャリアアップをし、たくさんの報酬を得ることを望んでいるという価値観を基本にしている。ゆえに成果主義がうまく機能する。余談だが、そこに飽き足らなくなってくると、社会起業のような活動を始める。

日本人はこれではおそらくやりがいを感じない。米国のような価値観を持っている人もいるが、その人たちも５０歳くらいまでに価値観が変わることが多いようだ。では日本人は何にやりがいを感じるかというと、自分にとってのおもしろさであり、また、他人から感謝される（認められる）仕事である。従来から、生涯現役でいたいという人は多くいた。野田先生の著書の表現を変えると、生涯、一プレイヤーでいようという人だ。

ところが、成果主義の中ではこれは通用しない。野田先生の指摘するようにミドルまできて、プレイヤーである人はあきらめ感があるというくらい深刻な状況になっている。

ここでドロップアウトしたくない人は、マネジメントの仕事に入っていく必要がある。ところがマネジメントの仕事にやりがいを感じる人は多くないし、不安感のようなものがあるのだと思う。そこで、マネジャーではなく、プレイングマネジャーを目指す。

つまり、マネジャーの役割もするが、同時にプレイヤーという役割も果たすという人だ。部下を持ち、部下を使ったプロジェクトをいくつか同時にマネジメントするというスタイルで仕事をしているミドルマネジャーがこれだ。日本の企業が上に述べたように、日本型経営スタイルでなんとか戦略実行をできているのは、プレイングマネジャーの役割が大きいことも間違いない。

このようなスタイルで仕事をしている人は、野田先生が指摘するように「プロジェティスタ」に極めて近いし、逆に、プロジェティスタをロールモデル（手本）とすると自分たちの価値観を活かし、成果を上げることが可能になるのではないかと思われる。

以上のように考えてみると、プロジェティスタが日本の企業の中で普及していくことは、ミドルマネジメントが復活し、競争力をとり戻るために不可欠だと思えてくる。また、その意味で、プロジェクトマネジャーは次のステージとしてプロジェティスタを目指すというのがよいだろう。さらに、著者が「ひとつ上のプロマネ。」といっているものの、ひとつの実現イメージは間違いなく、プロジェティスタである。

ということで、しばらく、プロジェティスタというのを追いかけてみたい。

◆プロジェクトの３大ステークホルダはそれぞれ、対立する目的を持つ

プロジェクトには多くのステークホルダがいる。プロジェクトマネジャーからみた場合の三大ステークホルダは、チーム、上位組織、顧客である。ここで言う顧客は、プロジェクトの成果物を活用して何らかの活用する人たちである。

プロジェクトの始まりには、プロジェクト憲章を作って、目的や成果目標、前提、制約を明確にしなさいという。たとえば、ＳＩベンダーのＳＩプロジェクトを例にとって考えてみよう。顧客はプロジェクトを起こした目的があるはずだ。それは、最終顧客に対するサービスの向上かもしれないし、あるいは、原価の低減かもしれない。いずれにしても、単純に考えれば、ＳＩベンダーに支払う費用が少なければ少ないほど、顧客の目的達成の度合いは大きくなることだけは間違いないだろう。

しかし、ベンダーにはベンダーの目的がある。利益を上げること、あるいは顧客との取引額を大きくするといったことだ。ここで早くも思惑が食い違う。顧客はお金を払いたくない。ベンダーは１円でもたくさんのお金をもらいたい。

さて、ここで視点を変えてプロジェクトチームのメンバーにはどのような目的があるのだろうか？プロジェクトをうまくやることによって、目標を達成し、評価を上げることが目標かもしれない。そのプロジェクトに新技術を適用し、習得することによって、その後のキャリアにプラスにすることが目的かもしれない。

いずれにしても、そんなに簡単に両立するようなものではない。

◆プロジェクトデザインとは結局のところ、目的の整合である

しかし、プロジェクトの目的は、このようにすべてのステークホルダの目的を満たすものでなくてはならない。プロジェクトのデザインをする中で、最も難しいのが、プロジェクトの目的の設定である。

多くの場合にはこれができないので、力関係で、まず、組織が顧客に対してなき、メンバーや下請けのベンダーが組織に対してなくという構図が描かれることが多い。これではだめだということで、なんとかしてみんなが満足する目的を見つけようという話になる。いわゆるＷｉｎ－Ｗｉｎの関係というやつだ。

ここでよく考えなくてはならないのは、目的の整合のさせ方には２つがあることだ。ひとつは文字通り、Ｗｉｎ－Ｗｉｎである。もう一つは共通点だけ取るという目的の設定の仕方だ。実は日本人は後者がとても得意である。

典型的な例を示そう。ＳＩプロジェクトで、「ユーザが満足する品質の○○システムを作ろう」という目的の設定である。このような目的が１００％プロジェクトの目的であるということはあり得ない。顧客もベンダーも戦略上の目的というのが必ずある。これだけで戦略上の目的が達成できればほとんど戦略などないと言ってもよい。

◆共通部分だけすり合わせするのはナンセンス

もうお分かりだと思う。このような部分的な目的設定をしておいて、あとは、属人的、あるいは場当たり的に適当にやっていこうというのが日本流なのだ。この場合、まず、戦略など顧みられることはない。ひたすら、当事者の満足やメンツといったものが重視される。要はそれで現場は丸く治まるのだ。何も目的の合わないところを公式にやりあって、勝ち負けをつける必要もないし、Ｗｉｎ－Ｗｉｎなどどうでもよいという感覚である。

ただし、これをやると、間違いなく、最もつらい思いをするのはプロジェクトである。一生懸命にやっても評価されない、責任は全部押し付けられるなど、悲惨なことになる。非公式な意思決定をするのだから弱いものが泣くのは当然である。

これではどんなにチームビルディングをやってみても、チームの一体感は生まれてこない。プロジェクト初期の緩い間はまだよいが、後半を迎え、本来チームワークがもっとも重要な修羅場になってくると、間違いなく、チームは崩壊する。チームの一体感を引き出すためには、まず、目的設定のところにとことんこだわり、目的が合意できない限り、プロジェクトは開始しないくらいの覚悟を持つことが必要である。

プロジェクトの運用においてチームのマネジメントに対する関心が高まってきている。チームのパフォーマンスには２つの側面がある。ひとつは創造性であり、もう一つが生産性である。

創造性は「３人集まれば文殊の知恵」を実現することだ。知的生産性だと言ってもよい。

いろいろなアイディアが出てきて、１人では思いつかないような問題解決ができたり、素晴らしい商品アイディアが出てきたりする。これはファシリテーションをうまく行えば、確実に実現できる。

ところがチームはよい話だけではない。プロジェクトの中でも、設計作業や開発作業のような実務的な仕事をチームで行うと必ず、生産性が下がる。つまり、２人でやって２人分の仕事ができることは珍しい。せいぜい、１．５人分だろう。人数が増えれば増えるほど、パフォーマンスの低下は大きくなる。

チームマネジメントの前提

よく、チームは２人で３人以上の仕事をするというが、これはこの２つがうまくいったときの状態を指している。つまり、創造性を高め、かつ、生産性を落とさない状態がチームなのだ。

チームが難しいのは、この２つには本質的なトレードオフがあることだ。

創造性を高めるにはできるだけ、自由に活動させる方がよい。しかし、あまり自由にさせると生産性が極端に低くなる。かつ、ＩＴのような顧客ビジネスのプロジェクトではこれに加えて、顧客への対応というもう一つのトレードオフが出てくることが多い。

このトレードオフを最適化するのがチームマネジメントだと言える。現実を見ていると、これらに優先順位を付けてチームを動かしていることが多い。たとえば、ソフトウエア開発のプロジェクトでは創造性を高めることを重視し、生産性を犠牲にしているケースが多い。また、同じＩＴでもＳＩプロジェクトでは生産性を重視し、創造性を犠牲にしているケースが多い。このようなトレードオフがトータルのパフォーマンスを高めるからだ。

しかし、これではマネジメントしているとはいえない。

どうすればよいか？創造性の向上によって実行力をカバーしていくこと、あるいは、逆に生産性の向上の中から創造的なコラボレーションを生み出していくことができて初めてチームのマネジメントだと言える。

プロジェクトマネジメントでは、ＷＢＳやＯＢＳによって分担をして仕事を進めていく。これはチームの生産性を落とさないためだ。チームへの第一歩は、ＯＢＳで決まった分担を前提にして、それを超えた行動をすることだ。ＷＢＳをいくら完璧に作ってもモレはあるものだし、突発的なできごともある。その中で、メンバーが自律的に判断をして、そのような事態に対処していけるようにすることである。

チームマネジメントが注目されるようになってきた。チームマネジメントとはどんなことをするマネジメントだろうか？

チームの話でよくつかわれるエクスサイズに以下のようなものがある。

一郎君と次郎君と三郎君の３人兄弟がいる。お母さんに言われて、家の掃除をすることになった。一人でやれば６時間かかる。３人で一緒にやれば何時間かかるだろうか？

単純計算をすれば２時間である。しかし、このエクスサイズを行うといろいろな答えが出てくる。ポイントは２時間を超えるかどうか。代表的な意見は以下のようなものだ。

１人でやったの無駄は段取り変えにある。掃除機をかける、掃除機をかけれない場所をふく、窓ガラスをふくというところで、何度か段取り変えが出てくる。したがって、２人でやることによればこの段取り変えを減らすような分担ができるし、また、疲労が少なくなるのでパフォーマンスの低下が小さく、ゆえに２時間以下に減る。

というのが一つの意見。もう一つの代表的意見は、

二人でいくら効率的にやっても２時間かかるのだから、２人でやる作業の段取りを決めたり、作業の行き違いもあると思われるのでそもそも、ベースラインを２時間に設定するのがおかしい。したがって、いくら頑張っても２時間ではできないだろう。

というもの。

他にもお兄さんの太郎君のリーダーシップによるだろうとか、兄弟の仲がよいかどうかによって違うとか、掃除の道具ややり方によって違うとか、まあ、いろいろと出てくる。チームビルディングにもなると思うので、ぜひ、一度、あなたのチームでも議論してみてほしい。

掃除のようなベースラインのある作業を行う場合には、１人の場合と同じやり方をしたのでは２人でやって生産性が倍になることはまずない。コミュニケーションの問題とか、協働の問題で、必ず、生産性は落ちる。

ＦＦＳ理論という独自のチーム理論を展開しているヒューマンロジック研究所によると、１０人のチームではだいたい、ベースラインの生産性が６～７人分の生産性だという。このデータは実験に基づくちゃんとしたものだが、僕も感覚的にいえば、こんな感じだと思う。

チームとは３人が集まったときに３人分以上の仕事をする状態だというが、まずは如何に３人分の仕事をするかというのが問題になる。この問題は、リーダーシップの問題であったり、チームワークの問題であったり、モチベーションの問題であったりする。

同時に、３人で、１人ではできない方法で作業ができる方法がある。分業して慣れればパフォーマンスが上がるというような単純な課題はプロジェクトではあまりないと思われるが、それでも工夫すれば見つかることが多い。そして、作業者としての熟練と、プロセスの改善を継続的に行う。

この２つの要素を組み合わせてチームのパフォーマンスを上げていくのが、チームマネジメントである。

◆チームマネジメントを学びたい方はこちら！

〓【開催概要】〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
　◆　「ひとつ上のプロマネ。養成講座」
　　　　第４回　チームを育てるスキルを身につける◆７ＰＤＵ取得可能
　　日時：2008年8月20日（水）　10:00-18:00
　　場所：ヴィラフォンテーヌ汐留コンファレンスセンター（東京都港区）
　　講師：好川哲人（株式会社プロジェクトマネジメントオフィス）
　　詳細・お申込　www.pmstyle.biz/smn/team.htm

〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
【講義】
・チームを作るとはどういうことか
・プロジェクトマネージャーのリーダーシップ行動
・チームビルディングエクスサイズ
【グループ討議】
・管理と統率を両立するにはどうすればよいか
・メンバーのコミットメントをどのように引き出すか
【ロールプレイ】
・スケジュール遅延の際のリーダーシップ
【エクスサイズ】
・チームコミュニケーションエクスサイズ
〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓

◆メンタルモデル

メンタルモデルという言葉を聞かれたことがあるだろうか？我々の心に固定化されたイメージや概念のことだ。刷り込み、思いこみだと言ってもよい。

ハーバードビジネスレビュー２００８年８月号にプロジェクトマネジャーのメンタルモデルをめぐるたいへん興味深い論文が載っていた。これだ。

キショア・セングプ、タレク・アブデル、ルーク・ファン・ワッセンホフ「プロジェクト・マネジャーが陥る「経験の罠」 」

この論文では、プロジェクトマネジメントのシミュレータを使って、数百人にのぼるベテランのプロジェクトマネジャーの調査をやっている。そして、その結果、必ずしも、これらの経験の豊富なプロジェクトマネジャーのパフォーマンスが高いわけではないことが分かった。むしろ、同じ失敗を繰り返し、パフォーマンスが低いケースが多いという結果が出た。

そしてその原因はなんと、従来、プロジェクトマネジャーの重要な資質だと考えられてきた「経験」にあるという結果を得たというのだ。

◆失敗を繰り返す３つの原因

実際に実験に協力したプロジェクトマネジャーの多くは、過去の判断ミスが反省せず、その後の意思決定に活かすこともなく、結局のところ、失敗を繰り返していることが多いが、その原因は３つあったそうだ。

ひとつ目は原因と結果の間にタイムラグがあることだった。タイムラグがあるので、因果関係がはっきりしない。たとえば、新たに加えたメンバーがチームに慣れ、思惑通りの能力を発揮するには常識的に考えて２～３か月かかるが、彼らはメンバーに加えるとすぐに能力を発揮するという判断をするのだ。そして、それは繰り返される。

二つ目は見込み違い。これは初期の見込みを修正できずに、チームに影響が出てくること。たとえば、生産性。ひとりひとりのメンバーの生産性に対して初期に設定した生産性が見込み違いであることが、進捗報告の評価によって判明しても無視する傾向がある。また、評価そのものを低めに行う傾向がある。これは、より多くのリソースを獲得したいという心理が働いているという。

三つ目はもっとも根深い問題だ。プロジェクト初期の目標が達成できそうにない場合に、彼らは目標の下方修正より、初期目標に拘り、ボロボロになりながらも何とか達成することにこだわるという。この背景には彼らのキャリアの中で「上司から与えられた目標は絶対である」というメンタルモデルが培われていくためだ。実際のところ、多くの企業では目標の下方修正は「失敗の自認」であるとみなされると指摘する。

このようにベテランのプロジェクトマネジャーは、長年、培われてきたメンタルモデルが支配し、それゆえに適切な判断ができなくなる傾向があるという論文である。これを防ぐためには、プロジェクト管理の仕組みの中に認知フィードバックの仕組みを入れて、プロジェクトマネジャーに思い込みに気付かせることが重要であると述べられている。まさに、アーンドバリューなどはそのためにあるといってもよいだろう。

以前、プロジェクトマネジャーの育成では失敗を糧にすべきという意見に対して、ＰＭ学会会長の富永氏に、「ＩＢＭでは失敗するプロジェクトマネジャーは何度でも失敗を繰り返す」と指摘されたが、結局、こういうことなのだろう（ちなみに、この論文で、企業名は明記されていないが、ＩＢＭと思われる企業がこの問題対処のベストプラクティスに取り上げられているので、ＩＢＭははやくからこの問題に気づき、対処していたのかもしれない）

◆経験を積めばつむほど失敗要因が強化される

少し、この論文から離れる。

この問題は、むしろ、メンタルモデルに起因するものなので、経験を積めばつむほど、強化されることになる。何とも考えさせられる論文である。全般的な印象でいえば、キャリアの浅いプロジェクトマネジャー（職位でいえば係長クラス）でこのような問題を感じさせる人は少ない（まれにエンジニアとしてのこのような感覚をそのまま引きずっている人がいるくらい）。ところが、シニアプロジェクトマネジャーになると、何を言っても自分の思い込みの世界から抜けきれないという人がよく見られる。明らかに強化されているわけだ。

ただ、これはそんなに単純な問題ではないことだけは言っておきたい。つまり、プロジェクトの状況で白黒がはっきりしていればアドバイスもできるが、本質的にはプロジェクトの状況も認知の問題であるので、そうは思わないと一言言われれば抗う余地はなくなる。したがって、対処のまずさも本人が気づくしかないのだ。

◆現場にみる３つの罠

また、この論文で指摘される３つのこの問題も、よく見かける。

最初のラグに対応できないという問題はかなり深刻な問題である。問題解決をする際にはアクションに必ずラグが出てくるが、このラグを考慮した問題解決を行うことのできるプロジェクトマネジャーにはほとんどお目にかからない。

二番目の見込み違いもよく見かける問題だ。多くのプロジェクトマネジャーは見積もりが間違っていたと認識した時点で計画を放棄する傾向がある。見積もりを見直して、新たな計画を作ってその計画に従って、プロジェクトを進めていこうとはまず考えない。ＰＭツールを使い、生産性を一括して変更できてもなかなかやろうとしない。初期の設定に拘り、なんとか、今の生産性をベースにして管理しようと工夫する。初期の設定が間違っていることはプロジェクトマネジャーとして決定的な落ち度になると考える傾向があるようだ。

これはプロジェクトの命取りになりかねない。

三番目も多い。なかなか、プロジェクトマネジャーが上位組織に対して、スコープ削減、納期変更などの目標の下方修正を申し入れることはない。これは不思議な現象だが、この論文のようにメンタルモデルを持ちだされるとよく分かる。そして、この論文の指摘通り、たとえば、１００％のスコープを９０％にして納期どおり、スケジュール通りに達成するよりは、大幅なスケジュール遅れ、大幅なコスト超過を起こしても、１００％のスコープを達成する方が評価される傾向がある。一度、コンサルティングに入った商品開発プロジェクトで、スコープ削減の提案をしたが通らず、２億円の予算が２億８千万円、開発期間１１か月が１５ヵ月になったが、プロジェクトマネジャーもメンバーも評価されて、びっくりしたことがある。

結局、上位のマネジャーは目的を達成するプレッシャーが一層強い。それゆえにこのようなことになるのだろう。

なんとはなくだが、コンサルティングの中で、抱いていた感じが、シミュレーションによってきちんと実証された感じだ。この論文はいろいろと使える！