社内のPM研修でWBSについて学んだ内容の備忘録
2017/02/21
なにこれ？
社内で、 プロジェクトマネジメント研修 WBS編 に参加してきた為、
そちらの内容に関してのメモと、個人的に学習した内容を合わせた備忘録。
WBSとは
Work Breakdown Structure の略で、
プロジェクトマネジメントで計画を立てる際に用いられる手法の一つ。
自転車の開発 で例えると
- デザイン
- 車体作成
- フレーム
- 部品制作
- 組み立て
- サドル
- 部品制作
- 組み立て
- ペダルとギア
- 部品制作
- 組み立て
- ハンドル
- 部品制作
- 組み立て
- フレーム
上記のように作業に必要な工程を_要素分解_ する事で、
プロジェクト全体で必要な作業を把握出来るようにする手法。
このように要素分解を行う事で、
各作業に必要な人員の確保・リソースの計算を行う事ができるようになる為、
責任分担が明確化される 。
WBS作成時のポイント
- 作業内容がもれなく記載されている事
- 作業単位が適正に分解されて、分かりやすくなっている事
分割する際の軸
WEBプロジェクトで主に使いそうなものは以下の3種類が多い。
- 成果物
- 時系列
- 場所(担当)
成果物 を軸とした場合
- 仕様
- デザイン
- システム
- プロジェクトマネジメント
時系列 を軸とした場合の例
- 要件定義
- 設計フェーズ
- 実装フェーズ
- 検収フェーズ
場所(担当) を軸とした場合の例
- クライアント
- 社内
- 外注
など。
WBSの型
ツリー型構造
メリット
- 構造や因果関係が理解し易い
デメリット
- 詳細を記述しにくい
備考
- チャート型（Chart form）とも呼ぶ
- 大項目を洗い出す時や、初期タスクの洗い出しやすい
一覧型構造
メリット
- 詳細が記述し易い
デメリット
- 構造がわかりにくい
備考
- 表型（Tabular form）とも呼ぶ
- ある程度大項目がわかっている場合、責任分担やスケジュールを盛り込みやすい
- WEBプロジェクトでは、こちらが利用されるケースか多い
分割された項目
どういった軸で分解するか決めた後、
更に細分化して項目を分解していく必要がある。
レベル毎の分解
分割された項目は、
- 大項目（1レベル）
- 中項目（2レベル）
- 小項目（3レベル）
- 中項目（2レベル）
といった階層構造で整理していく。
各担当の必要な分解レベル
WBSを閲覧する担当者によって、「分割された項目」 つまり、
WBSの分解が必要なレベルは異なる。
オーナーレベル（事業責任者等）であれば、2レベル程度で良いが、
作業者レベルの場合は、6レベルあたり(作業単位で分解されている方が良い)
ワーク・パッケージ
尚、最小単位まで分解された作業単位は「ワーク・パッケージ」と呼ばれて、
PMBOKでは「最下位レベルの要素成果物」と定義されている。
どこまで分解するかの指標としては、以下のような形が良いとされている。
- 経験が浅い・新規プロジェクト など
- 不確実性な要素が存在しているケースは、なるべく細かくブレークダウンしたほうが良い
- 経験がある・スキルが高いメンバーがアサインしている など
- 安定している場合はそこまで細かくブレークダウンしなくても良い
ワーク・パッケージの内容が適切かどうか
分解されたワーク・パッケージの内容が適切かどうか確認するには、
- ひとつのワーク・パッケージに複数の人が担当者に任命されている
- 適切な作業分解ができていない
- ワーク・パッケージ内の 各作業間に長い空き時間にある
- 待機工数が発生している
- ワーク・パッケージ内の 作業の一部に特化したリスクがあり、切り分けが必要
- 適切な作業分解ができていない
- ワーク・パッケージの 内容を明確に理解していないステークホルダーがいる
- 追加項目が発生する可能性がある
などを確認すると良い。
作成時の注意点
- WBSで最重要のものは「チーム全員でレビューをおこなう事」
- 不確実性の程度認識
- 管理の強弱を知る
不確実性とは
- 時間に制約がある
- 特殊なリソース調達が必要
- アウトプット結果が具体的に見えないタスク
- アウトプットの完成度が不透明
- 技術麺での新規性が高い
- 経験者がいない技術
- 前提、仮定が狂いやすい作業
管理の強弱とは
内製で行う作業なのか、ベンダーに発注を行う作業なのか？
ベンター作業との細かい 依存関係を明確に認識 しておく為。
レビュー時の観点
以下の点に注意して内容を確認する。
- 要素成果物に抜けがないか
- ブレークダウンは適切か
- 責任は明確化されているか
WBS更新時のルール策定
メンバーの解釈・裁量で期限設定やチケットの追加等を行われた場合、
WBSの管理が難しくなりWBSの信用性がなくなる。
結果として円滑なプロジェクト進行が難しくなる為、以下の点に注意する。
- WBSの管理者・更新者をチームで決めてルール化する
- 更新後の周知ルールを定める
備考
一般的にはWBSは、4つ程度の1レベルが存在 している程度が適正だと言われている。
既に利用しているWBSのテンプレートが存在している場合は、
新たにWBSを作成するプロジェクトがそのフォーマットに適しているのか を考えて引っ張られないようにする。
WBSは作成した後、その情報を元として後々の作業で利用される事が多い。
主にスケジュール管理に使用される事が多いため、各要素にユニークな識別子 を振り分ける事が一般的。
識別子 は、スケジュール / 予算見積書 など、様々な文書に利用できる 為、
識別子が一致していれば会計処理がスムーズにする事も可能。
コスト削減する場合にも、どの作業を削れば良いかが分かりやすくメリットがある。