LTSコラム

WBSの分解(2)
2011.7.26

昨今のプロジェクトの現場ではPMやチームリーダーも何をすべきかよく分かっていないというケースもよくありま
す。PMやチームリーダーがやるべき作業をきちんと理解していないのですからプロジェクトが上手くいくわけあり
ません。最近はこの種の事例が増えているように感じます。このようなPM(チームリーダー)のアサインが行われ
るのには幾つかの理由があります。主な事情としては過去10年、情報システム開発の外注化やパッケージソフト
ウェア依存の開発が進み自社内に自力でシステム開発を行った経験のないメンバーが増えたにも関わらず、そ
のようなメンバーが年齢を重ね「年功序列」の会社では彼らをPMにアサインせざるを得なくなったことが挙げられ
ます。10年前のITバブル時の大量採用の弊害の一つですね。ユーザー企業側より情報システム会社に顕著な傾
向のように思います。他にも長期間、運用保守等を行っていたメンバーがこれまた「年功序列」や「定期異動」等
のスキル外の要員でPMにアサインされる例もあります。

このようなプロジェクトでのPMは成果物のテンプレートを各チームやユーザーに提示し、必要事項を埋めるように
指示します。一方で自分はスケジュールやコストの管理に終始し、直接的な課題やリスクの対応を行うことはまれ
です。「型」の部分でしかプロジェクトの運営をしないため、成果物や要求事項に直接関わる問題が発生するとお
手上げとなります。

前述の「1週間ないし2週間程度、もしくは5人日~10人日程度のワークパッケージ」というのは実際にはかなり荒
い粒度です。自分が作業者の視点にたつとこれだけではすぐには作業に取り掛かれないことが分かるはずです。
そしてこのレベルのWBSの分解は実は経験がなくても、社内に過去事例や汎用的な方法論があれば文書として
の体裁を整えることができてしまいます。ところがこの先の分解となると単純な方法論や過去事例の適用ではな
く、業務の実態やユーザーの属性、プロジェクトの状況に合わせた判断を行う必要があります。

例えば「業務領域Aの要求仕様の文書化」という作業があったとします。要求仕様書(RFP)のテンプレートがあれ
ば作業を進められると思うかもしれませんが、実は一般に出回っているRFPのテンプレートにも多くのパターンが
あり、要求される記述粒度や記載項目もまちまちです。RFPの記載一つでシステム(ソフトウェア)ベンダーから提
案の質も変わりますし、後工程の進め方も変わってきます。よってRFPのテンプレートとして、どの程度の記述粒
度にするか、どのような項目を記述するかは全体のスケジュールや事前のユーザー要求の検討度合い等多くの
要素を考慮して決めなくてはなりません。こうなると具体的な作業手順を考える際にも経験と理論の裏付けが必
要になってきます。ところがこれがないPMはユーザーから「なぜこの時点でこの事項を決めなくてはならないの
か?」と聞かれても「過去の事例がこうなっていまして・・・」という苦しい説明に終始せざるを得ず、信頼を失う結
果になります。

作業を分解できることはPMの基本要素です。もし不慣れな領域のPMになっても絶対に中途半端なWBSの分解
でごまかしてはいかせません。自分が具体的に作業を説明できるまで他人の力を借りてでもしっかり分解を続け
る必要があります。逆に外注先や部下のPM能力を測るのであれば、依頼作業の工程の一部を取り出して具体
的な作業の進め方や注意事項を問いただしてみるべきです。澱みなく過去の事例も踏まえて説明できるようであ
れば信頼できるPMである可能性があります。