ＷＢＳはプロジェクト組織を規定する

ＷＢＳはプロジェクト組織を規定する （2012/10/24）

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

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

ＷＢＳ・案１
1　モジュールＡ
1.1　モジュールＡを設計する
1.2　モジュールＡをプログラミングする
1.3　モジュールＡをテストする
2　モジュールＢ
2.1　モジュールＢを設計する
2.2　モジュールＢをプログラミングする
2.3　モジュールＢをテストする
3　モジュールＣ
3.1　モジュールＣを設計する
3.2　モジュールＣをプログラミングする
3.3　モジュールＣをテストする

ＷＢＳ・案２
1　設計
1.1　モジュールＡを設計する
1.2　モジュールＢを設計する
1.3　モジュールＣを設計する
2　プログラミング
2.1　モジュールＡをプログラミングする
2.2　モジュールＢをプログラミングする
2.3　モジュールＣをプログラミングする
3　テスト
3.1　モジュールＡをテストする
3.2　モジュールＢをテストする
3.3　モジュールＣをテストする

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

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

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

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

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

となると、案２の方が優れているのか？　いやいや、そう簡単に結論に飛びつかないでほしい。この議論は、大事なポイントを忘れているのだ。それは「責任者」のことである。

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

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

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

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

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

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

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

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

こうしたことは、ＷＢＳの図を見て落ち着いて考えれば、当然分かるはずのことである。だが、ＷＢＳの作り方について、こうした基本的なことを書いている資料を滅多に見ないのは、不思議である。ＷＢＳはプロジェクト・マネジメントの土台（Foundation）である。建物が土台の上に成り立つように、ＷＢＳの設計は、細心の注意が必要なのである。