LTSコラム

WBSの分解(1)
2011.5.24

はじめまして、株式会社エル・ティー・エスで業務コンサルティングサービス部門を担当しています山本と申します。

企業の情報システム部門やシステム開発会社でのプロジェクトマネジメント能力の強化というのは古今東西共通の課題だと思います。ここ数年でPMBOKに代 表されるプロジェクトマネジメント方法論が広く普及し、業界全体としてのプロジェクトマネジメント能力は上がったかのような感触もあります。しかし一方 で、プロジェクトの現場で極めて基本的な要素分解もできないプロジェクトマネージャー(PM)を目にする機会も増えました。EVM等に代表される分析手法 を使えるかどうか以前の問題として、プロジェクトの要素をきちんと分解しプロジェクトメンバーに伝達できるかはPMの必須能力です。これから何回かに分け て「PMに必要とされる分解力」というテーマでコラムを連載したいと思います。

まず取り上げるのはWBSの分解についてです。

一般的にWBSは1週間ないし2週間程度、もしくは5人日~10人日程度のワークパッケージまでに分解することを推奨されています。ところがここにリスク が潜んでいます。実はこの程度のWBSの分解では分解粒度が圧倒的に不足しているのです。なおPMBOKでは分解されたWBSのワークパッケージ毎の詳細 アクティビティ定義はWBS作成とは別のプロセスで行うことになっていますが、ここではアクティビティレベルの作業もWBSに含めて記述しています。 「1週間ないし2週間程度、もしくは5人日~10人日程度のワークパッケージまでに分解」は管理工数の手間と効果のバランス、進捗管理やコスト管理を行う 際の管理粒度を念頭に導き出された解です。確かに細かすぎるWBSは全体像を見失わせ、管理工数を増加させてしまいますので、文書に記述するWBSとして はこのレベルが一つの目標となります。しかしここで気をつけなければいけないのは、文書としてのWBSの記述粒度とプロジェクトメンバーが理解している作 業の分解粒度は同じレベルであってはならないということです。文書としてのWBSがどうあれ、担当者の頭の中では作業は日単位、もしくは時間単位まで分解 されていなくてなりません。つまり個々の作業者が自分が行う作業を具体的にイメージし、実行可能な状態になっている必要がある、ということです。

スキルが高く経験豊富な人なら、5~10人日程度まで分解された作業指示は十分に細かい粒度と言えるかもしれません。しかしそんな人ばかりで構成されたプ ロジェクトはまれです。PMからチームリーダー、個々の作業者へと作業が移譲されていくにつれスキルも経験も下がり、自分自身の作業を明確にイメージする 力が落ちていきます。ですからPMやチームリーダーは部下の状況を見て、もし作業をイメージできていないようならWBSの文書上の記述レベルに関わらず部 下のサポートを行う必要があります。

ところが多くのプロジェクトでこの原則がなかなか機能しません。典型的な症状としては以下のような形で現れます。

PMやチームリーダーは作業を具体的にイメージできています。しかし作業指示時には「この仕事は君の担当だから後はよろしく」ですませてしまったりしま す。そして作業完了予定日に確認するとイメージと違うものができていて「何だこれは!」というオチになったりします。これはコミュニケーションの問題でも あるのですが、前述のPM⇒チームリーダー⇒作業者という作業分解の連鎖が途中で途切れてしまっているという点では作業分解の問題でもあります。対策とし てはWBSの個々の最小単位作業の手順化(WBSの再分解)、密なコミュニケーションによる作業指示者と作業担当者間のイメージの確認などがあります。

当たり前のようでこれがなかなか難しいのが現実です。上司はいつも部下になんらかの期待値を持っています。「これくらいは自律的に判断してほしい」とか 「これくらいの年次の担当者ならここまで出来て当たり前だ」とかです。一方で自分は忙しいので、部下の作業を再分解して指示したり、具体的な作業イメージ を確認することは怠り勝ちです。また部下の側もあまり細かく指示されるのをめんどくさく感じてしまい「おまかせください」的態度をとってしまいがちです。 そして気がつくと「こんなはずじゃなかった」という事態に陥ります。

ただこれらのケースの場合は、早めに事態に気付けば対応がとれます。少なくともPMは何をすべきか理解していますから、最悪はPMが部下の仕事を巻き取ることで対応が可能です。しかし昨今のプロジェクト現場ではもっと深刻な事態が起きています。