どんな本か？

『ザ・ゴール』で一躍有名になった、エリヤフ・M・ゴールドラット（Dr. Eliyahu M. Goldratt）博士による『制約理論（TOC：Theory Of Constraints）』を、プロジェクト・マネジメントに応用した、『クリティカルチェーン 〜 なぜ、プロジェクトは予定どおりに進まないのか?』という本がある。『ザ・ゴール』と同様の物語形式のセオリー本だ。

この本を種本として、TOCのプロジェクト管理手法『クリティカル・チェーン』を解説したのが、本書、『最速で開発し最短で納めるプロジェクト・マネジメント』TOCの管理手法”クリティカル・チェーン”』になる。

著者の村上 悟氏はTOCをベースにコンサルティングを行うゴール・システム・コンサルティング株式会社の代表取締役で、共著者の井川 伸治氏も（株）日本能率協会マネジメントセンターTOC推進センターのコンサルタントを行っている。ともに、TOCのプロフェッショナルの方々だ。

目次

第一章：進化する革新手法TOC
〜 プロジェクト管理必須のTOC・DBR理論

第二章：従来型管理技法の考え方と問題点
〜 PERT理論とクリティカル・パス

第三章：遅れを絶対に出さないプロジェクト管理
〜 リソースを最大に活かすクリティカル・チェーン

第四章：夢を「かたち」に変えるスケジュール
〜 開発部門のプロジェクト管理に挑むー物語編

そもそも、TOCとは何か?

まず、制約理論（TOC：Theory Of Constraints）は、工場の生産性向上を目指したもので、本文中では以下のように解説している。

（P.32〜）「制約条件」を強化して収益を最大化するTOC

1980年代前半、イスラエル出身の物理学者エリヤフ・ゴールドラット博士は、「工場の生産性は、ボトルネック行程（生産能力が最も低い工程）の能力以上には絶対に向上しない」という一見当たり前の原理を提唱します。

工場の生産性を上げるためには、他の生産工程や資材調達をボトルネック工程の生産スピードに合わせるべきという主張です。

これを実践した工場で実際に生産性が飛躍的に高まり、仕掛かりや在庫が劇的に減少したことから、ゴールドラット博士の考えは、TOC=制約条件の理論として普及していったのです。

『最速で開発し最短で納めるプロジェクト・マネジメント』より

TOCの理論を説明するために、よく比喩として利用されるのが、鉄の輪が連なった鎖のイメージだ。

（P.34〜）鎖を切れにくくするには、もっとも弱い輪を探してそれを強化する

TOCの特徴は、「制約条件」こそが、企業のアウトプット（利益）を増やすカギと位置づけていることです。

工場の全行程、あるいは全社を挙げて、さまざまな改善活動に取り組む従来の革新活動との最大の違いは、ここにあるのです。

企業の活動全体もしくはサプライチェーン全体を一本の鎖に例えることができます。

この場合、受注、原材料入手、生産、納入、請求、入金という最終的に金が企業に入ってくるまでの個々の活動は、鎖の輪の一つひとつに相当し、企業やサプライチェーン全体の収益力は、鎖全体の強度としてとらえられます。

鎖の輪の中に一つだけ弱いものがあれば、鎖全体の強度はその弱い輪の強度と等しくなります。

鎖を切れにくくするには、最も弱い輪を探してそれを強化すれば良く、それ以外の輪の強度を高めても鎖の強度は増しません。

これと同様に、企業やサプライチェーンの生み出す利益も、最も能力の低い活動の制約を受けるのです。利益を増やすには、最も能力の低い活動を強化すべきで、それ以外の活動をいくら強化しても利益には貢献しません。

『最速で開発し最短で納めるプロジェクト・マネジメント』より

TOCをプロジェクト・マネジメントに応用したクリティカル・チェーンとは？

TOCでは鎖の最も強度の弱い部分（制約）に着目したが、プロジェクトに当てはめると、その”弱い部分”とは何当たるだろうか？

それは、『クリティカル・パスと、それを実行する人的リソース』である、というのが、クリティカル・チェーン^[01]の根底の考え方だ。

プロジェクトは、複数のタスクが連なったプロセスであることから、そのタスクのつながりをチェーンと見立て、その中でもプロジェクトスケジュールにダイレクトに影響する、クリティカル・パスのチェーンのことを、『クリティカル・チェーン』と呼び着目する。

クリティカル・パスもやはりタスクのつながりだが、このパス上のタスクが一つでも遅延したらプロジェクト全体の遅延になるわけで、クリティカル・パス上の個々のタスクにバッファーをもうけて、個別に最適化しても意味がない。むしろ個別な余裕は、学生がレポートを書くのを提出期限ぎりぎりまで延ばしてしまうような、『学生症候群』に陥る可能性が高い。

そこでクリティカル・チェーンの考え方では、個々のタスクから余分なバッファーを取り去り（50%の確率で完了するレベルまで余裕をそぎ取る）、プロジェクトの最後に『プロジェクト・バッファー』を設ける。各クリティカル・パス上タスクの遅延は、このプロジェクト・バッファーを削ることで一元管理する。

クリティカル・パスに途中合流するタスクのチェーンは、遅れがひどくなると、このチェーンにクリティカル・パスの『移動』が起きる。そこで、これを阻止するために、クリティカル・パスに合流するチェーンの最後には合流バッファーを用意して、これもまたクリティカル・パスと同様に管理する。

もう一つ、クリティカル・チェーンの重要な考え方は、人的リソースの重なりを省く、ということだ。当然クリティカル・パス上のタスクを実施する人的リソースが最も重要であるため、この人的リソースがクリティカル・パス上のタスクを行う際に、他のタスクと被らないように、スケジュールを調整する。

これらのプロセスが、従来のクリティカル・パス法を拡張した、クリティカル・チェーンの考え方だ。

この概念を図にして分かりやすく解説したものが、ゴール・システム・コンサルティング株式会社のクリティカル・チェーンの説明ページにある。

実際のシステム開発プロジェクトに適用してみた

さて実は一度、このクリティカル・チェーンによるプロジェクト・マネジメントを、自分がプロジェクト・マネージャーであった案件に適用したことがある。

８人で１０ヶ月程のごく小規模プロジェクトだったが、プロジェクト・バッファーを１ヶ月用意し、バッファー消化状況をウォッチしていった。結局その１ヶ月のプロジェクト・バッファーは、ほぼ使い切って予定通りにカットオーバーした。なかなか有効なマネジメントスタイルだ、と感心した。なにしろ、プロジェクト全体のリスク状況をシンプルに定量化してトラックできるのだ（各フェーズやタスクでなく、プロジェクト全体であるというのがポイント）。

しかし、このプロジェクト以後、クリティカル・チェーン手法を他のプロジェクトに適用することができていない。特に大きくリスクが高いプロジェクトであればあるほど、適用から遠ざかってしまう。そういうプロジェクトこそ、より効果的なマネジメントを行いたいにもかかわらず。

それはなぜかというと、大規模なシステム開発プロジェクトになればなるほど、クリティカル・パスがきれいに見えるほど正確なWBSを引くことが難しくなるからだ。

クリティカル・チェーンをシステム開発プロジェクトに適用するための注意点

『WBSが引けない。』これは、システム開発プロジェクトの典型的な問題なのではないか？いや、正しくは『大企業の業務サポートのための社内システムを、SIerとして構築するプロジェクト』と定義した方がいい。よく、『システム開発』という言葉ひとくくりで、SIerの業務システム開発も、パッケージソフトウェアの自社開発も、WEBベンチャーのサービス開発もごちゃ混ぜに語られることがあるが、これらは全く別物だ。そして、この中でもSIerによる業務システム開発に、WBSが引けないプロジェクトが最も多いのではないかと思う。

なぜ、WBSが引けないのかということの詳細は別途考えたいところだが、たいていの場合、『既存と外部』というのが問題の根幹に存在する。

既存業務がある・既存ユーザーがいる・既存システムがある → 要件定義の調整が爆発する。既存データがある → 移行やIFの定義に難航する。既存システムがある → テスト実行の調整が困難だ。

開発フェーズ以外の、要件定義〜設計とテストフェーズのWBSを引くときに、あまりにも外部要因に引っ張られる。そのため、WBSを引こうにもタスクと見積もり、担当者が日に日にくるくる変わるので、クリティカル・パスを利用できる精度に追いつかない。これが良くあるパターンではないか？

実は、上記のクリティカル・チェーンが適用できたプロジェクトは、

• 短期の小規模プロジェクトで、
• 自分たちが作ったシステムのフレームワーク刷新プロジェクトであり、
• 移行データとテストは全て自分たちの中で完結していて
• 人的リソースが継続しているので生産性が把握しやすかった（見積もりが立てやすい）

という条件がそろっていたからだ。このレベルになると、さすがにWBSをキチンと引くことができ、クリティカル・パスを把握できる。

クリティカル・チェーンをお題目にした本の弱点はここにある。要は、『WBSがキチンと引けて、クリティカル・パスが分かるのは当たり前』という前提からスタートしていることだ。

本の中では、『各タスクの完了確率を50%から90%に上げるためには3倍の工数がかかる』というポイントに注目して、50%の完了確率でWBSを引き、バッファーを後ろにまとめる、ということを最重要としているが、そもそも、タスクがフェーズの中でどんどん洗い出され、その見積もりのぶれ幅がとんでもなく大きい、といった場合、この方法は全く役に立たない。

本書でも、本書以外のクリティカル・チェーンの説明書でも、システム開発プロジェクトへの応用が説明されているが、実際そこで指しているシステム開発プロジェクトとは、自社パッケージソフトウェア開発のことを指している。確かに、担当者がフェーズ毎・タスク毎に明確に別れていて、自社ソフトウェア製品を作っていく、というのは工場とのアナロジーも多く、適用しやすいのも分かる。

とはいえ、この本が使えないわけでは全くなくて、『クリティカル・チェーン』という目新しい概念を、理屈で理解するためには、なかなか良くできた参考書といえる。

元ネタの本『クリティカル・チェーン』とあわせて読む副読本として最適だろう。同様の狙いの本で、よりわかりやすく説明しているのが、『目標を突破する実践プロジェクトマネジメント』という本だ。カジュアルにクリティカル・チェーンを理解したいというニーズにはうってつけである。

ただ、繰り返しになるが、SIerによる業務システム開発プロジェクトに適用する場合、まず、クリティカル・パスが引けるほど確固としたWBSが引けるだろうか？ということを考える必要がある。

SIerによる業務システム開発プロジェクトのWBS構築とクリティカル・パスの把握、そしてクリティカル・チェーンの定量的管理のノウハウ（具体的なツール、レポートのたぐいも含め）が網羅された詳細説明書が欲しいところだ。そのようなクリティカル・チェーンプロジェクトの事例がはたしてあるのだろうか？

1. @ITによるクリティカルチェーンの説明がわかりやすい。 [戻る]