なぜ自発型プロジェクトは難しいのか？　プロマネの悩みを腑分けする

PM能力は組織の能力である

今月の半ばだったが、久しぶりにGAPPS Initiative の会合にオンライン参加した。GAPPS (Global Alliance for the Project Professions) は世界的に著名な豪州のPM学者・Lynn Crawford教授が設立しリードしてきたグループで、PM界の賢人会議などとも言われる（わたしが賢人だとう訳ではない、言うまでもないが）。プロジェクト・マネジメントの分野は世界的にいろいろな団体があり、米国発のPMI、欧州のIPMA、英国のAPMなどが、それぞれPM資格や認定を広めようと競っている。GAPPSはその中で中立な立場を守り、独自の視点から、分かりやすく実務に使えるガイドを自主策定してきた。

今回の主題は、「組織的なPM能力のアセスメント」のためのガイドラインの完成だった。プロジェクト・マネジメントの能力とは、プロマネ個人の能力だけで決まるものではない、という基本的認識が、そこにはある。PM論はどうしてもリーダーシップ論の文脈で語られることが多く、そうなるとリーダー個人の資質やスキルの話になりがちだ。だが、プロジェクト・マネジメント能力は組織全体の能力であり、組織が育てて活かすものだ。なぜなら、プロジェクトは基本的に、組織が自ら、何らかのアウトカムを得るために自発的に進めるものだからだ。

日本ではどうしても、プロジェクト・マネジメントが受注側の問題として捉えられがちだ。それは、(1)現在のPM団体組織に所属する人は、IT技術者が中心であること、(2)そのIT技術者は、多くが受注型ビジネス企業（とくに受託開発のSIer業界）に属していること、の二つの理由からなる。(1)は世界的に共通な現象だが、(2)は英米と違い、日本固有の事情である。

しかし世界的に見ると、プロジェクトとは「組織が自ら発案して実施するもの」という文脈でとらえている場合が多い。ISO21500なども、議論の経過をよく見ると、そうである。プロジェクトには「自発型」と「受注型」の二種類があり、区別が必要だと、わたしは10年以上も前から主張してきたし、自著『世界を動かすプロジェクトマネジメントの教科書 』にもそう書いた。だがあいにく、日本ではプロジェクトはデフォルトで受注型、という観念がいまだに強い。納期もコストも仕様も、受注時の契約で決められていて、自社には限られたリソースしかいない中で、さてどうするか——というのがPMの難しさだと思われている。

自発型プロジェクトの難しさとは

しかし、わたしの考えでは、プロジェクトは自発型の方が難しい。自社が発案し、自社が進める仕事なのに、なぜ契約で縛られた仕事より難しいのか。それは、プロジェクトのスコープが柔らかい中で、価値を生む方策を探さなければならないからだ。・・いや、こんな事を書くと、SI業界の人だけでなく、エンジニアリング業界の同僚達からも、ひどく反発されそうだなあ。「自発型の方が難しい!?　何言ってんだ！　スコープが堅くてコスト納期が厳しい方が、難しいに決まってるだろ！」という風に。

では、こう言い直そうか。自発型プロジェクトも受注型プロジェクトも、どちらも難しい。だが、難しさの質が違うのだ。受注型の難しさは、簡単に言うと制約条件の難しさだ。スコープ・コスト・スケジュールの厳しい制約。英国のPM学者の草分けであったMartinという人は、これを『鉄の三角形』と呼んだ。その中で、成果物を作り、かつ、受注金から原価を差し引いて利益を出さなければいけない。「もしもスコープ制約がなければ、コストと納期を満たすように、適当な成果物を作れば良いんだから、ずっと簡単じゃないか」と思う人も多いだろう。

ところが、自発型プロジェクトの難しさは別の所にある。それは、プロジェクトが価値あるアウトカムを生みださなければならない事だ。成果物（＝アウトプット）ができるだけでは、まだ話は半分でしかない。その成果物が、投下した労力や費用を上回る、価値を生みださなければ、プロジェクトを自発的にはじめた意味がなくなるのだ。たとえば何かITシステムを作っても（そして仮に予算と納期を守っても）、ろくにユーザに使われなかったら、失敗プロジェクトなのである。だって明らかに、ユーザが価値を認めていないのだから。

ご存じかもしれないが、今年発刊された最新のPMBOK Guide(R) 第8版では、プロジェクトの定義はこうなっている：
“A temporary endeavor in a unique context undertaken to create value”
「価値を創出するために、独自の状況において実施される有期的な取り組み」、というほどの意味だ（日本語訳は入手していないので、公式な翻訳がどうなっているかは知らない）。この版からはじめて、プロジェクトの定義にValue（価値）という言葉が入った。わたしに言わせれば、ようやく入った、である。価値抜きにマネジメントを論じてどうするんだ、と思う。ともあれ、「価値創出」がプロジェクトの目的である。この価値とは、決して受注者の「粗利益」だけを言っているのではない事に注意しよう。

プロジェクトのゴールとは何か

PMBOK Guideのプロジェクトの定義は、第7版までは、“A project is a temporary endeavor undertaken to create a unique product, service, or result” だった。「製品、サービス、所産」の創造が、プロジェクトの目的だとされていた。

ここでいう「製品」（Product）とは、企業が売る商品を必ずしも意味しない。建設会社が建てる橋も、自社で開発した業務システムも、売り物ではないが成果物としてのProductに位置づけられる。「サービス」は無形だが、実際にはサービスを生み出すためには、なんらかの人的・物的な仕組みがいる。たとえば教育サービスならトレーナーを育成する必要があり、通信サービスなら通信網システムを構築する必要がある。プロジェクトは、これを成果物とする。

3番目の「所産」とは何か？　これは原文の”Result” を見た方が分かりやすい。プロジェクトの中には、特段何か成果物を生み出す訳ではないが、ある種の状態になると終わるものがある。研究開発プロジェクトならば、発見・知見を得た状態である（それは論文や特許になるかもしれないが、あえてそうしない場合もある）。引越しプロジェクトなら、「新しい建物に引越終わった状態」が、Resultである。

では、プロジェクトの目的とは、こうした成果物やら状態を生み出すことなのか。それらアウトプットができあがれば、成功なのか。いったい我々は、なんのためにプロジェクトをやるのか。そこが実は、過去10年間における、プロジェクト・マネジメント分野での最大の問題だった。別の言い方をすれば、第6版から第8版までのPMBOK Guideの右往左往も、そこに原因があった。

何のためにプロジェクトをやるのか

落ち着いて考えてみれば分かるが、企業が新製品や新工場や、あるいは社屋移転などのプロジェクトをするのは、アウトプットだか所産だかのためでは、ない。それらは手段にすぎないのだ。何のための手段か。

新工場建設　→より大きな生産能力を得るため
新製品開発　→新市場を創出しリードする能力を得るため
新社屋移転　→より機能的で快適なオフィスで生産性を上げるため（生産性＝一人あたりの付加価値創出能力）
ECサイト開発　→より多くの顧客を引きつけ直接販売の能力を得るため
ERPシステム導入　→リアルタイムの経営数値の可視化により、より正確な経営判断能力や資源の再配分の能力を得るため

・・もう、いいだろう。企業の中で複数の部門が協力して、新しい何かにチャレンジするのは、新たな能力＝『ケイパビリティ』を最終的に得るためなのである。新工場の設備も、新製品の試作品も、新社屋ビルも、それ自体が目的なのではない。それらは手段であって、企業が新たな能力を得て価値を高めることが、目的なのだ。

組織が新たな能力を得て、価値を高めた状態が、目指すべき「アウトカム」である。そのアウトカムを実現するための道具が、プロジェクトの成果物（アウトプット）である。アウトカムを生み出すために、アウトプットを作ってる。この関係を忘れてはならない。下図は、わたしが大学などのプロジェクト・マネジメントの講義で使っているチャートで、プロジェクトとアウトプット、そしてアウトカムの関係を示したものだ。

ところがここに厄介なファクターが2つ関わってくる。まず第一に、人間の活動においては、しばしば手段が目的化してしまうことだ。ERPシステムの導入は、 経営判断の質の向上と言うアウトカムが目的なのに、プロジェクトに関わって、毎日苦労しているメンバーにとっては、システムを何とか導入して動かすこと自体が自分の目指す目的になりがちだ。

ITシステムを苦労して導入したのに、当初想定したようには活用されていない事例も、 よく聞く。こういう状況が生じるのは、プロジェクトの途中から、遠くであるはずのITシステムを作ること自体が自己目的化してしまうからだ。そして、これがもう一つのファクターと関わってくる。

プロジェクトの価値は、本当にプロマネが決められるのか

第二のファクターとは、望ましい結果（アウトカム）から、それをもたらす道具（アウトプット）を、上手に導出するのが難しいことだ。

これは鉄道の新線に駅を作るような例を考えるとわかりやすい。鉄道で交通を容易にすれば、地域の経済が活性化する（＝アウトカム）。しかし、具体的にどこに駅をつくるのか。その場所の選び方は、駅舎をどんな構造で、どんなデザインに作るかよりも、ずっと重要だ。

しかし、その決定プロセスはしばしば不透明に隠されたり、政治の影響を受けがちだ。 その結果、多くの人が首をかしげるような場所に、新駅が設置されたりする。おかしな場所に駅の位置が決まってしまったら、いかに駅舎の設計を工夫しても、利用者数は伸びるまい。アウトカムを実現できるような、適切なアウトプットを決めることに、失敗したのだ。こんなプロジェクトは、やっても浮かばれない。

問題は、このプロジェクト価値の大半を決するような、「駅の位置」に類するプロジェクトの重要な意思決定を、プロマネが行えるのか、にある。受注型プロジェクトでは、ほぼ無理だ。駅の位置が決まり駅舎の大きさも決まってから、設計や建設の契約になるだろう。では、自発型プロジェクトではどうか。わたしの経験した範囲でいうと、多くの場合、こうした重要な決定は実務レベル（＝プロマネ）よりも上の層で、大筋が決まってしまう。

ということは、プロマネが任命され仕事に着任したとき、すでにプロジェクトの価値創出可能性の、大事な部分が決まってしまっている、ということだ。なのにプロジェクトの成功も不成功も、プロマネの責任に帰せられ能力を評定されるのだとしら、ずいぶんな話ではないか。評定はともあれ、プロマネは誰もが良い仕事をしたいと願う。だが、自分で決められない部分が大きい。それが、自発型の難しさではないか。

・・と書いていたら、また長くなってしまった（汗）。プロジェクトについて語り出すと、言いたいことがいろいろと出てくるのだ。この続きも機会を見つけて、また書こう。

＜関連エントリ＞
「製造業のプロジェクトがうまく進まない、本当の理由」 (2024-12-01)