はじめに

PMBOKについて知見があればWBSを書く複雑さ・推奨されるルールと実際のPJへ適用する際のギャップに驚いた経験もあるかと思います。
加えてWBSは非常に奥深く、WBSを書くだけで数日の研修日程が組まれたり、本が一冊書けるほどの密度があります。
PMBOKが想定するPJは超大規模かつ長期です。実際の小規模・短期なPJへの適用する際のテーラリングとして流行りの引き算を実施し成功した事例についてまとめています。

対象のPJ規模

20名未満で1年程度のPJにFITします。1名で数ヶ月のミニPJでも活用していました。
私の役割はコミットしたQ(品質)C(コスト)D(デリバリー)S(スコープ)に影響を与えないよう、また与えうる場合にSを厳守するためにCを上げる、Dを短縮するためにSを縮小するなどの監視・コントロールを行うプレイングマネージャーでした。

WBS作成の流れ

大まかな流れです。

アクティビティリストの作成
アクティビティリストに作業工数とリソースをアサイン
各アクティビティのインプットとアウトプットによりアクティビティに依存線が引かれWBSが完成

PMBOKについて

PMBOKはプロジェクトマネジメントの知識体系です。
プロジェクトマネジメントの国際資格PMP試験もPMBOKをインプットに作成されています。
しかし冒頭記述の通り、PMBOKの知識体系をそのまま自身のPJに適用するにはギャップがあり、PMBOKも知識体系として自身のPJにカスタマイズ（テーラリング）せよ、と述べています。

PMBOKにおける用語定義について

アクティビティとはプロジェクトにおけるタスクであり、タスクは動詞です。
ＷＢＳの最下位のアクティビティを「ワーク・パッケージ」と呼びます。

引き算したとは言え準拠すべきルール

準拠すべきルールについて改めて触れておきます。

100%ルール

WBSはアクティビティにより階層化されアクティビティには親子関係があります。
ある親に関連する子のアクティビティ全てが実行すると親のアクティビティも同じく完了する事を100%ルールと呼んでいます。

よくある100%ルールを厳守出来ていない例 : アクティビティのパッケージング位置が適切でない

一見、A-1の子アクティビティ全てを終えればA-1が完了するを満たしていますが、A-1-4はA-2-1に依存します。
パッケージングが適切でなく、A-1-4は別途切り出され、A-3.ソフトウェアインストールの階層化のアクティビティとした方が良いです。

├── ●●●プロジェクト
│       │   └── A.検証環境を構築する
│       │       ├── A-1.サーバを搬入後物理結線する
│       │       │   └── A-1-1.サーバを搬入する
│       │       │   └── A-1-2.ラッキングする
│       │       │   └── A-1-3.物理結線する
│       │       │   └── A-1-4.サーバにインターネット経由でソフトウェアインストールする
│       │       ├── A-2.回線を引く
│       │       │   └── A-2-1.インターネット回線を引き疎通を確認する
│       │       └── A-3.動作確認を行う
│       │           └── A-3-1.XXXX

8/80H

1つの最下位アクティビティを8〜80Hの範囲に分割する事です。アクティビティの工数が大きすぎる場合にコントロールし辛い為です。
逆にPJに関連するアクティビティであっても8H未満のような小さいアクティビティがWBSとして管理されません。
8H未満のアクティビティが多すぎる場合、4/80Hルールにしたり調整が必要です。
8/80Hルールを採用する場合にも小さいアクティビティをどこでどう管理するかは設計が必要です。

段階的詳細化

ローリング・ウェーブ計画法と呼ばれ、未来すぎるアクティビティは最下位まで詳細化出来ないので100%ルールを準拠しつつも最下位までいかずとも「何となく」記載し、時が来たら詳細化する事です。

引き算レシピ

さっそく引き算していきます。

WBSの行を引き算

本来、アクティビティは１行１アクティビティですが、規模が大きくないPJにおいてはアクティビティが小さくなった場合のアクティビティを別で管理したり、MSProjectのようなツールは使えど依存線をアクティビティごとに変動させる、段階的詳細化の都度、つなぐのは意外と手間です。

PMBOK準拠
1行1アクティビティから1行Nアクティビティに変更
- 担当者が同じかつ8/80Hルールを準拠かつNアクティビティ内に閉じない他の依存関係がない場合に適用します。

こうする事で既存のアクティビティにアクティビティを追加する際にもWBS番号が増え新たに依存関係を再構築する事なく工数を増やすのみで対応が可能です。

WBSの列を引き算

ITO図（インプット、ツールと技法、アウトプット）はアクティビティの入出力を明確にし担当者をアサインする際のスキルセットの判断基準になりますが、WBSを作成するマネージャーがアクティビティに必要なスキルセットおよび担当者のスキルをある程度把握していれば「ツールと技法」については引き算可能です。

また私は工数精度についても若干引き算をしています。
±50%程度の精度としています。これなら8/80Hのアクティビティに収まっていれば実際の工数が+50%だとしてもPJ全体で吸収可能な為です。

アクティビティリストとWBSの区別

WBSを作成するツールとしてMSProjectを活用しています。「稼働を平準化」という神機能がある為です。
担当者のリソースが稼働設定上限を超えていたらいい感じにアクティビティをフロートしてくれる機能です。これにより「Aさんこの日18時間働かなきゃだね」という事件が発生しません。
依存関係を描き、休日、祝日設定をし、メンバーの稼働上限設定をし、スケジュールを引く点のみMSProjectを利用しており、アクティビティリストはExcelなどで作成し、その内容をMSProjectに転機しています。

アクティビティリストとして以下をExcelで作成

まとめ

このWBS行列の引き算（テーラリング）により私はプレイングマネージャーとしてWBSをメンテナンスしつつもWBSの担当者としてアウトプットをするメンバーとしてもPJに貢献出来ています。
誰かの参考になれば幸いです。

インスパイヤ

【ヒルナンデス】引き算クッキング

WBSの引き算レシピ