詳しい説明は

@IT情報マネジメント
WBS：http://www.atmarkit.co.jp/aig/04biz/wbs.html
PERT： http://www.atmarkit.co.jp/aig/04biz/pert.html

をお読み下さい。

WBSの最初のステップとして、目標を達成するのに必要な成果物を洗い出し、それらを更に細かい項目へと分割するところから始めます。
この部分はGTDの考え方と似ていますね。

その後のステップはGTDと少し異なりますが、このWBS、ＰＥＲＴのマネジメント手法もなかなか面白いので、その考え方について簡単に説明したいと思います。

WBS（ＰＥＲＴ）では一つの仕事を終わらせる為に必要なプロジェクトを洗い出し、それをアクションレベルのタスクまで小さく分解し、各タスクを処理するために必要な時間、リソースを割り振ります。
そして各タスクの主従関係を矢線で結び、全体として必要な時間とリソース量を可視化するというものです。

簡単ですが、そのイメージを書いた物が以下の工程表です。 このサンプルでは、この仕事を終わらせるために必要なプロジェクトを三つ挙げ、それをさらに細かいタスクに分割しています。

WBS（ＰＥＲＴ）では、このネットワーク図を見ながら、この仕事を完了させるのに必要なクリティカルパスを割り出します。
クリティカルパスとは、全体の工程の中で、このタスク、プロジェクトに遅れが生じると、全体の工程にまで影響を及ぼすというギリギリの工程を言います。

例えば、この工程表のプロジェクト1のタスク２、タスク３の作業工程に遅れが生じても全体の工程には影響しませんが、プロジェクト２（タスク1）~プロジェクト３（タスク３）までのどれかに送れが生じると全体の工程にまで影響を及ぼすというタスクの流れのことです。

工程管理を行う際は、このクリティカルパスを意識し、ここに遅れが生じないよう人員と時間を割くことで、全体の工程に遅れが出ない様に工程管理を行います。

考え方はシンプルで、それを実行させるためのシステム（ソフト）があるにも関わらず、実はこのマネジメントシステムを上手く使いこなす事が出来ませんでした。

この工程表を見ると、プロジェクト1とプロジェクト２の一部が重なっているので、そこには最低でも二人の人員を割り当て作業の重複を避ける必要があります。

たとえば、こんな感じですね。

ここでは、プロジェクト１をMoyori、プロジェクト２をMogtaがそれぞれ担当することで、作業の重複を避けるようにしています。

しかし、実際はこんな感じ

人員不足と、上限を抑えられた外注費率により、結局全ての作業を自分で行う事になる事が殆どでした。
私が二人居れば問題ないのですがそうも行かないので、この様な状況になった場合は

Moyori(一人目)： 9：00 ～17：00
Moyori（二人目)：17：00～24：00

と、一人二交代制で働かざるを得ないという状況でした(涙目)
タスクがもう一つ増えると、

Moyori（三人目)： 24：00～9：00

と、一人三交替制になることもしばしば。。。(涙目)

工程を管理しているようで、結局出来ないことへの無力感から、そのうち真面目に作るのをやめてしまったというのが実際のところです。

しかし、この工程表を作成するのは、全体の工程を把握し、作業項目、検討項目の抜けが無いかを把握するのには非常に有効な方法だと思います。

私が使っていたのはMicrosoft Projectというソフトでしたが、Projectと完全データ互換を持つフリーのソフト（OpenProj ）などもありますので、興味のある方は一度試してみてはいかがでしょうか。