見出し画像

ズバリ!「仕事(WBS)をどの程度まで詳細化すればいいのか?」に答える

前回は「計画をどこまで詳細化すべきか」という極めて厄介な問題について書きました。
今回は、その続編とも言える内容です。
プロジェクトマネジメントの中でも実行計画に対象を絞り、さらに具体的に書きます。

私の本職はビジネスコンサルタントなわけですが、その中身はさまざまです。事業立ち上げのお手伝いや事業計画作成の指導などが多いですが、馴染みのお客様からは事業の立て直しを依頼されることもあります。

トップダウンで止血(外部に流出するお金を厳しくコントロールすること)に専念するのが定石ですが、この効果は長続きしません。止血は緊急措置でしかないからです。
そんなとき、私たちが目指すのは「黒字体質」への転換です。
この時もそうでした。

事業体質の改善のために私たちが取り組んだのは「プロジェクトマネジメント力の底上げ」でした。
業績悪化の原因が大規模プロジェクトの失敗にあることは明らかでしたし、厳しい事業環境を勝ち抜くためにはプロジェクトの効率化は避けては通れなかったからです。この組織のマネジメントマネジメントはお世辞にも褒められたものではありませんでした。

私たちは主要なプロジェクトを相手にWBS(Work Breakdown Structure:作業分解構成図)作成に取り組みました。
WBSはスケジュール管理やコスト管理の背骨です。自分たちの作業をきちんと洗い出せないようでは、プロジェクトマネジメントのスタート地点にも立てません。WBS作成はプロジェクトマネジメントの基本の「き」です。

私はプロジェクトチームを相手に計画作成会議に明け暮れました。不慣れな業界でしたが、持ち前の明るさが受け入れられたのか、すぐにペースをつかむことができました。

そんな中で繰り返されたのがこの質問です。

「タスクはどの程度まで詳細化すればいいのか?」


この質問の答えは、実行計画の目的によって様々です。
プロジェクトが実行計画に何を求めているかによって、詳細化の度合いは違ってくるからです。

私たちが取り組んだプロジェクトではこうでした。

[実行計画の目的]
・   スケジュールの実現性を評価できる。
・   実行段階に遅れに対して速やかに対処できる。
・   実行段階に最終着地予測を把握できる。

目的は整理できましたが、一足飛びに詳細度が決まるわけではありません。次のステップとして、目的を達成するための要件について考えなければなりませんでした。
実行計画の目的がプロジェクトによって異なるように、実行計画に求められる要件もプロジェクトごとに様々です。
当時、私たちが取り組んでいたプロジェクトでは、次のように考えました。

[実行計画に求められる要件]
・   段取りが明らかになっている。
・   リソースの過負荷を明らかになっている。
・   タスクの依存関係が明らかになっている。
・   週次の進捗管理で進捗状況を明らかにできる。

これを踏まえると、タスクの詳細化の度合いはこうなりました。

[タスク詳細化の度合い]
・   タスク間の依存関係(終わったら始まる)を明らかにできる。
・   タスクの担当者を1名に特定できる。
・   部署や会社を跨いだ情報のやり取りを表現できる。
・   主だった作業の前後に潜む準備作業やまとめ作業に着目して記述する。

上から順番に説明しましょう。

詳細化が大雑把すぎるとタスク間の依存関係をうまく表現できません。タスクの途中から次のタスクが始まることになるからです。これを避けて無理やり「終わったら始まる」という依存関係に単純化すれば、無駄な余裕期間が計画に埋め込まれることになります。

例えば「設計」というタスクは次のように詳細化できます。
・関連情報収集(1日間)
・設計方針検討(1日間)
・図面作成(3日間)
・図面レビュー会(3日のうちの2時間)
・レビュー結果反映(1日間)
・図面発行(1日間)

レビューの前に設計者の手を離れるので、この時点で次のタスクである「試験準備」に取り掛かれるはずですが、詳細化が大雑把すぎて「設計」「試験準備」という程度の詳細化だったとすれば、これを表現できません。
「設計」が終わったら「試験準備」に取り掛かるという依存関係になり、実態に比べて5日間の余裕が生まれてしまいます。

ひとつのタスクに複数の担当者を割り当てることはよくありますが、担当者ごとに着手するタイミングや完了するタイミングは異なるものです。早く終わった人は次のタスクに取り掛かることになるのでしょうが、担当者ごとにタスクを詳細化できていなければ、これを計画に表現することはできません。

部署や会社を跨いだ情報のやり取りは段取りそのものです。このようなやり取りは、実働時間以上に期間を要するものです。きちんと表現できてないと、停滞が発生した際の責任の所在も曖昧になりがちです。情報のやり取りが適切に行われずになんとなく遅延してしまうことはよくあります。

WBSを作成する狙いのひとつは事前に手順をイメージすることにあります。いい加減に詳細化したのでは、主だった作業しかイメージできません。この作業の前には情報収集や方針検討のような作業が、後にはレビューやレビュー結果反映などのタスクが付き物です。これを計画段階に書き漏らしてしまうと、計画していた以上の期間を要してしまうことになります。

かなり具体的に解説したつもりですが、いかがだったでしょうか。
タスクの詳細化は計画作成の最大の障壁と言えます。今回の内容が、少しでも皆さんのお役に立てばと思います。


★★★ 概念化.com を立ち上げました ★★★

★★★  ぜひ、お立ち寄りください  ★★★


この記事が気に入ったらサポートをしてみませんか?