ワーク・パッケージ
ワーク・パッケージ
WBSの最下位のアクティビティを、「ワーク・パッケージ」とよぶことは、プロジェクト・マネジメントをちょっとでも勉強した人は知っていると思う。いうまでもないが、WBSとは、プロジェクトのスコープ(仕事の範囲)を、アクティビティに階層的に分解し、それに整理番号を付番したものである。
『プロジェクト』という業務は、それ自体では大きくて漠然として理解もハンドリングもしにくい。そこで、それをコントロール可能な小単位まで分解するのである。“大きすぎる問題は、小さな部分問題に分解して片付けろ”というのは、欧米人の得意とする発想であり戦略である。非常に分析的なアプローチと言えよう。
プロジェクトを、複数のアクティビティに分解する作業は、ある意味で、地図の上のぼんやりした領域を、そのカバーする市区町村によって数え上げる作業にも似ている。「この病院のサービスする地域」と問われて、○○区、××区、△△市某町・・とリストアップしてみると、だいたいのその姿が見えてくる。同様に、プロジェクトがカバーすべき活動範囲を、アクティビティ・リストに作ってみる。それが、プロジェクトの姿(スコープ)の『可視化』の第一歩である。
アクティビティ・リストは、ふつう、次のような表になる。
(1) アクティビティ1、(作業内容の説明)、担当者=誰々、期日=○月×日
(2) アクティビティ2、(作業内容の説明)、担当者=某々、期日=○月△日
・・・・・・・ ・・・ ・・・ ・・・
このようなアクティビティ・リストを作成して、その表をもとに各作業の分担を決め進捗を追いかける--これは、もっとも原始的なプロジェクト・マネジメントのあり方である。まさに、イロハのイだろう。アクティビティ・リストも作らない(作れない)ようでは、「プロジェクトをマネジメントしている」とは言えまい。
さて、ところでこのようなフラットなリストのままでは、いろいろと運用上の不便が生じる。たとえば、「基本設計」というアクティビティを進めていくうちに、「移行段階の運用設計」というような、より細かな作業の必要性が急に浮かび上がってきたりする。この両者は、並列にならべるのは何だか落ち着かない。一種の包含関係にあるからだ。では、どうすべきか?
答えは、アクティビティを階層化すればいいのである。アクティビティの下位概念として、サブ・アクティビティを考える。「移行段階の運用設計」は「基本設計」の下位にあたるアクティビティである、といった風にである。言いかえるならば、アクティビティというのはプロジェクトと同様に、さらにアクティビティに分解できると考えるのである。アクティビティは自己相似的だ、とも解釈できよう。
こうして、プロジェクトの全体範囲を表すための階層的アクティビティの構造が定義できる。これがWBSである。ちょうど、「当病院のサービス・エリア」をより明確に示すために、市よりも下の町丁目レベルで数え上げをするようなものである。
ついでにいうと、このとき、アクティビティの整理番号は必須である。社員に従業員番号があるように、プロジェクトにおけるコントロールの対象は、何であれ重複のない整理番号をつける。こんな事はある意味、英米においては常識以前の問題であって、だから誰もわざわざPMBOK
Guideになんか明記しないのである。
さて、そのようにプロジェクトを階層的にアクティビティに分解した結果を見た時、その最下位のレベルをワーク・パッケージと呼ぶわけである。地図が市町村・町丁目によって空白も重複もなく敷き詰められているように、プロジェクトの範囲は、ワーク・パッケージの総計になっている。
そして、各ワーク・パッケージにはそれぞれ、コストと、所要期間と、必要なリソースの情報が付随しているはずである。ワーク・パッケージのコストを集計すると、プロジェクト全体のコストになる。そしてコスト情報には、予定のコスト(予算)と実際のコスト(実績)が存在する。すなわち、ワーク・パッケージの意義とは、コスト・期間・リソースを集計し予実対比するための、アトムなのである。
このように考えると、ワーク・パッケージの『粒度』=大きさが重要であることが分かってくる。あるアクティビティは3ヶ月かかり、別のアクティビティは1日で終わる、というようなばらつきがある場合は、「粒度がそろっていない」と考えられる。粒度を適当にそろえる努力をしないと、コストや時間をコントロールしていく時の、集計の精度や意義が落ちていくのである。
じつは、ここがワーク・パッケージ作成の一番のポイントだと言っていい。というのは、アクティビティは(やろうとおもえば)いくらでも再分割していけるからだ。技術者は妙に律儀なところがあって、細かくすればするほど、“管理の精度が上がる”と信じたがる傾向がある。しかし、細かくしすぎると、むしろモニタリングやレポーティングの手間ばかりが増えて、管理のための管理に陥ってしまう。
たとえば、以前あるERPプロジェクトのWBSを見せてもらったことがあるのだが、全体納期は1年以上かかる大事業なのに、半日で終わりそうなアクティビティをたくさんWBSに書き込んでいる。そんなレベルまで、ほんとにプロマネさんはいちいち追いかけるんですか、と問いただしたくなる。私から見ると、それはワーク・パッケージというよりも、実装チェックリストの各項目のように思えたからである。
アクティビティ分解は、ある適切なレベルまでにとどめておく。そして、それ以下については、『デイリー・タスク』と見なして、各担当者にコントロールを委任しておく。これが、本来のあり方である。
そう考えてみると、ワーク・パッケージとは、「固有技術」と「プロジェクト・マネジメント」の境界面を示す、とも理解できる。ワーク・パッケージよりも下部(内部)には、プロマネはもはや立ち入らない。そこはもはや、担当者による固有技術の世界なのである。PMの仕事とは、そこよりも上位の領域、すなわちプロジェクトのワーク・パッケージへの切り分け、その論理的な順序関係づけ、予算や所要期間の設定、リワークやフォールバックへの準備、そしてコンティンジェンシー・リザーブやプロジェクト・バッファーの設定などであろう。そここそが、管理技術としての「マネジメント」の範囲だと考えられるのである。