クリティカルチェーン・プロジェクトマネジメント（CCPM）解説

クリティカルチェーン・プロジェクトマネジメント（CCPM）は、最も希少なリソースを中心に計画を組み立て、タスクごとに余裕を個別に積み上げるのではなく、共有のタイムバッファーで計画を守るスケジューリング手法です。エリヤフ・ゴールドラットが開発し、1997年の著書「クリティカルチェーン」でプロジェクト業務への制約の理論（TOC）の応用として紹介しました。

ほとんどのプロジェクトが遅延するのは作業量の見積もりが甘いからではなく、各タスクの見積もりに隠された安全時間が学生症候群（スチューデントシンドローム）とパーキンソンの法則によって消費されてしまうためです。CCPMはその余裕を取り除き、少数の明示的なバッファーにまとめ、バッファーの消費率を真の早期警告システムとして機能させます。

クリティカルチェーン・プロジェクトマネジメントとは何か

クリティカルチェーン・プロジェクトマネジメントとは、タスクの依存関係とリソースの利用可能性の両方を考慮したうえで最も長い依存タスクの連鎖を特定し、プロジェクトバッファー、フィーディングバッファー、リソースバッファーという3種類のタイムバッファーで計画を保護するプロジェクトスケジューリング技法です。

「クリティカルチェーン」という表現は意図的なものです。タスクの依存関係のみに基づいて最長パスを求めるクリティカルパス法（CPM）とは異なり、クリティカルチェーンは作業を担うリソースも考慮します。従来のクリティカルパス上にないタスクでも、担当者がすでに別の作業で手いっぱいであればプロジェクトを遅延させる可能性があります。CCPMはその現実をスケジュールの最初から織り込みます。

中核的な概念：

• クリティカルチェーン： 依存関係とリソース制約の両方を考慮した最長のタスクシーケンス。プロジェクトの最短所要期間を決定します。
• プロジェクトバッファー（PB）： クリティカルチェーンの末尾に追加する時間的余裕。チェーン上のあらゆるタスクの遅延を吸収します。
• フィーディングバッファー（FB）： 非クリティカルなタスクシーケンスがクリティカルチェーンに合流する箇所に挿入する時間的余裕。上流の遅れからクリティカルチェーンを保護します。
• リソースバッファー（RB）： 時間的な余裕ではなく、警告の役割を持つもの。クリティカルチェーンで特定のリソースがまもなく必要になることをスケジュール上で知らせるフラグです。
• 学生症候群（スチューデントシンドローム）： タスクに締め切りの余裕があるため作業を後回しにする傾向。実際に作業が始まる前に安全時間が無駄になります。
• パーキンソンの法則： 作業は与えられた時間いっぱいに膨らむ。5日の余裕を与えると、実際の作業が3日分であっても5日かかります。

主要なデータ

Standish Groupの2023年CHAOSレポートによると、ソフトウェアプロジェクトのうち期日内かつ予算内で完了したのはわずか31%であり、AgileやCPMスケジューリングが広く普及した現在も20年前とほぼ変わっていません。

• 2017年に「International Journal of Project Management」誌に掲載された研究では、CCPM導入後の建設プロジェクト30件を対象に、スケジュール超過率が平均22%から5%未満に低下したことが示されています（Leach, 2017）。
• PMIの「Pulse of the Profession 2022」によると、組織はプロジェクトパフォーマンスの低下により投資額10億ドルあたり平均9700万ドルを損失しており、スケジュールの遅延がその主な要因です。
• ゴールドラットのオリジナルケーススタディでは、バッファー消費率が従来のアーンドバリュー指標よりも数週間早くプロジェクト完了リスクを予測できることが示されています（Goldratt, 1997）。

CCPMとクリティカルパス法の比較

どちらの手法もタスクの依存関係からプロジェクトスケジュールを構築しますが、解決する問題が異なります。CPMはリソースが無限にあると仮定してタスクの順序ロジックに集中します。CCPMはリソースに限界があると仮定し、リソースの競合をスケジュール上で事前に解決します。

リソース状況が整理されていてタスク内容が明確であれば、CPMが適切なツールです。CCPMはリソースが真の制約になっている場合、つまり複数のプロジェクトを同時進行させているほとんどの組織で効果を発揮します。CPMによるFloat計算やプロジェクト総所要期間の算出方法については、クリティカルパス法およびFloatとSlackをご参照ください。

CCPMにおけるバッファー

バッファーはCCPMの核心です。ただの余裕時間ではありません。明確な目的を持った管理されたリザーブ、すなわち不確実性を吸収して、その不確実性が納期ミスに連鎖しないようにするためのものです。

プロジェクトバッファーとフィーディングバッファーのサイズ設定には「50%ルール」がよく使われます。各タスクを50パーセンタイル（早くも遅くもなる確率がほぼ同等）で見積もり、その合計の半分をバッファーとします。統計的な集計を使う手法もあり、個々のタスク見積もりの標準偏差からバッファーサイズを算出します。

バッファー消費ゾーンがチームの対応を決定します。

• グリーン（0〜33%消費）： 順調。対応不要。
• イエロー（33〜66%消費）： 要注意。原因を調査し、加速オプションを検討する。
• レッド（66〜100%消費）： 即対応。プロジェクトが危機的状況。エスカレーションして介入する。

バッファー消費率はCCPMにおける主要なプロジェクト健全性指標です。Waterfallのマイルストーンチェックボックスに代わるものであり、完了率よりも正直な指標です。

CCPMのメリット

スコープを削減せずにスケジュールを短縮できる。 タスク見積もりから隠れた余裕を取り除き、共有バッファーとして集約することで、CCPMで策定したスケジュールは従来手法と比べて10〜25%短縮されることが多く、不確実性への備えは変わりません。

真のリスクを早期に可視化できる。 バッファー消費率は、従来の差異レポートよりもはるかに早い段階でプロジェクトの状況を示します。個々のタスクがダッシュボード上でグリーンを示していても、バッファーが線形を上回るペースで消費されているなら要注意のサインです。

マルチタスクによる損失を軽減できる。 CCPMは各リソースがクリティカルチェーンの一つのタスクを完了してから次に移るよう業務を順序付けます。コンテキストスイッチングはナレッジワークにおける最大の隠れたコストの一つです。これを削減することで速度と品質の両方が向上します。

一時に一つのプロジェクトを優先できる。 複数プロジェクトの環境では、CCPMのスタガードスケジューリング（ポートフォリオレベルでドラム・バッファー・ロープとも呼ばれる）によって、すべてのリソースを同時に複数のプロジェクトに分散させるのではなく、いつどのプロジェクトを優先するかを組織として合意しやすくなります。

技術だけでなく行動も変える。 CCPMはインセンティブ構造を変えます。タスクに個別の安全余裕がなければ、時間を抱え込む意味がありません。作業が早く終われば、すぐに次のタスクに渡されます。パーキンソンの法則による消費は起こりません。プロジェクトベースラインがより正直に維持されます。

限界と課題

文化的な抵抗は現実の問題です。 CCPMは積極的なタスク見積もりへのコミットメントと個人の安全余裕の放棄を求めます。特にタスクの見積もりを外すことがキャリアリスクになる組織では、これは受け入れがたい要求です。スケジューリングの仕組みよりも必要な文化変革の方が難しいことが多いです。

ソフトウェアのサポートが限られています。 標準的なプロジェクト管理ツールはCPM向けに作られています。動的なバッファー追跡とリソースを考慮したチェーン計算を含む適切なCCPMの実行には、専用ツール（Exepron、ProChainなど）か、大幅な手作業が必要です。

複数プロジェクトへの適用は複雑です。 単一プロジェクトのCCPMは管理可能ですが、共有リソースを持つ相互依存したプロジェクトポートフォリオ全体への拡張には、ほとんどのチームが専用のサポートなしには対応困難なスタガードスケジューリングが必要です。

反復的な作業には適していません。 CCPMはフルスコープが事前にわかっており、タスクをあらかじめ順序付けできる場合に最も効果を発揮します。次のタスクが現在のタスクを完了するまで定まらないAgile Sprint型や探索型の作業とは相性が悪いです。そうした状況では作業分解構成図とローリングウェーブプランニングの組み合わせがより適しているかもしれません。

積極的な見積もりが裏目に出ることがあります。 組織がバッファーシステムを実際に信頼せず、マネージャーが依然として個々のタスク見積もりで個人を評価するなら、チームは別のところに余裕を隠します。リーダーシップの本物のコミットメントなしには手法が機能しません。

クリティカルチェーン・プロジェクトマネジメントの導入方法

ステップ1：フルスコープとタスクリストを定義する

スケジューリングを始める前に、所要期間、依存関係、リソース要件を含む完全なタスクリストを作成します。プロジェクトスコープを分解するために作業分解構成図を使用してください。この段階でスコープが不完全だと、クリティカルチェーンの計算が制約を見落とします。

ステップ2：タスク所要期間を50%信頼水準で再見積もりする

各タスクの担当者に「どのくらいの期間があれば、期日通りに完了する確率がほぼ半々になりますか？」と問いかけます。これにより、人々が保守的な見積もりに自然に積み込む余裕が取り除かれます。所要期間が従来の見積もりより20〜50%短縮されることを見込んでください。安全時間がなくなるのではなく移動するだけだと説明し、バッファーシステムを理解してもらいましょう。

ステップ3：リソース競合を解消してクリティカルチェーンを見つける

CPMと同様に、タスクの依存関係を使って初期スケジュールを作成します。次にリソース競合、つまり同じ人物や設備が重複するタスクで必要になる箇所を特定します。優先度の低いタスクを後ろ倒しすることで競合を解消します。その結果として得られる、依存関係とリソース制約を考慮した最長シーケンスがクリティカルチェーンです。

ステップ4：プロジェクトバッファーとフィーディングバッファーを挿入する

クリティカルチェーンの末尾にプロジェクトバッファーを追加します。選択した方法（50%ルールまたは統計的手法）でバッファーサイズを設定します。クリティカルチェーンに合流するすべての非クリティカルシーケンスを特定し、各合流点にフィーディングバッファーを追加します。スケジュールからタスクごとの安全余裕をすべて取り除きます。安全時間はすべてバッファーに集約されます。

ステップ5：リソースバッファーを警告として配置する

クリティカルチェーン上の重要リソースが必要なタスクの前に、そのリソースがスケジュールの別の場所で作業を終えてからクリティカルチェーンに移る場合、リソースバッファーを配置します。これはそのリソースが必要になる1〜2日前に届く通知またはあらかじめ割り当てのフラグです。適切な担当者に参加依頼が届かなかったためにクリティカルチェーンのタスクが遅れ始めるという状況を防ぎます。

ステップ6：バッファー消費を追跡してプロジェクトを運営する

プロジェクトを開始します。タスクの完了を追跡し、スケジュールを日次または週次で更新します。プロジェクト経過時間に対するバッファー消費をグラフにします。グリーン・イエロー・レッドの消費ゾーンを使って対応を決定します。タスクが早く完了したら、その時間を即座に次に渡し、非クリティカルな作業で埋めないようにします。個々のタスクの完了率ではなく、バッファーの状態に焦点を当てた短い週次プロジェクトステータスレポートレビューを行います。

クリティカルチェーン・プロジェクトマネジメントの適用事例

以下の表は、CCPMがさまざまな業界でどのように適用されてきたかを示しています。

ベストプラクティス

行うべきこと：

• 最初からバッファーシステムへのコミットメントを固める。部分的な採用（タスクの余裕を残したままバッファーも追加する）はスケジュールを倍増させ、信頼性を失わせます。
• すべてのステータスミーティングでバッファー消費を追跡する。タスクごとのステータス更新の後ではなく、アジェンダの最初の指標として取り上げます。
• 作業が早く終わったら、その時間を前に渡すことを称える。「早く終わる」は「次のタスクを今すぐ始める手助けをする」という意味のチーム規範を作りましょう。
• チェーン計算への入力としてリソース割り当てとリソース平準化のデータを正確に用意する。
• スケジュールが固まってからではなく、プロジェクト計画プロセスの早い段階でCCPMを統合する。

避けるべきこと：

• 個人をタスク見積もりで評価しない。それはCCPMが排除しようとしている余裕の隠し込み行動を再び生み出します。
• 文化変革の会話をスキップしない。バッファーロジックを事前に明確に説明しなければ、CCPMは人々に短い締め切りへのコミットを迫る手口にしか見えません。
• スコープが未定義の高度に反復的または探索的な作業にCCPMを適用しない。タスクの全シーケンスを合理的に事前計画できるプロジェクトに使用してください。
• リソースバッファーを無視しない。省略可能に見えますが、よくある失敗パターン（リソースが別のタスクを終えてもクリティカルチェーンが自分を待っていると知らない）を防ぎます。
• フィーディングバッファーの消費を追跡しないままにしない。フィーディングバッファーがレッドに達することは、プロジェクトバッファーが急速に消費され始めるという早期シグナルです。

よくある質問

クリティカルチェーンとクリティカルパスの違いは何ですか？

クリティカルパスはリソースが無限にあると仮定した場合の、タスクロジックのみに基づく最長の依存タスクシーケンスです。クリティカルチェーンはリソース制約も考慮した最長シーケンスです。実際のプロジェクトでは、リソースの競合が一部のタスクを遅らせ、制約を考慮したシーケンスが純粋な依存関係分析より長くなったり、ルートが変わったりするため、クリティカルチェーンはクリティカルパスと異なることが多いです。

プロジェクトバッファーはどのくらいの大きさにすべきですか？

一般的な出発点は、50パーセンタイル見積もりでのクリティカルチェーンタスク所要期間の合計の50%です。たとえば、クリティカルチェーンのタスクが50%信頼水準の見積もりで合計40日であれば、プロジェクトバッファーは20日になります。より厳密なアプローチでは、個々のタスク不確実性見積もりの二乗平均平方根を使います。適切なサイズはプロジェクトのリスクプロファイルと組織のバッファー消費経験によって異なります。

CCPMはAgile手法と組み合わせられますか？

CCPMとAgileは異なる問題を解決します。Agileは反復的デリバリーによってスコープの不確実性に対処します。CCPMはバッファー管理によってスケジュールの不確実性に対処します。SprintのBacklogをミニプロジェクトとして扱い、Sprint Level のバッファーを設定するかたちでCCPMをSprintプランニング内に適用するチームもあります。ただし、完全なCCPMアプローチは既知のスコープとタスクシーケンスを前提とするため、意図的なスコープの柔軟性を持つAgileと根本的に相容れない面があります。

CCPMをサポートするツールは何がありますか？

専用ツールにはExepron（クラウドベース）、ProChain、LYNXがあります。Microsoft Projectはアドインまたは手動設定でCCPMに対応できます。小規模プロジェクトにはスプレッドシートベースのバッファー追跡も機能します。重要なのは、リソース競合が発生するたびに手動で再構築が必要なツールではなく、スケジュールの変化に応じてクリティカルチェーンを動的に再計算できるツールです。

CCPMと制約の理論はどのように関連していますか？

CCPMはゴールドラットの制約の理論をプロジェクトマネジメントに直接適用したものです。TOCはあらゆるシステムにはスループットを制限する主要な制約が一つあり、改善の努力はその制約に集中すべきだという考えを持ちます。プロジェクトにおける制約はクリティカルチェーン、つまりプロジェクトの最短所要期間を決定するリソースまたはタスクシーケンスです。CCPMはTOCの「5つのフォーカシングステップ」（特定、活用、従属、強化、繰り返し）をプロジェクトスケジュールに適用します。

---

プロジェクトが失敗するのは技術的な複雑さよりも、スケジュールに起因することの方が多いです。CCPMは作業を簡単にするものではありません。しかし、タスクレベルの余裕では決して実現できない方法で、時間的なプレッシャーを可視化し、共有し、管理可能にします。まず一つのプロジェクトで試し、バッファー消費を正直に測定してください。データが拡張する価値があるかどうかを教えてくれます。

関連記事

• クリティカルパス法 CCPMが基礎とする依存関係のみのスケジューリング手法
• FloatとSlack CCPMのバッファーが置き換えるスケジューリングの柔軟性
• 制約の理論 CCPMの背景にある親フレームワーク
• リソース割り当てとリソース平準化と平滑化 CCPMが顕在化するリソース競合への対処
• プロジェクト計画 CCPMのスケジューリングが始まる上流ステップ
• タスクの依存関係 クリティカルチェーンに入力される依存関係ロジックの理解
• Milestoneチャート バッファー消費と並行した主要チェックポイントの追跡