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

menuclear
ホーム > ブログ > 工藤 武久の記事一覧 > 【第78回】標準WBSの神話


【第78回】標準WBSの神話


ご訪問ありがとうございます!          < 前回 | 目次 | 次回 >

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

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

 

【 あらためてWBSとは? 】

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

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

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

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

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

<新人P子さん> : 「えー!?WBSって、プロジェクトマネジメントの基本じゃなかったの?じゃ、どうやって進捗管理とかしてんの?」
(やっぱり、M男の言ってることは当てになんないわ!)=P子さんの心の声

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

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

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

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

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

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

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

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

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

 

【 標準WBSの意義 】

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

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

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

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

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

 

【 標準WBSの神話 】

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

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

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

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

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

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

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

それでは次回もお楽しみに!          < 前回 | 目次 | 次回 >

工藤武久

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

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

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

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

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

| 目次

採用情報
PM-waigaya
PM-WaiGaya
コンサルタントのトーク動画
PM Weekly Talk
PM Weekly Talk
コンサルタントが語る「PMBOK®12 の原理・原則」

Profileプロフィール

Avatar photo
工藤 武久
■株式会社アイ・ティ・イノベーション  ■コンサルティング本部 - 東日本担当 ■学歴:早稲田大学 - 第一文学部卒業 ■メーカー系のシステム子会社にて、主に官公庁向け大規模システム開発プロジェクトに、SE、PMとして携わる。立ち上げから運用保守フェーズに至るまで、システム開発プロジェクトの幅広い実務経験を重ねた。 ■2007年より株式会社アイ・ティ・イノベーションにおいて、大規模プロジェクトにおけるプロジェクトマネジメント支援や品質管理支援等のコンサルティングを手がける。 ■PMP、情報処理技術者試験(プロジェクトマネージャ、システム監査技術者他)など。 ■Twitter:https://twitter.com/iti_kudot  ~・~・~・~・~・~・~・~・~・~ ■ ブログランキングに参加しています! ◆人気ブログランキングにほんブログ村 ↑是非応援(クリック)お願い致します↑ ~・~・~・~・~・~・~・~・~・~ ■主なタグ:統合, スコープ, タイム, コスト, 品質, 人的資源, コミュニケーション, リスク, 調達, ステークフォルダ

Recent Entries最近の記事