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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

◆チームからのビュー

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

◆リスクの扱い

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

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

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

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

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

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

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

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

　・目標とする収益率

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

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

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

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

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

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

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

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

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

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

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

◆ＰＭの経験は必須！

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

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

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

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

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

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

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

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

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

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

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

このコラムは、２００６年５月２５日に実施した「事例にみるプロジェクトマネジメントオフィスの役割と機能」のセミナーを受講された方から興味深い質問に答えたものだ。

質問はいろいろな要素があり、質問を戴いた方には別途私信を差し上げた。ここでは質問の中で、もっとも本質だと思った質問について、読者の皆さんと問題意識の共有、あるいは、意見交換をできればと思っている。その質問とは

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

という質問である。

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

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

◆メンターに対する誤解

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

◆ラグビーに例えると

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

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

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

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

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

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

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

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

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

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

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

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

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

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

◆ＰＭＯハンドブック

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

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

Gerard M. Hill「The Complete Project Management Office Handbook」
https://mat.lekumo.biz/books/2005/06/the_complete_pr.html

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

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

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

◆ＰＭの系譜

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

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

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

◆ＰＭＢＯＫよりＰＭＯ

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

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

◆ＰＭＯの本質

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

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

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

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

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

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

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

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

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

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

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

に参加した。

「プロジェクトマネジメントオフィスツールキット」
　https://mat.lekumo.biz/books/2006/04/post_0ccf.html

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

◆ＰＭＯの設置状況

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

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

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

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

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

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

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

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

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

◆ＰＭの導入パターン

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

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

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

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

　戦略的エンタープライズプロジェクトマネジメント
　　https://mat.lekumo.biz/books/2005/12/post_ebe9.html

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