WBS（Work Breakdown Structure）を知りたい

ごきげんよう、Zei(ゼイ)です。
今回はお仕事で必要になりそうなので調べまとめた完全に私専用のメモです！
しかし！「個人開発ではありながらも、しっかりとシステム開発のプロセスを踏んで形にしていこう」企画を考えたら、WBSは知っていて損はないですし実際作ってみたい気持ちもありますので、お付き合いいただけましたら幸いでございます。

記事概要

WBS（Work Breakdown Structure）とは何か、作り方などをまとめています。

WBSと仲良しさんのガントチャートについてはこちら↓

WBS（Work Breakdown Structure）とは
WBSは構造化の軸に応じて主に2種類
メリット
WBSの作り方
WBSを作成する際のポイント
感想
参考

WBS（Work Breakdown Structure）とは

Work Breakdown Structure：作業分解構成図

プロジェクト全体を細かな作業（Work）に分解（Breakdown）した構成図（Structure）

プロジェクトの作業を段階的に細かなタスクに分解して計画を立て、実績管理すること
プロジェクト全体でやるべき作業を洗い出す際にとても役立つ

WBSは構造化の軸に応じて主に2種類

プロセス軸のWBS
成果物軸のWBS

プロセス軸のWBS

成果物が不透明な中長期プロジェクトに用いる
プロジェクトの階層に着目し、タスクを細分化・構造化する手法
例）自社の離職率を5%低減させる

成果物軸のWBS

成果物が明確な短期プロジェクトに用いられる
プロジェクト達成に必要な成果物から逆算してタスクを分解し、順序立ててツリー構造を構築
例）システム開発

メリット

やるべき作業の明確化
スケジュールが組める
役割を分担できる
工数見積が可能
進捗管理が可能
スコープが明確になる

やるべき作業の明確化

WBSの特徴は階層構造なのでトップダウン式にタスクを洗い出す
→思いつくままにタスクを並べるのではないので、タスクが思いつき易く整理されていく
→タスクの漏れが防げる
何をすれば良いか、どんな作業をしなければならないかが具体化される
→作業の漏れを防止することができる

スケジュールが組める

タスクをガントチャートに表現できる
→手際の良い作業手順を組むことができる

役割を分担できる

担当者を割り当てることができる
※責任の所在も明確にできる

工数見積が可能

各タスクの規模感が明確になり積み上げて全体の工数が明らかにできる
※タスクの分割があまい工数見積は、どんぶり勘定で誤差が大きい

進捗管理が可能

各タスクの進捗状況が明確にでき、何が遅れているのかを明確にできる

スコープが明確になる

作業スコープとして何が計画されているのかがプロジェクトメンバーやユーザーに共有することができる

WBSの作り方

成果物・プロセスから逆算し必要な作業を洗い出す
作業の粒度・順序を整理
作業の構造化と期日の設定
各作業に担当者を設定

1.成果物・プロセスから逆算し必要な作業を洗い出す

プロジェクトの目的や成果物から逆算し、漏れや重複に注意しながらタスクを洗い出す
必要作業が多い中長期プロジェクトの場合は大まかな作業フェーズごとにタスクを考慮する
だいたい3階層程度（大項目、中項目、小項目）にまとめる
あまりにも細かなタスクは、WBSの構造に含めない
　※細かなタスクは複数の親タスクにまたがったり、管理が煩雑化したりする恐れがあるため
プロジェクトの管理工数を考慮し、適度な粒度のタスクを洗い出す
　※8/80ルール(各項目の作業期間を８時間(１日)以上80時間(２週間)未満にすべき)など

例）Webサイトを制作するプロジェクトの場合
企画・設計・デザイン制作・実装・コーディング・リリースなど
→ここから作業フェーズをさらに細分化

作業の粒度・順序を整理

洗い出したタスクをいきなり構造化するのではなく、粒度・順序を整理することが重要
　※作業の粒度：工数や所要時間のこと
　※粒度にばらつきがあると、構造化した際にいびつなツリー構造となり、
　　　プロジェクト開始後の進捗管理が煩雑化する恐れもあるため
工数や所要時間を軸にグループ化する
タスクの依存関係を考慮し、順序を整理する
　※仮に優先順位の高いタスクが遅延した場合、他の関連タスクのみならず、
　　　プロジェクト全体にまで影響する恐れがあるため
クリティカルパスを設定しておく
　※クリティカルパス：次のタスクに移るために完成していないといけないタスクや
　　　所要時間が最も長いタスクのこと
　※重要なタスクを一目で把握できるため、プロジェクトの遅延防止にも繋がる

作業の構造化と期日の設定

プロジェクトの流れに沿って作業を構造化
親タスク・子タスクの関係性が正常であるか、同階層の業務負担がかけ離れていないかに注意
ツリー構造が完成したのち、各タスクに期日を設定
想定外の事態に備え、期日に余裕を作る
　※計画段階では気づけなかったタスクやトラブルが、プロジェクト稼働後に
　　発覚することはそれなりにあるため

各作業に担当者を設定

各作業に担当者を設定
すべてのタスクに担当者を設定
責任の所在が曖昧な状態になるような担当者振りはNG
　※ミスやトラブルが生じた場合、迅速に対処し円滑にタスクを遂行するためにも、
　　すべてのタスクに担当者を割り振る

WBSを作成する際のポイント

目標やゴールを明確にする
不明確なタスクは作らない
クリティカルパスとバッファは分けて考える
プロジェクトに余裕を持たせる
ツールを活用する

目標やゴールを明確にする

目標が曖昧だと不要なタスクを盛り込んでしまうことがあるため

不明確なタスクは作らない

できるだけタスクの内容を明らかにする
タスクの内容がどうしても確定できない場合、工数を推測で見積もらない
　※正直内容が曖昧なタスクが出てくることがあるが、タスクの中身が不明確である以上、
　　工数を見積もることができない
　※推測で見積もりを出したタスクが実は膨大な工数に及ぶこともあり得るため
不明確なタスクは確定できない状態で残しておき、実務を進める中で内容を明らかにしていく

クリティカルパスとバッファは分けて考える