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

なんだかんだといって、３～４年前に較べると、プロジェクトマネジャーは行動するようになってきたと思う。

ＰＭ養成マガジンは、ひたすら、行動すること、行動する能力を高めることに焦点を当てて活動をしてきた。

このような状況の中で、ある大手企業の人材開発マネジャーと話をしていて、プロジェクトマネジャーの育成には何が必要なのだろうか？と改めて考える機会があった。

もっと行動が必要なのか、あるいは、行動は十分で省察することが必要なのか？

別の言い方をすれば、行動する能力を高めるべきなのか、既存の行動について省察する能力を高めるべきなのだろうか？

上の人材開発マネジャーと話をしている中で感じたのは、組織の目的とマネジャーの育成が混乱しているのではないかということだった。

組織の目的は常に行動をすることである。これは間違いない。

しかし、今、プロジェクトマネジャー育成の目的は「行動の質を高めること」に移りつつあるのだと思う。

みんな十分に行動をしているのだ。しかし、必ずしも十分に結果がでない。空回りしてしまう。

この問題意識が芽生えたのは２年くらい前である。それ以来、ずっとＰＭ養成マガジンとしてどういうスタンスで行こうかと迷っている。

少なくとも、社内標準があってそれなりに従っているとか、ＰＭＰの資格をとって自分なりにシステマティックな方法で取り組んでいるといった人は、もう十分に行動をしていると考えてよい。問題は行動の質だ。しかし、そこで、立ち止まっている人が非常に多い。

しかし、ＰＭ養成マガジンの読者にはそうではなく、まだまだ、行動する能力を身につける必要のある人も多い。この辺が悩ましいところ。ＰＭ養成マガジンもブログ化もさることながら、読者を再定義しなおす時期に来ているのかもしれない。

この悩みはしばらく続きそう。

先週の金曜日の「ＰＭコンピテンシーを高める１冊の本」で紹介したこの本が昨日までに１２冊売れた。

Ｄ・クイン・ミルズ（アークコミュニケーションズ監修、スコフィールド・素子訳）
　　　　　　　　「ハーバード流マネジメント「入門」
　　https://mat.lekumo.biz/books/2006/07/post_da81.html

最近、紹介した本で、１回で１０冊以上売れた本は珍しい。こういう内容に興味を持っている人が多いことが分かったのは、収穫。

本音のところ、マネジメントセンスのないＰＭが多すぎる。そんなＰＭにプロジェクトマネジメント手法を教えるというのはナンセンス。「猫に小判」ならまだいいが、「〇〇〇〇に刃物」になりかねない。

メルマガ記事、読んでいない人もいると思うので、もう一度、掲載しておく。

　～マネジメントの原理を学ぼう～

プロジェクトマネジメントには独自の世界がある。しかし、プロジェクトマネジメントの本質は間違いなく「マネジメント」である。

ＰＭＢＯＫを勉強してもプロジェクトマネジメントのコアであるマネジメントのことは分からないし、また、多くのＰＭセミナーでも同様だ。

しかし、マネジメントはＰＭにとって中核になるものである。なんとかして身に付けたい。が、マネジメント本でテクニックを学んでみても始まらない。経営学の本は本質に迫れるのだが、難しい。

この本を読もう。原題は「Principles of Management」である。マネジメントの原理が誰にでも読めるよう易しく書かれている。まさに、プロジェクトマネジャーが自分のコアになるマネジメントスキルを身につけるにもってこいの一冊だ！

コンサルタント「プロジェクトマネジャーにどのくらい権限を与えていますか」

部長「プロジェクト実行に関するすべての権限を与えています」

コンサルタント「すべてとは？」

部長「決済された予算の使い方、マイルストーンを実現するスケジュールの組み立て、調達の仕方などです」

コンサルタント「責任は？」

部長「もちろん、全責任はプロジェクトマネジャーにあります」

コンサルタント「何の全責任ですか」

部長「予算内で納期に間に合うように求めている成果物を作ることです」

コンサルタント「プロジェクトに対する部長の責任はなんですか」

部長「プロジェクトマネジャーを指導することです」

コンサルタント「部長がプロジェクトマネジャーの立場なら、その権限でその責任を果たせると思えますか」

部長「果たせる思えるとすれば、組織の意味がないじゃないですか。それはプロジェクトでもないと理解しています。果たせないと思えることをなんとかして果たすから組織なんです」

Fin

◆プロジェクトマネジメントにおけるコンプライアンス

米国のプロジェクトマネジメントの本を読んでいると「コンプライアンス」という言葉がよく出てくる（ちなみに、ＰＭＢＯＫにはコンプライアンスという概念は今のところない）。

この言葉は、一般的な用語としては法令遵守などの企業倫理という意味で使われるが、プロジェクトマネジメントの中では多少異なるニュアンスでも使われる（もちろん、企業倫理という意味でも使われるが）。

異なるニュアンスとは、「標準」などの組織内のプロジェクトマネジメントに関するルール遵守という意味で使われる。

◆監査

少し話が飛ぶが、コンプライアンスの基盤になるのは「監査」活動である。会計監査、システム監査、環境監査、技術監査、システム監査、セキュリティ監査、品質監査、プロジェクト監査など、いろいろなものに対して適用される活動である。

監査論の定番書である八田先生の

　「監査論を学ぶ」
　　http://www.amazon.co.jp/exec/obidos/ASIN/4495169734/opc-22/ref=nosim

によると監査は

=====
監査とは経済活動と経済事象についての主張と確立された基準との合致の程度を確かめるために、これらの主張に関する証拠を客観的に収集・評価するとともに、その結果を利害関係をもつ利用者に伝達する体系的な過程である
=====

と定義されている。監査というと会計というイメージがあるが、経済活動、経済事象の捉え方によっては、ビジネスの活動はすべて監査の対象になるといってもよい。

では、どうして監査が必要になるのだろうか？

これにはいくつかのポイントが言われているが、最も基本であり重要なものが

　「利害の対立」

である。

例えば、企業と株主の場合、情報（決算書）をめぐって利害の対立が発生する可能性がある。利益が多くなれば配当を多くせざるを得ないからだ（もちろん、これを対立にするかどうかはマネジメントの問題だが、本質的な対立要素を含んでいる）。そこで、発信側としては、できるだけ利益を少なく発信したい。粉飾決算といった一線を踏み越える組織も出てくる。

このように、情報の発信者（この場合企業）と受信者（この場合株主）の間に情報をめぐる利害の対立の可能性がある場合には、「第三者」が入って監査を実施し、その情報が適切なものかどうかを明らかにされる必要がある。これが監査の必要性であり、組織として発信する情報の健全性を確保することがコンプライアンスだといってよい。

◆プロジェクト監査とは

さて、このような基本的な枠組みを理解した上で、プロジェクトにおける監査というものについて考えてみたい。まず、この監査の枠組みになぞらえると、プロジェクトの場合は誰が情報発信者で、誰が情報受信者なのか。

　情報発信者＝プロジェクト（プロジェクトマネジャー）

は分かりやすい。問題は情報受信者である。情報受信者として真っ先に出てくるのは

　情報受信者＝プロジェクトの成果物を受け取る顧客（社内外）

ということになると思われる。また、エグゼクティブも情報受信者になるだろう。微妙なのは、上位組織のマネジャー（ラインでプロジェクトを行うならラインマネジャー）である。上位組織のマネジャーは多くの場合、プロジェクトスポンサーになることが多い。

　ラインマネジャーはプロジェクトスポンサー
　　http://pmos.jp/pmstyle/pmcoe/pmcoe4.html

従って、プロジェクトチームに片足突っ込んだ存在であるし、スポンサーとしてプロジェクトに対して何らかの統制を行うことも可能である。しかし、実際にはここが情報受信者になっているケースが多い。これはプロジェクトマネジメントの問題点の一つである。これについてはまた、いずれ触れる。

◆監査がプロジェクトマネジメントを成功させる

そのような環境の中で、プロジェクト監査は、プロジェクトマネジメントの状況を第三者的に分析する。その視点はいくつかある。

まず、最初は冒頭に述べたコンプライアンスの視点である。つまり、組織の標準として定められたとおりの手順、基準、ルール、ツールに従って計画が作られているか、進捗が報告されているかといった点である。また、マネジメント判断の中で、メトリクスが遵守されているかどうかも問題になる。ここを担保しなくては監査活動は成立しない。

その上で、プロジェクトマネジメント成果物（計画や進捗ドキュメント）が公正なものであるかどうかである。つまり、進捗報告が規則どおりに行われ、かつ、内容に虚偽がないかどうかをチェックする。

ここが担保されないとプロジェクトマネジメントはできない。プロジェクトの「前提条件」の一つは、プロジェクト作業の担当者が「正しく」にプロジェクトマネジャーに状況を報告し、また、プロジェクトマネジャーが「正しく」に上位マネジャーにプロジェクトの状況を報告することである。この前提条件も監査では分析視点になる。

これで、形式的な健全性は保証されたことになる。この先は標準化がどれだけ進んでいるかによって変わる。標準化の究極の姿は標準手法、ツール、ルール、メトリクスなどに準じて進めていれば健全性が保証されることである。品質など、特定に分野においてはこの形は実現されつつある。

しかし、マネジメント全般になると少し、難しい部分がある。そこで、ある程度、マネジメントの内容に踏み込んだ視点からプロジェクトマネジメントの健全性のチェックが行われるようになる。

◆プロジェクトマネジメントにおけるコンプライアンス

米国のプロジェクトマネジメントの本を読んでいると「コンプライアンス」という言葉がよく出てくる（ちなみに、ＰＭＢＯＫにはコンプライアンスという概念は今のところない）。この言葉は、一般的な用語としては法令遵守などの企業倫理という意味で使われるが、プロジェクトマネジメントの中では多少異なるニュアンスでも使われる（もちろん、企業倫理という意味でも使われるが）。

異なるニュアンスとは、「標準」などの組織内のプロジェクトマネジメントに関するルール遵守という意味で使われる。

◆監査

少し話が飛ぶが、コンプライアンスの基盤になるのは「監査」活動である。会計監査、システム監査、環境監査、技術監査、システム監査、セキュリティ監査、品質監査、プロジェクト監査など、いろいろなものに対して適用される活動である。

監査論の定番書である八田先生の

　「監査論を学ぶ」
　　www.amazon.co.jp/exec/obidos/ASIN/4495169734/opc-22/ref=nosim

によると監査は

=====
監査とは経済活動と経済事象についての主張と確立された基準との合致の程度を確かめるために、これらの主張に関する証拠を客観的に収集・評価するとともに、その結果を利害関係をもつ利用者に伝達する体系的な過程である
=====

と定義されている。監査というと会計というイメージがあるが、経済活動、経済事象の捉え方によっては、ビジネスの活動はすべて監査の対象になるといってもよい。

では、どうして監査が必要になるのだろうか？

これにはいくつかのポイントが言われているが、最も基本であり重要なものが
　「利害の対立」
である。例えば、企業と株主の場合、情報（決算書）をめぐって利害の対立が発生する可能性がある。利益が多くなれば配当を多くせざるを得ないからだ（もちろん、これを対立にするかどうかはマネジメントの問題だが、本質的な対立要素を含んでいる）。そこで、発信側としては、できるだけ利益を少なく発信したい。そこで粉飾決算といった一線を踏み越える組織も出てくる。
このように、情報の発信者（この場合企業）と受信者（この場合株主）の間に情報をめぐる利害の対立の可能性がある場合には、「第三者」が入って監査を実施し、その情報が適切なものかどうかを明らかにされる必要がある。これが監査の必要性であり、組織として発信する情報の健全性を確保することがコンプライアンスだといってよい。

◆プロジェクト監査とは

さて、このような基本的な枠組みを理解した上で、プロジェクトにおける監査というものについて考えてみたい。まず、この監査の枠組みになぞらえると、プロジェクトの場合は誰が情報発信者で、誰が情報受信者なのか。

　情報発信者＝プロジェクト（プロジェクトマネジャー）

は分かりやすい。問題は情報受信者である。情報受信者として真っ先に出てくるのは

　情報受信者＝プロジェクトの成果物を受け取る顧客（社内外）

ということになると思われる。また、エグゼクティブも情報受信者になるだろう。微妙なのは、上位組織のマネジャー（ラインでプロジェクトを行うならラインマネジャー）である。上位組織のマネジャーは多くの場合、プロジェクトスポンサーになることが多い。

　ラインマネジャーはプロジェクトスポンサー
　　http://pmos.jp/pmstyle/pmcoe/pmcoe4.html

従って、プロジェクトチームに片足突っ込んだ存在であるし、スポンサーとしてプロジェクトに対して何らかの統制を行うことも可能である。しかし、実際にはここが情報受信者になっているケースが多い。これはプロジェクトマネジメントの問題点の一つである。これについてはまた、いずれ触れる。

◆監査がプロジェクトマネジメントを成功させる

そのような環境の中で、プロジェクト監査は、プロジェクトマネジメントの状況を第三者的に分析する。その視点はいくつかある。

まず、最初は冒頭に述べたコンプライアンスの視点である。つまり、組織の標準として定められたとおりの手順、基準、ルール、ツールに従って計画が作られているか、進捗が報告されているかといった点である。また、マネジメント判断の中で、メトリクスが遵守されているかどうかも問題になる。ここを担保しなくては監査活動は成立しない。

その上で、プロジェクトマネジメント成果物（計画や進捗ドキュメント）が公正なものであるかどうかである。つまり、進捗報告が規則どおりに行われ、かつ、内容に虚偽がないかどうかをチェックする。

ここが担保されないとプロジェクトマネジメントはできない。プロジェクトの「前提条件」の一つは、プロジェクト作業の担当者が「正しく」にプロジェクトマネジャーに状況を報告し、また、プロジェクトマネジャーが「正しく」に上位マネジャーにプロジェクトの状況を報告することである。この前提条件も監査では分析視点になる。

これで、形式的な健全性は保証されたことになる。この先は標準化がどれだけ進んでいるかによって変わる。標準化の究極の姿は標準手法、ツール、ルール、メトリクスなどに準じて進めていれば健全性が保証されることである。品質など、特定に分野においてはこの形は実現されつつある。しかし、マネジメント全般になると少し、難しい部分がある。そこで、ある程度、マネジメントの内容に踏み込んだ視点からプロジェクトマネジメントの健全性のチェックが行われるようになる。

今年に入ってからもう、３～４年読んでいるメールマガジンが立て続けに廃刊になった。内容の質が落ちているわけではない。どちらかというと、唐突な感のある廃刊。

プロジェクトマネジャー養成マガジンもそうだが、ビジネス系の人気メールマガジンは軒並み、読者数が減ってきている。

飽きたとかそういう側面もあると思うが、いろいろなメルマガの読者の一人として感じていることは、やっぱり、これだけスパムが増えてくるともういいという感じはある。組織として、メルマガドメインのメールの着信拒否を始めたところも少なくない。

メルマガにはメルマガのよさがあると思うので、当面、廃刊するつもりはないが、選択肢は必要だと思う。それで、ブログを作った。

今までも、ブログはいろいろと試みているが、メルマガの名称をつけたブログは初めて。メルマガにはすでにバックナンバーの収録サイト「プロジェクトマネジメントＯＳ本舗」がある。これをブログ化することも考えたが、ちょっと違うと思って今のところやめた。ブログはやっぱりアーカイブには適さないと思ったから。

そんなところで、実際のところ、どのような形でメルマガとブログを共存できるかよくわからないが、とりあえず、始めた。当面は、メルマガでかけなかったことを書くようなイメージになるかもしれない。

ぜひ、読者の皆様からもアイディアを戴きたい！

◆プロジェクトマネジメント能力

プロジェクトマネジメントの組織成熟度の議論というのは、プロジェクトマネジメント全般に渡す話ですが、その中でもとりわけ重要なのが、リスクマネジメントとプログラム統合マネジメント（マルチプロジェクト統合マネジメント）だと思われます。

まず、最初に「成熟度」の向上というのはどういうメカニズムにで起こるかを考えてみたいと思います。プロジェクトマネジメント能力を持つのは３つあります。プロジェクトマネジャー、プロジェクトチーム、そして、組織です。ＰＭＩ方式のプロジェクトマネジメントでは

　プロジェクトマネジャー　ＰＭＣＤＦ（ＰＭコンピテンシー）
　組織、チーム　ＯＰＭ３

で成熟度を向上させるようになっています。

◆プロジェクトマネジメントを成熟させるスパイラルメカニズム

ここで、注意しなくてはならないことは、プロジェクトマネジャーのＰＭコンピテンシーの向上、チームのＰＭ能力の向上、組織のＰＭ能力の向上は互いに深く関係していることです。

まず、組織の能力向上から考えて見ましょう。組織の能力が向上するために、さまざまなツールやテンプレートを作り、メトリクスを設定し、パフォーマンス評価をすることで、ノウハウが蓄積されていきます。

一方でプロジェクトマネジャーはトレーニングで最低限の知識やスキルを身につけます。これだけですと、プロジェクトマネジメントを実行するには四苦八苦するのですが、組織として準備されたツールやノウハウ、テンプレートなどの資産を活用することによって、スムーズにプロジェクトマネジメントを実行することができます。

特に、キャリアの浅いプロジェクトマネジャーの場合ですと、自分の実力以上のプロジェクトマネジメントを行うことも可能になります。

と、同時に、プロジェクトマネジャーはこれらのツールを使ってプロジェクトをマネジメントする中で、成功や、トラブルの経験をします。これらの経験を通じて、さらにノウハウが蓄積され、また、ツールの改善がなされます。

ツールが改善されれば、プロジェクトマネジャーもより強力な武装をすることになり、対応できるプロジェクトの範囲も広がってきます。

このような一連の流れとは別の流れとして、プロジェクトマネジャーのＰＭコンピテンシーの開発をすることがあります。これはプロジェクトマネジメントに限らず、いろいろな経験をしたり、あるいはものの見方、考え方のトレーニングをするといった中で開発されていきます。

ＰＭコンピテンシーが開発されていくことによって、ツールの使い方が変わってきます。より適切に使えるようになります。言い換えますと、ツールがより効果的に使えるようになるわけです。また、ツールに対するフィードバック、ノウハウの蓄積に対してもポジティブな影響を与えることはいうまでもありません。

◆チームからのビュー

この際のもう一つの視点はチームです。プロジェクトはどちらかというと既にある「タレント」の行動を引き出し、成果を生み出していくイメージが強いですが、マネジメント一つの視点に「育成」という視点もあります。これは主にチームワークを芽生えさせ、チーム力を向上させるという視点が中心になるわけですが、この中にはマネジメント的な要素が含まれるものもあります。プロジェクトマネジメントにはメンバーが中心になって進めていくものがあるためですが、その代表はリスクマネジメントです。計画としての取りまとめはプロジェクトマネジャーの役割ですが、実際にリスクを識別したり、あるいは、モニタリングをするというのはメンバー一人ひとりの役割になります。このようなメンバーのリスクマネジメントの能力を向上させることは、チーム育成の重要な部分です。リスク以外にも、スケジュールマネジメント、品質マネジメントなどはメンバーに権限委譲をし、メンバーが中心になって取り組んでいく必要があります。

◆複数のプロジェクトの調整

以上が、単一のプロジェクトで見た場合の話ですが、組織の成熟度を考える際に忘れてはならないのは、複数のプロジェクトの調整能力です。

例えば、複数のプロジェクト間におけるリソースの調整、複数のプロジェクトのスケジュール調整などです。マルチプロジェクトマネジメントの能力ということになりますが、組織の成熟度を上げる場合には、この視点が重要になってくる組織もあります。

ＰＭＩでは、マルチプロジェクトマネジメントの方式をまずは複数のプロジェクトを束ねる「プログラムマネジメント」、そして、プログラムを束ねるポートフォリオをマネジメントする「ポートフォリオマネジメント」と位置づけています。

この体系化の進展具合と、マネジメント改善の４レベル（標準化→測定→コントロール→継続的改善）の組み合わせで成熟度を表現しようとしています。マネジメントレベルは単一のプロジェクトに対するプロジェクトマネジメントのレベルをあらわし、複数のプロジェクトのマネジメントの体系化の度合いを表しているわけです。

つまり、組織におけるプロジェクトマネジメントの成熟度の向上は、個々のプロジェクトのマネジメントが改善され、同時に、複数プロジェクトの捉え方が適切になることを意味しています。

今回のコラムは、プロジェクトマネジメントの成熟について書いてみます。

◆成熟させるプロジェクトマネジメント能力

プロジェクトマネジメントの組織成熟度の議論というのは、プロジェクトマネジメント全般に渡す話ですが、その中でもとりわけ重要なのが、リスクマネジメントとプログラム統合マネジメント（マルチプロジェクト統合マネジメント）だと思われます。

まず、最初に「成熟度」の向上というのはどういうメカニズムにで起こるかを考えてみたいと思います。プロジェクトマネジメント能力を持つのは３つあります。プロジェクトマネジャー、プロジェクトチーム、そして、組織です。ＰＭＩ方式のプロジェクトマネジメントでは

　プロジェクトマネジャー　ＰＭＣＤＦ（ＰＭコンピテンシー）
　組織、チーム　ＯＰＭ３

で成熟度を向上させるようになっています。

◆プロジェクトマネジメントを成熟させるスパイラルメカニズム

ここで、注意しなくてはならないことは、プロジェクトマネジャーのＰＭコンピテンシーの向上、チームのＰＭ能力の向上、組織のＰＭ能力の向上は互いに深く関係していることです。

まず、組織の能力向上から考えて見ましょう。組織の能力が向上するために、さまざまなツールやテンプレートを作り、メトリクスを設定し、パフォーマンス評価をすることで、ノウハウが蓄積されていきます。

一方でプロジェクトマネジャーはトレーニングで最低限の知識やスキルを身につけます。これだけですと、プロジェクトマネジメントを実行するには四苦八苦するのですが、組織として準備されたツールやノウハウ、テンプレートなどの資産を活用することによって、スムーズにプロジェクトマネジメントを実行することができます。特に、キャリアの浅いプロジェクトマネジャーの場合ですと、自分の実力以上のプロジェクトマネジメントを行うことも可能になります。

と、同時に、プロジェクトマネジャーはこれらのツールを使ってプロジェクトをマネジメントする中で、成功や、トラブルの経験をします。これらの経験を通じて、さらにノウハウが蓄積され、また、ツールの改善がなされます。

ツールが改善されれば、プロジェクトマネジャーもより強力な武装をすることになり、対応できるプロジェクトの範囲も広がってきます。

このような一連の流れとは別の流れとして、プロジェクトマネジャーのＰＭコンピテンシーの開発をすることがあります。これはプロジェクトマネジメントに限らず、いろいろな経験をしたり、あるいはものの見方、考え方のトレーニングをするといった中で開発されていきます。

ＰＭコンピテンシーが開発されていくことによって、ツールの使い方が変わってきます。より適切に使えるようになります。言い換えますと、ツールがより効果的に使えるようになるわけです。また、ツールに対するフィードバック、ノウハウの蓄積に対してもポジティブな影響を与えることはいうまでもありません。

◆チームからのビュー

この際のもう一つの視点はチームです。プロジェクトはどちらかというと既にある「タレント」の行動を引き出し、成果を生み出していくイメージが強いですが、マネジメント一つの視点に「育成」という視点もあります。これは主にチームワークを芽生えさせ、チーム力を向上させるという視点が中心になるわけですが、この中にはマネジメント的な要素が含まれるものもあります。プロジェクトマネジメントにはメンバーが中心になって進めていくものがあるためですが、その代表はリスクマネジメントです。計画としての取りまとめはプロジェクトマネジャーの役割ですが、実際にリスクを識別したり、あるいは、モニタリングをするというのはメンバー一人ひとりの役割になります。このようなメンバーのリスクマネジメントの能力を向上させることは、チーム育成の重要な部分です。リスク以外にも、スケジュールマネジメント、品質マネジメントなどはメンバーに権限委譲をし、メンバーが中心になって取り組んでいく必要があります。

◆複数のプロジェクトの調整

以上が、単一のプロジェクトで見た場合の話ですが、組織の成熟度を考える際に忘れてはならないのは、複数のプロジェクトの調整能力です。例えば、複数のプロジェクト間におけるリソースの調整、複数のプロジェクトのスケジュール調整などです。マルチプロジェクトマネジメントの能力ということになりますが、組織の成熟度を上げる場合には、この視点が重要になってくる組織もあります。ＰＭＩでは、マルチプロジェクトマネジメントの方式をまずは複数のプロジェクトを束ねる「プログラムマネジメント」、そして、プログラムを束ねるポートフォリオをマネジメントする「ポートフォリオマネジメント」と位置づけています。

この体系化の進展具合と、マネジメント改善の４レベル（標準化→測定→コントロール→継続的改善）の組み合わせで成熟度を表現しようとしています。マネジメントレベルは単一のプロジェクトに対するプロジェクトマネジメントのレベルをあらわし、複数のプロジェクトのマネジメントの体系化の度合いを表しているわけです。

つまり、組織におけるプロジェクトマネジメントの成熟度の向上は、個々のプロジェクトのマネジメントが改善され、同時に、複数プロジェクトの捉え方が適切になることを意味しています。

◆ガバナンスマネジメントは完璧なのか？

プロジェクトのガバナンスマネジメントとは、プロジェクトに対する各ステークホルダ（ＰＭＢＯＫで定義されている意味でのステークホルダ＝プロジェクトマネジャー、プロジェクトメンバーも含むすべての関係者）の権限と責任を明確にし、その権限でプロジェクトにおける責任を果たしていくことである。

日本の組織にプロジェクトのガバナンスマネジメントの重要性を説いても、なかなか、理解してもらえないことが多い。例えば、プロジェクトガバナンスマネジメントの最も基本になるのはプロジェクトマネジャーにどのような権限を与えているかであるが、この点を聞いてみると、こういう答え方をする組織が多い。

　弊社ではプロジェクトマネジャーにプロジェクトマネジメントに関することは
　全面的に権限委譲している。プロジェクトマネジャーは全力を尽くして、
　プロダクトスコープを達成しなくてはならない

これには大きな前提がある。「制約条件を守る範囲において」という前提である。制約条件の中で共通の認識をしているケースが多いのは、利益（目標利益率）と納期である。プロジェクトマネジャーとしてはこれさえクリアすればあとは交渉ごとで基本的にそのイニシャティブはプロジェクトマネジャーにあると思いたい。

ところが、実は（プロジェクトの上位）組織はそうは思っていないケースが多い。一言で言えば、明確化されていないことはすべてガバナンスが組織側にあると思っていることが多い。

「権限委譲」をめぐるこの認識の違いはなぜ、起こるのだろうか？

◆プロジェクト憲章の位置づけ

一つはプロジェクト憲章の位置づけである。プロジェクトとはそもそも目的達成を第一義に、組織の規定（レギュレーション）を離れて実施するものである。ただし、まったく無法地帯では経営管理上の問題があるので、組織の規定に変わるルール（制約条件）をプロジェクト憲章で定め、それを以ってプロジェクトマネジャーを任命する。つまり、プロジェクトマネジャーを拝命するということは、プロジェクト憲章に書かれているレギュレーションを守ることを意味する。

例えば、組織の規定に「１社１０００万円を超える取引は、口座を開設して行うこと」という規定があったとしよう。口座を開設するためには、なんやかんやで２ヶ月くらいの時間がかかる。これに対して、このプロジェクトでは「ひょっとすると」特殊な技術調達が必要になり、ベンチャー企業との取引が必要になる「かもしれない」とする。すると、プロジェクト憲章では、例えば、制約条件として「取引が１社３０００万円以上になる場合には口座取引とする」という条件を決める。もちろん、最初の１社１０００万円の規定は度返しである。しかし、プロジェクト憲章がこのように使われることはまずない。プロジェクト憲章は組織の規定より強く制約をした場合に使われることが多い。

組織の規定にしたがっていたのではうまく行かないからプロジェクトとして取り組む。しかし、プロジェクトには組織の規定を適用する。これでプロジェクトがうまく行くはずがない。

◆リスクの扱い

もう一つはリスクの扱いである。上の話も実はリスクの議論を含んでいるが、リスク対応策の実施の際に組織の規定が優先される。違う言い方をすると計画は承認するのだが、リスク計画は承認しない。実際にリスクが発生し、そのときに必要な対処の内容によって誰が意思決定するか考えようという取り決めにする。もっといえば、そんなことがあるとややこしいので、計画通りにやれという乱暴な議論をする。

今年度から開始した「プロジェクト計画書」セミナーで、プロジェクト計画書の段階的詳細化の話をすると以下のどちらかの反応が返ってくることが多い。

一つは、プロジェクトの計画段階で最後までの計画を策定して、承認を得ないと前に進めない仕組みになっているという話。もうひとつは、一旦、策定した計画はプロジェクト側に事情で変更できないという話。本質的には同じ話だが、なんとも考えさせられる話だ。

◆権限委譲の正しさをチェックする方法

責任を全うするために必要な権限をといった議論をしだすと話は複雑になるが、実は権限委譲の適切さをチェックする方法はそんなに難しくない。

まず、プロジェクトのリスクに対して、プロジェクトで考えるべきリスクと、組織として考えるべきレベルのリスクに分ける。例えば、取引先の会社が倒産するといったリスクはこれはプロジェクトに大きな影響があってもプロジェクトで考えるべきリスクではない。このようなリスクというのは意外と多い。

その上で、プロジェクトレベルのリスクの対応策を検討する。そして、その対応策に必要な権限を分析する。すべての権限がプロジェクト憲章でプロジェクト（マネジャー）に与えられていれば、権限委譲は適切である。

実際にはプロジェクト憲章を発行する時点では、リスクが見えていないことも少なくない。そのような場合には、組織のレギュレーションで縛るのではなく、最低限、プロジェクトに課したい制約条件だけを決め、後は全面的に権限委譲する、つまり、組織のレギュレーションを無視する権限を与えることが望ましい。例えば、コスト関係でいえば

　・目標とする収益率

だけを決めておき、組織のレギュレーションがどうなっていようと、決済なく支出できるようにする。これが権限委譲である。ここで組織のレギュレーションを生かしていると、例えば、調達でここが安いのでといった組織の不要な介入が入ることになる。これではプロジェクトマネジメントはうまく行かない。

◆ガバナンスマネジメントはＰＭＯの役割

このようなガバナンスのマネジメントを行うには、組織がリスクに対して適切なマネジメントをしていることが不可欠である。組織が不必要にプロジェクトに介入しているのは、組織としてリスクが見えていない、扱いを決めていないといったリスクマネジメント不全が極めて多い。

組織側にたってこのようなリスクマネジメントとガバナンスマネジメントをするのはＰＭＯの役割である。

◆ガバナンスマネジメントは完璧なのか？

日本の組織にプロジェクトのガバナンスマネジメントの重要性を説いても、なかなか、理解してもらえないことが多い。プロジェクトマネジャーにどのような権限を与えているかという質問に対して、こういう答え方をする組織が多い。

プロジェクトマネジメントに関することは全面的に権限委譲している

だから、ガバナンスマネジメントは万全であるという。ところが、実態はまずそうはなっていない。何かあれば、すぐにガバナンスはプロジェクトから組織に戻る。この認識の違いはなぜ、起こるのだろうか？

◆プロジェクト憲章の位置づけ

一つはプロジェクト憲章の位置づけである。プロジェクトとはそもそも目的達成を第一義に、組織の規定（レギュレーショ）を離れて実施するものである。ただし、まったく無法地帯では経営管理上の問題があるので、組織の規定に変わるルール（制約条件）をプロジェクト憲章で定め、それを以ってプロジェクトマネジャーを任命する。つまり、プロジェクトマネジャーを拝命するということは、プロジェクト憲章に書かれているレギュレーションを守ることを意味する。

例えば、組織の規定に「１社１０００万円を超える取引は、口座を開設して行うこと」という規定があったとしよう。口座を開設するためには、なんやかんやで２ヶ月くらいの時間がかかる。これに対して、このプロジェクトでは「ひょっとすると」特殊な技術調達が必要になり、ベンチャー企業との取引が必要になる「かもしれない」とする。すると、プロジェクト憲章では、例えば、制約条件として「取引が１社３０００万円以上になる場合には口座取引とする」という条件を決める。もちろん、最初の１社１０００万円の規定は度返しである。しかし、プロジェクト憲章がこのように使われることはまずない。プロジェクト憲章は組織の規定より強く制約をした場合に使われることが多い。

組織の規定にしたがっていたのではうまく行かないからプロジェクトとして取り組む。しかし、プロジェクトには組織の規定を適用する。これでプロジェクトがうまく行くはずがない。

◆リスクの扱い

もう一つはリスクの扱いである。上の話も実はリスクの議論を含んでいるが、リスク対応策の実施の際に組織の規定が優先される。違う言い方をすると計画は承認するのだが、リスク計画は承認しない。実際にリスクが発生し、そのときに必要な対処の内容によって誰が意思決定するか考えようという取り決めにする。もっといえば、そんなことがあるとややこしいので、計画通りにやれという乱暴な議論をする。

今年度から開始した「プロジェクト計画書」セミナーで、プロジェクト計画書の段階的詳細化の話をすると以下のどちらかの反応が返ってくることが多い。

一つは、プロジェクトの計画段階で最後までの計画を策定して、承認を得ないと前に進めない仕組みになっているという話。もうひとつは、一旦、策定した計画はプロジェクト側に事情で変更できないという話。本質的には同じ話だが、なんとも考えさせられる話だ。

◆権限委譲の正しさをチェックする方法

責任を全うするために必要な権限をといった議論をしだすと話は複雑になるが、実は権限委譲の適切さをチェックする方法はそんなに難しくない。

まず、プロジェクトのリスクに対して、プロジェクトで考えるべきリスクと、組織として考えるべきレベルのリスクに分ける。例えば、取引先の会社が倒産するといったリスクはこれはプロジェクトに大きな影響があってもプロジェクトで考えるべきリスクではない。このようなリスクというのは意外と多い。

その上で、プロジェクトレベルのリスクの対応策を検討する。そして、その対応策に必要な権限を分析する。すべての権限がプロジェクト憲章でプロジェクト（マネジャー）に与えられていれば、権限委譲は適切である。

実際にはプロジェクト憲章を発行する時点では、リスクが見えていないことも少なくない。そのような場合には、組織のレギュレーションで縛るのではなく、最低限、プロジェクトに課したい制約条件だけを決め、後は全面的に権限委譲する、つまり、組織のレギュレーションを無視する権限を与えることが望ましい。例えば、コスト関係でいえば

　・目標とする収益率

だけを決めておき、組織のレギュレーションがどうなっていようと、決済なく支出できるようにする。これが権限委譲である。ここで組織のレギュレーションを生かしていると、例えば、調達でここが安いのでといった組織の不要な介入が入ることになる。これではプロジェクトマネジメントはうまく行かない。

◆ガバナンスマネジメントはＰＭＯの役割

このようなガバナンスのマネジメントを行うには、組織がリスクに対して適切なマネジメントをしていることが不可欠である。組織が不必要にプロジェクトに介入しているのは、組織としてリスクが見えていない、扱いを決めていないといったリスクマネジメント不全が極めて多い。

組織側にたってこのようなリスクマネジメントとガバナンスマネジメントをするのはＰＭＯの役割である。