来週の「オペレーション入門」に合わせてTOCの調査を行っていますが、だんだんTOCの本質が理解できてきました。
従来までのTOCに対する不信感が払拭されてきたような気がします。

結局は早い話「システムを構成する一番のボトルネックに合わせたPDCA活動」なんだね。と。
つまり、「制約条件がシステムのパフォーマンスを決定しているならば、その制約部分に重点をおいて、継続的に改善をしてゆこう」ってのがTOCの本質なんですね。

つまり、クリティカルチェーンも、クリティカルパスを探すのも目的や解決方法ではなく、継続的に続けられる改善活動の一つの手段。
うーん、これが理解できると、相当TOCに対する印象が変わります。

従来の漠然とした、PDCA活動よりも、「制約条件≒システムのパフォーマンスを決定する要素」にフォーカスした具体的な改善活動と、その制約条件を発見するための思考プロセス、ツール群、評価方法。
これらが三位一体になったものがTOCなんですね。

こりゃ、調べてみて大正解だったなぁ。
相当よく練られた理論かもね。

と同時に、プロセスに関しては補完的なものの必要性が理解できます。
つまり、ソフトウェア開発であれば、反復型開発＋TOCというのが効果的な感じ。
RUP+TOCでも全然OK。
XP+TOCは少し難しいかもしれないけど。

ちなみに今回は参考文献として、こんな本も買ってみました。

エリヤフ・ゴールドラットの「制約理論」がわかる本


値段が600円と、この類の書籍としては破格の値段です。
そして内容が実に分かりやすい。
TOC初心者には最適かも。

Critical ChainやCCPMを学ぶ前にますは「TOCの本質」を本書できちんと抑えないと、「何をやっているのか」が分からずに、失敗するんでしょうなぁ。