（１）クリティカルパスからクリティカルチェーンへ
（２）クリティカルチェーンプロジェクト管理の概要
（３）プロジェクトバッファと合流バッファを挿入
（４）最小の労力で最大の進捗管理効果を生むバッファ管理
（１）クリティカルパスからクリティカルチェーンへ
従来のPERT法のクリティカルパスでは、プロジェクトに使われる資源の競合といった動的な条件を考慮していません。資源の競合があり、かつ、資源は一度に１つの作業しかできないという条件を考慮した一連の作業工程が、プロジェクトの本当の制約条件になるのです。これをTOCプロジェクトマネジメントではクリティカルチェーンと呼びます。
つまり、クリティカルチェーンとは、プロジェクトのクリティカルパス上の要素と制約資源を使用する工程（制約工程）の組み合せを通るパスということになります。
（２）クリティカルチェーンプロジェクト管理の概要
従来のPERT法では、個別のタスクごとに開始日・終了日を設定していますので、タスクの担当者はタスクの納期を厳守することが要求されています。これらのタスクの中に安全余裕が含まれているわけです。個別のクリティカルパス上のタスク納期を守ることで、クリティカルパス全体の納期を守るという論理です。
クリティカルチェーン法では、下図のように、プロジェクト管理者はクリティカルパス上のタスク担当者の時間見積から安全余裕で見込む時間を抜き出し、クリティカルチェーンの最後にプロジェクトバッファーとして集めて集中管理しています。また、非クリティカルチェーンの枝パスにも合流バッファーを同様に設定します。
タスク担当者はシングルタスクで作業を行い、タスクの掛け持ち（マルチタスク）は行ないません。タスク担当者は前工程のタスクが終了すれば直ちに自分のタスクを開始し、終れば直ちに後工程の担当者へまわします。プロジェクト管理者は個々のタスク担当者の繁忙は管理しませんし、個々のタスク担当者へは担当するタスクの開始日・終了日（タスク納期）や作業期間を知らせません。
クリティカルチェーン法での日程計画（スケジューリング）では、タスク担当者の見積時間は50%の納期遵守確率で完了するとみなしています。したがって、プロジェクト管理者が見込んだ終了予定日（タスク納期）より遅れる確率が50%あることになります。クリティカルチェーン上のタスク遅延日数をプロジェクトバッファー（クリティカルチェーン全体の安全余裕期間）から差し引いていき、プロジェクト管理者はこの残り日数だけを注意していればよいことになります。プロジェクトバッファーが１日でも残っていれば、プロジェクト全体の納期が守れるという論理です。
（３）プロジェクトバッファと合流バッファを挿入
①プロジェクトバッファ Project Buffer
プロジェクトバッファは、クリティカルチェーンの最後に置かれます。その目的は、クリティカルチェーン上の遅れからプロジェクト納期を守ることにあります。 プロジェクトバッファの長さ（時間）については、米国での経験値として、クリティカルチェーン全体の時間の25%が目安として使われています。つまり、下図に示すように、各タスク（工程）の時間を悲観的（現実的）に見積り、その50%を安全余裕時間としてプロジェクトバッファに集め、それを半分にする訳です。理論上は、各タスクから2/3の安全余裕時間をプロジェクトバッファに集めることが可能です。当然、各タスクの見積り時間は半分になっています。
ＴＯＰへ戻る
②合流バッファ Feeding Buffer
合流バッファは、非クリティカルチェーン（枝パス）の遅れでクリティカルチェーンが遅れることを防ぐためのバッファです。枝パスのクリティカルチェーンへの合流点に設置します。合流バッファの長さ（時間）も、プロジェクトバッファと同様に計算します。
（４）最小の労力で最大の進捗管理効果を生むバッファ管理
ゴールドラット博士の書いた小説「クリティカルチェーン」の中では、バッファとして上記のプロジェクトバッファと合流バッファが紹介されています。プロジェクトの実施段階では、プロジェクト管理者はクリティカルチェーン上のタスク（クリティカルタスク）の担当者と毎朝５分間の顔を付き合わせてのミーティングを行い、「プロジェクトバッファの残量管理」と「合流バッファの残量管理」を行うことが求められます。
クリティカルチェーン法では、これらの２つのバッファの残量管理とともに、「リソースバッファ管理」と「ボトルネックバッファ管理」を行います。詳細につきましては藤川（fujikawa@cea.jp）までお問い合わせください。肝心な部分については、ゴールドラット博士も情報公開はしていないようです。
ＴＯＰへ戻る