前回、次代の工場管理の方向性は、IoT等の情報技術を活用し、生産ラインの特性をベースにした需要基準の生産管理ではないか、という展望をガイドラインにして、平成の30年間に工場管理にどのような進化、変化があったかをザッと、振り返ってみました。
MRP―MRPII―ERPの進化とフォード生産方式―トヨタ生産方式（TPS）は、現在の工場管理を構成する2大潮流となっておりますが、それぞれに弱点もあります。それに対する幾多の改善、挑戦の中で、最も期待されたのは、TOCが提唱するDBR/SDBRだったのではないか。期待された主な理由は、MRPもTPSも悪しきものとして排除したバラツキをDBR/SDBRは積極的に許容したこと。漠とした暗雲に包み込まれた生産管理に光明がさしかけた瞬間でもありました。
しかし、かすかな痕跡は残ったにしても、DBR/SDBRが2大潮流に与えた影響はほとんどありません。だからと言って、DBR/SDBRは使いものにならない、、と切り捨てていいのか、、。TOCのブームが過ぎ去った今、なぜ、DBR/SDBRが機能しないのか、レビューする中から次のステップへ進むヒントみたいなものがみつかればと、、思いつつ、、。
DBR/SDBRの適用に関して、SDBRの開発者、エリ・シュラーゲンハイムの「DBR/SDBRの境界」と題したブログが参考になります。その中で、DBR/ SDBRの導入で高い納期遵守率と高い信頼性を達成するための、不可欠かつ基本的な前提条件に付いて次のように述べております。（出典；日本語、英語） 気になるところを抜き出してみます。
＊どの製造オーダーも、正味のタッチタイムがリードタイム（投入から完了までの時間）に比べて非常に短い。
ゴールドラット博士は、タッチタイムはタイムバッファの10％未満だと仮定した。
それ以外の時間は、必要なリソースが空くのを製造オーダーが待っている時間であり、リソースの多くは稼働率があまり低くない。
＊ほとんどの製造オーダーは、イエローゾーン内に完了するか、レッドゾーンに食い込む当たりで完了する。
――― 中略 ―――
なら、ある工程のタッチタイムがバッファの30％くらいになると、一体どうなるんだろう？
SDBRでは、バッファの保護対象は、原材料を投入してから完了するまでの製造プロセス全体です。一つの工程でその30％も使うとなれば、次の2つの重大な問に答えないといけません：
①そのバッファ時間で、製造プロセス全体の変動から納期を守るのに十分か？ つまり、30％のタッチタイムは保護時間から引かないといけないので、残り70％の時間で納期を守るに十分か？ ということ。
②DBR/ SDBRのバッファ管理では、製造オーダーが今どの工程にあるかはバッファの状態に反映されない。なぜなら、タッチタイムが無視できるときは、大して問題にならないからである。しかし、ある特定の工程でバッファの30％も使うとなれば、製造オーダーがその長い工程を通過したか否かは大きな問題である。仮にまだその長い時間かかる工程の上流にあるとしたら、残っている実質的なバッファは、納期までの残時間に比べて相当短い時間になるからだ。
DBR/SDBRを適用できるのは、タッチタイムがリードタイムの10％未満であること。それを超えるとき、例えばある工程のタッチタイムが30％くらいになる場合は、残りの70％の時間で納期を守るのに十分かどうかを確認しなければならないし、また、製造オーダーがその工程（タッチタイムが30％の工程）の前にあるのか後ろにあるのか確認しなければならない、と言っているわけです。
この説明を読んでいる限り、特におかしなところはないようですが、実はこれ、「DBR/SDBRの境界」というよりは「DBR/SDBRの限界」を吐露しているように感じられます。
具体的な数値を入れて考えてみましょう。例えば、リードタイムが10日だとすると、正味タッチタイムは1日未満。で、ほとんどの製造オーダーは、イエローゾーン内に完了するか、レッドゾーンに食い込む当たりで完了するということなので、図１に示す日数分布（平均6日）で完了する、とします。ということは、正味タッチタイム平均が1日として、平均待ち時間は5日ということになります。
注目しているのは時間です。正味タッチタイム、リードタイム、3つのタイムゾーン、待ち時間。どれも時間。そしてオーダーの飛び込む時間間隔はランダムにバラツキ、タッチタイムもバラツク。
図１ 3つのタイムゾーンと平均完了時間のイメージ
この問題を「待ち行列理論」を利用して考えてみましょう。
簡略化して、生産ラインは1工程とします。オーダーの受注時間間隔は指数分布、タッチタイムは平均1日の指数分布に従うとします。平均完了時間を6日としますと、待ち時間は平均5日となります。単位時間当たりの処理数をμ、工程の稼働率をρとして、平均待ち時間は次の式で与えられます。
平均待ち時間＝ρ/｛μ・（1－ρ）｝
単位時間を1日としますと、1日での平均処理数はμ＝１、平均待ち時間は5日なので、
ρ/(1－ρ)=5
ρ＝0.833
工程の稼働率は83.3%ということになります。その他にも次のようなことが計算できます。
平均到着率λ；単位時間当たりに到着するオーダーの平均数
λ＝μ.ρ＝0.833
オーダーの平均到着間隔は、1/0.833＝1.2 となり、平均1.2日で1件のオーダーが来るということになります。
工程内にあるオーダー数の平均Lは、
L=ρ/(1－ρ)=0.833/(1－0.833)=5
工程前に処理を待っているオーダー数の平均Lgは、
Lg=ρ・ρ/(1－ρ)=0.694/(1－0.833)≅4.2
ということになります。イメージを図２に示します。
図２ タッチタイム1日の工程流れのイメージ
次に、タッチタイムが30％の場合について考えてみましょう。前と同じ条件でタッチタイムだけを平均3日として計算してみます。タッチタイムが平均3日かかりますので、待ち時間は平均3日（完了平均時間６日－タッチタイム平均3日）。タッチタイムが平均3日なので1日での平均処理数はμ＝1/３。
3×ρ/(1－ρ)=3
ρ＝0.5
工程の稼働率は50%になります。その他の値も同じように計算してみます。
L=0.5/(1－0.5)=1
Lg=0.5×0.5/(1－0.5)=0.5
イメージを図３に示します。
図３ タッチタイム3日の工程流れのイメージ
タッチタイムが10％から30％への変化に注目するため、その他の条件は大幅に簡略化しました。待ち行列理論を利用して計算したところ、タッチタイムが平均1日のときは工程の稼働率は83.3％、平均3日のときは50％という結果になりました。そして、仕掛と処理数を合わせた工程仕掛は、タッチタイムが平均1日では平均５オーダー、平均3日では平均１オーダーとなりました。
エリ―・シュラ―ゲンハイムの説明と比べてみましょう。
「DBR/SDBRを適用できるのは、タッチタイムがリードタイムの10％未満であること」
これをザックリと翻訳しますと、
「DBR/SDBRを適用できるのは、稼働率が83％未満であること」
となります。稼働率が83％以上を狙う場合はDBR/SDBRは使えませんよ、ということになりますね。
では、タッチタイムが30％のときは、、、そうですね。
「DBR/SDBRを適用できるのは、稼働率が50％未満であること」
となり、これが、タッチタイムが30％であるときのDBR/SDBRが使える条件だということになります。
「残りの70％の時間で納期を守るのに十分かどうか、また、製造オーダーがその工程の前にあるのか後ろにあるのか確認しなければならない」
なんていう必要はないことになります。（但し、オーダー個々の優先順を制御するときは、工程の位置が重要な意味を持つことになりますが、それについては別途、触れます）
いかがでしょうか。エリ―・シュラ―ゲンハイムの説明よりは、具体的なイメージがつかみやすくなったのではないでしょうか。ポイントは、工程の稼働率が重要な要素になっていることです。DBR/SDBRがバラツキを許容しておきながら、うまくバラツキを処理できない最大の理由は、稼働率（利用率）を考慮しなかったことではないかと思います。稼働率によって待ち時間が大きく変わります。どのように変化するかといいますと、実際は様々な係数がかかりますが、コアの部分は、
平均待ち時間＝ρ/(1－ρ)
となります。一例を示しますと、図４のようになります。これだけ待ち時間が急激に変化する要因である稼働率を無視したら、リードタイムのコントロールなどできるわけはありません。一目瞭然でしょ。DBR/SDBRが機能しない理由は、生産ラインの物理的基本特性である稼働率と待ち時間の関係を正しく捉えていないから、なんですね。
図４ 稼働率に対する平均待ち時間のカーブ
もちろん、待ち行列理論だけではすべてを説明できるわけではありません。待ち行列理論で計算できるのは、主に、平均値です。分布の形状を求めることはできません。生産管理では、納期遵守率も知りたいところですが、そのためには分布形状を計算する必要があります。どうしたらいいか、、。おいおい、お話ししてまいりたいと思います。
今回は、MRPやTPSが排除したバラツキを、むしろ積極的に取り入れながらも、結局はバラツキの渦の中で悶え、消えかけているDBR/SDBRの根本的欠陥は何なのか、についてお話しました。