クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか？

シリーズは全部読んでいるけれど、自分自身が抱えている問題とか課題とかに一番近い分野を扱ったのが本書だろう。とはいっても「ゴール」にしても、「思考プロセス」にしても、役に立たなかったかというと、そういうわけではなく、過去３作はすべて、何らかの形で仕事には役立っている。
「ゴール」を読んでからTOC理論には興味を覚え、その関連の本もいくつか漁っている。先にプロジェクトマネイジメント系の本で、クリティカルチェーンなどについては触れていたので、今回は「おさらい」という感じではあったが、それでも面白くて一気に読めた。


今回は、プロジェクトマネイジメントを扱っているわけだが、プロジェクトマネイジメントという世界においても、TOC理論を下敷きにして、今まで常識と思われていた事柄にメスを入れていく。

各プロジェクトのステップで、セーフティを入れているにも関わらず、いつの間にかセーフティを食いつぶし、毎度のように遅れてしまうプロジェクト。天候の原因や、下請け業者が納期を守らなかったなど、さまざまな予測不能な要因が絡まってプロジェクトの遅れは「常識」のように思われてしまう。しかし、精緻に見ていけば、そこには気づいてみれば、あまりにも単純な数々の「おかしい」考え方や、プロセスが横たわっている。

各ステップで作業が早く終わっても、それが平均化されることがなく、結果的にプロジェクトは一連の最も時間のかかるパスの遅れに、すべての遅れが集約されてしまうということ。各ステップにセーフティを置いても、それが学生症候群などでセーフティにならないこと。


ゴールドラットは、プロジェクトでは、クリティカルパスのみにセーフティを置き、クリティカルパスの完了期日のみを管理することを提唱する。クリティカルパスを中心に置き、クリティカルパスに合流するパスにもセーフティを置く（合流バッファ）。非クリティカルパスから生じる遅れからクリティカルパスを守るためだ。１つのプロジェクトを見た場合は、これだけで、各ステップにセーフティを置いていたときより、プロジェクトはよりスムースに進む。

ただし、普通、会社にはいくつものプロジェクトが動いていて、リソースの掛け持ちが行われている。ここでは個々のプロジェクトではなく、すべてのプロジェクトを１つのプロジェクトと見なし、最も長いステップを考える必要がある（クリティカルチェーン）。そしてリソース競合などを起こしているところの業務順位を明確にし、可能な限り個々の業務を同時に動くのではなく、従属関係に配置する。
この場合は、クリティカルパスではなく、クリティカルチェーンを遅らせないようにすることが、全体のスループットの向上になる。

と、まとめてみても、（まとまってないけど）こんな知識はたいしたものではない。


このシリーズの特色はなんといっても、小説形式を採用していることだ。理論的に説明されれば、それはそれで知識として得ることはたやすくなる。
しかし、このシリーズでは、あえて小説という形式を採用し、登場人物達が悩み、仮説をたて、検証していく様を描く。
ストーリーを追うことで、読み手も、そういった思考のプロセスそのものに浸り、単純な言葉や概念の理解ではなく、自分自身の課題や仕事へはどのように応用できるのだろうか？ということを、自然と考えさせられる仕組みを提供しているのだ。