すべてのPMに贈る、WBSの書き方におけるたった3つのルール

プロジェクトを進めていく上で必要となる、いつ・どこで・何を作るかを示す工程表「WBS（Work Breakdown Structure）」。いわばWBSは、プロジェクト全体の指針となる地図です。

しかしWBSの作り方や運用方法について、あなたは正しく理解していますか？　WBSはプロジェクトを成功に導く上で欠かすことができないものであるにも関わらず、その作り方・使い方を体系的に学んでいる人は少ないのが現状です。

今回はWBSを正しく理解し意味のあるものとするため、WBSの意味や意義、効果を高めるためのポイント等についてご紹します。

後藤洋平

プロジェクト工学提唱者。株式会社ゴトーラボ Founder/CEO。「チームに覇気がなく一体感がない」 「議論が空中戦になりがち」 「無駄な会議で時間を浪費しがち」 そんな組織の炎上体質を改善するための、プロジェクト工学ワークショップを提供しています。

使えるWBSは人を動かすが、使えないWBSは混乱をもたらす

WBSとは

WBSは「Work Breakdown Structure」の略です。日本語に訳すと「作業分解構成図」となります。プロジェクトのスケジュール管理に使われるツールのひとつで、プロジェクト全体を細かな作業に分解し、構造化して管理する手法です。

どんなに大きなプロジェクトでも、一つひとつの細かな作業の集まりです。最初に必要な作業を洗い出し、それぞれの作業に必要なコストや人員配分を割り出して、スケジュールを立てることで実行していきます。

プロジェクト達成に必要な作業同士の関係を可視化することで、前後の作業を意識しながらスケジュールを管理できます。

WBSの目的

大きなプロジェクトで困るのが「作ってみたものが欲しいものと違ってやり直しになった！」「やるべき作業範囲の認識が食い違っていてうまく連携できなかった！」といった問題です。WBSの目的は、そうしたトラブルを未然に防ぐことにあります。

作業を分解して細かくすることで、いくつかのメリットが生まれます。

• やるべき作業内容と受け持つ範囲が具体的になる
• 役割分担が明確になる
• スケジュールを立てやすくなる
• 立てたスケジュールと実際の進行状況を比較しやすくなる

WBSの問題点

WBSには一点、大きな問題があります。それはすなわち「上手にWBSを書くのは難しい」ということです。

全体としては複雑で難しい仕事でも、適切に分解することで、関係者は安心して一つひとつの作業に取り掛かれるようになります。しかしその分解方法が誤ってしまうと、どうなるでしょうか。

「一見正しい作業指示だけど抜け漏れがある」「やってみたら実現不可能な計画だった」ということになると、関係者は何を信じていいか分からなくなります。時には「取り決めが全くない状態のほうがまだマシ」という事態にすらなる恐れも……。

WBSを書くときに意識しておきたい3つのルール

WBSでトラブルを引き起こさないためには「最低限これだけは守っておこう！」という3つのルールがあります。

100%ルール

WBSにより、下層レベルから上位レベルまでの作業をすべてひとつにまとめ上げることで、取りこぼしのない、また余分な作業のないプロジェクトを構築できます。PMIが発行している国際標準のプロジェクトマネジメント知識体系ガイド『PMBOK』では、これを「100％ルール」と呼んでいます。

当然のことですが、ひとつの要素を分解したときに、漏れなくダブりなく、いわゆる「MECE」に分解するのが大切です。

幕の内弁当ならば、まずはきっと「ご飯」と「おかず」に分けるられるでしょう。さらにご飯は「米」「ごま塩」「梅干し」に、おかずは「焼き鮭」「卵焼き」「筑前煮」「漬物」……といった具合です。

形あるものはこのように分解しやすいのですが、ソフトウェア開発やキャンペーンのような姿かたちを表現しにくいものの場合、どうしても死角や思考の抜けが発生しやすいものです。最下位レベルでの取りこぼしがないか、十分に注意しながらWBSを書きましょう。

8/80ルール

作業は細かく分解しようとすれば、いくらでも分解できます。先ほどの例だと、「米」を作るためには「仕入れ」「洗米」「炊飯」「箱詰め」に分かれるでしょうし、「仕入れ」は「調達先の選定」「価格交渉」「契約」……と、細分化には際限がありません。当然ですが、細かすぎる工程表は作るのも運用するのも大変です。

そこで分解の目安とされているルールがあり、そのひとつが「8/80ルール」。作業の最小単位を、8時間（1日）以上、80時間（2週間）以下の工数に収まるようにしましょうというルールです。

一日で完成する作業は頭のなかでしっかりとイメージできますし、それ以上に分解する必要もありません。一方で2週間以上の作業をひとつにまとめてしまうと、細かな部分が詰め切れていない可能性が高いため、作業がイメージしにくく不確実性が高まってしまいます。作業の最小単位は8〜80時間のあいだに収まるよう、気をつけましょう。

7×7ルール

最後にご紹介したいのが「7×7ルール」です。ひとつめの7は、「ある作業を分解するときには7つ以内の要素に分解しましょう」というルール。もうひとつの7は、「分解する階層は7階層までにしましょう」というルールです。

プロジェクトの規模によっては、そもそも3階層ぐらいで間に合うことも多いでしょう。一般に要素分解の個数はプロジェクトの規模に比例しますが、最小単位の項目が何千という数になってしまうと、そもそも運用自体が非現実的になってしまいます。

現実的に運用できる要素数 / 階層数として、それぞれ7つまでにしておくべきでしょう。

書いたあとの運用も大事！WBSの運用で気をつけるべきこと

WBSは随時修正するもの

ここで、WBSに関する非常に根本的な問題について考えてみたいと思います。それは「最初から上手に分解でき、完全に計画通りに推進できるプロジェクトは、そもそもWBSに頼らなくても大丈夫」ということです。WBSが本領を発揮するのは、予測不可能性の高い、複雑なプロジェクトです。

しかし、いくら「100％ルール」や「8/80ルール」「7×7ルール」を使ったところで、それらはあくまで目安でしかありません。先の見通しが立ちやすいようなプロジェクトでも、進めてみた結果、当初の計画とズレることはよくあります。ある成果物を作るために「AとBとCの作業が必要だ」と思っていても、いざやってみると「DもEも必要だった」なんてことに後から気づく、というのは非常によくある話です。

「WBSのままにマネジメントしていく」のは、現実的にはなかなか難しいものです。プロジェクトを進める中で、最初に作ったWBSを随時修正していくことが必要でしょう。

変更、更新時に注意したい、マネジメントスキルへの信頼性を低めないコミュニケーション

前項で、WBSは初期条件に縛られて進めるものではなく、柔軟な運用こそが大切ということがお分りいただけたかと思います。しかしだからといって、むやみやたらと変更を繰り返してしまうと、「また変更……？」「このプロジェクト、本当に大丈夫か……？」とメンバーの不安を煽ることになってしまいます。

そこで注意していただきたいのが、以下の3点です。

• あらかじめ、WBSは修正・変更があるものと衆知しておく
• WBSの修正・変更の要望が発生したときに、連絡する関係者を決めておく
• 最終的に変更を許可する基準を決めておく

キックオフミーティングの際に、これが取り決められていると良いでしょう。「最初に作ったWBSは考える限りのベストなものであり、想定外のトラブルがない限りは信じて進めていける」、まずはその信用を得たうえで「どうしても」というときには柔軟に対処しましょう。

そして、その「どうしても」の基準が大切なのです。「担当者がミスしたから」という理由でWBSの修正・変更を許可するのはいただけません。誰もが「それは仕方ない」と合意できるラインがあってこそ、柔軟かつ適切な運用ができるのです。

プロジェクトに想定外のトラブルはつきものです。本当に大切なのは、トラブルがあったときに、いかに関係者間で合意形成をして、前に進んでいけるかです。WBSは適切に作成して運用すれば、プロジェクト推進の強い味方になってくれます。ぜひ、ご参考ください。