WBSをなぜ作るのか、そしてなぜ失敗してしまうのか

「WBS」はＩＴエンジニアの誰もが知っていることだろう。プロジェクトのタスクを全てまとめたプロジェクト管理表のことである。プロジェクト管理に欠かせない存在であり、プロジェクトの成否を握っているといっても過言ではない。しかし、「WBS」を有効活用できていない開発チームは多く、不便で面倒くさいものという印象を持たれることも少なくない。本記事では、「WBS」について改めて考察し、有効活用する方法を探る。

WBSとは？

WBSは略称であり、「Work Breakdown Structure」の頭文字を取って、呼ばれている。これを以下のように分解して考えるとWBSの目指すものが見えてくる。

「Work」→目的達成に必要な作業
「Breakdown」→分解
「Structure」→構造化する

これらをつなげると「目的達成に必要な作業を分解して構造化する」ということになる。つまり目的達成に必要な作業が漏れることなく、把握できるようにする目的で作成しているものということだ。WBSの良し悪しを見るには目的が果たせているかどうかが判断のポイントになる。

タスク管理というとまずToDoリストを思い浮かぶが、WBSはそれを発展させたものと考えればよいだろう。ToDoリストは、今後行うべきタスクをただ大雑把に書きだしたものであり、細かいタスクと荒いタスクが一緒に並べられている。またグルーピングがされていないため、何のための作業か把握しにくい。そういった問題点を解決するために、より細かいタスク管理に用いるのがWBSなのである。これは個人でタスク管理を行うのではなく、チームでタスク管理を行う際に活用されることが多い。

WBSの基本的な作り方

WBSについて理解するために、「カレーライスを作る」というプロジェクトを具体例に説明する。

必ずTOPダウンで作る。

プロジェクトを進める際に、必要な作業をすべて洗い出すことが重要である。これをブレインストーミングなどで意見を出して、ボトムアップで作るのは推奨できない。次々とアイデアが出てくるものの、順序立てられてはいないため、どこかで漏れがでてしまう。WBSを作る際は、TOPダウンで分解していくほうが良い。
カレーライスを作るのであれば、冷蔵庫にない食材を買い物に行かなければならない。これを更に分解して、食材をどこで買うかなどを加えるとより良いWBSとなるだろう。
図1
作成ルールを必ず守る。

項目1でTOPダウンでWBSを作るほうが良いとしたが、その際にはルールを必ず守る必要がある。例えば、「カレーライスプロジェクト」で「買い物」のタスクの下には買う必要のあるものが全てリストアップされている必要がある。これでもし、カレーに必要な食材が揃っていても、お米が家になければカレーライスを作ることができない。また、一方でカレーライスに必要のないものはここに書くべきではない。
全てのスコープを含める。

実施するべきタスクが、WBSに上がっていないということがよくある。そのため事前にプロジェクトのスコープをどこまで設定するかが肝心である。システム開発系で言えば、旧システムからのデータ移行処理などがありがちである。「カレーライスプロジェクト」で言うと、「後片付け」や「配膳」などが漏れてしまいがちだろう。

もちろん、実際のWBSはこの図より詳細に作りこむ必要がある。WBSではガントチャートと呼称される進捗状況を表した図を入れるのが一般的である。ガントチャートはタスクの進捗状況を可視化するために作成される。タスクの開始日と終了日を表に色を塗り、現状何日かかっているか、どこまで進んでいるのかなどを把握する。
図2　ガントチャート

WBSを作るメリット

WBSの大筋の目的や作り方がわかったところで、WBSを作る理由について具体的に記載する。

作業の抜けや漏れ、重複を防げる

WBSでは、トップダウンで作業や成果物を分解していく。この分解するという作業が抜けや漏れの発覚を促す。WBSを作成していくことで作業計画を洗練させていくことができる。
プロジェクトのスコープ（範囲）が明確になる

スコープというのは、プロジェクトの対象範囲のことである。つまりプロジェクトで「取り組むこと」と考えればよい。「取り組むこと」と「取り組まないこと」を明確にできていなければ、不必要なところに手を出したり、あるいは必要なところに手が回らなかったり、といった事態を招きかねない。
WBSにはそのプロジェクトの全てのスコープが含まれている。そのためWBSのタスクは全て「取り組むこと」であり、WBSに上がっていない作業は全て「取り組まないこと」になる。
このスコープを開発側とユーザー側が共有、内容に合意することで、費用を巡るトラブルを防ぐことができるのも理由のひとつである。
プロジェクトの進捗状況を可視化する

WBSには全てのタスクが上がっているので、完了したタスクの数がわかれば、進捗率を把握することができる。ただし、そのためには各タスクの粒度（作業量）をある程度揃える必要がある。この最小単位まで分解したタスクのことをワークパッケージと呼ぶ。
責任分担を明確にする

タスクをそれぞれ担当者に割り振ることで、責任範囲が明確になる。また担当者の負荷状況も同様に明確になるのである。これによって、プロジェクトメンバー全員が責任をもって作業に取り組むことができ、プロジェクトマネージャーは管理が行いやすくなる。

WBSはプロジェクト管理を行う上でこのようなメリットがあり、多くの現場で採用されているのである。なぜならチームとして動かなければならないため、詳細に作業を管理する必要があるからである。

WBSが活用できていないケース

WBSは50年以上前に開発された、プロジェクト管理の初歩ともいえる手法である。それぞれ形は違うが、ほとんどの現場でこの手法が採用されていることだろう。しかし、多くのメリットがあるにも関わらず、WBSを有効活用できていないという例は多い。WBSの活用がうまくいかないのは何故か、下記に考察してみた。

Excelで作成している

WBSの作成時によく用いられるのがExcelである。Office製品はほとんどの企業で導入されており、触ったことがないという人はいないだろう。WBS作成に必要な機能は大方揃っていると言ってよい。既に導入されているからこそ新たにコストが発生することがなく、操作に慣れるための時間も不要である。一見Excelで問題がないように見えるがそこに大きな落とし穴が隠されている。
なぜならあくまでExcelは表計算ソフトであって、WBSに特化したツールではないということだ。表自体を作ることは簡単だが、それを継続して使うことに向いていないのである。WBSは日々更新を続け、変化していくものであり、時にはWBSの形式を変更することもある。その度に関数やマクロをすべて変更しなければならない。
また同時編集が難しく、クラウドサービス等を用いなければならない。大人数であれば、連携がより難しくなるだろう。Excelは自由にWBSを作成できる一方で機能追加やメンテナンスをすべて自分で行わなければならないのだ。WBSの整備には時間がかかり、マネージャーに大きな負担がかかることだろう。そうして更新が滞りがちになり、プロジェクト管理ツールが無用の長物と化してしまうのである。
情報を詰め込みすぎている

WBSを作る際にありがちなのが、WBSに情報を詰め込みすぎてしまうということだ。上記のようにExcelで作ったWBSであれば、一つのシートに大量のタスクやスケジュール、作業内容と何から何まで詰め込んでしまっているのである。そういったWBSは大変見づらく、管理やチェックが行いにくい。見やすい、見づらいという点は大変重要で、見落としや勘違いが生まれて、後から手戻りや問題が起きてしまうのである。そもそも見づらいWBSを毎回確認しようとは思わないだろう。
毎回編集、確認するのが面倒

タスクは最初の計画から変わらないことが理想では有るが、実際は日々変わり続けるものである。変更がある度に管理者は時間を割いて、WBSの編集を行わなければならない。編集に不便な形式では更新も滞る。そのような放置状態のWBSでは、チームメンバーはタスク把握に苦労する。Excelファイルを共有フォルダに置いていれば
「フォルダを開く」→「ファイルを開く」→「Excelが起動するのを待つ」→「自分が担当のタスクを探す」
というプロセスを踏まなければならず、手間がかかる。どれだけ機能が充実していても「面倒くさい」と思われ、放置されてしまうのであれば、良いWBSとは決していえないだろう。

まとめ

本記事ではWBSを作るメリット、そして運用の失敗について考察した。その中でもExcelはWBSの質を悪化させる傾向が強い。なぜなら自由に機能追加できるところが裏目に出ており、WBSが使いにくいのは、作り方が悪いのであって、Excel自体に問題はないと考えてしまうのだ。こうなると、終わりのないWBS改善の旅に出てしまい、そしてその多くはたいした改善ができず、徒労に終わってしまうのだ。Excelスキルが高く、Excelで作成したWBSを有効活用できているのであれば問題ないが、もし既に使いにくいと感じているのであれば、そのWBSを作成したマネージャーのExcelスキルでは改善は不可能だと考えたほうが良いだろう。
WBSをどのように有効活用すべきなのか、次回の記事で考察する。