人気ブログランキング |

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

所要時間の見積り--時間と期間の差

スケジュール計画立案の中心は、時間の見積だ。これから行なわなくてはならないタスク(課業)の所要時間をどう見積もるか。この正確さが、計画全体の信頼性を決めるといっても過言ではない。

タスクの時間見積には、一点見積と、三点見積法がある。一点見積とは、文字通り、作業時間を一点で見積もる方法だ。たとえば、「外部インタフェース設計」というタスクがあったとして、その作業時間は3週間、というたった一つの値を、いきなり見積もる。それが過去のデータを整理して求めた値だろうと、あるいは経験者が“エイヤー”で決めた値であろうと、最初から一点で答えを求める方法が、一点見積だ。生産計画手法としてのMRPが、BOM(部品表)に付随してもっている標準リードタイムは、その典型だ。

それに対して、三点見積法は、確率的変動に基礎をおいている。同じ作業を繰り返し行なっても、所要時間にはいろいろな幅がでる。そこで、所要時間の「最善値(=最短期間)」「最悪値(=最長期間)」「最頻値(=その期間でおわる頻度が最も高い値)」の三種類の数字を見積もる。そして、
 推定所要時間=(最善値+最悪値+4×最頻値)÷6
という式によって、所要時間を求める。

三点見積法は、PERTの歴史とともに生まれた。その背景には、所要時間はさまざまな外的要因によって変動するため、確率的にしか定まらないという思想がある。しかも、その変動の形は、平均値のまわりに対象に分布する正規分布ではなく、プラス側(右側)にダラ下がりとなる、非対称な分布だろうと考える。その一つのモデルとしてベータ分布を用いると、上記の式が得られるのである。

しかし、この二種類の時間見積法には、ともに欠点がある。それは、総所要期間と純作業時間の区別が十分にされていない点だ。

総所要期間(elapsed time)とは何か。それは、タスクにとりかかってから、それが完了するまでの、全体の期間だ。「総所要期間=終了時刻-開始時刻」と定義してもよい。一方、純作業時間(duration)とは、作業者がそのタスクを完遂するために、本当にそれにかかわっている時間だ。前者は後者よりも、通常長い。総所要期間≧純作業時間となるのが普通だ。

それでは、なぜその両者に差が出るのか。プロジェクト・マネジメントの教科書的ガイドブック「PMBOK Guide」では、コンクリートの養生作業を例にとって、実質2日間のdurationで終わるはずの作業も、金曜日に始めたら週末の二日間の休日のために月曜日いっぱいかかり、実質4日間のelapsed timeになるかもしれない、などと説明する。これは、カレンダー日数と、終業日数の違いから来る、単純な例だ。

しかし、差異の本当の原因は、じつは作業者のマルチ・タスキングから来ることが多い。作業者が複数のプロジェクトのタスクに従事しているとき、おのおののタスクに着手から完了までつねに没頭できるケースはまれである。往々にして、別のプロジェクトの用件の邪魔が入り、作業を中断したりスイッチしなければならない。このために、総所要期間≧純作業時間となるのである。

かりに一歩譲って、マルチタスクによる割り込みや時間の分散がなく、担当者がつねに一時に一つのプロジェクト・タスクに従事したとしても、総所要期間≧純作業時間 となる場合がある。それは、その担当者の決済箱にたくさんのタスクが入ってきて、処理待ちの行列を作っているときである。

これはちょうど、大病院は3時間待ち・3分治療だ、という皮肉と同じ現象である。一人一人の患者に対する医師の作業時間は3分だ。決して複数の患者をマルチタスク的に並行して診ているわけではない。しかし、大勢の待ち行列のために、患者の側から見ると作業期間は3時間になってしまう。

プロジェクトにもこれと同様の事象がおこる。特定の繁忙部署やボトルネック工程の前には、長い行列ができている。PERT/CPMの弱点は、ここだ。クリティカル・パスは純作業時間ではなく、総作業期間の長さで決まる。しかし、この例のような状況では、一つのプロジェクトの中だけを見ても、クリティカル・パスは定まらない。かといって、『平均滞留率』のような曖昧な指標にたよるのも、ありがたくなかろう。

プロジェクト・スケジューリングにも、複数のプロジェクトを同時に計画し、うまく優先順位法や山崩しのできるツールが求められているのは、このためなのである。もっともその場合でも、プロジェクト間のトレードオフは、計画者の判断が必要になるのであるが。
by Tomoichi_Sato | 2011-08-03 23:22 | プロジェクト・マネジメント | Comments(0)

仕事の最小単位(2)--アクティビティのパフォーマンスを測る

アクティビティが『お仕事の最小単位』であり、マネジメントの基本部品であることは前回の説明でご理解いただけたと思う。このアクティビティは、ときに「タスク」と呼ばれることもある。わたしも以前はタスクという呼び名の方を使うことが多かった。だが、プロジェクト・スケジューリング(特にPERT/CPM)の理論では伝統的に「アクティビティ」の語が用いられてきたこと、さらにPMIのPMBOK Guide(R)が、activityよりもっと細かな日々の雑務を"daily task"と呼んでいることなどを考え合わせて、このように語法を変えることにした。

ちなみに生産スケジューリングの分野では、アクティビティという語はあまり使われず、ほぼ同じ概念が「タスク」とか「オペレーション」とか、あるいは「オーダー」と呼ばれたりする。もっとも、プロジェクト・マネジメント理論では仕事を中心に、そのインプットとアウトプットとして材料や成果物がある、と捉えるのに対し、生産スケジューリングでは逆に、材料や成果物など(つまりマテリアル)が視点の中心で、その材料を成果物につなげる媒介としてタスク/オペレーションを考える伝統が強かった。つまりモノが主役で作業は脇役な訳である。わたしはこのような物質中心の思考を転換したくて、あえて作業を抽象化した「工順」という概念を中心に据えようとしてきた。

ま、それはさておき、アクティビティに話を戻そう。「人に仕事をしてもらう」がマネジメントの基本であり、その指示する具体的実体がアクティビティである。アクティビティには、必要とするアウトプット・インプット・リソース・完了条件があり、それを明確にして指示を出すわけだ。ところで、その結果として、アウトプットが出てくれば、それだけでOKだろうか? 単に仕事をしてもらうのは必要最低限なことだが、できればちゃんと仕事をしてもらいたいと思わないだろうか? でも、「ちゃんと」した仕事と、不手際な仕事とは、どこが違うのか。

それを決めるためには、仕事の手際を評価する尺度をもたなければならない。つまり、マネジメントにおいては、アクティビティのパフォーマンス指標が必要なわけである。

アクティビティの評価尺度として、誰もが真っ先に思いつくのはコストであろう。どれだけ低コストで結果を出せるか。たとえば、あなたが、自分のプロジェクト・チームの立ち上げのために、作業用PCと机を10台ずつ用意する作業をサービス部門に頼むとする。どれだけ費用がかかるかは、たしかに重要なモノサシである。

しかし、コストさえ安ければそれでいい、と考えるほどあなたは単純ではない(はずだ)。もう一つ大事なものがある。それは納期だ。プロジェクト・ルームはなるべく早く立ち上げたい。社内の購買部門にはコストのみが優先事項だと信じている連中も多いけど、たかがPCの価格ネゴに半月かけて納品が1月後では、肝心の仕事が立ち上がらなくなってしまう。つまり、コストと並んで重要なアクティビティのパフォーマンス指標は、『時間』なのである。

コストと時間。少なくともこの二つは、アクティビティを測る必須の尺度となる。つまり、マネジメントはこの2軸を中心に仕事を導く必要がある。

ところで、コストにいったん話を戻すと、費用を考える場合、そのアクティビティを指示する先が、自社なのか、外注先なのか、あるいは自社でも別部門なのかで、少し話が異なってくる。ここでは一応、自社を前提に考えよう。では、自社のアクティビティのコストとは、本当は何を指すのか。

たとえば、あなたが自分のプロジェクトのテスト工程の一部を、他の部署の誰かに臨時に頼むケースを仮定しよう。ハードウェアのモジュールを10台ほど、出荷前の最終立会検査までに、事前に調整・テストしておかなければならない。計200以上の調整・テスト項目はリストにまとまっており、要領書も作成済みだ。でも追い込みの時期は忙しいので、力仕事の部分に手助けを頼むわけだ。この仕事を、他部門に依頼する。このとき、コストとは何だろうか。

原価管理の考え方では、原価は材料費・経費・そして労務費(人件費)からなる。材料(インプット)として必要なモノは10台のハードウェア・モジュールだが、これは支給するので費用はゼロだ(すでに製造アクティビティで計上済み)。試験器も会社の備品として持っている。問題は隣の部門の人件費である。

人件費のコスト化は、会社の取り決めにも依存している。本社の人件費は全部、一般管理費として丼勘定の中においている企業も、いまだにとても多い。こういう会社では、誰がどれだけ労力をかけようと、見かけ上は「タダ」である。他方、ホワイトカラーの時間をかなり細かく集計している企業もある。後者の場合、他部門の人件費も、その作業時間に単価(賃率)をかける形で集計される。

かりに、あなたの会社はとても先進的で(あるいは、とてもケチで)、各人がどのプロジェクトのどのアクティビティで何時間使ったかを、タイムシート上ですべて把握していると仮定しよう。そうすると、これでテスト作業に借り出された人たちの時間数が分かるから、賃率をかけると人件費が計算できる。ちなみに、日本企業のホワイトカラーの賃率は1時間数千円から1万円程度の間に入るケースが多い(給料の差よりも、オーバーヘッドの乗せ方の基準の違いで、大きく差が出る)。

あなたの依頼したテスト項目を全部こなすのに必要な時間は、延べで約100時間だった。二人がかりで1週間ちょっとの作業量である。慣れている自分達がやれば、もっと手早かったのに、とあなたは思う。でもとにかく、2人の人的リソースを、実働で7日近く占有したのである。

必要なリソースの量。これがアクティビティの第3の評価指標なのである。単位は(リソース数)×(時間)で通常は測られる。そして、これに単価をかけると、リソースの費用になる。一方、投入できるリソース量を決めると、アクティビティ遂行に必要な所要期間のベースが推算できる。つまりリソース量は、コストと時間という、2つの主要なパフォーマンス指標をつなげるパラメータとなっているわけだ。

コスト(Cost)、時間(Time)、リソース量(Resources)。石油メジャーのShellなどでは、仕事の最小単位をアクティビティと呼ぶかわりに、これら三大指標の頭文字をとって、最近『CTR』と呼んだりしている。名は体を表す、面白い言い方である。どこに着目すればいいか、初級マネージャーにとっても明確である。そして、一つの仕事が終わるたびに、これら指標を計測し、前回述べたようなアクティビティの辞書に実績を記録してデータベース化していくのである。ここまで実現できたら、たしかに「マネジメント・システム」と呼んでも良いだろう。
by Tomoichi_Sato | 2011-01-27 07:15 | プロジェクト・マネジメント | Comments(0)

仕事の最小単位--アクティビティの構造を学ぶ

「マネジメント」という行為の、最も原初的な定義は“人に働いてもらう”ことである。人に働いてもらうことで、自己の、あるいは共通の目的を、達成する。自分自身で手を動かして自己の目的を達成することは、マネジメントとは呼ばない。単に作業とか行為と呼ばれる。

あなたがもし食卓で母親に「ねえ、そこのお塩とって。」と言って手渡しもらったら、あなたは、その瞬間だけは、母親をマネジメントしているのである。母親に働いてもらって、自分の目的を達したからだ。でも、何も言わない前に、母親が気を利かせて塩をとってくれたら、もちろんマネジメントしたことにはならない。そもそも、座っているだけで目の前に夕食が出てきたとしても、たぶんそれは母親が自発的に調理をしてくれたのであって、自分がわざわざ命令を下してやらせている行為ではない。はっきりした依頼や指示や命令の有無が、マネジメントと、自発的な協調行動との境界線になる。

「はっきりした依頼」とは何だろう? まずは、具体的な作業の内容である。なにかをとってもらうという行為は、大げさに言えば輸送の作業である。輸送であるからには、対象物(荷物)、現所在地、そして送り先が必要になる。“そこ”にある“塩”を“(自分の手元に)”とって、という事項を最低限伝えなければ、相手は動きようがない。

それが何かを作る作業だったら? たとえば玉子を焼いて欲しいとき、具体的に言うべきことはなんだろうか。まず、欲しいアウトプットを正確に伝えなければならない。目玉焼きなのか、厚焼きなのか、錦糸玉子なのか。卵1個分か2個分か、はたまた100個分なのか。味付けは濃いめか薄めか。つまり、アウトプットすべきマテリアルの種類・数量・品質属性を指定するわけである。

ついで指示すべきは、いつまでに欲しいのかである。今すぐなのか、夕食の時でいいのか、あるいは3日後のパーティの時の話をしているのか。つまり納期を指定するわけだ。

さらに、インプットを指定してやる必要があるだろう。材料である。相手が母親ならば、どこに何があるか全て承知している。しかし、アパートを訪ねてきた友人に依頼するときは、「卵は冷蔵庫にあるし、油と調味料は食器棚の横に」と教えてやらなければなるまい。自分で支給できないときは「来るときコンビニで買ってきて」と、相手による調達を頼ることになる。

アウトプットと、納期と、インプット。これだけでいいだろうか? 大事なものが、まだある。『リソース』である。リソースというのは、作業を完遂するために必要な道具や場所や用役のことを指す。フライパンはどこ? あ、それは流しの下だ。ガスレンジは? えーと、電磁調理台しか無くてね・・

インプットとリソースの違いは、インプットが作業に使われて無くなる(アウトプットに転換する)のに対し、リソースは作業が終わったら解放されて元に戻ることだ。フライパンもガスレンジも、消えて無くなりはしない。ただし多少減耗する。そしてリソースは、作業中には占有される。つまり、いってみればリソースというのは化学反応における触媒のようなものなのである。

(念のため、注。ここでいうリソースとは、あくまで生産管理やプロジェクト・マネジメントでいう用語であり、「生産資源」などと訳されることもある。資源工学の世界で言う、海の底に眠っているかもしれない利用可能な物質やエネルギー類とは異なる)

リソースの中で、最も重要な種類のリソースは「人」である。作業に必要で、作業中は占有され、作業が終わったら解放される。これを英語で、Human resourceという。直訳すると人的資源だが、リクルートの場面では人材とか人財とか訳され、本社上層の会議室の中では要員・労働力などと呼ばれたりする。作業を終えて解放したときは多少減耗しているので、再生するためには、休ませたり眠らせたり食事をとらせたりお酒を飲ませておだてたりしなければならず、けっこう手間暇のかかるリソースである。

それでもまあ、ある局面では稀少な価値ももたらすことがあるので、大事にしなければならない。君でなきゃダメなんだ、君の作ったのを食べたいんだ・・・。「君の作る味噌汁を毎朝飲みたい。」--などという陳腐な文句が、いまどき意図した通り機能するかどうかは知らないが、リソースの指定はたいていの場合、重要である。

アウトプットと、インプットと、リソース。そして納期(これはもう少し一般化して、「完了条件」と言ってもいい)。これで完璧だろうか? じつは、マネジメント上、とても大事なことが抜けている。それは情報である。「指示情報」と「報告情報」のやりとりが必要だ。

指示情報とは、これまで列挙してきたアウトプット・インプット・リソース・完了条件などの伝達である。さらに、必要に応じてはレシピ(つまり設計情報ないし作業手順情報)も渡してやらなければならないかもしれない。もっとも、家族や、同一組織内では、お互いに了解している事項が多いので(これを「コンテキスト・レベルが高い」と形容する)、アウトプットと完了条件だけ指定すれば、あとはくだくだ言わなくても通用するはずである。

報告情報とは、完了時、ならびに(必要に応じ)途中途中で、作業がどういう状態であるか、アウトプットはどうなっているかを、指示した人=マネジメント主体に対して伝達するための情報である。誰かに働いてもらっているとき、終わったのか終わっていないのかも分からず、どういう状態にあるのかもさっぱり把握できていないのでは、「マネジメントしている」とは到底言えない。「お塩とって」のように、目の前で一瞬にて終わる作業ならば別だが、海を離れたところにいる誰かに2ヶ月かかる仕事をしてもらう際は、報告情報をもらわなければ困ってしまうだろう。

なお、ここまではインプットもアウトプットも物(マテリアル)である場合を記したが、作業の種類によっては、統計分析や企画書作成のように、インプットもアウトプットも情報やデータとなる場合もある。この場合、作業インプットとしての情報・データと、指示情報とは区別して理解すべきである。

ところで、指示/報告情報に関連して一点注意したいことがある。マネジメントにおいて、上記のアウトプット・インプット・リソース・完了条件を指定して依頼した場合は、原則として、依頼を受けた側がどのような手順で進めるか(すなわち相手の業務の「内部プロセス」)については、途中でいちいち口をはさまない。小姑のように、箸の上げ下ろしまでいちいち指示をしてはいけない。マネジメントというのは、際限のない命令-服従関係とは異なる。ある仕事のまとまりを、他者に指示したら、その内部には立ち入らず、相手の権限範囲とする。相手が自発的に改善できる領域を与える。これがマネジメントにおける「仕事の最小単位」の意味である。

プロジェクト・マネジメント理論において、この仕事の最小単位を『アクティビティ』と呼ぶ(「タスク」と呼ぶこともある)。WBSを作っていくとは、プロジェクト全体を、このようなアクティビティに階層的に分解していく過程を指している。アクティビティはいくらでも下位のサブ・アクティビティに際限なく分解可能だが、適切なレベルでとどめておく(最下位レベルのアクティビティを「ワーク・パッケージ」とも呼ぶ)。

仕事の最小単位--アクティビティの構造を学ぶ_e0058447_20282827.gif


そして、各アクティビティの、アウトプット・インプット・リソース・完了条件・指示情報・報告情報を明確に文書で規定しておく。できればリスト化し、あるいは辞書のようにデータベース化しておくと良い。そして誰でも必要に応じてアクセスできるようにしておく。

このような形でアクティビティを定義しないまま、共通経験の乏しい(コンテキスト・レベルの低い)海外子会社や外注先に仕事を依頼したって、うまく仕事がマネジメントできるわけがない。オフショア開発を上手に進めたかったら、自社の求めるアクティビティをきちんと規定するところから、まず始めるべきなのである。
by Tomoichi_Sato | 2011-01-16 20:36 | プロジェクト・マネジメント | Comments(0)

お知らせ:国際学会「ProMAC 2010」で発表します

今週、幕張で開催されるプロジェクト・マネジメント関係の国際学会「ProMAC 2010 Tokyo」において、10月14日(木)午後に、

  "Risk-based Project Value: Analysis on Budget Overrun and Progress Measurement"

のタイトルで講演発表を行います(英語)。
ご興味のある方は、よろしくご来聴ください。
by Tomoichi_Sato | 2010-10-12 07:36 | プロジェクト・マネジメント | Comments(0)

お知らせ:「スケジューリングシンポジウム2010」で講演発表します

日本中のスケジューリング分野の専門家・研究者・実務家が年1回集う、「スケジューリングシンポジウム」(主催:スケジューリング学会)をご存じでしょうか? 今年は第10周年記念として、「スケジューリングシンポジウム2010」が、きたる9月10日(金)・11日(土)、千代田区の法政大学で開催されます。
今回はわたしがオーガナイザとして「プロジェクト・マネジメント」のセッションを企画しています(11日14:30~)。

講演者とタイトルは次の通りです。

リスク確率に基づく新しいプロジェクト評価の理論的枠組みについて
 ○佐藤 知一(日揮(株))

エンジニアリング・プロジェクトにおける機器資材調達マネジメント
 ○橋野 秀紀(東洋エンジニアリング株式会社)

CCPMの受託型ITプロジェクトにおける導入事例
 ○岡村 孝彦(株式会社NTTデータ)

個別受注生産型の大型産業機械における工程計画システムの適用事例
 ○木村 早帆(株式会社 荏原製作所)

ご興味がある方はぜひご来場ください。
by Tomoichi_Sato | 2010-08-31 00:16 | プロジェクト・マネジメント | Comments(0)

バッファー・マネジメントとは何か

プロジェクトの計画作業は大きく二段階に分かれる。前半はスコープ定義で、プロジェクトを構成するアクティビティを洗い出し、達成すべき仕事の範囲全体を網羅しカバーする。このアクティビティを階層的に構成して整理番号を付番したものがWBSである。後半は、各アクティビティに必要なリソース・時間・コストを見積り、アクティビティの順序(論理的関係)にしたがって、ロジック・ネットワークを作成する。これがプロジェクトのタイム・テーブル(工程表)のベースとなる。これがスケジューリングである。

プロジェクトを表すアクティビティ・ロジック・ネットワークの始点から終点までを結ぶさまざまな経路のうち、最長のものをクリティカル・パスと呼ぶことはよく知られている。プロジェクト全体の所要期間(工期)は、クリティカル・パスよりも短くすることはできない。ここまではまあ、ある意味で基本である。

さて、プロジェクトの期限ないし納期設定を考える時、そこに自由度がある場合と、外部から制約条件として与えられる場合がある。受注ビジネスの中で生きている人は、「納期とは客先から与えられた制約条件だ」と考えることが多いだろう。契約によっては、納期遅延に対してペナルティ条項がついていることもある。そうでなくとも、納期に遅れたら信用を失い、次の受注機会には不利になる、と考えられる。

一方、新製品開発のように、自社が発案した自発型プロジェクトでは、納期はある程度、自ら設定できる。なお、英語では自発型プロジェクトをInternal Project、受注型プロジェクトをExternal Projectと呼んで区別する。ただし、自発型であっても、新製品の納期が展示会やフェアーなどの期日にしばられることはある。あるいは、対外発表の時期が、上からぽーんと鶴の一声のように下りてくることもあろう。いずれにせよ、自発型の場合、納期に多少の自由度があるケースが多い。

さて、自分が納期を設定できるときは、クリティカル・パスの長さで決めるべきだろうか。たとえば、クリティカル・パスの長さが120日ならば、納期は120日と宣言して良いだろうか。答えは、NOである。なぜなら、クリティカル・パスの長さとは、プロジェクトが達成可能な『最短の期間』だからだ。計画段階ですべてを見通すことはできない。いろいろと予期せぬ事やらミスやらが、途中で生じてくるものである。こうした外乱・内乱(?)によって、スケジュールというのは常に遅れていく可能性がある。そこで、クリティカル・パス長に、最小限の適切な余裕日数を加えて、納期を設定する方が安全である。この、意図して追加した余裕日数のことを、「バッファー」と呼ぶ。

余裕日数としての「バッファー」と、PERT/CPM技法でいう「フロート日数」は、ときどき混乱して使われるので、注意が必要である。PERT/CPMのフロートは、そのアクティビティが遅延したときに、プロジェクト全体の工期に影響を与えるまでの日数を言う。フロートが5日とは、そのアクティビティが5日以上遅れたら、プロジェクトの納期が遅れてしまう事を意味する(フロートにはFree FloatとTotal Floatの二種類があるが、説明は省く)。そして、クリティカル・パス上のアクティビティはすべてフロート=0日である。フロートとは個々のアクティビティに付随する属性値だと理解してほしい。

これに対してバッファーとは、特定のアクティビティにぶら下がる性質のものではない。あくまで、全体のプロジェクト・マネジメントの観点から、意図して置かれるものである。「時間のムダとり--スケジュールのサバを切り捨てる」(2009/12/07)でも説明したとおり、適正なスケジューリングにおいては、(1)アクティビティ所要期間の冗長な部分をみつける、(2)それを捨てる(正味分のみにする)、(3)プロジェクト全体に必要最小限の冗長性を付け加える、という、ちょうど情報理論と類似した手続きを行う。このステップ(3)がバッファーなのである。バッファーは生産管理で言う、意図した在庫配置に相当する。

それでは、このバッファーを、アクティビティ・ネットワークのどこに配置すべきなのか。たとえば全体工程120日のプロジェクトに15日のバッファーを追加するとして、それはどこに置くべきか。細かく分割して、すべてのアクティビティに公平に配分したら、という考え方もあり得よう。いや、クリティカル・パス上のアクティビティだけに個別配分する、という案もある。だが、これらはあまりおすすめできない。前にも書いたが、バッファーには加法性が成り立たず、1日のバッファーを15個持つよりも、15日のバッファーを一箇所にまとめておく方が、ずっと安全なのだ。

じゃあ、まとめて最初か最後に置くのはどうか? 最初にバッファーを置く、というのは、言いかえると、プロジェクトがスタートしてから15日間は、何の作業にも着手しない、ということになる。これではバッファーとしての意味がない。したがって、プロジェクトの最後にまとめて置く、というのが正解となる。これを、「プロジェクト・バッファー」とも呼ぶ。

さて、プロジェクトを遂行していく上で生じるさまざまな遅れにより、このプロジェクト・バッファーは次第に消費されていく運命にある。そこで、プロマネは残りのバッファー日数をウォッチして、あと何日までなら納期に影響がでないか、常に見ていくことをお勧めする。このように、計画段階で上手にバッファーを配置設定し、実行段階でそれをウォッチし続けることを、CCPM技法では「バッファー・マネジメント」と呼んでいる。

この目的のために実行段階でしばしば使用されるツールとして、横軸にプロジェクトの経過日数(割合)をとり、縦軸にバッファー日数の消費(比率)をとって定期的にプロットする手法(バッファー・トレンド・グラフ)がある。理想的に言うならば、プロジェクトの進行割合に比例して、バッファー日数が消費されていく、という形になる。開始後40日たったらバッファーは5日消費され、開始後80日では10日消費されている、という具合だから、プロットされた点は斜めの直線になるだろう。しかし、現実はなかなかそうはいかず、ジグザグの線になる。

グラフ上で点が上の方に来る状態は、プロジェクトの進行に対してフロートの消費が著しく大きいことを意味している。そこで、グラフに原点を通る2本の線を書いて、プロット・エリアを3つに分け、下からグリーン・イエロー・レッドに分けることがよく行われる。信号の色である。プロットされた点が下の方、つまりグリーン・ゾーンなら安全、中間のイエローなら注意、上の方のレッドなら危険、という訳である。

このようにCCPM技法では、プロマネが個別のアクティビティ全てを進捗管理するなど無駄な労力であって、クリティカル・アクティビティとバッファー日数だけをきちんとコントロールしておき、あとの精神的余力は他の重要な事に取っておくべきだと考える。そうはいっても全体の進捗率計算が必要だ
バッファー・マネジメントとは何か_e0058447_0123895.gif
が、この「プロマネの注意は重要な事だけに向けるべき」というのは、とても良い提案だと私は思っている。

(なお、フロートのあるパスにおけるバッファーの置き方や、受注型で納期が外から与えられる場合のバッファーの考え方、さらに納期要求が実行可能期間より短いときにはどうすべきか、など関連する問題もあるが、長くなってしまったのでまた稿をあらためて書くことにしたい)

関連エントリ:
時間のムダとり--スケジュールのサバを切り捨てる
早期着手かジャストインタイムか
by Tomoichi_Sato | 2010-08-04 00:14 | プロジェクト・マネジメント | Comments(0)

“猫型プロジェクト”のマネジメント法

世の中のプロジェクトには二種類あることをご存じだろうか? プロジェクトといえば、最初にスコープをきちっと決めて計画を立て、プロジェクトマネージャが強力なリーダーシップを発揮し、チーム員をぐいぐい引っぱって進めていく・・・そんな風にすべきだとPMの教科書類には書いてあるし、私も参考書にそう書いてきた。そのために、EVMSだCPMだという技法もあるのだ、と。

たしかに、マスター・スケジュールも立てず、クリティカル・パスの何たるかも知らないでプロジェクトを始めるのは、海図も持たず舵取りの仕方も知らないまま船出をするようなものだ。これで無事に航海して目的地にたどりつけたら奇跡だろう。とはいえ、世の中には、そんな事例がいくらでもあるのも事実である(とくに某○○業界では・・)。

しかし、百戦錬磨のプロマネをもってしても、PMBOK Guideに書かれているような近代的技法の数々を適用しても、さっぱり成功しないプロジェクトというのも、実は存在する。スコープは不確定で、スケジュールは“可及的速やかに”とされており、予算の大枠は存在するが、細目を決めがたい・・・そんな種類のプロジェクトも、確かにある。たとえば、新しいカテゴリーの新製品を作るような仕事や、博覧会の展示パビリオンを作るような仕事がそれである。

ある米国のプロジェクトマネジメント・コンサルタントは、こうした種類のプロジェクトを“猫型プロジェクト”と呼んで区別することを提案している。PMBOK Guide風の伝統的なこわもての管理手法は、この種のプロジェクトには全く向かない、と言う。それは、猫に対して犬のしつけを強要するようなもので、相手はこちらの言うことを聞くどころか、そっぽを向いて去っていってしまう。

米国PMIが制定したPMBOK Guideは、どちらかというとスコープがかなり明確で、かつプロジェクトの内容が物量で規定されるようなタイプのプロジェクトを念頭に書いている。いってみれば一括請負型プロジェクトである。こうしたプロジェクトは、計画上の自由度が少ないが、管理対象の物量が多いため、計数管理手法と軍隊型のリーダーシップに向いている。これは“犬型プロジェクト”だ

しかし、猫型プロジェクトは性格が全く異なる。猫型プロジェクトは基本的に自由度が非常に大きいので、計画や予測より発明の要素が強い。白いキャンバスに絵を書くようなものだ。始めた時点では、どこにたどり着くか、プロマネを含めて誰もよく分からないのだ。ここには命令の原則は通用しない。猫は呼んでも来ないし命令も聞かない。自分の気ままな思いつきで行動する。どこに行くか分からない。猫のように気ままなのだ。

猫型プロジェクトの難しさは、自由度が大きい条件下で、発想をどう育てるかという難しさである。そこに必要な手法は、軍隊式チームワークではなく、思いつきを生み出すためのコミュニティ・マネジメントであるという。そして、そのための手法の一つとして、『ジャーナル』を発行することを進めている。英語のJournalはもともと、語源的には“日々の”というニュアンスがある。毎日起きることを、時系列的に、ないしは日誌的に編集したものがジャーナルの原型である。そして、こういう仕事に従事する人を「ジャーナリスト」とよぶ。

このコンサルタントの処方箋はつまり、プロジェクトの中で毎日起きている出来事やアイデアやインプットなどを、関わるチームの全員にできるだけ毎日、伝えて共有することを勧めているわけだ。まあ最近では、それに向いたTwitterだのSNSだのといった仕組みが発達している。こうした情報共有系を活用して、なるべく皆のベクトルを一つに合わせてシナジーを生み出すことがコツなのだろう。

PMBOK Guideは、プロジェクト・マネジメントの世界に標準的な概念やプロセスを確立したという意味では、まことに画期的なものである。その功績は誰も否定しない。しかし、PMBOK Guideには「プロジェクトの分類学」が欠けているという不満をずっと私は感じている。プロジェクトには大規模なものも小規模なものもあり、受託型のものも自発的なものもある。そして、スコープが明確でハードな「犬型」と、目標も曖昧模糊としたソフトな「猫型」がある。これらは、みな適したマネジメント手法が違うのである。

にもかかわらず、“誰にもフィットするワンサイズ衣料品”のような解を、PMBOK Guideは提供しようとする。そうしたソリューションがあるかのような信念ないし誤解をふりまいている。そして、読む側もみな、自分をその衣服の型紙に合わせようと、肩をすくめたり首を伸ばしたりしているのではないか。だが思い出してもらいたい。PMBOK Guideを'80年代の終わりに着手した人たちは、米国の防衛宇宙産業とエンジニアリング産業が中心だった。彼らのビジネスは、巨大で、複雑で、スコープが明確に定義されていて、請負型で遂行するタイプのプロジェクトだったのだ。そうしたバイアスは、伏流する地下水のように、あの『標準書』のあちこちににじみ出している。

多くのプロジェクトマネジメントの解説書は、どうもPMBOK Guide的プロジェクト観に偏りすぎていると、私は思う。プロジェクトの世界は多様なのだ。その多様さを、そのまま活かせるようなマネジメント力こそが、求められていると言うべきだろう。


関連エントリー:

 一点集中型アプローチの限界
by Tomoichi_Sato | 2010-07-01 21:29 | プロジェクト・マネジメント | Comments(0)

役割(Role)としてのプロジェクト・マネージャー

世の中には、名刺に書きやすい資格と、そうでない資格がある。『弁護士』だとか『医学博士』だとかは、名刺に書くと箔がつくし、押し出しもきく。『技術士』や『不動産鑑定士』はそれよりやや専門的で地味な印象だが、その道の人は誰もが知るプロフェッショナルである。これに比べて、『漢字検定1級』とか『囲碁5段』とかは、知識レベルの深さでも資格取得の難易度の点でもひけをとらないはずだが、なぜか名刺に書く人は少ない。不公平なことである。

私が持っている(そして参考書も書いていた)『プロジェクトマネージャ』というのもまた、名刺に書きにくい資格だ。なぜなら、この名称では、取得資格なんだか社内組織上の職位を表わしているんだか、区別がつかないからだ。げんに私も名刺には記していない。

せっかく資格を取っても名刺に載せられないとさびしいので、もう少し注釈をつけて書こうかと考える向きもあろう。すると、『経済産業省認定 情報処理技術者プロジェクトマネージャ』ということになるが、ずいぶん長くて場所ふさぎだ。おまけに名刺交換の時に、自己紹介の目的にいささか不便である。
「初めまして。じつは私は経済産業省認定情報処理技術者プロジェクトマネージャでして」
「ほう。あなたは経済産業省認定情報処理技術者プロジェクトマネージャの資格をお持ちですか。そういえば、昨日も別の経済産業省認定情報処理技術者プロジェクトマネージャの女性にお会いしましたが、この方がなかなか美人でしてな・・」
これでは、いつまでたっても話の本題に入れそうもない。

世の中に『社長』とか『課長』とかいう名前の資格制度があったらおかしい。それなのに、情報処理試験制度がこのような名称を選んだのは、想像するに、二つ理由がある。まず、プロジェクト・マネージャーが専門職であるという認識があったのだろう。たしかにある意味ではそうだ。マネジメントが専門職なのか管理職(総合職)なのかは、議論の余地があるはずだが。

もう一つは、プロジェクトが時限的な営為である以上、PMもまたパーマネントな(永続的な)職位ではあり得ないはず、という理解があったのではないか。社長や課長は、永続的な職位である。個人単位ではいつかはその職を去るだろうが、管理対象はゴーイング・コンサーンを旨とする企業組織である。何かの目的を完遂したら解散、というプロジェクト組織とは異なる。

おそらく、この2点に、従来型の企業組織がプロジェクト・マネージャーという職業を位置づける際の居心地のわるさ、困難さが集約されているように思う。PMとは職位(=地位・特権)なのか、職種(=専門性)なのか? また永続的な部門の管理者なのか、それとも部門長に管理される者なのか? そもそも、若いPMは、自分より先輩の専門職チーム員に、指示を出す権利があるのか?

こうした混乱は、プロジェクト組織の本質を理解していないから起こる。じつはPMとは職位でもなく職種でもなく、役割(Role)なのだ。役者が劇で役割を演じる、あるいはサッカーでアシストとシュートの役割を分担するように、プロジェクトという限られた目的の中で、最終的な意志決定の責任をになう「役割を負っている」のがPMなのである。プロジェクトが終わって、PMの任を降りたら、つぎは誰か別のPMの下で、別の「役割」につくかもしれない。それはPCM(プロジェクト・コントロール・マネージャー)やEM(エンジニアリング・マネージャー)という「役割」かもしれない。

プロジェクト・マネジメントは専門技能である。この点はいくら強調しても強調しすぎることはない。しかし、たしかに(2年も3年も続く巨大プロジェクトは例外として)PMという一時的な役割を職位のごとく名刺に書くのは、おかしい。それならば、専門技能の持ち主である人々を、どう呼ぶべきなのか。

私の勤務するエンジニアリング業界では、『プロジェクト・エンジニア』と呼んでいるが、ちょっとそっけない職種名称だ。PMIの"Project Management Professional"(PMP)とか、PMCCの"Project Management Specialist"(PMS)などの名称の方が、ずっと気がきいている。

だが名称はどうあれ、この『プロジェクト・エンジニア』は、PMになるための主要なキャリア・パスだ。最初は雑用じみた調整役からはじめて、しだいにEMだとかPCMを経験し、やがてはPMの役割を担えるようになっていく。私は、(たとえば)プログラマ→SE→リーダー→PMといった、固有技術の専門職が経験とともに、いつのまにかマネジメント職に「超進化」するような、よくある不可思議な進化論にはどうしてもなじめないのである。できればより多くの業界において、名称はどうあれ、プロジェクト・マネジメントの専門職種性が認知され、適切な「役割」を与えられるようになっていくことを、私は切に望んでいる。
by Tomoichi_Sato | 2010-06-20 23:23 | プロジェクト・マネジメント | Comments(0)

進捗を把握する3つの方法

言葉の通じぬ、見知らぬ土地でタクシーに乗った。こちらの告げた目的地を、運転手は分かったんだか分からないんだか曖昧な態度のまま、車を発進させる。しばらく乗ったところでやはり不安になり、「もう半分くらいは進んだのかな?」と口にしてみる。すると、隣に乗っていた若い後輩が気楽そうに答えた。「もう、2/3くらいまで来ていますよ。」「なんでわかるの?」「だって、メーター見てください。空港からだいたい30ユーロくらいって、言われたじゃないですか。もう20ユーロ分、走ってますもん。」

進捗を把握するのは、簡単なように見えて、案外むずかしい。それは、私たちが『進捗とは何か』を、本当には良く理解していないからだ--こう言ったら驚かれるだろうか。無論、このタクシーの例のように、目的地に向かっているかどうか分からないときに、メーターだけ見て進捗を測るのが無意味な事は、誰でも分かるだろう。では、次の例はどうだろうか。

まだ戦後間もない昭和25年、国会で「北海道開発法」が成立した。敗戦で海外の植民地をすべて失った日本に、ただ一つ残されていた未開の沃野が、じつは北海道だったのだ。この法律に伴って、「北海道開発庁」という役所が設立される。その北海道開発庁が中心となって、2年後の昭和27年に、北海道開発の『第一次五カ年計画』が開始する(余談だが、五カ年計画という名称はなんだか社会主義国を連想させる)。

その『第一次五カ年計画』は、農業・畜産奨励・土壌開発(機械力による客土)・道路・河川・港湾整備・・・を含む壮大な国家的プロジェクトであった。予算は、国費だけで800億円。半世紀以上前の金額だから、現在に直せば1兆円を超えるだろう。

ところで、それから5年経った昭和32年に、著名な物理学者でエッセイストでもある中谷宇吉郎博士(当時北大教授だった)が、文藝春秋に爆弾論文を発表する。「北海道開発に消えた八百億円 - われわれの税金をドブに捨てた事業の全貌」(昭和32年4月号)という、きわめてショッキングなタイトルのその論文で、中谷先生は、人口・農業統計などの数字を詳細に調べ、「人口増加・食糧増産・農家戸数の増加は、・・・いずれも達成率0であった」と断ずるのである。

この論文のおかげで、北海道開発庁は上を下への大騒ぎになったらしい。北海道開発庁(なぜかこのお役所の主要機能は霞ヶ関にあった)では、翌月、さっそく文藝春秋誌に反論を掲載する。開発庁の高官が書いたこの論文には、「開発計画は順調に進展している」と書かれている。なぜなら、「過去の年度で順調に予算を消化してきたからだ」・・・。

この論法が、タクシーに乗った後輩社員と同じく、おかしいのに気づかれただろうか。過去にどれだけお金を使って事業を進めて来ようが、目標に一歩も近づいていなかったら、進捗はゼロである。タクシー・メーターをいくらにらんでも、進捗が分からないように。

たしかに開発庁だって努力はしてきたにちがいない。そのこと自体について、異論はない。だが、進捗と、過去の努力は関係がないのだ。なぜなら、進捗とは、これまでどれだけ仕事をしたかではなく、「これから先、どれだけ仕事が残っているか」で測るべきものだからである。

それなのに、進捗の議論となると、タクシー・メーターを見ることばかりに集中するきらいが、ときどきある。メーターをどれだけ精度良くしようが、リアルタイムで1円単位まで測ろうが、それは(コスト管理には資するかもしれないが)進捗管理には関係ないのである。

あるいは、「使った費用」のかわりに「使った時間」で測りたがる誤解も、後を絶たない。10日間でおわるはずの仕事がある。今、8日目だ。だから進捗は8割です--これが間違いであることも、説明の要はないと思う。こんな論法が通用するのなら、9日目は9割、10日目には10割になる。10日目でも仕事が終わらなくて、11日目に突入したら、進捗は何割になるのか。11割か?

これが馬鹿げていることは、考えてみれば誰にも分かる(はずだ)。だから、実際の進み具合は、担当者にたずねてみるしかない。かくして、プロジェクト・マネージャーは週次ミーティングでチーム員や関係者を集めて、各人に「どこまで進みました?」と訪ねたりする。プロマネはその答えを持って机に戻り、Excelの計算表か何かに数字を入れて全体の進捗率を計算する。有名なプロジェクト・マネジメント・ソフトウェアにもたいてい、『Progress %』を入力する機能がついている。まあ、一番ポピュラーなやり方であろう。

だが、こうした問答で返ってくる進捗率が、“タクシー・メーター的な進捗率”でないという保証は何もない。さらに担当者のサバ読みなども紛れ込みやすい。だから、「」で質問する方法は、私自身はあまりお勧めしない。

では、何で測るべきなのか? もし進捗を定量的に測りたいのだったら、やるべきことははっきりしている。「残りの仕事量」を定量化することである。それを、全体像と比べて、あと何割残っているかを計算する。だが、これは繰返し性の高い業務では可能だが、個別性の高いプロジェクト的業務では、決してたやすくない。

そのことを理解した上で、次に思いつく方法は、率の代わりに、各人に『残日数』(完了まであと何日かかるか)を申告させる方法であろう。「これが進捗管理の唯一正しい方法だ!」と力説される大学の先生に、あるセミナーでお目にかかったこともある。でも、はたしてそうだろうか。これが進捗管理として信頼できるためには、各担当者が、残日数について信頼に足る見積能力を持っている、という前提がある。これは、成熟度の高い組織ではあり得るかもしれないが、すべての会社に当てはまるとは、到底言えない。だって、プロマネ自身、上司に同じ質問をたずねられたとき、希望的観測を述べたりすることもあるではないか。

これと同様の方法として、『完了見込日』を答えさせる方法もあるが、問題点はよく似ている。仕事にはまり込んでいる担当者に、客観的状況把握を期待するのは難しいと、私は思う。もしやるのなら、むしろ各担当者をマネージしているリーダーか、あるいはPMOに、完了見込日を推測させる方がベターかもしれない。しかしこうなると、「上は俺たちのいうことを信用していないのか」との感情的反発もあり得るし、手間もかかるという何点があるだろう。

残る、第3の方法がある。それは、「マイルストーン」を活用する手法である。プロジェクトのプロセスを計画時点で検討し、要所要所にマイルストーンを(できればそのクリティカル・パス上に)配置する。そして、そのマイルストーンに、進捗率を当てはめるのである。その率は、EVMSで用いるようなコスト基準(残るアクティビティのコストの比率)でも良いし、あるいは別の何らかの基準で決めても良い。とにかく関係者全員が、各マイルストーンについて、ある程度納得し合意できる進捗率を、定めておく。そして、そこを通過した時点で、“何%を達成”と公表するのである。

もしプロジェクトが大きければ、それを各アクティビティについても定義しておく。設計書作成のアクティビティならば、「設計条件の整理」→「設計計算」→「図面の作成」→「設計書本文の作成」→「検討・承認」といった、標準的な内部プロセスがあるはずである。それぞれに対して、内部進捗率を10%・30%・60%・80%・90%・100%といった具合に取り決めておく(組織内部で合意する)。そして、週次ミーティングで質問するときは、「何%か」を聞くかわりに、「今どこのステップか」をたずねるのである。これならば、回答者の主観やサバ読みを、少しは排除しやすい。

いずれにせよ、繰返し業務と違って、プロジェクトは個別性が高い。これはすなわち、見通しにリスクが伴っており、「終わってみないと本当はどれだけの仕事量だったか分からない」ことを意味している。すなわち、プロジェクト的な進捗管理には、かならずリスクに伴う精度の問題が付随することを忘れるべきではない。この問題には「正解」は存在しないのだ。あるのは、「納得感を持てる」方法のみなのである。
by Tomoichi_Sato | 2010-06-13 18:44 | プロジェクト・マネジメント | Comments(0)

経営工学会論文賞を受賞しました

お知らせ:

5月15日(土)に開催された日本経営工学会春季大会で、昨年発表した学術論文
Risk-based Project Value Analysis: A New Theoretical Framework for Project Management』 日本経営工学会論文誌 Vol. 59, No. 6, pp.437-442 (2009)
によって、2009年度の経営工学会論文賞を受賞しました。
by Tomoichi_Sato | 2010-05-16 23:35 | プロジェクト・マネジメント | Comments(2)