TOCとはTheory of Constraintの略で、70年代後半にイスラエルの物理学者エリヤフ・ゴールドラット氏によって提唱された理論です。
TOCでは、ビジネス全体のプロセスの中で、
- プロセスの「つながり」
- プロセスごとの能力の「ばらつき」
の2つに注目して、その中に存在する制約(ボトルネック)を見つけ出した上で、それを全体最適の観点から活用してビジネスプロセスにおけるスループット(売上 - 真の変動費)を高めることを目標にしています。
この記事では、TOC理論と、それに関連するプロジェクトマネジメント手法であるCCPMを解説していきます。
Contents
プロセスにおける制約(ボトルネック)
会社におけるビジネスプロセスは必ず部門同士・人同士が連動しています。その中で、各プロセスにおける能力が次のような場合にビジネス全体のアウトプットはいくらになるか考えてみます。

上記のような場合、プロセスの中で最小となる12が、このプロセス全体のアウトプットになるわけです。言い換えると、この12の能力しかないプロセスが制約(ボトルネック)となっているわけです。
もし、ここで20や18のプロセスに対して、改善を試みて、能力が22になったとしても、制約である12のプロセスが改善されない限りアウトプットは増えません。むしろ、プロセス全体としては、同じ能力なのに、20を22にするための改善コストや維持コストが余分にかかってしまうかもしれないのです。
このように連動したプロセスの中で能力の高低があるとき、
・プロセス全体のアウトプットは能力の低い側で決まる
・それ以外の改善は、ビジネス上は何もインパクトを生まず余分なコストだけがかかる
ということになります。
これだけ見ると、
「そんなの当たり前の話でしょ」
と思うかもしれませんが、
工場の生産プロセスや、実際のビジネスプロセスの中では、この制約(ボトルネック)をよくわからないままに、個別最適の改善に取り組んでいるケースがたくさんあるのです。
特に各部門・部署が縦割りになっていると、その部門・部署のパフォーマンスだけ注目されてしまいます。上の例でいうと、20や18のように制約になっていない部署が一生懸命改善を図っているのに、ビジネスプロセス全体としては何もよくなっていないという事態が起こるのです。
部署ごとの改善発表で、会社の業績改善に貢献していますというプレゼンを見るのですが、なぜか会社全体で見ると一向に業績改善していないケースがありますが、これこそ制約以外の改善を一生懸命やっている状況なのです。
繰り返しますが、TOCで教えてくれる大事なことは、
・プロセスの制約(ボトルネック)を改善すれば、プロセス全体のアウトプットは改善する
・制約(ボトルネック)以外のところを改善するのは時間の無駄になる
ということです。
TOCを適用するプロセス
TOCの考え方では次の5つのステップにしたがって、改善を図っていきます。
ステップ1.プロセスにおける制約(ボトルネック)を見つける
まずはプロセスにおける制約を発見するところからスタートです。先の例でいくと、能力が12のところです。
ステップ2.プロセスにおける制約(ボトルネック)を活用する方法を考える
次に考えるのは、制約を100%活用することです。制約となるプロセスといえども、実際は70%、80%の稼働率であるというのは、よくあることです。先の例だと、12の能力をプロセスが実際は8や9という状態です。まずはそれを100%の12にする改善を図ります。
例えば、ある会社の制約が図面を作成する人だとすると、図面を書く人は図面を書くことだけに集中してもらい、その他全ての雑多な業務から解放します。これが、制約を徹底活用することです。
ステップ3.制約(ボトルネック)となるプロセスに、その他のプロセス全てを従属させる
次に他のプロセスを制約に従わせることを考えます。制約が見つかるとすぐに改善を図りたくなるのですが、今の制約を徹底活用することを考えて、プロセスを制約に従属させることが重要なのです。
先の図面作成の例だと、図面を書く人以外の人が、その雑多な業務を助けてあげることで、図面を書く人がその価値を最大限会社に提供することができるようになります。これがその他のプロセスを従属させるということです。
ステップ4.制約(ボトルネック)の能力を高める
制約を100%活用して、かつ他のプロセスを制約に従属させて、初めて現在の制約の限界能力を知ることができます。そこから改善を図ります。
図面の例だと、図面を書く人を増やしたり、教育を施して時間当たりの図面枚数を増やしたりすることです。
ステップ5.惰性に注意して繰り返す
プロセスが連携していて、かつ能力にバラつきがある以上、ひとつの制約が改善されると、必ず他の制約が出てきます。最初の例だと、12の能力が16になったとすると、次は隣にある14が制約になるわけです。改善の手を緩めずに、1のステップに戻ることで、継続的な改善が可能になります。

マルチタスクの排除
制約を徹底活用する際に重要なことは、マルチタスクの排除です。人はマルチタスク状態で、様々な業務を行ったり来たりしていると効率は悪くなる傾向にあります。
例えば、資料10ページを作成しているときに、
資料1ページ作成 ⇒ 電話 ⇒資料2ページ作成
⇒ メール処理 ⇒資料1ページ作成 ⇒ 同僚から相談
などとやっていると、資料作成は遅々として進んでいきません。
しかし、資料を作る時間を決めて、10ページ作っている間、誰にも邪魔されずに一気に作り込むと、生産性高く短時間で作ることができるようになるわけです。これは感覚的にわかって頂けるのではないでしょうか。
上記、図面作成の例では、図面を書く人が図面を書く仕事以外はしないということにしましたが、まさにマルチタスクを排除して、一番大事なことに集中してもらうようにするわけです。
※仕事に悪影響が出ないレベルのマルチタスクであれば問題ないですが、ひとつひとつの業務を集中してできない状態になるマルチタスクは排除が必要です。
TOCで使うCRTとFRTという概念
TOCを活用する際に出てくる概念として、CRT(Current Reality Tree)とFRT(Future Reality Tree)があります。
CRTとは、現在の困りごとを洗い出して、それらの因果関係を整理するものです。ここで出てくる困りごとのことをUDE(ウーディー、Undesirable Effect)といいます。以下はCRTとUDEを簡易的に示した例です。
CRTの例

従業員から多くの困りごとを引き出すことで、より精緻なCRTを作成することができるようになりますが、こうして簡易的に可視化するだけでも、どこに根本があるのかが見えてくるようになります。
そして、CRTの作成だけに留まらず、FRTも作成していきます。FRTは近い将来こうなっていて欲しいという明るい未来を関係者で確認するために作成します。
FRTの例

この例だと、経営陣が情報を細部にわたって把握できないことで、多くの混乱が招いているので、経営陣が適切な情報を持ち、安心して意思決定できることが、問題解決に近づくことなのだと理解できます。
このときの手段は様々考えられますが、次に紹介するCCPMはその解決策のひとつになります。
CCPM(クリティカル・チェーン・プロジェクト・マネジメント)
TOCの考え方をプロジェクトのマネジメントに活用するために編み出されたのが、CCPM(クリティカル・チェーン・プロジェクト・マネジメントです。
よくあるプロジェクトのスケジューリングとして、個々のタスクでバッファーを見ながら、コミットした納期に遅れが出ないようにマネジメントするという方法があります。
よくあるスケジュールに引き方

しかし、このようにマネジメントすると、たとえ個々のタスクの早く仕事が終わっても、バッファーをあるだけ消費してしまい、後工程に渡すということが起きてしまいます。なぜなら、人間はバッファーがあればあるだけ使ってしまうものだからです。
「早く報告したら、別の仕事を振られる」
「早く完成させたら、次はその時間をベンチマークにされてしまう」
等々が頭をよぎってしまうからです。
実際に起きること

しかし、CCPMでは、個々のタスクにバッファーを見ずに、プロジェクト全体でバッファーを共有して、みんなで消費するという考え方をします。
CCPMでのバッファーの考え方

CCPMにおける工程表作成手順
CCPMでは、次の5つのステップで工程表をひいていきます。
選択と集中、目標すり合わせ、段取り、サバ取り、バッファー管理
ステップ1.選択と集中
先にもあげたようにマルチタスクは、生産性の阻害要因になるので、極力排除する必要があります。まずは、プロジェクト数を適切な数にまで絞り込んで、メンバー全員が集中して仕事をできる環境を作る必要があります。
ステップ2.目標すり合わせ
プロジェクトメンバー全員が何を目的にプロジェクト実行をするのか、何のために工程表をひくのかという認識を一致させます。認識を一致させるのは、プロジェクトメンバーが目的不明瞭のままプロジェクトを進めると、必ず細かい工程で無駄が生まれてくるからです。
その目標をすり合わせるためのフレームワークとして、次の3つの要素を含んだODSCを提唱しています。
O:Objective(目的)
プロジェクトを何のために実行するのか、完成することでどのようなよいことを起こそうとしているのです。
D:Deliverable(成果物)
プロジェクトによって生み出されるものです。例えば、サービスの導入を目的としたプロジェクトなら、サービスそのものですし、それに伴うサービス開発のプロセスも成果物になり得ます。
SC:Success Criteria(成功基準)
プロジェクトが成功したと言える基準です。例えば、サービスの導入なら、納期通りできることが基準のひとつですし、上記にあげたプロセスが付随する成果物なら、以降のサービス開発で新たなプロセスが導入されるというのも基準になります。また、担当したプロジェクトマネージャーが独り立ちできるなども成功基準になり得ます。
ステップ3.段取り
CCPMでは、ゴールから遡って工程表を引いていきます。
そのときに、以下3つの質問をすることで、後工程に移れる前提条件となる前工程を正確に特定することができるようになります。
・この工程の前にやることは何ですか?
・〇〇したら××できるのですね?
・本当にそれだけですか?

この3つの質問をしながら、参加者全員で工程表を作っていくと、ベテランの思考プロセスを若手が追体験でき、若手の育成にもつながるのです。また、他部署のスケジュールに対する考え方や懸念なども、ここで全て洗い出すことができます。
それぞれのタスクは「〇〇する」という動詞形で記載していきます。
ステップ4.サバ取り(可能な限りアグレッシブに)
先にも書いたように、人間はバッファーがあればあるだけ使ってしまう生き物です。したがって、個々の工程からはサバを取り去って、50%の確率でできるリードタイムを入れていきます。
そして、できあがった工程表から、最も長く工数のかかるクリティカルチェーンを特定します。そして、今度はそのクリティカルチェーンに集中して、納期を短くする方法を考えます。その際の質問は以下の5つです。
・短くするうまい方法はないですか?
・タスクを並行でやれることはないですか?
・段取りを見直すことで、短くすることはできませんか?
・経営幹部から助けてもらうことで、短くする方法はありませんか?
・本当に五分五分ですか?
従来型のスケジュールの作り方だと、期間を短縮するとなると、関連部署同士の対立が起こることがあります。しかし、関連部署全員でODSCを明確にして工程表を作ると、工程表を目標どおりにするために、どうすれば目標を達成できるか、みんなが知恵を絞るようになります。つまり、プロジェクトスタート前から協力体制ができるようになるわけです。
最後にバッファーができたら、そのバッファーをざっくり半分にします。なぜなら、各工程の五分五分の確率で期間どおりに完成できるので、バッファーもざっくり50%で見ておけばよいという考え方です。
バッファーは最後にまとめる

ステップ5.バッファー管理
CCPMの工程表が完成し、プロジェクトが実行に移されたら、バッファー消費量を管理しながら、マネジメントします。以下がその例です。
バッファーマネジメント表

バッファーマネジメント表 運用例

このように進捗率に対するバッファー消費量で管理すると、誰が見てもプロジェクトの状態が一目瞭然になります。
これなら経営陣も安心できて、先のCRTで出した問題が、FRTで記したような、よい循環に変わっていきます。
また、個々のタスク管理では、プロジェクトマネージャーが率先して、以下の質問を現場の担当者にしていく必要があります。
・あと何日かかりますか?
(×どれくらいできた?)
・問題があるとしたら何ですか?
(×なぜ問題が起きたのか?)
・問題がありそうなら、何か助けられることはないですか?
(×何とか挽回しろ!)
決して、怖い顔をして「何で遅れたのか?」とか、「何とか挽回しろ」などと言ってはいけません。問題が起こる前に先手管理をしていくことが大事なのです。
CCPMのメリット
CCPMを活用すると、以下のようなメリットがあります。
- 各担当者は50%の確率のスケジュールを納期として必死に頑張る(担当者は共有バッファーを使うことが悪だと感じる)
- 関係部署がプロジェクトゴールに向けて協力できる(部署間対立を減らせる)
- 経営陣に対してプロジェクトの状態を可視化できる(経営陣に細かいことを聞かなくても安心してもらえる)
- 遅れリスクに対して、必要に応じて経営陣まで巻き込んで先手でマネジメントできる
なお、CCPMでは、プロジェクトゴールから工程を引いていくので、途中まで進んでしまったプロジェクトでも適用可能です。
まとめ
ここれまで書いたことをまとめると、TOCの概念を適用して可能になることは次のようなことでした。
- 制約(ボトルネック)となるプロセスを見つけて、その改善に集中できる
- CRTやFRTを作ることで、経営上の課題が明確になる
- CCPMを使うことで、部署間対立を減らせ、経営陣に対してプロジェクト進捗を可視化でき、担当者が各自の持ち分を必死に頑張ってもらうことができる。
「課題がたくさんあって、どれから手をつけてよいかわからない」
「課題解決のためのリソースが足りない」
というときは、TOCの原理に従って問題解決することをおすすめします。
TOCをもっと知りたい方にはコミック版がおすすめ
CCPMをもっと知りたい方は
その他の問題解決手法

