エンジニアのみなさま、日々の学習本当にお疲れ様です！
また本記事まで足を運んでいただき本当に感謝です。
約3分程度で読めるので最後まで読んでもらえると幸いです。

本記事を書こうと思った経緯

プロジェクト管理をする上でWBSに触れる機会が多いものの、表面的な理解しかできておりませんでした。

「何のために使うのか？」

「この手法を活用し、どの様な責務を持たせるべきなのか？」

を理解したい。そして実践したい。

その結果、プロジェクトにおける工程管理を「正しい知識を持って」「より円滑に」プロジェクトを進めたいと思ったためです。
いくつか記事を見ながら学び直した内容を要約してみました。
実務でWBSを活用したときのつらみや感じたことを織り交ぜながら本記事を完成させたいと思います。
主観が多いため 「もっとこうした方が良いよ！」 や 「うちの会社ではこの様な考えで取り組んでます！」 があればぜひコメント欄で教えていただけますと幸いです。

WBSとは？

WBS（Work Breakdown Structure）とは、プロジェクトの全体を視覚的に表現するツールであり、プロジェクトの作業を階層的に分解することを目的としています。具体的には、プロジェクト全体をいくつかの大きなフェーズや主要タスクに分け、それぞれのフェーズやタスクをさらに細かい作業単位に分解していきます。このように階層構造を持つことで、プロジェクトの全体像を把握しやすくなり、各作業の関係性や依存関係も明確になります。

WBSの特徴

階層構造
上位の作業から下位の詳細な作業へと階層的に分解されているため、全体像と細部の両方を把握しやすくなる
包括的なリスト
プロジェクトに必要な全ての作業がリストアップされているため、抜け漏れを防げる
管理のしやすさ
作業が細分化されているため、それぞれの作業の進捗状況やリソース配分を管理しやすい

階層構造の考え方はこんな感じ
画像引用先：https://asana.com/ja/resources/work-breakdown-structure

プロジェクトで使うものはこんな感じ
画像引用先：https://sevendex.com/post/20465/

個人的にはWBS作成時の肝は、計画時の階層構造をしっかり検討する事と考えます。
ここがおざなりになると、抜け漏れが出てきて手戻りが発生します。
全体スケジュールがタイトな場合、より時間がなくなりシステムの品質の担保も徐々に出来なくなってきます。

実働3年の短い経験の中でお話をすると、どれだけ準備をしても全て穏やかに計画通り進むプロジェクトは存在しないと考えます。要件時に描いた顧客の想いが変わり仕様変更するのはざらですし、プロジェクトメンバーのスキル不足や体調を崩してタスクが終わらないこともあります。そんな中で 「計画通り必ず進める」 と考えるよりも 「計画が崩れることを前提にリスクヘッジする」 考えを持ち、階層構造の段階で時間をかけて考え抜く必要があると考えます。自分一人で考えず、ステークホルダーにも相談をしながら作成していくことで抜け漏れのない、納得感のあるWBSが作成できると考えます。

WBSを作成する理由

プロジェクトの全体像を明確にする
WBSを作成することで、プロジェクトの大まかな構造が視覚的に明示され、各作業の位置づけが明確になる
作業の分担を明確にする
WBSはプロジェクトの各作業を細かく分解するため、誰がどの作業を担当するのかが明確になる
進捗管理を容易にする
各作業の完了基準や期限を設定することで、進捗状況を定量的に評価できる
リソースの最適配分
WBSを用いることで、必要なリソース（人材、時間、予算など）を正確に見積もることができる
リスク管理の強化
プロジェクトの各作業を詳細に分解することで、潜在的なリスクや問題点を早期に発見できる

システムを顧客の希望のスケジュール通りに納品しなければいけないため、エンジニアは常に 「期限」 と戦っています。期限を守るために対応箇所の不明点をできる限り無くした状態でタスクに望まないといけません。そのためにWBSを活用し、

「どんな項目があり」
「いつまでに」
「誰が」
「何をしなければいけないのか？」

を明確にする必要があります。
WBSを作成し、対応タスクや全体スケジュール、担当者を明確にしていきます。
ちなみにWBSは 「顧客」 や 「プロジェクトのリーダー以上」 に見せる事が大半だと思います。そのため、プロジェクトメンバーへ見せる項目をそのまま顧客やリーダー以上に見せても「いや、項目多すぎて見づらいですわ！」と返されます笑
この塩梅も非常に難しい...
個人的には顧客やリーダーへ見せる粒度としては作業分解構成図でいう「紫の項目」までかなと。小項目に関してはBacklogなどのタスク管理ツールを活用し、プロジェクトメンバーが把握できる様にするのが良いかと考えます。

WBSを作成するときの注意点

プロジェクトの範囲を明確にする
範囲が不明確なまま作業を分解すると、抜け漏れや過剰な作業が発生する
階層構造を意識する
上位レベルの作業から下位レベルの詳細な作業へと段階的に分解することで、全体像と細部の両方を把握できる
各レベルでの作業の関係性や依存関係も考慮しながら構造を作成することが重要
適切な詳細度を保つ
WBSの作業分解は、詳細すぎても大まかすぎも問題
適切な詳細度を保つことで、作業の進捗状況を効果的に管理できる
関係者との協議
各作業のプロジェクトメンバーやリーダーと協力して作業を分解することで、現実的で実行可能なWBSが作成できる
定期的な見直し
プロジェクトの進行に伴い、WBSも定期的に見直すことが重要
プロジェクトの状況や外部環境の変化に対応するため、WBSを柔軟に修正することで常に現状に適した作業構成を保つことができる

WBSで個人的に厄介だと感じているのが「項目の粒度」と「進捗管理」になります。
全体スケジュールに余裕があればまだ大丈夫ですが、スケジュールがタイトになってくると上記2点はどちらも雑な管理になりやすいです。

「項目の粒度」に関しては抜け漏れが発生した時に項目を追加するのですが、やりがちなのが 1機能を1項目として追加 することです。粒度が粗くなりがちで、開発を進めたときに考慮漏れが発生して新たに項目を追加する必要が出てきます。しんどい...
そこで、今回学習して今後実践していきたい内容が 「8/80 ルール」 になります。「各項目の作業時間を 8時間 / 1日以上、80時間 / 2週間未満」 とし、2週間以上かかるものは 「細分化できる項目」 として判断できるのが良さそうです。項目を追加するときも 時間のみ を判断材料として扱えるため判断しやすい印象です。

「進捗管理」に関しては、プロジェクトメンバーの協力無しでは更新することが出来ません。一方で日頃から進捗を更新してほしいと伝えてもエンジニアは多忙なため、更新タスクの優先順位が低くなりがちです。その結果、担当者ごとに確認する作業が発生します。さらに進捗が遅れてくると「遅延に対するリカバリー策」という謎の検討作業も発生し資料を追加することもあります...これは非常にもったいない。
今後実践していきたい内容が 「定例ミーティングで、はじめの5分間は進捗を入力する時間を設ける」 ことです。メリットとしては 「鮮明な情報を入力できる」 のと 「一日の作業内容を振り返る癖がつく」 ことです。ミーティングの中で入力してもらうことで開発と会議の頭の切り替えにもなりそうなので、試してみたいと思います！

さいごに

プロジェクトは「人」が動かしているため、なかなか思い通りにはいかないものです。
今回WBSを学び直しましたが、プロジェクトに関連する他の取り組みに関しても理解を深め、どんなプロジェクトが来ても必達できる様にしたいです。
また、WBSはあくまで 「プロジェクトを円滑に進めるための補助的なもの」 と認識し、WBSを更新することが仕事にならない様に日々改善をしていきたいと思います。

参考資料