私の本職は企業相手のビジネスコンサルティングなわけですが、その中身はさまざまです。事業立ち上げや事業計画作成などのお手伝いが多いですが、馴染みのお客様から不調事業の立て直しを頼まれることもあります。
このときもそうでした。
以前に事業立ち上げをお手伝いしたお客様からお声がけいただき、事業の立て直しをお手伝いしていました。
最初の1年間は幹部の皆さんとトップダウンの改革を進めたのですが、あまりうまくはいきませんでした。“止血”の名のもとに外部流出するお金を厳しくコントロールしたことで赤字を脱することはできましたが、そこから先に進めなくなってしまいました。
いろいろと悩んだ結果、私たちが目指したのは「黒字体質」への転換でした。
事業の体質改善といえば資金調達力強化から働き方改革までさまざまですが、私たちがこのときに取り組んだのは「プロジェクトマネジメント力の底上げ」でした。赤字の原因が大規模プロジェクトのコスト超過にあることは明らかでしたし、今後、厳しい戦いを勝ち抜くためにはプロジェクト運営の効率化は避けて通れなかったからです。この組織のマネジメント、とりわけプロジェクトマネジメントはお世辞にも褒められたものではありませんでした。
私たちは、プロジェクトマネジメントの基本の「き」として、主要プロジェクトを対象に、昼夜を問わずWBS（Work Breakdown Structure：作業分解構成図）の作成に取り組みました。プロジェクトで必要な作業を網羅的に洗い出すところから始めたのです。
WBSはスケジュール管理やコスト管理の背骨です。自分たちの作業をきちんと洗い出せないようでは、プロジェクトマネジメントもへったくれもありません。
私はたくさんのプロジェクトを相手に週次の計画作成会議を繰り返しました。慣れない業界だったので当初は戸惑いもありましたが、持ち前の明るさと砕けたしゃべり口調が現場に受け入れられたこともあり、すぐにペースをつかむことができました。
前置きが長くなりましたが、そんなときに、プロジェクトマネージャたちからの最初の質問は決まってコレでした。
「タスクはどの程度まで詳細化すればいいのですか？」
今になって思うと、最初のころは、私はうまくアドバイスできていませんでした。
時間はかかりましたが、洗い出されたWBSをもとに計画を作成し週次でそれを進捗管理するうちに、頭の中のシナプスがいい感じにつながり始め、詳細化の勘所が身に付きました。
さて、タスク詳細化の勘所を披露する前に、私たちが取り組んだプロジェクトマネジメント力底上げの狙いをお話ししておかないといけません。なぜなら、何が狙いかによって詳細化のあり方が違うからです。
［プロジェクトマネジメント力底上げの狙い］
- 計画段階にスケジュールの実現性を評価できること。
- 計画段階にプロジェクトコストを適切に積み上げることができること。
- 実行段階の遅れに対して速やかに対処できること。
- 実行段階の実績コストと着地予測を把握できること。
早く本題に話を進めたいところですが、もうワンステップ踏ませてください。
列挙したこれらの狙いを達成するためには、WBSの詳細度はどんな要素を満たさなければならないのでしょうか。
このとき、私たちが考えた要素がこれらです。
［WBS詳細度が満たすべき要素］
- 段取りが明らかになっている。
- リソースの過負荷を明らかにできる。
- タスクの依存関係を明らかにできる。
- 週次の進捗管理で進捗状況を説明できる。
そんなわけで、これが本題です。
これらの要素を踏まえ、タスク詳細化の勘所がこれです。
［タスク詳細化の勘所］
- タスク間の依存関係（終わったら始まる）を表現できる詳細度にする。
- タスクの担当者を１名に特定できる詳細度にする。
- 部署や会社を跨いだ情報のやり取りを表現する。
- ドキュメント作成などのメインタスクの前後作業に着目して記述する。
詳細化が大雑把すぎるとタスク間の依存関係をうまく表現できません。タスクの途中から次のタスクが始まったり、無理に「終わったら始まる」を表現しようとすると計画に無駄な余裕期間が発生したりします。
例えば「設計」というタスクは「関連情報収集（1日間）」「設計方針検討（1日間）」「図面作成（3日間）」「図面レビュー会（3日のうちの2時間）」「レビュー結果反映（1日間）」「図面発行（１日間）」というタスクに詳細化できるとします。レビュー前に設計者の手を離れるので、図面作成が終われば次のタスク「試験準備」に入れるはずです。ところが「設計」や「試験準備」という詳細度で計画が放置されてしまうと、設計が終わってから試験準備をするという依存関係となり、実態に比べて5日間の余裕が生まれてしまいます。
ひとつのタスクに複数の担当者を割り当てることはよくありますが、担当者ごとに着手するタイミングや完了するタイミングは異なるものです。早く終わった人は次のタスクに取り掛かるかもしれません。
ひとつのタスクに複数の担当者を割り当てていると、先行するタスクがすべて完了した後でなければ後続するタスクに着手できないような計画となり、ここでも余裕が発生してしまいます。
部署や会社を跨いだ情報のやり取りは段取りそのものです。このようなやり取りは、実働時間（実際に作業に関わっている時間）とは関係なく期間を要するものです。きちんと表現できてないと、停滞が発生した際の責任の所在も曖昧になりがちです。情報のやり取りが適切に行われずになんとなく遅延してしまうことはよくあります。
計画が苦手な人は大雑把に考えただけでプロジェクト全体を理解したつもりになりがちです。しかし、このとき頭の中で想定しているのは、解析作業であったり、図面作成作業であったりといった、いわゆるメインのタスクだけです。この以前には情報収集や方針検討といった準備作業が、この以降にはレビューやレビュー結果反映といった仕上げ作業が付き物です。
これらの作業をきちんと洗い出しておかないと、計画期間が過小見積りとなってしまうことがよくあります。
計画を作成するプロジェクトマネージャや計画作成に関わるプロジェクト関係者がプロジェクト開始前に作業手順を想像しウォークスルーできることは、WBSを作成する大事な狙いのひとつです。
私はこう考えています。
「WBS作成は関係者たちの想像のウォークスルーだ」
詳細化を軽視すると大雑把な見込みだけでプロジェクトを開始してしまい、実行フェーズになって予期せぬ問題が噴出してしまいます。
タスクの詳細化は計画作成の中でもビッグイベントのひとつです。
私の唱える“詳細化の勘所”が、皆さんのお役に立てばと思います。
★★★ 概念化.com を立ち上げました ★★★
★★★ ぜひ、お立ち寄りください ★★★
