「計画をどこまで詳細化すべきか」は計画者にとって極めて厄介な問題です。
そこで、経験から私なりに導きだした方法を紹介しましょう。
- 計画の目的を明らかにする。
- 目的達成に向けて実行計画に求められる要件を整理する。
- 要件を満足するにはどの程度詳細化すべきかを考える。
この方法を具体的に説明するわけですが、今回はプロジェクト計画を題材にとります。
プロジェクトマネージャになった気分で、タスクをどこまで詳細化するのが適切なのかについて、いっしょに考えていきましょう。プロジェクトマネージャが作成する計画はさまざまですが、わかり易さという点で、今回の対象には実行計画を取り上げます。
こんな目的を想定してみましょう。
［目的］
目的 ＝ 期限までにプロジェクトを完了する。
実行計画の目的としてはごく一般的です。事例はできるだけシンプルにしたいので、今回はコストを目的としません。
［目的達成に向けて実行計画に求められる要件］
- タスクが抜けなく洗い出されている。
- タスクが構造化され、上下関係（大分類、中分類、小分類などの包含関係）が明らかになっている。
- タスク間の依存関係（このタスクを開始するにはあのタスクが完了していなければならないなど）が明らかになっている。
- 遂行に適したリソース（担当者）がタスクごとに割り当てられている。
- タスクに適切な作業時間（所要時間や工数とも呼ばれる）が見積もられており、リソースに過負荷が生じていない。
- 期間依存のタスク（所要時間ではなく所要期間が完了までの期間が支配的なタスク）には適切な期間が見積もられている。
- 計画内容や個々のタスクの内容、着手基準や完了基準などを、タスクを担当するリソースと齟齬なく共有できている。リソースは計画内容に合意している。
- クリティカルタスク（期限に影響するために遅延が許されないタスク）やクリティカルパス（クリティカルタスクの一連）を特定できている。
計画しているタスクに抜けがあったのでは遅延が発生してしまいます。
タスクの依存関係はプロジェクトの遅延に直結するとても大切な要素です。頭で考えただけでは依存関係を正確にトレースできないので、それが原因で玉突きが発生したり想定していなかった待ち時間が発生してしまったりするものです。
リソースのスキルや経験がタスクに合っていなければ、計画通りに事が進みません。それが原因で品質不良が発生し、手戻りにつながってしまいかねません。
過負荷を放置すると、プロジェクトは進捗会議のたびにズルズルと遅れ始めます。
期間依存のタスクとしてベンダーに発注したタルクを例にとると、ベンダーの負荷状況を管理する必要はありませんが、期限に間に合う保証はないので、何らかの管理は必要です。管理するには事前に合意した期間見積りに基づくベースラインの存在が欠かせません。
事前の打ち合わせが足りず、作業が遅々として進まない状況下で担当者の口から「このタスクで私は何をやればいいのですか」という質問を耳にするのはショッキングです。
無理をして期間を短縮したタスクが実はさほど急ぐ必要がなかったということはよくあります。その逆に、急を要するタスクが後回しにされていることもよくあります。こんなことでは期限に間に合うはずありません。
［要件を満たすための詳細度］
さて、このような状況に陥らないためには、実行計画をどこまで詳細化すればいいでしょうか。
大雑把すぎるとタスク間の依存関係を記述することができません。なぜなら、大雑把に洗い出されたタスクの場合、タスクの途中に次のタスクへの連接点が発生してしまうからです。「前のタスクが半分終わったあたりで次のタスクを始めよう」
これでは依存関係が適切に記述されているとはいえません。
抜け落ちるタスクの代表格に「レビュー」や「レビュー結果の反映」があります。
レビューを担当する上位管理者がレビューに時間を割けるのは会議の合間などの限られた時間です。計画の段階でそれなりの期間を見込んでおかなければ遅れの原因になりますが、そもそも「レビュー」というタスクが洗い出されていなければ元も子もありません。
「レビュー」や「レビュー結果反映」に詳細度を合わせるとなると、その他のタスクもそれなりに詳細化する必要があります。
不慣れなリソースにタスクを任せるなら、タスクの内容、目的、完了基準などを予め合意しておくべきです。多忙を理由に端折ってはいけません。きちんと合意したいなら、タスクを適切に詳細化しておくべきです。
ひとつのタスクに何人ものリソースを割り当てる人がいますが、これはいただけません。役割分担や責任が曖昧になるからです。担当者どうしでお見合いが発生して、知らぬ間に遅延が発生してしまいます。ひとつのタスクにひとりのリソース、これを心がければタスクの詳細度は自ずと決まってきます。
適切に詳細化しておけば、クリティカルパスは自ずと浮かび上がってきます。
上記の観点から詳細化した実行計画の例がこちらです。
1 仕様検討
1-1 要求仕様を定める
1-1-1 要求仕様書や過去の議事録から要求事項を洗い出す
1-1-2 顧客からの要求事項を整理する
1-1-3 要求仕様を顧客と合意する
1-2 設計仕様書を作成する
1-2-1 要求仕様に対する実現方針を検討する
1-2-2 実現方針を設計仕様に落とし込む
1-2-3 設計仕様書を作成する
1-3 設計仕様と要求仕様の整合性を確認する
1-3-1 設計仕様と要求仕様の対照表を作成する
1-3-2 部内レビューを受ける
1-3-3 レビュー結果を反映する
1-3-4 再レビューを受け、設計仕様書を発行する
これはWBS（Work Breakdown Structure）と呼ばれます。
WBSを作成しようとして成果物のストラクチャーを書く人がいますが、これは間違いです。WBSはあくまで“作業”のストラクチャーです。成果物のストラクチャーとして書かれたWBSでは進捗管理に馴染みません。
今回はプロジェクトの実行計画を例にあげましたが、他の計画であっても詳細度を決める要領は同じです。
今回紹介した手順がすべての基本で、これは私が実践を通じて身に付けたものです。ぜひ試してみてください。やっていくうちに、皆さんなりの方法が見つかるかもしれません。
★★★ 概念化.com を立ち上げました ★★★
★★★ ぜひ、お立ち寄りください ★★★
