クリティカルチェーンプロジェクト管理

クリティカルチェーンプロジェクト管理（CCPM）は、プロジェクトタスクを実行するために必要なリソース（人、機器、物理的スペース）を重視したプロジェクトの計画と管理の方法です。^[1]これは、エリヤフ・M・ゴールドラット によって開発されました。これは、タスクの順序と厳格なスケジュールを重視するクリティカルパスとPERTアルゴリズムから派生した、より伝統的な方法とは異なります。クリティカルチェーンプロジェクトネットワークは、リソースを平準化するよう努め、開始時間に柔軟性があることを要求します。

クリティカルチェーンプロジェクト管理は、制約理論から派生した方法とアルゴリズムに基づいています。CCPMのアイデアは、1997年にエリヤフ・M・ゴールドラットの著書「クリティカルチェーン」で紹介されました。CCPMの適用により、1910年から1950年代に開発された従来の方法（CPM、PERT、ガントなど）よりも10％から50％速く、または安くプロジェクトを達成できるとされています。^[2]

1998 年時点のStandish Groupおよびその他による従来のプロジェクト管理手法の調査によると、通常、予定どおりに完了するプロジェクトは 44% に過ぎません。プロジェクトは通常、当初計画された期間の 222% 、当初予算の 189% で完了し、プロジェクトの 70% は計画された範囲(提供される技術的コンテンツ) に達せず、30% は完了前にキャンセルされます。^[3] CCPM は、これらの従来の統計と比較してパフォーマンスの向上を目指します。

従来のプロジェクト管理方法では、失われた時間とリソースの30％は、不適切なマルチタスク（特にタスクの切り替え）、学生症候群、パーキンソンの法則、受信トレイの遅延、優先順位付けの欠如などの無駄な手法によって消費されています。^[4]

プロジェクト計画において、クリティカル チェーンとは、限られたリソースがある場合にプロジェクトが短時間で完了するのを妨げる、優先順位とリソースの両方に依存するタスクのシーケンスです。リソースが常に無制限に利用できる場合、プロジェクトのクリティカル チェーンは、クリティカル パス メソッドと同一になります。

クリティカル チェーンは、クリティカル パス分析の代替手段です。クリティカル チェーンとクリティカル パスを区別する主な機能は次のとおりです。

1. (多くの場合は暗黙的な) リソース依存関係の使用。暗黙的とは、プロジェクト ネットワークには含まれず、リソース要件を確認して識別する必要があることを意味します。
2. 最適なソリューションの探索が不足している- 「十分に良い」ソリューションで十分である理由:
   1. 知られている限りでは、絶対的な最適値（つまり、全体的に最も短いクリティカル チェーンを持つ値）を見つけるための分析手法は存在しません。
   2. 推定値に内在する不確実性は、最適値とほぼ最適値（「十分に良い」ソリューション）の差よりもはるかに大きくなります。
3. バッファの識別と挿入:
   • プロジェクトバッファ
   • バッファの供給
   • リソースバッファー（企業は通常、より多くのリソースを提供することに消極的です）
4. スケジュールに対する個々のタスクのパフォーマンスではなく、バッファの消費率を監視することで、プロジェクトの進捗状況と健全性を監視します。

CCPM 計画では、プロジェクト内のタスクに追加された大量の安全時間をバッファーに集約して、期日のパフォーマンスを保護し、不適切なマルチタスク、学生症候群、パーキンソンの法則、不十分な同期統合によってこの安全時間が無駄になることを回避します。

クリティカル チェーン プロジェクト管理では、アーンド バリュー管理ではなくバッファー管理を使用してプロジェクトのパフォーマンスを評価します。一部のプロジェクト マネージャーは、アーンド バリュー管理手法は誤解を招くと感じています。これは、プロジェクトの制約 (つまり、クリティカル チェーン) の進行状況と非制約 (つまり、他のパス) の進行状況を区別していないためです。イベント チェーン方法論では、プロジェクトのサイズ、供給、およびリソース バッファーを決定できます。

プロジェクト計画または作業分解構造(WBS) は、クリティカル パスとほぼ同じ方法で作成されます。計画は完了日から逆算して作成され、各タスクは可能な限り遅く開始されます。

各タスクには期間が割り当てられます。一部のソフトウェア実装では、2 番目の期間が追加されます。1 つは「最善の推測」または 50% の確率の期間で、もう 1 つは「安全な」期間で、完了の確率が高くなります (組織が許容できるリスクの量に応じて、おそらく 90% または 95%)。その他のソフトウェア実装では、すべてのタスクの期間の見積もりを調べ、バッファーに集約される固定パーセンテージを削除します。

各タスクにリソースが割り当てられ、計画は積極的な期間を使用してリソース平準化されます。プロジェクトの最初から最後までのリソース平準化されたタスクの最長シーケンスは、クリティカルチェーンとして識別されます。50％の見積もりを使用する理由は、タスクの半分は早く終了し、残りの半分は遅く終了するため、プロジェクト全体の差異はゼロになるはずだからです。^[5]

パーキンソンの法則、学生症候群、またはその他の理由により、タスクは短時間で完了するよりも長時間かかる可能性が高いことを認識し、CCPM は「バッファー」を使用してプロジェクト スケジュールと財務実績を監視します。クリティカル チェーン上の各タスクの「余分な」期間 (「安全な」期間と 50% の期間の差) は、プロジェクトの最後にバッファーに集められます。同様に、バッファーはクリティカル チェーンに送られる各タスク シーケンスの最後に集められます。プロジェクト バッファーの終了日が、外部の関係者に納品日として提供されます。最後に、ベースラインが確立され、プロジェクトの財務監視が可能になります。

代替の期間見積り方法では、モンテ カルロ シミュレーションを使用して、期間の確率ベースの定量化を使用します。1999 年に、ある研究者^{[誰? ]}がシミュレーションを適用して、プロジェクトの作業分解構造の各コンポーネントに関連するリスクがプロジェクトの期間、コスト、パフォーマンスに与える影響を評価しました。モンテ カルロ シミュレーションを使用すると、プロジェクト マネージャーは、プロジェクト コンポーネントに影響を与えるさまざまなリスク要因に異なる確率を適用できます。発生確率は、発生確率 0% から 100% まで変化します。リスクの影響は、発生確率とともにシミュレーション モデルに入力されます。モンテ カルロ シミュレーションの反復回数は、許容誤差レベルによって異なり、プロジェクトの結果に対するリスクの影響の全体的な確率を示す密度グラフを提供します。

計画が完了し、プロジェクトを開始する準備が整うと、プロジェクト ネットワークは固定され、バッファーのサイズは「ロック」されます (つまり、プロジェクト中に計画期間を変更することはできません)。これは、バッファーがプロジェクトのスケジュールと財務実績を監視するために使用されるためです。

個々のタスクの期間に余裕がないため、リソースは目の前のタスクに集中してそれを完了し、次の人またはグループに引き継ぐように促されます。ここでの目的は、不適切なマルチタスクを排除することです。これは、すべてのリソースに優先順位情報を提供することで実現します。文献では、リレー レースとの類似点が示されています。プロジェクトの各要素は、できるだけ迅速に動くように促されます。プロジェクトの「区間」を走っているときは、気を散らしたりマルチタスクをしたりすることを最小限に抑えながら、割り当てられたタスクをできるだけ早く完了することに集中する必要があります。一部のケース スタディでは、重要な連鎖タスクに取り組んでいる人のデスクに実際のバトンが掛けられ、他の人が邪魔をしないようにしていると言われています。ここでの目標は、仕事を遅らせたり、時間があるように見えるときに余分な仕事をしたりする傾向を克服することです。CCPM の文献では、これを、タスクの開始日と完了日を監視する「従来の」プロジェクト管理と対比しています。CCPM では、日付に関係なく、できるだけ迅速に動くように促します。

タスクの期間は 50% の確率期間で計画されているため、学生症候群とパーキンソンの法則を克服して、クリティカル チェーン タスクをできるだけ早く完了するようにリソースにプレッシャーがかかります。

支持者によると、監視は、ある意味では、クリティカル チェーン方式の最大の利点です。個々のタスクの所要時間は 50% の見積もりから異なるため、すべてのタスクを「時間どおりに」完了させようとしても意味がありません。見積もりが完璧になることは決してありません。代わりに、計画段階で作成されたバッファーを監視します。バッファーの消費量をプロジェクトの完了の関数として示すために、フィーバー チャートまたは同様のグラフを作成して投稿できます。バッファーの消費率が低い場合、プロジェクトは目標どおりです。消費率が、プロジェクトの終了時にバッファーがほとんどまたはまったくなくなる可能性が高い場合は、損失を回復するための是正措置または回復計画を作成する必要があります。バッファーの消費率が、ある臨界値 (おおよそ、プロジェクトの終了前にバッファーがすべて消費され、完了が遅れる可能性がある割合) を超えた場合は、それらの代替計画を実施する必要があります。

臨界シーケンスは 1960 年代に初めて特定されました。^{[引用が必要]}

• 制約理論
• イベントチェーン手法

• プロジェクトマネジメント・イン・ザ・ファストレーン、ISBN 1-57444-195-7 
• クリティカルチェーンプロジェクトマネジメント、ISBN 1-58053-074-5 
• 短時間でプロジェクトを遂行: クリティカル チェーンの概要、Mark Woeppel 著
• クリティカル チェーンの実践: 制約理論を使用したプロジェクトとポートフォリオの管理、JPBernard および I.Icord 著、ISBN 978-2-35422-253-6 
• クリティカル チェーン プロジェクト管理の批判的考察、Tzvi Raz、Robert Barnes、Dov Dvir、Project Management Journal、2003 年 12 月。
• クリティカル チェーン プロジェクト管理の理論と実践 2018-08-17 にWayback Machineでアーカイブ、ロイ ストラットン、POMS 第 20 回年次会議、2009 年 5 月
• 「クリティカル チェーンの批判的考察」の批評的レビュー、スコット ボタン、EM 540 研究論文、2011 年 3 月

• 制約理論のオンライン ガイド - プロジェクト バッファリングとクリティカル チェーン バッファ管理の説明
• 制約理論: 研究データベース
• クリティカル チェーン プロジェクト - クリティカル チェーン専用の Web サイト
• クイズ - クリティカルチェーンに関する10問のクイズ