Chapter 6

第6章: CCPM ── プロジェクトに持ち込んだTOC

あなたはIT プロジェクトのマネジャー。

工程表は完璧。20 個のタスク、各タスクに「余裕を持って」見積もりをもらった。全部足すと、プロジェクトは6 ヶ月で完了するはず。

ところが3 ヶ月経って蓋を開けると、半分のタスクが遅れている。不思議なのは、前倒しで終わったタスクは一つもない こと。ばらつきがあるなら、早く終わるタスクもあって、相殺されるはずなのに。

なぜいつも、プロジェクトは予定より遅れるのか? 早く終わったタスクはどこへ消えた?

ゴールドラットは1997 年、続編『クリティカル・チェーン』で TOC をプロジェクト管理に適用した。これが CCPM (Critical Chain Project Management)。製造業以外で TOC が最初に大きく根を張った領域だ。

6.1 プロジェクトはなぜ遅れるのか

CCPM の出発点は、「プロジェクトはなぜ毎回遅れるのか」という現場の素朴な疑問だった。ゴールドラットは3 つの心理現象を指摘する。

学生症候群 (Student Syndrome)

学生時代、レポートの提出日が2 週間後に決まる。最初の10 日は何もしない。残り 3〜4 日でようやく取り掛かり、最後の日は徹夜になる。

職場でも全く同じことが起きる:

図 6.1 — 学生症候群。タスクの大部分が締切直前に集中する。前倒しの余裕は使い切られる。

「余裕がある期間に他のことをしてしまう」のは人間心理の鉄則。プロジェクトに見積もられた余裕は、前倒しで終わるためではなく、後ろにずらすため に使われる。

パーキンソンの法則 (Parkinson’s Law)

「仕事は与えられた時間を全部使うまで膨らむ」── これがパーキンソンの法則。

10 日見積もったタスクは、5 日で終わりそうでも10 日かけて納品される。追加機能を入れる、手戻りで磨き直す、関係者に念入りに説明する。早く終わっても「早く終わりました!」と報告しない。理由は:

早く終わると「見積もりが甘かったのでは」と疑われる
次回から余裕を削られる
待機中だと別タスクを振られる

これらは個人の合理的選択であり、組織のインセンティブ設計の結果だ。

マルチタスクの罠

人は複数プロジェクトを並行で持つと、全部が遅くなる。これは経験則だが、認知科学的にも実証されている。

図 6.2 — シングルタスク vs マルチタスク。並列にこなすと「全部が遅い」が成立する。さらに切り替えコストでトータルも長くなる。

タスクを切り替えるたびに コンテキストスイッチコスト が発生する（人間の場合、再度集中するのに平均20 分以上かかると言われる）。3 プロジェクト並列 = 3 倍遅いではなく、4〜5 倍遅い が実感に近い。

6.2 個別セーフティの集約 ── CCPM の中核アイデア

ゴールドラットの解決策は驚くほどシンプルだ。

各タスクから「個人が抱える安全余裕」を全部剥がして、プロジェクト全体の最後に1 つの巨大なバッファとして集約する。

これがクリティカルチェーンの中核発想。個別の余裕は浪費されるが、集約された余裕は実際の遅延吸収に使える。

通常のスケジューリングとの違い

伝統的なクリティカルパス法（CPM）では、各タスクに 安全余裕付き で見積もりを設定する。

タスクA (中央値 5 日 + 余裕 5 日 = 見積もり 10 日)
タスクB (中央値 5 日 + 余裕 5 日 = 見積もり 10 日)
タスクC (中央値 5 日 + 余裕 5 日 = 見積もり 10 日)
...
合計: 100 日

CCPM はこれを変える:

タスクA (中央値 5 日)
タスクB (中央値 5 日)
タスクC (中央値 5 日)
...
タスク本体合計: 50 日
+ プロジェクトバッファ (集約セーフティ): 25 日
合計: 75 日

個別のセーフティを足すと 50 日だが、集約すると 25 日で十分 になる。理由は統計だ。すべてのタスクが同時に最悪値を引く確率は極めて低い。個別余裕の合計（50 日）の半分くらいを集約バッファとして持てば、プロジェクト全体は十分安全になる。

これは 大数の法則 と 中心極限定理 から導かれる。N 個の独立なばらつきは、合計するとばらつきが $\sqrt{N}$ 倍にしか増えない。だから合計を保護するには、各セーフティの合計より遥かに小さいバッファで足りる。

6.3 クリティカルチェーン vs クリティカルパス

伝統的な CPM（Critical Path Method）は タスクの依存関係だけ から最長パスを求める。

CCPM が加える要素: リソース制約。「同じ人が同時に2 つのタスクをこなせない」という当たり前の制約を、CPM は無視しがちだった。

図 6.3 — クリティカルチェーンの定義: 依存とリソース競合を両方含めた最長パス。CPM とは別物。

クリティカルパスは 依存だけ の最長経路。クリティカルチェーンは 依存 + リソース競合 の最長経路。多くの現実プロジェクトでは、両者は別物になる。

6.4 バッファの3 種類

CCPM では3 種類のバッファを使う:

図 6.4 — CCPM の3種類のバッファ。プロジェクトバッファ、フィーディングバッファ、リソースバッファ。

バッファ	場所	役割
プロジェクトバッファ (PB)	クリティカルチェーンの末尾	プロジェクト全体の遅延を吸収
フィーディングバッファ (FB)	非クリティカルパスから合流する地点の手前	サブパスの遅延がCCに伝染するのを防ぐ
リソースバッファ (RB)	クリティカルチェーン上の担当者切り替え地点	「次は山田さんの番」を早めに伝えてリソース欠勤を防ぐ

バッファ運用は DBR と同じ3 色

CCPM のバッファマネジメントは DBR と全く同じ発想だ:

バッファ消費	色	アクション
0〜33%	GREEN	何もしない
33〜67%	YELLOW	注視、対策検討
67〜100%	RED	即座に介入

これは「プロジェクト全体の遅延を、1 個の指標で見られる」点が決定的に強い。複数のタスクの遅延状況を別々に追う必要がない。

6.5 リレー走者の規律 ── 早く終わったら早く渡す

CCPM が現場に求める文化の変化は2 つ。

1. リレー走者になる

タスクを担当する人は リレー走者 のように振る舞う必要がある:

自分の番が来たら、即座に着手する
早く終わったら、即座に次の人に渡す（遅らせない）
マルチタスクは禁止（バトンを離さない）

「いつもより早く終わりました」は 称賛されるべき結果 であり、「見積もりが甘かった」と批判されない文化が必須。

2. 個人の見積もりではなく、集団の保険で動く

「自分のタスクの安全余裕」を所有する文化から、「プロジェクト全体のバッファを皆で守る」文化へ。

これは思想転換だ。マネジメントは「あなたのタスクの遅延を許容する」のではなく、「プロジェクトバッファの消費を許容する」と言わなければならない。

これは口で言うほど簡単じゃない。人事評価が個人タスクの完了率で決まる組織では、絶対にこの転換は起きない。 CCPM 導入の本当の難しさは、ガントチャートでもバッファ計算でもなく、評価制度 にある。

6.6 マルチプロジェクト環境への展開

複数プロジェクトが走る組織で CCPM を運用するときは ドラム を別の意味で導入する。

マルチプロジェクト CCPM では、最も逼迫したリソース（戦略リソース） を1 つ選び、それがすべてのプロジェクトの「ドラム」となる。

つまり戦略リソースの可用性に合わせて、プロジェクトを 時間軸でずらして 投入する。 2 つのプロジェクトが同時にこのリソースを必要としないように、組織レベルで投入を調節。

これは DBR の発想を組織全体に拡張したものだ。「全プロジェクトを同時に並行で動かせ」という発想を捨て、「戦略リソースの容量に合わせて、プロジェクト投入をシーケンス化」する。

結果として、各プロジェクトのリードタイムは大幅に短縮される。

6.7 CCPM の実績と限界

CCPM は1997 年以降、製造、IT、建設、医薬品開発、軍などで広く適用された。

領域	効果（典型値）
製造工程	リードタイム 30〜50% 短縮
IT プロジェクト	納期遵守率 50% → 90%+
R&D（医薬品）	開発期間 25% 短縮（事例: ハネウェル等）
軍事プロジェクト	米空軍の整備で大幅短縮

ただし限界もある:

限界	内容
評価制度の壁	個人タスク評価が残る組織では失敗
見積もりの中央値化	文化的に「サバを読む」習慣が抜けない
アジャイル時代との相性	全体計画ベースなので、頻繁なスコープ変更には弱い
ツール固有のロックイン	専用ソフトに依存する事例が多い

第8章で実際の数字を見るが、CCPM は「成功すれば劇的、失敗すると元に戻る」が他の TOC 手法より顕著だ。

6.8 第6章の振り返り

プロジェクトが遅れるのは 学生症候群・パーキンソン・マルチタスク の3 大心理現象
個別のセーフティは消費される。集約すれば総量で半分 で済む
クリティカルチェーン = 依存 + リソース競合の最長パス
バッファは3 種類: プロジェクト・フィーディング・リソース
3 色（GREEN/YELLOW/RED）で運用が単純
文化転換が決定的: リレー走者の規律、早く終わったら即受け渡し
評価制度を変えないと CCPM は形骸化する

この章で読めるようになるニュース

「○○プロジェクトが計画より3 ヶ月前倒し」── CCPM 的な集約バッファ運用の効果として読める
「マルチプロジェクト体制の見直し」── 戦略リソースをドラムに置く発想として理解できる
「アジャイル + クリティカルチェーン」── 2 つの手法の相性を判断できる

次の第7章では、TOC のもう一つの横展開 ── 思考プロセス (TP)。工場やプロジェクト以外の、ありとあらゆる問題に TOC の発想を適用する論理ツール群を見る。