プロジェクト・ダイナミクスの構造



PMBOK Guideの編纂者たちが、いわゆる「9つのマネジメント領域」を定義したとき、そこにProject Integration Management=プロジェクト統合管理を入れたのは卓見だった。これ以外の8領域、すなわち、コスト管理、時間(スケジュール)管理、スコープ管理、品質管理、人的資源管理、調達管理、リスク管理、コミュニケーション管理、は、それぞれが独立した管理対象範囲を持っている。

(ところで、以前「マネジメントと管理はどこが違うか」にも書いたとおり、私は『管理』という日本語が嫌いだ。だから、こうやって8回も9回もくり返して書かされると、ちょっとうんざりしてくる。管理という用語はあまりにも多義性の言葉で、あらゆる物事を曖昧に片づけてくれるので、ひどく便利な魔法の道具になってしまう。私は、仕事の内容を正確に表現したいので、普段はあえて、マネジメント/コントロール/アドミニストレーションの3つのカタカナ言葉を使うようにしている。)

さて、独立した対象範囲があるということは、いいかえると、指標化して管理しやすいということだ。その典型がコスト管理である。コストは誰の目にも明らかなお金の数字で表現される。そこには曖昧さはみじんもない。そして、指標として重要である。それも、ふつうは組織の階層を上に行けば行くほど、コストの重要性が増し、その他の領域、たとえば技術品質や人的資源などの重要性が小さくなっていく。平社員ならばコストを度外視して技術的達成に打ちこんだりするかもしれないが、経営者でそう行動する人は稀だ。

したがって、経営層がプロジェクトを見るときは、たいていの場合はコスト指標が最大の管理指標になる。だから、自社のプロジェクトの遂行能力を向上しようとすると、まず採算向上が目標になり、原価管理のツールがまっさきに整備される傾向が強い。

ところで、採算というものは、コストだけ「管理」していれば、目標を達成できるものだろうか? じつは、採算の悪化している赤字プロジェクトの内部をよく調べてみると、もう少し別の事情が分かる。

たとえば、エンジニアリング業界での典型的な失敗プロジェクトは、次のようなパターンで起こる:まず、きびしい受注合戦の中で、かなり無理をした安値で受注する。そのままでは最初から赤字が予想されるので、プロマネは原価を下げるよう必死に努力する。この業界ではベンダー/サブコントラクターからの調達金額がコストのかなりの部分を占めている。そこで発注金額を下げるために、リスクはあるが安いベンダーを採用したり、あるいは延々と金額交渉に時間をかけざるをえない。

結果として、次第にプロジェクト・スケジュールが遅れてくる。おまけに、予算上の予備費を取れないために、プロマネはリスク要因に対処できる余地が無くなる。だが、プロジェクトでは予期できない突発事象が必ず起きるものだ。たとえば、安いベンダーの納品物がまるきり品質が低くて使えなかったり、あるいは途中で倒産してしまったり。こうして、プロジェクトはさらに遅れてしまう。しかたなく、スケジュールの挽回をはかるため要員をもっと投入する。こうしてコストはどんどんと膨らんでいく・・

おわかりだろうか。プロジェクトの採算が悪化する直接原因は、スケジュールにある。そして、スケジュール遅延の原因は、品質保証や調達の失敗にある。さらにその元をたどっていくと、コミュニケーションやリスクの問題につきあたる。

このように、ある管理領域で見つかった問題の根幹は、たいていは別の管理領域の失敗に起因するのだ。それは一種の玉突き現象に似ている。問題事象が最初に発見される場所は、コストである可能性が高い。数字で表わされ、鵜の目鷹の目でチェックされるからだ。しかし、コスト・オーバーランの原因は、たいていスケジュール遅延かスコープ漏れである。その原因は、さらに品質・調達・人的リソースの問題にある。そして、これらの遠因は、たいていリスク対処とコミュニケーションの失敗にあるのだ。だから私は、プロジェクト原価管理システムを構築すれば原価を管理できる、というような発想に反対なのである。

PMBOK Guideのいう管理領域は、すべてが独立で対等ではないことを知るべきだ。そこには、階層的な因果関係がある。それが、プロジェクトというものの、ダイナミクスを形づくっている。だからこそ、『プロジェクト統合管理』が必要だ、とPMIの先覚者たちは感じたのだろう。プロジェクト・マネジメントを考える者はみな、そのダイナミクス(動力学)をもっと真剣に学ばねばならないのだ。
# by Tomoichi_Sato | 2005-08-28 23:26 | プロジェクト・マネジメント | Comments(0)

ポルトガルで干ばつと山火事

外信によれば、ポルトガルでは数十年来の水不足の夏となり、大規模な山火事が何カ所も発生している。懸命な消火活動にもかかわらず、山火事の勢いはいっこうに衰えていない。国内の森林の約5%が消失したと言われる。
このままでは、ポルトガル第3の都市で、古い大学町コインブラにも被害が及ぶと予想されている。火災による犠牲者も14名にのぼった模様だ。
# by Tomoichi_Sato | 2005-08-27 00:50 | Comments(0)

プロジェクトにおける人的資源管理とは

アメリカの新聞連載マンガに"Dilbert"というのがある。作者はScott Adams。現代アメリカのハイテク企業における馬鹿馬鹿しさをとても辛らつに皮肉っており、毎日読むのを楽しみにしている(Webサイトでも1日遅れで読める)。ことに、主人公Dilbertと、彼の上司で無能なマネージャーとの対話をあつかった話は、いつも吹き出すほどに面白い。

米国のマンガは基本的に、時事問題を扱わないのが特徴だ。チャーリー・ブラウンのシリーズなどは、何十年前のものを読んでも、同じような感じで、いつまでも古びずに楽しめる。しかし、Dilbertはあえて最新のトピックや用語をネタに取り入れる。古くなる危険性をあえておかしつつも、ビビッドな問題意識をギャグにしているわけだ。

私の好きな話の一つに、Aliceという女性のベテランSEが、キャリアアップを望む若い事務職の女の子に、仕事について説明する話がある。「エンジニアになるには、何年もの訓練が要るの。」とAliceは説明する。「でも、エンジニアのボスになるのは、何の訓練も要らないのよ。」(ここで読者は、例の無能な上司を思い起こす)「あれって、スキル不要の、苦労のない労働なの。」これをきいて若い事務職の女の子は言う。「それなら、私にもできそうね。」

マネジメントは、何のスキルもトレーニングも無しで出来る仕事だ。そう断言すれば、反論する企業はいくらでもあるだろう。我が社では、かくかくの適性検査や昇格試験があり、またしかじかの管理者教育を実施している、と。しかし、少なからぬ日本人や米国人が、このDilbertのマンガに少しでも可笑しさを感じるのだとしたら、やはり無能な管理職が太平洋の向こう側にもこちら側にも大勢いることを示しているはずだ。

なぜ、マネジメントは"スキル不要の職能"と思われているのか。それは、マネジメントの地位と職能が不可分の状態になっているからだ。管理職の地位に配置されたら、部下を管理できる、と誰もが信じて疑わない。部下を管理するとは何か。部下に命令や目標を与え、部下を評価して賃金の格付けをすることだ、と思われている--普通は。

だが、プロジェクトはちがう。「プロジェクト・マネージャーは管理する専門の職能だが、地位ではなく単なる役割だ」などと言うと、皆が目を白黒させてしまう。職能と地位を分離して考えられないからだ。

年功序列の日本企業では、管理者の地位にはある程度、経験年数の裏書きがある。しかし会社の創始者の息子が『世襲』するケースもある。日本には、上場しているが内実は同族企業、という会社も多いので、そういうところでは、キャリアのない「若様」が、ポンと重要な地位につくことがある。地位につけば、すぐに管理の仕事を始める。こういう世界に働いていると、たしかに「管理はスキル不要の商売」と思いたくなる。じつは米国にだって欧州にだって世襲の会社は多い。だから彼らだって、同じように考えてるだろう。

しかし、ゴーイング・コンサーン、すなわち継続性が自己目的である企業とちがい、プロジェクトとはあくまでも特定目的を達成するための時限的な営為である。明確な目的を持つ組織では、管理者は「管理機能」を果すことが要求される。世襲とか年功序列だけで管理者を決めることは合理性に欠ける。そこで、しだいに地位と管理職能との分化か起こってくる。

さきほど、管理とは部下に命令や目標を与え、部下を評価して賃金の格付けをすることだ、と書いたが、じつは前半がマネジメント、後半が地位に関係する主な項目だ。後半はサラリーマンの生殺与奪の権限だが、これを抜きでどこまで人を動かすことができるかどうかが、プロジェクト・マネージャーにとって問われる『人的資源管理』の手腕なのである。そして、もしも失敗したら、その結果はプロジェクトの品質やスケジュールの失敗に現れてくるのだ(昇進や給与査定はプロジェクトとは関係ない領域だからである)。

PMBOK Guideは「マネジメントの9領域」を定義したが、じつは、プロジェクト管理の9領域は、このような形で、それぞれが独立しておらず、ある領域での失敗が別の領域に結果として現れてくるような関係性を持っている。このことについては、長くなってきたので、また次回語ろう。
# by Tomoichi_Sato | 2005-08-21 23:38 | プロジェクト・マネジメント | Comments(0)

プロジェクト採算管理は重要か

はたしてプロジェクトの採算管理は本当に重要か、などというと、常識知らずのレッテルを貼られるかもしれない。とくに、受託開発をビジネスとしているシステム・インテグレーター(SIer)ではそうだ。システム開発プロジェクトは一つ間違うと、の単位で赤字が発生し、他の数十のプロジェクトで稼いだ利益が吹っ飛びかねない。

だからプロジェクトの綿密な採算管理は必須だ。個別のプロジェクトがいかなる採算状況にあるのかを、マネジメントの側がチェックできる仕組みが求められている。いや、それだけでなく、部門単位でも収支の集計を行なって、採算で目標管理するべきだ--こういう理由から、最近、大手のSIerではプロジェクト採算管理システムの構築が活発だ。そもそも、システム開発はお手のものだから、自社ニーズにマッチした仕組みを自社内で作ってしまおう。そう考えられておられる会社もかなりある。

でも、ちょっと待ってほしい。かりにあなたが、見知らぬ街でタクシーに乗っているとする。運転手に行き先を告げたが、いつ着くのか、いくらかかるのか、あなたはよく分からない。目安の時間と値段は、あるいは事前にたずねることもできただろう。しかし現実は道路渋滞のために、別の道を通っていたりする。そもそも、運転手は十分信用できるのかどうか。わざと回り道をして、とんでもない料金を請求するのではないか・・・

そんな疑いを持っているとき、あなたは、タクシーの料金メーター・システムが正確であれば大丈夫だ、と思うだろうか? 着いたときにメーターを見て、金額に驚きはしないだろうか? いやいや、乗っている最中も、3分おきにメーターを見て料金をチェックしているから問題はないのだ、と考えるのだろうか? でも、目的地まであと何㎞あるのか分からないのに、現地点までの料金だけ正確に把握したからといって、いったい何の足しになるのだろうか?

プロジェクトの採算管理システムが重要だと信じている人は、タクシーの料金メーターをにらみつづけている乗客によく似ている。すでに過ぎてしまった結果だけを管理しているのだ。そんなのは「管理」の名に値しない。管理というからには、これから先の行為をどうすべきなのか、判断し指示できなければならないからだ。

そのためには、現時点までに費やしたコストと、現時点における進捗データが、完全にリンクしていなければ意味がない。タクシーでいえば、現在地から目的地までの距離が、リアルタイムに正確に分かっている必要がある。そうなれば、あといくら料金がかかって、最終的にいつ着くのかを推定できるだろう。おかしければ運転手に軌道修正を要求できる。そのためには、GPSとカーナビを積んでいるタクシーを選ぶべきだ。

同様に、プロジェクト採算管理システムを構築するのだったら、プロジェクトの進捗把握と残作業量を同時につかまえられる仕組みにしなければならない。進捗管理とは、「どれだけ進んだか(工数を費やしたか)」ではなく、「あとどれだけ仕事が残っているのか」で測るべきものだからだ。

その点は大丈夫さ。我が社はプロマネから残工数やETC(Estimate to Complete=完了までの予想費用)をヒアリングして入力することになっているから。そう答えられた会社もある。でも、そのデータは、リアルタイムですか?

多くの会社では、採算の集計は月次に行なわれる。工数集計は人事・勤怠管理システムから集計し、外注費は発注検収システムから受け取る仕組みになっており、そうした会計処理の多くが月次だからだ。だが、システム開発が短納期化して、6-9ヶ月のプロジェクトが珍しくなくなってきた昨今、はたしてこれでリアルタイムの把握といえるだろうか? へたをすれば、プロジェクト全体の1/6=17%の誤差が、集計遅れのために発生しているのだ。あなたは1日に4時間も遅れる時計を信用していられるだろうか? 私はごめんだ。

採算管理は進捗管理とセットでなければ意味はない。会計処理ではないのだから、1円単位の正確さは不要だ。しかし、プロジェクトの進捗状況にひもづいたコストが、最大でも1週間以内に集計されてこなければ役には立たない。そのためには、進捗と消費工数を、プロジェクト・チームの構成員全員が、毎日入力できるようになっている必要がある。外注作業についても、同様に進捗(出来高)がリアルタイムに見えるべきだ--「e工程マネージャー」の設計思想は、そこにある。

べつに我が製品だけを宣伝するつもりはないが、採算管理とはそういう観点から考えるべきものなのだ。プロジェクトの失敗は、たしかに採算割れに現れる。しかし、それは最終結果なのだ。タクシーの料金メーターだけを見ても、それは結果論に過ぎない。運転手が道を間違えているとき、それに途中で気づくためには、リアルタイムの進捗管理が必要なのである。
# by Tomoichi_Sato | 2005-07-13 23:03 | プロジェクト・マネジメント | Comments(0)

生産技術というお仕事

製造業にとって、製品開発のスピードは競争力のキーになる。製品開発は一般に、核となる要素技術の発明、ないし市場における新しい動向がきっかけになって始められる。むろん、業種によっては、毎年定常的に多数の新製品を出し続けるところも少なくない。そうしたケースでは、製品開発までの期間がきちんと「読める」状態にまで、管理レベルを上げていく必要がある。

プロジェクト・スケジューリングの技術に関わっているおかげで、最近は製品開発プロジェクトの相談に乗るケースが増えてきた。従来、製品開発とは「固有技術」だけの世界と思われていた。ところが、近年わずかづつではあるが、プロジェクト管理という「管理技術」も必要なのだと認識される企業が増えてきたようだ。

製品開発となると、BOMの話題に触れることも多い。今年のはじめに「BOM/部品表入門」という本を上梓したこともあって、いかにスムーズに新製品のBOMを構築できるかが議論のトピックになったりする。ことに、設計部品表(E-BOM)と製造部品表(M-BOM)が別立てになっている会社では、とくにその問題意識が強い。

ところで、製品開発プロジェクトの進め方を考える場合も、企業内のE-BOMとM-BOMの統合を進める場合も、どうやらキーになる部署があることに、最近気がついた。それが「生産技術部」である。名称は「生産企画課」だったり「製造技術センター」だったり、まちまちだが、ようするに製造工程を準備する職務をもった部署である。たいていの場合は本社ではなく工場にあり、しかも一種のスタッフ部門として扱われている。

この「生産技術」という職種が、その企業の中でどのように位置づけられているかが、どうやらスムーズな新製品開発や、BOMマスタ情報の信頼性確保に、大きく影響しているようなのだ。なぜか。それは、生産技術というお仕事の本質が、量産方法の設計と実現にあるからだ。

量産方法の設計とは何か。そもそも、新製品の青写真は、製品設計部門(たいていは本社機能にある)が図面に作る。この段階では、「何をつくるか」(What)が決まっているだけだ。しかし、製造業は、製品を低価格で安定して量産できてナンボの世界である。「いかにつくるか」(How)が大事なのだ。

そして、それを決めるのが生産技術である。ここの段階であらためて、どの材料をどう加工して、いかに組み立てるかを検討する。そして、試作品をつくって性能や加工性を評価する。標準作業時間を決めて製造単価を割り出す。ついで主要な部品のサプライヤーを決め、外注する部分を決め、必要な製造装置の仕様を決めてメーカーに発注し、それを工場に据え付ける。

そして量産試作が行なわれる。これが品質的にも経済的にもパスして、はじめて製品は「商品」になるのだ。これが生産技術の主要な仕事である。副次的な仕事として、既設の工場設備の保全とか、据付け工事などの工務管理、製造工程の改善、標準作業の見直しなどがある。

そして、残念ながら、日本の多くの企業では、この生産技術部門の地位が、決して高くないのだ。嘘だと思ったら、あなたの会社で経営工学科出身の学生をどこに配属するか、考えてみるといい。経営工学は生産技術の主要な基礎学問である。そのキャリアパスが定まっていないとしたら、それは生産技術の位置が曖昧なのだ。あるいは、生産技術部門出身の取締役の数を数えてほしい。大抵の製造業の会社では、出世するのは製品開発か営業か財務部門出身者だ。トヨタ自動車のように、生産企画がエリートコースで、出身者が社長になれるような会社は、極めて例外である。

製品開発を重視するというのなら、設計図を現実に落しこむための生産技術を重視していなくてはならない。餅の絵を描くのがいくら上手でも、食べられなければ役に立たない。そして、美味しい餅をつくのは、生産技術部門の役割なのである。
# by Tomoichi_Sato | 2005-06-15 13:49 | ビジネス | Comments(0)

プロジェクト・マネジメントの品質

ISO9000の品質システムは、大抵のいっぱしを気取る企業に導入され、運用されている。そして、疎まれてもいる。この標準規格自体は21世紀に入ってさらに思想を深化させ、今では品質マネジメントシステム(QMS)と自らを呼ぶようになった。しかし、率直に言って、日本企業でQMSを嬉々として運用している所には、私はほとんどお目にかかったことがない。皆が従っているが、内心は無用のものだ、と感じている。保険か税金のようなものだ、と。

私はいまだに、『品質』というものが良く分からない。私自身が製造業の品質管理部門で働いた経験がないせいだろう。工場建設のプロジェクトで品質検査をしたり、システム開発の統合テストを進めるやり方についてだったら、少しは分かっているつもりだ。構成図通りに製作され、指定の材料がつかわれ、仕様書通りに機能する。そういう検査が保証する品質は、『後ろ向き品質』と呼ばれる。軍隊の行進のように、皆がついて来ているかどうか、予定した到達点からずれていないかどうかを、後ろを向いてチェックする。フィードバック・コントロールである。

これに対して、『前向き品質』という概念がある。これは、より良き構造・材質・機能を「設計する」ことで品質を高めることを指す、と。そう参考書に記載もしたし(「プロジェクトマネージャ合格完全対策」)、そう人に言いもした。しかし、では、より良き品質とは何か。それは誰が決めるのか。どう設計で実現するのか。その方法論が必要だ。

ところで、最近北京に出張したおり、中国で活躍しておられる日本企業の方から面白い言葉を学んだ。それは『営業品質』だ。中国では最近まで訪問販売という形式が事実上法律で禁じられてきた。だから法人営業のスタイルがまだ確立していない。しかも営業マンは、周知の通り転職とジョブ・ホッピングの激しい雇用慣習の中で生きている。そこで、どうしても売上高に比例したインセンティブの比率を高くして、成果で競争させる方向にむかいがちだ。しかし、そうすると「営業品質が下がってしまう」というのだ。

営業の品質とは何か。セールスには素人の身で勝手に想像するならば、顧客との永続的な関係維持に寄与できる数々の要素なのだろう。見積を頼んでもすぐに出てこない。出ても間違いだらけで、こちらの意図を理解していない。発注すると納期に遅れる。間違った品物を送りつけてくる。数量が足らない。クレームをしても返事がない。なのに請求書だけは素早い--こんな営業マンがいたら、私だって二度と頼むものか、と思うだろう。こうしたケースは営業品質が悪い、と呼んでもよさそうだ。

この営業品質というものは、そのメーカーが出荷してくる製品自体の品質とは別のものだ。素晴らしい製品を出してくる、しかし営業は最低、そんな会社もじじつ存在する。しかたなく買うこともあるが、ユーザは幸せではない。

してみると、顧客満足とは、つぎの式で表わされるように思える。

 顧客満足=f(製品品質,営業品質)
 
関数型はよく分からぬが、おそらく足し算よりも掛け算に近い性質のものだろう。一方、製品品質は次のように定義される:

 製品品質=g(構造属性群,材質属性群,機能属性群・・)

関数型は、ユーザの求める用途や価値観によって左右されるが、おおむね足し算型であり、重みは機能属性が高そうだ。

それでは、価格はどこに入るのか? これは、営業属性だ。つまり、

 営業品質=h(価格,支払方法,納期,納品精度,クレーム対応度・・)
 
となる。関数型は、よく分からない。中国では、今のところ圧倒的に価格因子で決まるらしい。しかし日本や他の先進国では、あとの項目の方がもっと重要度を帯びてくるに違いない。

ところで、生産管理の世界では、よく「品質はプロセスで作りこめ」と言われる。製造して、最後に製品検査で後ろ向き品質チェックをするのではなく、製造プロセスの各段階で品質を確保していかなければいけない、という意味だ。だとすると、営業品質にも同じ思想が適用できるに違いない。

受注生産の製品で、プロセスを切り回すのはプロジェクト・マネジメントの役割である。自社製品の開発でも同じだ。そこで、あらためて「プロジェクト・マネジメントの品質」が問題になってくる。ちょっと長くなってきたので、この項はあらためて論じることにしよう。

(注:拙編著「プロジェクトマネージャ合格完全対策」で品質の章を執筆しているのは、畏友・齋藤登志勝氏である)
# by Tomoichi_Sato | 2005-05-21 23:59 | Comments(0)

 ★★ 都市ヴェネツィア フェルナン・ブローデル

フランスの歴史家ブローデルによる、肩の凝らない(しかし正確な)ヴェネツィアの歴史案内。地中海世界の専門家らしく、この小さな、しかし巨大な都市共和国とその領土を、歴史と地理の中にあざやかに定置してみせる。それは、さながらムラノ島のガラス細工のように多面的で、さまざまな角度からの光と反射に満ちて、美しい。

写真家クイーリチによる本書の写真も、とても美しい。もともと、きわめてピクチャレスクな水の街なのだ。しかし、その瞬間をフィルムの上に捉えるのは、別の力量である。

とはいえ、訳者・岩崎力のあとがきや細川周平の解説は蛇足であり、がらくただ。この名著に何の価値もつけ加えていない。
# by Tomoichi_Sato | 2005-03-19 23:38 | 書評 | Comments(0)

 ★★ 釈尊の生涯 中村元

1963年刊行の本書は、現在、平凡社ライブラリーの一冊として新書版で手に入る。出た当時は、かなり革命的な内容の本だったにちがいない。にもかかわらず、日本の仏教界がこれで大論争に巻き込まれたとか、刷新運動に展開したとか、あまり聞いたことがないのは、不思議なほどである。

著者は初期の仏典や関連資料をよりどころに、仏教の開祖であるシャカ族のゴータマ・シッダッタ、尊称ブッダの出生から出家・悟り・布教・臨終までを、ていねいにたどる。そこからは、一切の誇張や神秘や奇跡的エピソードが、後世の附託としてすべて除外され(ここが第一に論争的なところだ)、等身大の人間としての姿に描かれる。

また、ブッダ自身の思想的な深化も、数々の教典を歴史順に逆にたどるような手法で、その地層をより分けていく。たとえば、苦行を放棄して中道の悟りに至った、とふつうは言われているが、これも後世の仮託であるという。著者の立場は、

「仏教そのものは特定の教義というものがない。ゴータマ自身は自分の悟りの内容を定式化して説くことを欲せず、機縁に応じ、相手に応じて異なった説き方をした」

「ゴータマはその臨終においてさえも、仏教というものを説かなかった。彼の説いたのはいかなる思想家・宗教家でもあゆむべき真実の道である。ところが後世の教典作者は右の詩に接続して、仏教という特殊な教えをつくってしまったのである」

という説明に集約されている。こうした意見までをも容認する日本仏教というものの懐の深さに感心すべきなのか、こうした異見さえも無視する日本仏教というものの鈍感さを心配すべきなのか、私のような異教徒には、なかなか定かではないのである。
# by Tomoichi_Sato | 2005-03-14 23:44 | 書評

 ★★ WBS入門 Gregory T. Haugan著

WBS(Work Breakdown Structure)はプロジェクト・マネジメントの根幹をなす基準情報だ。プロジェクトの遂行に必要な全てのワークを階層的に構成したもので、通常はそれに整理番号を付番する。WBSはプロジェクトの計画段階で作成し、ワーク・スコープと、コスト見積と、作業期間(工数)見積のベースになる。そして遂行段階では、作業指示と進捗コントロール(コスト・スケジュール・スコープ変更)のマスタ・リストとして用いられる。終結段階ではWBSはデータ収集と分析のキー情報となる。

それくらい重要な概念であるWBSは、にもかかわらず良い参考書に恵まれていない。WBSが生まれたのは1960年代だから、ずいぶんと長いこと空白時代が続いていたわけだ。プロジェクト・マネジメントの標準的教科書PMBOK Guideも、2000年版まではWBSについてほとんど何も語っていない。したがって、本書が訳出されたのはまことに時宜にかなったことではある。

本書の長所は、原則論とチェックリストをきちんと押えた、教科書的な作りになっていることだろう。その原則はある意味ではシンプルで、たった2つしかない。それは、
「100%ルールを守れ」
「レベル2にプロジェクト・マネジメント要素を置け」
というものだ。100%ルールとは、ワークの親子関係をトップダウンで分解定義していくときに、子レベルのワークを全て集めたものは、親レベルのワークを100%カバーしていなければならない、という原則だ。東京都を23区に分解したら、区の合計は都のエリア全部をカバーしていなければならぬ訳だ。

レベル2にプロジェクト・マネジメント要素を、というのは、少し説明が必要だ。まず、この著者はプロジェクトをレベル1、その直下のワーク(「フェーズ」に相当する場合もある)をレベル2と数える。これは、WBSをレベル0から数えはじめるエンジニアリング業界などとは少し違う流儀だが、まあ習慣の問題だろう。そしてプロジェクトの最初のレベルに分解する際、忘れずに「プロジェクト・マネジメント」という作業を入れなさい、と説く。これはまことに正統な指摘だろう。というのも、実はこれを忘れるケースが、わが国でも非常に多いからだ。

つい最近も、日本を代表する大手企業のWBSを見せてもらったことがある。レベル1-4まで定義された詳細なものだったが、どこにもプロジェクト・マネジメントという仕事が見あたらない。思わず、「御社ではプロジェクト管理はなさらないのですか?」などと口走ってしまった(こんなことを口にするから、私は仕事をもらえないのだ)。まあ、WBSのどこにもプロジェクト・マネジメントが無かったら、上手にPM管理ができている訳もないのだから、ある意味ではつじつまが合っている。だが、そういう自覚のない大企業がこの国には山のようにあるのだ。

ただし、この本の読者は、著者が「WBSは成果物の階層分解を基本にせよ」という思想を基本にしていることに注意すべきである。そもそも、WBSの世界には、『成果物中心主義』と『作業(プロセス)中心主義』の二つがあって、長らく神学論争を繰り広げてきた歴史がある。著者Hauganは航空宇宙産業で、米国防総省相手のプロジェクト管理にたずさわってきた経歴の持ち主だ。MILのスペックは個別受注品の調達にフォーカスを当てた作りであるため、どうしても成果物中心主義になりがちである。

その点は著者も自覚していると見えて、プロジェクトを主目的によって「成果物」「サービス」「結果」の3タイプに分類し、それぞれに適したWBSのスタイルを提案している(「結果」タイプというのは、組織変革プロジェクトなどのように具体的な産出物が存在しない種類を指している)。そして、「サービス」「結果」タイプではプロセス的な要素を置いていい、としている(というか、そう置くしかないのだが)。

しかし、成果物をBOMのようにブレークダウンしていっただけでは、プロジェクト・マネジメントのような横断的要素が欠落してしまう。したがって、「レベル2にプロジェクト・マネジメント要素を置け」という要請が出てくるのである。

『成果物中心主義』と『作業(プロセス)中心主義』が論争を続けてきたということは、逆にいうと、そのどちらかだけではプロジェクトの記述は不十分なのである。これを克服するための方法は一つしかない。それは、成果物とプロセスの二次元のマトリクスを作成して、その平面の中でワーク・パッケージを作成する方法である。残念ながら、本書ではそこまでは書いていない。そもそも、そんな高等な技術を実行できる企業は、世界のエンジニアリング業界だってほんの1,2社しかいないのだから、まあ無理もないことだが。

本書は、WBS作成の入門者にとっては、それなりに実用的な参考書だ。ただし、原書にない日本版の「付録」が、180ページの本の4割を占めているのは、親切といえるのかどうか。経済産業省のCIO補佐官(外資系コンサル会社)のインタビューなど、なぜWBS入門書のおまけに付いているのか、少々原因不明である。また、付録2にはプロジェクト・マネジメントの初歩的な用語概念の解説もたくさんついているが、ちょっと中途半端であろう。用語の選び方を見ると、そもそもこの本がIT業界の人間をもっぱら読者として想定していることは、よく分かる。監訳者の伊藤衡氏も外資系ITメーカーを転々とした人のようだから、版元の翔泳社のねらいは明白である。翻訳の文章自体はこなれたレベルだが、細かな用語の選び方などは、若干不注意な点が見られて、ときどきちょっと惜しまれる。
# by Tomoichi_Sato | 2005-03-09 23:46 | 書評 | Comments(0)

★★★ 江崎浩司の世界

みなとみらいホールにて。
副題は「愛するがゆえに笛は飛ぶ」。まあ実に、江崎さんらしいタイトルではある。

曲目は、バレンタイン・デーにちなんで、第1部は江崎浩司・脚本編曲による音楽物語「シンデレラとウグイス夫婦」(エイク・クープラン・モーツァルト・クライスラーなどの小曲とナレーションで構成する)、第2部はヘンデル・スカルラッティ・ヴィヴァルディなどのバロック歌曲をオーボエで演奏する前半と、バッハ・モンティ・R=コルサコフ・モーツァルト・ドビュッシーなどのヴァイオリン曲やピアノ曲をリコーダーで(!)演奏する後半からなる。実に意欲的なプログラムだ。

それにしても、この人の笛の巧さは、まことに驚嘆すべきレベルだ。長久真実子さんのチェンバロ伴奏も良いが、「マルチ笛吹き職人」を自称する江崎さんの演奏のクオリティの高さには、心底驚いてしまう。リズムの正確さ、音程やフレージングの絶妙さ、指使いの速さ(誰がいったい「くまんばちの飛行」や「チャルダッシュ」をあのスピードでリコーダーで演奏できるだろうか!)、ブレスの巧みさ、そして何よりも歌心の繊細な表現が素晴らしい。これほどのレベルのリコーダー奏者は、賭けたっていい、世界中を探しても、そうは居まい。

しかも、彼はどんどん上手くなってきている。今回出たばかりのCD「空飛ぶ笛」を買ってかえって聴いたが、彼がほんの3年前に録音した缶入りCD「Bath Herb & Music」と聴き比べてみると、その進歩の度合いが分かる。同じジャズ曲「煙が目にしみる」が入っているが、その差は明瞭だ。この人は最近2,3年で、はっきりと音楽とは何かをつかんできたのだ。小節線に区切られた音のかたまりではなく、歌うフレーズの生きた流れとして、音楽を表現できるようになっている。30代の人間の成長力というものだろう。

それほどのレベルの演奏会を、横浜みなとみらいの小ホールで、満員とはいえない人数の聴衆とともに、たったの3千円で聴けるのだ。この国の音楽環境の良さを感心するよりも、この国の音楽愛好家の耳のありかを疑ってしまう。本当にこれでいいのだろうか? 彼が先月タブラトゥーラで披露したオリジナル曲のタイトルに「だれもわかってくれないし」というのがあったが、まさに、彼の気分を表わしているに違いない。サントリー・ホールで、大真面目に「男はつらいよ」を演奏して、耳が化石になった石頭連中の顰蹙を買ったりした彼だ。成長しつつある彼の才能は、今やクラシックだの古楽だのといった枠の中に押し込めておくには、大きすぎるようになったのだ。

どうか、江崎さんのコンサートがあったら聴きに行ってほしい。これからも彼がどんどん新しい音楽に挑戦していけるようなチャンスに恵まれることを、私は切に祈っている。
# by Tomoichi_Sato | 2005-02-10 23:49 | 映画評・音楽評 | Comments(0)