プロジェクト・マネジメントでよく使われるWBS（ワーク・ブレイクダウン・ストラクチャ）の書き方を解説した本。

…なのだけど、非常に大味で内容の薄い本だった。もともとあまり分量のない本なのだけど、書かれている中身はもっと少なかった。特に全体の1/3は原著とは直接関係ない日本人コンサルタントへのインタビュー記事とQ&Aと大して役に立たない実例集だった。

WBSとは要するにツリー型のToDoリスト（やらなきゃいけないこと一覧表）のことだ。一番上に最終目的を配置し、その目的を達成するための副目的をその下に複数個置いていく。さらにその副目的を実現するための副々目的を…と階層的に目的をブレイクダウン（噛み砕く）していく。そうすることで、どこからとっかかりをつければいいのか分からなかった大きな目標に対して作業の道程をつけることができる。WBSを元にガントチャートみたいなスケジュール表を作り、進捗管理（どこまで終わったか）することができる。

「100%ルール」とは、副目的をすべて達成したら自動的にその上の目的を達成したことにならなければならないという網羅性を言っている。言われてみれば当たり前のことなのだけど、意外と見落としがちなことなので改めて強調されていてなるほどと思った。もしこの「100%ルール」が守られていないのならば、やらなければならない作業が見落とされているということだ。

目的はやろうと思えばどんな形にも分割できるけれど、あくまで基本的にはまず成果物ごとに分けるのが正しいらしい。工業製品だったら部品ごと。イベントだったら会場設営とか料理とかそういったもの。まあどうしてもプロセス（段取り）ごとになってしまう場合もある。プロジェクトの性質による。設計と製造みたいなものはWBSを二つに分けるのがいいそうだ。

「ワーク名は名詞と形容詞だけで名づけること（動詞は使わない）」というのは、まあ別にどうでもいいじゃんという気もするけれど、シンプルに名づけておかないと長ったらしくなって把握しづらい。末端のワークの下に実際の具体的な作業をアクティビティリストとして挙げるのだけど、逆にそちらは「○○を△△する」といった動詞入りの呼称をつけるのだそうだ。

ワークは部分的な依存とか独立性がないように分割する。そうじゃないとワークを分割しきれていないということだ。もちろんワークを無意味に分割しすぎるのもいけない。ワークは大体80時間程度にするのが望ましいのだそうだ。大体二週間。週に一回の進捗会議を二回経れば終わるぐらいの粒度にすべきらしい。うーん。言っていることは分かるのだけど、これでは大きくてゆったりしたプロジェクトしか管理できなくなってしまう。まあ元々この手のプロジェクト・マネジメントなんて米軍とかアメリカの大企業が大プロジェクトに使うために開発されたものだから、ちまちました短納期のプロジェクトに適用するのはそもそも無理があるのかもしれない。

レベル2（最終目的のすぐ下）に必ず「プロジェクト・マネジメント」というワークを用意すべしと言っている。ここにプロジェクト開始前後の作業や途中の調整なんかを入れる。これが各所に分散されてしまうと分かりにくくなる。

複数のプロジェクトを管理する場合についても言及されていて、プロジェクトを一まとめにしてプログラムと呼んでいる。なんだかコンピュータのプログラムを連想してしまうけれど、イベントのプログラムなんかのイメージなんだろうな。プログラムはレベル0の場所に置き、プログラムマネジメントをレベル1つまり個々のプロジェクトと同列に置く。なぜプロジェクトの集まりをわざわざプログラムとして管理したほうがいいのかというと、プロジェクトを動的（ダイナミック）に組み上げたり修正したりする必要があるからだ。

世の中には経営工学など効率的な方法や段取りについて研究する分野があり、この本もそういうような分野の研究者が書いたものだ。読む人が読めば必要十分なことが書かれた本なのかもしれない。中身がないだの無駄が多いだの素人がケチをつけるのは筋違いなのだろうか。でもやはりこの本の体裁からすれば普通の読者が読むように出版された本にしか思えない。あげく、原著者の名前を出しておきながらそれとは全然関係のないインタビュー記事やらQ&Aやらを詰め込んでまとめたのは卑怯ではないか。