WBSを制するものはプロジェクトを制す！WBSの意味とその目的

プロジェクト計画時には必ずWBSを行います。

 

規模の大小はありますが、WBSを作る際には、設計・デザイン・制作（開発）・テストといったフェーズごとに作業者を複数名アサインし、それぞれのメンバーに分担して任せることになるかと思います。

 

先日、とあるプロジェクトの要件が具体的になったので、エンジニアのリーダーの方にWBSを依頼したところ、「WBS」という作業自体に認識のずれがあることがわかりました。

 

その時は、お互いにWBSのタスクイメージをすりあわせることで、認識相違でないことがわかったのですが、「WBSもディレクター同様、会社によって定義が異なるものなのかな？」と、改めてWeb屋の仕事の役割や定義について考えさせられました。

（ディレクターの定義や役割についてはコチラの記事を参照）

 

僕自身、タスクのゴールイメージがブレていなければ、定義にこだわる必要はないと思っているのですが、いい機会なので再認識を兼ねてWBSについて整理してみようと思います。

 

WBSの認識相違

考えるキッカケとなった「WBS」の認識ブレについて説明してきます。

 

僕の理解では、

 

WBS = タスクの洗い出し、タスクの分解

 

なのですが、エンジニアのリーダーは、

 

WBS = スケジュール

 

でした。

 

どっちが正しいのか、はたまた二人とも間違っているのか。

まず手始めに言葉の定義からいきたいと思います。

 

WBSとは

そもそも、「WBSとは一体何なのか？」ですね。

 

WBSは、Work Breakdown Structureの略で日本語にすると、作業分解構成図になります。

「作業分解構成図って何なんですか？」という声が聞こえてきそうなので、以下、WBSの定義を引用します。

 

WBSとは、プロジェクトマネジメントで計画を立てる際に用いられる手法の一つで、プロジェクト全体を細かい作業に分割した構成図。

WBSでは、まずプロジェクトの成果物をできるだけ細かい単位に分解していく。その際、全体を大きな単位に分割してから、それぞれの部分についてより細かい単位に分割していき、階層的に構造化していく。成果物の細分化が終わったら、それぞれの部分を構成するのに必要な作業（一つとは限らない）を考え、最下層に配置していく。個々の部分を構成する一連の作業のかたまりのことを「ワークパッケージ」と呼ぶ。WBSのそれぞれのワークパッケージに担当する人員を配置していけば、プロジェクトを遂行する組織図ができる。これをOBS（Organization Breakdown Structure）と呼ぶ。

引用元：http://e-words.jp/w/WBS.html

 

内容から、「WBS = スケジュール」と解釈するのはちょっと難しいですね。。。

 

ここはやはり僕の理解である「タスクの洗い出し、タスクの分解」の方がマッチしているということで先に進みたいと思います。

（こっそりひと安心とします。笑）

 

スッキリしたところで、次にWBSの目的について考えてみます。

 

WBSを行う2つの理由

WBSが「タスクの洗い出し、タスクの分解」であることはわかりました。それでは、なぜ「WBSを行うのか」について言及したいと思います。

 

僕は、以下の2点ためにWBSを実施をしています。

• 工数算出・スケジュールを作るため
• タスクの内容を理解するため

 

一般的には、前者の「工数算出・スケジュール作成」のために実施するものであると説明されているかと思います。一方、後者の方は、過去の経験からとても重要視している点になります。

 

僕の考えるWBSについて興味のある方は、「タスクの内容を理解するため」を一読いただければ幸いです。

 

工数算出・スケジュールを作るため

工数算出とは、成果物を作り上げるために必要な各タスクがどのくらいボリュームがあるのかを把握する作業であり、スケジュールは、ボリュームが判明した各タスクをいつ・誰が・実行するか、を計画するものになります。

 

そのため、タスクの洗い出し・分解であるWBSは、スケジュールを作る上での先行タスクとなります。

WBSはスケジュールを作成するための中間成果物ということですね。

 

ここでちょっと言葉の定義に戻りますが、「スケジュールを作成する」という作業の流れを見ると、まずWBSを行い、次に各タスクの工数を算出し、最後にタスクの前後関係やクリティカルパスを意識しながら線表にしていくため、WBSが甘いと手戻りを余儀なくされます。

 

そう考えると、WBSにかかる比重はかなり高いので、「WBS = スケジュール」という考えはあながち間違っているわけでもないことがわかります。

 

とは言え、規模の大きな案件の場合は、スケジューリングする前に、WBSに抜け漏れがないかといった中間レビューを入れることも多いので、その場合は明確に「WBS」と「スケジュール」の作業をわけて管理する必要があります。

 

やはり、WBSはWBSとして、あくまでスケジュールを作るための前タスクとして考えたほうが良いかと思います。

 

タスクの内容を理解するため

先に述べたとおり、教科書通りだとWBSは「スケジュールを作るための中間成果物」として考えられているかと思います。

ところが僕はWBSに、もうひとつの目的をもっています。

 

それは「タスク内容を理解すること」です。

 

プロジェクトマネージャーやディレクターなど、プロジェクトマネジメントの役割を担うポジションの人は、「クライアントが求める成果物は何なのか、そして、それはどうやったらできるのか」を理解する必要があります。

 

例えば、設計・デザイン・コーディング・開発・テストといった各フェーズごとに複数人のメンバーをアサインする場合、各メンバー（ないしはチームのリーダー）にWBS作成の指示を出し、まとめ上げるようなステップを踏みます。

 

その際、自分の得意分野でないフェーズを担当するメンバーから提出されたWBSを見ても、「定義されている成果物が一体どんなものなのか」また「そのタスクが一体どういうことをするものなのか」が、理解できないことがあります。

 

当然、不明なタスクや成果物がある場合は、それらをすべて把握・理解する必要があります（自分で作業できるようになる必要はありません）

そのため僕は、自分とってよくわからないタスクを確認することをWBSで実施しています。

 

なぜ、WBSでタスクの理解をするようになったのか

その昔、とあるクライアントにてデータセンター移設に伴う、サーバをする移管プロジェクトの相談がありました。

 

当時の会社には、インフラの知見があるWebディレクターはいなかったため、プログラミング経験のあるディレクターである僕が白羽の矢が立ちました。

理由は「システムがわかる奴が他にいないから頼む」という理由からです。

 

「だから〜、システムという言葉でプログラムとインフラ一緒にしないでくださいよ〜」

 

という意見はいつものとおり無視され、今回も無事（！？）に僕がディレクターとしてアサインされることになりました。。。

 

とは言え、僕はプログラミング経験しかないので、インフラ系プロジェクトのディレクションはできませんし、もちろん作業もできません。よって、過去に別のプロジェクトでお付き合いのしたことのある開発会社さんに外注することで請け負える体制を構築しました。

 

信頼できる開発会社さんだったこともあり、

 

「とりあえず、いつもどおりディレクションすればなんとかなるかな」

 

なんて楽観的に考えてしました。

この時点でWebディレクター（プロジェクトマネージャー）失格ですね（笑）

 

いつもどおり要件定義を終え、スケジュールを作るタイミングになったので、「要件にしたがってWBSと工数算出を行い、概算見積もりをお願いできますか」と、開発会社に依頼しました。

（この時、開発会社へは設計から先すべてを丸投げする形での依頼です）

 

ところが数日後、概算見積もりとその根拠となるWBSと各タスクの工数を説明してもらうMTGの場で、冷や汗が止まらない事態になりました。

 

ヤバイ、、、わからないタスクが多い・・・

 

概算見積もりに記載している想定成果物でわからないものが幾つかあり、さらにWBSの説明を受けてもそれが一体何をするタスクかわからないものもありました。

 

そのため、とりあえず気になった点を指摘する程度でMTGが終わってしまったのですが、自席に戻ってからも、「どうやってディレクションしよう。。。」と、途方にくれてしまいました。

 

上司に相談しましたが、「丸投げすればいいじゃん」という回答なので、もはやコイツはアテになりません。

「オマエはいつも丸投げしか言わねぇし、それならWeb制作会社を辞めてどっかの代理店にいけよ」という言葉を飲み込み、プロジェクトをディレクションするためにどうしたらいいか考えました。

 

今更インフラタスクを理解しようにも時間がないので、今回は進行管理に徹し、わからないタスクを全部教えてもらうことにしました。

 

開発会社の方に事情を説明し、ロングミーティングにお付き合いいただき、すべてを教えてもらいました。

 

ただ、何でもかんでも聞くでは芸がないので、次フェーズから「開発会社と対等に話せるようになる」という目的を持って、タスクにはインとアウトが必ずあるという特性を活かし、

 

Aを作るためにはBとタスクが必要である。でもBという作業が具体的に何をするのかわからないので、さらにくわしく説明を求める。すると、Bのタスクをするためには、CとDという作業が必要で〜

 

という具合に、自分が理解できるところまで細かくブレイクダウンすることで、「スケジュールを作る」タイミングでは、開発会社のスケジューリングに意見できるくらいにはなりました。

 

これが功を奏し、WBSのタイミングでプロジェクトのリスクの洗い出すことができたので、早い段階でリスクヘッジ案を検討・実行することができました。

 

その結果として、サーバ移設当日は大きなトラブルもなく、1時間程度の遅れで完了させることができました。

 

これは、サーバ移設案件の成功体験として僕のポートフォリオに刻まれています（笑）

 

WBSを制するとどうなるの？

先の「タスクの理解」でわかった方もいると思いますが、WBSを徹底すると、

 

想定されるタスクを予見することで事前に「いつ・誰が実施するか」という計画の立案

 

が可能になります。

 

僕の経験則になりますが、予期せぬ事象で一番多いのは、プロジェクト計画時のタスク漏れです。

 

プロジェクトを進める上で、リスクは一つでも少ないほうが望ましいです。

 

作業者がインフルエインザになった、といった突発的な事象は受け入れるしかありませんが、未然に防げるものは、潰しておくことでプロジェクトが成功する確率は高まることは理解できると思います。

 

_{プロジェクト管理の上で、予期せぬ事象が発生することは仕方がないことは、以前リスクマネジメントの記事で触れたとおりです。}

 

つまり、WBSを徹底することは、最高のリスクヘッジになるということです。

 

最後に

読み返して見ると、こういうテーマこそが、このブログで書かなければいけないことですよね。。。。

 

今日は、WBSに軽く触れただけですが、まだWBSを実施する際に意識していることがいくつかあったりします。

 

というわけで、時間のあるときにWBS関連の記事を書いてみようと思います。

 

2017.9.18追記

WBSの記事として、WBSはどこまで細分化すればいいのか【WBSの記事第二弾】を公開しました。

よろしければ、こちらもご覧いただければと思います。

 

2018.1.17追記

当該記事が、レバテックキャリアに紹介されました。

プロジェクトマネジメントの参考になる記事まとめ