プロジェクトマネージャの資格をお持ちですか。プロジェクトマネージャの女性にお会いしましたが、この方がなかなか美人でしてな・・」これでは、いつまでたっても話の本題に入れそうもない。世の中に『社長』とか『課長』とかいう名前の資格制度があったらおかしい。このような名称を選んだのは、想像するに、二つ理由がある。プロジェクト・マネージャーが専門職であるという認識があったのだろう。たしかにある意味ではそうだ。マネジメントが専門職なのか管理職(総合職)なのかは、議論の余地があるはずだが。一つは、プロジェクトが時限的な営為である以上、PMもまたパーマネントな(永続的な)職位ではあり得ないはず、という理解があったのではないか。社長や課長は、永続的な職位である。個人単位ではいつかはその職を去るだろうが、管理対象はゴーイング・コンサーンを旨とする企業組織である。何かの目的を完遂したら解散、というプロジェクト組織とは異なる。この2点に、従来型の企業組織がプロジェクト・マネージャーという職業を位置づける際の居心地のわるさ、困難さが集約されているように思う。そもそも、若いPMは、自分より先輩の専門職チーム員に、指示を出す権利があるのか?こうした混乱は、プロジェクト組織の本質を理解していないから起こる。じつはPMとは職位でもなく職種でもなく、役割(Role)なのだ。役者が劇で役割を演じる、あるいはサッカーでアシストとシュートの役割を分担するように、プロジェクトという限られた目的の中で、最終的な意志決定の責任をになう「役割を負っている」のがPMなのである。プロジェクトが終わって、PMの任を降りたら、つぎは誰か別のPMの下で、別の「役割」につくかもしれない。それはPCM(プロジェクト・コントロール・マネージャー)やEM(エンジニアリング・マネージャー)という「役割」かもしれない。プロジェクト・マネジメントは専門技能である。この点はいくら強調しても強調しすぎることはない。たしかに(2年も3年も続く巨大プロジェクトは例外として)PMという一時的な役割を職位のごとく名刺に書くのは、おかしい。それならば、専門技能の持ち主である人々を、どう呼ぶべきなのか。私の勤務するエンジニアリング業界では、『プロジェクト・エンジニア』と呼んでいるが、ちょっとそっけない職種名称だ。Specialist"(PMS)などの名称の方が、ずっと気がきいている。名称はどうあれ、この『プロジェクト・エンジニア』は、PMになるための主要なキャリア・パスだ。最初は雑用じみた調整役からはじめて、しだいにEMだとかPCMを経験し、やがてはPMの役割を担えるようになっていく。私は、(たとえば)プログラマ→SE→リーダー→PMといった、固有技術の専門職が経験とともに、いつのまにかマネジメント職に「超進化」するような、よくある不可思議な進化論にはどうしてもなじめないのである。できればより多くの業界において、名称はどうあれ、プロジェクト・マネジメントの専門職種性が認知され、適切な「役割」を与えられるようになっていくことを、私は切に望んでいる。言葉の通じぬ、見知らぬ土地でタクシーに乗った。こちらの告げた目的地を、運転手は分かったんだか分からないんだか曖昧な態度のまま、車を発進させる。乗ったところでやはり不安になり、「もう半分くらいは進んだのかな?」と口にしてみる。すると、隣に乗っていた若い後輩が気楽そうに答えた。「もう、2/3くらいまで来ていますよ。」「なんでわかるの?」「だって、メーター見てください。空港からだいたい30ユーロくらいって、言われたじゃないですか。20ユーロ分、走ってますもん。進捗を把握するのは、簡単なように見えて、案外むずかしい。それは、私たちが『進捗とは何か』を、本当には良く理解していないからだ--こう言ったら驚かれるだろうか。このタクシーの例のように、目的地に向かっているかどうか分からないときに、メーターだけ見て進捗を測るのが無意味な事は、誰でも分かるだろう。次の例はどうだろうか。戦後間もない昭和25年、国会で「北海道開発法」が成立した。敗戦で海外の植民地をすべて失った日本に、ただ一つ残されていた未開の沃野が、じつは北海道だったのだ。いう役所が設立される。その北海道開発庁が中心となって、2年後の昭和27年に、北海道開発の『第一次五カ年計画』が開始する(余談だが、五カ年計画という名称はなんだか社会主義国を連想させる)。含む壮大な国家的プロジェクトであった。金額だから、現在に直せば1兆円を超えるだろう。ところで、それから5年経った昭和32年に、著名な物理学者でエッセイストでもある中谷宇吉郎博士(当時北大教授だった)が、文藝春秋に爆弾論文を発表する。増加は、・・・いずれも達成率0であった」と断ずるのである。この論文のおかげで、北海道開発庁は上を下への大騒ぎになったらしい。北海道開発庁(なぜかこのお役所の主要機能は霞ヶ関にあった)では、翌月、さっそく文藝春秋誌に反論を掲載する。開発庁の高官が書いたこの論文には、「開発計画は順調に進展している」と書かれている。「過去の年度で順調に予算を消化してきたからだ」・・・。この論法が、タクシーに乗った後輩社員と同じく、おかしいのに気づかれただろうか。過去にどれだけお金を使って事業を進めて来ようが、目標に一歩も近づいていなかったら、進捗はゼロである。タクシー・メーターをいくらにらんでも、進捗が分からないように。たしかに開発庁だって努力はしてきたにちがいない。そのこと自体について、異論はない。進捗と、過去の努力は関係がないのだ。進捗とは、これまでどれだけ仕事をしたかではなく、「これから先、どれだけ仕事が残っているか」で測るべきものだからである。それなのに、進捗の議論となると、タクシー・メーターを見ることばかりに集中するきらいが、ときどきある。メーターをどれだけ精度良くしようが、リアルタイムで1円単位まで測ろうが、それは(コスト管理には資するかもしれないが)進捗管理には関係ないのである。「使った費用」のかわりに「使った時間」で測りたがる誤解も、後を絶たない。10日間でおわるはずの仕事がある。進捗は8割です--これが間違いであることも、説明の要はないと思う。こんな論法が通用するのなら、9日目は9割、10日目には10割になる。10日目でも仕事が終わらなくて、11日目に突入したら、進捗は何割になるのか。11割か?これが馬鹿げていることは、考えてみれば誰にも分かる(はずだ)。実際の進み具合は、担当者にたずねてみるしかない。して、プロジェクト・マネージャーは週次ミーティングでチーム員や関係者を集めて、各人に「どこまで進みました?」と訪ねたりする。プロマネはその答えを持って机に戻り、Excelの計算表か何かに数字を入れて全体の進捗率を計算する。%』を入力する機能がついている。ポピュラーなやり方であろう。した問答で返ってくる進捗率が、“タクシー・メーター的な進捗率”でないという保証は何もない。担当者のサバ読みなども紛れ込みやすい。「率」で質問する方法は、私自身はあまりお勧めしない。進捗を定量的に測りたいのだったら、やるべきことははっきりしている。「残りの仕事量」を定量化することである。それを、全体像と比べて、あと何割残っているかを計算する。これは繰返し性の高い業務では可能だが、個別性の高いプロジェクト的業務では、決してたやすくない。そのことを理解した上で、次に思いつく方法は、率の代わりに、各人に『残日数』(完了まであと何日かかるか)を申告させる方法であろう。「これが進捗管理の唯一正しい方法だ!」と力説される大学の先生に、あるセミナーでお目にかかったこともある。これが進捗管理として信頼できるためには、各担当者が、残日数について信頼に足る見積能力を持っている、という前提がある。これは、成熟度の高い組織ではあり得るかもしれないが、すべての会社に当てはまるとは、到底言えない。プロマネ自身、上司に同じ質問をたずねられたとき、希望的観測を述べたりすることもあるではないか。これと同様の方法として、『完了見込日』を答えさせる方法もあるが、問題点はよく似ている。仕事にはまり込んでいる担当者に、客観的状況把握を期待するのは難しいと、私は思う。やるのなら、むしろ各担当者をマネージしているリーダーか、あるいはPMOに、完了見込日を推測させる方がベターかもしれない。なると、「上は俺たちのいうことを信用していないのか」との感情的反発もあり得るし、手間もかかるという何点があるだろう。残る、第3の方法がある。それは、「マイルストーン」を活用する手法である。プロジェクトのプロセスを計画時点で検討し、要所要所にマイルストーンを(できればそのクリティカル・パス上に)配置する。そのマイルストーンに、進捗率を当てはめるのである。その率は、EVMSで用いるようなコスト基準(残るアクティビティのコストの比率)でも良いし、あるいは別の何らかの基準で決めても良い。関係者全員が、各マイルストーンについて、ある程度納得し合意できる進捗率を、定めておく。そこを通過した時点で、“何%を達成”と公表するのである。プロジェクトが大きければ、それを各アクティビティについても定義しておく。いった、標準的な内部プロセスがあるはずである。それぞれに対して、内部進捗率を10%・30%・60%・80%・90%・100%といった具合に取り決めておく(組織内部で合意する)。週次ミーティングで質問するときは、「何%か」を聞くかわりに、「今どこのステップか」をたずねるのである。これならば、回答者の主観やサバ読みを、少しは排除しやすい。いずれにせよ、繰返し業務と違って、プロジェクトは個別性が高い。これはすなわち、見通しにリスクが伴っており、「終わってみないと本当はどれだけの仕事量だったか分からない」ことを意味している。プロジェクト的な進捗管理には、かならずリスクに伴う精度の問題が付随することを忘れるべきではない。この問題には「正解」は存在しないのだ。あるのは、「納得感を持てる」方法のみなのである。(2009)によって、2009年度の経営工学会論文賞を受賞しました。23:32はじめまして。22:20退路を断つことです。17:48本当にその通りですね。メッセージを入力してください。