こんなWBSはダメ！うまくいかないWBSの6タイプ

プロジェクトを立ち上げるとき、かならずそこには生み出すべき成果物があります。そして「自分たちが生み出すべき成果物は何か」について、メンバーは共通の認識をもって仕事を進めることが大切です。

このように書くと当たり前のように思えますが、規模が大きく複雑なプロジェクトでは、この共通認識を持つことが非常に難しくなります。そのため新しいプロジェクトを進めていく上では、「WBS（Work Breakdown Structure）」と呼ばれる、いつ・どこで・何を作るかを示す工程表が必要です。WBSはプロジェクト全体の地図の役割を担うものであり、メンバーとの共通認識を持つための資料になります。

適切な方法で成果物を定義し、WBSにうまく落とし込むのは、プロジェクト成功のための基本です。しかしそのWBSを書くのは、なかなか難しいもの……。今回は「うまくいかないWBS事例」を紹介しつつ、WBSをうまく書く方法を解説します。

後藤洋平

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

WBSとは、成果物と作業を”MECE”に分解すること

プロジェクトにおける「成果物」とは

どんなに大きなプロジェクトでも、一つひとつは「作業」です。そしてどんなプロジェクトでも、有形であれ無形であれ、かならず「作業」を通して何かしらの「モノ」が作られます。それは「成果物」と呼ばれます。

成果物とは、工程が完了した際の成果のことです。システム開発でいえば、プログラムや仕様書・設計書、あるいは議事録や進捗管理表などのドキュメントが成果物にあたります。成果物は「確かに依頼された作業が完了しましたよ」という証拠になります。

プロジェクトにおける「作業」とは

成果物と対になるのが「作業」です。どんなものであれ、作業をせずに新たな成果物が生まれることはありません。

では、作業とはなにか。改まって考えるのも変な感じがしますが、辞書をひくと「仕事。また、仕事をすること。特に、一定の目的と計画のもとに、身体または知能を使ってする仕事。（引用：デジタル大辞泉）」とあります。

大切なのは、「一定の目的と計画のもと」に「身体または知能を使って行う」という二点です。どんなプロジェクトでも、必ずそこには目的があり、材料があります。つまりプロジェクトにおける作業とは、自分自身にINPUTされた材料に対して、加工を行い、次の工程で待つ人にそれを渡す（OUTPUTする）ことです。

「作業」と「成果物」を漏れなくダブりなく書き上げるのが良いWBS

WBSを書く上で大切なのは、最終成果物を実現するために必要となる中間成果物を、いかに ”漏れなくダブりなく（MECE）” 分解し数え上げるかです。

よくプロジェクトマネジメントの解説で、カレーライス等の料理が例として取り上げられます。カレーを作るだけであれば、「カレールウ」「ご飯」「香の物」「食器」という感じに分類できますが、例えば規模の大きなパーティーならどうでしょうか。

メニュー作りに始まり、飲食の準備をするのはもちろんのこと、部屋の飾りつけや招待状、余興も必要かもしれません。パーティーの規模や目的によっては、コンセプトを詰めたりデザインしたりと、進めているうちにあれやこれやと必要なものが次々に発生してくる……ということがあります。

実はそれらは「後から発生している」のではなく、「最初に見通しを立てるのに失敗していた」といえるのです。最終成果物の想定が甘く、全体のうちの一部しか考えていないと、遅延やミスの原因になります。

そうならないためには、「最終成果物」の直下にある「中間成果物」の層を、文字通り漏れなくダブりなくすべて数え上げ、WBSに落とし込むことが大切です。

こんなWBSはダメだ！うまくいかないWBSの6タイプ

プロジェクトにおける最終成果物をうまく分解できないと、当初立てたスケジュールや役割分担がうまく回らなくなってしまい、最悪の場合、チームの崩壊にもつながりかねません。

今回は筆者が見聞きしてきたなかから、ちょっとこれはマズいな……と印象に残っているものをご紹介します。

NG事例1：自分の周りしか考えられていない粒度バラバラなWBS

開発フェーズというよりは営業フェーズに見られがちなのが、単純に思いついた作業をならべて、それらしきスケジュールを置いてみただけ、という「なんちゃってWBS（のようなもの）」です。

自身の担当領域以外の知識が浅いなかで、自分自身の工程の周辺に重きをおいて考えてしまうせいで、ある部分については詳細に考え抜かれているのに、それ以外の部分については妙にざっくりとした想定になっているケースがよくあります。工程ごとの粒度がバラバラなため、プロジェクト進行中に抜け漏れが発覚しがちです。

NG事例2：根拠なくバッファをとったWBS

ある作業にどれくらいの時間が必要なのか、事前に見積もることは難しいものです。実際に作業に着手して初めて、思ったより簡単だったり、想定以上に時間がかかってしまったりといったことはよくあります。

そこでかならず人は、スケジュールにバッファを取ることにします。4日ぐらいかかりそうなものは「念のためもう1日」とか、半日でできそうな作業であっても「念のため翌日の午前中まで」とバッファを取っておくものです。

バッファは、プロジェクト進行中に想定外のトラブルがあっても、全体が遅れないようにするためには有効です。しかしきちんとした理由がなく、「なんとなく」で設定されたバッファは危険です。なぜならバッファは、メンバーの納期意識をゆるませることにもつながるからです。

「どうせもう少し余裕があるんでしょ？」なんて悠長に構えていると、実は全然そうでもなく、納期意識がゆるいことで致命的な炎上に発展することもあります。

NG事例3：レビュー＆修正の工程を考えていないWBS

作業時間にはバッファを取っても、作業後の工程については考慮していないWBS（のようなもの）がたびたび見られます。

事前に作業完了基準が明確になっていて、作ったものが一発でOKになるのならば良いのですが、世の中にある多くの仕事はそうではありません。人は必ずミスをするものなので、生み出したアウトプットが計画通りのものであるか、ミスはないかをチェックし、問題があった場合には修正する、という工程が不可欠です。つまり、「レビュー」と「修正」です。

あらかじめレビューと修正の工程を組み込まないと、作業着手をうまくマネジメントできても、終了のマネジメントが失敗してしまいます。

NG事例4：根拠なく工数を見積っているWBS

多くの場合、WBSを書いたらそれぞれの作業に必要な工数を見積ります。しかしどんなに考え抜いても、工数を正確に見積もるのは難しいものです。まして自分以外の人が担当する仕事については、根拠なく工数を見積もってしまいがちです。

とくに要件定義が中途半端で、具体的になにをどう作りこんでいくのかが見えていない状態でスケジュールを立ててしまうと、着手後に矛盾が生じ、計画自体がダメになってしまうので要注意です。

NG事例5：外部関係者が抜け落ちているWBS

受託型のプロジェクトに多いのが、ベンダー側、あるいはユーザー側のどちらかの視点でしか組み立てられていないWBSです。内部的には必要なものが数え上げられ、必要なものが用意され、作業が順調に進んでいくように見えるのですが、連携する外部の組織やチームが考慮されておらず、「じつは実行不可能」な計画になっていたりします。

本来はそんなことがないように、カウンターパートになっている窓口同士が協力しあい、プロジェクトにおける互いの分担と過程をすりあわせることが必要です。しかし一見上手にWBSを書けているせいで、うっかり外部組織を見落としてしまう、なんてことがよくあります。

NG事例6：そもそも材料が揃っていないWBS

論外といえば論外なのですが、世の中には「書いたそばから遅延していく」WBSというものがあります。つまり、最初に着手しようとしている作業の前提条件が満たされない状態でスタートをしてしまっている、というものです。

作業には、必ずそれを実行するために必要なINPUTがあります。材料を揃えないまま、あたかも揃っているかのような認識でWBSが作成されてしまい、関係者全員がそこに疑問をもたずについていってしまう……。さあ、いざ作業を始めようと着手した瞬間、まさかの抜け漏れに気づいて大騒ぎ……なんてことには、ならないようにしたいものです。

WBSを書くときは、目的と手段をきちんと区別しよう

WBSを作成する本来の目的

なぜWBSを作るのか。それは「作業」と「成果物」を抜け漏れなく洗い出すためです。やっている途中で、あれもこれもと必要なものが発見されたら、スケジュールや品質を管理するのが飛躍的に難しくなってしまいます。そうならないために、WBSを作ることで事前にプロジェクト全体を見渡しておくのです。

近年のWBSは、作成をするのが当たり前になりすぎており、たまに「実際は想定通りには進まないけど、形式上必要だから書いておく」とか「スケジュールを考えるために作る」という人がいます。また過去の案件をなんとなく引っ張り出して、細部だけ整えてお終い、という風にしてしまう人もいます。それではWBSの本来の意味を見失っています。

成果物が明確でないフェーズでは、WBSはむしろ有害になることも

新しいプロジェクトを始めるにあたって、何を・どのように・いつまでに作るのか、そもそも何のために作るのかといった根本的なことが、最初からきちんと見通せていないことも多いです。また、さまざまな制約条件、さまざまな要望や要求、使えるリソース……こうした変数をもとに最適解を導き出していくなかで「本当にやりたかったことはコレだったんだ！」と気づくことも多いのです。

そんな未知の要素が多いプロジェクトにおいては、プロジェクト全体の地図の役割となるWBSは逆に厄介な存在にもなり得るののです。

「作ってみたけど欲しいものではなかった」「着手してみたら立てたスケジュールに意味がなかった」そういうプロジェクトには、したくないものです。

WBSとは、詰め将棋のようなもの

一方で、「これを作れば絶対成功間違いなし」というターゲットが明確であり、そこに至る道筋もきちんと見通せているならば、WBSは大きな効果を発揮します。

将棋にたとえるならば、プロジェクト序盤や中盤は手が広く、あいまいな状況のなかで方針を立てていくフェーズであり、どんなに頑張って考えても「なんちゃってWBS」になってしまいがちです。

逆にプロジェクト終盤は、詰むか、詰まないかがロジックで追いかけられます。一手の間違いが致命的なミスにつながりかねない、そんなときはWBSを軸にした精度の高い計画が効果的です。

WBSは、正しく作って正しく使えば、強い味方になるツールです。ぜひ、有効な場面で効果的に活用しましょう。