PMstyleプロデュース

◆セルフメンタリング

前回はコンピテンシー開発では、適切なレベルの目標を設定することがポイントであることを説明した。今回は、この目標をいかにクリアしていくかを述べる。

漠然と目標設定をしただけでは、なかなかクリアできるものではない。そこで、目標を作ったら、それを中間目標に細分化し、中間目標のクリアを積み重ねていけば最終的な目標もクリアできるような方法を考える必要がある。ちょうど、プロジェクトにおけるＷＢＳのような考え方である。ここで、セルフメンタリングという方法を提案したい。

セルフメンタリングのプロセスは、以下のようなものである。

　（１）課題（中間ゴール）設定
　　　→　（２）行動の決定
　　　　　→　（３）行動
　　　　　　　　→　（４）結果のまとめ
　　　　　　　　　　→　（５）新しい課題の設定

◆課題の設定

課題の設定では上に述べたように、目標を達成するための中間ゴールを設定する。

例えば、目標をプロジェクトの目的に対して優先順位の高い作業から着手していくことだとしよう。一見、なんでもない目標に見えるが、そう簡単には達成できない。例えば、ある商品をアップグレードした商品を開発するプロジェクトだとしよう。このプロジェクトの優先準の高い課題は２つある。一つは、売りになるポイント（商品差別化コンセプト）を決めることである。もう一つは、その仕様を実現するための手段（技術など）を確立することである。順序的には、仕様を決めて、手段を確立すること。

ところが、ありがちな話として、サーベイをしてみたが、コンセプトが明確に見えてこない。弱い。これでは、エグゼクティブマネジャーは承認しないだろう。そこで、もう少し練ろうという話になる。ただし、事業計画に載っている開発なので、上市時期は変えることはできない。

こんなときにあなたらなどうするだろうか？多くの人がここで考えることは、コンセプト固めはするとしてそれだけでは手があまる。そこで、とりあえず、いずれやらなくてはならないことで今すぐにできることは何かということだ。結論として、例えば、とりあえず、現行商品の改善点の検討はすぐにできるのでしようということになる。

ところがこのケース、本当に優先順位が高いのは、コンセプトデザインとともに、技術開発である。コンセプトデザインと「原理」は深い関係がある。すぐにやらなくてはならないことは、コンセプトに対する仮説を設定して技術検討をすることなのだが、
なかなかできない。

◆セルフメンタリングの課題設定

さて、ここでセルフメンタリングの課題はどのように設定するのだろうか？

まず、最初は決まっていないことに対して、

　「常に仮説設定をして物事を考えるようになる」

ことだ。多くの人にとって、これが最初に取り組むべき課題であろう。ここで、前回述べたように、課題として「優先順位を設定し、優先順位の高いものには仮説設定を行う」といった複雑な課題にすると挫折する人もたくさんいるだろう。自分のレベルをよく考えて、また、課題の本質が何かをよく考えて、できるだけシンプルな課題設定をすることが望ましい。

◆コンピテンシー学習のポイントは目標設定

前回はコンピテンシー学習の進め方について述べた。コンピテンシーを学習するにあたっては、何がポイントになるのだろうか？

コンピテンシー開発とは行動できるようになるということである。そのためには行動を繰り返し行う必要がある。なおかつ、単に繰り返したのではだめ。失敗を繰り返してもコンピテンシーは高まっていかない。

コンピテンシーはパターンであるので、その目標の設定によって行動の難易度が決まってくる。これがコンピテンシーの高い／低いという話になる。つまり、コンピテンシーの高い人は難しい目標に対して対応ができるが、低い人は易しい目標しか対応できない。スキルも同じような側面がある。

◆リスク管理力の例

一つ、例を考えてみよう。製品開発プロジェクトのプロジェクトマネジャーのリスク管理力というコンピテンシーを考えてみる。リスク管理力のコンピテンシーの高い／低いはおそらくリスク識別能力では決まらない。プロジェクトマネジメントのスキルがあれば、リスクはそれなりに想像がつく。システムのサポートを得ることもできるだろう。

リスク管理力のコンピテンシーが問われるのは、リスク事業が生起の発見である。たとえば、要員Ａの力量不足というリスクを想定していたとする。リスク管理力のコンピテンシーの低いプロジェクトマネジャーＸは、おそらく、Ａの仕事の進捗報告を見て初めてこのリスクの発生に気がつく。ところが、リスク管理力が高いプロジェクトマネジャーＹは、普段の会話を交わしている中で気づく。もっと高いＺはそれを確認するような行動をとるだろう（本人には分からない形で試している）。

この２つを較べると、プロジェクトマネジメントの結果に歴然とした差が生じることは明らかだ。

◆目標設定の例

そこで、低い人も高くなりたいと思うわけだが、上で述べたことは、いきなり、Ｚのような行動をとろうとしてもまず取れない。試していることを相手に見透かされて、モチベーションを下げるのがオチだ。そこで、まず、Ｙ、あるいはもう少し、低い目標を掲げる。目標の高さのポイントはその時点でも２回やれば１回はうまくできるだろうというレベル。

そして、実際にそのような行動をとるように心がけていく。容易な課題でも、成功すれば自信になる。５回やって５回成功する自信ができれば、目標を挙げていく。くれぐれもムリをしないことがポイントである。

うまく習慣化ができない人は、一般的に目標設定がまずい。難しすぎるので、何度やってもできない。そのうち、いやになって努力をやめてしまうというパターンが多い。ここをクリアすることが肝心である。

◆コンピテンシーの学習ステップ

前回は、思考習慣や行動習慣がスキルを成果に結びつけるキーになるということを説明した。では、自分が必要だと思う思考や行動を習慣化するにはどのようにすればよいだろうか？言い換えると、それらをコンピテンシーとして学習していくにはどうすればよいか？

コンピテンシーの学習には、いくつかのステップがある。その流れはおおよそ以下の５つのステップである。

１）コンピテンシーの理解
２）実経験での認識
３）ソリューションの構築
４）ケーススタディ
５）スキル実践

コンピテンシーの学習（あるいは習慣化）は自分の抱える問題の解決を目的として行われることが多い。たとえば、スコープクリープが起こることが多いことを自身のプロジェクトマネジメントの問題点として認識しているとすれば、それを改善することがコンピテンシーの開発動機になる。

◆コンピテンシーの理解

そこで、まず、必要となるのが、今から自分が開発しようとするコンピテンシーが、どのような状況で、どのような問題解決に役立つものであるかを理解する。上の例でいえば、「プロジェクトの目的を常に意識し、行動に反映する」というコンピテンシーが身につけば問題が解決できると予想される。このコンピテンシーはたとえば、

何か判断に迷う状況に直面したときに、目的を意識的に思い出し、その目的達成のための自分の責任を確認し、自分の責任を全うする行動をとる

のように理解できる。また、この際に、コンピテンシーを構成するコンピテンシーモジュールを理解する。

◆実経験での認識

次に、この理解を自分の経験に当てはめてみる。

＜状況＞
スケジュールが遅れ気味だか、現在までのコストがオーバーしている。要員を追加投入したいが、投入すると確実にオーバーする

＜行動＞
このプロジェクトの目標は商品売価に影響を与えないコストで、環境法制対応をすることであったのを思い出し、コストに影響を与えない遅延の解消方法として、１ヶ月納期を遅らせる

といった感じである。

◆ソリューションの構築

学習するというのはこのような行動を抽象的な行動パターン（ソリューション）に落とし込んでいくと同時に、そのパターンを確実に実行できるようにすることを意味している。たとえば、上のコンピテンシーであれば、

Ｓ１：プロジェクトの目的を再確認する
Ｓ２：目標を設定する
Ｓ３：行動を計画する
Ｓ４：行動する
Ｓ５：行動の目的への貢献を評価する

といったソリューションが考えられる。パターンを確実に実行できるようにするためには、このようなソリューションをツールに落とし込んで使っていくとよい。

◆ケーススタディ

次にそのツールを使って、過去に経験した問題に対して、ソリューション適用のケーススタディをしてみる。場合によっては、ソリューションの見直しを行う必要が生じる。

◆実践

実際にプロジェクトの中でソリューションを適用しながら、コンピテンシーを開発していく。

◆なぜ行動できないのか？

何がしかのトレーニングを受け、プロジェクトマネジャーとしてプロジェクトをマネジメントしたがうまくいかない。何がまずいかは説明できる。人に指示をすることもできる。ただ、実際に自分がやるとなるとうまくいかない。こんな人はいないだろうか？

【ケースストーリー１】
プロジェクトマネジャーのＫ氏は進捗ミーティングの中で、設計作業をしているメンバーＢが自分の担当スコープを明確に理解していないことに気がついた。それについて指摘したのだが、なかなか、真意が伝わらない。そこで、実際に設計に介入し、設計を変更した

Ｋ氏は、Ｂが理解できないのは、Ｂ氏の技術スキルの低さだと判断した。それゆえに、作業に介入していった。しかし、実際にはＢ氏はＫ氏の指摘は理解していたが、自分が正しいと確信して、それがうまく表現できないでいた。結果として、Ｂ氏はＫ氏の設計の意図を理解できず、後の工程で開発者への対応がトラブルの元になった。

【ケースストーリー２】
プロジェクトマネジャーのＫ氏は初期の計画を作った。最初のマイルストーンまでの詳細計画は作ったが、技術開発要素があったため、次のその後の計画は、技術開発のめどがついた時点で詳細化することに決めて、プロジェクト作業に入った。思ったより技術開発作業に苦戦し、２０日の計画のところ、３０日かかった。しかし、計画の見直しが億劫になり、次のシニアマネジャーのレビューまではほぼ１ヶ月あるので、初期計画を目標として、みんなで頑張って挽回しようとまとめ、そのまま進めた。コンティジェンシー計画では技術開発に予想以上の時間がかかった場合には、シニアマネジャーに報告し、協議をすることになっていた。

Ｋ氏は認識はよいと思ってこのように進めたわけではなかった。どういう結果になるかもおおよそ、想像できていた。後ろめたさを感じながらも、「プロジェクトが混乱するのは得策ではない」、「シニアマネジャーのＡさんに心配をかけると事が大事になる」などといったことを考えながら、このような行動をとっていた。

アタマで分かっていないことを変えるのは比較的簡単である。しかし、Ｋ氏は頭では分かっている。しかし、行動ができていない。このような状況を変えることはそんなにやさしいことではない。

ここで注目しておきたいことがある。もっているスキルや知識とそれらを使って行動をすることの距離感である。この距離感が大きくなればなるほど、行動する力を求められることになり、そのような仕事ほど、難しい仕事だと感じる。

◆スキルを行動に結びつける力とは

では、自分の持っているスキルを行動に結びつける力とはどんなものだろうか？これにはいろいろなケースがある。

【ケースストーリー１】は「コミュニケーション力」である。コミュニケーションの場合、どちらもどちらという側面はあるものの、もう少し、プロジェクトマネジャーのＫ氏のコミュニケーション能力が高ければＢ氏にきちんと理解させることができただろう。

【ケースストーリー２】は「意志の力」である。自分のとった行動の結果が分かっているので、もうこれ以上、アタマで理解すべきことはない。自分が本当によいと思う行動をする強い意志が必要である。

この連載でもっとも問題にしたいのは、この「意志の力」である。意志の力を身につけて、アタマで考えたことを行動に移すにはどうすればよいかを議論したい。そのキーワードは「行動習慣」、「思考習慣」である。

このメールマガジンの連動セミナーの狙いはこの習慣をつけることにある。

◆マネジメント行動とは

前回は準備号ということで、ＰＭコンピテンシーのイメージを述べた。今回はもう少し具体的に、プロジェクトマネジャーにはどのようなコンピテンシーが必要かということを考えてみる。その前に、「マネジメント行動とは具体的にはどのようなものか？」という質問があったので、補足。

プロジェクトマネジメント行動とはたとえば、

　・スコープを定義する
　・スケジュールを作る
　・母体組織とリソースの活用に関する交渉をする
　・チームをまとめるパーティをする
　・トラブルに対処する

といったものである。前回述べたように、ＰＭコンピテンシーとはプロジェクトマネジメント行動の中核となるものである。このような行動を「一定のレベルで行う」ために必要になるのがＰＭコンピテンシーである。

◆pmstyle　ＰＭコンピテンシー

pmstyleのＰＭコンピテンシーには

・アカウンタビリティ
目標達成のための自己の責任を明確に自覚し，結果に対して責任のある行動をとる

・自信
リスクの高い仕事に挑戦する，あるいは，権力のある人に立ち向かう

・リーダーシップ
メンバーを効果的にともに働くように導いたり，動機付けを行う

・アナロジー思考力
ある分野の現象を，まったく異なる分野の現象に置き換えて考える

・顧客志向性
顧客を大切にし，顧客の関心に最大の注意を払う

・顧客説得性
顧客にとっての真の利益を察知し，顧客の要望とのギャップを埋める行動をとる

・創造性
新たな発想で事実や技術の活用を考える

・戦略指向性
先々の展開を予想し，目標達成にむけて戦略性のある発想ができる

・リスク管理能力
リスクをきちんと認識し，そのリスクを踏まえた発想をする

・バランス感覚
複数のものごとのバランスを保ちながら，全体を進めていく

・実行力
目標の達成を阻害するさまざまな抵抗にひるまず，次々と新たな行動を起こす

・問題解決能力
目標達成を阻害する問題を迅速かつ，適切に処理する

・自己統制力
ストレスやプレッシャーの中でも自己を安定した状態に保つことができる

・徹底確認力
ものごとを体系的に捉え，曖昧さを排除し，詳細にまで注意を払いながら行動する

・現象観察力
起こっていることをきちんと観察し，それを多面的に比較し，検討することができる

・分析思考力
原因と結果の間の関係を突き止め，それに基づいて考えを展開していくことができる

といったものがある。

◆ＰＭコンピテンシーがある場合、ない場合

このようなコンピテンシーがある場合と、ない場合で、プロジェクトマネジメントの行動が変わってくる。一つの例をとると、アカウンタビリティというコンピテンシーが高い人がスコープ定義をするために、ＷＢＳを作成すると成果物重視のＷＢＳを書くが、アカウンタビリティの高くない人がＷＢＳを作成すると、プロセス重視のＷＢＳをつくり、成果物がこぼれてしまうといったことが起こる。

この関係は逆の関係もあることに注意をしてほしい。仮に、スコープ定義の方法としてその手順や、ＷＢＳという手法を知らない人がいれば、決してアカウンタビリティは高くならない。

つまり、ＰＭコンピテンシーをもつことと、手順を知っていること、手法を知っていることは相互に必要条件になっている。

では、このようなコンピテンシーを身につけるにはどうすればよいか？次回。

◆ＰＭコンピテンシー元年スタート！

この連載記事は、ＰＭコンピテンシーを開発しようという趣旨の連載記事です。好川は今年度をＰＭコンピテンシー開発元年と位置づけ、本格的にこの問題に取り組んでいくことにしています。

◆ＰＭコンピテンシーって本当に開発できるの？

ＰＭコンピテンシーの開発については、よく聞かれることが２つあります。一つは

　「ＰＭコンピテンシーって本当に開発できるの？」

という質問です。この質問については、ＰＭ養成マガジンの連載記事『プロジェクトマネジメントＯＳ原論』で解説しているところですので、詳しくはそちらをお読み戴くとして、結論だけを述べておきます。

　「開発できます」

『プロジェクトマネジメントＯＳ原論』

◆ＰＭコンピテンシーの開発とＰＭスキルの習得はどう違うの？

もう一つの質問は、

　「ＰＭコンピテンシーの開発とＰＭスキルの習得はどう違うの？」

という質問です。これについても、実は上に書いた『プロジェクトマネジメントＯＳ原論』でも別の言い方で触れているのですが、ここではストレートに説明しておきます。

「ＰＭコンピテンシーを開発する」とは、プロジェクトマネジメントを実践できるようになることを言います。実践力です。これに対して、ＰＭスキルの習得という場合には、プロジェクトマネジメントを行う能力を習得することを指しています。つまり、ゴールが違うのです。

ＰＭスキルの習得はある意味で潜在的能力の獲得であり、実際にできるかどうかはやってみなくてはわかりません。これに対して、ＰＭコンピテンシーを習得するというのは、実際に行うことです。

このように双方はゴールが大きく異なりますが、ゴールにたどり着くまでの道のりも大きく異なります。

ＰＭスキルは人から話を聞いたり、トレーニングを受けたりすることで身につけていくことができます。もちろん、座学で身につけたことを実践することによって学習が生まれ、それもＰＭスキルになっていきますので、実践も大切です。

ＰＭコンピテンシーは実践して初めて開発されます。逆に、実践できないとＰＭコンピテンシーが開発されたとは言えないわけです。

◆ＰＭコンピテンシー開発とメルマガ

さて、以上のように考えた場合、ＰＭコンピテンシーには２種類の要素があります。一つは、プロジェクトマネジメントを実践する際の考え方やものの見方、心得といったようなものです。もう一つはプロジェクトマネジメントのやり方そのものです。

この連載では、前者の開発目的で

　『ＰＭコンピテンシーを強化する行動習慣・思考習慣』

というテーマで隔週で記事を書いていきます。これは、pmstyle.com@munity会員版、メルマガ版の両方で配信します。

後者の開発目的では、

　『ＰＭコンピテンシーを強化するＰＭプラクティス』

というテーマの記事をやはり隔週で書いていきます。これについては、pmstyle.com@munity会員版でのみ配信します。メルマガだけを購読の方で、こちらをお読みになりたい方は、この機会にpmstyle.com@munity会員にご登録ください。もちろん、無料です。

pmstyle.com@munity会員登録

◆セミナー連動

また、この記事はセミナーと連動して運営していきます。前者の開発のセミナーとし
ては、

新・ＰＭコンピテンシー強化術（習慣編）～プロジェクトマネジメントを成功させる７つの習慣
http://www.pmstyle.biz/smn/compnew.htm

があります。また、後者の開発セミナーとしては

新・ＰＭコンピテンシー強化術（手法編）～プロジェクトマネジメントを成功させる７つのプラクティス
http://www.pmstyle.biz/smn/prac.htm

があります。

セミナーと記事は補完的な関係にあります。記事だけ、セミナーだけでもそれなりの効果がありますが、併せて使われることによってより効果的に活用できます。

１）記事を読んで戴き、セミナーで実践のきっかけをつかむ（スクーリング）
２）セミナーで実践に取り組み、記事で補強していく（セルフメンタリング）

など、お好みの方法でご活用いただければ幸いです。好川のお奨めは、セミナーで実践のきっかけと動機を得て、記事を読むことによってリマインドしていくという活用方法です。

読者の方には一人でも多く、セミナーにお越しいただければと思います。

では、次回から本題に入りますので、お楽しみに！

◆ＰＭＩの貢献はすばらしい！

ＰＭＢＯＫの勢いは衰えるところを知らない。十数年前に財政危機だったＰＭＩが世界戦略に出て、それが功を奏し、今は本当に飛ぶ鳥を落とす勢いである。すばらしいＶ字回復である。

ＰＭＩの運営の仕方についてはいろいろと批判もあるようだが、昨年末（２００５年１２月）で

　会員数　208,660人
　ＰＭＰ数　184,461人（日本人12,977人）

という数字は批判のしようがない数字である。そして何よりも、１１カ国語でＰＭＢＯＫという自らの標準を出版していることはすばらしい文化貢献である。

◆ＰＭＢＯＫは日本人のメンタリティにあうか？

ただ、ＰＭＢＯＫというのはよくも悪くも米国的である。

著者は１９９５年くらいからＰＭＢＯＫの導入支援を始めて、相当な数をこなしているが、導入の際に問題になるのは必ずといってよいくらい、アカウンタビリティとレスポンシビリティに対する考え方である。

ＰＭＩが定めるプロフェッショナル責任に

（１）個人の健全性（真摯さ）とプロフェッショナリズムの確立
（２）個人の能力（コンピタンス）の増進
（３）専門領域の知識集積への貢献
（４）利害関係者間の調整
（５）チームや利害関係者との協調関係

の５項目がある。（１）～（３）はよいのだが、（４）、（５）はそんなことを言われたくないというメンタリティを持っている国は結構多いのではないかと思う。たとえば、日本だと、こんなことをプロフェッショナル責任として表に引っ張り出されるとこそばゆい部分もあるし、逆にこれが責任だといわれると、抵抗があるという人も結構多い。必要性を否定しているわけではない。

もっといえば、責任だとか、権限だとかを明示的に扱っていくことへの違和感がある。

たとえば、ＰＭＢＯＫで推奨されている、ＲＡＭ（Responsibilty Assignment Matrix）というツールを導入する。チェックリストとしては便利だし、よく使う。Responsibleが誰かということになるとはっきりしないケースが多い。「責任」という言葉を使うと、みんなの責任であるということになるのだ。そこで、体制については責任にせずに、スコープ区分を応用して定義していく方が現実的だという話になる。

これは、日本企業の強みであるし、現場力の源泉でもある。そして、ＲＡＭを作らなくても、スコープ区分で仕事ができるというのは、「アメリカ人」のあこがれる「自律型チーム」であり、そこでは、プロジェクトマネジャーだけでなく、チームとして（４）や（５）の責任を果たしていると思われる。

したがって、（４）や（５）は、わざわざ言われたくないし、明示的に実行することは得意ではないということにもなる。

◆日本人は最強のネゴシエータ

これを日本的だと否定してしまうのは容易であるが、ここで、ジム・トーマスという弁護士・実業家でありながら、世界的著名なネゴシエータの交渉術の本で、日本人の交渉術について指摘されていることを紹介しておく。詳しくは僕のブログの記事

　面目と調和を保つ交渉
　https://mat.lekumo.biz/pm/2006/03/post_c789.html

を読んで欲しいのだが、とりあえず、結論は

　日本人の交渉術には非の打ちようがない！

と絶賛している。その背景にあるのが、（あえてこのような表現をするが）、日本流のアカウンタビリティとレスポンシビリティの扱い方であるのは間違いない。交渉がプロジェクトマネジメントのひとつの柱であるのを否定する人はいないだろう。

このような意見を持つ米国人もいる。米国流の方法がよいと簡単に日本を切り捨ててしまえるだろうか？答えを出す前に、では、他のプロジェクトマネジメント標準はどうなっているのか？

戦略ノートでは今回が９１回である。実はこの問題は最近感じている問題ではなく、戦略ノートを始めたときから持っていた問題である。これから１００回のカウントダウンに向かって、この問題を考えてみたい。

◆プロセスを考えるか、システムを考えるか？

この問題を考えるキーワードは、プロセスを考えるのか、システムを考えるのかである。

それだけをインプットしておき、まずは、いろいろな標準を分析してみたいと思っている。とりあえず、最初は、ＰＭＢＯＫでは十分ではないという人が、なぜか、一様に取り上げるＩＰＭＡ（International Project Management Association）のＩＣＢ（International Competency Baseline）を取り上げてみたい。次回をお楽しみに

◆プロジェクトマネジャーＫ氏

何回か、プロジェクトマネジメントＯＳ、つまり、ＰＭコンピテンシーは開発できるのか？この問題を考えてみたい。本論に入る前に、PM Magazineの連載に書いたのだが、あるプロジェクトマネジャーの話をしてみたい。

仮にＫ氏としておこう。Ｋ氏は印刷機器の商品開発のプロジェクトマネジャーである。
著者がＫ氏とであったのは、あるプロジェクトのコンサルティングしたときだ。Ｋ氏は１５年くらいＰＭの経験があり、過去にすばらしい業績を残しているらしい。社長表彰も何度か受けている。

新しい知識の習得にも積極的で、最近ではＰＭＢＯＫを独学で勉強して、自分の経験で説明できるというレベルまで理解していた。当然、組織からの信頼も厚く、今回、戦略商品のプロジェクトのＰＭに選ばれたのも信頼があればこそだった。

コンサルティングをすぐに、考え方は適切であることがわかり、その能力は見当がついた。おそらく、能力だけでいえば、著者が知っているプロジェクトマネジャーの中でもトップクラスだと思う。経験も、知見もある。

ところが、しばらく様子を見ているうちに、あることに気づいた。確かに、メンバーの動き方や、自分のとるべき行動まで、的を得たことを言うのだが、それに対して、メンバーの行動を支援する行動、あるいは自分自身がこうすべきだと言った行動を実際にしない。たとえば、リスクはチームの主要メンバーが集まってきちんと分析しようとキックオフミーティングで宣言したにもかかわらず、実際には自分だけでリスク分析シートを作ってそれをメンバーに「周知」して終わるといった対応をしていた。

リーダーにこっそりと話を聞いてみたところ、最近、ＰＭを担当したプロジェクトでも同じような傾向があり、メンバーからもそのように見られているとのこと。

あなたの回りにＫさんはいませんか？

◆スキルが向上したが、ＰＭコンピテンシーは向上していない

ＩＴ系を中心にして、ここ数年で、急速にプロジェクトマネジメント担当者のＰＭスキルというのは向上してきたように思う。ＰＭＢＯＫに関する理解も進んできたし、また、活用という点でも多くの人が活用している。しかし、一方で、ＰＭコンピテンシーはあまり向上していないように思える。

この連載でしつこいくらい言っているが、ＰＭコンピテンシーというのは能力を表しているわけではない。行動、実践を問うている。つまり、「～できる」かどうかではなく、「～しているかどうか」を表すのがＰＭコンピテンシーである。どちらが重要かというのは組織、プロジェクト、個人（キャリア）などいくつかの視点があるので、簡単には結論できないが、プロジェクトマネジメントの立場からは、能力では不十分である。行動しているかどうかが問題である。

ここで、曲者概念がある。それは、「実践力」なるものだ。これは非常に扱いが難しい。本来はプロジェクトマネジャーの評価は行動で行うべきものだが、実際にはプロジェクトマネジメント行動は機会がないとできない。たとえば、ＩＴスキル標準でよく問題になるように、ピーク時要員５０～１００名のＳＩプロジェクトをマネジメントしているといった場合に、じゃあ、そんな規模のプロジェクトがない企業のプロジェクトマネジャーはどのように評価するのかという問題になる。そこで、実践についてもポテンシャルを表現する概念がほしくなり、それが実践力となる。

ちょっと脱線したが、実践力ではなく、実践でＰＭコンピテンシーを捉えるとすると、上のＫ氏はかつてはＰＭコンピテンシーがあったが、現在はＰＭコンピテンシーがないということになる。後日談であるが、彼がそのようになっていったのは、実はキャリア的な問題があったためのようだ。ということは、もし、一念発起してがんばると、きっと彼は適切なマネジメント行動をとるようになるだろう。つまり、ＰＭコンピテンシーを持っていることになる。

ＰＭの世界では、ＰＭコンピテンシーはスキルに近い捉え方をされることが多いが、ＨＲＭの世界では、キャリアとか、目標管理との関連性が必ず出てきている。Ｋ氏の事例を見ていると、やはり、ＰＭの世界でもスキルだけでコンピテンシーを捉えるだけでは不十分ではないかと思う。このあたりに、開発可能かどうかという議論の根底があるように思える。

◆はじめに

久々のプロジェクトマネジメントＯＳ原論である。このシリーズではＰＭコンピテンシーを向上させ、プロジェクトを成功させる７つの習慣を取り上げ、その強化策について議論してきた。また、昨年度は５回にわたり、習慣化のセミナーを行ってきた。
また、多くの企業で実践して戴いた。

これらの活動のフィードバックを得て、７つの習慣をバージョンアップした。経験が加味されて、持論がリファインされたという感じである。ＯＳ原論で、ご披露をしようと思っているのだが、ある方とお話をさせて戴いている中で、面白いことを指摘されて、今回はちょっと回り道というか、脱線をするが、

　　プロジェクトを失敗に陥れるプロジェクトマネジャーの７つの「悪習慣」

というのを書いてみる。

この中には、組織の論理を否定しているものもある。しかし、そこで否定されている組織の論理は、組織がプロジェクトをやるということにとってはマイナスになるものである。『ＰＭＯマガジン』で議論をしていく予定だが、組織マネジメントと整合するプロジェクトマネジメントなどありえないと思っている。目的と結果が違うからだ。

組織マネジメントにとって成果は結果に過ぎない。しかし、プロジェクトマネジメントにとって成果は目的である。まあ、そんなことも念頭に置きながら読んで戴けると幸いである。

◆プロジェクトマネジメントを失敗させる７つの「悪習慣」

１’プロジェクトの目的を考えない
プロジェクトの目的が何かを考えず、顧客の言うとおり、上司の言うとおり、計画通りにやるやろうと腐心する。そして、その結果、何か問題が起こった場合には、他人のせいにして、自分は責任をとろうとしない

２’常に受身で行動する
求められるまで報告はしない、求められるまで提案はしない、メンバーから頼まれるまでは動かないなど、常に相手からのアクションがあるまでは自分からは行動しない。

３’ステークホルダとの間で常に勝ち負けを考える
交渉や、トラブル対応の場面では、常に自分が相手より有利な成果を得ることが出来ることを重視し、常に、勝った、負けたを考える。その結果、自らのプロジェクトはスムーズに進み、相手が不本意な状況に陥っても気にしない。

４’チームを使い捨てる
チームはプロジェクト実行のための手段だと割り切り、チームやチームメンバーとはそのプロジェクトが終わるまでの付き合いだと考え、メンバーの成長や、チームの団結などには無関心で、メンバーの持っている能力を使うことだけに関心を示す

５’リスクから逃げ回る
自分の失敗につながる可能性のある意思決定は、確実にうまくいく答えが見つかるまで先送りする。その結果、プロジェクトのスケジュールが遅れても、突っ込んでいたらもっとひどいことになっていたかもしれない、仕方がないと考える。

６’ステークホルダと形式的なコミュニケーションを重視する
顧客にはちゃんと言ったはずだ、上司にちゃんと報告しているという風に、情報伝達をしたという事実にのみ関心をもち、自分の伝えたいことを相手がどのように理解したかには関心を持たない。また、相手から聞いたことに対しても、相手が何を言っているかよりは、自分がどのように解釈しているかを重視する。

７’自分たちの考える品質が達成できれば満足する
お客が欲しいと思うものより、その道のプロフェッショナルである自分たちが価値があると思うものの方が重要だと考え、顧客の意見に耳を貸そうとせず、自分たちの考えを顧客に押し付けようとする。

◆よい習慣を身につけ、悪習慣を追放しよう！

さて、そのような悪習慣に陥らないためにはどうすればよいか？よい習慣を身につけることである。

【プロジェクトマネジメントを成功させる７つの習慣】
・プロジェクトの目的を常に意識する
・ステークホルダとのＷｉｎ－Ｗｉｎを考える
・チームを成長させる
・リスクをコントロールする
・ステークホルダと共通認識を形成する
・主体的に行動する
・顧客視点で品質を考える

お気づきの方もいらっしゃるかと思うが、冒頭に述べたように、ここに示した７つの習慣２００６は、７つの習慣２００５から進化している。

◆セミナーもリニュアル

これに併せてセミナーもリニュアルしました。今まで半日（５時間）であったセミナーを、受講者の声を参考に、２日間のセミナーに拡張しました。習慣化のきっかけ作りも、単にワークショップだけではなく、ケーススタディ、ロールプレイと多様化してします。まだ、ＰＭコンピテンシー強化術を受講していらっしゃらない方は、ぜひ、受講してみてください！また、旧・ＰＭコンピテンシー強化術を受講された方で、物足りなさを感じた方にも自信を持ってお奨めします。

新・ＰＭコンピテンシー強化術（習慣編）
　　　～プロジェクトマネジメントを成功させる７つの習慣

　http://www.pmstyle.biz/smn/compnew.htm

◆プロジェクトマネジャーの責任

今回はもう少し、プロジェクトを手の内に入れることについて本質的な話をしてみたい。それは、そもそも、プロジェクトをコントロールするとはどういうことなのか、プロジェクトをコントロールするためには何が必要なのかという点だ。

著者は「プロジェクトを成功させるリーダーのスキルとマインドを知る」という定番セミナーの中でプロジェクトマネジャーの責任を

１．計画への落とし込みと共有をする責任
２．計画実行を動機付ける責任
３．計画実行状況を管理する責任
４．状況を説明する責任
５．予想外の状況で判断をする責任

の５つだと定義しているが、この中でより本質的な責任は３．と４．だと考えている。
他のものは、この２つの責任を全うするためにあるといってよい。

◆プロジェクトをコントロールする目的

プロジェクトをコントロールする目的というのはいろいろな見方があるかもしれないが、突き詰めれば

　常にプロジェクトの状況を説明でき、状況に応じた適切な判断をし、プロジェクトの目標を達成すること

である。プロジェクトマネジメントを導入した企業は後半のプロジェクトの目標を達成することには関心が高くなるが、成果責任を果たすというのは実はそちらではない。
前半の部分である。なぜか？

プロジェクトにはステークホルダがいるからだ。例えば、無人島で自分の住む家を建てるのであれば、話は別だ。とにかく家が建てば文句はない。しかし、ビジネスの多くのプロジェクトではそのプロジェクトに関連するビジネス要素はたくさんある。例えば、商品開発であれば、できた商品の広告や売込みをしなくてはならないし、流通の整備もしなくてはならない。ＩＴのプロジェクトであれば、作ったシステムを業務に使うユーザがいる。

このような中で、とにかく、商品やシステムを開発できたというだけでは不十分である。それでも約束した納期内であればともかく、納期を遅れてしまえば全くもって不十分である。

納期に遅れること自体が問題なわけではない（もちろん、遅れないに越したことはないのだが）。プロジェクトをコントロールしているとは、常にプロジェクトに対する見通し、つまり、今どういう状況にあり、ゴール達成が予定通りできそうかどうか、できないとすれば、いつ達成できるのかといったことである。これが計画をベースにして行われなくてはならない。

◆根拠と仮説が重要

そして、常に計画通りに行うためにはどうすればよいかという判断ができ、資源を投入したり、そのほかもろもろのマネジメントが「根拠」を以ってできなくてはならない。これがコントロールである。

この際に注意しなくてはならないことは、この根拠はプロジェクトの不確実性の中で決定されるので、正しいかどうか分からない。論理的であることは求められるが、正しいことは求められない。その根拠に基づいてやってみないと分からない部分が多々あるからだ。いわゆる仮説である。

多くのプロジェクトマネジャーが陥っている問題は、「やってみないと分からない」という部分だけが一人歩きをしていることである。繰り返しになるが、それではステークホルダとのコミュニケーションができない。

例えば、ＩＴ系のプロジェクトによくあるが、リソース能力にばらつきがあるので、正確な議論ができないという指摘がある。この問題は難しい部分がある。本当にばらつきが大きい場合には、スケジューリングの基礎をなす手法であるＰＥＲＴ／ＣＰＭが統計的な手法なので、そもそも手法の適用ができないという問題が生じる。ただ、統計的に取り扱いが可能な範囲のばらつきであれば、仮説を作ってきちんとコントロールしながら進めていくべきである。

◆別の視点

以上は、計画をベースにコントロールをするという議論であるが、実はコントロールの方法にはこれ以外のものもある。一つは遅れである。遅れの部分にだけ注目してコントロールをしていくような手法がある。これがＣＣＰＭ（クリティカルチェーンプロジェクトマネジメント）である。もう一つは、「モノ（成果物）」に注目してコントロールをしていく方法がある。これがＡＰＭ（アジャイルプロジェクトマネジメント）などの手法である。２月２７日に行うセミナーはこのような議論になると思う。

　「売れる製品を作るプロジェクトマネジメント」
　　日時：２月２７日１３：２０－１７：５０
　　詳細・お申込　http://www.pmstyle.biz/smn/20060227.htm