本ブログは移転しました。こちらをご覧ください。
◆米国流チームと日本流チーム
チームの書籍が目立つようになってきた。なぜ、今という気もするが、出版業界の戦略としては、そろそろ、個人向けの啓蒙本にかげりが見えてきたので、しばらくは別のところでといったところなのだろう。
チームといえば、ＰＭＩの示しているプロフェッショナル責任の中に「チームや利害関係者との協調関係」という項目があるように、プロジェクトマネジャーにとっては苦手の一つである。
以前、日経ＢＰ社の谷島編集委員に弊社のセミナーに出ていただいたときに、「日本人はチームワークを小学校のときから教え込み、チームワークがよいとされてきたが、プロジェクトをやってみるとそうでもないということがわかってきた」といわれていたが、さしむき、こんなところだろう。
なぜ、このような勘違いが生じるのか？一言でいえば、米国人の考えるチームは個ありき、日本人の考えるチームは集団にもかかわらず、それがチームだと考えているからだ。
本ブログは移転しました。こちらをご覧ください。
ＰＭＢＯＫの功罪はいろいろだと思うが、最大の「罪」はプロジェクトマネジメントを現場の管理技術に限定してしまい、プロジェクトの経営への貢献をないがしろしてしまっていることではないだろうか？もっとも、厳密にはＰＭＢＯＫに罪はない。むしろ、罪があるのはＰＭＢＯＫを管理手法だと理解して、そのようにしか使わなかった人たちにあるというべきだろう。
本ブログは移転しました。こちらをご覧ください。
◆あるメルマガ読者からの質問
お盆休みにあるメルマガ読者から次のような質問を戴いた。質問の中では、プライベートなことも含めて、いろいろなことが書かれているので、編集して、質問だけを再構成する。
定型業務で改善をすることが重要なのはよく分かる。しかし、プロジェクトにおける改善というのはどのような意味があるのか？改善によって本来の達成できないような作業を可能にするというのはそれなりに分かるが、それはリスクを伴うことであって、一概によいとはいえないのではないか？（実際はもっと柔らかい文面でした）
メルマガやブログに、
カイゼンによって、通常はできない目標にチャレンジしよう
ということをよく言っているが、こういう受け止め方をされているのかと知ってちょっと驚いた。なぜ、このように受け止めるのかと考えていて、あることに思い当たった。
◆仕事と作業
仕事と作業の違いがあまりきちんと認識されていないのではないか？
話は変わるが、ＷＢＳの「work」という言葉は日本では仕事という意味でも使うし、作業という意味でも使う。このためか、若干、混乱しているように思える。
言葉の定義としては、仕事というのは、解決すべき課題に対して答えを出すことであり、仕事を成し遂げるための手段が作業である。たとえば、
・市場調査をし、商品の機能を設計する
というのは仕事である。これに対して、
・収集されたデータの指定された分析方法で分析する
というのは作業である。ここで注意すべきことは、仕事と作業の間にも仮説があることだ。たとえば、市場データを収集してこういう方法で分析しようというのは、その分析方法によって市場ニーズが抽出できるという仮説を持っているからだ。仮説がないのは定型業務であり、仮説があるのが非定形業務であるといってもよいだろう。
◆成果とはなにか？
さて、もう一つ、考える要素がある。成果だ。成果というのは仕事によってもたらされる。つまり与えられた課題をどの程度解決したか、言い換えると仕事の品質が成果である。ここにも仮説が重要な役割を持っている。
仕事をしてどれだけの成果を上げるかどうかは、この仮説の妥当性によるといってもよい。たとえば、上で引き合いに出した商品開発で、市場調査をしなくても商品を作って市場投入することはできなくはない。しかし、それでは期待する成果が得られないと分かっているので、市場調査という仕事を行うのだ。
ＷＢＳというのは成果、仕事、作業（ワークパッケージレベル）の仮説を作るためのツールである。
※仮説について勉強したい人はこちら
◆プロジェクトにおける改善の考え方
さて、改善の話に戻る。
この構造を考えればわかるように、カイゼンには２つのレベルがある。ひとつは、作業レベルの改善である。仕事を行うために、できるだけ無駄なく、作業を組み立てられるように改善をする。ここでは仕事として設定された課題を効率よく解決することが目的であるので、基本的にはリスクは小さくなることはあって、大きくなることはあってはならない。
ここで作業時間が減るので、時間ができる。プロジェクトの場合、この時間の使い方が問題なのだ。どのような仕事を組み合わせれば成果が最大化されるか、この仮説を徹底的にブラッシュアップするためにこの時間を使わなくてはならない。
それによってはじめて、期待以上の成果を上げることが可能になるし、成果目標をストレッチしても実現が可能になる。
本ブログは移転しました。こちらをご覧ください。
プロジェティスタという考え方が注目を浴びている。きっかけになったのは、この本だ。
野田 稔+ミドルマネジメント研究会「中堅崩壊―ミドルマネジメント再生への提言」、ダイヤモンド社（2008）
プロジェティスタはイタリアで存在している職業で、一言でいえば、中小企業がプロジェクトを実施するときに、そのプロジェクトマネジメントを引き受ける。これにはイタリア独特の背景がある。イタリアでは、95％以上の企業が従業員9人以下という中小企業で、中小企業の輸出比率は60％に達する。イタリア企業の全体としての強みは、各企業間で縦横に張り巡らされた水平ネットワークであり、ネットワーク環境で活躍し、ある意味でこのネットワークを支えているのがプロジェティスタという職業だというわけだ。
日本もイタリアと同じように中小企業産業を支えている国であるが、大企業がビジネス中核を担い、中小企業はそこに対して技術を中心に部分的なコミットをするという産業構造を持つ日本ではプロジェティスタは成り立ちにくい職業である。しかし、その発想は大いに参考になる。実際に、野田先生が提案されているのも、企業内において、ミドルマネジメントのロールとしてプロジェティスタを位置づけることである。
このプロジェティスタという形は、プロジェクトマネジャーのロールモデルとして非常に卓越したものではないかと思う。
ＰＭＩがＰＭＢＯＫやＰＭＣＤＦ（Project Managemet Competency Development Framework）だけを提示していた時代は、プロジェクトマネジャーは独立性の強い仕事だという風に感じていた人も多いと思う。現に日本企業でＰＭＢＯＫに関心を持った企業のほとんどはそのようなプロジェクトマネジャー観を持っていたと思われる。
しかし、それは米国においてもあまり現実的な姿ではなく、また、ＰＭＩの標準を見ていてもその後、プログラムマネジメントやポートフォリオマネジメントにおける標準、さらには、これらすべてを束ねるＯＰＭ３という組織成熟度の標準が登場するに当たってはだんだん、見え方もプロジェクトマネジメントは組織ぐるみで行うものだという方向に変わってきている。
つまり、ガバナンスのマネジメントをきちんとして、プロジェクトマネジャー、プログラムマネジャー、ポートフォリオマネジャーといった「ロール」に、「プロジェクトマネジメント」、「プログラムマネジメント」、「ポートフォリオマネジメント」という「ツール」を使ってプロジェクトを組織としてマネジメントしていくという合理的なマネジメントシステムを構築し、戦略実行をしていこうという考え方が明確になってきた。
このような価値観は、従来からある日本の価値観に合わない点が出てきている。大きな問題は２つあるように思える。ひとつは、プログラムマネジメントやポートフォリオマネジメントといった組織マネジメントが含まれてくる部分は日本型経営の強みであった。ここを標準化してしまい、競争の対象から外してしまうのは、あまりにももったいない。米国は違うが、日本企業はこの部分のマネジメントに付加価値の源泉があるからだ。
そもそも、なぜ、こういう話になっているかと考えてみると、戦略経営が必要だということに尽きる。では、なぜ、戦略経営かと考えてみると、これはいくつかの理由はあるが、最大の理由はグローバルな競争である。グローバルな競争のためには戦略が必要である。これは事実だと思う。
ただし、では、日本型の組織では戦略経営が成り立たないかというとそんなことはない。トヨタがなによりもそれを証明しているし、たとえば、京都には日本市場に関心を持たず、いきなりグローバル市場に出ていき、マネジメントシステムを構築している会社がいくつもあるが、そのような企業の経営を見ていても、日本型経営のスタイルで戦略展開している。要するにこの議論は、戦略を持つべきであるということだけが問題であるにもかかわらず、抱き合わせ販売のように戦略達成のマネジメントをそこに押し付けられているところにあるのは明らかである。
つまり、戦略を作り、戦略実行ができるのであれば、どのような形でも構わないことになる。
二つ目の違和感は、個人にとってのやりがいの問題だ。米国のマネジメントシステムはキャリアアップをし、たくさんの報酬を得ることを望んでいるという価値観を基本にしている。ゆえに成果主義がうまく機能する。余談だが、そこに飽き足らなくなってくると、社会起業のような活動を始める。
日本人はこれではおそらくやりがいを感じない。米国のような価値観を持っている人もいるが、その人たちも５０歳くらいまでに価値観が変わることが多いようだ。では日本人は何にやりがいを感じるかというと、自分にとってのおもしろさであり、また、他人から感謝される（認められる）仕事である。従来から、生涯現役でいたいという人は多くいた。野田先生の著書の表現を変えると、生涯、一プレイヤーでいようという人だ。
ところが、成果主義の中ではこれは通用しない。野田先生の指摘するようにミドルまできて、プレイヤーである人はあきらめ感があるというくらい深刻な状況になっている。
ここでドロップアウトしたくない人は、マネジメントの仕事に入っていく必要がある。ところがマネジメントの仕事にやりがいを感じる人は多くないし、不安感のようなものがあるのだと思う。そこで、マネジャーではなく、プレイングマネジャーを目指す。
つまり、マネジャーの役割もするが、同時にプレイヤーという役割も果たすという人だ。部下を持ち、部下を使ったプロジェクトをいくつか同時にマネジメントするというスタイルで仕事をしているミドルマネジャーがこれだ。日本の企業が上に述べたように、日本型経営スタイルでなんとか戦略実行をできているのは、プレイングマネジャーの役割が大きいことも間違いない。
このようなスタイルで仕事をしている人は、野田先生が指摘するように「プロジェティスタ」に極めて近いし、逆に、プロジェティスタをロールモデル（手本）とすると自分たちの価値観を活かし、成果を上げることが可能になるのではないかと思われる。
以上のように考えてみると、プロジェティスタが日本の企業の中で普及していくことは、ミドルマネジメントが復活し、競争力をとり戻るために不可欠だと思えてくる。また、その意味で、プロジェクトマネジャーは次のステージとしてプロジェティスタを目指すというのがよいだろう。さらに、著者が「ひとつ上のプロマネ。」といっているものの、ひとつの実現イメージは間違いなく、プロジェティスタである。
ということで、しばらく、プロジェティスタというのを追いかけてみたい。
本ブログは移転しました。こちらをご覧ください。
◆プロジェクトの３大ステークホルダはそれぞれ、対立する目的を持つ
プロジェクトには多くのステークホルダがいる。プロジェクトマネジャーからみた場合の三大ステークホルダは、チーム、上位組織、顧客である。ここで言う顧客は、プロジェクトの成果物を活用して何らかの活用する人たちである。
プロジェクトの始まりには、プロジェクト憲章を作って、目的や成果目標、前提、制約を明確にしなさいという。たとえば、ＳＩベンダーのＳＩプロジェクトを例にとって考えてみよう。顧客はプロジェクトを起こした目的があるはずだ。それは、最終顧客に対するサービスの向上かもしれないし、あるいは、原価の低減かもしれない。いずれにしても、単純に考えれば、ＳＩベンダーに支払う費用が少なければ少ないほど、顧客の目的達成の度合いは大きくなることだけは間違いないだろう。
しかし、ベンダーにはベンダーの目的がある。利益を上げること、あるいは顧客との取引額を大きくするといったことだ。ここで早くも思惑が食い違う。顧客はお金を払いたくない。ベンダーは１円でもたくさんのお金をもらいたい。
さて、ここで視点を変えてプロジェクトチームのメンバーにはどのような目的があるのだろうか？プロジェクトをうまくやることによって、目標を達成し、評価を上げることが目標かもしれない。そのプロジェクトに新技術を適用し、習得することによって、その後のキャリアにプラスにすることが目的かもしれない。
いずれにしても、そんなに簡単に両立するようなものではない。
◆プロジェクトデザインとは結局のところ、目的の整合である
しかし、プロジェクトの目的は、このようにすべてのステークホルダの目的を満たすものでなくてはならない。プロジェクトのデザインをする中で、最も難しいのが、プロジェクトの目的の設定である。
多くの場合にはこれができないので、力関係で、まず、組織が顧客に対してなき、メンバーや下請けのベンダーが組織に対してなくという構図が描かれることが多い。これではだめだということで、なんとかしてみんなが満足する目的を見つけようという話になる。いわゆるＷｉｎ－Ｗｉｎの関係というやつだ。
ここでよく考えなくてはならないのは、目的の整合のさせ方には２つがあることだ。ひとつは文字通り、Ｗｉｎ－Ｗｉｎである。もう一つは共通点だけ取るという目的の設定の仕方だ。実は日本人は後者がとても得意である。
典型的な例を示そう。ＳＩプロジェクトで、「ユーザが満足する品質の○○システムを作ろう」という目的の設定である。このような目的が１００％プロジェクトの目的であるということはあり得ない。顧客もベンダーも戦略上の目的というのが必ずある。これだけで戦略上の目的が達成できればほとんど戦略などないと言ってもよい。
◆共通部分だけすり合わせするのはナンセンス
もうお分かりだと思う。このような部分的な目的設定をしておいて、あとは、属人的、あるいは場当たり的に適当にやっていこうというのが日本流なのだ。この場合、まず、戦略など顧みられることはない。ひたすら、当事者の満足やメンツといったものが重視される。要はそれで現場は丸く治まるのだ。何も目的の合わないところを公式にやりあって、勝ち負けをつける必要もないし、Ｗｉｎ－Ｗｉｎなどどうでもよいという感覚である。
ただし、これをやると、間違いなく、最もつらい思いをするのはプロジェクトである。一生懸命にやっても評価されない、責任は全部押し付けられるなど、悲惨なことになる。非公式な意思決定をするのだから弱いものが泣くのは当然である。
これではどんなにチームビルディングをやってみても、チームの一体感は生まれてこない。プロジェクト初期の緩い間はまだよいが、後半を迎え、本来チームワークがもっとも重要な修羅場になってくると、間違いなく、チームは崩壊する。チームの一体感を引き出すためには、まず、目的設定のところにとことんこだわり、目的が合意できない限り、プロジェクトは開始しないくらいの覚悟を持つことが必要である。
本ブログは移転しました。こちらをご覧ください。
プロジェクトの運用においてチームのマネジメントに対する関心が高まってきている。チームのパフォーマンスには２つの側面がある。ひとつは創造性であり、もう一つが生産性である。
創造性は「３人集まれば文殊の知恵」を実現することだ。知的生産性だと言ってもよい。
いろいろなアイディアが出てきて、１人では思いつかないような問題解決ができたり、素晴らしい商品アイディアが出てきたりする。これはファシリテーションをうまく行えば、確実に実現できる。
ところがチームはよい話だけではない。プロジェクトの中でも、設計作業や開発作業のような実務的な仕事をチームで行うと必ず、生産性が下がる。つまり、２人でやって２人分の仕事ができることは珍しい。せいぜい、１．５人分だろう。人数が増えれば増えるほど、パフォーマンスの低下は大きくなる。
よく、チームは２人で３人以上の仕事をするというが、これはこの２つがうまくいったときの状態を指している。つまり、創造性を高め、かつ、生産性を落とさない状態がチームなのだ。
チームが難しいのは、この２つには本質的なトレードオフがあることだ。
創造性を高めるにはできるだけ、自由に活動させる方がよい。しかし、あまり自由にさせると生産性が極端に低くなる。かつ、ＩＴのような顧客ビジネスのプロジェクトではこれに加えて、顧客への対応というもう一つのトレードオフが出てくることが多い。
このトレードオフを最適化するのがチームマネジメントだと言える。現実を見ていると、これらに優先順位を付けてチームを動かしていることが多い。たとえば、ソフトウエア開発のプロジェクトでは創造性を高めることを重視し、生産性を犠牲にしているケースが多い。また、同じＩＴでもＳＩプロジェクトでは生産性を重視し、創造性を犠牲にしているケースが多い。このようなトレードオフがトータルのパフォーマンスを高めるからだ。
しかし、これではマネジメントしているとはいえない。
どうすればよいか？創造性の向上によって実行力をカバーしていくこと、あるいは、逆に生産性の向上の中から創造的なコラボレーションを生み出していくことができて初めてチームのマネジメントだと言える。
プロジェクトマネジメントでは、ＷＢＳやＯＢＳによって分担をして仕事を進めていく。これはチームの生産性を落とさないためだ。チームへの第一歩は、ＯＢＳで決まった分担を前提にして、それを超えた行動をすることだ。ＷＢＳをいくら完璧に作ってもモレはあるものだし、突発的なできごともある。その中で、メンバーが自律的に判断をして、そのような事態に対処していけるようにすることである。
本ブログは移転しました。こちらをご覧ください。
チームマネジメントが注目されるようになってきた。チームマネジメントとはどんなことをするマネジメントだろうか？
チームの話でよくつかわれるエクスサイズに以下のようなものがある。
一郎君と次郎君と三郎君の３人兄弟がいる。お母さんに言われて、家の掃除をすることになった。一人でやれば６時間かかる。３人で一緒にやれば何時間かかるだろうか？
単純計算をすれば２時間である。しかし、このエクスサイズを行うといろいろな答えが出てくる。ポイントは２時間を超えるかどうか。代表的な意見は以下のようなものだ。
１人でやったの無駄は段取り変えにある。掃除機をかける、掃除機をかけれない場所をふく、窓ガラスをふくというところで、何度か段取り変えが出てくる。したがって、２人でやることによればこの段取り変えを減らすような分担ができるし、また、疲労が少なくなるのでパフォーマンスの低下が小さく、ゆえに２時間以下に減る。
というのが一つの意見。もう一つの代表的意見は、
二人でいくら効率的にやっても２時間かかるのだから、２人でやる作業の段取りを決めたり、作業の行き違いもあると思われるのでそもそも、ベースラインを２時間に設定するのがおかしい。したがって、いくら頑張っても２時間ではできないだろう。
というもの。
他にもお兄さんの太郎君のリーダーシップによるだろうとか、兄弟の仲がよいかどうかによって違うとか、掃除の道具ややり方によって違うとか、まあ、いろいろと出てくる。チームビルディングにもなると思うので、ぜひ、一度、あなたのチームでも議論してみてほしい。
掃除のようなベースラインのある作業を行う場合には、１人の場合と同じやり方をしたのでは２人でやって生産性が倍になることはまずない。コミュニケーションの問題とか、協働の問題で、必ず、生産性は落ちる。
ＦＦＳ理論という独自のチーム理論を展開しているヒューマンロジック研究所によると、１０人のチームではだいたい、ベースラインの生産性が６～７人分の生産性だという。このデータは実験に基づくちゃんとしたものだが、僕も感覚的にいえば、こんな感じだと思う。
チームとは３人が集まったときに３人分以上の仕事をする状態だというが、まずは如何に３人分の仕事をするかというのが問題になる。この問題は、リーダーシップの問題であったり、チームワークの問題であったり、モチベーションの問題であったりする。
同時に、３人で、１人ではできない方法で作業ができる方法がある。分業して慣れればパフォーマンスが上がるというような単純な課題はプロジェクトではあまりないと思われるが、それでも工夫すれば見つかることが多い。そして、作業者としての熟練と、プロセスの改善を継続的に行う。
この２つの要素を組み合わせてチームのパフォーマンスを上げていくのが、チームマネジメントである。
◆チームマネジメントを学びたい方はこちら！
〓【開催概要】〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
◆ 「ひとつ上のプロマネ。養成講座」
第４回 チームを育てるスキルを身につける◆７ＰＤＵ取得可能
日時：2008年8月20日（水） 10:00-18:00
場所：ヴィラフォンテーヌ汐留コンファレンスセンター（東京都港区）
講師：好川哲人（株式会社プロジェクトマネジメントオフィス）
詳細・お申込 www.pmstyle.biz/smn/team.htm
〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
【講義】
・チームを作るとはどういうことか
・プロジェクトマネージャーのリーダーシップ行動
・チームビルディングエクスサイズ
【グループ討議】
・管理と統率を両立するにはどうすればよいか
・メンバーのコミットメントをどのように引き出すか
【ロールプレイ】
・スケジュール遅延の際のリーダーシップ
【エクスサイズ】
・チームコミュニケーションエクスサイズ
〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓〓
本ブログは移転しました。こちらをご覧ください。
◆メンタルモデル
メンタルモデルという言葉を聞かれたことがあるだろうか？我々の心に固定化されたイメージや概念のことだ。刷り込み、思いこみだと言ってもよい。
ハーバードビジネスレビュー２００８年８月号にプロジェクトマネジャーのメンタルモデルをめぐるたいへん興味深い論文が載っていた。これだ。
キショア・セングプ、タレク・アブデル、ルーク・ファン・ワッセンホフ「プロジェクト・マネジャーが陥る「経験の罠」 」
この論文では、プロジェクトマネジメントのシミュレータを使って、数百人にのぼるベテランのプロジェクトマネジャーの調査をやっている。そして、その結果、必ずしも、これらの経験の豊富なプロジェクトマネジャーのパフォーマンスが高いわけではないことが分かった。むしろ、同じ失敗を繰り返し、パフォーマンスが低いケースが多いという結果が出た。
そしてその原因はなんと、従来、プロジェクトマネジャーの重要な資質だと考えられてきた「経験」にあるという結果を得たというのだ。
◆失敗を繰り返す３つの原因
実際に実験に協力したプロジェクトマネジャーの多くは、過去の判断ミスが反省せず、その後の意思決定に活かすこともなく、結局のところ、失敗を繰り返していることが多いが、その原因は３つあったそうだ。
ひとつ目は原因と結果の間にタイムラグがあることだった。タイムラグがあるので、因果関係がはっきりしない。たとえば、新たに加えたメンバーがチームに慣れ、思惑通りの能力を発揮するには常識的に考えて２～３か月かかるが、彼らはメンバーに加えるとすぐに能力を発揮するという判断をするのだ。そして、それは繰り返される。
二つ目は見込み違い。これは初期の見込みを修正できずに、チームに影響が出てくること。たとえば、生産性。ひとりひとりのメンバーの生産性に対して初期に設定した生産性が見込み違いであることが、進捗報告の評価によって判明しても無視する傾向がある。また、評価そのものを低めに行う傾向がある。これは、より多くのリソースを獲得したいという心理が働いているという。
三つ目はもっとも根深い問題だ。プロジェクト初期の目標が達成できそうにない場合に、彼らは目標の下方修正より、初期目標に拘り、ボロボロになりながらも何とか達成することにこだわるという。この背景には彼らのキャリアの中で「上司から与えられた目標は絶対である」というメンタルモデルが培われていくためだ。実際のところ、多くの企業では目標の下方修正は「失敗の自認」であるとみなされると指摘する。
このようにベテランのプロジェクトマネジャーは、長年、培われてきたメンタルモデルが支配し、それゆえに適切な判断ができなくなる傾向があるという論文である。これを防ぐためには、プロジェクト管理の仕組みの中に認知フィードバックの仕組みを入れて、プロジェクトマネジャーに思い込みに気付かせることが重要であると述べられている。まさに、アーンドバリューなどはそのためにあるといってもよいだろう。
以前、プロジェクトマネジャーの育成では失敗を糧にすべきという意見に対して、ＰＭ学会会長の富永氏に、「ＩＢＭでは失敗するプロジェクトマネジャーは何度でも失敗を繰り返す」と指摘されたが、結局、こういうことなのだろう（ちなみに、この論文で、企業名は明記されていないが、ＩＢＭと思われる企業がこの問題対処のベストプラクティスに取り上げられているので、ＩＢＭははやくからこの問題に気づき、対処していたのかもしれない）
◆経験を積めばつむほど失敗要因が強化される
少し、この論文から離れる。
この問題は、むしろ、メンタルモデルに起因するものなので、経験を積めばつむほど、強化されることになる。何とも考えさせられる論文である。全般的な印象でいえば、キャリアの浅いプロジェクトマネジャー（職位でいえば係長クラス）でこのような問題を感じさせる人は少ない（まれにエンジニアとしてのこのような感覚をそのまま引きずっている人がいるくらい）。ところが、シニアプロジェクトマネジャーになると、何を言っても自分の思い込みの世界から抜けきれないという人がよく見られる。明らかに強化されているわけだ。
ただ、これはそんなに単純な問題ではないことだけは言っておきたい。つまり、プロジェクトの状況で白黒がはっきりしていればアドバイスもできるが、本質的にはプロジェクトの状況も認知の問題であるので、そうは思わないと一言言われれば抗う余地はなくなる。したがって、対処のまずさも本人が気づくしかないのだ。
◆現場にみる３つの罠
また、この論文で指摘される３つのこの問題も、よく見かける。
最初のラグに対応できないという問題はかなり深刻な問題である。問題解決をする際にはアクションに必ずラグが出てくるが、このラグを考慮した問題解決を行うことのできるプロジェクトマネジャーにはほとんどお目にかからない。
二番目の見込み違いもよく見かける問題だ。多くのプロジェクトマネジャーは見積もりが間違っていたと認識した時点で計画を放棄する傾向がある。見積もりを見直して、新たな計画を作ってその計画に従って、プロジェクトを進めていこうとはまず考えない。ＰＭツールを使い、生産性を一括して変更できてもなかなかやろうとしない。初期の設定に拘り、なんとか、今の生産性をベースにして管理しようと工夫する。初期の設定が間違っていることはプロジェクトマネジャーとして決定的な落ち度になると考える傾向があるようだ。
これはプロジェクトの命取りになりかねない。
三番目も多い。なかなか、プロジェクトマネジャーが上位組織に対して、スコープ削減、納期変更などの目標の下方修正を申し入れることはない。これは不思議な現象だが、この論文のようにメンタルモデルを持ちだされるとよく分かる。そして、この論文の指摘通り、たとえば、１００％のスコープを９０％にして納期どおり、スケジュール通りに達成するよりは、大幅なスケジュール遅れ、大幅なコスト超過を起こしても、１００％のスコープを達成する方が評価される傾向がある。一度、コンサルティングに入った商品開発プロジェクトで、スコープ削減の提案をしたが通らず、２億円の予算が２億８千万円、開発期間１１か月が１５ヵ月になったが、プロジェクトマネジャーもメンバーも評価されて、びっくりしたことがある。
結局、上位のマネジャーは目的を達成するプレッシャーが一層強い。それゆえにこのようなことになるのだろう。
なんとはなくだが、コンサルティングの中で、抱いていた感じが、シミュレーションによってきちんと実証された感じだ。この論文はいろいろと使える！
本ブログは移転しました。こちらをご覧ください。
ＰＭＢＯＫプロジェクトマネジメントの導入をすると、例外なく、ドキュメントワークの大変さを訴えるプロジェクトマネジャーが出てくる。実際にプロジェクトの立ち上げの際には時間の制約があり、かつ、マネジメント業務が集中する中でやらなくてはならないので、本当に大変だと思う。いくら、ドキュメントワークに慣れているといっても、欧米のプロジェクトマネジャーはこれだけのドキュメントを本当に書くのかと疑問を持っているプロジェクトマネジャーも少なくない。
そう思った経験のある人は、ＰＭＢＯＫのプロジェクト活動の図式をもう一度、みてほしい。実はプロジェクトマネジメントの仕事というのはプロジェクトマネジャーが一人でやるような図式になっていないのだ。少なくとも、プロジェクトマネジメントを担当すべき人は３名いる。
（Ａ）プロジェクトマネジャー
（Ｂ）プロジェクトスポンサー
（Ｃ）プロジェクトマネジメントチーム
である。プロジェクトマネジメントの指揮をするのがプロジェクトマネジャーであることは間違いないのだが、それはプロジェくマネジメントチームを結成し、プロジェクトマネジメントの体制を作り、さらには、プロジェクトスポンサーへのマネジメント活動の依頼をすることを意味している。
さて、プロジェクトマネジメント業務を分類すると、以下のように分けることができる。
（１）プロジェクト体制の整備
（２）プロジェクト運営方針の調整とステークホルダの調整
（３）プロジェクト運営に関する意思決定
（４）プロジェクトの統制
（５）プロジェクトマネジメント成果物作成作業
（６）プロジェクトの対外的アピール
ＰＭＢＯＫで問題にされているドキュメントワークの多さは、（４）の量の多さである。
さて、ここで問題は誰が何をするかだ。まず、確実にプロジェクトマネジャーの仕事だと言えるのは、（１）～（４）である。そして、（１）の中で、プロジェクトマネジメントチームの編成をする。その上で、（５）を依頼する。また（６）はプロジェクトスポンサーの仕事である。
ところが、現実には、（１）～（６）のほどんどがプロジェクトマネジャーの仕事になっている。これでは、いくら時間があっても足りない。
プロジェクトマネジャーがプロジェクトの立ち上げで真っ先にやるべきことは、プロジェクト憲章の作成でもなく、スコープの明確化でもない。プロジェクトの形を一緒に作ることのできるプロジェクトマネジメントチームの結成である。
本ブログは移転しました。こちらをご覧ください。
◆型と形
６月２５日のPMstyle＋メールマガジンの巻頭言に守破離（しゅはりと読む）について書いたのだが、短時間で簡単に書いたので、もう少し、詳しく調べて記事にしてみた。
どうも、守破離を論じる前の問題として、型とは何かという問題があるようだ。PMスタイルという型に関係するコンセプトを打ち出しながらいまさらの話で恐縮なのだが、いろいろと調べてみた。
東北大学名誉教授の源了圓先生は、型とは何かと考えるときに、形と型はどう異なるのか？がポイントだと指摘している。源先生によると、型を構成するものは心技体であり、
「型」とは、ある「形」が持続化の努力を経て洗練・完成したものであり、機能性・合理性・安定性を有し、一種の美をもっている。さらにそれは模範性と統合性を具えている。
【出典】http://www.sal.tohoku.ac.jp/80thanniv/minamoto.html
と指摘する。型が機能性、合理性、安定性、規範性、統合性というのは、分野に関わらず、型である限り必要な要素だというのは納得ができる。プロジェクトマネジメントで、米国プロジェクトマネジメント協会（ＰＭＩ）により１９８７年に初めてまとめられたプロジェクトマネジメント標準と１９９６年にまとめられたＰＭＢＯＫ第１版を比較してみるとこれは非常によく分かる。
◆型とは家と間からなる
編集工学を唱える松岡正剛氏は、
型というものは、いろいろのものと一緒にある。一番わかりやすくいえば「家」と「間」とともにある。「家」は職能の伝統を守る門のことで、ここに家元も出てくれば、入門も破門も出てくる。
【出典】http://www.isis.ne.jp/mnn/senya/senya1100.html
と指摘する。
家は上の説明の通りである。日本人にはＰＭＩを家だと見做している人が少なくない。違うと思うが、まあ、そう考えたい気持ちはわからなくはない。
◆間とステークホルダマネジメント
説明しにくいのは間である。日本人にとって、「間が悪い」などという言葉があるように、間という概念は浸透している。しかし、説明となると難しい。そもそも、間というのはなぜ必要なのか？
間について調べていたところ、やはり、源先生の指摘がもっとも納得できた。著者なりにまとめてみると、
間というのは心技体の心の部分に関わるものである。いろいろな間があるが、たとえば、能の世阿弥は父である観阿弥の教えを成熟させていく中で、本質的な美の追求と、観客を本位とした美の実現という異なる二つの方向性を、いかにして両立させるかという問題に行き当たった。そこで、静止してはいるが全身全霊がこもった緊張状態である「せぬ隙」を生み出した。ただし、そうした内心の精神的な動きを観客に知られては具合が悪いので、自分自身が自分の心を隠すことが必要だと考えた。これが「無心」であり、無心ができて、心技体が完成する
というのが源先生の見解である。プロジェクトマネジメントの型を極める中で、この間というは意外と重要ではないかと思われる。ステークホルダマネジメントの本質は間にあるのではないかと思うからだ。
◆型の成熟と守破離
このように型というのはいろいろな視点がある。このほかにの見方もあると思うが、源先生の指摘のように「形」の延長線上にあるのだと思う。つまり、型を極めるというのは、形から入り、型を覚え、型を破り、新しいものを作っていくプロセスということになる。
このプロセスを示したのは、守破離である。このプロセスを、守破離という言葉で表現したのは、江戸時代の茶匠、川上不白の『不白筆記』である。
川上不白の『不白筆記』では、
守ハマモル、破ハヤブル、離ハハナルと申候。
とある。また、川上不白は『茶話集』で
守は下手、破は上手、離は名人
とも記している。
この考え方自体は禅の考え方で、川上不白が影響を受けたのではないかと推察される達人がいる。ひとりは上で名前の出てきた世阿弥で、『風姿花伝』で「序破急」を説いた。もう一人は歌集『利休百首』にて、
規矩作法 守り尽くして 破るとも 離るるとても 本を忘るるな」
と説いた千利休である。いずれにしても、まず最初は型を守り、次に型を崩してみる。そして、最終的に型から離れるというプロセスである。離れるというのが若干イメージしにくいが、離れるというのは松岡正剛氏の家が重要な要素であるという説明を考えるとよく分かる。家を離れるのだ。家を離れたからといって好き勝手にやってよいという話にはならない。千利休のいうように「本を忘るるな」である。すなわち、本質を見失うなということだ。
◆プロジェクトマネジメントにおける守
この守破離のプロセスは、プロジェクトマネジメントにおいても、展開でき、有用なものであると思われる。
まずは、守である。教えられた型を徹底して学ばなければならない。この学びの中では形が出発点になる。形を覚え、そこから型の意味を学んでいくのだ。スキルを「身につける」とかいうのは、この段階をさす言葉で、ここでは教えが必要である。
プロジェクトマネジメント道では、ＰＭＢＯＫの型を覚え、ＰＭＰの資格を取るというのが王道かもしれないが、ＰＭＢＯＫにこだわる必要はない。ある程度の範囲で型と認めているものであれば、何でもよい。たとえば、企業独自の流儀とか、業界独自の流儀とかでもよいわけだ。
◆プロジェクトマネジメントにおける破
次の「破」はその身に付いたスキルをつかって、行動をすることだ。あまり使わない言葉だが、身につけるに対して、「身を働かせる」といってもよい。落語で芸を揶揄する言葉に「箱入り」というのがあるが、この段階で箱からでなくてはならない。そのためには創造性や工夫が必要である。そして行動において重要なことは、その行動による影響をきちんと認識し、感じておくことが必要だ。
プロジェクトマネジメントでいえば、ＰＭＢＯＫを覚え、実際にやってみる中で、現実に合わないところがあれば、変えていく。たとえば、プロセスのインプットやアウトプットを変える、ツールを変えるといったこと。あるいは、プロセスそのものを破ることも破だといってもよいかもしれない。
ここで重要なことは、実際に変えてみたときにどのようなことが起こったかをしっかりと観察し、型の持つ意味をしっかりと理解することだと思う。それが上手に型を崩すことにつながっていく。
◆離とはキャリアである
そして、「離」は自由自在に行動すること。しかし、本質を踏み外してはならない。
能や茶道のような求道的なものとは少し違うかもしれないが、マネジメントにおいてもやはり、この本質なるものはあると思われる。本質に行き当たるには、何のために仕事をしているのか、そして何のためにマネジメントをするのかというところがポイントになるのだろう。
それはたぶん、顧客のためであったり、社会のためであったり、あるいは自身のためであったりする。著者はビジネスの世界ではそこまでに積み上げてきたキャリアを活かして仕事をする、あるいはキャリアをかけて仕事をするといったことが、離に当たるのではないかと思っている。ここで重要なことは、自由に行動するということは、すなわち、自身のキャリアをかけているのだということをきちんと認識することである。
キャリアが型に変わると言ってもよいと思う。
型を持たないスタイル、キャリアをかけて仕事をするというスタイル。これが「ひとつ上のプロマネ。」の目指しているところである。
最近のコメント