WBSはプロジェクト組織を規定する

いま、これからあるプロジェクトを開始するところだと仮定しよう。あなたはプロマネとして、仕事のやるべき範囲(=スコープ)を明確にし、WBSを作ろうとしている。プロジェクトの種類はあえて問わないが、ここではITプロジェクトを想定しよう。成果物は情報システムで、A・B・Cの3つの主要機能モジュールからなる、とする。各機能モジュールはそれぞれ、システム設計→プログラミング→テスト、という仕事のプロセスを経て、できあがる。

さて、3つの機能モジュール×3段階の作業プロセスだから、合計9個のアクティビティからなるプロジェクトである。これをWBSに構成するとき、二種類の表現が考えられる(IT系の仕事になじみのない人は、「システム設計」「プログラミング」「テスト」をそれぞれ、「コンセプト開発」「製品設計」「量産準備」だとか、「機械設計」「資材調達」「製造」とか、自分に理解しやすい業務におきかえてみてほしい)。

WBS・案1
1 モジュールA
1.1 モジュールAを設計する
1.2 モジュールAをプログラミングする
1.3 モジュールAをテストする
2 モジュールB
2.1 モジュールBを設計する
2.2 モジュールBをプログラミングする
2.3 モジュールBをテストする
3 モジュールC
3.1 モジュールCを設計する
3.2 モジュールCをプログラミングする
3.3 モジュールCをテストする

WBS・案2
1 設計
1.1 モジュールAを設計する
1.2 モジュールBを設計する
1.3 モジュールCを設計する
2 プログラミング
2.1 モジュールAをプログラミングする
2.2 モジュールBをプログラミングする
2.3 モジュールCをプログラミングする
3 テスト
3.1 モジュールAをテストする
3.2 モジュールBをテストする
3.3 モジュールCをテストする

さて、上記二つの案のうち、どちらをとるべきだろうか? あるいは、両者は互換的(convertible)で、内容的に差はない、と考えるべきだろうか。

ちなみに、互換的とは、こういうことである:上のWBSは、1.2, 3.2といった、単なる順番に依存したコーディング体系になっている。しかし、対象モジュールをA, B ,Cと表記し、作業プロセスを1, 2, 3とすれば、「モジュールAをテストする」アクティビティはA-3というコードになる。案1と案2の差は、A-3と表記するか3-Aと表記するかの違いであって、両者は機械的にコンバート可能だから、要するに同じことだ、という意見である。なかなかスマートな見解ではある。

ところが、両者は実務的には大違いなのだ。プロジェクトの生みだす成果物の品質や納期だって、大きな差が出るだろう。なぜだろうか? 

考えてみると、案1の方は、アクティビティをモジュール単位でまとめている。つまり、成果物の構成に依存したWBSの作り方になっている(もう少し製造業風に表現するなら、部品表=BOMに準じた構成になっている)。こうした成果物の構成は、プロジェクトごとに変わるわけだから、成果物中心型のWBSも、当然ながら毎回かなり異なるわけだ。なお、WBSの世界では、プロジェクトの直下の階層をレベル1、さらにその下の階層をレベル2という風に呼ぶ習慣である。成果物中心型WBSは、第1レベルの構成がプロジェクトごとに毎回変わるわけだ。

他方、案2は、業務のプロセス中心のWBSであることが分かる。業務プロセスは成果物のいかんにかかわらず、共通性が高い。その結果、WBSのレベル1の構成は、どのプロジェクトでもほとんど変わらない、ということになる。

となると、案2の方が優れているのか? いやいや、そう簡単に結論に飛びつかないでほしい。ちなみに米国ではかつて、WBSを成果物中心で構成するかプロセス中心で構成すべきかについて、かなり議論になったと聞く。その議論はまだ決着していないらしく、PMIの出したモノグラフも、たしか両方のパターンが例として記述されていたと記憶する。

だが、こうした論争は、大事なポイントを忘れているのだ。それは「責任者」のことである。

WBSの構成図を書いたら、次にプロマネがすることは、各アクティビティの担当責任者を決めていくことだ。そして、図なり表なりに、それを記入していくだろう。このとき、レベル1もレベル2も、当然ながら責任者の名前を決めていくことになる。

すると、どうだろう。仮に「モジュールAをテストする」アクティビティ(=レベル2)の担当者はつねに佐藤君だったとしても、その上位にあたるレベル1の担当者は、「Aモジュール」に責任を持つのか、それとも「テスト」に責任を持つ人なのか、守備範囲が違ってくることになる。前者(案1のケース)なら“Bモジュールがどうなっていようと自分は責任ない”との立場だろうし、後者(案2)なら、“設計のよしあしについては感知しない”スタンスになるだろう。当然、自分の部下の使い方だって、違ってくる。

すなわち、二つのWBSは、組織図にすると、こんな違いになるのだ。

e0058447_036125.gif


そして、このような組織の違いは、何を生みだすだろうか。このプロジェクトのロジック・ネットワーク(アロー・ダイアグラム)を描いてみれば、一目瞭然だ。成果物中心型なら、スケジュール的にも各モジュールはばらばらに進行していきがちである。他方、プロセス中心型WBSならば、設計全体に対する責任者がいるわけだから、彼または彼女は、設計が一応まとまって全体の整合性をとってから、先に進もうとするだろう。つまり、プロジェクトはフェーズ単位に進行していくことになるはずだ。

e0058447_0363886.gif


そして、プロマネであるあなたは、自分のプロジェクトをどのようにマネージしたいかによって、どちらのWBSをとるか判断するべきなのである。たとえば、モジュール間の関連性が強くて、全体が密結合のシステムを作る場合は、プロセス中心型で進めたいだろう。逆に、たとえばすでにあるシステムに、新規機能をいくつか追加していくようなプロジェクトならば、モジュールができた順にリリースしたいから、成果物中心型を選ぶだろう。もしもこれが逆だったら、いかに仕事がやりにくいか、想像に難くない。

ところで、こまったことに、会社というところは普通、まず組織が先にあって、プロジェクトが個別に後から来る。その逆というケースは、あまりない。あるとすれば、あなたが社長直轄の特命プロジェクトを任せられ、担当者も社内から好きに指名していい、チーム編成も全く自由だ、といった例外的な場合だろう。
「いいんですか?」
「いいとも。君にすべて任せるから、好きなようにブイブイやってくれたまえ。」
--なんていう、ドラマでしかお目にかからないようなケースなら、確かに組織設計にも自由度はあろう。

しかし、たいていの会社では、すでに組織の器が決まっている。そして、その形に合わせてWBSを(なかば無意識に)決めることになる。会社がゼネコンやSIerなら、タスクフォース型組織になる(つまり成果物中心型)だろうし、製造業なら、まず間違いなく機能型組織だからプロセス中心型WBSになる。プロジェクトのWBSは、こういうパターンにするのが「当然だ」と思いながら。

だが、そんなのは「当然」ではないのだ。繰り返すが、WBSはプロジェクト組織を決める。そしてプロジェクト組織とは、プロジェクトを遂行するための手段にすぎない。だとしたら、会社全体の部門構成がどうなっていようと、プロジェクトの性格と目的に合わせた組織を(そしてWBSを)設計すべきなのだ。

こうしたことは、WBSの図を見て落ち着いて考えれば、当然分かるはずのことである。だが、WBSの作り方について、こうした基本的なことを書いている資料を滅多に見ないのは、不思議である。WBSはプロジェクト・マネジメントの土台(Foundation)である。建物が土台の上に成り立つように、WBSの設計は、細心の注意が必要なのである。
by Tomoichi_Sato | 2012-10-24 23:56 | プロジェクト・マネジメント | Comments(0)
<< WBSはコスト見積の基準を規定する 製品のグローバル、組織のグロー... >>