CCPM理論編：優秀なチームでも失敗？原因は「ボトルネック」！CCPM基礎のTOCを学ぶ
Back to Top
はじめに
#「優秀なメンバーで計画通りに進めているはずなのに、なぜかプロジェクトが遅延し、時には失敗してしまう…」
多くのプロジェクトで、このような経験はないでしょうか？
その根本的な原因は、目に見えにくい 「ボトルネック（制約）」 にあるのかもしれません。
この「制約」に注目した手法が、 CCPM（Critical Chain Project Management） です。
CCPMは導入実績がまだ少なく、あまり知られていないかもしれませんが、私自身の経験からも、非常に実践的で効果的な手法だと実感しています。
ある顧客は、「CCPMに加えて、他のフレームワークも理解しているPMだと安心できる」と話していました。
それだけ、CCPMはまだ珍しく見られる一方で、きちんと理解している人には信頼感があるのです。
PMBOK、Scrum、ITIL、CMMI、A-SPICEなど、プロジェクトマネジメントには多様なフレームワークやガイドがあります。
こうした多様な手法がある中で、なぜCCPMが注目に値するのか？
その理由や背景について、これからわかりやすく解説していきます。
CCPMは、TOC（制約理論）を基盤にしたプロジェクトマネジメント手法です。
TOCが「制約に集中して全体最適を目指す」アプローチであるのに対し、CCPMはそれをプロジェクトのスケジュール管理に応用しています。
今回はその前提となるTOC、特にプロジェクトの成否を分ける 「制約」 の考え方についてお話ししていきます。
TOCとは
#Theory of Constraints（制約理論）の略で、全体最適を実現するために、制約に集中してマネジメントすることで解決策を導く理論体系です。
組織全体の「つながり」と「ばらつき」を考えると、どこかに必ず制約が見つかります。
制約に集中し、解消することが全体最適となります。
さらに、集中することで、短期間に結果を出すことができるのです。
引用元： TOC CLUB JAPAN「TOCとは」
この説明だけでは「制約」や「つながり」「ばらつき」「全体最適」といったキーワードが少し分かりにくいと思いますので、具体例を用いて説明していきます。
クイズ：車両生産工場の例
#
上図は、簡易的に車両生産工場の製造工程をイメージしたものです。
- 五角形の矢羽根が1つの工程を表し、左から右に向かって工程が進みます
- 下から上に向かって工程が合流します
- 矢羽根の左下にある赤丸の数字は、その工程が1日に車両1台分の部品を何台分製造できるかを表す「生産能力」です
それでは、クイズです！
「検査」は1日あたり車両8台分の処理能力があり、「タイヤ製造」は車両9台分のタイヤを製造可能です。
この工場で1日に完成車として製造できる車両台数は何台でしょうか？
解答と解説
#
正解は、 4台 です。
理由は、「エンジン製造」が1日に4台分しか製造できず、ここが ボトルネック つまり 制約 となっているからです。
たとえ前工程で7台分の部品が用意できたとしても、エンジンが4台分しかなければ、それ以上は完成させることができません。
TOCではこのような工程を「制約（Constraint）」と呼び、制約が全体の処理能力を決定します。
一連の「つながり」はTOC用語で「依存的事象（Dependent Events）」と呼ばれます。
TOCにおける制約の特徴
#このように単純な工程構成で、各工程の処理能力が明確な場合は、制約の特定は比較的容易です。
しかし、実際の現場ではこうした単純な状況ばかりではありません。
そこで、制約を特定するためには制約の特徴を理解することが重要です。
- 制約の特徴
- 在庫が積まれている
- 後工程が待たされている
- 処理に時間がかかる
TOCの全体最適５ステップ
#TOCでは、制約を中心に改善を進めるための「5ステップ」が提唱されています。
これはあらゆる業種・業務に応用可能です。
- 制約を特定する
- 全体の成果を最も制限している要因＝制約を特定する
- 例）処理が極端に遅い機械や担当者
- 制約を徹底活用する
- 制約が今ある状態で最大限活躍できるよう工夫する
- 例）稼働率の向上、重要タスクの優先割り当て
- その他すべてを制約に従わせる
- 全体最適のために、他の工程は制約のペースに合わせる
- 例）遅い工程に合わせて仕掛品を減らす
- 制約の能力を高める
- 投資や改革で制約そのものの能力を引き上げる
- 例）新設備導入、外注など
- 次の制約を探す
- 制約が解消されたら、次の制約を特定し、改善を継続する
たとえば、「エンジン製造」の能力を強化して1日6台分作れるようになると…
次の制約は「内装部品組み付け」（1日5台分）になります。
ソフトウェア開発業務への応用
#私の主なコンサルティング対象であるソフトウェア開発においても、TOCは非常に有効です。
上図は、顧客が機能を要求し、それが実装されて利用可能になるまでの流れを簡易的に示したものです。
ソフトウェア開発業務では、以下のような変動要素があります。
- 要求される機能内容と数は都度異なる
- 同じ人が実施するわけではない
「その時々で変わる要素」はTOCでは「統計的変動（Statistical Fluctuation）」と呼ばれます。
ソフトウェア開発業務の制約特定
#ソフトウェア開発でも、TOCの制約の特徴を応用することで ボトルネック を見つけることが可能です。
- ソフトウェア開発業務における「制約の特徴」
- タスクやチケットが積みあがっている
- 後工程が前工程の成果物待ちで停滞している
- 入力から出力までのスループットが悪い
制約を特定できれば、TOCの原則に従って対処するだけです。
まとめ
#- システムには制約がある
- 「つながり」と「ばらつき」があると、必ず制約が存在する
- システム全体の処理能力は制約によって決まる
- 一部の要素が全体の処理能力を制限している
- 制約に集中することが全体最適につながる
- 制約と非制約を明確に区別し、制約に集中することで成果が上がる
- 非制約には、あえて「何もしない」勇気も必要です（※これが難しい）
- 非制約の強化は、むしろ制約の在庫を増やすなど悪化につながる可能性がある
次回は「CCPM実践編」として、今回学んだTOCの考え方をベースに、具体的なCCPMのプロジェクト計画（スケジュール作成やバッファ設計）について解説します。
どうぞご期待ください。
