ITプロジェクトの実践～スコープ・マネジメント～ 第1回 WBSを作ってみよう｜建設情報クリップ

 

 

---

 
ITプロジェクトを成功に導くためには、どのようにマネジメントすればよいだろうか？
プロジェクトマネジメントにも基本と呼べるような技がある。
今回の連載では、ITプロジェクトの混乱防止に役立ちそうなプロジェクトマネジメントの「技」を紹介する。
第1回目は、スコープ・マネジメントの知識エリアからWBS（Work Breakdown Structure）を取り上げる。
プロジェクトマネジメントの「基本中の基本」に当たる技法で、WBSの善し悪しでプロジェクトの成功は大きく左右される。
 
 

本連載で取り上げるプロジェクトマネジメントとは、正確には「モダンPM（プロジェクトマネジメント）」と呼ばれる手法です。
従来のやり方との違いは、「普遍的、汎用的にまとめられたPMの知識体系を使って」プロジェクトをマネジメントするところです。
図-1に、我が国で最も普及しているPMの知識体系「PMBOKⓇガイド」が提供する知識エリアを示しました。
統合、スコープ、人的資源、コミュニケーション、リスク、調達、ステークホルダー（利害関係者）、品質、
コスト、タイムの10の知識エリアがあります。
 

 
今回紹介するWBSは、スコープ・マネジメントで利用する技法です。
スコープとは、「範囲」のことで、スコープ・マネジメントの知識エリアでは、プロジェクトの成功に必要な成果物と作業を定義し、
プロジェクト完了時にそれらが完成されたことを保証するための知識をまとめています。
その中心になる技法がWBSです。
 
 

WBSは、
「目的を達成するために必要な作業（Work）を漏れなく分解（Breakdown）し、構造化（Structure）して見える化する」
技術です。
図-2に様々なWBSの例を挙げました。
表現方法に決まりはありませんが、①、②のようにツリー形式、もしくは③のようにリスト形式で階層構造を表すのが一般的です。
 
WBSは、PMの普及により注目を集めた技法ですのでプロジェクトマネージャのみが利用する技術と思われがちですが、
概念が提唱されたのは1960年代にまで遡ります。
様々な分野の開発プロジェクト（図-2①②）で利用することはもちろんですが、
イベントの計画立案が必要になったとき（図-2③）や工場の工程管理、家族旅行を計画するなど、
日常の業務や普段の生活でも役に立ちます。
 

 

ではWBSには、どういうメリットがあるでしょうか。
整理すると、以下の6つのメリットが挙げられます。
 
●メリット1　作業の抜け・漏れ、重複を防止できる
●メリット2　作業の進め方が共有できる
●メリット3　プロジェクトのスコープが決まる
●メリット4　計画が明確になる
●メリット5　分解して管理する習慣が身に付く
●メリット6　先を見る習慣が身に付く
 
それぞれのメリットについて見ていきましょう。
 

WBSを作る過程で論理的に作業や成果物を分解していきます。
この分解するという思考そのものが抜け・漏れや重複への“気付き”を促進します。
 

慣れている仕事ならいきなり作業を始めるケースもあると思いますが、
そうでない場合は、作業のイメージや段取りを考えてから取り掛かると思います。
もし、いきなり始めてしまったらどうなるでしょうか？
図-3のように作業の進め方や役割分担で問題が出てくるかもしれません。
図-2②に造船の例を挙げていますが、
なじみのない人でもWBSをみれば作業の進め方についてある程度のイメージを持つことができます。
また、WBSに記述された言葉を使うことによりコミュニケーションミスを防ぎます。
 

 

先に挙げたPMBOKⓇガイドには、「WBSはプロジェクトスコープのベースライン」と記述されています。
ベースラインという言葉は、プロジェクトマネジメントの文脈の中で使うとステークホルダー間で合意した基準を指します。
つまり、WBS に書かれている作業がプロジェクトの「スコープ内」で、WBSに書かれていない作業は「スコープ外」となります。
スコープがあいまいな状態だと、追加作業に要する費用を巡り、発注側とベンダー側でトラブルになりかねません。
 

WBSはプロジェクトで作成する計画の入力情報となります。
図-4に示すようにスケジュールや役割分担はWBSに記述された作業を基に決めていきます。
必要な工数やコストの把握、必要なリソースの洗い出しもWBSを基に行います。
品質計画とリスク対応計画を立案する際にもWBSは入力情報となります。
WBSから作業イメージを思い描き、「ここは大丈夫か」と気配りすることで、品質上の問題点やリスクに気付くことがあります。
 

 
このように管理しやすい、しっかりした計画は、よいWBSの作成から始まります。
 

大規模なプロジェクトやよく定義されていないプロジェクトは、WBSを基に小さな単位に分割して統治することが大事です。
マネジメント上の問題、例えばスコープ、納期、コストといったトレードオフの関係にある項目の調整は、
小さな単位で解決し、プロジェクト全体に影響が及ぶのを防ぎます。
 
プロジェクトに限らず、大きな仕事や自分が経験したことがない仕事を与えられたら、
できる限り問題を局所化し対応方法を考えることが大事です。
WBSの利用を続ければ、こうした習慣を自然に身に付けることができます。
 

WBSはゴールまでの道筋を考えながら作成します。
実際に洗い出していると「思っていたより大変！」「なんだ、これとこれをやればいいのか」といった気付きが得られます。
 
プロジェクトを遂行する上で、最も大切なリソースは「時間」です。
お金は使わなければ残りますし、調達することもできます。
しかし、過ぎ去った時間を取り戻すことはできません。
だからこそ、時間を無駄にしないために、プロジェクトの「先を読む」ことが求められます。
また、プロジェクトに限らず、普段の仕事の中でも、先を見て時間をうまく使えれば作業効率は高まります。
 
 

図-2のように例を見ればWBSがどういうものかは容易にイメージできますし、簡単に作れそうにも思えます。
しかし、いざ作ってみようとすると意外に難しいのがWBSです。
どんなことを考え、どんな形で作っていけばよいのでしょうか？
いくつかの定石がありますので、それを紹介していきます。
 

WBSは、計画段階で作ります。
そうはいっても、ソフトウェアの開発が伴うプロジェクトでは不確定要素が多く、
設計が終わってみないと次の作業が見えてこないというケースがあります。
こういう場合でも、WBSは作成します。
例えば、今から作業に着手する上流工程のWBSは詳細に作っておいて、下流工程のWBSは粗く作っておきます。
上流工程で仕様が明らかになった段階で、下流工程のWBSを詳細化していきます。
 
波は海岸近くでは細かく砕け散りますが、遠くの方は大きく見えることから、
プロジェクトマネジメントの世界では、段階的詳細化のことをローリングウェーブ計画法と呼んでいます。
 

WBSの表記は、図-2に示したようにツリー形式、もしくはリスト形式で記述するのが一般的だと説明しました。
2つの表記法をどのように使い分ければよいでしょうか？
 
ツリー形式のよいところは直感的かつ鳥瞰的に理解しやすい点です。
一方、リスト形式のよいところは、スケジュールや役割分担の作成につなげやすい点です。
WBSのアウトラインを作っていくときには、付箋紙やホワイトボードなどを使いツリー形式で書いて全体を整えていきます。
ツリー形式は、チームで相談しながらWBSを作る際などに思考ツールとして利用すると効果的です（図-5）。
 

 
出来上がったWBSは、表計算ソフトなどを使ってリスト形式にまとめてプロジェクト計画につなげていきます。
 

作業を洗い出す際には、通常、最上位の作業を定義（図-2①の例では、「○○システムの開発」）し、
上位から作業を分解するというトップダウンのアプローチが用いられます。
トップダウンで作業を洗い出すときに大切なのは、まず1つの視点を決めて洗い出し、その後、視点を変えて補足していくことです。
筆者らは、この視点として「成果物ベースの分解」と「プロセスベースの分解」を勧めています。
 
成果物ベースの分解は、
上位の成果物（サービス含む）とその構成要素（部品やサブシステムなど）の関係に従って作業を洗い出します。
図-2①の「ITプラットフォームの構築」のように「ITプラットフォーム」は、「サーバー」と「ネットワーク」から構成され、
「サーバー」は、さらに「Webサーバー」、「APサーバー」、「DB サーバー」から構成されるというように
成果物の構成要素に従って分解していきます。
そして構成要素を基に対応する作業（設計、輸送、工事など）を洗い出していきます。
作業開始前に成果物がある程度明確に定義されている場合に有効です。
 
これに対してプロセスベースの分解は、
時間軸（作業の進め方）に沿って作業を洗い出していきます（図-2①の「業務ソフトウェアの開発」参照）。
ソフトウェア開発を伴うプロジェクトのように成果物が計画段階でよく定義されておらず、
ローリングウェーブ方式で進めるときにはプロセスベースで分解していくことが有効です。
 

作業の分解に当たっては、「漏れなく」洗い出すことが大切です。
これが「100％ルール」です。
親子関係の子に当たる作業の集合が、その上位の親の作業内容を網羅するように作ります。
100％ルールは、WBSのすべての階層に適用されます。
作成したWBSについては100％ルールを満たしているかどうかを確認します。
 
 
今回は、WBSを取り上げ、メリットや作る際のポイントについて紹介しました。
 
WBSは、プロジェクトマネジメント固有の技術と思われがちですが、普段の仕事や生活でも役に立つ技術です。
まずは、身近なものから活用してみてはいかがでしょうか？
 
 
〔編注〕
プロジェクトマネジメントにつきましては、「積算資料」2013年10～12月号に「プロジェクトマネジメントの薦め ～ ITプロジェクトを成功に導く～」も掲載しております。
 
第1回：なぜプロジェクトマネジメントが大事なのか？《前編》
第1回：なぜプロジェクトマネジメントが大事なのか？《後編》
第2回：プロジェクトマネジメントの知識体系《前編》
第2回：プロジェクトマネジメントの知識体系《後編》
最終回：プロジェクトマネジメント・オフィス《前編》
最終回：プロジェクトマネジメント・オフィス《後編》
 
 
 

［1］PMI（Project Management Institute）「プロジェクトマネジメント知識体系ガイド（PMBOKⓇガイド） 第5版 日本語版」、
　　 PMI、2013
［2］初田賢司「システム開発のためのWBSの作り方」、日経BP社、2012
 
 
 
【出典】

---

月刊積算資料2014年7月号

 
 

最終更新日：2014-08-19

 

ピックアップ電子カタログ