PMstyleプロデュース

続・プロジェクト監査を理解しよう（2006.7.31）

前回のコラムでは監査の必要な理由と、プロジェクトマネジメントにおける監査の意義を説明した。

　http://people.weblogs.jp/pmstyle/2006/07/post_5080.html

今回は、もう少し、プロジェクト監査について深く考えてみたい。その前に、少し、監査の基本を整理しておく。

◆監査の主体者

監査の定義は前回述べたが、監査には３つの主体がある。監査依頼者、被監査者、および、監査人（監査員）である。前回述べたように、監査の公正さはこの３つが独立し、健全な関係にあった初めて担保される。これらの言葉は以下のように定義される。

　監査依頼者：監査を要請する組織、または人
　被監査者：監査される組織（プロジェクト）
　監査人：監査を行う力量を持った人

◆誰が誰を監査するか

上のような主体があるときに、監査の種類は誰が誰を監査するかで、第一者監査（いわゆる内部監査）、第二者監査、第三者監査に分けることができる。

第一者監査は内部監査を呼ばれるもので、組織内で独立した監査チームが組織の他部門を監査するものである。ビジネスの中で実施されるプロジェクトの監査はほとんど内部監査になる。

第二者監査、第三者監査はいずれも独立した組織が他の独立した組織を監査する。

第二者の場合には発注者が同組織である。例えば、ＳＩのプロジェクトで委任契約先の活動を発注者が監査することがあるが、これは第二者監査である。

第三者監査は依頼者が外部の監査人に依頼して、組織内の被監査者の監査を行うケースである。このようなケースはビジネスの中では珍しいが、公的性格のプロジェクトではよくあるケースだ。

◆何を監査するのか

監査の内容は大雑把にいえば、２つある。

一つ得られたパフォーマンス（実績）が妥当なものかどうかをチェックする監査である。これが前回述べたコンプライアンスの監査であり、定められた基準に合致しているかどうかが問題にされる。当然、合致していない場合には、不適合となる。パフォーマンスでよく問題になるのは、はやり、変更をめぐるものである。

例えば、１５％のスケジュール遅れが発生したら、シニアマネジャーに分析と改善計画を報告するという変更管理ルールを決めていても、結局の正しく実行されないといったケースだ。これは、監査としては比較的分かりやすい。

もう一つはプロジェクトマネジメントシステムが妥当なものであり、それが適切に運営されているかどうかをチェックするものである。

これはシステム監査という呼び方をされることが多い。こちらは若干分かりにくい。システム監査の立場からは、上の問題は必ずしも不適合であるとは断定できない。そのような事実（データ・ログ）が発見された場合、その是正として、バリアンスの大きさに関係なく、１ヶ月に一度、シニアマネジャーに対して報告をするというコミュニケーション計画を追加したとし、この措置によるこの問題は繰り返し起こらないと判断されるので、不適合とは判断されない。逆に、これでもまだ、同じ問題が起こるだろうと判断されれば不適合だと判断される。

◆プロジェクトマネジメントにおける監査の必要性

というインプットの元で、もう一度、プロジェクトマネジメントの監査の必要性について考えてみる。

プロジェクトマネジメントの標準化の最も難しい点は、その標準を導入してもプロジェクトが成功するとは限らないことだ。プロジェクトマネジメントというのは本質的にそのような位置づけにある。プロジェクトの成功を保証するものではないが、やらないよりはやった方がよい。これが基本的な位置づけである。

このような位置づけからすると、パフォーマンス監査は必ずしも重要ではない。むしろ、システム監査を通じて標準の評価とマネジメントの改善をしていく。そこに最も重要な意味があるといえる。

このコラムでは、プロジェクトマネジメント監査については、その必要性を中心に概要を述べた。監査のテクニックについては、別途、本論の中で解説する予定である。

◆関連講座のお知らせ

＜ＰＭＯリーダー養成講座第４回＞

プロジェクト品質を向上させるプロジェクト監査の理論と実際
http://www.pmstyle.biz/smn/audit.htm

プロジェクトマネジメント監査を理解しよう（2006.7.24）

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

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

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

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

◆監査

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

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

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

によると監査は

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

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

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

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

　「利害の対立」

である。

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

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

◆プロジェクト監査とは

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

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

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

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

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

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

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

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

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

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

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

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

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

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

◆関連講座のお知らせ

＜ＰＭＯリーダー養成講座第４回＞

プロジェクト品質を向上させるプロジェクト監査の理論と実際
http://www.pmstyle.biz/smn/audit.htm

プロジェクトマネジメントの成熟とは（2006.7.12）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

◆チームからのビュー

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

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

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

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

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

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

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

◆関連講座のお知らせ

＜ＰＭＯリーダー養成講座第３回＞

ＰＭナレッジマネジメントと組織成熟度の向上
http://www.pmstyle.biz/smn/opm2.htm

正しい権限委譲！？（2006.6.12）

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

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

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

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

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

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

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

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

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

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

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

◆リスクの扱い

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

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

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

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

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

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

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

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

　・目標とする収益率

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

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

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

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

◆セミナーのご案内

ＰＭＯリーダー養成講座のオプションカリキュラムに、組織としてのリスクマネジメントに関するセミナーの設定をしました。

　リスクに強いプロジェクトと組織を作る
　　http://www.pmstyle.biz/smn/pmo_risk.htm

です。ＰＭＯがどのようにリスクマネジメントを指揮し、推進していくかを議論するセミナーです。ぜひ、ご参加ください。

続・ＰＭＯスタッフのスキルとキャリア（2006.6.5）

◆ＰＭＯスタッフのコンピテンシー

前回は、ＰＭＯのスタッフが持つべきコンピテンシーについて述べた。今回はそれをどのように育てるかを議論したい。

現業部門のスタッフというのは非常に難しいものがある。コーポレートスタッフはまさに組織を動かしている人であるが、ＰＭＯに限らず、現業部門のスタッフは支援業務的な色合いが濃い。支援というのは難しい概念である。自分が業務を実行するわけでもない。ラインマネジャーのように指示をして、任せるわけでもない。プロジェクトに対して、組織図の上には出てこない影響を与え続ける必要がある。

前回、重要なものを一つ挙げるとすればリーダーシップだと述べたが、同時に３つのスキルの重要性を指摘した。

一番目は対象業務スキルとしてのプロジェクトマネジメントスキルである。ＰＭＯのコンサルティング領域はいうまでもなくプロジェクトマネジメントであるので、このスキルがないことには前に進めない。

二番目はプロセスマネジメントのスキルである。標準プロセスを定義し、メトリクスを設定し、プロセス改善の指揮をしていく能力である。

三番目はマーケティングスキルである。つまり、プロジェクトやステークホルダがどのようなサービスを必要としているかを分析し、それらの情報に基づいて限られた資源をどのようにサービスに展開していくかを練り上げるマーケティングスキルである。

◆ＰＭの経験は必須！

まず、最初の観点からはＰＭＯ人材には、小さなプロジェクトでよいので、プロジェクトマネジャーの経験をさせることが必要である。ＰＭＯの業務そのものを行うためには、ＰＭＰ程度の基本知識があれば十分だと思われる。

また、実際に、品質管理の専門家などでプロジェクトマネジメントの経験なしにＰＭＯの仕事をしている人も少なくないが、ＰＭＯの支援の中でどれだけ「リアリティ」、「現場感覚」がもてるかはサービスの質を決める重要な要素であるので、経験に越したことはない。

そのように考えると、キャリアとしてプロジェクトマネジメントのキャリアからＰＭＯというのが望ましいと思われる。しかし、世間でよく言われるように、ＰＭＯとプロジェクトマネジャーのダブルキャリアというのは望ましくない。上に述べたように、プロジェクトマネジャーとＰＭＯリーダーの共通点は基本的な知識と認識作りのための経験であり、一定のプロジェクトマネジメント経験ののちには、ＰＭＯとしての専門キャリアを歩んでいくべきである。

◆プロセスマネジメントスキルはトレーニングで

そこで問題になるのが、専門スキルである。これは一言でいえば上に述べたように、プロジェクトマネジメントに対するプロセスマネジメントのスキルである。これはある程度、トレーニングで身についていくと思われる。例えば、実テーマを題材にしたシミュレーション型の研修、ワークショップなどである。ただ、プロセスマネジメントのスキルの中で、論理的に割り切れないスキルがある。それは、人が絡んでくる部分である。

例えば、スケジュール遅れが目立っていれば、当然、生産性に関するメトリクスを入れるが、ここで注意する必要があるのは、メトリクスを入れることによって逆に生産性が下がってしまうことがある。計測負荷といった話ではなく、「やらされ感」が生じ、プロジェクトへの動機を下げてしまい、それが悪影響を及ぼすようなヒューマンファクターである。

このような問題は、トレーニングだけで解消するのは難しい。やはり、業務の中でしっかりと現場をみて、体感して、獲得していくしかないように思われる。

◆プロセスマネジメントスキルを本物にするマーケティングスキル

が、この問題に対するある程度の形式的なアプローチとしてマーケティングがある。闇雲に現場を見るよりは、マーケティングの基本知識を身につけた上で現場に出て、現場の声をマーケティング的な視点から分析していくことが重要だろう。

自分たちの施策をプロジェクトに対して受け入れてもらうためのリーダーシップはこれらの経験によって醸成されていく。同時に、トレーニングによって身に付けることができる部分もある。それはファシリテーションのようなコミュニケーションスキルである。これらに併せて取り組んでいくことが望まれる。

◆関連セミナー

◆関連セミナーのご紹介

　ＰＭＯリーダー養成講座
　　http://www.pmstyle.biz/smn/pmolist.htm

上に述べたようなＰＭＯスタッフに必要なスキルを網羅した講座です。

ＰＭＯスタッフのスキルとキャリア（2006.5.29）

◆ＰＭにはＰＭＯリーダーはできない

先週と２週続きになるが、今週もコラム。今週コラムにしたのは、５月２５日に実施した「事例にみるプロジェクトマネジメントオフィスの役割と機能」のセミナーを受講された方から興味深い質問があったためだ。質問はいろいろな要素があり、質問を戴いた方には別途私信を差し上げた。ここでは質問の中で、もっとも本質だと思った質問について、読者の皆さんと問題意識の共有、あるいは、意見交換をできればと思っている。その質問とは

当社では、ＰＭＯリーダーやＰＭＯスタッフは、プロジェクトマネジャーをできる人ならできると考えているが、その考えは正しいと思うか？

という質問である。

結論から書こう。できない。

最近、ＰＭＯへの関心が高まり、コンサルティングの中でもよくこの質問が出るようになってきた。そのように思う理由はよく分かるし、また、逆に、ＰＭＯスタッフはプロジェクトマネジャーの経験者でないと聞かれると（ここは考え方に温度差があると思うが）、そうだといいたい。しかし、プロジェクトマネジャーの経験だけで、ＰＭＯスタッフをやるというのは、「ＰＭＯ＝トラブル時の対応要員」という発想に近い。

◆メンターに対する誤解

同じことはメンターにも言える。（少なくともメンターを本来的意味で捉えるなら）プロジェクトマネジャーとして優秀な人をＰＭメンターとしておけば大丈夫だろうという発想は正しくない。これはメンターというと分かりにくいが、優秀なエンジニアが必ずしも人を育てたり、うまくアドバイスしたりすることができるとは限らないことを考えると当たり前である。アドバイスしたり、仕事の中で人を育てる部分のスキルが「メンタリング」としての成果に直結することは言うまでもない。

◆ラグビーに例えると

ＰＭＯリーダーやスタッフの場合も同じ構図だ。上で「ＰＭＯ要員＝トラブル時の対応要員」だと書いたが、逆にこのケースがもっともよく分かる。ラグビーをご存知の人はよく分かると思うが、スクラムハーフというポジションがある。スクラムからボールを取り出し、バックスに展開する起点になるポジションだ。ボールの奪い合いをするときに、スクラムハーフがフォワード陣のモールやラック（ボールをめぐる密集・奪い合い）に巻き込まれたら、そのチームは機能しなくなる。スクラムハーフは密集になるとすぐにボールを渡し、密集の外に出ておく必要がある。

トラブルのときにＰＭＯというのはスクラムハーフのような役割をしている。フォワードをまとめていくナンバー８がプロジェクトマネジャー。フォワード全体はプロジェクトチームである。バックスはそのトラブルを解決するためのソリューションを持っている専門的なスタッフである。スクラムハーフが自らが密集に巻き込まれたら、フォワードの選択肢は狭まる。自らがボールを持って前進していくしかなくなるからだ。つまり、トラブルに対応するためには、ＰＭＯリーダーにはプロジェクトマネジャーとは別の役割が求められるし、そのためには「リカバリーマネジメント」のスキルが必要だ。

◆ＰＭＯスタッフの専門性

トラブル以外の局面でも同じである。ＰＭＯの仕事の中で極めて専門性が高いものは

　・標準化（展開）
　・プロセス設計
　・メトリクス設計
　・ツール（テンプレート類）設計
　・監査技術
　・トレーニング設計
　・ポートフォリオ

などであるが、ＰＭＯのスタッフはプロジェクトマネジメントのスキルとともに、これらの専門性を持つ必要がある（もちろん、ＰＭＯ組織としての担当が決まっているので、すべて必要ではないかもしれないが）。

◆マーケティングスキルがないとＰＭＯは務まらない

さらに、重要なことは、ＰＭＯの仕事の中で、マーケティングの仕事が非常に重要性があることである。日本の企業でＰＭＯがマーケティング的アプローチで、標準を決定したり、提供サービスを決めている例を見たことがないが、米国ではＰＭＯ自体のアウトソーシングサービスが発展しており、常識になっている。また、日本の企業においても、総務などではすでにそのようなアプローチをしている企業がある。そのようなセンスをもった人材を育成することも求められるだろう。

逆にこのような専門性を持たないＰＭＯスタッフがプロジェクトを支援するのであれば、プロジェクトマネジメントチームの１メンバーの役割しか果たせない。もちろん、それでもよいという考え方もあるが、ＰＭＯがない組織のプロジェクトマネジメント力は低くなる。

◆何よりも重要なリーダーシップ

加えて、ＰＭＯリーダーにはプロジェクトマネジャーとは少し異なるリーダーシップが必要である。ＰＭＯリーダーのリーダーシップはプロジェクトを引っ張るリーダーシップではなく、組織に対して、自らの提供する標準プロセス、手法、ツール、サービスなどを活用させるための影響を与えるリーダーシップである。日本企業のＰＭＯに何が最もかけているかといわれれば、やはりリーダーシップだと思う。

同時に、リーダーシップを発揮する手段として、ファシリテーションのスキルも必要になる。

ＰＭＯリーダー（スタッフ）はこのように広範なスキルを備える必要がある。

次の問題は、では、どのように育てていくかというキャリア形成の問題だが、長くなったので、来週。

◆関連セミナーのご紹介

　ＰＭＯリーダー養成講座
　　http://www.pmstyle.biz/smn/pmolist.htm

上に述べたようなＰＭＯスタッフに必要なスキルを網羅した講座です。

また、リーダーシップファシリテーションについてもオプションで準備しています。

●ＰＭファシリテーション
　　http://www.pmstyle.biz/smn/facilitation.htm

ＰＭＯの本質（2006.5.22）

◆ＰＭＯハンドブック

ＰＭＣｏＥ戦略ノートも９回になった。今週は一休みで、ＰＭＯコラム。

ＰＭＯについては、米国では

Gerard M. Hill「The Complete Project Management Office Handbook」
http://people.weblogs.jp/books/2005/06/the_complete_pr.html

という本が出版されている。

この本、２００３年の後半に出版された本であるが、なんと６２４ページもある大作である。ＰＭＯに関する議論が始まったのは１９７０年台であるので、ＰＭＯに関するほぼ３０年間の集大成がこの本にまとめられているというわけである。

もちろん、弊社がプロジェクトマネジメントオフィスの機能体系をまとめる際にもこの本は参考にさせて戴いている。

◆ＰＭの系譜

プロジェクトマネジメントには、おそらく３つくらいの発展の系譜がある。

一つはエンジニアリングからの流れである。これは、品質管理などの分野からの発展である。二つ目はオペレーションマネジメントからの発展の流れがある。これは生産管理などからの発展である。この２つは一般的に認識されているが、意外と認識されていないもう一つの系譜があるのではないかと思う。それは（組織）マネジメントからの発展である。成果物が複雑になればなるほど、エンジニアリング的な扱い方が難しくなり、マネジアルアプローチの方が有効になってくる。

これらは視点の違いであり、どの道から上ろうと頂上は同じであるといいたいところであるが、そうはいえない部分がある。価値観の違いはずっと残るように感じている。そこで、どの立場をとるかという話になるのだが、著者はマネジアルアプローチがもっとも効果的だと思っている。そして、マネジアルアプローチからはＰＭＯの強化というのがまず考えられる。

◆ＰＭＢＯＫよりＰＭＯ

その意味で、著者はプロジェクトマネジメントを強化したいのであれば、ＰＭＢＯＫのようなプロセスの導入ではなく、まず、ＰＭＯを強化すべきだと思っている。その意味で、このハンドブックは非常に貴重な本だと思う。

ただ、このハンドブックは機能について述べたものであるが、これだけでＰＭＯが語れるかという議論がありそうだ。プロジェクトマネジメントでも、知識と行動のギャップというのがあるように、ＰＭＯの活動にも知識と行動のギャップがある。

◆ＰＭＯの本質

このギャップを埋めるものは

　リーダーシップと支援スキル

であると思われる。これが、ＰＭＯの本質ではないかと思う。このような本質を持って、初めて標準化の活動や、監査活動が意味を持ってくる。

ＰＭＯのリーダーシップは、プロジェクトマネジメントに対するルールや価値観を組織に導入し、それを学習し、組織における「基本的仮定」になるように昇華させていく源泉になるものである。

もう一つは支援スキルである。組織にプロジェクトマネジメントを定着させ、それを発展させていくためには、必ず、支援が必要になる。支援は指導ではない。

指導はプロジェクトマネジャーやプロジェクトチームの意思決定そのものに対して介入し、その意思決定を正していく行動である。

   これに対して支援は、プロジェクトマネジャー、あるいはプロジェクトチームのプロセスに介入し、プロセスを正しい方向に導くことによってプロジェクトマネジメントやプロジェクトをよい方向に導いていくのが支援である。プロセスコンサルテーション、あるいは、今流にいえば、ファシリテーションのスキルである。

この２つの要素を兼ね備えないとＰＭＯはプロジェクトからあまり意識されないお目付け役になる。あるいは上位組織の傀儡のような存在になってしまう。それではその組織のプロジェクトマネジメントは進歩しないだろう。

◆関連セミナーのご紹介

　ＰＭＯリーダー養成講座
　　http://www.pmstyle.biz/smn/pmolist.htm

上に述べたようなＰＭファシリテーションに興味のある方は、ぜひ、ご参加ください！
詳細、お申し込みはこちらです。

ＰＭＯでＰＭ推進（2006.4.10）

◆ＰＭＩＴのＰＭＯセミナーに参加してきました

４月８日にＰＭＩ東京で、

　ＩＴプロジェクト管理者のためのわかりやすいＰＭＯセミナー

に参加した。

「プロジェクトマネジメントオフィスツールキット」
　http://people.weblogs.jp/books/2006/04/post_0ccf.html

という本を東京支部の翻訳委員会で翻訳し、出版した記念セミナーだったが、最初の瀬尾会長の話によると、２日間で８０人が満席になったとのこと。懇親会のときに事務局の田中さんに聞いた話だと、最初はＰＤＵ獲得のためだと思っていたら、締め切っても、問い合わせが絶えず、次回の問い合わせまであったというのでブームだと驚かれていた。

◆ＰＭＯの設置状況

その瀬尾会長の講演の中に、昨年、法人スポンサー会議で２６社にアンケートをとったところ、まず、設置状況については以下のようなものだったそうだ。

＜１＞ＰＭＯ設置状況
　設置済み　　　　　　５０％
　１年以内に設置予定　　４％
　必要性があるが未定　１９％
　予定なし　　　　　　１５％
　そのほか　　　　　　１２％

半分の企業にすでにＰＭＯを設置しているというのは、ＩＴ系が中心だとしても結構な割合である。思ったよりもはるかに多かった。次に、ＰＭＯの要員数だが、計画中のものも含めて

＜２＞ＰＭＯ部門人数
　９人以下　　　　　　７６％
　１９～４９人　　　　１９％
　５０～９９人　　　　　０％
　１００人以上　　　　　５％

という結果だったそうだ。

さらに、ＰＭＯの担当すべき業務のベスト３は

　大規模案件のフォロー
　ＰＭシステム充実
　ＰＭ育成

の３つである。この３つはリカバリー（火消し）、標準化、人材育成の３つで、いわゆるＰＭＯの３点セットで、それが顕著に出ているわけだ。

さて、このセミナーでは、ＮＥＣさん、ユニシスさんのＰＭＯへの取り組みの事例の紹介の後で、書籍の内容に基づいて、永地さん、諸藤さん、永谷さんの３名で、ＰＭＯの設置、プロジェクトマネジメントの支援、プロジェクトマネジャーの人事政策について解説があった。この本は、なかなか、興味深い本である。

◆ＰＭの導入パターン

  実際には、プロジェクトマネジメントの導入のパターンというのはいくつかある。

一つは、人材を育成し、その人材の活動に託することである。つまり、プロジェクトマネジメントを知っている人材を育成し、その人がプロジェクトマネジメントを実行することによって組織にプロジェクトマネジメントが導入されていく。この方法は、エンジニアなどの専門職にプロジェクトマネジメントを担当させるやり方として適している。この際、スキルを付与する手法が標準であれば、ある程度、組織としての標準的なマネジメントも実現できる。少なくともこれまでは、中心的な方法であったし、これからも一定の割合で必ず残っていく方法だといえよう。

二つ目は、プロジェクトマネジメントの導入を指揮する組織をつくり、その組織が中心になってプロジェクトマネジメントを導入していくことである。この場合、人材の育成も行うが、プロセスの標準化やツールの整備が中心になる。これがＰＭＯを設置してプロジェクトマネジメントの普及を図っていくパターンである。このパターンは、組織プロセスがしっかりとしている企業がプロジェクトマネジメントの導入をする場合に適しており、最近、ＰＭ導入の動きが活発になってきた製造業ではこのパターンが増えている。今回のＰＭＩＴのセミナーが盛況であったのもそのような同様の背景によるものと思われる。

三つ目は、日本ではあまり注目されてこなかったが、リーダー育成のプログラムの中にプロジェクトマネジメントを含めて、プロジェクトマネジメントを行うことのできる「マネジャー」を育成するという方法がある。これはある意味で、一番目の方法と対象的である。実際に、日本のＭＢＡコースでプロジェクトマネジメントのカリキュラムがあるという話は聞いたことがないが、欧米ではＭＢＡコースには必ずといってよいくらい、プロジェクトマネジメントのカリキュラムがあるし、また、

　戦略的エンタープライズプロジェクトマネジメント
　　http://people.weblogs.jp/books/2005/12/post_ebe9.html

といった優れたテキストもある。これからは日本もこのアプローチは考えていかなくてはならないだろう。この連載の中で、ラインマネジャー（組織マネジャー）の役割というのにこだわっているのもこのあたりに一つの理由がある。

ということで、今週は軽めの話題でした。また、来週。

◆関連セミナーのご紹介

　ＰＭＯリーダー養成講座
　　http://www.pmstyle.biz/smn/pmolist.htm

上に述べたようなＰＭＯスタッフに必要なスキルを網羅した講座です。

また、リーダーシップファシリテーションについてもオプションで準備しています。