「The Haystack Syndrome」の第3部は、一般の方は原書で読むしかありません。私は幸いにして日本語訳の原稿が手元にあります。 が、結構難解なんです。日本語で読んでも。難解さの大きな理由は、 スケジューリングの複雑さ、というよりは、生産ラインの複雑さから来ているのではないか、と思います。
ＤＢＲのスケジューリングでタイムバッファーが大きな役割を演じます。タイムバッファーには、ＣＣＲ（ボトルネックとほぼ同意味）バッファー、 組立バッファー。出荷バッファーの3種類あります。タイムバッファーの大きさは、工程を流れるスピードで決められます。 早く流れればタイムバッファーは短くてよい。で、ボトルネック工程が遊ばないようにスケジューリングするわけです。
スケジューリングの手順は、5ステップ。
ステップ１；システムの制約条件を見つける
ステップ２；制約条件を徹底活用する
ステップ3；制約条件以外のすべてを制約条件に従属させる
ステップ4；制約条件の能力を高める
ステップ5；制約条件が解消されたら、最初のステップに戻る
ＴＯＣの本によく出てきますね。このステップを一巡しても収束しないときは、何回か繰返すんです。必ず収束してスケジュールが完成するか、、、 なんですが、少々あやしいんですよ。収束しないときがあるんです。 そのときは、最後に、人間の手で、「えいっ！ やっ！」で英断を下す、、と書いてあります。
例えば、タイムバッファーですが、製品ミックスや負荷状態で流れるスピードが変わります。タイムバッファーを長く取ればボトルネックの手空きの確率は減りますが、 リードタイムが長くなり、競争力が低下します。だから、タイムバッファーは最適点を探して設定するわけですが、工程を流れるスピードが変動しますので、 最適点だと思っていた点が狂っちゃうわけです。ほんで、ダイナミック・タイムバッファーとかいう考え方を持ち出すんですよ。 タイムバッファーが短くてよいときは短くして、長いタイムバッファーでないとダメなときは長くする。
いつタイムバッファーが短くてよいか、長くしなければならないか、そんなことは神のみぞ知る、でしょ。さらに、タイムバッファーの長さを変えたら、スケジューリングをやり直す、ってことです。 この考え方は、さすがに非現実的でありまして、そのうち創始者もいわなくなりましたが、、。
こんなのもあります。ボトルネック工程が2つ、近いところにあるときです。ボトルネックは1つしかない、とＴＯＣは主張しているのですが、現実はそうはいかない。 バラツキがあるとボトルネックの能力もある範囲で変動します。その範囲が重なる工程は、不規則にボトルネック状態になります。いつどっちの工程がボトルネック状態になるか、 これも神のみぞ知る。これだとスケジューリングのしようがないわけで、しょうがないから、両方をボトルネックとして扱うことになるわけです。そうすると、 どちらのボトルネックも手空きがないようにスケジューリングしなければならないわけで、そのときタイムバッファーの長さをどうするかが問題となります。 ボトルネックとボトルネックの位置が近いときなどは、干渉を防ぐために、その間に「時間のつっかい棒（Time rod）」を入れなさい、って書いてあります。
また、タイムバッファーは3種類ですが、ひとつの種類のタイムバッファーが複数あることも珍しくありませんので、これだけでも、スケジュールは複雑になります。
という具合で、ＤＢＲのスケジューリングは複雑で、難解なんです。当時、ＤＢＲ対応ソフトだという触込みで、10種類以上のソフトが発表されていましたが、 どれもＤＢＲもどきだったんじゃないかと思います。つまり、原理的にＤＢＲのスケジューリングは、ごく簡単な生産ラインでしかできないんです。
ここで、学ぶべき重要なことはなにか、といえば、ＴＯＣの始まりは、より具体的にいえば、ＤＢＲの始まりは、スケジューリング方法の開発であった、ということなんです。 これは、「ザ・ゴール」の巻末にある創始者の解説をみてもわかります。抜粋すると、
「工場を経営している知人から、いかに生産スケジューリングを工夫してもうなくいかないという相談を受けた」
「ついに画期的な生産スケジューリング方法とそのスケジューリング・ソフト『ＯＰＴ』を開発した」
「ＯＰＴ」は、当時の工場で、目覚しい成果を上げたのは事実でしょう。それは比較的簡単な生産ラインでのことだったんじゃないかと思うんです。 その後、適用範囲を広げるうちに、スケジューリングがどんどん複雑になってきた。そして、苦労してつくったスケジューリングが3日もしないうちに、 生産予定の変更で、スケジューリングのやり直しなんてなことになる。こうなったら、やってられませんね。
実行可能なスケジューリングを目指したＤＢＲですが、それがあやしくなってくれば、存在理由もなくなってくるわけです。
これを受けて登場するのがＳ－ＤＢＲ。ＳはSimplifiedのＳ。簡単だったはずのＤＢＲは、結局、複雑になりすぎてダメになったので、 今度こそはシンプルだ、ということなんでしょうか。
名が示すとおり、Ｓ－ＤＢＲはすごく簡単になりました。ボトルネックのタイムバッファーと組立バッファーを廃止して、 出荷バッファーだけにしました。もっと大胆な変革は、スケジューリングを廃止したことです。ＤＢＲはスケジューリングが複雑になりすぎて自滅しましたが、 そのスケジューリングをやめちゃったんです。ＤＢＲの失敗の根源を絶った。実に合理的な方向転換だったと思います。
スケジューリングを廃止して、タイムバッファーをひとつだけにしたことで、すごくシンプルになりました。これで、 ＤＢＲはＳ－ＤＢＲという名前で復活するんです。今は、ほとんどがＳ－ＤＢＲになっています。ＤＢＲは、 事実上、消えたんじゃないのかな、、。あったとしてもごく限られた条件のところで、でしょうね。
Ｓ－ＤＢＲの最大の特徴であるスケジューリングの廃止。現在の生産管理が生産計画（日程計画）を機軸としていること、また、 ＤＢＲはスケジューリングの改良から出発していることを考えると、 かなり大胆な発想ではないか、と思いますよね。スケジュールがなくて大丈夫なの？と。
しかし、これはＤＢＲからの引継ぎ事項で、大胆というほどのことではないんです。ＤＢＲはボトルネックのスケジュールはありますが、 他の工程のスケジュールはありません。ですから、非ボトルネック工程はＤＢＲもＳ－ＤＢＲもスケジュールなし、 で同じ。スケジュールがなくても動くのはＤＢＲで実証済みのこと、なんです。
Ｓ－ＤＢＲのスケジュール廃止は、スケジューリングの改良というＤＢＲの出発点まで遡ると、結果論ではありますが、ＤＢＲは回り道だったのかもしれません。 回り道だけならいいのですが、制約理論がＤＢＲに端を発していることを考えると、その発達過程で派生した理論とか法則みたいなものも、 再考してみなければならないのかもしれません。ということは、Ｓ－ＤＢＲも制約理論の枠内でＤＢＲの血筋を引いていますので、 Ｓ－ＤＢＲの実用性なども、見直すところがあるかもしれない、、そんな気がしています。