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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

◆ＰＭＯの３つの活動

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

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

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

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

◆ＰＭＯの３つのタイプ

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

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

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

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

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

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

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

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

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

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

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

現場力というのがなんとなくキーワードになってきている。

現場力というのを、経験と混同している人によく会う。これは曲者だ。例えば、ＰＭＯのメンバーとして仕事をするのに、ＰＭの経験が不可欠だと考える人が多い。プロジェクトマネジャーの考えを理解する必要があるといった理由だ。

しかし、ＰＭＯの現場力というのは少し、違う。現場力というのは現場を見て、ものごとを判断する力である。上に曲者だと書いたのは、経験をすると、自分の経験で現場で起こっていることを無視して判断する危険があることだ。これは大いに気をつける必要がある。

確かに、自分が経験したことが、今、現場でも起こっている可能性はある。しかし、やっぱり違うことの方が多い。お客さんが違えば、きっと違う。ミッションが違えば、やっぱり違うだろう。経験に頼って現場の判断をするというのはかくも危険なことである。

ある意味で、昔取った杵柄で、強硬な意見をいう役員とか、ＰＭＯがそんな役回りになる危険もある。そうなったら、プロジェクトの足を引っ張るだけだ。

自分にどんな経験があろうと、謙虚に現場を見る。その上で、自分の経験を使って判断する。そういう力が現場力だ。

ここで、経験で「こんなことが起こっているだろう」と推測するのであれば、経験などないほうがましだ。

文部大臣が小学生から英語を勉強させる必要はないといって、ちょっとした騒動になった。行政の一貫性を無視した発言なので、発言そのものはどうかと思うが、考え方は与したい部分がある。

英語でコミュニケーションできることはこれまでもこれからも必須である。そして、言語中枢は１０歳くらいまでにかなり出来上がってしまうので、小学生から学ばせることが望ましい。この理屈は良く分かる。

しかし、言葉というのは文化である。モノがなければ、単語はない。思考法がなければ、その思考法を具現化するレトリックはできない。典型的な例を挙げれば、否定と肯定だ。例えば、「基本的にそれでよいと思う」という言い方がある。これを英作文しろといわれれば、困る。文脈が明確な中で、合意する前提条件を明確に述べるといったことしか思いつかない。

こういう言い方はビジネスの中で論理的にものごとを進めていく際の障害になるので、歓迎されない。しかし、逆に明確にすることで問題が派生するケースがある。

例えば、顧客の要求を明確にする作業の中で、顧客が「基本的にそれでよいと思う」と言ったとすれば、「だいたい、よいと思うが、まだ自分たちにも見えない部分があるので、それを基本路線として一緒に考えてほしい」というような意味のことが多い。分からないのだから、条件として明確にかけない。しかし、書こうとするので、不完全な条件記述になる。当然、後でトラブルの元になる。こんな感じだ。

どこに問題があるかというと、言葉の背後になる行動様式の違いがあり、そもそも、それは文化に拠る部分が大きい。ソフトウエアの世界でいえば、仕様記述の問題としてワインバーグがこの問題はよく指摘しているし、ユースケースなどが使われだした理由もここにある。ユースケースは英語でも日本語でもない新しい言語ということになり、そこに新しい行動様式、思考様式を築いていこうという試みだ。

マネジメントとか、エンジニアリングでは、多くの場合、欧米から日本に概念を持ってくるので、この逆のケースがよく発生する。プロジェクトマネジメントでもそれはある。

よい意味でもっとも痛感するのがスコープ。この言葉は日本語にはない。だから外来語としてカタカタになっている。スコープという言葉を一つ導入することで、今までやってきたいろいろな工夫も説明できるので、導入に意味がある例。実際に、組織のプロジェクトマネジメントを導入すると、真っ先に普及する言葉はスコープであることが多い。今まで、もやもやしていたのが、霧が晴れたように言葉にできたのだと思う。

逆に、どうかなと思うのが、レスポンシビリティ。例えば、ＲＡＭに相当する概念は体制図だと思うが、日本的な業務運用を考えると、ＲＡＭより体制図の方が自然だし、定義する意味がある。日本的な考え方では責任とは連帯責任であり、いろいろな意味でプロジェクトを最後まで成し遂げるためにはプラスに働くことが多い。極論すれば、ＷＢＳがなくても、職務記述があれば、やってしまうのが日本の組織である。

ＰＭＢＯＫがこのやり方よりよいなどとは言い切れないだろう。民主党が農業政策として付加価値を全面に押し出した政策を主張しているが、工業の分野でも同じような特性がある。少なくとも、日本人は、このやり方で高い付加価値の商品を生み出してきた。これは日本人のＤＮＡであり、文化でもある。

このような文化の中に、不用意に新しい言葉を入れると、琵琶湖の外来魚のようになってしまう可能性がある。外来魚が従来の生態系を壊したように、その言葉が文化を壊してしまう可能性がある。

技術をどんどん、欧米から導入するのは明らかにプラスである。しかし、マネジメントを不用意に入れるのは、日本人のコアコンピタンスである現場を壊してしまう可能性が高い。そろそろ、考えるべきときに来ている。

◆ＰＭＯブーム到来！？

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

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

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

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

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

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

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

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

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

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

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

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

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

pmstyle.bizで実施しているアンケートの中間結果です。コメントするとバイアスが乗るので、コメントはしません。現場を見ている実態が出ていると思います。

■回答者業種ベスト３
　（１）ＩＴ　５２％
　（２）製造業　２６％
　（３）コンサルタント業　５％

※だいたい、こちらで把握しているメルマガ読者の傾向に似ています。

■職種ベスト３
　（１）プロジェクトマネジャー　３２％
　（２）エンジニア　２２％
　（３）支援スタッフ　１４％

※これも、メルマガ読者の傾向ですが、支援スタッフが増えてきました。

■プロジェクトマネジャー育成に重要な一手　ベスト３
　（１）経験　５４％
　（２）上司、メンターの指導　２１％
　（３）コミュニティ活動　８％

※む～、これについてはそのうち、記事を書きましょう。

■研修日数
　（１）３日以内　４０％
　（２）なし　３０％
　（３）５日以内　２０％
　（４）６日以上　１０％

※むう～、研修は受けないという人が２位で、全体の３０％いらっしゃいます。

■受講したことのある研修ベスト３
　（１）ＰＭ基礎知識　２３％
　（２）ＰＭＢＯＫなどの標準手法　１９％
　（３）リスクマネジメントなどの個別テーマ　１６％

※だいたい、予想通りですね

自分の考えは違うという人はぜひ！
　http://www.pmstyle.biz/20060810.htm

１０月４日までやっています！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

今年も１１月の最初にPMI東京のフォーラムが開催される。プログラムが発表になったので見ていたら、ずいぶん、コミュニティ色が強いフォーラムになってきた。学会は別にすると、日本の職業人のフォーラムで、これだけコミュニティ色が強いのも珍しい。

発表の大半が、研究会の成果や、会員による自主的な発表である。まさに、コミュニティの本来あるべき姿といったところだ。素晴らしい。

いろいろとご苦労もあるようだが、PMI東京の事務局、リーダの方の活動には頭が下がる思いである。

このメールマガジンもコミュニティができれば思ってやっているが、ＰＭにとってコミュニティというのは、特別な意味を持つものだ。

まず、何よりも、他社のプロジェクトマネジャーとの交流ができる。交流の中で、新しい知が生まれる。

これがなぜ、重要か？プロジェクトマネジメントは新規性との戦いである。確かに新規性の中には世の中にないといった新規性もあるが、自分の所属する企業や組織の中での新規性というのも少なくない。これはひょっとすると、他の企業や、他の組織で経験していることかもしれないのだ。

２つの同じ経験が出会えば、新しいアイディアが生まれるかもしれない。

初めて　×　経験　のコラボレーションも新しいアイディアを生むかもしれない。

いろいろな人の経験が混じり、新しい知見が生まれる。そんなコミュニティを作りたい。

ＰＭ養成マガジンを始めたころに、

　「PMBOKは叡智か陰謀か」

　　http://www.pmos.jp/honpo/note/note3.htm

という記事を書いたことがある。この記事についてはおそらく、メルマガセミナーなどの機会に１０人以上の人と議論をしたと思う。

この記事は競争という視点で書いているのであまり理解してもらえないままだったような印象があるが、この記事を書いたときに漠然と思っていたことが現実になってきたように思う。

この記事を書いたときに思っていたのは、日本の産業は泥臭さを捨てたらおしまいだということだった。ＰＭＢＯＫ導入にその危険を感じていた。

そもそも論を言えば、日本人はこの種の形式化をするのが下手である。というよりも、したがらないといった方が正しいかもしれない。よい例がトヨタのカンバンだ。この仕組みを、技術的に捉えなおしたのは、日本の研究者でなく、アメリカの研究者だった。

日本人の研究者の能力が云々というよりも、社会的にこの部分は守らなくてはという意識が研究者に二の足を踏ませているように思う。平たくいえば、そんな研究をしても、産業界から支援を受けることはできない。

理論化をすることは素晴らしいことだが、同時にそれは誰にでもできるようになることを意味している。ここに突入することは自殺行為だと直感的に分かっているのだ。

プロジェクトマネジメントで起こっていることはまさにこれだ。確かに、組織としての能力は上がってきたと思う。しかし、泥臭く、すごいことをやってくれるプロジェクトマネジャーが少なくなってきている。

プロジェクトＸにならないように、プロジェクトマネジメントをしましょうはいいのだが、プロジェクトＸができなくなっては話にならない。これも何度か議論した。

　「ＰＭＢＯＫではプロジェクトＸはできない、いや、できる」

アニメーションの例を引き合いに出すまでもなく、日本の強い産業は職人的なところである。思いっきり泥臭いところである。

すごいことをしてくれるプロジェクトマネジャーがなくなったことはかまわないといえばかまわない（産業的には大問題だが、、、）

しかし、プロジェクトマネジメントを生命線とする企業で起こっているもう一つの問題は、問題は、プロジェクトに現場感がなくなってきたことだ。プロジェクトマネジャーがデスクワークを重視し、泥臭さがなくなってきた。これはいくつもの組織で感じている。

泥臭さが消えたプロジェクトマネジャーにはメンバーはついてこない。それどころか、メンバーの泥臭さを否定するようなプロジェクトマネジャーすら出てきた。

そろそろ、「是正」の時期に来ているように思うが、みなさんはどう思われるだろうか？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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