WBSは、システム開発のプロジェクトマネジメントに使用されがちですが、システム開発以外にも、どのようなプロジェクトでも使用する事ができます。漏れのないWBSを作成するには、WBSの作成方法や作成後の運用方法を正しく理解する必要があります。本稿では、WBSの意義と作り方、導入、作成に使えるツールまで紹介しています。
目次
WBSとは?
WBSとは、Work Breakdown Structureの略で、作業を分解して構造化するプロジェクト管理手法です。スコープ、コスト、スケジュールを一元管理し、プロジェクト計画の整合性を確保します。プロジェクト全体の作業を大きな粒度のタスクから細かいタスクにまで分解し、タスクの漏れを無くします。WBSによって各々の担当者のやるべきことを明確化した上で、スケジュール設定を行うことで、遅延の少ない精度の高い工数見積もりが可能となります。
WBSを作成するメリット
プロジェクトのスケジュールを透明化
WBSでタスクを洗い出して、ガントチャートに落とし込むことで効率的な作業手順を組めます。そして、それらのタスクをWBSにて一元管理することによって、ステークホルダー全員がプロジェクトの全体像を把握することができるようになります。これによりクライアントは安心感を持ってプロジェクトを任せることができ、チームメンバーは各タスクの期限を把握してプロジェクト進行に臨むことができます。
プロジェクトの全容が透明化されることにより、他メンバーの進捗が芳しくない時や何か問題が発生した際の早期問題察知が可能となり、プロジェクト進行の遅延をなるべく無くすことが可能となります。
タスクの関係性の可視化
プロジェクトを進行する上で、各タスクは「〇〇が終了しないと□□の作業が開始できない」といった依存関係で結ばれています。この依存関係を正確に把握していないと、正しいスケジュールを組む事ができず、一つのタスクにエラーが発生しただけでプロジェクト全体に大幅な遅延が発生してしまいます。これを防ぐためにも、WBSを使ったタスクの関係性の可視化がとても重要と言えるわけです。
依存関係によって結びつけた全タスクの最初から最後までを、最も所要時間が長くなる経路をクリティカルパスと呼び、それを把握しておくことがプロジェクトのスケジュール管理を行う上でとても重要です。このクリティカルパスを見誤らずにWBSがひけるよう、各タスクの依存関係を意識しましょう。
タスクの責任範囲の明確化
タスクの洗い出しが完了したら、必ずそれぞれのタスクに担当者を割り振りましょう。メンバーのキャパシティやプロジェクト全体のバランスを考えながら担当者を配置します。この際に意識したいのは、「1つのタスクに1人の担当者」の鉄則を守る事です。1つのタスクに複数の担当者を配置してしまうとそれぞれの責任感が薄くなり、プロジェクトの遅延や作業のミスなどのエラーが発生しやすくなってしまうためです。複数の担当者を入れないとタスクを完了できないと感じる時は、そのタスクをさらに細かく分解して1人の担当者で遂行できるものに落とし込みましょう。
WBSの階層構造
WBSでは、従属関係に基づいて複数の階層にタスクを分割します。各々のプロジェクトによってWBSの規模感が変わるため、タスクの階層の数が変わることもありますが、主には3段階の階層でタスクを分割するのが一般的です。
マイルストーン
マイルストーンは、プロジェクトのフェーズ毎の状態目標となります。マイルストーンでは、手段が目的化するのを防ぐため、それぞれのフェーズが終わった時にチームやプロジェクトがどのような状態になっているかを定義する必要があります。WBSには「100%ルール」というものがあり、子要素は親要素を100%満たすものでなければなりません。これは子要素を全て満たしても親タスクが完了できないという状況を防ぐためです。この「100%ルール」に基づいて子要素の要素を全て満たすマイルストーン作りを意識しましょう。
例えば、プロジェクトチームがコーポレートサイトの制作をゴールとしている時、マイルストーンは次のようになるでしょう。
- 要件定義書が完成している状態
- 情報設計が完了している状態
- デザインの制作が完了している状態
- デザインが開発・実装されている状態
- テストが完了し、公開できている状態
このようにプロジェクト管理を大まかなフェーズに分けて、達成すべき状態を明記したものになります。マイルストーンによって、フェーズ毎の明確なゴールを設定され、それらを達成するために必要な業務を親タスク、子タスクに細分化する事でWBSを作成していきます。
親タスク
親タスクは、マイルストーンの従属関係にあり、より細かく分割したものになります。サブタスクを分割する基準として、「8/80ルール」というものがあります。これは1つの親タスクを完了するのに要する時間を最低8時間以上、最高80時間未満に収めることで、極端に短いもしくは時間が長くかかってしまう親タスクを無くし、各親タスクの作業量の均一化を図ります。
先の例に従って、マイルストーンの「要件定義書が完成している状態」を親タスクに分解すると次のようになります。
- サイトの目的の定義
- 要求の要件化
マイルストーンよりは詳細なものに分解されましたが、親タスクはまだマイルストーンの従属関係にすぎず、これだけでは作業を進めることはできません。タスク内容を可視化するため、子タスクまで細かく分解する必要があります。
子タスク
子タスクは、WBSにおけるタスクの最小単位で、これ以上分割することの出来ない作業になります。子タスクの粒度はプロジェクトの規模感や種類にもよりますが、同プロジェクト内のワークパッケージ同士はなるべく大きすぎず、同じ粒度に揃えるのが好ましいです。例えば、定例会議が週に1度あるとしたら、週に1人の担当者が終わらせられる程度の大きさに揃えるのが良いでしょう。
子タスクの作成の際に注意すべき点として「7×7ルール」というのがあります。1つの親要素に対しての子要素は7つまでとし、WBS全体の構造も7階層までとするということです。子要素の数が多くなり過ぎると、総子タスク数が数千個にもなってしまい、実用的ではありません。8つ以上の要素を作らないといけない時は親要素を増やすか、複数のプロジェクトに分割して対応する必要があります。
先の例に従って、親タスクの「サイトの目的の定義」を子タスクに分解すると次のようになります。
- エグゼクティブインタビューの準備
- エグゼクティブインタビューの実施
- 制作目的をリストアップ
ここまで分解すると、プロジェクトの目標を達成するための具体的な業務が明確になりました。どこまで具体的に可視化したいかによって、階層を増やすことも可能です。
WBS辞書
WBSは成果物や業務名が列挙された図に過ぎません。それぞれの業務の内容を細かく表現するためにWBSの構成要素に関する作業内容等を記述し、WBSを補完する文書「WBS辞書」を作成します。WBS辞書の構成要素としては、以下の内容等が記述される事が多いです。
タスクの説明
タスクの説明には、タスク名、タスク内容の詳細な説明、目標を簡易にまとめます。タスク内容の説明は読み手がすぐに理解できるよう、文量は1~2文ほどで簡潔にまとめておくのが良いでしょう。
担当者
タスクの担当者は、どの担当者に責任があるのかを明確化する重要な情報です。サブタスクには、その業務を担当する部署・チームを担当者として設定し、ワークパッケージには、1人の個人を担当者として設定します。
アウトプット
そのタスク・ワークパッケージで、具体的に期待されているアウトプットを定義します。このアウトプットの具体性によってステークホルダー間のアウトプットの認識のずれを防ぎます。
予算
そのタスクが完了するのに必要な予算を記入します。その予算の項目も細かく記入しましょう。ワークパッケージに予算を記入すると細かく分散しすぎてしまうので、サブタスク、もしくは親タスク毎で予算を設定するのが一般的です。
完了日
タスクが完了されるべき日時を決めます。多くのプロジェクトで全てのタスクがスケジュール通りには動きません。そのため、定められている期間を超過することを念頭にスケジュールをリアルタイムで正しく管理できる体制を整えましょう。
ステータス
素早く進捗確認を行うために、完了日の設定と合わせて、タスクのステータスも記録しておくべきでしょう。ステータス項目はいくつかありますが、「保留」「進捗中」「完了」といった項目を使用する、もしくは進捗を%で表現するといった形が一般的でしょう。
WBSとガントチャートは違う
よくガントチャートとWBSを混同する人がいますが、その二つは別物です。ガントチャートはスケジュールを引くための一つのフォーマットの名前であるのに対し、WBSはタスクの構造化手法です。多くのプロジェクトで、WBSで構造化したタスクをガントチャートに落とし込んでスケジュール管理が行われているので、そう思われてしまうことが多いですが、WBSとガントチャートは分離して考えましょう。
WBSは必ずしもガントチャートに落とし込まれる必要はなく、簡易にタスクを洗い出したい時はドキュメントにテキストでまとめるだけでも良いのです。その他に落とし込むフォーマットとして、カンバンやカレンダーなどもあります。これらをプロジェクトに最適な形で併用して効率的なコミュニケーションを図れるようにしましょう。
WBS作成ツール
上段で述べたように、WBSをプロジェクトマネジメントに使う際にはガントチャート等のフォーマットに落とし込んで使うのが有効的です。それらのフォーマットに落とし込む際に便利なツールを紹介しますので、皆さんのプロジェクトに合ったツールを選定、使用してみてください!ここでは、「コーポレートサイトの制作」を例に各ツールの事例として紹介していきます!
Google スプレッドシート
メリット
- 昔から使われているため、ネット記事などによるナレッジが多くある
- テンプレートを探しやすい
- 汎用性が高く、プロジェクトに合わせて仕様を調整しやすい
- リアルタイムにチーム内でシェアできる
- 使い慣れてる人が多い
事例
スプレッドシートによるWBSの作成を行う際は、まずはネットで「WBS テンプレート」と検索して、テンプレートをゲットして使いましょう。それからプロジェクトに合わせてスプレッドシートの調整を行い、活用しましょう。
さらにスプレッドシートでは関数や条件付き書式の設定を行う事ができるので、自由にプロジェクトやメンバーに合わせて仕様を変える事ができます。しかし、スプレッドシートにある程度長けている方でないと、設定を行う事が難しい可能性があるので、使う人によっては使いにくいものになってしまうかもしれません。
Notion
メリット
- デザインがシンプルで見やすい
- リレーショナルデータベースの活用ができる
- 親タスク・子タスクの関係性を可視化しやすい
- カレンダー・カンバンなどのフォーマットに簡単に切り替えれる
使用事例
NotionによるWBSの作成を行う際は、親タスクと子タスクの関係性を意識して作成しましょう。 Notionでは、親要素と子要素をつなぐリレーショナルデータベース機能を活用すると、一覧性の高いWBSを作成する事ができます。工夫次第で多くの情報を繋いで可視化する事が可能となるため、色々調整しつつプロジェクトに合わせたWBSを作成してみてください!
親要素のページを開くと、子要素の進捗率などの数字も併せて閲覧する事が可能となります。さらにカンバンや自由度の高いドキュメント設計を行う事ができるので、作成事例を元に調整して作成してみてください。
Wrike
メリット
- 複数のプロジェクトを横断的に見れる
- タスクの階層構造が分かりやすい
- タスクの依存関係を可視化できる
事例
WrikeによるWBSの作成を行う際は、マイルストーン、親タスク、子タスク全ての関係性を意識しましょう。Wrikeでは、タスクの構造が見やすく整理されるため、各々のロードマップをわかりやすく可視化することが可能です。さらに複数のプロジェクトに関わっている場合でも、それらのタイムラインを一覧で見る事ができます。
さらにWrikeでは、タスクの依存関係も可視化する事ができ、クリティカルパスまでもを簡単に可視化する事ができます。WrikeはWBSを作る上では、細かい設定ができる仕様になっているため、複数のプロジェクトを細かく設定したいという方にはとっておきのサービスと言えるでしょう。
チームに合わせたWBSを作成するのが重要
ここまでWBSについて色々と解説してきましたが、最終的には各々のチームに合わせた運用方法を探るのがベストです。チームに人員が少なくて工夫しないといけなかったり、プロジェクトが大規模でWBSの構造を複雑にせざるを得ないといった状況もあると思うので、トライ&エラーを繰り返しつつ、最適な運用を見つけましょう。