PR

 ここ数年,「WBS(Work Break-down Structure)」を作成する開発現場が増えている。WBSは,プロジェクトで必要な作業全体を,作業項目単位に分割・構造化し各作業項目の成果物や担当を明記したものである。通常は,契約の前提としてプロジェクトの立ち上げ時に粗いWBSを作成し,プロジェクトの進行とともに詳細化していく。

 ところが,「このWBSの書き方が原因で,プロジェクトが混乱するケースが最近増えている」(日立製作所 プロジェクトマネジメント技術センタ長 初田賢司氏)。その最も大きな原因は,「一つの作業項目に複数の担当者または担当企業を割り当てること」と,初田氏は指摘する。

 なぜ,一つの作業項目に複数の担当者または担当企業を割り当ててはいけないのか。それは,その作業項目に割り当てられた各担当者または担当企業の作業範囲があいまいになるからだ。

 例えば,「業務プロセス設計」の中の「業務機能定義」という作業項目で,A社は「◎」,B社は「○」と記述したとしよう()。A社が主体になって,A社とB社が共同で実施することは分かる。だが両社の作業範囲はあいまいである。その結果,実施段階になって,「業務機能定義」のために必要な「業務用語と業務コードの定義」など,具体的な作業をA社とB社のどちらが実施するのかで,もめる可能性がある。最悪の場合,両社ともに「自分の作業範囲ではない」と考えて,実施しないかもしれない。こうした問題が起こると計画の見直しが必要になるなど,プロジェクトは混乱する。A社とB社の信頼関係が損なわれる恐れもある。

図●作業分担があいまいなWBSの例
図●作業分担があいまいなWBSの例
WBSに示すユーザーとベンダーの作業分担については,「◎(メイン)」と「○(サブ)」,あるいは「○」と「△(支援)」といったあいまいな表記は避ける。特に,業務プロセス設計や移行,ユーザー教育などの作業は分担があいまいになり,作業の漏れやトラブルにつながりやすい
[画像のクリックで拡大表示]

 特に,こうした問題が起こりやすいのは,「業務プロセス設計と移行,ユーザー教育」と日本ユニシスの服部克己氏(プロジェクト支援室長)は指摘する。作業範囲のあいまいさに起因する問題を起こさないために,作業の実施前に「WBSの一つの作業項目には1人の担当者または1社の担当企業を割り当てておく」のが大原則である。