人気ブログランキング |

カテゴリ:プロジェクト・マネジメント( 154 )

プロジェクト・マネジメントにリーダーシップ論は要らない

昨年、国内最大手のシステム・インテグレーターのPMOの方から依頼されて、そこの社内PMセミナーで講演する機会があった。どういう話をしようか、少し迷ったのだが、その冒頭で、私はこう切りだした。「プロマネを選ぶときに、リーダーシップの有無を最初に問題にするのはおかしいと思います。少なくとも、私の業界ではそういうことは議論になりません。」

ご承知の通り、私はエンジニアリング会社に勤務して、プラント系のプロジェクトとSI系のプロジェクトの両方を経験してきた。二足の草鞋をはき、両者を子細に比べてみて気づいたのは、技術的な要素が大きくちがうにもかかわらず、プロジェクト遂行のストラクチャーがずいぶん似ているということだ。いずれも受託型のビジネスである。スコープと納期とコストが主要なコントロール対象である。元請け-下請け構造で複数業者が関わっている。個別受注・個別設計である(とはいえ、客先の要件はじつは業種によってかなり共通している)。納品物は生産財であって、客先はそれを受け取って自分のビジネスを運転しなければならない・・・

それにもかかわらず、エンジ業界とSI業界の人々のプロジェクト・マネジメント論議は、驚くほどちがう。その違いの一つが、リーダーシップ論だと思う。リーダーの資質とは何か。それは育成できるのか。PMOはそれをどう支援すべきか。こうした論点がくりかえしトピックに現れてくる。

しかし、ちょっと考えてほしい。あなたが航空会社を選ぶとき、機長のリーダーシップを気にするだろうか。「ご安心ください。当社のジャンボ・ジェット機のパイロットは、リーダーシップに優れた統率力ある人材を選んでいます。」などと広告されていたら、なんだかかえって不安にならないだろうか?

ジャンボ・ジェット機の操縦が易しい仕事だとは、決して思わない。しかし、リーダーシップだけで飛行機が飛ぶわけではない。われわれがパイロットに期待するのは、まず専門的教育を受けていること、ついで飛行実務経験だろう。機長のリーダーシップなどというものは、何か非常事態が起こった際に、迅速・的確かつ勇気ある決断ができるかどうかが問われるときのみ、真に重要になる。だが私はそんな事態は、あまり頻繁に予想したくないのだ。

同じようなことが、プロジェクトにも言える。少し前になるが、IT分野の雑誌にPM特集があって、その見出しの一つが「プロの火消し人集団」だった。だが、果たしてプロの火消し屋が何人もいるような組織は正常だろうか? あなたが工場を見学に行ったとき、「ご安心ください。わが工場には、専任の消防隊が3班もおります。」と胸を張られたらかえって心配になるにちがいない。あなたはその職場で働きたいと思うだろうか?

念のためにいっておくが、私は別にプロジェクト・マネージャーにリーダーシップが全く不要だ、などと主張しているのではない。それが真っ先に議論されるのはおかしい、と言っているのだ。リーダーシップは、いざというときのために必要だ。そして、不思議なことにある一定規模以上のプロジェクトでは、かならずそういう危機が訪れる。私の知っているベテランのプロマネは、「さすがの俺も、今回はもうダメか! と思うことが必ず2回来る。」と言っていた。リーダーシップは、そうした危機を乗り越えるためには、たしかに必要である。だが、危機を乗り越えるときは、プロマネだけでなく、プロジェクト・スポンサーやエンジニアリング・マネージャー、コントローラー達が一丸となって解決に動いていくものだ。プロマネ一人が背負うべきものではない。

それでは、なぜリーダーシップ論がSI業界では優先されがちか。それは、SIプロジェクトは『失敗率が高い』という信念、ないし神話があるからではないか。失敗確率が高ければ、たしかにリーダーシップの心配も高まろう。大西洋をはじめて横断する機長には、たしかに操縦技術以上に、強いリーダーシップがいるだろう(もっともリンドバーグには部下の副操縦士はいなかったのだから、誰に対するリーダーシップかと問われると答えられまい)。

プロジェクト・マネジメント技術とは畢竟、プロジェクトのリスク確率との闘いの技術である。PMBOK Guideのプロジェクトの定義(A project is a temporary endeavor undertaken to create a unique product or service)に、なぜ『リスク』の語が入っていないのか、私は常々疑問に思っている。もしあなたが、ジャンボ・ジェットの運行をプロジェクトだと思えないとしたら(上記の定義にはぴったり合っている)、それは、そこに失敗のリスクをほとんど感じないからだ。だから、プロジェクトの定義には「リスクをともなう」という一語が追加されなければならない。

と同時に、ビジネスの技術というものは、プロジェクトのリスクを低減して、だれもそれがプロジェクトだと感じないようにしむけていくべき存在だ。それが、プロジェクト・マネジメントのハード・スキルと呼ばれるものなのである。
by Tomoichi_Sato | 2007-07-09 22:47 | プロジェクト・マネジメント | Comments(0)

プロマネのハードスキルとソフトスキル

「ハードスキル」と「ソフトスキル」という用語をはじめてきいたのは、2003年のことだったと思う。米国で参加した会議におけるPMコンサルタントの講演で、この区別を知った。プロジェクト・マネジメントに携わる人間のスキルを、「ハード」と「ソフト」に二分する思考方法は、そのときまで私の中には無かった。

米国の思考法は、つくづく「分けていく」思考法だな、と思う。分類し、分析し、分業する。全体を部分に細分化して、それぞれの特徴・特性を多面的に把握する。そして目的合理性の見地から、それらを使い分け、組み合わせていく。だから道具立ては専門分化したツールの集合体になる。PMBOK Guideの構成を思い出してほしい。まるでゴルフバッグに入ったクラブの束みたいだ。あるいはナイフとフォークを何本も並べるフルコースの食事のようだ。(これに対し日本人は最初から最後まで一膳の箸だけですませる。最小限の道具だけで何でもできるよう、自分の側があらゆるスキルを駆使するのが日本のスタイルだろう)

さて、そのスキルだが、プロジェクト・マネジメントの理論や手法やツールなど、形式化された知識を使いこなせる能力、これを「ハードスキル」とよぶ。一方、問題解決や交渉やモチベーションアップなど、非定型な(主に対人的な)技能を「ソフトスキル」という。

当然ながら、良いプロジェクト・マネージャーには、この双方のスキルが必要である。では、これらはどう習得すべきか? 習得の面からいうと、両者は全く異なる。ハードスキルは本や座学で学べる。しかしソフトスキルは、持って生まれたセンスを経験の蓄積の中でみがいていくしかない。前者はコンピュータなどの仕組みに乗せやすいが、後者はなかなか仕組みにのせにくい、といってもいい。

と、こう書いていくと、“だからソフトスキルを充実させる方が重要な課題で・・”とつながりそうに思えるかもしれない。しかし、私は今のところ逆だと考えている。ソフトスキルは、部下を持ち中間管理職の立場になったら、誰でもその必要性に気づく。プロジェクト的職種だろうが、そうでなかろうが、あまり関係がない。だから世の中の本屋には、リーダーシップ論や人心掌握術や処世訓があふれかえっているのだ。だれもがこの問題について悩んでいる。つまり、だれもがこの問題を認識している訳だ。

ところが、プロジェクト・マネジメントのハードスキルに関しては、その存在すら知らない管理者がいまだに圧倒的に多い。問題を認識していなければ、改善の対策などあるわけがない。さすがにIT系企業ではCMMiだとかPMBOK GuideだとかITILだとか、毎年あの手この手でおどかされているから、うすうすその存在については気がついている。しかし、それ以外の業種・職種ではどうだろうか。製造・生産技術・研究開発・マーケティング・経営企画・サービス・・・あらゆる分野で非定型な「プロジェクト」は存在する。中には企業の短期・中期の命運を左右する大きなプロジェクトもある。にもかかわらず、こうした世界のプロマネたちは、「プロジェクト管理に理論がある」という基本的なことさえ知らずに仕事をしているかもしれないのだ。まるで、海図も測量器具も知らずに航海に出る船長のように。怖ろしいではないか。

たとえば、12ヶ月スケジュールのプロジェクトがあったとしよう。今、開始してから3ヶ月たった。当初の計画では、現時点までに600万円の出費が予想されていた。ところで、実際の出費は500万円だった。このとき、「このプロジェクトはコストを予定内におさえているから安心だな」とプロマネが判断したら・・それは決定的に間違っている。プロジェクトのコスト管理は、定常業務と同じような予実対比で見てはいけない。これがアーンドバリュー分析(EVMS)の教えである。

EVMSに限らず、WBSコード、アロウアンス、クリティカル・パス、トータルフロート、TRM、マイルストーン、ドキュメント・インデックス・・・これらプロジェクト管理の基本的な理論や手法はみな、ハードスキルの範囲だ(とはいえ、適当に選び出したこれら用語がすべてカタカナの外来語であるということ自体が、この国のビジネス文化を象徴しているなあ)。

幸い、ハードスキルは短期間で一通りの知識を学べる。学んだ知識を実践力にかえていくためには繰り返し練習が必要だが、その機会は実務にいくらでもころがっている。だからこちらの方が優先課題だ、と私は言うのである。そのためにはまず、プロマネ、ならびにその上にいる上級管理職が、ハードスキルの存在を知らなければならない。

私の知っている米国人は長らく金融関係でシステム開発にたずさわっていたが、中年になってからこうした理論を学び、「あと10年早くこれを学んでいたら、あれほど苦労せずにすんだのに!」と痛感したという。彼はのちに、独立してPMコンサルタントとなり、こうした知識の普及活動に従事することで、大勢の人が自分と同じような無駄な苦労を避けられるように貢献している。

前回、私は『だれのための生産管理?』(「タイム・コンサルタントの日誌から」2007/05/06)で、人間不在の管理論を強く非難した。しかし、今回はまったく逆のことをあえて書いている。人間論を排除したPM論が必要なのだ。リーダーシップ論も人格論も部下の掌握術も、いらない。まず、ハードスキルを学ぶべし!
by Tomoichi_Sato | 2007-05-14 22:00 | プロジェクト・マネジメント | Comments(0)

プロジェクト貢献価値の理論

EVMSを製品開発型プロジェクトに単純に適用しようとすると、意外な困難に見舞われる。前回それを、単純なガレージカンパニーの例題で考えてみた。いま、発明家(技術者)と実際家(セールスマン)が協力し、まず発明家が20万円の材料費で100万円相当の新装置を製作する。成功確率はフィフティ・フィフティ。つぎに実際家が買い手を捜す。9割方の確率で成功するだろう。この、2タスクからなるシンプルな製品開発プロジェクトで、「製造」タスクが成功裏に完了したとき、進捗率はいくつと算定すべきだろうか?

通常のアーンドバリュー分析は、タスクのコストをその価値と考える。「販売」タスクのコストがほとんどゼロのため、このままでは進捗率=100%という答えになってしまいそうだ。この困難を避けるためには、タスクのもつ真の『価値』を算定しないといけない。しかし、それでは真の価値とは、いったい何か?

ためしに、この問題をもっと単純化してみよう。タスクをたった一つ、「製造販売」にしてしまう。かかる費用は20万円。失敗するリスク確率は、 100%-50%×90%=100%-45%=55%となる。もし、このプロジェクトがうまくいけば、収益は100万-20万=80万円の価値を生み出す。

ところで、この単純化プロジェクトがはじまる時点では、まだ100万円の売上は確実ではない。売上の期待値は、100万×45%=45万円にすぎない。一方、失敗しても部品代20万円は確実にかかる。したがって、プロジェクトの期待価値は、45万-20万=25万円だったのである。言いかえると、この「製造販売」タスクの成功は、25万円のプロジェクト価値を、80万円の価値に増大させたわけだ。差し引き、80万-25万=55万円の価値増大に貢献したことになる。

これを別の言い方で表現すると、タスクの貢献価値とは、そのタスクの開始時点で期待されるプロジェクトの収益(=価値の期待値)と、そのタスクの完了時点での価値の期待値の差分で表現される。そして、価値の期待値とは、各タスクのもつ失敗のリスク確率と、タスク遂行に伴う費用ならびに収入(キャッシュフロー)で決まるのだ。

では、最初のように「製造」「販売」の2タスクからなるプロジェクトではどうなるか、計算してみよう。プロジェクトの期待価値は次のようになる。
「販売」完了時点:100万-20万=80万円
「製造」完了時点:100万×90%-20万円=90万-20万=70万円
「製造」着手時点:100万×90%×50%-20万円=45万-20万=25万円
したがって、
「販売」タスクの貢献価値=80万-70万=10万円
「製造」タスクの貢献価値=70万-25万=45万円

両方のタスクの貢献価値を合計すると、55万円となって、さきほど計算した1タスクのプロジェクトの貢献価値と同じになることがお分かりいただけるだろう。

さて、これで準備はできた。いま、「製造」が完了して「販売」の開始時点になった。すると、進捗率は、まさにアーンドバリュー分析の教えるとおり、その時点までに達成した価値を、価値の合計で割ることで得られる。それは、
45万円÷55万円=81.8%
となる。

よろしいだろうか? タスクの価値とは、そのタスクの前後で増えるプロジェクトの期待収益であらわされるのだ。そして、価値は、タスクのリスク確率(失敗確率)に依存する。上の例を見てほしい。「製造」の方が「販売」よりもずっと貢献価値が大きい。これは、「製造」の方がリスク確率が大きい、すなわち“難易度が高い”からである。難しい仕事ほど、価値が高いのだ。当たり前に思える常識を、貢献価値の理論は数式で証明してくれる。

ちなみに、上の例で「販売」のリスク確率を失敗ゼロ、としたらどうなるか。「販売」の貢献価値もゼロになることは、すぐ分かると思う。失敗するリスクの全くないタスクは、必要かもしれないが、貢献価値はゼロなのである。

実際のプロジェクトでは、タスク数は2よりもずっと多いし、並行するタスクも存在する。こうした複雑な系でも、貢献価値を計算する手法は構成可能だ。詳しくはProMAC 2006の拙論文を見ていただきたい。

それにしても、もう一度、上の例をよく考えてみてほしい。従来の経営論では、しばしば「製造」はコストセンターで、「販売」がプロフィットセンターと扱われてきた。そして、プロフィットセンターの営業部門の発言力が、どんどん増していった。しかし、貢献価値を比較したら、コストセンターであるはずの製造部門の方が、より大きな価値を生み出しているのだ。どちらが経営上重要であるか、明らかではないか。

そしてまた、貢献価値の理論は、従来は評価の困難だった、企業内のバリューチェーンや、複数企業をまたぐサプライチェーンの適正付加価値の計算も可能にしてくれるのである。それもこれも、「リスク確率」の概念をキャッシュフロー分析に取り入れたからである。貢献価値の理論の威力が、少しでも納得いただければ幸いである。
by Tomoichi_Sato | 2006-12-12 17:38 | プロジェクト・マネジメント | Comments(0)

プロジェクトにおけるタスクの価値を計算する

米国PMIがまとめたプロジェクト・マネジメント知識体系の標準"PMBOK Guide"の普及にともない、日本でも次第にアーンドバリュー管理システム(EVMS)が使われるようになってきた。進捗とコストを同時におさえながら、プロジェクトのコントロールをする上では、非常に有用なツールである。日本にも『出来高』という立派な言葉と概念があったのだが、それをマネジメントの技術として普遍化・活用できなかった。日本のビジネス文化の弱点かもしれないと思うと、ちょっとくやしい気もする。

ところで、EVMSが広まるにつれ、なんとなく進捗はアーンドバリューで測ればすべてOK、という理解も広まってしまったようだ。舶来の理論をそのまま鵜呑みにしたがる風潮も、またわれらが文化の弱点かもしれない。以前、「アーンドバリュー分析の落とし穴」(『コンサルタントの日誌から』2002/10/20)などにも書いたとおり、EVMSは用法を心得て使うべきであり、決して万能の手法ではない。

EVMSの最大の弱点は、じつは製品開発型のプロジェクトに適用しようとする際に、うきぼりになる。ためしに、きわめて単純な例を考えてみよう。いま、発明家(技術者)と実際家(セールスマン)が二人でガレージカンパニーをはじめようとしている。発明家は、20万円ほどの部品を組み合わせて、100万円相当の機械と同等の機能を持つ新装置を作れる画期的アイデアを考案した。実際家は、それができたら自分が買い手を捜してやろう、ともちかける。つまり、この二人の事業は、「製造」と「販売」の2タスクからなる、きわめてシンプルな製品開発プロジェクトである。

ただ、発明家が実際にその装置を組み上げられるかどうかは、まだフィフティ・フィフティの見込みだ。一方、セールスマンは、もしその装置ができあがれば、9割方は買い手を見つけられる自信がある。製造タスクのコストは20万円。販売タスクのコストは、まあ電話代や交通費が多少かかるだろうが、ほぼゼロとしよう。

さて、ここで問題である。いま、ぶじ発明家が装置を組み上げることに成功した。つまり第1の製造タスクは完了したわけだ。ではプロジェクトの現時点の進捗率はいくつか? あなたはどう考えますか?

アーンドバリュー分析の立場から言うと、プロジェクトの進捗率とは、その時点までに完了したタスクの価値の合計を、全タスクの価値の総計(=つまりプロジェクト全体予算)で割った数値である。では、この場合はいくつか。プロジェクト全体のコストは20万円だ。そして、完了したタスクのコストも20万円だった。したがって、最初のタスクしか終わっていないのに、進捗率は100%になってしまう! はたしてこれで良いのだろうか?

はっきりしていることが一つある。それは“これでは働いている人間の実感にあわない”ということだ。実感に合わない尺度では、人をマネジメントすることはできまい。いや、問題は販売経費をゼロとしたことだ、と思う人もいるかもしれない。しかし、では販売経費をかりに千円としようか。そうしたら、進捗率は20÷20.1=99.5%となる。少数以下を切り上げると100%だ。これではなんら解決になるまい。EVMSによる進捗計算を製品開発プロジェクトに無反省に適用すると、いかに問題かおわかりになっただろうか。

この問題の本質はどこにあるのか。それは、「タスクにかかる費用を『タスクの価値』と見なす」というアーンドバリュー分析で広く用いられる前提にある。これは言いかえれば、費用のかからないタスクは価値が低い、と考えていることになる。一般に知的作業は人件費のみだからコストが小さい。それにひきかえ製造や建設や量産はコストが大きい。つまり、力仕事の方が価値が高いと評価されるわけだ。EVMSはアメリカ国防省の調達プロジェクトにおいて発達したから、コスト基準でタスクの価値をはかる考えがしみついてしまっているようだ。

コスト基準がだめだとすると、“二人の協力によるプロジェクトなのだから、半分終わったら50%と考えよう”といった解決法もあろう。しかし、これはマネジメント理論による解決というより、政治的決着というべきだ。製造作業が2人がかりだったらどうするのか。セールスに5人かかったらどうか。声の大きいタスクの方が勝つような進捗率計算など、マネジメントシステムの役には立つまい。それでは、どうすべきだろうか。

答えだけ先に言おう。『貢献価値の理論』を用いれば、タスクの真の価値を計算することが実はできる。そして上記の例では、進捗率=81.8%となるのだ。製品開発プロジェクトは、いや一般に全てのプロジェクトは、複数の人間が協力して、一度限りの目標を達成するための、リスクを伴う活動である。そこではリスク基準による貢献価値の理論が活きてくる。その考え方と具体的計算方法については、次回書こう。
e0058447_23371037.gif

by Tomoichi_Sato | 2006-12-04 23:39 | プロジェクト・マネジメント | Comments(0)

プロジェクト・マネジメントの世界は変わりつつある

オーストラリアのシドニーに行ってきた。ProMAC 2006に出席するためだ。正式にはInternational Conference on Project Management 2006といって、APAC(アジア・パシフィック)地域のプロジェクト・マネジメント国際学会である。2年ごとに持ち回りで開催されており、前回のProMAC 2004は東京で(正確には千葉で)開催された。第一回は2002年でシンガポールで行なわれた。2年後の第4回はアラスカ州のアンカレッジで開かれる予定だ。

3年前、米国ボストンで開催されたProjectWorldに参加したときの感想を、この「タイム・コンサルタントの日誌から」で『プロジェクト・マネジメントの世界は動いている』と書いた(2003/06/07)。その感は今回さらに強くなったと思う。このPM業界(というのもおかしな表現だが)に、多くの俊英が集まって、急速に経験の集積と手法の進歩するのが感じられる。

豪州側は豪PM協会とPMI Sydney支部が主催者になっているが、Defenceつまり政府国防関係も共催しているところが面白い。そしてかなり熱心に活動に参加していた。もともとプロジェクト・マネジメントと軍事との関係は深い。PERTは米国海軍のコンサルタントであったランド・アソシエイツが開発した手法だったし、 EVMSだって米国国防省が調達の標準手順として採用したからここまで広まったと言うことができる。それ以外に、建設/エンジニアリング関係の発表も多かった。むろんIT産業も参加している。製造業もいる。とにかくオーストラリアからの参加者は分野の裾野が広い、と感じる。

ひるがえって、日本からの参加者はというと、ここには若干の片寄りを感じた。参加者の数でいえば、おそらく2番目に多い国だと思うが、そのほとんどはIT業界の企業人なのである。それも、特定の大企業数社に限られていて、各社から大勢くり出している、という感じだ。こうなると容易に想像がつくが、日本人同士がかたまって日本語でしゃべっている状態になる。ちょっと、もったいない。

それはともかく、学会発表はなかなか興味深いものも多かった。一例を挙げれば、"Earned Schedule" の考え方の提案がある。米国海軍のコンサルタントLipke氏が発表で、EVMSの応用として、CPIやSPIといったアーンドバリュー分析の指標をいろいろと調べ、遂行途中で真の納期を精度良く予測するために、"ES"という新たな尺度の提案をしている。事実の集積に基づいた議論で面白かった。

私自身は2年前のProMAC 2004で初めて公開した『リスク基準のプロジェクト評価手法』の発展版を発表したわけだが、リスクは一つのキーワードだった。ほかに多くの参加者を集めていたテーマは組織論と人材教育だろうか。誰もが悩むテーマだからだろう。しかしこの種の話題はどうしても「工学」というより「経営学」みたいなアプローチになる。言葉による分析、インタビュー調査による集計が中心で、エンジニアとしてはどうにも歯がゆい。

プロジェクト・マネジメントの議論は、どうしても理工学的アプローチと、“文系”的アプローチの両面が出てくる。対象が人間の集団だから、それは無理もないことだと思うが、理論や手法として世界で通用するためには、やはり沢山の事実への適用によって磨かれないといけない。自戒を込めて言うわけだが、日本がこの分野で貢献するためには、もっと広い業種・分野での意見の交換が必要ではないかと思うのだ。
by Tomoichi_Sato | 2006-10-11 21:52 | プロジェクト・マネジメント | Comments(0)

予定と実績の間のミッシング・リンク

今、米国で最も広く使われているプロジェクト管理ソフトウェアは何か? --答えは、"Excel"である。これは少し前にBostonで行なわれたProject Worldのカンファレンスで聞いた答えだ。ついでにいうと、Microsoft Projectとは、米国で最も売れており、かつ最も使われていないソフトウェアだ、とも聞いた。

MS Projectは私の勤務先でも(使いたければ)使えるが、あまり好まれていない。その理由は色々だ。ユーザ・インタフェースは親切なようでいて、一貫性がない。マウスのドラッグで工程表のガントチャートを簡単に書けるのは便利だが、どうも妙に親切すぎて、おかしな事をしばしば、しでかしてくれる。メニュー階層も分かりにくいし、印刷設定も不可思議である。

しかし、もっと根本の所で、プロジェクト・マネジメントのプロの目から見ておかしな部分がある。たとえば、MS Projectにはタスクやプロジェクトの予定終了日以外に、「期限」を設定できる。この二つは何が違うのか? またプロジェクトの終了日をずっと後ろにずらすと、何とクリティカル・パスが消えてしまう。「クリティカル・パス」というのはプロジェクトの開始から終了までの経路の中で最長のものを指す、というのが定義である。だとしたら、このソフトは、クリティカル・パスの意味を知らないのだ。

しかし、もっとも問題なのは、じつは別のところにある。MS Projectには、スケジュールの開始/終了日付が、「予定」と「実績」の二つしかないのだ。これでは困る、と、プロジェクト・マネジメントのプロである同僚たちは言う。予定と実績の間に、プロジェクトの世界ではもう一つ必要なものがあるのに、MS Projectをはじめとする多くのプロジェクト管理ソフトには、それが欠けている。そのミッシング・リンクとは、「見込み=forecast」である。

見込み日(forecast date)とは何か。これは、「現在のままでゆくと、開始日・終了日はこの日付になる」と判断された結果だ。今、設計のタスクを遂行中だとしよう。予定では、3月の1ヶ月間で設計完了のはずだった。つづく実装作業は、4月1日から開始の予定である。これらは「予定日」だ。ところが、設計は3月10日になって、ようやく開始した。そしてまだ完了していない。だから、実績開始日は3/10で、実績終了日はまだ無い。しかし、開始が10日遅れたのだから、作業ボリュームにかわりがないとしたら、設計が終了するのは、4月9日の「見込み」(forecast)である。実装開始の見込み日は、4月10日になる。

プロジェクトは複数の人間が協同する作業である。下流工程の担当者は、自分のタスクが本当はいつ着手できる「見込み」なのか分からないと、困ってしまう。だからforecast dateは必須なのだ。これが、プロジェクト・マネジメントのプロの感覚である。

ところが、少なからぬ企業で、この「見込み日」の概念が、なぜか活用されていない(単に知らないだけなのだろうか?)。では、そうした会社では、現実を予想するのに、どうしているか。

答えは簡単だ。計画をそのたびごとに変更していくのだ。設計の着手が遅れたら、設計の予定日付も変えてしまう。こうして、何回も計画を更新していくから、計画の履歴管理が必要だ、などという要求が出てくる。しかし、この調子で計画をどんどん変更していったら、結局のところ、実績は常に計画と一致することになる。これで本当に進捗管理といえるのだろうか? 

計画のベースラインとは、めったなことでは変えないのが、プロフェッショナルのやり方である。では、変わりやすい現実にどう追随していくか。そのためにこそ、見込み日(forecast date)が必要なのだ。

ちなみに、生産スケジューリングの世界には、普通Forecast dateなどない。いらないのだ。なぜなら、製造現場の作業は精度が高いので、たいていはスケジュールどおり仕事が進んでいく。見込み日の概念がいるのは、ホワイトカラーだけだ。ホワイトカラーの仕事は、製造現場よりも精度が低い。だから、計画通り進まないのが当たり前になっている。精度が低い人たちが、不思議なことに、なぜか給料はたくさん貰っている。まあこれは余談だが。

ところで、見込み日を運用するに当たって、きわめて重要なことが一つある。それは、“見込みは誰が決められるのか”という問題である。よく、プロマネが進捗会議で担当者に対して、「その仕事はいつ終わる見込み?」と聞いたりする。この質問が意味を持つのは、回答者が『正しく予測できる能力・態度を持っている』という時に限られる。パートナー企業との共同プロジェクトや、海外ベンダーとのプロジェクトなどでは、この条件はかなりの留保つきでないと、適用できない。担当者が見込みを正しく答えられると言うのは、一企業の中だけで成り立つ、性善説だと考えるべきである。
by Tomoichi_Sato | 2006-03-17 12:47 | プロジェクト・マネジメント | Comments(0)

プロジェクト制の要件

ソフトブレーン(株)の会長・宋文洲氏はいつだったか、持論のプロセス・マネジメントに関連して、「プロセスは線路で、プロジェクトはそこを走る個別の電車である」と言われたことがあった。これはなかなか面白い喩えだと思う。プロセスはいったん路線を引いたら固定して変わらないが、プロジェクトは運転手も、乗せている客も毎回違う。行き先だって変わることもある。“だからプロセスの設計が重要なんだ”というのが宋さんの立論である。

しかし、これはある意味では例外的なケースだとも考えられる。通常の製造業においては、まず「プロジェクト」という仕組み自体が確立していない。製品開発や受注生産といった個別の『案件』は、たとえば

企画→設計→試作→生産技術→購買→製造→物流、

という複数の機能部門の中を、上流から下流に向けて流れていくケースがほとんどだ。言いかえれば、縦割り組織の中をバケツリレーのように受け渡されていくわけだ。普通の電車の運転手は終点まで変わらないが、縦割り組織のメーカーは、ひと駅ごとに運転手が交替する鉄道に似ている。

むろん、それでずっとうまく行っているならば、何の問題もない。しかし、製品開発や個別受注生産は、複数の機能部門が関わり合う、クロス・ファンクショナルな活動である。業容を拡大したり、短納期化を進める状況下で、複数の案件が並行して進むとき、ボトルネックの作業負荷を誰が調整するのだろうか? 部門を統括する上級マネジメントか? しかし、個別の案件で設計と購買の鞘当てが起こるたびに、いちいち事業部長が介入して調整するわけにもいくまい。

たとえば、既存の部品を転用すれば、早くできるのは分かっているが、しかしオーバースペックで高いものにつく。今回用に注文し直せば安く上がるが、とうぜん手配に時間がかかる。製品出荷の早さ(納期)をとるか、製品コストを取るか。製品開発は常にトレード・オフに直面するものだ。決断には責任がともなう。誰がそのリスクをとるのか?

答えは明らかだ。プロジェクト・マネージャーが必要なのである。納期とコストの双方に最終的な責任をもつ、プロマネが判断すべきだろう。そして、そのためには、社内でまず『プロジェクト制』の確立が必須になる。バケツリレーがこんぐらがって、もう限界に達したな、と思ったら、それはプロジェクト制を導入すべき時期なのだ。

プロジェクト制、というと、なぜだかすぐ「社長直属プロジェクト」を想起する人が多い。しかし、ここではそんな、“社運を決する一大プロジェクト” だけを考えているのではない。始まりがあり、明確なゴールがあって、複数の部署の人間が協力して成し遂げなければならない仕事(しかも失敗の可能性もある仕事)は、「プロジェクト」として公式に扱おう、と決めるのだ。

プロジェクト制の要件はいくつかある。まず第一に、プロジェクト・マネージャーの指名である。プロマネに、品質・納期・予算(QCD)に関する最終的な権限と責任を与える(人事権までは与える必要はない)。

予算に責任を持つためには、プロジェクト予算体系を確立しなければならない。これを支える仕組みとして、プロジェクト番号制が望ましい。プロジェクト番号をキーとして、日報による社内人件費把握や、外部費用のプロジェクト別把握ができなければならない。

誰をプロジェクト・マネージャーに任命すべきかも、悩ましいところだろう。企画部門かもしれないし、設計部門かもしれないし、生産技術部門から出すのがいいかもしれない。タスクフォース(「工務店」型)組織か、マトリクス(「置屋」型)組織かによっても、答えは違う。だが、いずれにせよ、プロジェクト・マネジメントに関する基礎的なトレーニングは必須だろう。固有技術と、管理技術は違うからだ。この点を忘れると、プロジェクト制など、すぐに絵に描いた餅になってしまう。

スムーズな製品開発や個別受注生産にとって、「プロセス」は必要条件だが、十分条件ではないのだ。最後まで決定に責任を持つ「運転手」=プロジェクト・マネージャーが望まれるのだ。
by Tomoichi_Sato | 2006-02-19 23:46 | プロジェクト・マネジメント | Comments(0)

PMOが最も必要とされる場所

先日、PMI東京支部のシンポジウムにパネラーとして招かれ、参加させていただいた。テーマは「PMOはPMクライシスの救世主になれるか」で、PMO組織への期待論が中心だった。参加者は私の他に、Johnson & Johnsonのマーケティング部門の方、そしてUNIYSの方で、司会進行役がIBMの神庭さんである。外資系メーカー・エンジニアリング業界・IT業界それぞれの観点から、興味深い論議になったと思う。

PMOはProject Management Officeの略語である。複数のプロジェクトを統括してマネジメントする専門部署、というほどの意味だが、最近はどうやら流行の3文字略語になってきたらしい。例によって米国で広まりはじめ、すぐわが国にも飛び火した。おそらくシンポジウムの聴衆の中にも、PMOの名刺を持つ方が少なからずいらしたに違いない。

ところでパネル・ディスカッションが進むにつれ、このPMOという組織の位置づけについてのすれ違いが明らかになってきた。それは、簡単に言うとPMOがラインを主導するのか、あるいはスタッフとして支援に徹するのか、その違いである。あるいは、プロマネはPMO部門に所属するのかしないのか、という違いだと言ってもいい。

ちなみに、私の勤務先である日揮は、PMOという名前の組織はない。プロジェクト本部という組織があり、それとは別にエンジニアリング本部という機能別組織(電機・機械・化学・建築・制御・シビル等の設計者集団)がある。プロマネはプロジェクト本部に属して、各案件(プロジェクト)ごとに機能別組織の横串を通すマネジメントを行なう。つまり、典型的なマトリクス型組織である。

マトリクス組織のプロジェクト・チーム員は、機械エンジニアなら機械専門部の部長が上司であり、固有技術はその部長が統率する。プロマネは、管理技術に徹するわけだ。ここでは固有技術と管理技術は独立して、車の両輪となっている。

ところが、IT業界のSIerは、タスクフォース型組織をとる会社が殆どである。タスクフォース型組織では、プロマネはプロジェクト・チーム員の上司に当たる。つまり、固有技術と管理技術の両方を、ある意味では同じプロマネが面倒を見なければならないわけだ。しかも、SIerでは、プログラマ→SE→サブ・リーダ→プロマネ、というようなキャリア・パスが多い。固有技術者が進化して、管理技術のマネージャーになるという、ポケモンの進化論みたいな変身が要求される。

だからこそ、管理技術の中心であるPMOの確立が「救世主」として期待されるのだろう。PMI東京支部は、IT業界の参加者が圧倒的に多い。パネル・ディスカッションのテーマも、その問題意識が反映されたのだろう。

しかし、タスクフォース中心型組織(私はこれを「工務店方式」と呼んでいる)では、プロマネはPMOの所属にはならない。したがって、PMOは必然的に支援型スタッフになる。これで複数プロジェクトを統括管理できるのだろうか? まあ、指揮系統から言ってかなり困難だろう。もし、無理にそうした役割をPMOに期待するとなると、こんどはPMOが『本社』、各プロジェクト・チームが『工場』、みたいな関係にならざるをえない。

その場合、PMOを「頭でっかちの本社組織」にしないための工夫と制限が必要だろう。ひとつの方法は、現場と人を定期的に入れかえることである。つまり、PMO勤務経験をプロマネの必須のキャリア・パスとする。また、プロジェクト実務経験者を、PMOに転属させる。要するに、固有技術と管理技術の『両刀使い』を養成するしかない。

もともとPMBOK Guideの原型は、エンジニアリング業界や航空宇宙業界の出身者が中心になって作られた。こうした業界は機能別組織が発達している。一方、IT業界は、構造的にそういう社内体制になりにくい。米国PMI風の発想が、どうしても日本ですれ違いを生みやすいのはこのためだろう。

私の見るところ、PMO組織の確立がもっとも成功するのは、じつはSIerでも建設・エンジニアリング業界でもない。製造業・流通業における、新製品開発や上市などのプロジェクト管理である。なぜなら、こうした仕事は、必ず複数の機能部門の協力を必要とする。営業企画・研究開発・製品設計・生産技術・購買・マーケティング・物流・・等々である。しかも、こうした仕事は、たいていの場合、「プロジェクト」として位置づけられておらず、単に「案件のバケツリレー」でこなされているからだ。予算についても、スケジュールについても、誰も本当の意味でのコントロールをしていない。

このような縦割り組織において横串を通し、『プロジェクト制』を確立し、効率よく短期間で製品開発・上市を進めていくためにこそ、PMOという部門が役に立つのだ。じじつ私も、最近はこうした製品開発プロジェクトのマネジメント・システム導入をお手伝いすることが増えており、かつその効果が大きいのも見てきている。

PMOは、製品開発にとってこそ「救世主」なのだ。もっとも、まれに単なるプロジェクト・チームをPMOとよんでいるケースもあるようだ。これは遂行と統括マネジメントの区別がされていないのだろう。誤解だと言うべきなのかもしれない。
by Tomoichi_Sato | 2006-02-08 01:22 | プロジェクト・マネジメント | Comments(0)

WBSのつくり方

WBSは、「仕事のBOM」である。私は最近、そう説明することにしている。プロジェクトという、始まりと終わりがある仕事の全体像を表現するには、それを構成している仕事の部分品ひとつひとつに分解して、どういう構成になっているかを示すのが一番分かりやすい。それがWBSである、と。

WBSはWork Breakdown Structureの略である。プロジェクト・マネジメントで使う用語だ。このWorkという英語はいささか多義語で、仕事(人の作業)のこともさすが、加工対象物(モノ)のことをも意味する。そのせいかどうかしらないが、WBSの作り方には従来、二通りの考えがあった。

まず、WBSは人の作業の構成表である、とする考え方がある。システム開発プロジェクトという仕事は、「要求分析」「設計」「実装」「テスト」「移行作業」などとブレークダウンしていく。「設計」はさらに「基本設計」「詳細設計」「実装設計」に分けることもできるだろう。これはある意味で、仕事の進む順序=プロセスを表現しているとも言える。別の例で言えば、製品開発プロジェクトという仕事のWBSは、「製品企画」「市場調査」「設計」「試作評価」「量産準備」というわけだ。

もう一つの流儀は、WBSを、プロジェクトの成果物の構成にしたがって作るやり方だ。在庫管理システムの開発ならば、「入出庫機能モジュール」「保管機能モジュール」「棚卸機能モジュール」「マスタ管理モジュール」といったサブシステム別にブレークしていく。入出庫機能モジュールは、さらに「入庫」「出庫」「返品」といったサブモジュールに分けられるかもしれない。これはまさに、成果物の構成部品表をイメージしているわけで、WBSは仕事のBOM、という表現にぴったり来ると感じられるかもしれない。

ところで、後者のやり方では、一つまずいことがある。それが何か、おわかりだろうか。

成果物単位にWBSをつくると、成果物全体に共通の作業が、抜け落ちがちになる弱点がある。たとえば、典型的な例は「プロジェクト・マネジメント」というタスクがそれである。プロマネの仕事は、ふつう、どれか個別のモジュールには従属しない。あるいは、製品設計ならば、「製品企画」や「市場調査」などもそれである。

前者の方式を、Functional WBS (F-WBS)と呼び、後者をProduct WBS (P-WBS)と呼んで区別することがある。そして、両者の間には、長い論争の歴史があった。

最近、Gregory T. Haugan著「WBS入門」(翔泳社・刊)という本が出版されて話題になったが、著者はP-WBSの流派の人だ。彼は長らく米国国防総省の調達対象となるような航空宇宙産業のプロジェクト・マネジメントにタッチしてきた人だから、作るべきモノが最初から明確になっている世界の人だ。航空機は胴体と主翼と尾翼とエンジンからなり・・という風に。

その彼も、この問題点は意識しており、「WBSでは『プロジェクト管理』を必ずプロジェクト直下の第1階層に置け」という意味のことを書いている。これは一種の現実的な妥協策であろう。もっとも、F-WBS流儀で仕事の構成を作る人たちの中でさえ、ときどき『プロジェクト管理』のタスクが置き忘れられていたりする。だから、これは本質的な弱点とは言えないかもしれない。

私の目から見ると、P-WBSの本当の弱点は、「WBSのマスタを作りにくい」ことにある。WBSはプロジェクトのBOMだと考えられる。そして、BOMは普通、マテリアル・マスタの中から選び出された品目の組合せによって構成される。生産管理の世界では、マテリアル・マスタがまずあって、それからBOMができるのだ。ならば、WBSを作る場合だって、"Work"のマスタから選び出して組み合わせるべきだ。

成果物は個別プロジェクトでみな異なる。だから、その要素のマスタというのは想像しにくい。しかし、仕事のプロセス自体は、開発対象が在庫管理システムであろうが受発注システムであろうが、大筋にかわりはない。したがって、要素業務のマスタがつくりやすいのである。

要素業務のマスタが作れると、どういう利点があるか。それは、仕事の標準的なデータベースを作れることを意味している。すなわち、プロジェクト計画に置いて最も重要な、工数見積や期間見積に、過去のデータが活かせるということなのだ。これが、F-WBSを用いた場合の最大のメリットなのである。

Haugan氏の「WBS入門」の最大の問題点も、そこにある。この著者は、WBSにマスタが必要であり、それは構築可能だという認識がない。いや、彼だけではない。じつは米国PMIは、そのものずばり"Work Breakdown Structure"というPractice standard(モノグラフ)を出版しているのだが、この中にも、WBSのマスタという考え方が欠落している。

WBSを作るならば、マスタが必要である。そうでないと、WBSの作り方は、プロマネ各人の恣意性にまかされてしまう。このことは、広く理解されるべきであると、私は考える。
by Tomoichi_Sato | 2005-10-14 00:01 | プロジェクト・マネジメント | Comments(0)

プロマネの鍵、貸します

往年の名画『アパートの鍵貸します』に、忘れがたいシーンがある。終幕近く、主人公(ジャック・レモン)が上司に、いつものとおりアパートの鍵を貸してくれ、とたのまれる。彼は鍵を渡すのだが、上司はそれを見て、叫ぶ。「これは役員用バス・ルームの鍵じゃないか!」。

アメリカの会社には、どうやら役員専用のトイレがあるらしい。社長が平社員に混じって、社員食堂で平気で食事をする日本では、想像しにくい話だが、その鍵は、役員であることの象徴なのである。米国で暮らすと、あちこちに鍵が要るので、すぐ鍵束がじゃらじゃらと重くなってゆく。ことに自宅の鍵は、外敵から物理的に身を守る盾であって、決して人に貸すものではない。

そのアパートの鍵を、不倫の密会用に上司に貸すことで、主人公は代償として出世を手に入れてきた。そんな行き方がリスキーであることは、うすうす感じていただろう。しかし、その彼も、自分の部屋で、若い女性(シャーリー・マクレーン)が睡眠薬を飲んで倒れているのを発見したときに、はじめて潜在的な「リスク」が具体的な「イシュー(問題)」になって、身に降りかかったことを知るのである。

プロマネを数人、貸してくれませんか” --そんな依頼が、ときどきある。中には、“できれば派遣社員の単価で”という虫のいいオマケまでついたりする。腕のいいプロマネは利益の源泉であって、それを安い費用で貸し出したら、私の勤務先は干上がってしまう。プロマネを貸すことは、自分のアパートの鍵を貸すのと同じくらい重大なことなのだ。

それでは、プロマネの適正な価格はどのように決めるべきだろうか。これについて明確に書いた本は、まだ読んだことがない。私の会社の経営者は、腕の良いプロマネをどこからか連れてこられるのなら、1億円払っても惜しくないと考えるだろう。エンジニアリング業界では、大きなプロジェクトは予算額が1千億円を超える。プロマネがヘタをうったら、赤字だって数十億円に迫るだろう。これが仮に半分で済んだら、プロマネ代1億円だって安いものではないか。

アパートの扉や壁が、住人を外敵から物理的に守ってくれる存在なら、プロマネは巨大なリスクから会社を守ってくれる、扉の鍵にあたる存在なのである。古代の中国人は、万里の長城という途方もない壁をこしらえたが、この防護壁の機能は、門を守る将軍の一人が外敵に対して門を開いてしまったことで、完全に無に帰した。鍵は掌に握れるくらい小さい。材料でいえば原価は数百円だろう。しかし、リスクの観点から言えば、その価値はきわめて大である。プロマネも同じで、人件費単価で貸し借りできるものではない。

「プロジェクト・ダイナミクスの構造」にも以前、書いたとおり、プロジェクトの問題発生には階層的な構造がある。問題事象が最初に発見される場所は、コストである。しかし、その原因は、たいていスケジュール遅延かスコープ漏れである。それらは品質・調達・人的リソースの問題から引き起こされる。そして、遠因は、たいていリスク対処とコミュニケーションの失敗にある。リスクの感覚は、プロジェクト・マネジメントの根底課題なのである。

では、リスク感覚はどのように磨かれるのか。それは何よりも、経験の蓄積を通じて磨かれるのだ。プログラマの世界には若い天才がときどき現れるが、プロマネには若い天才は存在し得ない。それにくわえて、プロジェクト対象となる分野の固有技術についての一通りの理解がなければならない。そうでなければ、この先何が起こりそうか、どうして分かるだろうか。

プロマネに必要な三要素は、経験から得たリスク感覚と、固有技術への理解と、管理技術である。最初の二つは、組織の中で時間をかけて育てていくしかない。最後の一つだけは、座学でもある程度は身に付くし、たとえば「e工程マネージャー」のようなツールの形で借りてくることもできる。

こうしてみると、借り出したプロマネを、ぽーんと一人で見ず知らずの組織に放り込んで、プロジェクトが機能する訳がないことが分かる。プロジェクトとは複数の人間が共同して行なう仕事だ。周囲とのコミュニケーションのポイントも分からず、固有技術も分からず、過去の経験もなければ、リスクをマネージしようもない。

『アパートの鍵貸します』は、人生の危機を乗り越えたジャック・レモンが、地位や金銭を捨てて真実の愛情を手に入れるシーンで終わる。ビリー・ワイルダー監督は、その場面を繊細で美しい白黒の映像で撮っている。彼にとって一番大事なものは、貸し借りでは決して手に入らないものなのだ。
by Tomoichi_Sato | 2005-10-07 22:56 | プロジェクト・マネジメント | Comments(0)