DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

ご訪問ありがとうございます！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

前回は、テーラリングという便利な概念に隠れた『不都合な真実』（組織標準の質の悪さ）について考察しました。組織標準は個別プロジェクトの結果による継続的改善を重ねることで、できるだけそのまま適用できるぐらい具体的で実用的なものを目指す必要があります。

今回は、組織標準の中でもプロジェクト計画を組み立てるうえで中心的な位置づけとなるはずの標準WBSについて考察します。

【　あらためてWBSとは？　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
システム開発プロジェクトに携わっていると、WBSという用語を耳にしない日は無いぐらいに感じます。しかし、WBSを用いたプロジェクトマネジメントが現実のプロジェクトにしっかり根付いているかというと、ちょっと疑問です。というのも、よくよく思い返してみると、WBSという用語が次に示すような脈絡で使われていることが多いのが現実です。（※１）

＜　WBSという用語が使われる脈絡の例　＞
主に進捗会議などで、部長などの管理職クラスからの発言として。。。
１． やるべき作業をしっかりWBS化して、進捗を定量的に報告すること。
２． その遅延はWBS上のどのタスクに該当するんだ？
３． なんで、WBSを作らずに進めてるんだ！
４． 今回やったことをWBSとして整理して、次のプロジェクトにも役立てるように！
・・・

Ｐ子さんが不思議そうな顔をしています。

＜新人Ｐ子さん＞　：　「なんか変じゃないですか？この発言だけ聞いてると、結局、最初から最後までWBS作らずにプロジェクトを進めてたみたいに感じるわ？そんなことってあるんですか？」

＜ベテランＰＭのＭ男氏＞　：　「アホか？プロジェクトは問題だらけで、そんなに細かくタスクを分解して計画たてると、毎日のように細かい計画を見直さなきゃならんから、WBSで管理するなんて非現実的じゃ！上がうるさいから最初はそれっぽいもん作るが、遅延がかさんでくると結局誰も見向きもしなくなるんじゃ！」

＜新人Ｐ子さん＞　：　「えー！？WBSって、プロジェクトマネジメントの基本じゃなかったの？じゃ、どうやって進捗管理とかしてんの？」
（やっぱり、Ｍ男の言ってることは当てになんないわ！）＝Ｐ子さんの心の声

・・・　おやおや、今回のブログテーマは、個別プロジェクトで作るWBSのもととなるはずの標準WBSです。しかし、肝心のWBSが現実のプロジェクトでうまく活用できていないとしたら。。。いったい世の中で、よく言われている標準WBSっていったい何のために整備されているんでしょうか？

標準WBSの議論に入る前に、まずはWBSの定義を見てみましょう。まずは、PMBOKガイド第5版の記載から見てみましょう。（※２）

WBSは、プロジェクトマネジメント業務を含めたすべての成果物とプロジェクト作業を表すものである。最下位レベルのすべての作業を上位レベルにまとめ上げることにより、何も取りこぼしが無く余分な作業を行うことも無くなる。これが100パーセント・ルールと呼ばれる。

ワーク・ブレークダウン・ストラクチャー（WBS：WorkBreakdownStructure）．プロジェクト目標を達成し、必要な成果物を作成するために、プロジェクト・チームが実行する作業の全範囲を階層的に要素分解したもの。

次に、ITmedia エンタープライズの情報システム用語事典から引用します。（※３）

WBS
work breakdown structure / ワーク・ブレークダウンストラクチャ / 作業分解図 / 作業分割構成 / 作業の詳細構造

プロジェクトマネジメントの計画フェイズにおける主要なツールで、プロジェクトの成果物あるいは仕事（work）を詳細区分（breakdown）して階層構造（structure）化した図表、あるいはその図表によってプロジェクトのスコープ全体とその中で作られる成果物ないしは作業の関係を体系的に集約・把握する手法のこと。

WBS作成はプロジェクト計画の初期に行う作業で、プロジェクトで実施されなければならないすべての作業を洗い出し、同時にプロジェクトマネジメントにおけるコントロール単位を明確化するものとなる。WBSはその後のプロジェクト工数の見積もり、日程計画（ネットワーク図など）、調達管理（外注化判断）、資源配分計画（役割分担表など）、予算／コスト管理（EVMSなど）、リスク管理といったフェイズのベースとなるもので、プロジェクトマネジメント全体の基盤となる。
・・・

うーむ。これらの定義を見ていると、確かにWBSがしっかりできていなければ、スコープ、スケジュール、コスト、調達・・・ほとんどの知識エリアに影響してくるようです。なのに、なぜ、必ずしもプロジェクトの現場でWBSを使った管理がしっかりできていないということがあり得るのでしょうか？Ｍ男氏のように考えているプロジェクトマネージャはごくまれであり、たいていのプロジェクトではプロジェクトで実施すべきタスクをしっかりとWBS化して管理できているのでしょうか？単なる杞憂でしかないのでしょうか？

【　標準WBSの意義　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
そもそもWBSが有効活用されていないとすると標準WBSなどあってもあまり役に立たないでしょうから、逆説的に標準WBSと言う考え方があるということはWBSが現実のプロジェクトでそれなりに活用されているという前提でここからの議論はスタートしましょう。

先ほど見たように、WBSはプロジェクトのスコープ、スケジュール、コストなどの計画を立てる上での骨格となるものです。このWBSが属人的に作成された場合、重要なタスクの抜け漏れやタスク粒度のばらつきにより進捗把握に不正確さが入り込むなど、的確なプロジェクト運営ができなくなる可能性が生じることになります。このような属人化によるデメリットを排除するために、過去プロジェクトの実績などからプロジェクトで想定される全てのタスクをあらかじめ洗い出してテンプレートとして準備しておいたものが標準WBSです。

標準WBSは、プロジェクトで実施すべきタスクの定義を行うだけでなく、標準WBSに含まれる各タスクを実施すべき標準的なスキルセットや工数、日数、成果物ボリュームなどの属性をセットで整理しておくことで、コスト見積りやスケジュール検討のベースとしても使える便利なものです。全てのプロジェクトが標準WBSをもとにWBSを組んでいけば、複数プロジェクトの管理レベルを合わせることが可能であり、複数プロジェクトを横並びで比較してコントロールすることが可能になります。

＜　標準WBSを利用することの主なメリット　＞
１．プロジェクトで実施すべきタスクの抜け漏れを防止できる
２．タスク粒度を均一化することで、管理レベルの均質化を図ることができる
３．コストやスケジュール見積りなどの標準的な指標値のもととすることができる
４．プロジェクト立ち上げ時の計画策定が省力化できる
・・・

こうして考えていくと、誰しも標準WBSをしっかり作り込むことが、システム開発の組織成熟度を高めるための近道であると結論づけることになるでしょう。。。

【　標準WBSの神話　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
ここまでWBSの定義や標準WBSの意義について確認してきましたが、もう一度現実のプロジェクトに目を向けてみます。先ほどあげたような標準WBSのメリットは、確かにその通りだと思います。しかし、現実のプロジェクトには独自性があり、さまざまな不確実性（リスク）が内在するものであり、不条理に満ち溢れています。（※４）

いくら標準WBSのような、どのプロジェクトでも通用する部分の標準テンプレートを構築し、それらを活用することによって、どのプロジェクトでも同じように実施する部分の生産性や品質が高まったり均一化が図れたとしても、それだけで独自性を持つプロジェクトを成功に導くことはできないことに気付く必要があります。

何も標準WBSが使いものにならないというわけではありません。標準WBSは、経験の少ないプロジェクトマネージャなどにとっては有効なツールとして機能することは確かだと思います。だからといって、標準WBSを活用したことでプロジェクトが成功する確率が高まるという論拠にはならないのです。（私はこのことを「標準WBSの神話」と呼んでいます。）

なぜなら、プロジェクトが失敗する理由の大半は、プロジェクトの独自性に起因する部分だからです。プロジェクトのスコープや規模の違い、採用する技術の違い、関係するステークフォルダーの思惑の違い、リリース日や予算などの制約事項、などなど実にさまざまな違いに応じて、WBSの構成要素や各タスクに含まれる属性を変えていく必要があるのです。

そして、Ｍ男氏の発言を肯定するわけではないですが、プロジェクト実行中にはさまざまな状況の変化が発生することから、一度組んだWBSを常に見直しながら状況の変化に対応させていく必要があるのです。つまり、WBSは一度組んだらそれで終わりではなく、何度も見直しを繰り返していく必要がある、いわば生き物のような存在なのです。

なので、冒頭で紹介した　＜　WBSという用語が使われる脈絡の例　＞　は、プロジェクトマネジメントの基本ともいうべきWBSを単に「作っていない」ということではなく、「プロジェクト状況の変化に応じたWBSの見直しが行われていない」ということの現れだと考えらるのです。

「WBSは一度作ったら終わりではなく、プロジェクト状況の変化に応じた見直しが欠かせない！」

それでは次回もお楽しみに！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
応援してくださる方は、クリックよろしくお願いします！
◆　人気ブログランキング
◆　にほんブログ村
～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～

※１　詳細WBSについては、当ブログの以下の回参照。
・【第７４回】プロジェクト・スケジュールのミドル・アップダウン構築法

※２　Project Management Institute, Inc.(2013)『プロジェクトマネジメント知識体系ガイド（PMBOK®ガイド）』（第5版）Project Management Institute, Inc.

※３　ITmedia エンタープライズ > 情報マネジメント用語辞典 > 情報システム用語事典：WBS（だぶりゅーびーえす）
http://www.itmedia.co.jp/im/articles/0508/05/news117.html

※４　プロジェクトにおける不条理については、当ブログの以下の回参照。
・【第５０回】『変身』～プロジェクトの不条理への挑戦状