三日坊主の悪癖が出て先々月、先月の寄稿をサボり談義を中断したことをお詫びします。その償いと言うわけでもないが、今回は内容の都合もあり少々字数が多くなりました。

　WBSの基本については当談義の先の稿(WBS　その1〜5)で一通り解説したので、ここらで例題を基に実際にWBSを作ってみよう。例題プロジェクトは各位に馴染みが深い「マイホーム建設」とする。この題材は2003年にJPMFの有志が起稿した「トコトンやさしいプロジェクトマネジメントの本」を部分的に引用させて頂いているが、できる限り一般的なものとした。考察は出来の悪い木構造(WBSと呼ぶにはあまりにも質が悪いので敢えて木構造と言う)とこれを改善したWBS(こちらは本来のWBSと呼ぶに値するものと見做す)を作り、両者の違いを比較検討する要領で進める。

図―1　マイホーム取得プロジェクト管理体系

　まずは図―1をご覧いただきたい。いきなり誰が見ても問題含みの木構造であることは明白で、このような管理体系を基にしてマネージする人は凡そ居ないと思う。我が家を取得することは個人としては人生のいち大事なので誰でも慎重に準備して掛かる筈であるが、今回は事例演習として敢えて出来の悪い体系を例示した。図中の太線で囲った箱はWork Element(ＷＥ)、最下段の細線で囲った箱はWork Package(WP)と想定する。(WE，WPについては当談義(WBS　その5)を参照)

　上図のタイトルは本来であれば"マイホーム取得プロジェクトWBS"とすべき所であろうが、冒頭に述べる理由(WBSの品質)で此処では敢えて"管理体系"と称した。上図の体系はマイホームを手に入れる際に行う作業を一通り示しては居るが、これはプロジェクトなのかプログラムなのか！　プログラムならばどんなフェーズを踏んで進めるのか、そこには誰が関与するのか等について曖昧なところが多い。この体系でマイホーム取得のプロジェクトを管理するには問題含みの点が多く、将来困難や混乱を引き起こすことが推測される。

　ではこの管理体系をプロジェクト管理に使用した場合どのような問題がでてくるかを分析してみよう。予測される問題は：
�@プロジェクト或いはプログラムのライフサイクルが曖昧であることに基づくもの：
　図−1が対象とするスコープはプロジェクトではなくプログラムと捉える方が妥当に見える。なぜなら企画段階と想像できる作業から実行段階の作業が含まれている。おまけに入居まで含まれている。宅地とか資金が整わなければこのプロジェクトは中断される可能性も大きい。この曖昧さの原因はプロジェクトのライフサイクル、即ち作業着手時点での条件と最終目的が示されていないからである。此処ではプログラム開始時点の前提として、我が家を建てるかどうか決まっておらず、良い土地が見つかり、資金的にも可能であれば戸建の我が家獲得プロジェクトを実行に移す。出来上がったら入居・・・と言うことにする。即ちこのテーマは"マイホーム取得プログラム"である。
�Aステークホールダーの責任区分が曖昧(特に契約当事者)であることに基づくもの：
　戸建の家を建てる際はまず施主が居り、宅地販売業から土地を買って、工務店などに建設を依頼する。完工したら家財を持って入居するがこのとき輸送業者に委託するかもしれない。施主はこれらの業者と各段階で契約を結ぶ。図−１ではステークホールダー各自の作業分担が判りづらい。契約スコープを明確にすることはトラブルを最小化するために重要である。
�@ プログラムフェーズの切れ目が曖昧であることに基づくもの：
　上記�@と�Aの条件を勘案するとプログラムフェーズは必然的に「調査・企画段階」と「建設実行段階」に分かれる。正しくは入居のフェーズもあるが此処では考察から割愛する。

　図―１には上記以外にも改善すべき点があろうが、これらの曖昧箇所を明確にして組み立て直せば有効に使えるWBSになる。上記の分析では大きく分けて2種の問題が指摘できる。一つはプログラムのスコープ定義である。２つ目はプログラム或いはプロジェクトの状態を捉えるための状態把握の切り口である。此処では関係者(組織)とフェーズの切り口の重要性をハイライトしている。WBSを作る際に配慮する切り口については当談議(WBS　その2)を参照されたい。

図−2および図―3に改善したWBSを示す。

図―2　マイホーム取得プログラムの企画段階のプロジェクトWBS

図―3　マイホーム取得プログラムの建設段階のプロジェクトWBS

　改善されたWBSは企画フェーズと建設フェーズに分かれている。この二つのWBSは契約で繋がっている。次いで改善された２つのWBSには担当組織の切り口が見える。この他にも幾つかの修正が加えられているが、その拾い出しは演習課題として各位の宿題に譲る。フェーズと組織の他にどの様な修正が施されているか、図―１と図―２＆３をじっくり見比べて違いを拾い出して頂きたい。違う点がマネジメントの策として配慮された点である。そこにはプロジェクトマネジャーが考える管理の意図が埋め込まれている。どの様な意図が埋め込まれているかは読者各位のご推察に委ねる。
も一つ演習課題を提供する。WBSを作る際には、プロジェクトの状態を"この塊で束ねて(切り口)見たい"との意図をもって体系化するが、此処で重要なことは切り口を階層化する順位である。改善されたプログラムWBSの階層はフェーズの次に組織の順で階層化されている。束ねの切り口とその順位が組み合わさったシナリオはプロジェクトマネジャーの思考プロセスを具現化したものである。この要領はWBS設計のノーハウに値するところである。これを身に付けるのは自分でトライ＆エラーを試みるのが早道。本項の材料で各位演習されたい。

　我が家取得のプロジェクトを図―１の体系で進めたとすると、図―2&3で配慮された切り口は図−1ではリスクとして潜在する。当然のこととして不要の折衝や手間暇もかかり、思わぬ出費(無知であるが故の浪費)も嵩む。何故かしら気になるところには必ず言って良いほどリスクが潜んでいるものである。これらの気になるところは木構造に描くことにより問題箇所を浮き彫りに出来る。危なさそうなところが判れば、後は感と経験と常識(KKC：下記注参照)で問題や齟齬の原因を突き止め、危険排除・極小化の対策も容易にできることは誰でも知るところである。

　筆者注：プロジェクトマネジメントでKKD(感と経験と度胸)は重要な要素の一つであるが、WBSを作るに際してはKKDの内の度胸を乱用してはいけない。WBSはステークホールダー共有のものであるため、WBSの基本を理解した人ならば誰でもそのプロジェクトの大凡を読み取れるもので有らねばならない。度胸は極度に私的な判断であるのでWBS設計の要件に合わない。WBSには常識的な判断が求められるのでそれを作成するに当たってはK(感)とK(経験)とC(Common Sense)を持って臨みたい。
----------------------------------------------------------------------
城戸俊二：PMリソースセンター部長
　(有)デム研究所　http://www.dem.co.jp/