MRPの大雑把なスケジューリングの欠点改善を目指したOPTでしたが、思うようには売れませんでした。しかし、苦肉の策で出版した「ザ・ゴール」は、思いのほか売れ行きがよく、その後十数年、ベストセラーの座をしめ、全米で２５０万部を超える販売数を記録しました。
OPT発売のときも、「ザ・ゴール」出版のときも、スケジューリングの詳細についての説明はありませんでした。MRPについてはすべてが公開されていたのに、、。DBRのスケジューリングについても公開を望む声が大きくなりました。
１９９０年、ゴールドラットは「The Haystack Syndrome」を出版。その中で、DBRのスケジューリングについて詳細な説明を行っています。それをきっかけに、DBR対応の生産スケジューラが次々と発表されました。中には、“ゴールドラット博士公認”なんていうサブタイトルを付けるベンダーもいました。１９９０年代後半、ベンダーは１０社を超えていたんじゃないかと思います。
しかし、ゴールドラット自身がスケジューラを開発することはありませんでした。OPTの失敗を繰り返したくなかったのでしょうか。
DBRスケジューラが実際の現場で使われるようになりました。しかし、ゴールドラットが「The Haystack Syndrome」で説明したようにスケジュールすることはできませんでした。ただ、生産リードタイムが短縮したなどの効果が出たという事例はわずかながら報告されています。OPTを使わなくても改善できた、という現象に似ているのかもしれません。
使えない生産スケジューラがいつまでも売れるわけはありません。DBR対応スケジューラはポツリ、ポツリと姿を消し、２０００年代の中頃にはその大部分が姿を消しました。
このような動きの中で、DBRに異変が起きます。あれほどロジカルに、詳細に説明されるボトルネックを中心としたスケジューリングをあきらめたのです。ボトルネックを中心にスケジュールすることにより、MRPのスケジューリング機能の矛盾を解消しようとしたわけですが、目的を達成することなく、幕が引かれることになりました。
DBRは失敗でした、ということは、さすがに言えなかったようで、S-DBR（Simplified-DBR）にモデルチェンジし、旧DBRと併存させることになりました。
「The Haystack Syndrome」にあるDBRのスケジューリング方法について、少し詳しくみていきましょう。
TOCのお馴染みのステップを繰り返しながらスケジュールを組み立てていきます。
①システムの制約条件（ボトルネック）を見つける
②制約条件を徹底的に活用する
③制約条件以外のすべてを制約条件に従属させる
④制約条件の能力を高める
⑤制約条件が解消されたら、最初のステップにもどる
オーダーの納期を守りながら、且つできるだけ遅く投入して、ボトルネックの能力を割り当て、稼働率は１００％になるようにする、といったことはよく知られていることです。それまであまり出てこなかったことについても説明されています。
- タイムバッファーはResource Buffer（ボトルネック）、Assembly Buffer（組立）、Shipping Buffer（出荷）の３つのバッファーがある。つまり、３か所でスケジューリングが必要。
- ボトルネックが複数あり、互いに干渉するとき、Time Rodという時間のつっかいぼ棒を入れて、干渉を防ぐ
- 非ボトルネックの負荷が一時的に１００％を超えるときそれを検出して、タイムバッファーを増やす。つまり、状況に応じてタイムバッファーの長さを調節する（Dynamic Buffering）
Dynamic Bufferingに関して、おもしろいことが書いてあります。それは、オーダーが工程の前でできる行列を待つ時間について言及していることです。一部、抜粋してみます。
これまで苦労した問題のひとつは待ち時間をどう見積もるかだ。待ち時間を決めることでいつも製造担当と資材担当の間でもめることは、MRPを導入しようとした人は誰でも知っている。問題対策や優先順の入れ替えが常態化しているのをみると、待ち時間は短めに設定されているようだ。全体のリードタイム短縮への圧力が、みんなで長めに設定している、と思わせているのだろうか。常に議論していても、工程の待ち時間の見積もりはかなり大雑把だということは関係者のだれもがよく知っていることだ。設計では、状況はもっと悪い。待ち時間は実行時間に丸められてしまい、時間見積の信頼性を落とすことに繋がる。
不思議なことではない。待ち時間は個々の作業ではなくリソースに割り当てられる負荷によって決まる。オーダーは均一な流れで到着するわけではない。そしてオーダーの組み合わせは常に変化し続ける。その結果、猛烈に忙しい日が２日続いたと思えば、次の日は何もすることがない、といったように、それぞれのリソースに課される負荷は大きく変動する。待ち時間を数値で与えようとすることは、動的な実態を仮想的な平均値で代表させようとすることだ。満足する結果にはならないだろう。
待ち行列現象で起きる待ち時間についての記述です。ところが、ところが、てっきり、ボトルネックでの待ち時間かと思いきや、違うんですよ。驚いたというか、拍子抜けしたかというか、、。非ボトルネックでの話なんです。
投入からボトルネックまでの間にある非ボトルネック工程の負荷が高くなったとき、タイムバッファーを長くするというDynamic Bufferingの説明なんです。
ボトルネックの稼働率は１００％に近いわけですから、オーダーの待ち時間は大きく変動するわけです。非ボトルネックでの影響どころではありません。事細かな配慮をして、５ステップを踏みながらスケジュールを収束させようとしているとき、指数関数的に増加、変動する待ち時間が加われば、一瞬にして立てたスケジュールは崩壊してしまうんじゃないでしょうか。それには、まったく触れていないんです。
待ち行列の待ち時間に気付きながら、そして、常にボトルネックを中心に考えるTOCで、なぜ、非ボトルネックでの待ち時間だけを考え、肝心のボトルネックでの待ち時間に気が付かなかったのか、不思議でなりません。
DBRとS-DBRの大きな違いは、DBRがResource、Assembly、Shippingの３バッファーであるのに対し、S-DBRはShipping Bufferだけしかないことです。ResourceとAssemblyのバッファーをShipping Bufferに含めた、と説明されています。
実は、Resource BufferはAssembly BufferやShipping Bufferと基本的に異なるところがあります。それは、Assembly BufferやShipping Bufferには待ち行列現象による待ち時間は基本的に発生しにくいのに対し（待ち行列現象以外の待ちは発生します）、Resource Bufferは必ず待ち行列現象が生じることです。
ですから、Shipping BufferにResource Bufferを含めたといっても、待ち行列時間は生じますので、その軽減策を講じることが必要になります。S-DBRは常に市場に制約があるという条件で使うことにしているのは、工程内部にボトルネックが生じて多大な待ち時間を発生させないことを意図したものと考えられます。
スケジュールに関して、付け加えておきたいことがもうひとつあります。ゴールドラットは、１９９７年、「クリティカル・チェーン」を出版します。クリティカル・チェーンとはプロジェクト管理の方法論です。中心的課題はプロジェクトのスケジューリング。
プロジェクト管理にはPERTやCPR（クリティカルパス法）がありますが、プロジェクトは一般的には、生産と比べれば、不確定要素が多く、納期やコスト管理がむずかしくなります。クリティカル・チェーンのバラツキを管理する方法は、これまでのPERTやCPRとは異なります。
注目しておきたいところは、生産スケジューリングのDBRとの関係です。DBRと同じようなタイムバッファーを組み込んで時間変動を管理するのか、と思いきや、DBRとは異なった時間変動管理法を採用していることです。各タスクの時間変動分を集めて、一番後ろにプロジェクト・バッファーとして、タイムバッファーを置きます。進捗管理は、このプロジェクト・バッファーへの食い込み具合で行います。
ゴールドラットは、なぜ、生産ラインと異なるバラツキ管理を採用したんでしょうか。設計～生産という受注生産もありますので、そのような時、設計はプロジェクト管理、生産はDBRというと繋がりが悪くなります。同じ方法の方が繋がりはスムースです。いや、それ以上の理由があるんでしょうね。どんな理由なんでしょうか、、。
次回、考えてみます。