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)

納期短縮三か条

私はタイム・コンサルタントである。「時間の悩み」を抱えるクライアントに対して、解決へのアプローチを示すことで、プロフェッショナルとしてのビジネスを成立させている・・・と、自己紹介には書きたい。できれば。

しかしまあ、現実はなかなかそう甘く行かない。タイム・マネジメントの仕組みを提案するだけでは、なかなかビジネスにはならないのだ。生産スケジューリングやプロジェクト・スケジューリングの仕事をしていてつくづく感じるのは、『やっぱりコスト削減が優先』という圧力の強さである。製造業や流通業向けのSCMシステム構築の課題は、物流費の削減が真っ先にくる。納期短縮は、「それもできたらやりたい」であって、部分目標でしかない。だから私は、パート・タイム・コンサルタントという存在だ。

コスト競争はすでに行き着くところまで行ってしまった。あとは非価格競争力の問題で、性能だとか品質だとかも大事だろうが、納期で勝負すべきだ。"Time is Money"にも書いたとおり、私の主張はこの点にある。

ところで、うっかり作りすぎてしまった製品は、在庫となって財務諸表に現れる。それも不思議なことに、さも資産であるかのように。ところが、納期を遅れて売り損なった注文は、財務諸表のどこにも現れない。だから、それは見えないコストとなり、経営の関心の外になる。こういう心理的メカニズムが、どこかで働いているにちがいない。

それではもし、そうした心理的な霧が晴れて、納期短縮が重要だと気づいたら、どうしたら良いのか。私だったら、3箇条の処方箋を書く。

(1)「隘路に集中すべし」

クリティカル・パス(隘路)を見つけ、その短縮に集中すること。いうまでもないが、クリティカル・パス以外の作業をいくら努力して短縮しても、全体の納期は早まらない。この原理を、皆が理解する必要がある。これはとくに、新製品開発の納期において大事だ。むろん、設計に手こずりがちな受注生産形態でも共通の処方だが。

全員の目標を、納期短縮に向けることが、何よりも重要である。設計部門は性能を、購買部門は資材コストを、製造部門は作業効率を第一に動いていたら、誰が納期に責任を持つのか?

(2)「進捗を皆に見せるべし」

進捗が見えると、事前に準備できる。じつは、これが大きいのだ。バトンリレーも、事前の助走が大事だろう。人間は賢い存在で、先読みができる。言われたことだけをやるロボットとは違う。多くの企業では、部門の壁や、事業所の地理的な分散によって、他の仕事の進捗が見えて来ない。これを見えるようにしてやるだけで、納期は1-2割程度短くなると言っても過言ではない。

進捗がいったん後退したら、その事実を直視することも重要だ。とくに設計業務は、環境変化や客先の気まぐれで、いったん決まったはずのことが元に戻ってしまうことが多い。「こういう手戻りが生じる業態では、プロジェクト・スケジューリングの道具など使えますか? 使えないでしょ?」などとセミナーで反論されたこともあるが、無論、使えるのである。

進捗というのは、“これまでどれだけ工数をかけたか(努力したか)”ではなく、“あとどれだけ仕事が残っているか”で測るべきものだからである。もし手戻りしたら、進捗率は下がるべきなのだ。それが事実なのだから、仕方がない。この質問者は、「進捗は下がってはいけない」という理屈(願望?)と現実把握を取り違えておられるのだろう。マネジメントというのは、客観的な事実認識からスタートすべきものなのだから。

(3)「時間はお金で買うものと思うべし」

納期短縮にはコストとリスクがつきまとう事を理解すること。納期を短縮するためには、ある程度先読みをして、準備や手配をかけておく必要がある。ここには推測が入るため、ずれや手戻りのリスクも生じる。急いだ分、余分なコストがかかってしまうのだ。これを逆に表現すれば、お金を節約しようとすると、時間がかかる、ということになる。

時間とお金との間には、トレードオフの関係がある。お金を取るか時間をとるか、マネジメントが指針を下すべきなのだ。「繁忙期には納期優先で考え、閑散期にはコスト優先で行こう」という顧客がいたが、これはとても立派なポリシーである。トレードオフの状況でどのような判断を下すべきかを定めた指針を、企業の「戦略」ないし「ポリシー」と呼ぶ。

そして、困ったことに、戦略もポリシーも持ち合わせていない会社が、じつはとても多いのだ。選ぶとなると必ず、目に見える「お金」になってしまう。だから私は、いつまでたっても、パート・タイム・コンサルタントでしかないのである。
# by Tomoichi_Sato | 2005-09-21 23:25 | サプライチェーン | Comments(0)

南蛮のみちⅠ 司馬遼太郎

「街道を行く」シリーズの1冊。この人の小説は、地の文章に解説や余談が多くて随筆みたいになりがちだが、随筆の方は多少の演出があってフィクティシャスに感じる。不思議な小説家だ。

日本人にとって、ながらく日本・唐・天竺の三つしかなかった文明世界に、突然飛び込んできたのが「南蛮」文明だった。しかも、面白いことに、その伝道の中心人物フランシスコ・ザビエルは、フランスでもスペインでもなく、バスクの人だった。そこで、この旅路の前半は、バスクという国をめざしてパリからフランス南西部を横切って進む。

そのバスク文化を理解するための第一の資料として、司馬遼太郎があげるのは、近代日本に宣教師としてやってきた、バスク出身のS・カンドウ神父の著作だ。「バスクは風と水と光の国だと形容される」とカンドウ神父は書く。そして、起源未詳のピレネー山脈先住民であるバスク民族の世界を、いとも魅力的に描き出す。騎士道精神と熱烈な信仰に支えられたザビエルは、その光輪の中に定置される。

バスク人は、見かけはフランス人やスペイン人とさほどちがわない。バスク名物のベレー帽も、フランス人の象徴のように思われている。彼らのアイデンティティを支えるものは、その気質と、バスク語だけである。スペイン語とは、バスク語の音韻の上に乗ったラテン語なのだが、そのスペイン王国からも、国民国家論を信奉するフランス共和国からも、存在を無視され迫害された歴史がある。

しかし、この旅行記は、そうした剣呑な雰囲気をうまく筆先でさばいて取り払い、ひたすら純朴で美しい「常世の国」バスクを描き出している。これを読んで、バスクに行きたくならない人は少ないだろうと思う。それだけ、司馬遼太郎が楽しんでいる旅行記と言えるだろう。
# by Tomoichi_Sato | 2005-09-18 15:18 | 書評 | Comments(0)

アメリカでハリケーンの被害

米国のメキシコ湾岸を襲ったハリケーンKatrinaは、史上最もひどい被害をもたらす結果となった。ニューオーリンズでは有名な旧市街French Quaterの堤防が決壊し、洪水状態となっている。上陸二日前には沿岸地帯に非常事態宣言が出され、80%の住民が避難したが、それでもかなりダメージを受けたようである。

このニュースで奇妙なのは、Katrinaが発生してからもしばらくの間、並みのクラスのハリケーンということで、さほど報道でも注目されていなかったことだ。CNNなどが騒ぎ出したのは、上陸する少し前からである。

米国のメキシコ湾岸は石油産出地帯で、沿岸には製油施設が並ぶが、その9割は操業停止状態に追い込まれた。このため、WTI原油価格は$70を突破して、史上最高値を更新した。一般消費者にとってはまさに泣き面に蜂だろう。
# by Tomoichi_Sato | 2005-08-31 12:58 | Comments(0)

スイスから東欧にかけて洪水

南欧とは逆に、スイスからドイツ東部、そしてルーマニアにかけて大雨になり、この夏は平年の5倍以上の降雨量があった。洪水や土砂崩れなどの災害で、スイス・ルーマニア・ブルガリア合わせて数十名の犠牲者が出た模様である。ドイツでも河川の氾濫で水浸しになる都市が出ている。
# by Tomoichi_Sato | 2005-08-29 22:55 | Comments(0)

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



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)