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

◆プロジェクト評価は必要ない

プロジェクトの評価の議論をするときに、常に、行き当たるのがこの問題。ちょっと脱線するが、コラムとしてこの問題を考えてみたい。

日本人は古くから猫に額といわれる田んぼで、血のにじむような努力をし、生産性を向上し、収穫を得てきた。これによりいろいろな価値観が生まれてきた。一粒の米も粗末にしない、失敗は許されない、諦めない、周囲の田んぼと仲良くして迷惑をかけない、ものごとをあいまいにしておく、など。政策的にこのような価値観が推奨された節もある。

このような価値観は日本人のビジネス観にも根強く残っている。敗戦で一から出直したときにもこの価値観は生き延びた。このような価値観というのは、努力が確実に報われる環境下では悪いことではない。というより、とても効率的なやり方である。戦後の高度成長はその証だといってもよいだろう。田んぼのメタファでは、どんどん、新しい土地を切り開いて、田んぼに変えて行くことのできる間は努力は報われる。

この状況で各田んぼ（プロジェクト）の評価をしようとすると何が起るか？評価する必要はないという結論に行き着く。収穫を増やそうと思えばいくらでも田んぼの開墾の余地はある。みんな頑張っている。何で評価をする必要があるのか？ということになる。

◆プロジェクト評価より大切なものがある

ところが、もう開墾する土地がないとなると話は変わる。努力しても報われるという保証はない。というより、努力するだけでは報われない。そこで、まず、成果主義だと言い出す。つまり、努力をするだけではだめで、成果が出たものに報いようという発想だ。ただし、もう新たに開墾する土地がない、生産性もあがる見込みがないという閉塞的な状況で成果主義を持ち出しても尻すぼみになるだけだ。

この状況でプロジェクトの評価をすると、何が起るか。これ以上トータルの収穫が増えない中で、成果をあげる方法はひとつ。失敗しないことだ。つまり、失敗の可能性が少ないほど、よいプロジェクトだということになる。

しかし、この期に及んでも、まだ、努力は美しいという小学校の道徳で学んだ価値観が捨てられない。成果のある努力のみが美しいとはあまり思われない。従って、失敗しないプロジェクトがよいのだが、失敗すればそのときにはみんなで考えようということになる。結果として、やはり、評価には本腰が入らない。

◆拾うための評価ではなく、捨てるための評価

このように評価ができない根源は、捨てるものがないということにある。要するに、分けられる間は分けようという発想が強く根付いている。国土の広さの制約で、捨てて、大きくとるということができなかった。これがいまだに尾を引いている感がある。

多くの事業領域で感じるのは、これからは捨てないと成長できないだろうということだ。グローバル化というのはある意味で捨てることである。国内で自社のコンピタンスに合わない事業を捨て、海外に市場や人材を求める。成長神話の発想で、まずは国内制覇。それが実現できれば海外進出などと考えていると捨てることもできないし、グローバルな事業もできない。京都には戦後、急速に成長したベンチャーがいくつかあるが、共通した特徴は国内とグローバルの展開を最初から分けていないことだ。従って、評価と選択が極めて重要であり、それに成功した企業が成長している。

戦略経営とは何をやるかではなく、何をやらないかと決めることだとよく言言われる。プロジェクトを評価する際に、「実施する」プロジェクトを決めるためだと考える人が多い。この考えの背後には、別段問題なければ、捨てる必要はないという思いがある。最近注目の「もったいない」である。しかし、一方で、慢性的な人手不足に悩む企業も多い。

二つを考え合わせると、はやり、プロジェクト評価は捨てるために行うと考えた方がよい。そうすることによって、今まで見えなかったリスクが見えてくることも多々あるように思う。

◆優先順位のマネジメントはプロジェクトの要

戦略マネジメントとは優先順位付けであるといってもよい。戦略の実行手段であるプロジェクトマネジメントの中では優先順位のマネジメントは特別な意味を持っている。

プロジェクトにおける優先順位はさまざまな要因で決まってくる。一つのプロジェクトの中でいえば、クリティカルパスにある作業は他のタスクに優先される。

プロジェクトのメンバーが専従ではなく、複数のプロジェクトに参画している場合は、プロジェクトの優先順位が問題になるケースがある。例えば、Ａさんが行っている仕事が双方のプロジェクトでクリティカルパスにあり、他人を以って変えがたい仕事である。すると、全体のスケジュールが遅れること、あるいは、それ以降でスケジュールを調整しなくてはならないことを覚悟してその人の仕事の優先順位をつけなくてはならない。その際に問題になるのは、プロジェクト同士の優先順位である。優先順位の高いプロジェクトのＡさんの仕事を優先する。

もう少し経営側に目を向けると、どのプロジェクトを実施するかという問題もある。これも一種の優先順位である。

つまり、あるプロジェクトの中でコンフリクトを解消するためには、いくつかのレベルの優先順位を考えていく必要がある。逆にいえば、いくら一つのプロジェクトの中で最適の意思決定をしたと思っていても、それが結果として、そのプロジェクトの失敗につながるケースは少なくない。

◆優先順位を考えずに失敗しているオフショア開発プロジェクト

最近、このようなパターンをよく耳にするケースはＳＩにおけるオフシェア開発である。人材が確保でいないのでオフショア開発に踏み切る。オフショアという解決策が本当に問題解決になるかどうかという根本的な議論はあると思うが、それはさておいて、オフショア開発を考える際に、まず、他のプロジェクトでとは考えない。決め撃ちである。オフショア開発の意義をどこにおくかにもよるが、リソースマネジメントにおくのであれば、リスクがあまりにも大きいにも関わらず、決め撃ちでオフショア開発をするのは無謀である。事業部なり、部門なりで、抱えているプロジェクトを抱えてプロジェクトを眺めてみて、プロジェクトの優先順位を分析し、リスクをとれるプロジェクトをオフショアとして、原因になったプロジェクトはオフショアのプロジェクトからのリソースをまわすという選択もある。

このような意思決定の根拠になるのは、プロジェクトの優先順位である。

◆「優先順位などつけれない」は本当か

ここで、最近、よく耳にする誤解を指摘しておく。ＳＩ企業の人からよく聞く話だが、

「実施しているプロジェクトはすべて受注したプロジェクトなので、優先順位という考え方はなじまない。すべてのプロジェクトを、納期の早いものから、同じ品質で収めるのが我々の任務である」

一見、正しい。ただし、「リスクがなければ」である。優先順位付けというのはそもそも何のために行うのかをよく理解しておく必要がある。リスクマネジメントである。プロジェクトリスクがある限り、論理的に準備したリソースですべてのプロジェクトに対応できるとしても、現実にできるという保証はない。ましては、３件に１件は納期遅れプロジェクトがあるといわれる業界である。原因はいろいろあるとしても３件に１件のプロジェクトは納期に遅れる。そもそも、上のような理屈など成り立たないのだ。プロジェクトをやめるという選択肢はないとしても、このプロジェクトではお客にないてもらうという選択肢はあるのだ（もちろん、おおっぴらにはいえないので、公式には上のようなコメントになるのだろうが、もし、真剣に言っているとすれば怖いものがある）。

ここで考えておくべきことは、プロジェクトの優先順位をマネジメントすることによって、確実に初期の計画通りに終わらないとならないプロジェクトは確実に終わることができることだ。これが戦略的なプロジェクト実行である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

◆ＰＭＯの３つの活動

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

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

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

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

◆ＰＭＯの３つのタイプ

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

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

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

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

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

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

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

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

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

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

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

◆ＰＭＯブーム到来！？

９月２９日に第２期のＰＭＯリーダー養成講座の説明会を行った。１週間前にすでに５０名になり、好評だった。今回は講演をマイクロソフトの浦さんに、プロジェクトマネジメントの導入をテーマにお願いした。PMstyleでもそろそろ、ツール（ＰＭＩＳ：プロジェクトマネジメント情報システム）の問題と正面から取り組もうと思っており、どんな切り口がいいかを探る意味があったが、こられた方の関心は、はやり、ＰＭＯの立上げとか、成長にあるようだった。

ちなみに、同じ日の夕方、ＰＭＩ東京支部の例会で、三菱総研の方がＰＭＯの話をされるということで参加したが、こちらも盛況で、ＰＭＯに対する関心はどんどん高くなっていることを実感した。

このセミナーでも簡単に問題提起をしたのだが、実際問題として、ＰＭＯにはどんな問題があるのだろうか？あるいは、ＰＭＯを作ったときにうまく機能するにはどのような問題をクリアしなくてはならないのだろうか？この問題はさまざまな観点があるのだとは思うが、今、もっとも痛切に感じているのは、人の問題である。また、企業から聞く話の中でもやはり、人の問題が大きいようだ。

◆ＰＭの標準化は賽の河原で石を積むような仕事？

先日、こんな相談を受けた。３年くらい前から、ＰＭＯを作ってＰＭＢＯＫ流の定着を図っているのだが、なかなか、成果がでない。コンサルも使っているが、コンサルの分析は仕組みやプロジェクトマネジャーの問題点の指摘が多い。確かに指摘としては正鵠を得ているので順に取り組んでいるのだが、あまり、成果には結びつかない。「賽の河原で石を積んでいるような思いだ」とも言われていた。

この企業はコンサルタントを入れているので、方法論を作るところにはあまり問題がないのだと思うが、よく見かけるＰＭＯの活動の問題で以下のような問題がある。

標準や制度を作っても実行されない
プロジェクトガバナンスのマネジメントができない
プロジェクトに影響を与えられない
プロジェクト実施環境に応じて、ＰＭＯが変容できない

この中でもっとも基本的な問題はやはり、最初の「標準や制度を作っても実行されない」という問題である。最近、ＰＭＯの権限という話をよく聞く。ＰＭＯが権限を持ち、現場に出るといろいろな問題が解決するという話はある意味で幻想である。そんな活動をするＰＭＯを作るのであれば、プロジェクトマネジャーの強化をするだろうし、そもそも、そんなことができないから、プロジェクトマネジメントに対する支援の必要性が訴えられているのだ。

◆ＰＭＯの切り口での支援をするＰＭＯリーダー

その意味で、ＰＭＯはＰＭＯとしての切り口で支援を行わなくてはならない。そのためには、まずは、標準や制度を実行性のあるものにすることだ。

ここで再び、ＰＭＯの権限というのが登場してくる。ＰＭＯに権限を与えると、標準や制度を実行させることができると考える。これも幻想だ。プロジェクトマネジャーが標準や制度を実行することでプロジェクトの結果責任から逃れられるのであれば、確かに、考えるプロジェクトマネジャーはいるような気がする。しかし、最終的には、やはり、そういう理由では実行しないだろう。

プロジェクトマネジャーが標準や制度を実行する「唯一の理由」はその標準を使えばプロジェクトが成功すると思うことである。ここでまた水掛論になる。ＰＭＯが他の成功したプロジェクトや識者の意見を取り入れて開発した標準を、「一介のＰＭ」が無視するのは如何なものか？

これでは良い商品を作ったのに買ってくれないと顧客のレベルを非難している企業と同じだ。ＰＭＯにとってプロジェクトマネジャーはコントロールの対象ではなく、顧客である。そのような対応ができるのが、われわれが提唱しているＰＭＯリーダーである。そうあってほしいと思っている。

◆ＰＭブームからＰＭＯブームへ

プロジェクトマネジメントのブームが沈静化し、地に足を据えた取り組みをする企業が増えてきたなと思ったのもつかの間、なんやら、ＰＭＯブームのような状況になってきた。プロジェクトマネジメントブームもＰＭＯブームも根っこは同じだ。プロジェクトマネジメントがうまく行かないことにある。

話は変わるが、ＰＭＡＪのＰ２Ｍの改訂に関わることになった。その入り口で、Ｐ２Ｍがどうすれば売れるかという議論があり、なかなか、興味深かった。Ｐ２Ｍはプロジェクトマネジメントとプログラムマネジメントの標準であるが、はやり、企業の多くはプログラムマネジメントではなく、プロジェクトマネジメントをきちんとやることを望んでいるという。

この感覚は僕がコンサルティングの現場で感じている感覚に近い。付け加えれば、かなりの人は、プロジェクトで起こっている問題の原因の多くがプログラムの問題であると気がついているにも関わらず、やはり、それをプロジェクトマネジメントの範囲で何とかしようする。これは単に職務権限の問題なのかもしれないが、深刻な問題であることは間違いない。

◆ＰＭＯに注目すれば何が変わるのか？

では、ＰＭＯに注目すれば何がどう変わるのか？ＰＭＯを強化するとプロジェクトマネジメントがうまく行き、プロジェクトが成功するのか？残念ながら、そうはならないだろう。その理由を説明する前に、なぜ、こういう発想になるのかを考えておきたい。

一般的に、人が問題解決を行う場合には、例外なく自分（の役割と実績）がきちんとできているという前提で進めていく。プロジェクトマネジメントの問題であれば、まずはプロジェクトマネジャーをなんとかしなくてはならないという話になる。ここで何らかの施策を行い、これ以上成果がでない、あるいは、十分に成果が出なかったという認識をすると次のフェーズに移る。これが現在の状況で、ここで、ＰＭＯが注目された。ＰＭＯを作ればなんとかなると思う人が多い。

ＰＭＯを作ること自体は無駄なことではないが、これは優先順位が違う。プロジェクトチームにはもう一つ、内部のロールがある。戦略ノートの４回あたりで述べたプロジェクトスポンサーである。

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

◆課題解決型のＰＭＯの設立を目指す

一通り、プロジェクトマネジメントの導入を行って、さらに、次に進もうとしたときに、まず、行うべきことは、プロジェクトが成功させるためにはプロジェクトスポンサーが何をすればよいかを真剣に考えることである。その中に、ＰＭＯを作るという話が出てくる。ただし、何でもいいからＰＭＯを作るということではない。プロジェクトスポンサー（多くの場合、プログラムマネジャーである）が複数のプロジェクトのマネジメントを見ていく中で、もう一つの顔である組織マネジャーの一人という立場でみて、プロジェクト単体でやるのではなく組織として取り組んだ方がよい課題が出てきたときに、ＰＭＯを作るという選択が出てくる。

実は、プロジェクトマネジメントの導入というのは本来はこの文脈で出てくるものだ。プロジェクトスポンサーがプロジェクトマネジメントの導入の必要性を感じ、それを組織マネジャーの立場でＰＭＯを作り、展開していったケースが多い。

そのように考えると、ＰＭＯにどのような機能を持たせるかを他社がどうだといった理由で分析してみてもほとんど意味がない。考えるべきことは、自社のプロジェクトマネジメントの問題を分析し、それに併せて、ＰＭＯの機能を設計することだ。

◆ＰＭＯの設立は毒になるケースがあるので要注意！

ここで警告しておきたいことがある。プロジェクトマネジメントの導入というのはなんやかんやと言っても薬になっても毒になるケースはあまり見たことがない（導入のアクティビティが混乱して毒になったケースはいくつか知っているが）。しかし、ＰＭＯの導入は下手をするとプロジェクトガバナンスを混乱させ、毒になるケースがあるので注意を要する。

◆フェーズマネジメントによる不確実性への対処

ＰＭＢＯＫをよくご存知の方なら、フェーズという概念があることはご承知の通りだろう。例の立ち上げ、計画、実行、統制、終結というプロジェクトマネジメントライフサイクルはフェーズに 対するものである。したがって、一般的には一つのプロジェクトにおいては複数のフェーズが存在し、フェーズを実行する中で次のフェーズにおける不確実さを拭い去っていき、状況を（前提条件、制約条件など）を明確にし、徐々に進めていくことになる。

逆にいえば、プロジェクトの最初の段階でゴールまでの計画ができるものにはプロジェクトマネジメント的手法はあまり必要ないともいえる。

◆商品開発プロジェクトにおけるフェーズ

例えば、商品開発のプロジェクトを例にとれば、最低２つはフェーズが存在する。一つは商品企画である。戦略上（経営上）の課題から開発する商品のコンセプトや機能仕様を明確にする。企画フェーズ開始の段階では、どのような商品を作るかはぼんやりしている。企画フェーズを通じて、だんだん、それを明確にしていく。明確になったものを次のフェーズである商品開発フェーズに渡す。

商品開発フェーズでは、企画フェーズからきたコンセプトや機能仕様を実現する商品を設計し、開発をする。開発フェーズの最初の段階では、実装仕様も決まっていないが、設計作業を通じてそれをだんだん明確にしていき、設計が終われば試作やフィールドテストを行い、企画フェーズで決められたコンセプトや機能仕様を満足しているかどうかを確認する。

商品企画から商品開発に進む際に、技術的な裏づけができていないケースがある。この場合ような場合、企画の後、あるいは、企画と並行して技術検証（技術開発）フェーズを設けることが多い。

ＳＩでいえば、要件定義　→　基本設計　→　詳細設計・開発といったフェーズを設定することが多いが、意図するところは商品開発を同じである。

◆フェーズマネジメントの限界とプログラムマネジメント

フェーズマネジメントの考え方は製品開発マネジメントの基本であるが、ここでやっかいなことがある。それはフェーズというのは（ＩＴ系の用語でいえば）ウォーターフォールを前提にしている点だ。上の商品開発でいえば、企画フェーズが終わって、その成果をインプットとして開発フェーズに渡し、開発フェーズに渡し、開発フェーズの作業を始めるという点である。このようなやり方は長時間かけて、じっくりと商品開発を行う際にはあまり問題にならないが、短期間で開発する、あるいは、商品への戦略的ニーズそのものが比較的に短期間に変化するようなケースは難しい。このようなケースでは、商品開発によるベネフィットの維持が最大の課題になる。企画フェーズである程度、設計との調整を取りながら進めていくことが要求されるし、開発中もある程度企画変更に対応しながら進めていくことが要求される。

この問題を解決するためのポイントは、各プロジェクトを独立にマネジメント（decentraized management）することである。この独立性を保証しないと、設計やデザイン、あるいは、技術的な制約に必要以上に引っ張られる。

その上で、各プロジェクトの目標を一段上から調整していくことにより、全体のベネフィットを最適化する必要がある。

例えば、ある電子商品を開発している最中に小型化のブームがやってきた。当然、デザインからは小型化という付加的な要求が持ち上がる。しかし、小型化をすればコストが上がるし、また、開発要素があり、発売時期そのものに影響がでそうだ。

ここで開発はデザインされたものを実現するといった関係をつけてしまうと、最適な判断をするのは難しくなる。おおかた、市場やユーザをたてにしたデザインの主張に引っ張られる。いくらユーザが受け入れても、競合に先を越されては意味がない、価格が高ければ売れないなどの問題が出てくる。このあたりをトータルで考えるためには、市場、ユーザ受容性、コストなどをトータルで考えて、その意思決定を各プロジェクトの目標に落とし込む必要がある。

このようなケースに、検討に値するのが、プログラムマネジメントの適用である。一つのプロジェクトをサブプロジェクトに分解し、独立したプロジェクトとしてプロジェクト間の調整を取りながら進めていく。このようなマネジメント手法が有効である。

また、これにより、技術開発のような複数のプロジェクトにまたがるプロジェクトは全体最適を考慮した進行が可能になる。その意味でも、意味がある。

◆ＩＴにおけるプログラムマネジメントの適用事例

最近は企業統合が珍しくなくなっている。この際、たいてい問題になるのが、情報システムの統合である。例えば、東京三菱とＵＦＪの経営統合ではまさに、情報システムの統合スケジュールが問題になり、監督官庁も絡んで経営統合のスケジュールそのものが二転三転したのは記憶に新しい。

この例からも分かるように、規模の大きなプロジェクトの情報システムを統合しようとすれば、数十の情報システムを統合しなくてはならないことは珍しくない。このようなときに、これを一つのプロジェクトとして行うと２～３年では到底完了しないだろう。それゆえに、このようなプロジェクトでは、全体をプログラムとして管理し、プログラムマネジメントを実施するのが当たり前になっている。

◆リードタイムの短縮を実現するプログラムマネジメント

このような話は、決して、経営統合の際の情報システムに限ったことではない。ライフサイクルがどんどん短くなっている最近のビジネスでは、工法やプロセスの工夫では思ったようなリードタイムの短縮ができず、課題をプログラムとして捉え、並列的に実行することにより、リードタイムの短縮を図ることは珍しくなくなってきた。

製品開発の世界では、従来よりコンカレントエンジニアリングという手法でリードタイムの短縮を図ってきた。コンカレントエンジニアリングは企画・開発から販売・廃棄にいたる製品ライフサイクルの全フェイズに関連する部門が、製品の企画や開発、設計などの段階に参加・協働し、同時にプロセスを進めていく開発手法である。これもある製品を開発するという一つのプロジェクトであるが、プログラムとして扱い、マネジメントを行っている。

◆プログラムマネジメントと分散マネジメント

企業の戦略があって、その戦略を実行するためにどのような課題があるかが決まる（戦略課題）。この戦略課題を実際のアクションに落とすものがプログラムであり、プロジェクトのコントロールの対象は戦略に対するベネフィットになる。そして、ベネフィットを最適化するために、複数のプロジェクトをデザインし、実行していく。

これが、Ｐ２Ｍなどで言われているプログラムのイメージであるが、プログラムはこのような形だけではなく、上のような形態が増えている。一方で、プログラムにすればスムーズに進むプロジェクトを強引にプロジェクトとして実行しようとして失敗している事例も目立つ。

ＳＩプロジェクトでは何らかの形で並列開発をすることが多くなっているが、これをプロジェクトをみなして開発すると必ずといってよいくらい失敗している。スケジュール的に無理があり、タイムマネジメント、リソースマネジメントが破綻をきたしている。このようなケースはプログラムとしてマネジメントしていかないとうまく行かない。

その意味で、プログラムマネジメントはプロジェクトマネジャーにとっても現実的で重なマネジメント手法になってきている。大規模、納期の厳しいプロジェクトをマネジメントしなくてはならないプロジェクトマネジャーにとっては必須スキルだといってもよいだろう。

それだけではない。プログラムマネジメントはプロジェクトの分散型マネジメントという非常に興味深い枠組みも提供する。これについては次回！

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

　https://mat.lekumo.biz/pmstyle/2006/07/post_5080.html

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

◆監査の主体者

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

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

◆誰が誰を監査するか

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

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

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

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

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

◆何を監査するのか

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

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

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

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

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

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

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

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

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

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

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

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

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

◆監査

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

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

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

によると監査は

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

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

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

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

　「利害の対立」

である。

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

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

◆プロジェクト監査とは

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

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

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

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

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

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

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

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

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

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

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

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

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

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