プロジェクトの「補助線」

【補助線】プロジェクトマネジャーの成熟度モデル

本ブログは移転しました。こちらをご覧ください。

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

 

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

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

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

【補助線】おとなのマネジメント

本ブログは移転しました。こちらをご覧ください。

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

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

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

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

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

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

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

【補助線】ダイバーシティについて考える

本ブログは移転しました。こちらをご覧ください。

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

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

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

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

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

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

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

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

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

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

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

これは別の機会に。

【補助線】「メタ」計画

本ブログは移転しました。こちらをご覧ください。

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

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

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

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

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

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

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

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

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

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

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

【補助線】プロジェクトマネジメント計画とプロジェクト計画

本ブログは移転しました。こちらをご覧ください。

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

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

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

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

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

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

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

【補助線】続・プロジェクトマネジメントはサイエンスかアートか

本ブログは移転しました。こちらをご覧ください。

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

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

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

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

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

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

逆に、

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

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

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

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

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

【補助線】プロジェクトマネジメントはサイエンスか、アートか

本ブログは移転しました。こちらをご覧ください。

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

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

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

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

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

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

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

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

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

アートが必要である。

続・ＰＭＯリーダーがＰＭを変える

本ブログは移転しました。こちらをご覧ください。

◆３０％以上の赤字の責任は組織の責任

ＳＩ企業のマネジャーと話をしていると彼らが口を揃えていうことに、

「プロジェクトマネジメントが定着してきて、小規模なプロジェクトの納期遅れ、予算超過のプロジェクトの割合は劇的に減った。しかし、それらの努力をすべて帳消しにするような大規模プロジェクトの赤字は依然としてなくならない。どうしたものだろう」

という実情がある。もちろん、彼らも手をこまねいているわけではない。原因を分析してみれば、このような大きな赤字プロジェクトもリスクが発見されていなかったとか、まあ、プロジェクトマネジメント導入前に小さな失敗をしていたプロジェクトと同じような原因が並ぶのだ。そこで、なぜ、成功したり、失敗したりするのかという疑問になる。

これはもはや狭い意味でのプロジェクトマネジメントの問題ではない。

◆大きな失敗がなくらならい３つの理由

この問題の大きな理由は３つくらいある。

一番目の理由は、プロジェクトの建て直しの仕方である。プロジェクトマネジメントの基本的な考え方は是正である。つまり、プロジェクトの実績状況が悪くなってきたときに、計画（ベースライン）を変えなくて済むようにアクティビティを変更していく。一言でいえば、問題解決である。

ところが、この種の問題解決はうまく行かないことがある。ベースラインを変えないというのがこの問題解決の制約条件であるが、その制約条件がクリアできる範囲に答えがないことがあるのだ。その場合、制約条件そのものを外してやる必要がある。ゼロベースで如何にしてプロジェクトの目的を達成するかを検討しなおし、目標（計画）設定をしなおす必要がある。

問題は、この判断だ。この判断は体系的に行う必要がある。スケジュールとコスト、品質といった指標だけを見て判断をするのは危険である。プロジェクトマネジャーの状態、チームの雰囲気、メンバーの様子、コミュニケーションの状態、ステークホルダの態度（信用状況）、といったものも見て総合的に判断をしなくてはならない。これは、リカバリーマネジメントでは「リカバリーデシジョンパッケージ」と呼ばれる。

よくある失敗は、例えばスケジュールが３０％くらい遅れているときに、チームやステークホルダの状況を見ないで、計算上だけでリカバリーをしてしまうことだ。これが大きな失敗を引き起こす。

この仕組みづくりはＰＭＯの重要な役割である。

二番目の理由はプロジェクトガバナンスの混乱である。ここで、もっとも問題になるのがプロジェクトスポンサーである。プロジェクトスポンサーは、片足プロジェクトチームに足を突っ込んでおり、片足はプロジェクトチームの外にいるステークホルダの役割を果たすプロジェクトガバナンスの安定のために極めて重要な役割である。例えば、プロジェクトマネジャーの任命責任を持つラインマネジャーのような立場の人だ。

ところがトラブルが起こってしまうと、プロジェクトスポンサーが（何とかしようと）混乱して、自らがプロジェクトのガバナンスを不安定にしてしまう。例えば、プロジェクトマネジャーの頭越しにメンバーに対して指示をするとか、顧客と折衝するなどだ。

さらに、悪いことに、プロジェクト全体の司令塔がいなくなることが多い。プロジェクトマネジャーは現実的な顧客やメンバー対応に追われ、スポンサーもガバナンスを持っているという意識はない。結果として、ガバナンス不在のような状態になる。

このようなケースでは、ガバナンスの所在を明確にし、それを適切な人に移行していく。このガバナンスマネジメントはＰＭＯの重要な役割の一つである。

３つ目がエグゼクティブスポンサー（例えば、事業部長）の戦略的判断のミスである。仮に、一つのプロジェクトが組織の年間の利益を吹っ飛ばしてしまうのだとすれば、集中すべきプロジェクトは明確だ。極論すれば、小規模プロジェクトで赤字を出してもいいので、大規模プロジェクトに集中する必要がある。ＳＩなどでいえば、小規模なプロジェクトは少なくとも日本のトップＳＩ企業が受注すべきではない。組織論的に言って、５千万円のプロジェクトを５億円のプロジェクトを同一組織でやることには無理がある。これはリスクマネジメントを考えてみると良く分かる。このようなアンバランスがあると、組織として持つ複数プロジェクトのリスク評価ができなくなる。

このような芸当をやってのけるには、プロジェクトのカテゴライズとカテゴリーごとのマネジメントスキームの確立が不可欠である。この仕事もはやり、ＰＭＯの仕事である。

◆ＰＭＯの果たすべき役割は大きい

このように冒頭の問題に対して、ＰＭＯの果たすべき役割は多い。ここで注目したいことは、これらの仕事は支援の仕事には違いないが、受動的な支援、つまり、依頼されて支援するような類のものではない。むしろ、プロジェクトマネジャーと立場は異なるものの、組織としてのプロジェクトマネジメントの先頭に立って、全体を動かしていくような仕事である。

今回は、トラブルのケースを考えてみたが、ＰＭＯがプロアクティブに動くことによってプロジェクトマネジメントがスムーズにいく部分が多い。これこそ、ＰＭＯリーダーの仕事である。

続々・ＰＭＯリーダーがＰＭを変える

本ブログは移転しました。こちらをご覧ください。

◆ＰＭＯの３つの活動

一般論だが、プロジェクトマネジメントオフィスの活動は３種類あると考えてよい。

一つは、プロジェクトマネジメントの仕組みづくりと仕組みの改善である。この中には、プロジェクトマネジャーの育成やアセスメントが含まれる。

二つ目は、監査機能である。基本的な目的は、設定した仕組みに従ってプロジェクトマネジメントが実施されているかどうかを検査し、行われていない場合には是正をしていくことである。

三つ目はプロジェクトで実施されるプロジェクトマネジメントの直接的な支援である。これ事態もいくつかの分類をすることが可能だが、大きくは二つに分けることができる。一つは、オペレーションの支援である。もう一つは、ビジネス的支援である。前者では、プロジェクトマネジメント計画を策定する支援、トラブルの発生したプロジェクトのマネジメント支援などがある。後者にはポートフォリオマネジメントなどが代表的である。

◆ＰＭＯの３つのタイプ

この３種類の活動は、一般的な企業では異なるＰＭＯ組織で実現されることが多い。

仕組みづくりはだいたい、「全社ＰＭＯ」で行われる。これに対して、品質監査やプロジェクト監査など、間接的に個別のプロジェクトマネジメントに関わっていく場合には全社のＰＭＯがそれをカバーすることは難しく、事業部くらいのスパンでＰＭＯを設置して、対応していくことが一般的である。この場合、このＰＭＯは全社のＰＭＯが策定した全社共通の仕組みを使ってプロジェクトマネジメントが行われていることを前提とした取り組みを行う。プロジェクトの規模があまり大きくない場合には、このタイプのＰＭＯが個別プロジェクトのマネジメントオペレーションの支援を行うことがある。しかし、プロジェクトの規模が大きくなると、実質的に専従にならざるを得ないため、第３の形態としてプロジェクトの中にＰＭＯをおくという形態をとることがある。ＰＭＢＯＫ的にいえば、プロジェクトマネジメントチームである。ＳＩ業界などではこの形は比較的一般的な形である（このタイプのＰＭＯをプロジェクト内ＰＭＯと呼ぶ）。

第３の形態の場合、プロジェクトの規模によっては、１プロジェクトをいくつかのプロジェクトに分けてプログラムとして運営していく場合と、一つのプロジェクトして運営していく場合の２つのケースが考えられる。前者の場合だと、ＰＭＯの主要は役割はプログラムマネジメントそのものになる。後者の場合であれば、プロジェクトマネジメントの支援になり、大きく性格が異なってくる。この点も注意が必要だ。

◆ＰＭＯのポジショニング

今、プロジェクト内ＰＭＯがプロジェクトマネジメント成功の最終兵器といわれるようになっている。どういうポジショニングをすればプロジェクトマネジメントの成功に直結するのだろうか？

この問題を考えるに当たって、非営利団体のマネジメントが参考になる。

一般的な組織を持つ非営利団体のマネジメントでは、２つの重要な役職がある。専務理事と事務局長である。専務理事が経営的意思決定を行い、理事長の承認を得る。意思決定されたことを実施するのは事務局で、その組織の長が事務局長である。つまり、実質的にマネジメントを実行するのは事務局長である。

従って、非営利団体のマネジメントは事務局長のマネジメント実行能力によってずいぶん変わってくる。経営状況のよい非営利団体は、その活動内容の筋のよさもさることながら、必ずといってよいくらい、優れた事務局長がいるものだ。

◆ＰＭＯリーダーは事務局長

一つの非営利団体を大規模プロジェクトとしてみれば、専務理事はプロジェクトマネジャーである。事務局がプロジェクトマネジメントチームである。そして、事務局長の役割を果たすのは、ＰＭＯリーダーである。

つまり、ＰＭＯリーダーがプロジェクト内ＰＭＯをうまく牽引することによって、プロジェクトマネジメントがうまく行くという構図が出来上がる。そのような構図を作っていく必要があろう。

ＰＭＯの現場力

本ブログは移転しました。こちらをご覧ください。

現場力というのがなんとなくキーワードになってきている。

現場力というのを、経験と混同している人によく会う。これは曲者だ。例えば、ＰＭＯのメンバーとして仕事をするのに、ＰＭの経験が不可欠だと考える人が多い。プロジェクトマネジャーの考えを理解する必要があるといった理由だ。

しかし、ＰＭＯの現場力というのは少し、違う。現場力というのは現場を見て、ものごとを判断する力である。上に曲者だと書いたのは、経験をすると、自分の経験で現場で起こっていることを無視して判断する危険があることだ。これは大いに気をつける必要がある。

確かに、自分が経験したことが、今、現場でも起こっている可能性はある。しかし、やっぱり違うことの方が多い。お客さんが違えば、きっと違う。ミッションが違えば、やっぱり違うだろう。経験に頼って現場の判断をするというのはかくも危険なことである。

ある意味で、昔取った杵柄で、強硬な意見をいう役員とか、ＰＭＯがそんな役回りになる危険もある。そうなったら、プロジェクトの足を引っ張るだけだ。

自分にどんな経験があろうと、謙虚に現場を見る。その上で、自分の経験を使って判断する。そういう力が現場力だ。

ここで、経験で「こんなことが起こっているだろう」と推測するのであれば、経験などないほうがましだ。