プロジェクト・マネジメントの目的とは何か (2016-05-25) 中堅エンジニアが壁を破って成長するには、何を学ぶべきか。そういう問いに関連して、ここ何回か書いている。初級の仕事を一通りおえて、とりあえず一人前のことはできるようになっても、その先にしばしば壁がある。そこを乗りこえて面白い仕事をしていくためには、もう少しマクロにものを見て、人を動かせるようになっていく必要がある。 今年の1月に、静岡大学と浜松ソフト産業協会の共催によるプロジェクト・マネジメント講座に呼ばれて、初日の講師を務めさせていただいたときも、その話から始めた。集まった方はほぼ全員がIT技術者だった。IT分野は勉強会も盛んで、知識欲に燃えた熱心なエンジニアも少なくない。わたしはたずねた。 「この中で、現在プロマネの仕事をされている方はいらっしゃいますか?」 手を上げた方は全体の1/3もいなかった。ある意味、予想通りではある。プロマネの仕事をばりばりこなしている人は、こうした講座を聴きに来る必要がないし、第一、忙しくて聴きに来る暇もないだろう。わたしは受講者の方に申し上げた。 「すると、ここにいる過半数の方は、SE的な仕事をメインにされているソフトウェア技術者だと思います。じゃあ、もう一つおうかがいします。今やっている仕事が楽しい人、手を上げてください。今の仕事が楽しくて楽しくて仕方がない人は?」 結果はご想像に任せよう。少なくとも、全員からはほど遠かった。「つまり、楽しくない仕事をしている人が、結構いらっしゃる訳ですね。では、今の皆さんの状況を打破するためには、どうしたらいいでしょう? 充実した、面白い仕事をするためには? --たしかに皆さん、勉強熱心でいらっしゃる。しかし、あるレベルに達したら、そこから先はソフトウェア技術だけでは、充実した仕事はむつかしいのです。」そう、わたしは続けた。 「たった一人でプログラムを書いて、世界を転換させる、そんな夢を抱いて業界に入った人もいるでしょう。ただ、それで成功する人は、たぶん百万人に一人。それ以外の人は、他人と協力して、チームで仕事に取り組まなければなりません。そして面倒なユーザを説得し、上司を動かして、目的を達する必要があるのです。一つの目的のために、人を動かす技術。それがプロジェクト・マネジメントです。良い仕事をしたければ、プロジェクトの動かし方を知るべきなのです。」 仕事を良く理解したければ、仕事の『なぜ』=目的をしっかり把握する必要がある。プロジェクトとは、一つの目的のために、チームを動かして進める仕事だ。プロジェクトの目的とは、たいていはシステムなどの成果物と、そのアウトカムである。そこは、はっきりしている。 では、プロジェクト・マネジメントという仕事の目的はなんだろうか。 え? それはプロジェクトの目的と同じじゃないか。つまり成果物としてのシステムだよ??という答えは、じつは答えになっていない。もしそうなら、コーディングやテストという仕事が、プロジェクト・マネジメントの内部になければいけないことになる。もしかりにチームがプロマネ抜きでちゃんと仕事を果たして、システムを納品したら(理屈の上では可能だ)、プロジェクト・マネジメントの役割は何なのか? いや、理屈の上どころか、チームの足を引っ張る無能なプロマネだって、実在する。じゃあ、上手なプロマネと下手なプロマネの違いはどこから生まれるのか。有能なプロマネは何に奉仕し、無能な奴は何に失敗しているのか? 答えは簡単だ。プロジェクト・マネジメントの目的は、プロジェクト価値を最大化することなのだ。 え、それだけ? --そう。それだけだ。この目的を分かっているプロマネは、良い成果物が短期間にできるよう、チームの目標を明確化し、チームが働きやすい場や状況を作り上げ、問題を適時解決していく。ときには余計な管理で手間取らせないよう、手出しを控えたりする。逆のプロマネは・・言わなくてもお分かりだろう。 以上。 ま、ここで終わりにすれば、最近やたら長い傾向にあるわたしの記事の中では、画期的に短いエントリになるな。そうすれば省エネだし、地球環境にも優しい(?)かもしれない。が、ちょっとだけ補足を付け加えることにする(だから長くなるのだが・・)。 前々回の記事によれば、生産マネジメントの目的は、「生産の仕組み(生産システム)をつくり、活かし、進化させ、それによって働きがいを創出すること」だった。だったらPMだって、「プロジェクトの仕組みをつくり、活かし、進化させ、働きがいを創出する」という風にならないのか? 生産とプロジェクトはある意味、兄弟ではないか。そう感じられる読者もおられるかもしれない。 だが、そうではないのだ。プロジェクトを立ち上げ、場や組織を作るのは、プロジェクト・マネジメントの目的ではなく、「本来業務の一部」である。チーム作りは、手段に過ぎない。レンガを積むことは、レンガ職人の仕事の目的ではないことを思い出してほしい。本来業務は、仕事の目的ではない。 そして、プロジェクトはその定義上、一度限りの仕事であり、プロジェクト組織は一過性のものなのだ。生産マネジメントは永続的な仕事だが、プロジェクト・マネジメントは一過性の仕事である。そこが根本的に違う点である。 じゃあ、進化させるのは? つまり、プロジェクトで得た知見や教訓を、他のプロジェクトの改善に結びつけること。もっと別の言い方をすれば「組織のプロセス資産」の強化だ。これはPMの目的ではないのか? あいにく、知見やL&Lや組織の資産は、プロジェクトの波及効果(アウトカム)の一部である。良いアウトカムを生み出すことは、プロジェクト価値を高めることの中に、すでに含まれている。という訳で、プロジェクト・マネジメントの目的は、生産の場合より、ずっとシンプルな文章で表現できるのである。 もともとプロジェクト・マネジメントは、直接の成果物を生み出さない、「間接業務」である。だからもし、プロジェクト・マネジメントに全体の1割のコストがかかり、それが全体に対し1割以上の価値向上をもたらさなかったら、そんな作業は引き合わないのだ。 ただし念のため書いておくが、価値(Value)とは、利益(Profit)とイコールではない。ここを間違える人は、受注型ビジネスの業界に多い。プロジェクトの価値とは、受注金から原価を差し引いた値だろ、と。だが、それだけではないのだ。価値は、金銭的価値と、非金銭的価値とからなっている。受注型プロジェクトではたしかに、利益という金銭的価値はとても大事だ。だが、たとえば、その顧客やその分野での実績を得られたとか、プロジェクトで人が育ったとか、そうしたお金に換算しにくいアウトカムもまた、プロジェクトの価値の一部なのだ。 だから、「プロジェクト・マネジメントの目的はプロジェクト価値を最大化することだ」という定義は、すなわち「価値とは何か」という大きな問題を考えることを、プロマネに要求しているのだ。金銭的価値、そして複数のお金に換算しがたい価値があるとき、どれをとるのか、どれを優先するのか、そうした問いに、自覚的なプロマネは答えなければならない。 もともとマネジメントが決断能力を持つためには、価値観が必要である。「決断」はマネジメントの中心にある行為だ。そして、何が「良い」状態であり、どうなれば「価値が高い」かが明確でなければ、適切に「決める」ことはできない。ただし残念ながら、現在のプロジェクト・マネジメント理論には、こうした適切な価値論が欠けている(唯一、英国OGCのガイドライン”Management of Value“だけが、この問題への一つのアプローチを与えていると思う)。 もう一つだけ付け加えておこう。それは「プロジェクトは見えないシステムである」ということだ。プロジェクト価値の向上は、その見えないシステムの設計や運転からもたらされる。そこがこの仕事のむつかしさなのだ。 現代プロジェクト・マネジメントの考え方は、1950年代の『クリティカル・パス法』の誕生とともに生まれた。これはプロジェクトというものを、複数のアクティビティ(要素作業)から構成されるシステムととらえた、システムズ・アプローチの産物であった。つまりモダンPMとは、「プロジェクト=システム」という視点の上に立っているわけだ。 それ以前までは(つまり古代のピラミッド建設や万里の長城の時代から20世紀初頭の帝国覇権主義の時代まで、えんえん数千年にわたって)、人間はプロジェクト全体を「かたまり」としてしか見ていなかった。大きなかたまりのまま計画したり操作しようとしたりしてきたが、決してうまくいかなかったのだ。デュポン社の化学プラント建設スケジュールや、ポラリス潜水艦ミサイルの納期の予測のために、クリティカル・パスやPERTの手法が開発されてはじめて、人類はやっとプロジェクトに対する科学的理屈を手に入れたのである。 ところで、プロジェクトをシステムとしてみた場合、生産システムや交通システムなどとは歴然とした違いが一つある。それは、「実在」か「過程」かの違いだ。 生産システムは、空間的にも実在しているし、それに属する機械や人間も目に見える。永続的な仕組みである。しかしプロジェクトは、同じシステムではあるが、目に見えない。全体が同時に実在している訳ではないからだ。個別の瞬間には、その時点で走っているいくつかのアクティビティが動いているだけで、全体像を「見る」ことはできない。 たまにIT産業の方から、「プラント・エンジニアリングの業界はうらやましいですね。プラントが出来ていく姿は目に見えますから。ソフトウェアは目に見えないから大変なんです」といわれることがある。どういたしまして! それはものごとを表層的に見ているだけである。現場に組み上がっていくプラントは目に見えるかもしれないが、結果でしかない。プロジェクトの成否を決める大事な部分は、その現場に資材を届けるサプライチェーンであり、工事図面を作成するエンジニアリング・チェーンである。こうしたアクティビティは世界中に散らばっているし、よく目にも見えないのだ。 プロジェクトは目に見えないシステムである。それは(哲学者のホワイトヘッド風にいうならば)永続的な「実在」ではなく一過性の「過程」である。それを設計し運転していくのが、PMである。途中で後戻りできない。だから大変なのだ。 そして、プロジェクトは人間をその構成要素として含む「第二種のシステム」である。機械的な構成要素だけからなる「第一種のシステム」は、科学法則だけで予測可能だ。だが、自分で勝手に判断する人間を含む第二種のシステムでは、予測や制御がはるかにむずかしい。そして、だからこそ面白いのだし、上手くいった場合には価値が高いのだ。プロジェクトは放っておくと混沌に陥りやすい。それを束ねて、ある目的成果物やアウトカムを生み出す。放置した場合と統合した場合の価値の差が、プロジェクト・マネジメントの良否を測る尺度である。 価値観と、システムズ・アプローチの視座。これの二つが、プロジェクト・マネジメントの目的、すなわちプロジェクト価値の最大化を実現するために、必要なのである。こういうことは、輸入版のPM教科書にはあまり書いていない。いや、じつをいうと、わたしがこのことに気がついたのも、ほんの数年前のことだった。それまでは自分でもうまく言語化できていなかったのだから、いつも偉そうなことを書いているわりには、お恥ずかしい次第だ。 言葉にすること。それはマネジメントの第一歩である。マネジメントとは(少なくともその中核の意味は)人を動かすことにある。人を動かすには、テレパシーが使えない限り、言葉で伝えるしかない。だから言語化はとても大事なのだ。そして動かすべき「人」の中には、じつは未来の自分も含まれる。いや、正直にいうと、未来の自分ほど、動かしがたく、迷いやすく、忘れっぽい存在はいない。だから目的の言語化とは、何よりもぶれない自分自身への、道しるべなのである。