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

◆標準とは何か

前回は、プロジェクトマネジメントの標準は現場のプラクティスを吸い上げていき、構築していくべきだという話をした。

このノートでは、標準については第１７回から６回にわたって、「戦略的ＰＭＯの標準化への取り組み」と題して議論している。まずは、こちらを改めて読み直してみてほしい。

第１７回　戦略的ＰＭＯの標準化への取り組み（１）
http://pmos.jp/pmstyle/pmcoe/pmcoe17.html

さて、今回は、この記事も踏まえつつ、標準とは何かということを改めて考えてみたい。

上記の記事でも定義したが、標準とは

　メソドロジー（方法論）の適正な適用を保証するためのルール

である。表現形式は様々である。これについても上の記事を参考にしてほしい。

◆「適正な適用」とは？

ここで考えたいのはこれはどういう意味かということだ。もっと的を絞っていえば、「適正な適用」とは何を指しているのかということだ。

みなさんの組織でスコープ定義をするときに、ＷＢＳを作り、中間成果物に対するマイルストーンを設定する、いわゆるマイルストーン管理をすることを「標準」として定めている組織は多いだろう。これは標準といえるだろうか？

実際に、マイルストーン管理をしようとすると、プロジェクトマネジメントの初心者がよく悩むように、ＷＢＳでワークパッケージの規模はどのくらいにすればいいのか、あるいは、マイルストーンはどのくらいのスパン（あるいは数）を設定すればよいのかという問題が出てくる。

ここで勘違いしてはならないのは、ＷＢＳとか、マイルストーン管理というのは、メソドロジーである。標準とは、これらが適正に適用されるためのルールである。そう考えると、たとえば、上のような問題（ワークパッケージの規模とか、マイルストーンのスパン）の決め方を明示しない限り、メソドロジーが適正に適用されるのは難しいかもしれない。すると、それらのルールが標準だということになる。

◆コンピテンシーを標準化するという考え方

あるいは、発想を変えると、これも、以前の記事で述べたが、「コンピテンシー」を標準化するという考え方もある。プロジェクトマネジメントもマネジメントであるので、適正といってみたところで、一律に決めれるものではないという考え方は当然ある。

すると、メソドロジーを適正に適用するために一律に決めることができるものは何かと考えたときに、プロジェクトマネジャーの能力であり、また、その能力を使った行動であると考えるのだ。実は、マネジメントの中ではこちらの発想の方がマジョリティである。

プロジェクトマネジメントであれば、ＰＭコンピテンシーを入れるものがこれに該当する。同じようなＰＭコンピテンシーをもった人が２人いたとしよう。その２人がＷＢＳを作ったときに、結果として、ＷＢＳのワークパッケージのサイズは違うかもしれない。これはこれで、同等なＰＭコンピテンシーを持つプロジェクトマネジャーのマネジメント行動なので、両方とも適正な適用をしていると考えましょうという考え方である。

◆何のために標準化するかの

ちょっと、違和感を感じる方もいるかもしれない。実は、ここでもう一つ考えるべきことがある。それは、何のために標準化するのかという問題である。

この問題については次回に議論するので、ぜひ、みなさんの方でも考えてみてほしい。

前回、ＰＭＯはプロジェクトに対してサーバントリーダーシップを発揮すべきだということを書いたところ、プロジェクト（マネジャー）の召使になれというならまだわかるが、理由が分からいし、イメージが持ちにくいという意見を頂いた。また、別の方からはそれはリーダーシップというよりもプロパガンダではないかという意見も頂いた。さらに、別の方からは、そんなユルイことを言っていないで、強権的なリーダーシップを持つべきではないかという意見を頂いた。まあ、記事としてそれなりに響いたということだろう。

プロパガンダという話はある程度、当たっている部分もあるのだが、本質的には違うと思うので、今回、もう一度、この問題を考えてみたい。

◆サーバントリーダーシップが必要な背景（１）

まず、この話の背景はどこにあるのだろうか？この点から考えてみたい。

この話の背景は２つあると思っている。ひとつは今年の５月７日のコラムに書いた話であるが、ＰＭＯはその組織のプロジェクトマネジメントのオーナーシップを持つということだ。つまり、プロジェクトをどのように行うかということは事業組織の戦略の問題だとしても、そのプロジェクトのマネジメントをどのように行うべきであるかについては、ＰＭＯは決めるべき立場にいる。

実は、５月７日の記事についても、その後、お会いした人と議論したり、メールでご意見を戴いたりしたが、プロジェクトマネジメントのオーナーシップを持つことと、プロジェクトのオーナーシップを持つことは違う次元の話であることを混乱している人が多い。

プロジェクトのオーナーシップを持つことは、プロジェクトの作業をどのように進めるか、顧客にどのようなスタンスで対応するかといったようなことであり、成果物を生み出すことについて、責任と権限を持つということである。これに対して、プロジェクトマネジメントについてオーナーシップを持つというのは、プロジェクトが責任と権限が果たせるようにするために行う管理（マネジメント）に対して責任と権限を持つということである。これは全く異なるものである。

◆サーバントリーダーシップが必要な背景（２）

もう一つの背景は、プロジェクトマネジメントの導入はマネジメントの変革であるということだ。変革であるので、基本的にはＰＭＯがああしろ、こうしろと言える類の問題ではなく、どうすればよいかを当事者が一番よく知っている。知らないのであれば、考えるべき問題である。

ＰＭＯがオーナーシップを持ち、強権的にプロジェクトマネジメントのやり方を決めていくというのであればわかりやすいのだが、ＰＭＯとしては

・オーナーシップを持つ
・現場（プロジェクトマネジャー）の意見を重視する

という二律背反を実現しなくてはならない。そこで、ポイントになるのが、「変革」であるということだ。

セミナー「ＰＭＯによるプロジェクトマネジメントの定着化のポイントと事例」
http://www.pmstyle.biz/smn/pmo_startup.htm

でも基本コンセプトしているが、プロジェクトマネジメントの定着化は変革マネジメントである。したがって、ＰＭＯが細かなやり方を指示していくことは適切とはいえばい。むしろ、ＰＭＯはプロジェクトマネジメントの方向性、方針、取組のスタンス、導入後のビジョンなどを明確に示し、その範囲で各プロジェクトでプロジェクトマネジャーが工夫したやり方を考える。ＰＭＯはプロジェクトマネジャーが実際にそれを実行できるように支援をしていく。そして、うまくいったやり方（プラクティス）を組織に吸い上げていき、調整をしながら、最高のやり方（ベストプラクティス）を作り上げていくことが望まれる。

◆ＰＭＯがすべき支援はサーバントリーダーシップを以て可能となる

ただし、プロジェクトマネジャーに一から考えよというのは現実的とはいえない。そこで、プロジェクトマネジャーが「ＰＭＯが示したビジョンに対して、マネジメントのやり方を工夫することを支援する」という位置づけで、標準を提供していくことはある意味で不可欠である。

すると、その場合の標準は守らなくてはならないルールという位置づけではなくなる。むしろ、たたき台であり、また、プロジェクトマネジャーたちのこういう風にやっていこうという考えを集約したものになるのだ。その意味で、自己決定であり、プロジェクトマネジメントの導入はスムーズに進んでいくだろう。

このように、決して表にでるわけではなく、といって、裏方だからといって意思決定を逃げるわけでもない。このようなやり方をサーバントリーダーシップという。少しは理解が進んできただろうか？

さて、こういう話をすると違和感がある人がいると思う。そう、組織としてはそんなつもりでプロジェクトマネジメントを入れているわけではない、組織として管理したいのでプロジェクトマネジメントを入れているんだ。プロジェクトマネジャーがレポートをしないというルールをきめたらどうするんだという意見が聞こえてきそうである。

◆リスクマインド

リスクマネジメントの環境整備が進んでいる。たとえば、ＩＴ系だと日本プロジェクトマネジメント協会（ＰＭＡＪ）が標準的なリスクマネジメントマニュアルの頒布をはじめているし、企業独自でリスクチェックリストを準備している企業も増えている。ＰＭＯのメインの役割がリスクのチェックだという企業も少なくない。

さて、そんな中で考えておきたいことがある。それは、リスクマネジメントというのは統制では実現できにくということだ。統制というのは確定的なことがらに対して威力を発揮するものである。

◆リスクマインドがあって初めてリスクマネジメントが活きる

一例としてこんなことを考えてみよう

（１）スケジュールが遅れそうであれば、できるだけ早く申し出てくれ
（２）スケジュール遅れが、各アクティビティに対してベースラインの１０％を超えたら、その日のうちに報告してくれ

いずれも、プロジェクトマネジャーがメンバーに対して出す指示としてはありそうな話だ。ところが、（２）は実効的であり、統制しているといえるのに対して、（１）はほとんど実効力がなく、統制しているとは言い難い。聞き流して終わりだろう。リスクマネジメントというのは本来は（１）のようなことをやりたいのだ。

もし、メンバーがこのスケジュールが遅れたら、仲間に迷惑をかけるとか、顧客に迷惑をかけるといった「危機感」を持っていたとしたらどうだろうか？まずいことが起こったらちょっとでも早く相談しようと考えるだろう（もっともプロジェクトマネジャーの対応の仕方にもよるが）。

これがリスクマインドである。メンバーやステークホルダがリスクマインドを持っていなければ、リスクマネジメントは機能しない。

◆リスクマインドの診断

さて、では、あなたのプロジェクトリスクマインドの診断をしてみよう。

プロジェクトマネジャーの方は今、あなたがプロジェクトマネジメントを担当しているプロジェクトを思い浮かべて欲しい。ＰＭＯの方は、あなたの組織の代表的なプロジェクトを思い浮かべてみて欲しい。

そして、「あなたのプロジェクトにどのくらい当てはまるか？」について、以下の点数をつけていただきたい。

まったく当てはまらない　１点
しばしばあてはまる　２点
かなりあてはまる　３点

（１）計画を無視して作業をすることはまずない
（２）直面する状況、課題はこのプロジェクトでも他のプロジェクトでも起こっているものだ
（３）作業に必要な情報の全てはメンバーの手に入りにくい
（４）プロジェクトマネジャーやメンバーは業務遂行にあたり、特定の方法の遵守を求められる
（５）納期、予算、収益において厳しい計画が課せられる
（６）メンバーは計画の達成のためにしばしば近道となる案を採ろうとする
（７）プロジェクトにミスの報告を躊躇させる雰囲気がある
（８）リスク事象が発生した際に、メンバーに対策を実行する権限を与えられていない
（９）リスク事象に対処するのに必要なスキルや専門知識に欠けるメンバーが多い
（１０）問題の討議の中で、議論の前提に疑問を投げかける発言がメンバーからでくることはほどんどない
（１１）ミスをすると責められる
（１２）他のメンバーに助けを求めにくい雰囲気がある

１２の質問の合計点数はいくらになっただろうか？

［１］１３点以下の場合
あなたのプロジェクトは高いリスクマインドがある。リスク計画を十分に立てれば、リスクをうまくコントロールすることができる

［２］１４～２３点の場合
あなたのプロジェクトはリスクマインドが十分とはいえず、リスク計画を作っていても、リスク事象の発生により、致命的なダメージを負う可能性がある。リスクトラッキングをしつこく実行する必要がある

［３］２４点以上の場合
リスク計画を作ってもあまり効果がない。リスクマネジメント以前に、リスクマインドの向上策をとるべき。

◆ＰＭＯリーダーの定義

PMstyleでは、数年前から「ＰＭＯリーダー」という言葉を使っている。ご承知のように、昨年からはＰＭＯリーダー養成講座という連続講座を始めた。ＰＭＯブームと相俟って、多くの方に受講して頂いているが、以前として、ＰＭＯは本当にリーダーシップを持つ必要があるのかという質問をいまだに受ける。

プロジェクトマネジメントの導入、実施、成熟という一連のミッションに対してリーダーシップを発揮するのがＰＭＯリーダー

というのが答えなのだが、なかなか、理解していただけない。

◆ＰＭＯリーダーのリーダーシップ

プロジェクトマネジャー、あるいは組織とＰＭＯの関係からすると、ＰＭＯが決めたようにプロジェクトマネジメントを行うことを命令することはもちろん、ＰＭＯがプロジェクトの中に入って率先してプロジェクトマネジメントをする、あるいはするように仕向けて行くことは、ＰＭＯとしての本務の範囲を逸脱していると考えている人が多いからだ。

実は、このようなリーダーシップをＰＭＯに求めているわけではない。ＰＭＯリーダーが発揮すべきリーダーシップはリーダーシップである。サーバントリーダーシップはリーダーとしてフォロワーに奉仕することを基本とするリーダーシップである。ただし、サーバントになるわけではない。

◆ＰＭＯの仕事はプロジェクトに奉仕すること？！

仕事がら、ＰＭＯの人との付き合いは多いが、ＰＭＯがプロジェクトに奉仕すべきだという人は多い（支援という言い方をする人が多い）。しかし、奉仕といった場合に、微妙な、しかし、決定的な温度差がある。プロジェクトマネジャーやプロジェクトが困っていればとりあえず支援しなくてはならないと思っているＰＭＯもいれば、もう少し、支援の目的を明確にして支援しようとしているＰＭＯもいる。

トラブルプロジェクトのサポートという同じ活動を行う２つのＰＭＯを考えてみよう。ひとつのＰＭＯは、プロジェクトでトラブルが発生したときに、経緯はともかくサポートをし、そのプロジェクトを予定通りに終わらせることに全力を尽くして支援する。

これに対して、自分たちが定着させようとしているプロジェクトマネジメントの進め方をしているプロジェクトに対してのみ、トラブルの場合にサポートするＰＭＯがある。こちらはプロジェクトに奉仕するのではなく、「プロジェクトマネジメントに奉仕」しているのだ。

◆ＰＭＯの影響力

みなさんのＰＭＯはどちらのタイプだろうか？ＰＭＯにリーダーシップはいらないと思っているＰＭＯは前者であることが多い。この場合、如何に尽くせるかというのが問題になる。ちょっと、言葉が過ぎるかもしれないが、このタイプのＰＭＯはなくなってもその組織のプロジェクトマネジメントへの影響は小さい。

ところが後者のＰＭＯの場合、仮にそのＰＭＯがなくなれば、組織のプロジェクトマネジメントは崩壊してしまう可能性すらある。なぜか？

仮に、ＰＭＯのミッションが導入、実施、成熟だとしたとすれば、後者のＰＭＯは自ら（あるいは組織としての）ミッションを達成するために支援をしている。これに対して前者のＰＭＯはお助けＰＭＯである。

あえていえば、前者のＰＭＯは、組織としてプロジェクトをきちんと終わらせるというミッションがあって動いているといえなくもないが、このミッションはどちらかというとプロジェクトスポンサーのミッションである。

◆ＰＭＯリーダーのリーダーシップはサーバント型リーダーシップ

話を元に戻そう。ＰＭＯリーダーは

プロジェクトマネジメントの導入、実施、成熟というミッションに達成のために、プロジェクトやプロジェクトマネジャーの支援を行う

人である。そして、このような奉仕活動はリーダーシップに他ならないことをよく認識しておく必要がある。

リーダーシップには「俺についてこい」型だけではなく、このようにリーダーが考えるミッションを達成するためにフォロワーに奉仕するというタイプのリーダーシップもある。一般的にはこのようなリーダーシップはサーバントリーダーシップと呼ばれる。

サーバントリーダーシップの詳細は、ＰＭ養成マガジンの「戦略ノート」に２００２年に書いているので、こちらを参考にして頂きたい。

リーダーシップ考（４）～サーバントリーダーシップ
http://pmstyle.jp/honpo/note/note25.htm

◆ＲＲＡＡ

前回、ＰＭＯがプロジェクトマネジメントのオーナーシップを持つべきであるという話をしたが、今回は、この点も含めて、ＰＭＯがどのような権限と責任を持つべきかを議論してみた。

日本ではあまり使われないが、組織のガバナンスを定義する方法として、ＲＲＡＡというフレームがある。

　Role（役割）
　Responsibility（実行責任）
　Accountability（説明責任）
　Authority（権限）

である。ステークホルダ分析などの場合にも使われることがある。このフレームに従って、ＰＭＯを定義してみよう。

◆ＰＭＯのＲＲＡＡ

最初はいわゆるＰＭＯのＲＲＡＡについて考えてみよう。「いわゆる」という書き方が気持ち悪ければ、この後で述べるＣＰＭＯ（全社ＰＭＯ）によって確立されたプロジェクトのマネジメントの標準の適用による効果を見ながら、事業部、地域などの範囲で、プロジェクトマネジメント推進の戦術的なマスタープランに対する責任を持つＰＭＯである。

ＰＭＯのＲＲＡＡは

・Role（役割）：ＰＭＯ
・Responsibility（実行責任）：プロジェクトマネジメント遂行の戦術的なマスタープランとリソースマネジメント
・Accountability（説明責任）：CPMOと事業部マネジャーへの報告
・Authority（権限）：年次の全社マスターポートフォリオ、および、プロジェクト資源予算計画の策定と調整

と定義できる。

◆ＣＰＭＯのＲＲＡＡ

次に、ＣＰＭＯについては

・Role（役割）：ＣＰＭＯ
・Responsibility（実行責任）：全社におけるビジョン、ミッション、ゴール、目的など、戦略的マスタープラン
・Accountability（説明責任）：CEOへの直接報告
・Authority（権限）：年次の全社マスターポートフォリオ、および、プロジェクト資源予算計画のレビューと承認

と定義できる。

基本的には、ＣＰＭＯとＰＭＯでほぼガバナンスが決まってくるが、もうひとつ、ＰＳＯの定義を決めておくと混乱が少なくなる。

◆ＰＳＯのＲＲＡＡ

ＰＳＯのＲＲＡＡは

・Role（役割）：ＰＳＯ
・Responsibility（実行責任）：プロジェクトマネジメント遂行のオペレーショナルマスタープランとプロジェクトポーフォトリオマネジメント
・Accountability（説明責任）：ＰＭＯとラインマネジャーへの報告
・Authority（権限）：プロジェクトポートフォリオのオペレーションプランと予算要求の承認

と定義できる。

◆活動のオーナーシップという概念

前回まで、ＰＭＯマーケティングの話をしてきたが、この問題を議論するために不可欠な要素がプロジェクトマネジメントのオーナーシップである。財務、マーケティング、営業、エンジニアリング、製造など、会社の中で組織管理や製品プロセスで行われているさまざまな活動には、オーナーシップがある。財務であれば財務部門がオーナーシップであり、そのトップ（例えばＣＦＯ）がオーナーになる。マーケティングであれば、マーケティング部門がオーナーであり、そのトップ（例えば、マーケティング部長）がオーナーになっている。

オーナーシップは基本的にその分野の活動に対して、すべての権限を持つと同時に、すべての責任を負うことになる。その意味合いは、財務や、マーケティングなどのビジネスシステムやビジネスプロセスを構築し、そのシステムの運用やプロセスの実行に対して責任を持つということである。当然ながら、誤った運用や実行がされた場合には指導する義務が生じる。

◆日本でもこれからはオーナーシップの確立が不可欠になる

さて、米国の動向を見ていると、日本でもこれから、プロジェクトマネジメントも財務やマーケティングと同じようにオーナーシップが生じることが予想される。。つまり、オーナーシップが存在し、そのオーナーシップのもとに、権限と責任を持ってプロジェクトマネジメントの展開が行われるようになるだろう。オーナーシップを持つ部門はいうまでもなくプロジェクトマネジメントオフィスであるＰＭＯである。

今、多くの企業でプロジェクトマネジメントの定着化・普及に苦労している理由のひとつはこのオーナーシップの欠如にあると思われる。ＰＭＯマーケティング以前の問題として、プロジェクトマネジメントの実施についてＰＭＯが責任も権限も持たない。単なるプロジェクトの支援部門やプロセス標準部門として位置づけられ、プロジェクトマネジメントに関する社内における権限はプロジェクトマネジャーや組織マネジャーより小さいというのが一般的な姿である。

◆オーナーシップのないという現実

例えば、プロジェクトマネジメント標準の実施を求めたところで、例えば

　・顧客が異なるやり方を求めている
　・標準どおりのやり方をするには、スケジュール的にも厳しいし、納期的にも厳し
い

といった理屈がまかり通っている。こういう書き方をするとそんなことはないと思われるＰＭＯの方も多いと思う。例えば、プロジェクト計画書は組織レビューの対象になっており、そこでは標準に則ったものが求められるという反論がありそうだ。

しかし、そのような組織でも、最終的な「プロジェクトマネジメント成果物」としての体裁は整えられるが、それが厳しく運用されている企業は決して多くない。たとえば、レビューはする。仮に、計画書の内容に問題があれば差し戻しがある（これもそんなに多くない）。ところが、計画書の記載方法に問題があっても指摘だけで、対応してくれで終わる。このような仕組みを持っているある企業の話だが、作業着手時に計画書の監査を実施したところ、作業着手前に計画書が組織レビューされており、指摘事項があったものの中のなんと９５％が未対応で作業に着手していた。こんなものだ。これは本来許されるものではないが、上に述べた（実質的な）権限の問題で、プロジェクトマネジメントを実行することに対するオーナーシップがない状況になっているわけだ。

さて、では、このような現状を踏まえてどのようにオーナーシップを確立していけばよいのだろうか？この点については次回議論してみたい。

◆定着化サイクルのコラムに戴いた意見

７月９日のコラムでプロジェクトマネジメントの定着化サイクルとして

通知　→　教育　→　奨励

というサイクルが必要だという話をした。この中で、プロジェクトマネジメントの定着化にマーケティングの手法を持ち込んで話をした（実際に、弊社はそういうコンサルティングを行っているのだから当然！）。これに対して、この３ヶ月くらいの間に何人ものＰＭＯの方から懐疑的な意見を戴いた。このメルマガは読者数は２０００名弱と少ないのだが、しっかり読んで戴いている方が多く、うれしかった。実は、このような状況に対する偽りのない第一印象はこれ。ただ、僕にも思うところがあるので、今回は意見を整理し、それに対する意見を書いてみたい。

戴いた意見を整理するとおおよそ、以下の３点に集約される。

（１）まず、ＰＭＯの顧客は、プロジェクトマネジャーなのか、組織なのか

（２）プロジェクトマネジャーを顧客だと考えた場合、組織としてこうしてほしいというのが入ってくるので、１００％顧客のニーズにこたえるということにはならない

（３）組織のニーズの入った標準やツールである限り、彼らがもろ手を挙げてそれを使うということにはならないし、プロジェクトマネジャーにとってのメリットも出しにくい。

◆そもそも、プロジェクトマネジャーとはどういう立場か

まず、基本的な認識として、プロジェクトマネジャーは経営組織の中でどういう立場なのかを考えてみる必要がある。９月７日にブログに以下のような記事を書いた。

プロジェクトマネジャーになるということ
https://mat.lekumo.biz/ppf/2007/09/post_1c25.html

この記事に書いていることが著者の考えである。一口でいえば現場を代表するリーダーではなく、経営を代表するリーダーである。

もちろん、これが一致するのがもっとも望ましいし、このような認識をすることはあまり望ましいものではないという考えも同時にもっているが、現場の立場でものを考えればよい立場ではないということを明確にするために、敢えてこういうものの言い方をしたい。

と同時に、プロジェクトマネジャーの標準やツールありきで、このサイクルを回していっても効果は薄く、自分たちがプロジェクトマネジャーの立場で彼らでは発想できない標準やツールを提供していくことが成功の秘訣であることを述べた。

ただし、現場にいて、現場を取りまとめていくという立場はある。したがって、マネジメントだけではすまない部分もあり、リーダーシップの発揮が求められる部分もある。

まず、これが一点目。

◆ＰＭＯにとってはプロジェクトマネジャーも組織も顧客

次にそのように考えた場合、プロジェクトにおいては、プロジェクトマネジャーが経営側の利益代表であり、そもそも、顧客がプロジェクトマネジャーか、組織かという命題の立て方そのものがおかしいのではないかと思う。顧客はいうまでもなくプロジェクトマネジャーであり、その背後には顧客としての組織があると考えるのが正しいだろう。

言い換えるとこの命題は、プロジェクトマネジャーを現場の利益代表だと考えているので発想するわけで、ＰＭＯはそこを改めていくべきだ。

さて、そこで、どうすればつかってもらえる標準やツール（以下、サービス）が提供できるかという話だ。７月９日のコラムで書いたマーケティングの話になる。このコラムで３つのサービス開発の方法があると説明した。プロダクトアウト、マーケットイン、マーケットアウトである。

◆ＰＭサービスにおけるプロダクトアウトとは

説明が不十分だったようなので、具体的な例で説明する。プロダクトアウトという方法は、ＰＭＯが普段の活動の中で必要だと感じているサービスを提供していくという方法である。組織側の立場に立っていろいろなサービスを提供していくというのはほとんどプロダクトアウトになると思われる。これでは、ほとんど、受け入れられるサービスができないと思われるが、ＰＭＯのサービスというのは本質的にそういうものだと思っている人も少なくない。

つまり、自分たちは組織の代理人であり、組織の代わりにプロジェクトマネジメントに関するガバナンスを持っており、それを行使することが使命だ。要するに、ごちゃごちゃ言わずにいうことを聞けという考え方。

これは一理あるのだが、必ずといってよいくらい、事業ガバナンスとのコンフリクトが起こる。つまり、言うことを聞くのはよいが、もし、それで儲からなかったら誰が責任と取るのかという議論の中で、いろいろな問題が起こる。

◆ＰＭサービスにおけるマーケットイントとは

次に、マーケットインという考え方。これはプロジェクトマネジャーのニーズを十分に聞き、それに対して、応えていくことを基本としたサービスの提供方法である。これは一見正しいように見えるかもしれないが、プロジェクトマネジャー自身が現場の利益代表であるとそんなに話は単純ではない。当然、ニーズに応えることができないケースが出てくるだろう。

◆マーケットアウトがすべてを解決する

最後がマーケットアウト。実は、申し訳ないことにこのコラムで次回説明するといってしないままになっている。マーケットアウト戦略は、ＰＭＯがプロジェクトマネジャーの立場でプロジェクトマネジャーが発想しない手法や標準を創り、それをサービスとしてプロジェクトマネジャーに提供していくことを意味する。

実は、上に述べたいろいろな問題を一挙に解決する秘訣はここにある。ＰＭＯがマーケットアウト戦略をとり、プロジェクトマネジャーの立場で、組織が満足する方法を考案し、サービスとして提供していくことこそが、ＰＭＯの成功要因である。

弊社ではこのようなマーケティングをＰＭＯマーケティングと呼んでいる。ＰＭＯマーケティングができれば、（１）～（３）の問題が一挙に解決するだろう！

９月２７日で第３期のＰＭＯリーダー養成講座が終わり、懇親会の席でＰＭＯのコストの議論になった。この問題について考えてみたい。

◆そもそもプロジェクトマネジメントコストは誰が持つべきか？

ＰＭＯのコスト以前に議論されているようで、本気で議論されていないのがプロジェクトマネジメントのコストをどう考えるかだ。この話はたいへん難しい話であるが、ＰＭＯとしてきちんと整理しておかなくてはならない話である。

プロジェクトマネジメントは本来、そのプロジェクトの目的を達成するために行うべきものである。その意味で、何をやって、何をやらないかということはプロジェクトマネジャーが判断すればよい。

しかし、実際にはそうはならない。標準を作る組織が多い。なぜだろうか？

◆アンケートに見る標準化の効果

以前、翔泳社のＰＭマガジンという雑誌の連載でこのアンケートをやったことがある。この結果で出てきた効果ベスト３は以下のとおりである。

（１）初心者にとって有効　４５％
（２）ナレッジの蓄積に有効　３５％
（３）プロジェクトマネジメントがうまくできる　１０％
http://pmstyle.jp/honpo/survey1/survey4.htm

これからわかるようにプロジェクトマネジメント標準がそのプロジェクトに対して、「直接的なメリット」をもたらしていると感じている人は全体の１割程度に過ぎない。これに対して、組織にメリットがあると思っている人は８０％いることになる。

◆標準化の本来の目的は

このアンケートの選択肢には明確な形で書いていないが、標準化というのは本来

　組織として成功を計画をできるようにするため

に策定するものである。言い換えると、このやり方をしていればうまくいくだろうという指標として標準がある。

であるとすれば、その組織の標準のプロジェクトマネジメントは、そのプロジェクトを成功を成功させるために欠かせないものであり、そう考えると、マネジメントコストはプロジェクトが持つというのが筋が通っている。

こういう建前がある。しかし、現実にはそのような筋書きにはなっていない。ＰＭＯから、自分たちの策定した標準どおりに行えば、プロジェクトはうまくいくという自信に満ちた言葉を聞いたことはない。標準を策定している側からの言い分は、だいたい、上のアンケートのものに近い。

まず、誰でも同じプロジェクトマネジメントをできるようになる。これは組織としては意味のあることだ。という言い分。確かにプロジェクトの成功率は上がるだろうが、シニアなプロジェクトマネジャーにとっては標準的なプロジェクトマネジメントを行う理由にならない。

そこで出てくるのが、ノウハウの蓄積という話。これはシニアなプロジェクトマネジャーにとっては自分のノウハウを組織に還元させていくという意味で標準を遵守する動機にはなる話だ。ただし、マネジメントコストをプロジェクトが持ってやるべきことではないという但し書きが着くだろう。

◆アカウンタビリティのための標準化という発想は正しいのか？

そこで、ＰＭＯ側の奥の手が出てくる。アカウンタビリティの確保である。つまり、上司や組織にプロジェクトの状況を説明し、必要とあれば指示を仰ぐのは組織人の義務であるという理屈だ。これを言われればプロジェクトマネジャーはやらざるを得ない。ただし、この場合もプロジェクトがコストを持つという話は成立しにくい。確かに、問題があれば組織として支援するので報告は必須であるというともっともらしいのだが、そもそも、そのような事項は組織がすべきプロジェクトマネジメントであり、それをプロジェクトマネジャーにマルナゲしているのがおかしいのだ。

このように考えると、プロジェクトマネジメントのコストはプロジェクトが持つべきだという論理は分が悪いのだが、あなたは、どう整理すればよいと思われるだろうか？

皆様の意見をお待ちしています。上の記事はブログ記事にしてありますので、こちらにコメントをください！

◆ＰＭＯブーム！？

ＰＭＩ東京事務局の永谷裕子さんに聞いた話だが、永谷さんがＪＵＡＳ（日本情報システムユーザ協会）で初めてＰＭＯのセミナーをやったところ、あっという間に１００名の応募があったそうだ。

この話を聞いてもそんなにびっくりしないくらい、ＰＭＯへの関心は高まっている。PMstyleでも昨年からＰＭＯリーダー養成講座というＰＭＯスタッフ育成の体系的講座（全６回）をやってい る。今年４月からの第４期ではほとんどのセッションが満席になっている。

◆米国のある企業＠１９９６

なぜ、こんなにＰＭＯが注目されるようになってきたのだろうか？プロジェクトマネジメントは米国から１０年遅れているといわれる。「プロジェクト的な性格を持つ業務の管理方法の唯一解がプロジェクトマネジメントだ」というのは少し違うと思うので、これがそのまま「プロジェクトのマネジメント」が遅れていることと意味しないが、「モダンプロジェクトマネジメント」ということであれば、１０年以上だと思う。僕はちょうど、１９９６年は米国の企業と一緒に仕事をしていたが、今のＳＩ企業と較べると、たぶん、その企業のプロジェクトマネジメントの方が進んでように思う。

この会社にはかなりしっかりとしたＰＭＯ組織があった。プロジェクトマネジメントのオーナーシップを持つだけではなく、プロジェクトへの支援活動も実践的なもので、我々のプロジェクトもずいぶん助けられた。特に、米国の拠点にプロジェクト本体があって、日本にも部隊がいるようなバーチャルチームだったが、チームのコミュニケーションの支援はまさに、「プロフェッショナルの業」だったような印象がある。

◆定着に１０年かかる

実は最近、ＰＭＯの仕事をするようになって、改めて、この企業のＰＭＯマネジャーとコンタクトをしていていろいろなことがわかったが、設立は８０年代前半だそうだ。１０年くらいはうまく機能しなかったそうだ。ただ、うまく行きだしたら、加速的にうまくいくようになったそうで、このあたりは定着化の話としてたいへん、興味深い。

さて、日本の企業はプロジェクトマネジメントに関心を持つようになってきて、まず、何をやったかというと多くの会社がＰＭＢＯＫの導入を行った。そして、多くの企業がうまく行かずに苦しんでいる。理由ははっきりしている。ＰＭＢＯＫというのは多くの企業がやっていることを標準化したものだが、その背後にはＰＭＢＯＫそのものではあまりフォーカスされていないプロジェクトマネジメントの推進体制というのがある。

◆ＰＭＢＯＫはハコモノ、ＰＭＯで魂を入れる？

つまり、多くの企業は「ハコモノ」としてＰＭＢＯＫを入れている。まあ、ハコモノを入れて、後で中身をつめていくというのは日本型マネジメントの特技だといえるので、失敗だとは言い切れないが、あまり感心したことではない。

それはそうとして、我々がＰＭＢＯＫの導入コンサルティングをやったクライアントのＰＭＯは例外なく、「これだけのことはできないし、プロジェクトマネジャーにやれとも言えない。できる範囲でやればいいよね」という。できなくて当たり前である。プロジェクトマネジャーにやらせることを前提にしているからだ。もちろん、ＰＭＯとしても何らかの支援はしなくてはならないと考えるが、そもそも、前提が間違っている。

ＰＭＢＯＫはプロジェクトマネジャーのやることを示したものではない。プロジェクトマネジメントとしてすべきことを示したものだ。

ＰＭＢＯＫを採用する、しないに関わらず、プロジェクトマネジメントはプロジェクトマネジャーだけがやるものではないことに多くの企業が気がついてきた。そこで、とりあえず、ＰＭＯを作ってプロジェクトマネジメントの一端を担うようにし始めた。ハコモノにやっと少し、中身ができてきたわけだが、これが、今、ＰＭＯが注目されている理由である。

今日はちょっと軽めの話題。

松本人志の初監督作品「大日本人」を見られた方は多いと思う。ビジネスの世界にも、怪獣とその怪獣の退治方法を書いた本がある。

ジーニー・ダックが書いた「チェンジモンスター」にチェンジモンスターという本だ。変革を実現しようとしたときに、抵抗する、新しい動きをぶち壊すといった「活躍」をするモンスターの退治方法を書いた本だ。日本語でいえば、さしむき、「抵抗勢力」といったところだろう。

パロディーではないが、プロジェクトマネジメントの導入、定着化をするときに登場してくるチェンジモンスターの行動を整理してみた。

ＰＭＯがプロジェクトに対して、支援、指導をしようとしたときに、こんなチェンジモンスターに出会うことはないだろうか？ちなみに、ジーニー・ダックはボスコンのコンサルタント（出版当時）。論理的なアプローチの一方で、感情的・心理的なアプローチもしなくては変革は成し遂げられないということなのだろう。

■タコツボドン
得意技：自分の担当を超えた視野を持つことを拒否し，「よそ者」の関与を否定する
叫び声：「プロジェクトマネジメント自体がプロジェクトの仕事ではない」、「標準を使えというご忠告はありがたいですが、我々もプロジェクトの成功を第一に検討してみますので、後はお任せください」

■ウチムキング
得意技：社内で何が評価されるかを重視し，顧客等の外部ではなく社内にすべての行動の焦点をあわせ，社内外のズレに目を閉ざす
叫び声：「顧客はいろいろと言っていますが、社内の雰囲気は悪くないし、協力的ですので、このままでうまく行きます！」

■カコボオウレイ
得意技：従来のやり方はどんなに効率が悪くても中止をできない，決断できない
叫び声：「これまでのやり方で、うまくやってきたのだから、直すべきところは直し、このやり方でやるほうが顧客も社内も安心だよ」

■ミザル・キカザル・イワザル
得意技：３匹セットになって，見ざる，聞かざる，言わざるを通し，嵐が過ぎるのを首をすくめてやり過ごす
叫び声：「また、ＰＭＯが新しい仕組みを作ろうとしているけど、どうせ今回もまた掛け声だけだ。しばらくすれば、忘れてしまう。動くだけ損に決まっている。様子見だ」

■ノラクラ
得意技：様々な言い訳を使いあの手この手で変革を回避しようとする
叫び声：「顧客の進捗を管理するというのは前例がない。前例のないやり方をすると、社内も顧客も混乱するだけだ。それで協力を得られなくなったらどうする。百歩譲って、社内や顧客が受け入れるとしても、うちのプロジェクトは人手がたりない」

■マンテン
得意技：すべての可能性をリスクを潰して１００点満点の報告書がないと動き出せず，結局，具体的なアクションは取れない，あるいは遅れてしかとれない
叫び声：「本当にリスクはこれだけだろうか？まだ検討不足じゃないだろうか？プロジェクト開始前にもう少しじっくり検討しなくては！」、「この計画で絶対に失敗しないといえるだろうか？やるからにはパーフェクトでなければ！」

■カイケツゼロ
得意技：課題の指摘やできない理由の説明は巧みだが，解決策の提言は出せない
叫び声：「協力会社以外からのリソースの調達は何度も検討したが無理なんです。その理由は５つあって．．．」

【参考資料】
モンスター名は「チェンジモンスター―なぜ改革は挫折してしまうのか? 」が出典。
得意技は「チェンジモンスター―なぜ改革は挫折してしまうのか? 」を一部編集。