PM Tools A to Z

PM Tools A to Z
No.35
クリティカル・チェーン（４）
2005.12.28
KT
今回はクリティカル・リソース（ボトルネックとなるリソース）を考慮したパスであるク
リティカル・チェーンの考え方と、リソース競合が起ったときのプロジェクトのスケジュ
ーリング方法について説明します。
１．クリティカル・チェーンとは
あるリソース（人的資源）がクリティカル・パス上のアクティビティと非クリティカ
ル・パス上のアクティビティにアサインされている場合、クリティカル・パスをキー
プするためにクリティカル・パス上のアクティビティを最優先に実施すると、アサイ
ンされている非クリティカル・パス上のアクティビティの方が遅れてしまい、それら
が在るパスが新たにクリティカル・パスになってしまう危険があります。
前回までの説明では、リソースの制約を考慮しないままプロジェクトのボトルネック
としてクリティカル・パスを挙げてきましたが、実際にはリソースの制約を考慮した
スケジューリングが必要になります。
具体的には、各リソースは一度に一つのアクティビティしか実行できないという制約
の下で見出された新たな最長パスが、プロジェクトの真のボトルネックになります。
このパスのことを TOC によるプロジェクトマネジメント手法ではクリティカル・チェ
ーンと呼んでいます。
２．クリティカル・チェーンによるプロジェクトのスケジューリング
それでは、クリティカル・チェーンの考え方に沿って、プロジェクトのスケジューリ
ングの方法を図で例示しましょう
（１）図１において、リソース R の担当するアクティビティが R1∼R6 とします。
横方向を時間軸とします。
リソース R には、R3 と R5 のアクティビティが同時にアサインされています。
また、R2、R4、R6 も同時にアサインされています。
（２）TOC によるプロジェクトマネジメント手法では、一度に一つのアクティビティしか
実行しないので、これらのリソース競合を避けるには図２のようにスケジュールを
組み直して、リソース競合を解消する必要があります。
このように再スケジューリングすると、クリティカル・パスで計画したスケジュー
ルよりもプロジェクトが延伸してしまいますが、リソース競合がある場合にはやむ
を得ません。
（３）次に図２で合流バッファーの位置を見てみましょう。
前回説明したとおり、合流バッファーとはクリティカル・パスに合流するパスの遅
れによって、クリティカル・パスそのものが遅れてしまうことを防ぐために、その
Copyright© 2005 Technosurge Co., Ltd. All Rights Reserved
合流点に設けられたバッファー（安全余裕）のことです。
したがって、図２で置かれている合流バッファーの位置を修正して、図３のように
クリティカル・チェーンに合流するパスに合流バッファーを設定するようにします。
これで、クリティカル・チェーンの考え方によって、リソース競合がある場合のプ
ロジェクト・スケジュールが作成できました。
図１ リソース競合有り
R1
R2
R3
R4
R5
FB
R6
クリティカル・パス
FB
R1~R6： 同一リソース担当アクティビティ
FB： 合流バッファー
PB： プロジェクト・バッファー
FB
PB
FB
（スケジュール延伸）
図２ リソース競合解消
R1
R2
R3
FB
R4
PB
R5
FB
R6
図３ FB位置修正
R4
クリティカル・チェーン
FB
FB
FB
R3
FB
R1
R2
PB
FB
R5
FB
R6
参考文献：１．クリティカル・チェーン
エリヤフ・ゴールドラット著
２．TOC クリティカル・チェーン革命
稲垣公夫著
ダイヤモンド社
JMAM
＜end＞
Copyright© 2005 Technosurge Co., Ltd. All Rights Reserved