今までプロジェクト管理に関し、色々な人がいろいろなことを言ってきたけれど、プロジェクト管理理論について僕の考えることがある程度曖昧ながら固まってきていることもあり、この場を使って書いてみたい。
今日、トピックとして挙げたいことは、WBSに関することだ。WBSは、Work Breakdown Structureの略で、定訳は見かけたことはなく、日本語の文章でもWBSと、そのまま書くことが多い。意味としては、プロジェクト目的を達成するために、作業項目を詳細に分割し、MECEに構成された作業体系を指す。敢えて訳すとすれば、プロジェクト作業体系とでもいえるだろうか。でも、通例に従い、WBSで通すことにする。
プロジェクトは大抵、達成できるかどうかが不明確だ。不慣れな新しい技術を使うこともあるだろうし、今まで会ったことも無かった人間と協調してアクティビティをすすめていくというコミュニケーションの問題もある。どんなプロジェクトも不確定の要素を抱えている。不確定要素は、すぐにコストに跳ね返る。企業戦略論で有名なバーニーは、先行者と二番手が同等の事業を興す際のコストの差について指摘しているが、そこで挙げられた数字は、二番手は先行者の60％のコストで済むというものだ。先行者と二番手の戦略間のコストの比率は、不確定要素のコストと読むことができる。これだけで不確定性のコストを云々するつもりは無いが、プロジェクトはゴーイングコンサーン型の業務と比べ、明らかにコスト劣位であることが分かるだろう。
そこで、WBSは、プロジェクトの不確定要素を削減する手段として用いられる。少なくとも作業漏れや、無駄な重複に関してはWBSを使うことで削減できる。逆に、MECEに構成されないと格段にプロジェクトリスクが増す。プロジェクトには資源に制約があるし、期限が決っているから、作業項目に無駄な重複があると作業自体が無駄だし、リソース不足の原因となるだけでなく、作業者のストレスの大きな原因となる。また、作業漏れがあると、プロジェクト目的が達成されないのだから、作業漏れは、大きなリスクである。とはいえ、プロジェクトの作業を洗い出すということは、かなり難しい作業であることはすぐにわかるだろう。
WBSは、プロジェクトの作業を洗い出すという意味では、トップダウンのアプローチでやっていくことが多い。しかし、このトップダウンのプロジェクト分割のアプローチが問題だ。
まず、プロジェクトをマイルストンごとに分けるというアプローチをとることがある。マイルストンというのは、疎なコミュニケーションを管理する手法であり、基本的にはプロジェクトチームと、プロジェクト外のコミュニケーションに用いるべきものだ。
例えば、プロジェクトの中間目標として経営会議に報告するタイミングで、これだけのプロジェクトの実績や成果をあげておく必要があるだとか、ベンダーの切り替えのタイミングで、これだけの作業はしてもらわなくては後続のベンダに外注できない、だとかというようなタイミングを意味する。プロジェクトを期間で分割し、サブプロジェクトを構成するような手法である。
マイルストンによる分割という手法には問題点があることを認識しておいたほうがよい。マイルストンで実績と計画の間の同期を取っていくために、先行のサブプロジェクトが優秀で予定期限前に作業を終えたとしても、後続のサブプロジェクトに余裕を与えることができないからだ。すると、結局最後のマイルストンと最終プロジェクト期限の間にリスクが集中することとなってしまうからだ。
とはいえ、企業間をまたぐようなプロジェクトなどでは、マイルストンを用いてコミュニケーションをせざるをえないことが多い。オフショアでの開発などでは特に、きっちりした成果物をマイルストンごとに作成して、後続を担当するチームに引き渡す必要があるからだ。
逆に、マイルストンを用いてコミュニケーションをしなくて済むのなら、プロジェクトのリスクとしては格段に低くなる。最終プロジェクト期限のリスクが、プロジェクト期間全体に分散されるためだ。これは、順序だてて考えればあたりまえのことなのだけれど、意外と認識されていないことでもある。
（続く）
