WBSはプロジェクト組織を規定する (2012/10/24) いま、これからあるプロジェクトを開始するところだと仮定しよう。あなたはプロマネとして、仕事のやるべき範囲(=スコープ)を明確にし、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の構成図を書いたら、次にプロマネがすることは、各アクティビティの担当責任者を決めていくことだ。そして、図なり表なりに、それを記入していくだろう。このとき、レベル1もレベル2も、当然ながら責任者の名前を決めていくことになる。 すると、どうだろう。仮に「モジュールAをテストする」アクティビティ(=レベル2)の担当者はつねに佐藤君だったとしても、その上位にあたるレベル1の担当者は、「Aモジュール」に責任を持つのか、それとも「テスト」に責任を持つ人なのか、守備範囲が違ってくることになる。前者(案1のケース)なら“Bモジュールがどうなっていようと自分は責任ない”との立場だろうし、後者(案2)なら、“設計のよしあしについては感知しない”スタンスになるだろう。当然、自分の部下の使い方だって、違ってくる。 すなわち、二つのWBSは、組織図にすると、こんな違いになるのだ。 そして、このような組織の違いは、何を生みだすだろうか。このプロジェクトのロジック・ネットワーク(アロー・ダイアグラム)を描いてみれば、一目瞭然だ。成果物中心型なら、スケジュール的にも各モジュールはばらばらに進行していきがちである。他方、プロセス中心型WBSならば、設計全体に対する責任者がいるわけだから、彼または彼女は、設計が一応まとまって全体の整合性をとってから、先に進もうとするだろう。つまり、プロジェクトはフェーズ単位に進行していくことになるはずだ。 そして、プロマネであるあなたは、自分のプロジェクトをどのようにマネージしたいかによって、どちらのWBSをとるか判断するべきなのである。たとえば、モジュール間の関連性が強くて、全体が密結合のシステムを作る場合は、プロセス中心型で進めたいだろう。逆に、たとえばすでにあるシステムに、新規機能をいくつか追加していくようなプロジェクトならば、モジュールができた順にリリースしたいから、成果物中心型を選ぶだろう。もしもこれが逆だったら、いかに仕事がやりにくいか、想像に難くない。 ところで、こまったことに、会社というところは普通、まず組織が先にあって、プロジェクトが個別に後から来る。その逆というケースは、あまりない。あるとすれば、あなたが社長直轄の特命プロジェクトを任せられ、担当者も社内から好きに指名していい、チーム編成も全く自由だ、といった例外的な場合だろう。「いいんですか?」「いいとも。君にすべて任せるから、好きなようにブイブイやってくれたまえ。」--なんていう、ドラマでしかお目にかからないようなケースなら、確かに組織設計にも自由度はあろう。 しかし、たいていの会社では、すでに組織の器が決まっている。そして、その形に合わせてWBSを(なかば無意識に)決めることになる。会社がゼネコンやSIerなら、タスクフォース型組織になる(つまり成果物中心型)だろうし、製造業なら、まず間違いなく機能型組織だからプロセス中心型WBSになる。プロジェクトのWBSは、こういうパターンにするのが「当然だ」と思いながら。 だが、そんなのは「当然」ではないのだ。繰り返すが、WBSはプロジェクト組織を決める。そしてプロジェクト組織とは、プロジェクトを遂行するための手段にすぎない。だとしたら、会社全体の部門構成がどうなっていようと、プロジェクトの性格と目的に合わせた組織を(そしてWBSを)設計すべきなのだ。 こうしたことは、WBSの図を見て落ち着いて考えれば、当然分かるはずのことである。だが、WBSの作り方について、こうした基本的なことを書いている資料を滅多に見ないのは、不思議である。WBSはプロジェクト・マネジメントの土台(Foundation)である。建物が土台の上に成り立つように、WBSの設計は、細心の注意が必要なのである。