投稿者: tonchi

生産型の流れでは、工程ひとつひとつが待ち行列現象を起こす形をしています。生産にたずさわる誰もが、工程の稼働率をできるだけ高く維持しようとします。そうすると、待ち行列現象が強くなり、長い待ち時間が発生することになります。

プロジェクト型でも待ち行列現象は起きますが、部分的であり、その影響は生産型に比べれば軽微です。

待ち行列現象の待ち時間とはどんな特徴があるんでしょうか。事例で試算してみましょう。図１をご覧ください。できるだけ同じ条件で比べた方がわかりやすいと思います。生産型もプロジェクト型も直列5工程（５タスク）、処理時間平均は工程４（タスク４）が９時間、他の工程（タスク）は7時間です。生産型の工程バラツキは変動係数0.25、プロジェクト型は0.75と大きくしてあります。生産型のオーダはランダムに投入されますが、平均時間間隔は10時間です。プロジェクト型はプロジェクトX、ひとつです。

図１　事例研究；生産型とプロジェクト型の比較

生産型では、ひとつのオーダが完成するまでの時間、プロジェクト型ではプロジェクト開始後完成までの時間を試算してみます。その一例を図２に示します。プロジェクト型のタスクのバラツキは生産型のそれの３倍であることにご留意ください。にもかかわらず生産型の所要時間の方が平均も最大値も長くなっています。分布をみても、プロジェクト型は、正規分布に近い分布形状ですが、生産型のそれは右に大きくすそ野が伸びています。

図２　生産型とプロジェクト型の完成までの所要時間の比較

どの工程での待ち時間が長いのか、調べてみました。工程１，２，３、と５はほぼ同じなので、工程１を代表に、工程４の待ち時間と比べてみました。結果を図３に示します。工程４の待ち時間が全体の所要時間に大きく影響を与えていることがわかります。 

図３　工程４の待ち時間が長い

工程１，２，３，５の稼働率は0.7、工程４のそれは0.9。稼働率が高くなると、待ち時間が急激に長くなる待ち行列現象の影響であることは明白です。

この待ち行列現象による待ち時間。困ったことに、実に、捉えにくいというか、扱いにくいというか、始末に負えないんです。図２と図３のデータを採るとき、計算ごとに結果が結構バラツクんです。乱数を使っていますので、バラツクのは当たり前なんですが、計算するごとに出る結果の違いに驚いてしまいます。お示しした結果は、だいたい平均的なものです。

プロジェクト型の所要時間の分布はだいたい正規分布に近いのですが、生産型のそれは右に長々とすそ野を引くのが特徴のひとつです。プロジェクト型の分布は統計理論を応用できそうですが、生産型の分布は統計理論では扱えそうにありません。生産型の分布を扱える数理モデルってあるんでしょうか。いろいろ探してみたんですが、見つかりません。

待ち行列理論も調べてみました。待ち行列理論の数理モデルは待ち時間、待ち行列の長さ、待っているWIPの数を計算できますが、すべて平均なんです。生産管理では、平均値も有用な情報ですが、分布の端っこの部分が重要ですので、そこを知りたいんです。確率分布の形状を扱える数理モデルって、ないのかなぁ～、、。今のところ、見つかっておりません。ご存知の方がいらっしゃいましたら、ぜひ、ご一報ください。

プロジェクト型のスケジューラでは、バラツキを考慮したものがあります。プリミティブなものでは、３点見積で標準偏差を求め、本格的なものは過去の蓄積されたデータから標準偏差を求め、加法性を利用して、各タスクの平均、分散を合算してプロジェクト全体の所要時間を算出する。正規分布で近似して、納期の達成確率などを見積もるようなことが行われているようです。

では、生産スケジューラではどうなんでしょうか。待ち行列現象を考慮した生産スケジューラって、市販されているのでしょうか。

生産スケジューラ・ベンダーの宣伝文句をみると、受注生産、多品種少量・変量、即座の計画変更、、なんでもゴザレ、、という感じですが。額面通り受け取れば、当然のことながら、待ち行列現象に対しても、対応策をとっているのではないか、と思われるんですが。実態はどうなんでしょうか。

さらに、追求してみたいと思います。

DPM研究舎

ゴールドラットが提唱したDBR生産スケジューラは、盟友のエリ―・シュラ―ゲンハイムが提唱するS-DBRにGrade Up（Grade Down?）されたことで、実行可能なスケジューリングができないことを認め、MRPのスケジューリング問題を解決しようとした元々のゴールにたどり着くことはできませんでした。ただ、スケジュールがなくても、ボトルネックを中心とした管理方法は有効で、うまく使えばそれなりの効果はでるようです。

ゴールドラットが次に発表したのが「クリティカル・チェーン」。プロジェクト管理のあたらしい方法です。各タスクのバラツキ分を集めて、スケジュールの一番後ろにプロジェクトバッファーとして置きます。プロジェクトバッファーの一番後ろが納期ですので、プロジェクトバッファー以内で終了すれば、納期は守られることになります。

DBRのタイムバッファーとクリティカル・チェーンのタイムバッファーは異なります。この違いに何か特別な意味はあるんでしょうか？　ゴールドラットにしてみれば、TOCという壮大なマネジメント論のとっかかりであるDBRの考え方を踏襲したかったのではないかと思うんですが、、ね。プロジェクト管理では、負荷１００％を超える特定のリソースがボトルネックと考えることはできないんでしょうか。ボトルネックのリソース（人）には雑用を頼まない、それでも足りなければ、助っ人をあてがう、、。DBRと同じように考えることができそうですがね、、。

ゴールドラットはTOCの原点ともいえるDBRの考え方をプロジェクト管理に適用しなかったのはなぜなんでしょうか。いまさら故人に聞くわけにもいきません。いろいろと思いめぐらしてみましょう。

ゴールドラットがプロジェクト管理について考えていたのは１９９０年の中頃ではないかと思われます。１９９０年に「The Haystack Syndrome」でDBRのスケジューリングを発表し、それを真似ていくつかのDBRスケジューラが開発されました。現場で使ってみると、どれもまともに実行可能なスケジュールを組むことはできません。

そして、盟友であるエリ―・シュラ―ゲンハイムがボトルネックのスケジューリングを排したS-DBRを開発します。エリ―・シュラ―ゲンハイム他著「Supply Chain Management at Warp Speed」にS-DBRの詳細な説明が載っています。

２３ページに、ボトルネック（CCR; Capacity Constrained Resource）負荷が処理時間とWIPにどのような影響を及ぼすかの図があります。説明を加えておきますと、処理時間とは待ち時間と正味処理時間を足したものです。正味処理時間は、基本的に、負荷によって変わりませんので、指数関数的に上昇する処理時間の中身は待ち時間の増大です。

図１　CCR Load v.s. Production Time
(Reference; Supply Chain Management at Warp Speed)

エリ―・シュラ―ゲンハイムがS-DBRを提唱した大きな理由は、ボトルネック工程での待ち行列現象を回避するためだったのではないかと思われます。“ボトルネック工程の稼働率を100％でスケジューリングすることは物理的に不可能である”ことに気が付き、DBRの最も重要な概念である“ボトルネックの能力を100％引き出す”ことを断念せざるを得なかったのではないか、、。

「ボトルネック工程の１００％稼働スケジューリングはうまくいかない」

プロジェクト管理で、“DBR方式”を採らなかった理由がは、、この辺りでしょうか。

ゴールドラットを救ったのは、生産工程フローとプロジェクト・タスク・フローの違いです。以降、生産型、プロジェクト型とします。何が違うかと言いますと、生産型にはあって、プロジェクト型にはないもの、です。

図２をご覧ください。基本的なところだけをシンプルに表しております。生産ラインにオーダーがランダムに来ます。「工程１」で「オーダA」の処理が終わる前に「オーダB」が来た場合、「オーダB」は「工程１」の前で「オーダA」の処理が終わるまで待つことになります。「オーダA」の処理が終わる前に「オーダC」が投入されれば「工程１」の前では「オーダB」と「オーダC」の2つのオーダが「工程１」の前で待つことになります。この現象、お気づきのことと思います。待ち行列現象です。「工程１」の処理能力に対してオーダの投入が少ないときは待ち時間は短く、オーダが多くなると待ち時間はグンと長くなります。負荷と待ち時間の関係は図１のようになります。

待ち行列現象を起こすのは、「工程１」だけではありません。「工程２」も「工程３」も・・・ほとんどの工程で待ち現象を起こす可能性があります。。稼働率が低い間は待ち時間は短いので余り影響はありませんが、生産管理では常に稼働率を高くすることを目指していますので、いたるところで待ち行列現象を起こしてしまいます。ボトルネック工程は一カ所か二ヶ所、なんて悠長に構えているわけにはいきません。どの工程も100％の稼働率を目指すのが宿命。

図２　生産ラインの代表的モデル

プロジェクト・タスク・フローはどうでしょうか。実は、プロジェクト・タスク・フローでも待ち行列現象は起きます。わかりやすいのは、管理者の机で山積みになるハンコを待つ書類の山。“めくら判”でも、1週間もかかる。

構造上の基本的な特徴、生産ラインとの違いに注意してプロジェクト計画の流れをみてみましょう。図３に基本的なプロジェクト計画の流れを示します。

プロジェクトXをひとつのまとまったプロジェクトとします。「タスク１」で最初の仕事をします。終わったら「タスク２」、次に「タスク３」、、、そして「最終タスク」を終えて「完成」となります。

図３　プロジェクト計画の一般的流れ

生産型とプロジェクト型の違いをまとめてみましょう。共通する部分、類似する部分、あいまいな部分、、もありますが、あえて単純化して、両者の違いをみてみます。

生産型はひとつの工程（処理ユニット）にオーダ（非処理対象）が次から次と来ます。一方、プロジェクト型はひとつのプロジェクト（非処理対象）に対して様々なタスク（処理ユニット）があります。単純化しますと、次のようになります。

生産型　　　　；非処理対象数（多数）＞＞処理ユニット（基本単位１）
プロジェクト型；非処理対象数（基本単位１）＜＜処理ユニット（多数）

生産型はひとつの工程に対して、オーダが多数流れてくる。プロジェクト型は、ひとつのプロジェクトが多数のタスクで処理されて完成する。いかがでしょうか。

で、待ち行列現象が起きるかどうか、の視点でみてみましょう。生産型はほとんどの工程が待ち行列現象の発生条件を満たしております。プロジェクト型はどうでしょうか。プロジェクトがひとつしかありませんので、行列ができませんね。待つのは、プロジェクトではなくて、タスク（リソース、人、、）。もちろん細かくみれば、プロジェクトも複数のジョッブに分けられますので、時間単位を短くしてみると、ジョッブの待ちがあることが観察されますが、全体としてみれば、待ち行列現象の程度は小さいのではないかと思われます。

もうひとつの違い。
生産型；一つの工程の処理時間が短い
プロジェクト型；一つのタスクの時間が長い

これは、管理サイクル内でどの程度の進捗管理（修正、調整等含む）ができるか、という視点でみるとき、生産型では一個、一個の処理時間をリアルタイムで管理することは困難。一方、プロジェクト型の場合は、短くは朝夕、1日単位、週単位での進捗管理が可能、という違いはあるのではないか、と思われます。

これも大きな違いです。
生産型；処理時間の見積が正確
プロジェクト型；処理時間の見積精度が低い

生産型の作業時間は標準化が行われ、大量生産では、時には秒単位で標準作業時間が設定されています。プロジェクト型は、作業そのもの繰返しが少なく、作業時間の見積精度は低いのが一般的です。表１に生産型とプロジェクト型の比較をまとめてみました。

表１　生産型とプロジェクト型の比較

生産型とプロジェクト型のスケジューリング、さらに追及していきます。

DPM研究舎

MRPの大雑把なスケジューリングの欠点改善を目指したOPTでしたが、思うようには売れませんでした。しかし、苦肉の策で出版した「ザ・ゴール」は、思いのほか売れ行きがよく、その後十数年、ベストセラーの座を占め、全米で２５０万部を超える販売数を記録しました。

OPT発売のときも、「ザ・ゴール」出版のときも、スケジューリングの詳細についての説明はありませんでした。MRPについてはすべてが公開されていたのに、、。DBRのスケジューリングについても公開を望む声が大きくなりました。

１９９０年、ゴールドラットは「The Haystack Syndrome」を出版。その中で、DBRのスケジューリングについて詳細な説明を行っています。それをきっかけに、DBR対応の生産スケジューラが次々と発表されました。中には、“ゴールドラット博士公認”なんていうサブタイトルを付けるベンダーもいました。１９９０年代後半、ベンダーは１０社を超えていたんじゃないかと思います。

しかし、ゴールドラット自身がスケジューラを開発することはありませんでした。OPTの失敗を繰り返したくなかったのでしょうか。

BDRスケジューラが実際の現場で使われるようになりました。しかし、ゴールドラットが「The Haystack Syndrome」で説明したようにスケジュールすることはできませんでした。ただ、生産リードタイムが短縮したなどの効果が出たという事例はわずかながら報告されています。OPTを使わなくても改善できた、という現象に似ているのかもしれません。

使えない生産スケジューラがいつまでも売れるわけはありません。DBR対応スケジューラはポツリ、ポツリと姿を消し、２０００年代の中頃にはその大部分が姿を消しました。

このような動きの中で、DBRに異変が起きます。あれほどロジカルに、詳細に説明されるボトルネックを中心としたスケジューリングをあきらめたのです。ボトルネックを中心にスケジュールすることにより、MRPのスケジューリング機能の矛盾を解消しようとしたわけですが、目的を達成することなく、幕が引かれることになりました。

DBRは失敗でした、ということは、さすがに言えなかったようで、S-DBR（Simplified-DBR）にモデルチェンジし、併存させることになりました。

「The Haystack Syndrome」にあるDBRのスケジューリング方法について、少し詳しくみていきましょう。

TOCのお馴染みのステップを繰り返しながらスケジュールを組み立てていきます。
①システムの制約条件（ボトルネック）を見つける
②制約条件を徹底的に活用する
③制約条件以外のすべてを制約条件に従属させる
④制約条件の能力を高める
⑤制約条件が解消されたら、最初のステップにもどる

オーダーの納期を守りながら、且つできるだけ遅く投入して、ボトルネックの能力を割り当て、稼働率は１００％になるようにする、といったことはよく知られていることです。それまであまり出てこなかったことについても説明されています。

＊タイムバッファーはResource Buffer（ボトルネック）、Assembly Buffer（組立）、Shipping Buffer（出荷）の３つのバッファーがある。つまり、３か所でスケジューリングが必要。
＊ボトルネックが複数あり、互いに干渉するとき
Time Rodという時間のつっかいぼ棒を入れて、干渉を防ぐ
＊非ボトルネックの負荷が一時的に１００％を超えるとき
それを検出して、タイムバッファーを増やす。つまり、状況に応じてタイムバッファーの長さを調節する（Dynamic Buffering）

Dynamic Bufferingに関して、おもしろいことが書いてあります。それは、オーダーが工程の前でできる行列を待つ時間について言及していることです。

～～～～～
これまで苦労した問題のひとつは待ち時間をどう見積もるかだ。待ち時間を決めることでいつも製造担当と資材担当の間でもめることは、MRPを導入しようとした人は誰でも知っている。問題対策や優先順の入れ替えが常態化しているのをみると、待ち時間は短めに設定されているようだ。全体のリードタイム短縮への圧力が、みんなで長めに設定している、と思わせているのだろうか。常に議論していても、工程の待ち時間の見積もりはかなり大雑把だということは関係者のだれもがよく知っていることだ。設計では、状況はもっと悪い。待ち時間は実行時間に丸められてしまい、時間見積の信頼性を落とすことに繋がる。

不思議なことではない。待ち時間は個々の作業ではなくリソースに割り当てられる負荷によって決まる。オーダーは均一な流れで到着するわけではない。そしてオーダーの組み合わせは常に変化し続ける。その結果、猛烈に忙しい日が２日続いたと思えば、次の日は何もすることがない、といったように、それぞれのリソースに課される負荷は大きく変動する。待ち時間を数値で与えようとすることは、動的な実態を仮想的な平均値で代表させようとすることだ。満足する結果にはならないだろう。
～～～～～

待ち行列現象で起きる待ち時間についての記述です。ところが、ところが、てっきり、ボトルネックでの待ち時間かと思いきや、違うんですよ。驚いたというか、拍子抜けしたかというか、、。非ボトルネックでの話なんです。

投入からボトルネックまでの間にある非ボトルネック工程の負荷が高くなったとき、タイムバッファーを長くするというDynamic Bufferingの説明なんです。

ボトルネックの稼働率は１００％に近いわけですから、オーダーの待ち時間は大きく変動するわけです。非ボトルネックでの影響どころではありません。事細かな配慮をして、５ステップを踏みながらスケジュールを収束させようとしているとき、指数関数的に増加、変動する待ち時間が加われば、一瞬にして立てたスケジュールは崩壊してしまうんじゃないでしょうか。それには、まったく触れていないんです。

待ち行列の待ち時間に気付きながら、そして、常にボトルネックを中心に考えるTOCで、なぜ、非ボトルネックでの待ち時間だけを考え、肝心のボトルネックでの待ち時間に気が付かなかったのか、不思議でなりません。これが、DBRスケジューリングが実行可能なスケジュールとはならない大きな理由です。

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というと繋がりが悪くなります。同じ方法の方が繋がりはスムースです。いや、それ以上の理由があるんでしょうね。どんな理由なんでしょうか、、。

次回、考えてみます。

DPM研究舎

成功事例よりもはるかに多い生産スケジューラ導入の失敗事例。今始まったことではありません。様々な改善の努力も行われています。月間雑誌「工場管理」では頻繁に取り上げられるテーマです。「あーやればいい」、「こうやらなくちゃ」、「いやいやこうであるべきだ」、、と議論は尽きません。でも、改善の兆しは一向に見えない。

AIだ、IoTだ、第４次産業革命だって騒いでいるご時世ですから、生産スケジューラもさぞかし進化しているのでは、と思われる方も多いと思います。生産スケジューラ・ベンダーのWebsiteを見れば、見込生産、受注生産なんでもござれ、スケジュール変更も即座に対応、、うんぬんと万能ぶりをうたう説明が満載。

生産現場で多発する生産スケジューラ導入失敗事例とベンダーの美辞麗句。このギャップに、異常な“怪しさ”を感じてしまいます。これが、日本の“製造業”をむしばんでいなければいいのですが、、。製造現場でも、お悩みの方が多いのではないか、と察します。

「えっ、えっ、えっ、、生産スケジューラって、そんなに複雑な問題なんですか？　昔からあったし、スケジュールなんて、日常生活のいたるところにあるじゃないですか。珍しくもなんともない。何が問題なんですかぁ～。」

生産スケジューラの背後にある問題構造とは？　と、大上段に構えるつもりはありません。ごく、常識的な知見をつなぎ合わせながら、生産スケジューラが抱える根本問題を探ってみたいと思います。

ちょっと、振り返ってみましょう。生産スケジューラと最も関係が深いのがMRP。MRPは
Material Requirements Planningで、資材所要量計画のこと。計画した生産台数に必要な部品などの数量を計算するのに使われます。それにスケジューリング機能が加わり、MRPIIとかManufacturing Resource Planning（製造資源計画）となります。生産スケジューラとの関係を考えるのは、MRPIIの方ですが、MRPと略します。

MRPのスケジューリング機能は、その出自からみてもわかりますように、時間単位（タイムバケット）が大きい。１週間程度が多いようですが、時間や分、秒単位ではない。ですから、MRPのスケジュールは大雑把。

時代が進むと、この大雑把さが問題となってきます。この問題に対していくつかの提案が出てきます。その中のひとつが、TOC（制約理論）のDBR（Drum Buffer Rope）。

“『ザ・ゴール』誕生の背景とその後”から抜粋、要約

1970年代後半にイスラエルの物理学者エリー・ゴールドラット（Eli Goldratt）は生産スケジューリングのことを相談され、物理学の研究で得た発想や知識を使って当時としてはアーキテクチャ面で画期的な生産スケジューリングソフトウェアOPT（Optimized Production Technology）を開発した。

OPTは高価なソフトウェアであるにもかかわらず、それを導入した工場では生産性が大幅に改善され、生産リードタイムが劇的に短縮するという効果が出て一躍注目されるようになった。

市場環境も良かった。どの工場もコンピュータ導入に躍起で、オートメーションが時代の流行でもあった。どの生産マネジャーもスループットの向上と納期遵守に悪戦苦闘していた。仕掛品の削減メリットに注目し始めた者もいた。これを実現する機能を備えたソフトは、OPTだけだった。にもかかわらず、クライアント数は期待したほど増えなかった。

失望感のなかから、何か新しいアプローチがあるはずだとゴールドラットは考えた。小説を通じて製造とは何なのか、彼の手法を伝えようと思ったのだ。『ザ・ゴール』の誕生である。

ところが、『The Goal』の出版（１９８４年）直後に、多くの読者から『The Goal』は自分の工場とまったく同じ状況を描いているとか、自分の工場をモデルにしたのではないかという手紙が舞い込むようになる。中には小説にあるとおりに改善を実施してみたら、小説とまったく同じような劇的な成果が出たという手紙もあった。

いくつかの工場を訪れるにつれ、ゴールドラットは非常に不愉快な現実に直面することになった。それまで我が子のように大切に育て誇りにしていたスケジューリング・ソフトがパフォーマンス改善にとって障害になるのだと現実が証明してしまったのだ。『ザ・ゴール』を読み、その内容を実行しただけの工場のほうが、高いお金を払ってOPTを採用したクライアントより高い成果を上げてしまったのだ。それもはるかに短い期間にである。どうしてなのだとゴールドラットは悩んだ。

これがきっかけで、ゴールドラットはOPTの販売を止め、その背後にある考え方をTOC(Theory Of Constraints：制約条件の理論)と名付け、経営コンサルティングに従事するようになったのである。

この件（くだり）に、生産スケジューラの特性が隠れているのではないか、と思います。それは、「OPTでうまくスケジューリングすることができなかった」ことです。

OPTはボトルネック工程の能力を１００％発揮するように、スケジュールします。つまり稼働率１００％でスケジュールします。そうしますと待ち行列現象が起きて、予測不能な待ち時間が発生します。こうなるとスケジュール通りの実行が不可能になります。

待ち行列現象による待ち時間を短くするためには稼働率を下げるしかありません。つまり、稼働率を待ち時間はトレードオフの関係にあります。

しかし、スケジューリングに実行できなくても、ボトルネックの能力を重点に管理することになります。その結果、工場全体の生産性は改善することになります。

前に取り上げたA社の事例によく似てます。

MRP／生産管理パッケージを使っていた受注生産が主体のA社。納期短縮のため、詳細な計画を策定できる生産スケジューラの導入を企画した。導入してみたが、納期の短縮は実現できなかった。むしろ以前よりも納期が長くなるケースが頻発したり、欠品が増えたりした。

コンサルタントの支援を受けてたどり着いた解決策（運用基本方針）は、
「ボトルネック工程は手作業で管理」
「前後の非ボトルネック工程はスケジューラで計画作成」
でした。その結果、

「新たな運用基本方針により、A社の標準納期は標準品が平均30日から平均10日、材料調達を伴う特注品は平均60日から平均40日に短縮できた。」

つまり、稼働率の低い非ボトルネック工程はスケジュールできるが、稼働率の高いボトルネック工程は実行可能なスケジューリングはできないため、手作業で管理することにした、ということです。「『ザ・ゴール』を読み、その内容を実行しただけの工場のほうが、高いお金を払ってOPTを採用したクライアントより高い成果を上げてしまった」話と似ていませんか。

オーダーが次々飛び込み、作業時間等は確率的に変動する環境では、
「ボトルネック工程の稼働率が１００％のとき、待ち時間が予測不能となり、実行可能なスケジューリングを組むことは不可能である」
と言えます。稼働率と待ち時間はトレードオフの関係にあり、この現象から逃れることはできません。

「OPTがなくても、それ以上の改善効果が出る」。ゴールドラットはなぜそうなるのか、理解できていなかったようです。１０年もの年月をかけて開発したOPT。MRPの大雑把なスケジューリングを改善しようとした試みは未達に終わりました。しかし、ゴールドラットの非凡なところは、ポジティブな面、つまり、スケジューラがなくても生産性を改善できることに注目したことです。それがDBRとなり、TOCに発展したわけです。

次回も、生産スケジューラとTOCの関係をみていきます。

DPM研究舎

前回のA社の事例、、。氷山の一角かなぁ～って思う方が多いと思いますが、そうでもありません。私もいろいろな工場をみてきましたが、似たような事例が、、いっぱいありました。思い返せば、今始まった話ではありません。昔から同じようなはなしが延々と、、。生産スケジューラにまつわる社会現象かな。少し、調べてみましょう。

このような問題を分析するのに様々な方法があります。ビッグデータを集めてAIで分析、なんていうのは今流ですね。ここでは、超古い、というか、昔からある定番的方法で分析してみようと思います。弁証法とかTRIZとか、TOCに共通した方法です。いずれも問題の解決を目指しています。簡単に言いますと、問題の根本原因を対立の構図で捉え、その対立を解消する条件を見つけ、それを実現する、という方法です。

では早速、生産スケジューラに関する問題を対立の構図にまとめてみましょう。生産スケジューラの問題に関連する最も基本的な制約的性質は、“固定時間しか扱えない”ことではないかと思います。一方、現実は、ランダムに飛び込むオーダは指数関数的カーブで変動する待ち時間を誘発し、それに作業時間のバラツキが加わります。変動する時間を固定時間でどのように扱えばいいのか、これが課題であり、問題です。これを簡単に、

[固定時間]vs[変動時間]

と表しておきます。この対立が原因で、様々なことが起きますが、大きく分けると、
生産スケジューラは、
イ) 使える
ロ) 妥協して使う
ハ) 使えない

の３つ。

例えば、A社の場合。生産スケジューラの導入はうまくいきませんでした。つまり、（ハ）。その後、“かけ込み寺”に相談して、限定的に使うことで落ち着いたようです（ロ）。経験的に言えば、大部分は“限定的にだましだまし使う（ロ）”か“生産スケジューラ導入失敗（ハ）”に分類されるのではないかと思います。

生産スケジューラがまったく使えないか、というとそうでもありません。ちゃんと使えている工場もあります。どんな工場かと言いますと、代表例は半導体工場。多品種・受注生産ですが、生産スケジューラがないと動かない、というぐらいの活躍です。それは、半導体の製造プロセスは専用装置で構成されており、仕様が決まれば装置での処理時間が決まり、実際の作業もそれほどのズレもなく行われるからです。対立構造でみれば、「変動時間」の変動が非常に小さいために、対立が起きない、起きてもごくわずか、と解釈できます。

生産スケジューラを使ってメリットがあるかどうか、の視点を入れて分けると次のようになるんじゃないか、と。
１、生産スケジューラは必須
２、多少問題はあるが、限定的、部分的に使いこなしている
３、生産スケジューラは使っているがメリットなし
４、まったく使えない

１と２はメリット有。３と４は使うメリットはなし。それぞれ、どれぐらいの割合か。調べてみたんですが、データは見つかりませんでした。私的経験的に、そして無責任にザックリと言えば、生産スケジューラの導入を行った工場（生産スケジューラとかかわりのない工場は含まない）を母数にして上から、１は１割、２は２割、３は３割、４は４割。切りが良すぎますかね。

「革新的生産スケジューリング入門」著者；佐藤知一、2000年4月初版の１８４ページに「スケジューリング問題のパラダイム」という図があります。そこにはこんな説明があります。

“古典スケジューラは、決定論的問題（作業時間等はすべて計画通り）、静的問題（すべてのオーダー情報が事前にそろっている）が前提の静的な最適化。”

“APSは、確率的問題（作業時間等は確率的に変動する）、動的問題（オーダーが次々飛び込んでくる）が前提の動的な適応制御。”
注）APS；Advanced Planning and Scheduling

対立図に戻ります。

[固定時間]vs[変動時間]

ここでの[固定時間]とは、上記の説明にある“古典スケジューラ”の特徴です。それがAPSになると[動的な適応制御]になります。そうなるともはや対立は消え、問題は完璧に解決されることになります。

この本を読んだとき、「生産スケジューラ問題はそのうち解決するんだ」と思いました。

あれから、２０年！　IoT、AI、第４次産業革命だとすっかり世の中変わりました。APSもさぞかし進化したかな、と思って、「APS　先進的スケジューリングで生産の全体最適を目指せ！」２００１年１２月の著者、西岡靖之氏に聞いてみました。返事は、
～～～～～
ＡＰＳについては、あまり進歩はないようですね。
特に確率論的なアプローチはあまり聞きません。
～～～～～

佐藤知一氏には、APSが「動的な適応制御」が可能かどうかの確認のため、次の質問をしてみました。
＝＝＝＝＝
「確率的に変動する作業時間でスケジュールした場合、作業の開始時刻や終了時刻はどのようになるのでしょうか」
＝＝＝＝＝

残念ながら、質問に対する答えはどこにもありません。「適切な生産マネジメント」とか「場合によります」とか。末尾にはこんなフレーズで締めくくられていました。
＝＝＝＝＝
「学んで思わざるはすなわち暗し、思うて学ばざればすなわち危うし」ーー
＝＝＝＝＝
すっかり、はぐらかされてしまいました。わかったことは、APSは２０年たっても“古典スケジューラ”のままだった、こと。APSって、Advanced Planning and Schedulingではなくて、Ancient Planning and Schedulingじゃないでしょうか。

[固定時間]対[変動時間]の対立構造は今も健在です。この対立が引き起こす現象をみてみましたが、注意深くみると、少し違った現象も起きています。A社の事例でもそれらしき影が垣間見られます。A社とはどんな会社か、記事の著者に聞いてみました。
―――――
「スケジューラ以前に現場がシステムからの指示を無視しして自分たちの都合で製造順序を変えて製造しているという状況」
―――――

佐藤知一氏のメールにはこんな説明が、
＝＝＝＝＝
「標準作業時間の概念も存在せず、作業時間の実績値をとる仕組みもないような管理レベルの現場に、生産スケジューラを入れる価値がないことは、ほとんど自明だと思います。」
＝＝＝＝＝

「管理レベルの低い工場」に生産スケジューラを導入する話です。対立構造からみると、管理レベルは低く、作業時間はバラツキ、工程管理はなっていない、、ということですので「生産スケジューラは使えない」（上記分類４）、となる単純なケースのはずなんですが、、。

私もいろいろな工場をみてきました。「管理レベルの低い工場」が多かったように思います。でも生産スケジューラは入っている。しかし、うまく動いているところはほとんどなし。眠ったままになっているんです。「なんで、スケジューラを入れたんですか？」と聞くと、こんな応えが、、、。

「生産管理、工程管理などの管理体制を構築するためには、マネジメントツールである生産スケジューラを導入する必要がある、と言われた」

んだそうです。うまく動かないことがわかると、

「御社は管理うんぬん以前で、生産スケジューラを使いこなせるレベルにはありません」

と言われておしまい、だったとのこと。

生産スケジューラベンダーの“どのような生産体制でも対応できます”的な誇大広告、「生産スケジューラはマネジメントツールです」などのセールストーク。固定時間しか扱えない弱点を覆い隠し、「生産スケジューラで管理体制の骨組みをつくることができます」とたたみかける。無垢な中小企業を落とすのにたいした時間は要しません。うまくいかないことはわかっておりますので、ちゃんと、後始末の言葉も用意されています。「御社は管理うんぬん以前で、、、」。

生産スケジューラの導入がうまくいかなかったA社、代理店に相談すると、「問題は生産スケジューラではなくA社の業務にあるので、手の打ちようがない」といわれて、、、。

「管理レベルの低い工場」は生産スケジューラベンダーのお得意さん？

DPM研究舎

先月、ある生産スケジューラ・ベンダーから「生産スケジューラソフトウェア代理店募集」のメールが届きました。代理店をやるつもりはありませんでしたが、最新の生産スケジューラってどんなものかな、何か新しい機能でも加わったのかな、と多少の期待もあって、ちょっと、メールのやり取りをしてみました。メールの回数が増えるにつれ、的外れな応えが多くなり、がっかり。何も変わっていませんでした。IT技術が飛躍的に進歩しても、その技術を取り入れることもなく、生産スケジューラは“発達障害”を患っているようです。

そんな折、Webをググっていたら、こんなのが目に留まりました。

「AIブームで脚光浴びる生産スケジューラ、ベンダーの宣伝に踊らされるな」（日経コンピュータ 2017年6月8日号）https://active.nikkeibp.co.jp/atclact/active/17/120800203/121100005/

この記事を手掛かりに、生産スケジューラが“化石化”する根本問題に迫ってみたいと思います。

記事の要点をまとめますと、次のようです。

[現状]
A社はMRP／生産管理パッケージを使っていた。金属製品の受注生産を主体とするA社では、見込み生産を前提とするMRPのロジックは、適合しにくい。このため生産計画機能は有効に使われておらず、作業指示書の発行、生産実績管理が中心だった。

[スケジューラ導入]
生産スケジューラの導入を考え始めたきっかけは、営業部門からの納期改善要求である。納期短縮のため、詳細な計画を策定できる生産スケジューラの導入を企画した。 業務知識がある代理店に導入のサポートを依頼し、比較的スムーズに導入自体は完了した。

[導入結果]
導入した生産スケジューラを使ってみたものの、期待されたような納期の短縮は実現できなかった。むしろ以前よりも納期が長くなるケースが頻発したり、欠品が増えたりした。
何とかならないかと代理店に相談すると、「問題は生産スケジューラではなくA社の業務にあるので、手の打ちようがない」という回答であった。

A社の事例に似た話は、よく聞きます。簡単に、次のようにまとめてみました。

[現状]
受注生産が主体のA社は、MRP／生産管理パッケージを使っていた。

[スケジューラ導入]
納期短縮のため、詳細な計画を策定できる生産スケジューラの導入を企画した。

[導入結果]
納期の短縮は実現できなかった。むしろ以前よりも納期が長くなるケースが頻発したり、欠品が増えたりした。

「納期短縮のため生産スケジューラを導入したら、かえって納期が長くなり、欠品が増えた」ということですね。はたからみれば、“笑い話”なんですが、生産スケジューラに関するこの手の話って、昔からあって、減るどころか、増えてるんじゃないか、という感じがします。

「前よりも悪くなった」という目前の問題を解決する手っ取り早い方法は、元に戻すこと。前の状態の方が良かったわけですから、、。これが最も簡単な方法、、。

医者がくすりを処方して、症状が悪化したら、そのくすり、すぐにやめるんじゃないでしょうか。常識だと思うんですがね、、。

ところが、生産スケジューラの場合は、簡単にそうはいかないようなんです。

“何とかならないかと代理店に相談すると、「問題は生産スケジューラではなくA社の業務にあるので、手の打ちようがない」という回答であった。”

とのこと。このあたりが普通の商品と違うんですね。普通の商品だったら、使ってみて使えなかったら、“返品”してお金を返してもらうとか、別の新品と交換するとか、ですよ。生産スケジューラに関しては、導入した顧客の方に問題があるんですね。

というわけで、A社で解決策を模索することに。何が原因なのか。問題分析に取り組みました。

[問題原因分析]
納期を短縮するために工場全体で何をするべきかを、原点に戻って検討し直すことにした。
＊毎月1回、部署横断の検討会を開催。
＊検討会では最初に、なぜ生産スケジューラが計画した通りに生産できないかを議論した。各部署からは次のような意見が上がった。
（1）A社の製造方法では、標準加工時間と実加工時間を一致させることが難しい
（2）機械のチョコ停やセットアップ要員の調整などのため、生産計画通りに工程が進まないことが多くある
（3）工程計画立案のベースにしているMRPのリードタイムは日単位でしか設定できず、時間単位の実用的な生産計画が作れない
（4）安全在庫を持てる標準品と、材料調達を伴う特注品のうちどちらの納期対応を優先させるのかはっきりしない
（5）製造現場は指示書の指示日はあてにならないと考えており、前工程から来た順に製造している

現場の様子がよくわかりますね。で、A社のとった“解決策”は、、。

[解決策]
 何度もPDCAサイクルを試行しながらたどりついたA社の生産スケジューラの運用基本方針は、納期遅れの原因になりがちな「ネック工程」を定め、そこは自動ではなく手作業で負荷を調整する。
 ネック工程より後の工程の完了日と、前の工程での着手日はそれぞれ生産スケジューラで自動計算し、納期を決定する。実際の生産では、ネック工程以降は工程に到着した順番で製造するようにする。
 従来は生産管理システムが計画したリードタイムを基に最初の工程の開始日を設定していたが、ネック工程の負荷オーバーのため納期遅れが頻発していた。そこで、ネック工程は人間が手作業できめ細かく管理することで、影響を最小限に抑えるようにした。ネック工程に変更があれば、前後の生産計画は生産スケジューラで自動的に組み直す。

解決策の要点は、
「ネック工程は手作業で管理し、前後の非ネック工程はスケジューラで計画作成」
ということでしょうか。

ちょっとだけ、じっくり、考えてみましょう。
「納期短縮のため、詳細な計画を策定できる生産スケジューラの導入」を決めたんですよね。つまり、納期の主要部分である生産リードタイムを短縮するために、生産スケジューラを導入した。生産リードタイムの中で一番長い時間がかかるのは、仕掛が滞留するネック工程。生産リードタイムを短縮するためには、ネック工程のスケジュールを詳細に組む必要がある。

ところが、解決策は、
「ネック工程は手作業で管理」。
非ネック工程は、
「前後の非ネック工程はスケジューラで計画作成」。

「実際の生産では、ネック工程以降は工程に到着した順番で製造するようにする」のであれば、生産スケジューラはいりませんよね。非ネック工程は仕掛が滞留する時間は短いので、生産スケジューラを使ったからといって、生産リードタイムの短縮にどれほど有効か、はっきりしませんね。ですから、ネック工程前の非ネック工程も工程に到着した順番で製造すればいいんじゃないでしょうか。

簡単にいうと、ネック工程も非ネック工程も生産スケジューラはいらない、ということになりませんか。

「新たな運用基本方針により、A社の標準納期は標準品が平均30日から平均10日、材料調達を伴う特注品は平均60日から平均40日に短縮できた。」

生産スケジューラ導入後の納期が基準なのか、導入前の納期が基準なのか、はっきりしませんが、とりあえず、良い結果が出て、“めでたし、めでたし”としておきましょう。次回、もっと掘り下げて考えてみたいと思います。

https://www.tocken.com

Prediction Oneをいじくりまわしてみようと思います。サンプルデータがいろいろあります。その中から、研究テーマに合うのは、

「出荷数予測による生産計画の精度向上」

かな。これを使って、遊んでみましょう。データの概要ですが、表１のように、モデルがMM2、YH15、NK5の３つ。2016年2月から2019年9月まで、月ごとの出荷数があります。3カ月前、4カ月前、5カ月前の出荷数と発売からの経過月数の項目もあります。

表１　サンプルデータ

モデルごとの出荷数をグラフで示しますと図１のようになります。

図1　出荷数推移

このデータを実出荷数と考えてみます。サンプルデータのモデルMM2を使ってみます。これまでは、過去のデータで将来の出荷数を予測するのに、エクセルを使うことが多かったのではないかとおもいます。いくつかのFORECAST.□□□というエクセル関数があります。説明では、“指数三重平滑化などの機械学習アルゴリズム”を使って予測しているとのこと。最近のバージョンでは、もっと簡単で、「データ」→「予測シート」とクリックするだけで予測結果が得られます。

ちょっとやってみましょうか。表２のようにデータ範囲を選択します。

表２　データ選択

次に「データ」→「予測シート」をクリックします。

図２　「データ」、「予約シート」

図３に示すような予測結果が得られます。予測期間とか信頼範囲なんかも設定できます。

図３　予測結果

モデルMM2のデータを使って、出荷数を予測してみます。
・2016年2月～2017年1月のデータで2017年2月～6月を予測
・2016年2月～2018年1月のデータで2018年2月～6月を予測
・2016年2月～2019年1月のデータで2019年2月～9月を予測

図４に予測結果を示します。信頼区間は95％です。

図４　MM2の予測結果。灰色矢印は使用データの範囲。

予測期間が左から数えて１番目と２番目は、「こんなもんかなぁ～」という感じですが、３番目は予測と実出荷数の乖離が大きいようです。でも、全体の傾向からみれば、合っているような気もしますが、、。使うデータで予測結果に差が出てくるようで、これって、当り前といえば当たり前、でしょうか。

では、Prediction Oneで予測してみましょう。Prediction Oneのデモでは先々3カ月の予測設定になっていますので、そのまま先々3カ月を予測することにします。また、Prediction Oneのデモでは3つのモデルを同時に処理していますので、これもそのままの条件にしておきます。但し、予測結果はMM2だけみてみます。

先ず、2016年2月～2017年1月のデータで2017年2月～6月を予測しようとしましたが、
“データ数が少ないため、学習処理が実行できません”
というアラームが出てしまいました。が、
・2016年2月～2018年1月のデータで2018年2月～6月を予測
・2016年2月～2019年1月のデータで2019年2月～9月を予測
は、結果が出ました。予測結果を図５に示します（矢印で示した赤線）。

図５　Prediction Oneの予測結果

Prediction Oneの予測結果は、実出荷数よりも、また、エクセルの予測よりも高く出ました。実出荷数と比べれば、左から２番目は差が大きくなり、３番目は差が小さくなりました。単純な結果ではないようです。

ちょっと、エクセルに戻ります。１２カ月のデータではデータ数が少なくて結果が出せませんでしたが、エクセルでは予測できますので、
・2016年2月～2017年1月のデータで2017年2月～6月を予測
・2017年2月～2018年1月のデータで2018年2月～6月を予測
・2018年2月～2019年1月のデータで2019年2月～9月を予測
をしてみました。その結果を図６に示します。

図６　過去12カ月のデータで予測

左から３番目の予測は、過去１２カ月のデータを使った予測が過去３６カ月のデータを使った場合やPrediction Oneの予測よりも実出荷数に合っているようです。図４と図６は、どちらもエクセル。アルゴリズムは同じですが、使うデータ数（範囲）の違いで、予測結果もだいぶ違うようです。実務でこれをどう使うかは、また別の課題になるんでしょうね。

Prediction Oneで使うデータについて、みておきましょう。エクセルでは使いませんが、Prediction Oneでは、以下のデータを使いました。
・発売からの経過月数
・５か月前の出荷数
・4か月前の出荷数
・３か月前の出荷数
どのデータも入手に問題はないと思いますが、予測にどのようにかかわっているんでしょうね。説明では、「Prediction Oneはソニーが開発しているDeep Learningのオープンソースソフトウェア、Neural Network Librariesを利用しています」とのこと。勉強すればわかるようですが、、。

これまでの統計理論をベースにした予測に加え、AIを利用した予測ができるようになってきました。予測だけではなく、AIは社会のあらゆるところで使える可能性を秘めています。当然、生産管理や在庫管理にも使えそうです。今回、Prediction Oneをいじってみましたが、決して、わかりやすい結果は得られませんでした。だから、AIはダメだ！　なんて言うつもりは、毛頭ありません。

AIを使いこなすためには、AIを上回る“人知”が必要なのかもしれません。引き続き、AIの動きを注視していきたいと思います。

AIが生産管理や在庫管理にどのような影響を及ぼすのか。先に、日立の取組をみてみました。要点は、

鉄道の運行管理などの数理最適化技術（所有技術）とAI制約プログラミング（新技術）を融合し、熟練者独自の計画パターンを機械学習させ、
＊自動的に最適な生産計画の立案
＊需要変動など日々の環境変化にも柔軟に生産計画の組み替えを可能とする

と。しかしこれは、「最適な生産計画」が「最適な生産実現」にはつながらないことが多く、実用的な視点からみれば、限定的な利用しか期待できず、“イマイチ”。

今回は、ソニーの開発した“Prediction One”に注目してみたいと思います。

https://predictionone.sony.biz/

Websiteから転記します。

Prediction Oneは、データさえ用意すれば、数クリックで高度な予測分析を自動的に実行できるソフトウェアです。必ずしも専門スキルを必要とせずに予測分析ができ、ビジネスに活用できます。専門家の方にとっては、予測モデルの構築作業が飛躍的に効率化します。

AIによる予測分析は、これまでは、ニューラルネットワーク、勾配ブースティング、クロスエントロピー、二乗誤差、損失関数、、、なんていう言葉でなんとなく理解していました。理解したといっても、概念だけ。実際に、これらの考え方を応用して予測分析を行うことはできませんし、やる気も起きません。専門性が高すぎて、手も足も出ず、、。

で、Prediction One。しろうとにも使える、みたい。しかも“無料”で。

さっそく、ダウンロードしてみました。

先ずはチュートリアルを開いてみました。事例がいくつかあります。
「顧客行動予測に基づいたターゲティング」
「退会予測による退会の削減」
・・・・
・・・・

ずーっとみていきますと、興味のある事例が出てきました。
「来客数予測による仕入れ量決定」
「出荷数予測による生産計画の精度向上」
「機器の故障予測による故障の未然防止」

「来客数予測による仕入れ量決定」を開いてみます。こんなことが書いてあります。

＊過去の来客数の実績データに基づき、来客数を予測する

＊予測分析の手順～学習と予測～

＊学習用データ
予測分析では、下記のような、来客数の実績データを基にした学習用データを用いて、来客数を予測するモデルを作成する。データは2018/8/1～2019/9/15の407日分。

＊予測用データ
作成した予測モデルを利用して、来週１週間（2019/9/16～9/23）の来客数を予測する。

＊予測結果ファイル
予測結果は以下のような形式で出力される（オプション設定によって形式は異なる）。
来週１週間（2019/9/16～9/23）の来客数を予測。

おもしろそうですね。操作も簡単そうなので、実際の数値を入れて、いじりまわしてみたくなりました。

https://www.tocken.com/DPM研究舎へ戻る

今回も、2019年4月1日発行された在庫管理の本についての論評です。この書の主張の根幹みたいな部分に迫ってみたいと思います。それは何かといいますと、“「必要なものを必要なときに必要なだけ」発注することができる不定期不定量発注法がお勧めだ”、という主張です。本書からその主張の骨子を拾ってみます。

p.73
▶▶ 「必要なものを必要なときに必要なだけ」発注する
需要が変動するからこそ在庫管理が必要です。定期不定量発注では先の見通しは完全に読めないことから、担当者の思惑が入り込み、在庫の過剰や絞り込みすぎが問題になる可能性がありました。
不定期不定量発注法では、思惑が入り込む問題はあまり心配いりません。急に出荷が増えて在庫が減ってしまったら、慌てることなく発注すればよいだけです。逆に、出荷が減って在庫があまりがちという状況になれば、発注しなければよいのです。定期不定量発注法に比べて、発注担当者のストレスは少ないと言えそうです。

p.76
▶▶　日数で換算する
—-「明日、出荷するために必要な量」を計算するためには、在庫の数量を「日数」に換算して判断します。まず、過去の出荷実績を日単位で収集します。—-２～３年、販売し続けるものであれば、過去１年程度の期間について出荷データを収集し、出荷があった日をベースに「1日あたり平均出荷量」を算出します。

p.76~77
▶▶　需要の変動をみる
—-２～４週間程度の期間で平均出荷量を求め、出荷があるたびに、その時点から過去２～４週間の平均出荷量を求めるのです。——出荷があるたびに平均出荷量を求めるので、計算の対象が移動していきます。このような計算によって求められる平均値を移動平均といいます。—–

p.82
▶▶　毎日「発注点チェック」を行う
発注のタイミングが来ているかどうかは、毎日、出荷があるたびに計算してチェックします。需要は変動するわけですから、いつ発注すべきか、状況は毎日変化する可能性があると考えるからです。これを「発注点チェック」と呼ぶことにしましょう。発注点チェックは、以下の手順で行います。
①出荷があるたびに「在庫量÷1日あたり平均出荷量＝出荷対応日数」の計算を行う
②出荷対応日数とリードタイム日数＋安全在庫日数を比較する
③出荷対応日数がリードタイム日数＋安全在庫日数を下回ったら、発注する

不定期不定量発注法とは、発注タイミングも発注量も不定で、よく言えば、“適時適量発注”だが、悪く言えば、“行き当たりばったり発注”、と巷の評価は定まっていません。本書の主張は前者。本当に“適時”であり“適量”なのか。チェックしてみましょう。

本書が主張する不定期不定量発注法の基本的なメカニズムを一般的な不定期定量発注法（定量発注点法）との比較を通して調べてみます。簡単な条件で考えてみます。需要（出荷量）の母集団を
＊1日あたり平均出荷量は10個、標準偏差は2個
の正規分布に従うとして、変わらないものとします。リードタイム日数は3日（固定）とします。

安全在庫は、安全係数を2として、
安全在庫=安全係数×√リードタイム日数×1日あたり出荷量標準偏差＝2×√3×2≅6.9
で、7個となり、発注点となる在庫数は、
発注点在庫数＝平均出荷量＋安全在庫＝10（個/日）×3（日）＋7（個）＝37（個）
で、37個となります。定量発注量は60（個）としておきましょう。

次に、本書が主張する不定期不定量発注法ではどうなるか、調べてみます。

先ず、“1日あたり平均出荷量”を計算します。本書の説明では何日間かの“移動平均”となっています。“移動平均”について、ちょっと、コメントしておきます。移動平均算出の日数をｎ日とすると、平均は母集団の平均と同じ、標準偏差は、母集団の標準偏差をσとすればσ⁄√nとなります。

数値を入れてみましょう。母集団（1日あたり平均出荷量）の標準偏差は2個ですので、n=10の移動平均の標準偏差は、
(2（個）)/√10≅0.63（個）
となります。 “1日あたり平均出荷量”が、２σでみれば、8.74（個）～11.26（個）の範囲にバラツクとみることもできます。「発注点チェック」をしてみます。

①出荷があるたびに「在庫量÷1日あたり平均出荷量＝出荷対応日数」の計算を行う

①の計算に従えば、同じ“在庫量”でも“1日あたり平均出荷量”がバラツキますので、“出荷対応日数”もバラツクことになります。“出荷量の母集団は変わらない”という条件でも“出荷対応日数”が変動することにご留意ください。

②出荷対応日数とリードタイム日数＋安全在庫日数を比較する

“安全在庫日数”は安全在庫を日数換算したもののようです。安全在庫は、先に計算したように７個ですから、切り上げて1日となるんでしょうか。“リードタイム日数”は3日ですから、“リードタイム日数＋安全在庫日数”は4日。

③出荷対応日数がリードタイム日数＋安全在庫日数を下回ったら、発注する

わかりやすいように、在庫量がどうなったとき発注するのか、という視点でみてみます。①～③から、次の式が導き出せます。
在庫量<(リードタイム日数+安全在庫日数)×1日あたり平均出荷量 リードタイム日数；3日、安全在庫日数；1日、１日あたり平均出荷量は8.74（個/日）～11.26（個/日）を代入すると、 在庫量<(3+1)×8.74～(3+1)×11.26　→　在庫量＜35（個）～45（個） つまり、発注点が35（個）～45（個）の範囲で変動することになります。一般的な発注点方式では発注点が37個で一定ですが、本書の主張する不定期不定量発注法では発注点がランダムに変動するということになります。 一般の不定期定量発注法は、発注量は予め決められています。本書が主張する不定期不定量発注法では、発注量は次のようになります。

P83
1日あたり平均出荷量×在庫日数＝発注量

“在庫日数”は予め決めた日数ですが“1日あたり平均出荷量”が掛けられていますので、発注量も毎回変動することになります。定量発注量の60個を“在庫日数”に変換しますと、6日となり、発注量は、 6（日）×8.74（個/日）～6（日）×11.26（個/日）≅53（個）～68（個） と変動することになります。

一般的な不定期定量発注法と不定期不定量発注法の比較をまとめますと、次のようになります。

不定期定量発注法 不定期不定量発注法 発注点 37（個）一定 35（個）～45（個） 発注量 60（個）一定 53（個）～68（個） 不定期不定量発注法は、その名の通り、“発注点”も“発注量”も変動します。しかし、そのことによって、同じサービス率を保つための在庫量が増えてしまいます。“発注点”の変動は安全在庫を増やし、“発注量”の変動は在庫量を増やします。下図を参照ください。

出荷があるごとに“1日あたり平均出荷量”を計算し、“その時の在庫量”を調べ、“出荷対応日数”を計算し、それを“リードタイム日数＋安全在庫日数”と比較し、“出荷対応日数”が小さければ“1日あたり平均出荷量×在庫日数＝発注量”を計算し“発注する”。 一方、一般的な不定期定量発注法は、在庫が発注点以下になったとき、予め決めた定量を発注する、これだけ。簡単です。 本書の主張する不定期不定量発注法。出荷ごとに毎回「発注点チェック」なる退屈な計算をして手間暇かけ、結果、在庫量が増える。一般的な不定期定量発注法と比べて、良いところはどこにも見当たりません。にもかかわらず、ご丁寧に、下記の説明まであります。筆者らは在庫管理の“専門家”？。レベルの低さに“唖然”とするしかありません。

p.67
▶▶　定量発注法の特徴 不定期定量発注法のほうは、今後も使用するという会社はあるでしょう。ただし、需要の変動への対応力は低いと言わざるを得ません。発注時期を不定期にすることによって、多少、需要の変動に対応しているという程度です。

p.70
不定期定量発注法では欠品や過剰が起こりやすく、しかも、その状態にはなかなか気づくことができません。この方法をあまりお進めしない理由は、まさにそこにあります。適用するとしても、在庫品のすべてをこの方法で管理することは、危険なことといわざるを得ません。

DPM研究舎

2019年4月1日発行された在庫管理の本について論評をしております。前回は、「間欠需要」では在庫過多になるので、在庫を減らす方法として、
①出荷頻度を織り込んだ必要量計算を行う
②出荷頻度が落ちてきたら、出荷量の計算期間を延ばしていく
の2つがある、という説明。その真贋を調べてみました。②はまったくの“いかさま”。そちらに気を取られ、①についてはスルーしてしまいましたが、

５日間の必要量＝1日あたり出荷予測×５日間の出荷日数予測

の式の

５日間の出荷日数予測

は、「出荷確率」を意味しているのではないか、ということに気が付きました。

「出荷確率」につきましては “ものづくり徒然草”の
No.87　安全在庫の計算；「出荷確率」を考慮するのはなぜ？
No.88　ポアッソン分布が暴く“出荷確率”の虚
に愚見をサラッと載せてありますので、参考にご覧頂ければ、と思います。“出荷確率”という考え方も、実は、統計学を知らない素人が持ち出した“珍説”、、、のようでありまして。

さて、今回は何を取り上げましょうか。p.10~p.13に　1-1 在庫実態を「見える化」する　に注目してみましょう。（茶色部分は本書より抜粋）

▶▶「在庫散布図」で在庫の実態をみる

アイテム別に在庫の実態を把握するための有効な手法として「在庫散布図」があります。図1-1は、在庫散布図の一例を示しています。まず、在庫拠点を1ヶ所選んでください。次に、その拠点における以下の3つの数字を用意してください。必要なのは、その拠点に在庫してあるすべてのアイテムの数字です。

①アイテムごとの月間出荷量
②アイテムごとの月間出荷日数
③アイテムごとの月末在庫量

これらの数字が取れたら、以下の計算を行います。
④1日あたりの平均出荷量＝月間出荷量（①）÷月間出荷日数（②）
⑤出荷対応日数＝月末在庫量（③）÷1日あたり平均出荷量（④）

さて、ここまで計算できたら、⑤出荷対応日数と②月間出荷日数という2つの数字を使って、在庫散布図を作ります。図1-1を見てください。 （本書の図とは異なるデータですが、イメージは似せてあります）

図1-1　在庫散布図

縦軸に「出荷対応日数」、横軸に「出荷日数」を取っています。出荷対応日数というのは、「今ある在庫で、あと何日分の出荷に対応できるか」という数字です。たとえば、出荷対応日数が10日なら、あと10日間の出荷に対応できるということになります。

横軸の出荷日数というのは、月間で何日出荷があったかということです。出荷日数の最大値は、その月の稼働日数になります。

在庫散布図へのプロットは、アイテム別に出荷対応日数と出荷日数がぶつかるところにマークをしていきます。

▶▶在庫散布図からわかること

図の左上の、出荷対応日数100日にプロットされているアイテムがあります。このアイテムは出荷日数が1日ですから、月に1回しか出荷がないということです。そして、今の出荷状況なら、今の在庫量はあと100日分あるということです。出荷が月1回ですから、実質100か月分の在庫だということです。

出荷対応日数が、０日に限りなく接近してプロットされているアイテムも少なくありません。これは、欠品の危険があります。在庫が少なすぎるのです。

この説明を読んでなんとなくわかったような気になられた方も多いのではないかと思います。月間出荷量、月間出荷日数、月末在庫量から出荷対応日数を計算し、出荷対応日数で在庫量の適正さを判断するということなんですが、、。

でも、ですね、、。きちんと調べてみると、欠陥だらけで、使いものにはなりません。その理由のいくつかを上げますと、、

[1] 図1-1をご覧ください。出荷日数が０（グラフの一番左端）には出荷対応日数のプロットはありません。月間出荷日数が０だと分母が０となるため、1日あたり平均出荷量の計算ができないんですよね。だから出荷対応日数も計算できない。でも、現実には２～３カ月に1回しか出荷がないとか、半年に1回の出荷とかいうアイテムって、たくさんありますよ。「出荷がないのに在庫がある」。これって、在庫管理では忌々しき状態なんですがね。それを無視しちゃってんじゃないでしょうか。

[2]　在庫量は出荷時に減少し、入庫時に増加して変動する。ですから在庫量を捉えるためには変動の範囲を捉えなきゃいけません。一般的には、平均とか分散、最少、最大などで変動範囲をつかまえます。月末とかの一時期のデータだけではとらえられませんよね。さらに、経理では月末の在庫残高をみますから、それをできるだけ少なくしようとして、月末出荷推奨・月末入庫抑制に走る、などの影響があって、ますます乱高下するわけです。月末在庫量だけで在庫量全体のバラツキを捉えることはできませんね。

[3]　①～⑤の式をみても、補充発注から入庫までの調達リードタイム（納入リードタイム）をまったく考慮していませんね。在庫量を決定する最も重要な要素ですよ、調達リードタイムは。原理的に破綻してますね。

[4]　 調達リードタイム＞発注間隔のとき、必ず発注残が生じます。前に発注したものが入庫される前に次の発注が行われますので、前に発注したものは発注残状態になる。在庫管理では“常識”。しかし、①～⑤の式の中に発注残はなし。これだと在庫循環のメカニズムを正しく捉えることができませんので、間違った判断を助長することになります。

[5]　需要は受注件数（出荷件数）と1件当りの受注数量（出荷数量）で決まります。受注即出荷とすれば、出荷日数は需要に対して従属的に決まります。“出荷件数”と“出荷日数”は、在庫循環のメカニズムの中では、全然違うんです。例えば、出荷可能日数28日のとき、出荷日数と出荷件数との関係は図1-2のようになります。直線的な関係ならまだしも、非直線的な関係なので、在庫量の計算に出荷日数を使うと間違った答えが出てきます。

図1-2　出荷日数と出荷件数の関係の一例

在庫管理では、[1]~[5]はいずれも致命的な欠陥です。これで“在庫実態を「見える化」する”ことができるのでしょうか？　見えたとしても、“虚像”か“歪曲された像”しか見えないのでは、、。

DPM研究舎へ