米国の大学生向けの教科書的な本は、「生産スケジューリングは絶対に無理なのでやめるように」と明言している。
「Asprova解体新書」のプロローグ（13ページ）にある記述です。「教科書的な本」とはFactory Physicsではないかと思います。読んでみると、
生産スケジューラ（by computer）が「処理時間固定（or決定）」「処理ジョッブ固定（or決定）」を条件にしているのに対して、「処理時間のバラツキ」や「ランダムなジョブの投入」が不可避な現実の生産ラインでは、この物理的条件の違いを解消する策は存在せず、従って、
「生産スケジューラは実行可能なスケジュールを生成できない」
と説明されています。「生産スケジューリングは絶対に無理なのでやめるように」の裏付けは取れました。わざわざネガティブな説明を最初に出したからには、この問題に対する“答え”みたいなものが「Asprova解体新書」に書いてあるのでは、、と微かに期待しました。
Factory Physicsが指摘する問題がどのように取り上げられているのか、それに対する対策らしきものがあるかどうか、「Asprova解体新書」のすみずみまでみてみました。が、、、何もありませんでした、、。・・・いやいや、ありましたよ。びっくりするようなことが、、。
巻末（230ページ）に、
「査読を快く引き受けてくれました佐藤知一氏、本間峰一氏、勝呂隆男氏に感謝いたします」
と。「Asprova解体新書」の内容に同意してバックアップしている専門家がいるんです。
実は、ちょっと古い話ですが、こんなことがありました。
きっかけは2冊の本。一冊目は、
「革新的生産スケジューリング入門」佐藤知一氏著、2000年4月15日発行
読んだのは、2000年中頃だったでしょうか。APS（Advanced Planning & Scheduling）で盛り上がっていた頃です。APSは“（オーダがランダムに次々に飛び込んでくる）動的問題”と“（作業時間等が変動する）確率的問題”に対応するスケジューリング方法だ、というあたりに興味を持ちました。興味を持ったといっても、疑いの目でですが、、。
もう一冊は、
「“JIT生産”を卒業するための本」生産革新フォーラム編著（メンバー；佐藤知一氏、本間峰一氏他5名）、2011年12月30日発行
JITに関する本は、それまでに数え切れないほど出版されています。様々、読みました。理論に重点を置いたもの、現場のやる気を主題にしたもの、導入成功事例集的なもの、、などなど。「“JIT生産”を卒業するための本」の中身は、正直に言えば、何を言いたいのかよくわからない、という感じでした。
その頃はTOCにどっぷり、でした。TOCも突き詰めていくと、つじつまの合わないところが目立つようになってきました。
＊ボトルネックだけをスケジューリングすればよいというOPTというソフトの販売をすぐにやめたのはなぜか。
＊DBR（Drum Buffer Rope）からスケジューリングをしないS-DBR（Simplified-DBR）にグレードダウンしたのはなぜか。
ゴールドラット、エリーシュラーゲンハイム（S-DBRの提唱者）、オーデットコーエン（ゴールドラットスクール校長）らと話しているうちに、だんだんわかってきました。
そして、Factory Physicsを一通り読んで、“生産スケジューラ（APS）で動的問題も確率的問題も原理的に解けない”ということがわかってきました。
生産革新フォーラムというグループがあります。代表幹事が本間峰一氏、メンバーに佐藤知一氏他「“JIT生産”を卒業するための本」の共同著者がおります。その会合で、2014年7月16日、講演を行い、次のような話をしました。
＊稼働率を高くすると急激に待ち時間が長くなること
＊その待ち時間を挽回することはできず、工程を経るごとに累積され生産リードタイムは長くなっていくこと
固定時間で作成したスケジューリングでは、この待ち時間は計算されませんので、生産スケジューラから出力されたスケジュールと待ち時間を含むスケジュールとはかなりの差が出てきて、ほとんどの場合、“実行不可能”となる、、というような話を交えて、、。
本間峰一氏の反応は、“ほとんど理解できていない”という感じでした。しかし、佐藤知一氏の反応には手ごたえを感じました。後日、彼のBlogでも紹介しています。
https://brevis.exblog.jp/22236990/
内容に違和感はありません。“待ち行列現象”はご理解いただけたと感じました。
あれから6年ほどたちました。“待ち行列現象”を生産スケジューリングではどのように捉えているのか、佐藤知一氏にメールしてみました（2020年1月）。
私が知りたかったのは、生産スケジューラで実行可能なスケジュールを生成する条件は何か、ということでした。どのようなやり取りがあったのか、彼の説明を引用（水色部分）しながらその要点を列記してみます。先ずは、こんな説明から、、
① 標準作業時間の概念も存在せず、作業時間の実績値をとる仕組みもないような管理レベルの現場に、生産スケジューラを入れる価値がないことは、ほとんど自明だと思います。
管理レベルが低い現場では生産スケジューラを入れる価値なしとのこと。管理レベルについてもう少し具体的に知りたかったので、生産スケジューラが実行可能なスケジュールを生成する“実用的な条件”は何か、と尋ねました。次のような説明です。
② 主要な工程における実作業時間と品質（不良率）が、工場の管理目的から見て受容可能な範囲の精度で、推算できること
具体性はないので、工学的な表現でお応えいただけないかと再三お願いしました。が、残念ながら、“文学的”な説明しかいただけませんでした。待ち時間を計算できるかどうかについては、次のような説明がありました。
③ 固定リードタイムで無限負荷計画のMRPは、たしかに使えませんが、現在の生産スケジューラは実作業時間のみ固定で、待ち時間は自分で計算します。
条件付きではありますが、待ち時間は計算できるとの説明です。彼の実務の説明もありました。
④ わたしの業界では、計画策定時に、作業期間が確率的に変動するようなスケジューラを、必要に応じて各社で使っています。それにより、作業のクリティカリティを評価してモニタリングの方法を決めたり、フロート（TOC風に言えばタイム・バッファー）の配置を決めたりするのです。
作業時間が変動してもスケジューラは使えますよ、という説明です。そして、
⑤ 生産スケジューラは一種のシミュレータです。
と、生産スケジューラはシミュレータとしても使えると主張しています。こんな説明もありました。
⑥ 生産スケジューラは、マネジメントのためのツールです。管理目的も受容可能性の判断も、いずれも価値判断を含むマネジメントの問題であって、純粋な技術論ではありません。
他にも、おもしろい説明がいくつかあるんですが、今回の意見交換を通して感じたことをとりあえず、私なりにまとめると次のようになります。
～～まとめ～～
「マネジメント」を“生産管理”と置き換えて、生産スケジューラと生産管理の関係について考えてみたいと思います。生産管理と言えば初めに出てくる言葉は“生産計画”。生産計画の出来不出来が生産管理のレベルを決めるとよく言われます。もっと一般的に言っても、マネジメント・サイクルの基本はPDCA。その最初がPlan、計画です。ですから、生産管理の一丁目一番地が生産計画だ、というのが現在の主流の考え方ではないかと思います。
生産計画が現場に降りてくると生産スケジュールになります。詳細な生産スケジュールを作るのが生産スケジューラ。きめ細かな生産管理をするためには生産スケジューラはなくてはならない“ツール”である、と。
「生産スケジューラは、マネジメントのためのツールです」
これは、大量生産が始まって以来発展してきた生産管理の本流の中に定着している伝統的な考え方ではないかと思います。
では、生産スケジューラとはどんな効用のあるツールなのか。生産スケジューラ・ベンダーのサイトを覗いてみると、生産リードタイム短縮、在庫削減、納期遵守率向上、、、見込生産にも受注生産にも対応、柔軟・迅速な計画変更、、、と万能。生産スケジューラは生産管理ではなくてはならないツールと映ります。
ところが、実際現場に導入して、うまく動かせない企業をたくさんみてきました。うまくいったという企業はわずかで、しかも部分的な導入にとどまっている例が多いように思われます。
そんな企業に対して、「管理レベルの低い企業は生産スケジューラを入れる価値がない」と斬り捨てます。「生産スケジューラをうまく使いこなせない企業は、管理レベルが低い」とも聞こえます。
ではどの程度の管理レベルであれば生産スケジューラを入れる価値がるのか、その判断基準はあいまい。行間から忖度すれば、これで判断できないのは、マネジメントのレベルが低いからだ、と言っているようです。マネジメントのレベルが充分に高ければ、
＊待ち時間も計算できる
＊生産スケジューラをシミュレータとして使い、最適条件で生産を管理することもできる。
＊バラツキがある場合は必要なところにタイム・バッファーを入れておけばよい。
となります。まとめますと、
「ジョブの投入時間間隔がランダムで、処理時間が変動しても、マネジメントのレベルが高ければ、それらのバラツキを生産スケジューラが機能する程度に管理することができ、生産スケジューラを重要なマネジメントツールとして使うことができる。」
というのが彼の主張のようです。
～～～～～～
「生産スケジューラは実行可能なスケジュールを生成できない」
とするFactory Physicsに対して
「マネジメントレベルが高ければ、投入時間間隔や処理時間の変動があっても、生産スケジューラをマネジメントツールとして使うことができる」
とする佐藤知一氏の主張。さて、どちらに軍配が上がるのでしょうか。
「生産スケジューラは実行可能なスケジュールを生成できない」最も大きな理由は何でしょうか。もう少し詳しくみてみましょう。「処理時間のバラツキ」や「ランダムなジョブの投入」があるとどのような物理現象が起きるか。このBlogでは再三取り上げておりますのでお分りだと思います。“待ち行列現象”です。待ち行列理論で詳しく論じられています。
待ち行列理論でその現象がわかっているのなら、投入時間間隔や処理時間のバラツキから待ち時間の長さを求めることができないのか。もちろんできます。しかし、簡単に求められるのは待ち時間の平均で、その分散は簡単には求められないんです。様々な近似式が提案されていますが、どれも難解で、限定的で、誰でもどこでも簡単に使える式ではありません。分散の特性は、バラツキが大きくなり、稼働率が高くなると、平均と同じように急激に大きくなります。また、待ち時間の確率分布形状は釣鐘状からは程遠く、片側に山のすそ野のように、ダラダラと広がります。ですから、持ち時間を点推定することは、ほとんど、不可能となります。
しかし、佐藤知一氏は実際、スケジューラを使っていると言ってます。
「わたしの業界では、計画策定時に、作業期間が確率的に変動するようなスケジューラを、必要に応じて各社で使っています」
これはどういうことなんでしょうか。彼が使っているのはプロジェクト管理です。生産管理ではありません。プロジェクト管理と生産管理で何が違うのか。生産ラインでは待ち行列現象が必ず、強烈に起きるのに対して、プロジェクトのスケジュールでは、部分的、限定的にしか起きません。プロジェクト管理では、タスクの平均時間や分散は加法性が成り立ち、統計理論を利用して、必要なタイムバッファーなども計算できます。
詳しくは、こちらのBlog をご覧ください。
生産スケジューラとプロジェクト管理スケジューラは何が違うのか；2020年4月
待ち行列現象の待ち時間の特徴；2020年5月
お分かりいただけたでしょうか。Factory Physicsは生産管理のスケジューラについて、佐藤知一氏はプロジェクト管理のスケジューラについての記述である、と言えば両者の顔が立ちそうです。
こんな話もあります。2年ほど前、このBlogに“生産管理システム活用の盲点…工場管理8月号[特集１]”を投稿しました。工場管理2018年8月号の特集記事「生産管理システム活用の盲点」の中身の貧弱さに驚き、私見を綴ったものです。
この記事の執筆者は生産管理のコンサルタントです。プロジェクト管理だという逃げ道はありません。生産ラインの物理的特性、工学的特性を理解しないまま、つまりそれらが”盲点“に入ってみえないから、こんな的外れな記事になるのかな、と思います。記事そのものが「生産管理システム活用の盲点」を具現化している、とみると、おもしろい記事です。ちなみに、この記事を書いたのは本間峰一氏です。興味のある方はBlogを覗いてみてください。
「Asprova解体新書」を解体してみました。生産スケジューラがいかに有用か、もりたくさんの機能がわかりやすく説明されています。生産スケジューラから出力されたスケジュールを本来の目的通り現場では使われていないことや、実際は2カ月かかっているものが生産スケジューラだと2週間でできることになるとか、正直ベースで書かれていることにも好感が持てます。
しかし、
米国の大学生向けの教科書的な本は、「生産スケジューリングは絶対に無理なのでやめるように」と明言している。
という情報をどのように理解したのでしょうか。
「教科書的な本」を調べてみたんでしょうか？
「Asprova解体新書」では、生産ラインの物理特性や工学的特性についてはまったく触れられておりません。物理学、工学を無視した生産スケジューラがツールとして機能する根拠はどこにあるのでしょうか。まったく使いものにならない、とは申しません。“おにぎり大の石ころ” も “かなづち” の代わりになる程度の、あるいはそれよりは多少マシな使い方はあるかもしれません。
「Asprova解体新書」をお読みになる方々の参考にでもなれば幸いです。
投稿者: tonchi
“米国の大学生向けの教科書”に書いてあること
「Asprova解体新書」から見えてきたAsprovaの致命的欠陥。それは、一般的な生産ラインでは、必ず起きる“待ち行列現象”を考慮に入れていないことではないか。と言いながらも、ちょっと、ひっかかるものがあります。１３ページにある記述です。
米国の大学生向けの教科書的な本は、「生産スケジューリングは絶対に無理なのでやめるように」と明言している。
著者は、米国では「生産スケジューラは絶対に無理」だと言われていることをご存知だったんですね。そして、さらに、
米国はその後、生産スケジューラの失敗の後遺症から立ち直っていない。しかし、現在のテクノロジーなら可能なのかもしれない。
と。
「現在のテクノロジーなら可能なのかもしれない」
著者はどんな可能性を思い浮かべているのでしょうか。この文脈から推察すると「米国の大学生向けの教科書的な本」に手がかりみたいなものが書いてあるのでは？ どんなことが書いてあるのか、気になりだしました。実はこの本、心当たりがあるんです。たぶん、これしかないかな、と思う本が。
書名；FACTORY PHYSICS
著者；Wallace J. Hopp、Mark L. Spearman
出版社；Waveland Press,Inc.
Amazonでみる
B5サイズで700ページ。ぎっしり書いてあります。1990年、Northwestern大学のMaster of Management in Manufacturingで本格的に使い始めたようです。今回は、第15章 Production Scheduling（516ｐ～552ｐ）辺りにどんなことが書いてあるか、覗いてみましょう。
はじめに、少し、補足しておきます。第15章では、生産スケジューリングを生産方式、ジョブの流し方、人間の経験則などなど、様々な角度から多面的に捉えています。ここでは、コンピュータによる生産スケジューリングに的を絞って考察してみたいと思います。そのために、初めに、生産スケジューラ（コンピュータ）の機能、役割を確認しておきます。
生産スケジューラに期待される機能としては、
① 工場（企業）の利益向上のため、生産リードタイム、工程仕掛、稼働率などの最適なバランスを提示する →目標を達成する最適スケジュールの生成
② それを実現するための具体的なスケジュール（作業者・機械などの開始・完了時刻）を生成する →実行可能なスケジュールの生成
とします。
第15章の初めで、スケジューリング研究の歴史を振り返っています。本書から引用します（要約）。
実務としてのスケジューリングは生産と同じぐらい古いが、研究としては1900年代初めの科学的管理法の動きまでさかのぼる。しかしスケジューリング問題に本格的に取り組み始めたのは1950～1960年代にコンピュータが現れてからである。
MRP,MRPII,and ERPについての記述があります。
コンピュータが使われ始めたのはMRPあたりから。MRPの特徴は、
1、リードタイムは部材に結び付けられ、生産現場の状態には無関係。生産能力は無限。
2、過剰在庫より仕事遅れの防止を重視し、リードタイムはひとつ。そのため、リードタイムが長くなりやすい。投入を早めて、待ち行列が長くなり、サイクルタイムが長くなる。
MRPの単純なモデルでは有効な結果は出せないことがわかると、スケジューリングの研究者や実務者はMRPIIそしてさらにERPを志向するようになる。JITに傾く者もいた。しかしながら大部分のスケジューリング研究者は、オペレーションリサーチの領域で数理的体系化を目指した。
スケジューリングの数理問題を解く条件を次のように単純化しています。
1、すべてのジョブは問題の初めに準備ができている（すなわち、処理が始まる前にジョブは到着している）。
２、処理時間は決定している
３、処理時間はスケジュールの影響は受けない（つまり、段取りはない）
４、機械は絶対に故障しない
５、優先使用はなし（すなわち、一旦、ジョブ処理が始まったら、中断なく終わらなければならない）
６、ジョブのキャンセルはなし
現実は次のようになっています。
1、常に2台以上の機械がある。従って、生産リードタイムを最短にするジョンソンのアルゴリズムやその他の派生アルゴリズムは直接役に立たない。
2、処理時間や需要はバラツク。ランダムなバラツキは生産システムに多大な渋滞を生じさせる。これを無視すれば、スケジューリング理論は非現実的な動きをベースにすることになる。
3、課題の前提条件となるジョブの準備が整っていない。工場が稼働している間、新しいジョブは入り続ける。工場を“からっぽ”にしてから新しいジョブを始める、という条件などは現実的ではない。
4、処理時間は時には順序依存性がある。段取り回数はジョブの順序に依存する。似たような部分のあるジョブは段取りを共通にできるが似ていないジョブはできない。これはボトルネック工程のスケジューリングでは重要。
つまり、生産スケジューリングを生成する数理モデルの条件と現実の生産ラインの状態には、根本的な違いがある、ということです。最も重要な違いを2つ挙げておきます。
＊処理時間のバラツキ
様々な要因で処理時間はバラツキます。ところが、生産スケジューラの条件では、「処理時間は決定」していますので、矛盾します。
＊需要発生のバラツキ
工場には常に新しいオーダー（ジョブ）が入り続けます。予めどのようなジョブが来るかきめられませんが、生産スケジューラでは、「処理が始まる前にどのようなジョブを処理するかわかっている」という条件です。これも矛盾します。
この違いが生産スケジューリングの機能にどのような影響を与えるのか、考えてみます。
ひとつ目の「目標を達成する最適スケジュール」を生成することはできるかをみてみます。
数理的条件で考えてみます。機械1台で25種類のジョブを処理するとします。組み合わせは、25！。25の階乗です。エクセルで計算したら、
15,511,210,043,331,000,000,000,000
と出ました。すごい数ですね。ビックリマーク（！）の意味がわかります。スーパーコンピュータ富岳の計算スピードが41.5京回/秒 だそうです。チェックするプログラムってどんなのかわかりませんが、単純に割り算すると、４３３日かかることに、、。現実の工場には、機械は数台、数十台ありますので、数理モデルで最適解をもとめるのは、“不可能”ですね。（NP困難問題）
実際はさらに、“処理時間のバラツキ”と“需要発生のバラツキ”があります。仮に上記の計算が数日で済んだとしても、処理を実行するときは、条件が変わっていて、最適解の意味はまったくなくなってしまいます。
結論は次のようになります。
「生産スケジューラが目標達成のための最適スケジュールを生成することは“不可能”である」
次に、二つ目の機能について検討します。
実行可能なスケジュール
ひとつ目の「目標を達成する最適スケジュール」を生成することは不可能ですが、“まぁまぁ”のスケジュールを生成することはできます（後述）。問題は、それに従って実行できるかどうか。
ある時、工場で処理する「オーダー（ジョッブ）」とそれらの処理時間を決めます。その決められた数値でスケジュールが生成されます。現実は、新しいオーダーがランダムに入り続け、処理時間もバラツキます。“まぁまぁ”のスケジュールでも、できるだけ高い稼働率を狙います。すると、その工程では、処理時間の数倍の待ち時間が生じてしまいます。この待ち時間を挽回することはできません。累積され、後ろの工程になればなるほど、処理開始時刻がどんどん遅れることになります。
「スケジュールでは昨日の午前9：00から始めることになっていたジョブが今日の午後3：00にやっと着いた」、なんていうことが頻発することになります。
結論は次のようになります。
「実行可能なスケジュールを生成することはできない」
あるいは、
「生産スケジューラから出力されるスケジュールに従って作業を行うことはできない」
このような結論となるわけですが、Factory Physicsでは、これに対する解決策も提案しています。どんなものか、みてみます。
先ず、生産方式の改善で対処するアプローチはお馴染みです。例えば、「フォード生産方式」。コンベヤーに台車を等間隔に投入することで「需要発生のバラツキ」をなくします。生産車種はT型1車種、作業を分業してコンベヤーに沿って人を配置して「処理時間のバラツキ」をなくします。この考えを多車種生産に広げたのがトヨタ生産方式。ただ、トヨタ生産方式のようにバラツキがなくなると（小さくなると）、ジョブは等間隔（サイクルタイム）で流れてきますので、生産スケジューラが出力するような細かなスケジュールは不要になります。
その他、小さな改善も含めれば数え切れないほどの方式が提案されています。
では、「処理時間のバラツキ」も「需要発生のバラツキ」も扱えない生産スケジューラではどのような改善策があるのでしょうか。大きく2つあるようです。
ひとつ目は、「処理時間のバラツキ」や「需要発生のバラツキ」の少ない生産方式と生産スケジューラの組み合わせです。バラツキを扱えない生産スケジューラでもバラツキが小さくなれば、使える可能性は出てきます。第15章では“動的管理”としてCONWIPと生産スケジューラの組み合わせが紹介されています。
動的管理：システムの物理的特性を利用することで、リスケジューリングすることなく、需要や生産能力のランダムな変化に対応できる動的管理ができる。動的管理の一例は統計的スループット管理（STC）とフレキシブルなキャパシティバッファー（例えばシフトの追加）のあるCONWIPである。生産ラインの長期的生産量に影響のない小さなランダムなゆらぎがあっても一切、調整はしない。さらに、このようなシステムは、予定よりも生産能力が大きいときは“前倒し生産”となる。これを詳細なスケジュールで行うことは難しい。
もうひとつは、“ヒューリスティック（Heuristic）”。発見的という意味だそうですが、分かりにくいですね。試行錯誤とか経験則と言った方がわかりやすい。論理的ではなく、必ずしも“最適解”ではないが、まぁまぁの答えとなる、ということのようです。
実際、生産スケジューラがHeuristicを使っているのは“NP困難問題”に対しです。AsprovaではGreedy AlgorithmというHeuristicを使っているようです。
実行不可能なスケジュールでも現場作業監督者は作業者に指示を出さなければなりません。新参者にはできません。試行錯誤の経験則（Heuristic）が物言うところです。
しかし、問題としている「処理時間のバラツキ」と「需要発生のバラツキ」を固定値しか扱えない生産スケジューラで処理しなければならないという矛盾をHeuristicなアプローチで改善できるか、というと、答えは、明らかに“否”。
ということで、Factory Physicsが示す、スケジューリング問題に対する解決策は、すべて周辺（生産方式とか）の条件を変えるもので、2点の対立を解消するものではありません。
従って、Factory Physicsが示す生産スケジューラの機能についての結論は次のようになります。
「生産スケジューラが目標達成のための最適スケジュールを生成することは“不可能”である」
「実行可能なスケジュールを生成することはできない」
著者は「生産スケジューラは絶対に無理」の意味を理解しているのでしょうか、、。それは失礼ですね。ちゃんと理解してますよね。
と、すると、「現在のテクノロジーなら可能なのかもしれない」と宣う著者は、Factory Physicsも気が付いていない「生産スケジューラ・起死回生の秘策」を持っているのではないか。「Asprova解体新書」をもう一度、見直してみたいと思います。
「Asprova解体新書」から見えてくる致命的欠陥
“生産スケジューラでスケジューリングしたらリードタイムが１/４になったという話”
“生産スケジュール本来の機能は使わずに、生産の準備とか、原材料の所要量計算とか、だけに使うという話”
なんで、そういうことになっちゃうのか、納得できる説明はありません。生産スケジューラの機能の中に隠れているのかもしれません。どのようなデータを入れて、どのような結果が出るのか、基本的なところを確認しておきます。
登録しておく製造BOMなどの「マスタデータ」は次のような事項です。
＊品目（コード、種別）
＊製造BOM（品目、工程番号、工程コード、指図コード、品目/資源、前段取り、製造時間）
＊資源（機械、人員など）
＊シフト（稼働時間のパターン）
＊カレンダ
オーダに関連するオーダーコード、品目、納期、数量、優先度など入力します。
出力される項目は次のような内容です。
＊作業テーブル（コード、品目、数量、資源、製造開始日時、終了日時、製造時間）
＊資源ガントチャート
＊オーダガントチャート
マスタデータに登録するコードとか工程番号などのデータはすべて確定値というか、固定値というか、そういうものです。現実と合わなければ修正しなければなりません。マスタデータが間違っていれば、結果も間違いを含んだものになります。当たり前の話なんですが、、。
ここで注目しておきたいのは製造BOMの中の“製造時間”です。製造時間って、バラツキますよね。まったく同じ品目でも、ある時は５０分、別のときは６５分とか、、。マスタには一つの固定値しか入れられませんので、“平均＋バラツキ分” で設定するんでしょうか。固定値は固定値ですがね、、。
現実は、“製造時間”はバラツキます。製造時間がバラツクとどうなるんでしょうね。
このBlogでは、何度か、取り上げているテーマなので、繰返しになる部分もあると思いますが、生産スケジュールとの関係を気にしながら、簡単にレビューしておきます。
生産工程に影響を及ぼすバラツキは、大きく分けて、２種類あります。
①オーダの到着時間間隔（投入時間間隔）
②工程での処理時間（製造時間、作業時間、、）
わかりやすいように、ひとつの工程に注目します。注文はランダムに来ます。工程の処理能力には限界があります。例えば、工程の平均処理能力は１時間に６個としましょうか。平均の処理時間は１０分ですが、オーダごとにはバラバラです。あるものは６分、別のオーダは１３分というように。１時間に平均６個の処理能力があるところに、１時間に５個のオーダがあったとすれば、工程の稼働率は５÷６＝０．８３ で８３％ということになります。
オーダはランダムに来ますので、その時、工程がビジーであれば、その処理が終わってから、新しいオーダの処理をすることになります。その時、そのオーダは待つことになります。どのぐらいの時間、待たなければならないのかの計算式があります。但し、これは、オーダ到着時間間隔も処理時間も指数分布に従うときです。
平均待ち時間＝(平均処理時間)∙(稼働率/(１-稼働率))
平均処理時間；１０分、稼働率；０．８３で計算しますと、平均待ち時間は５０分となります。オーダ到着時間間隔も処理時間も指数分布というのは、めいっぱいバラツク状態ですので、実際は、そんなにバラツキは大きくはないと思いますが、決して、無視できないことだけは確かです。
この待ち行列現象の厄介なところは、稼働率が高くなると急激に待ち時間が長くなるという特性です。生産スケジューラでは稼働率はできるだけ高くなるようスケジューリングしますので、考慮しなければならない重要な現象です。
Asprovaに戻ります。BOMの“製造時間”に入れることができるのは、“固定値”だけです。“確率変数”を入力することはできません。スケジューリングのロジックも固定値しか扱えないようになっています。
つまり、Asprovaは“待ち行列現象”による待ち時間をまったく考慮に入れていないことになります。
“生産スケジューラでスケジューリングしたらリードタイムが１/４になったという話”
を振り返ってみましょう。数値を入れて、ザックリと計算してみましょうか。４０工程で生産リードタイムを４０日（２カ月）としてみましょう。生産スケジューラでスケジュールすると、リードタイムは１０日（２週間）になる、ということですね。
計算を簡単にするため、工程の作業時間をすべて同じとします。４０工程で４０日かかりますので、１工程は１日。１日は８時間とします。一方、生産スケジュールの結果は、４０工程で１０日ですので、１日に４工程、１工程は２時間、となります。生産スケジューラは待ち行列現象による待ち時間を無視していますので、それを加えたらどうなるか、大雑把な計算をしてみます。
各工程の稼働率を７５％としてみます。前記の式に代入して計算してみます。平均待ち時間は次のようになります。
平均待ち時間＝２（時間）×（0.75/（１－0.75））＝６（時間）
処理時間；２時間に待ち時間；６時間を加えると８時間。現状に合いますね。
実際そうなるかどうかはわかりませんが、待ち行列現象の影響をザックリと感じることはできるかと思います。
“生産スケジュール本来の機能は使わずに、生産の準備とか、原材料の所要量計算とか、だけに使うという話”
はどうでしょうか。
生産スケジューラでスケジュールすると、投入時間間隔と製造時間のバラツキによる待ち時間が考慮されていませんので、作業開始時刻は早めにセッティングされてしまいます。早めにセッティングされた時刻に間に合うように原材料や生産の準備をしますので、問題は生じないでしょうね。さらに、製造時間の時間単位と原材料や生産準備の時間単位の違いもあると思います。多いのは、前者は“分”、後者は“日”。“日”は安全側にまるめられますので、さらに早くなります。
作業指示には使わないで、原材料や生産準備の予定にだけ使うのであれば、生産スケジューラなんて、使わなくてもいいんじゃないのかな。あれもできます、これもできますって、機能満載の生産スケジューラ。秒単位で作業指示が出せます、と言っていますが、“そんなの、かんけいねぇ”となりませんか。
「Asprova解体新書」から、Asprovaが抱える致命的欠陥がみえてきました。これはAsprovaだけの問題なのか、どの生産スケジューラにも共通して言えることなのか、、。
「Asprova解体新書」の【コラム】で気になるところ
「Asprova解体新書」を読み始めると、
“生産スケジューラは絶対に無理”
その理由は、
“マスタデータの作成と維持が困難である”
“米国はその後、生産スケジューラの失敗の後遺症から立ち直っていない”
という記述で立ち止まってしまいました。ネガティブな位置からはじめる方が説明がしやすいのかもしれません。この本には、これらに対する反論というか、Asprovaは違うよ、ということが書いてあるはず。そんな期待を持ってしまいます。
本の内容は、大部分はAsprovaの取説。ところどころに生産管理や在庫管理の説明があり、そして【コラム】として、顧客企業への訪問記や自慢話が挿入されています。その中から、気になるところを抜き出してみます。
２７ページ
～～～～～～～～～～～
【コラム】自動車部品工場の生産スケジューリング・・・生産準備
・・・数年前に生産スケジューラを導入し、うまく稼働しているということで今回訪問することになった。・・・
この工場では生産スケジューラは使用しているが、まだフル活用はできていないと話している。すなわち、生産スケジューラのスケジュール結果を用いた生産指示が出せていないということだ。
・・・何に役立てているかというと、生産準備である。・・・生産準備の主な仕事は、①内示情報から所要量を計算して原材料、外注の手配をする、②内示情報から工場の負荷状況をチェックする、ことである。
～～～～～～～～～～～
似ている記述が、、、
３６ページ
～～～～～～～～～～
【コラム】かんばん方式を導入した工場でも、生産スケジューラによる所要量計算が必要
・・・トヨタ生産方式によるカイゼンでも、・・・原材料の購買の計算をMRPで行っていると、原材料の在庫削減には限界がある。そこで生産スケジューラを導入して原材料の所要量、タイミングを最適化するのである。この場合、生産スケジューラが作成した作業指示の詳細データは、使われないかもしれない。・・・
～～～～～～～～～～
またまた、同じようなことが、、、
５６ページ
～～～～～～～～～
【コラム】金型工場の生産スケジューリング・・・BOMに誤差はあるが、生産の「見える化」が進んだ
生産スケジューラの導入が完了し、成功裡に稼働している工場を訪問した。・・・工場見学すると、工場には生産スケジューラで立案した結果が印刷して貼られていた。生産スケジューラは、細かい作業指示を出すのが本来の機能であるが、この工場では、細かな生産指示を現場には出していない。各マシンへの作業の割付けと負荷量のグラフを表示していた。後は状況に応じて実際の作業を行うということである。
～～～～～～～～～
３つのコラム。いずれも、生産スケジュール本来の機能（細かい作業指示を出す）は使わずに、生産の準備とか、原材料の所要量計算とか、マシン作業の割付け表示とかに使っているっていうことのようです。実際の作業の進め方は現場に任せてあるとのこと。
似たような話、前にもありました。２０１９年１２月のBlog「生産スケジューラ；ベンダーの宣伝に踊らされるな！」でも、生産スケジューラを導入して、かえって混乱したという事例を紹介しました。解決策は、「ネック工程は人間が手作業できめ細かく管理し、前後の非ネック工程はスケジューラで計画作成」。肝心のネック工程は人間の手作業、余裕がある工程はスケジューラを使用、ということです。
なんか、変だと思いませんか。逆ですよね。きめ細かな作業指示こそ生産スケジューラを使うと思ってましたが。現実は、逆。
コラムに３回も出てくるということは、そして、他の事例でも似たようなものがあるということは、生産スケジューラの機能と何等かの関係がありそうですね。
もうひとつ、【コラム】から抜粋。
５１ページ
～～～～～～～～～
【コラム】ショックアブソーバ工場の生産スケジューリング・・・生産リードタイムを劇的に短縮した
・・・ショックアブソーバの生産工程は金属加工など４０から５０と長く、生産リードタイムも２カ月かかっていた。生産スケジューラで実データを登録してスケジュールしてみた。・・・
そして、結果を見て驚いた。生産スケジューラのガントチャート上で、生産リードタイムが２週間となっている。「えっ、そんなバカな？」と担当者。でも、ガントチャートをしばらく詳細に眺めていると「やはりこれは本当だ。２週間でつくれる！」とつぶやいた。生産リードタイムが１/４になった。私も驚いた。「でも、工場長には言えないなあ。だって今まで何をやっていたんだ、と叱られちゃう」とのことだ。
～～～～～～～～～～
生産スケジューラの最も代表的な改善項目は生産リードタイムの短縮。リーダタイムが１/４になるなら、前の【コラム】ではなぜ、生産スケジュール本来の機能は使わずに、生産の準備とか、原材料の所要量計算とか、だけに使うのか。穿った見方をすれば、生産スケジューラから出る作業指示通りには作業ができないのではないか。とすると、問題は、リードタイムが１/４となったスケジューリングの実現性というか、実行可能性というか、、はどうなのか。リードタイム２カ月と２週間の差は何なのか、、。
出口はまだ、見えません。
「Asprova解体新書」を拝読
生産スケジューラについての愚見をみてか、ある筋から「こんな本があるよ」という連絡がありました。
「Asprova解体新書 生産スケジューラ使いこなし再入門」
著者；高橋邦芳、出版社；日刊工業新聞社 ２０１９年６月２７日 初版発行
プロパガンダ的な本であることは、すぐにわかります。著者はAsprovaの代表取締役会長だそうで。どこの生産スケジューラベンダーのWebsiteをみてもそうなんですが、AsprovaのWebsiteをみても、“なんでもできます”的な万能ぶりを、あらん限りの美辞麗句をちりばめて、これでもか、これでもか、、という感じ。思わず、“誇大広告じゃないの？”と。
この本も、その延長線上の本だろうな、と思いながら、、。“まえがき”は飛ばして、“プロローグ”。新入社員が生産管理セミナーに参加するという物語で始まります。著者の工夫の跡が感じられます。
１２ページ辺りから“生産スケジューラ”のにおいがしてきます。Asprovaの導入検討や導入プロジェクトで「困ったことベスト１０」として、こんなことが書いてあります。
～～～～～～～～～～～
困ったことベスト１０
１ 費用対効果（ROI）を示すのが難しかった
２ Asprovaを何に活用したらよいか迷った
３ 現状業務をどこまで変えたらよいか迷った
４ 機能が多過ぎて、何ができて、何ができないのかわかりにくかった
５ 希望しているスケジュール結果が出なかった
６ マスタ構築、マスタメインテナンス、データ連携が難しかった
７ 作業指示をどのように出して、作業実績をどのように取るのかを迷った
８ 必須で難しい要件が後回しになって、最後になって困った事態になった
９ 社内に抵抗勢力や反対派がいた
１０ 担当者が交代したら、Asprovaを使わず、Excel管理に戻ってしまった
～～～～～～～～～～～～～～～～～
“誇大広告”というイメージはありません。意外と、まじめな本なんだ、という感じです。
続いて、次のようなことが書いてあります。
１３ページ
～～～～～～～～～～～～～
生産スケジューラの歴史
▶１９８２年頃、エリヤフ・ゴールドラットの挫折
入社直後、上司である清水部長から、エリヤフ・ゴールドラットの「ザ・ゴール」という本を読むようにと言われ読んだ。ザ・ゴールのあとがき（日本語版P521）には、氏が生産スケジューラを開発し、米国で販売を好調に行うが長続きせず、挫折する。その代りに、ザ・ゴールという世界的ベストセラー小説を書いた。上村講師に聞くと、そのソフトウエアはボトルネックに着目したものだそうだ。しかし、何の理由かはよくわからないが、ゴールドラットはそのソフトウエアの開発を放棄し、ザ・ゴールを執筆したのだ。
米国の大学生向けの教科書的な本は、「生産スケジューリングは絶対に無理なのでやめるように」と明言している。その理由として、マスタデータの作成と維持が困難であることを挙げている。ゴールドラットが挫折したのも、マスタデータが理由だったのだろうか。マスタデータとは、そんなに怖いものなのか。米国はその後、生産スケジューラの失敗の後遺症から立ち直っていない。しかし、現在のテクノロジーなら可能かもしれない。さらに話は続いた。
～～～～～～～～～～～～
いやいや、これはこれは、、生産スケジューラの否定から入っているじゃないですか。
“生産スケジューラは絶対に無理”
会長さん、こんなこと書いて大丈夫ですか。
“マスタデータの作成と維持が困難である”
という理由も現実味を帯びています。
“米国はその後、生産スケジューラの失敗の後遺症から立ち直っていない”
そうなんですよ。一時は、結構な数の米国拠点の生産スケジューラベンダーがおりましたが、今はほとんどいなくなりました。日本には、まだまだ、たくさんの生産スケジューラベンダーがおりますが、、。
米国で見捨てられ生産スケジューラの実態をよくご存知のようです。そして、それを背景にこの書を著したのだとしたら、、
「生産スケジューラって、もしかすると、、もしかするかもしれない」
生産スケジューラの欠陥を知って書いたのであれば、その欠陥を埋める方策なり、解決策なりがかかれているのではないか。米国の生産スケジューラベンダーが解決できなかったことをAsprovaは解決したのではないか。
これが、本当なら、、
「美辞麗句だらけの、誇大広告、、」
などと揶揄したことを、ひれ伏して取り下げ、最大の“称賛”の言葉を贈らなければなりません。
この本に、どんなことが書いてあるのでしょうか。次回、報告します。
DPM研究舎
待ち行列現象の待ち時間の特徴
生産型の流れでは、工程ひとつひとつが待ち行列現象を起こす形をしています。生産にたずさわる誰もが、工程の稼働率をできるだけ高く維持しようとします。そうすると、待ち行列現象が強くなり、長い待ち時間が発生することになります。
プロジェクト型でも待ち行列現象は起きますが、部分的であり、その影響は生産型に比べれば軽微です。
待ち行列現象の待ち時間とはどんな特徴があるんでしょうか。事例で試算してみましょう。図１をご覧ください。できるだけ同じ条件で比べた方がわかりやすいと思います。生産型もプロジェクト型も直列5工程（５タスク）、処理時間平均は工程４（タスク４）が９時間、他の工程（タスク）は7時間です。生産型の工程バラツキは変動係数0.25、プロジェクト型は0.75と大きくしてあります。生産型のオーダはランダムに投入されますが、平均時間間隔は10時間です。プロジェクト型はプロジェクトX、ひとつです。
図１ 事例研究；生産型とプロジェクト型の比較
生産型では、ひとつのオーダが完成するまでの時間、プロジェクト型ではプロジェクト開始後完成までの時間を試算してみます。その一例を図２に示します。プロジェクト型のタスクのバラツキは生産型のそれの３倍であることにご留意ください。にもかかわらず生産型の所要時間の方が平均も最大値も長くなっています。分布をみても、プロジェクト型は、正規分布に近い分布形状ですが、生産型のそれは右に大きくすそ野が伸びています。
図２ 生産型とプロジェクト型の完成までの所要時間の比較
どの工程での待ち時間が長いのか、調べてみました。工程１，２，３、と５はほぼ同じなので、工程１を代表に、工程４の待ち時間と比べてみました。結果を図３に示します。工程４の待ち時間が全体の所要時間に大きく影響を与えていることがわかります。
図３ 工程４の待ち時間が長い
工程１，２，３，５の稼働率は0.7、工程４のそれは0.9。稼働率が高くなると、待ち時間が急激に長くなる待ち行列現象の影響であることは明白です。
この待ち行列現象による待ち時間。困ったことに、実に、捉えにくいというか、扱いにくいというか、始末に負えないんです。図２と図３のデータを採るとき、計算ごとに結果が結構バラツクんです。乱数を使っていますので、バラツクのは当たり前なんですが、計算するごとに出る結果の違いに驚いてしまいます。お示しした結果は、だいたい平均的なものです。
プロジェクト型の所要時間の分布はだいたい正規分布に近いのですが、生産型のそれは右に長々とすそ野を引くのが特徴のひとつです。プロジェクト型の分布は統計理論を応用できそうですが、生産型の分布は統計理論では扱えそうにありません。生産型の分布を扱える数理モデルってあるんでしょうか。いろいろ探してみたんですが、見つかりません。
待ち行列理論も調べてみました。待ち行列理論の数理モデルは待ち時間、待ち行列の長さ、待っているWIPの数を計算できますが、すべて平均なんです。生産管理では、平均値も有用な情報ですが、分布の端っこの部分が重要ですので、そこを知りたいんです。確率分布の形状を扱える数理モデルって、ないのかなぁ～、、。今のところ、見つかっておりません。ご存知の方がいらっしゃいましたら、ぜひ、ご一報ください。
プロジェクト型のスケジューラでは、バラツキを考慮したものがあります。プリミティブなものでは、３点見積で標準偏差を求め、本格的なものは過去の蓄積されたデータから標準偏差を求め、加法性を利用して、各タスクの平均、分散を合算してプロジェクト全体の所要時間を算出する。正規分布で近似して、納期の達成確率などを見積もるようなことが行われているようです。
では、生産スケジューラではどうなんでしょうか。待ち行列現象を考慮した生産スケジューラって、市販されているのでしょうか。
生産スケジューラ・ベンダーの宣伝文句をみると、受注生産、多品種少量・変量、即座の計画変更、、なんでもゴザレ、、という感じですが。額面通り受け取れば、当然のことながら、待ち行列現象に対しても、対応策をとっているのではないか、と思われるんですが。実態はどうなんでしょうか。
さらに、追求してみたいと思います。
生産スケジューラとプロジェクト管理スケジューラは何が違うのか
ゴールドラットが提唱した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日単位、週単位での進捗管理が可能、という違いはあるのではないか、と思われます。
これも大きな違いです。
生産型；処理時間の見積が正確
プロジェクト型；処理時間の見積精度が低い
生産型の作業時間は標準化が行われ、大量生産では、時には秒単位で標準作業時間が設定されています。プロジェクト型は、作業そのもの繰返しが少なく、作業時間の見積精度は低いのが一般的です。表１に生産型とプロジェクト型の比較をまとめてみました。
表１ 生産型とプロジェクト型の比較
生産型とプロジェクト型のスケジューリング、さらに追及していきます。
生産スケジューラは使いものになるのか；TOCの教訓[2]
MRPの大雑把なスケジューリングの欠点改善を目指したOPTでしたが、思うようには売れませんでした。しかし、苦肉の策で出版した「ザ・ゴール」は、思いのほか売れ行きがよく、その後十数年、ベストセラーの座を占め、全米で２５０万部を超える販売数を記録しました。
OPT発売のときも、「ザ・ゴール」出版のときも、スケジューリングの詳細についての説明はありませんでした。MRPについてはすべてが公開されていたのに、、。DBRのスケジューリングについても公開を望む声が大きくなりました。
１９９０年、ゴールドラットは「The Haystack Syndrome」を出版。その中で、DBRのスケジューリングについて詳細な説明を行っています。それをきっかけに、DBR対応の生産スケジューラが次々と発表されました。中には、“ゴールドラット博士公認”なんていうサブタイトルを付けるベンダーもいました。１９９０年代後半、ベンダーは１０社を超えていたんじゃないかと思います。
しかし、ゴールドラット自身がスケジューラを開発することはありませんでした。OPTの失敗を繰り返したくなかったのでしょうか。
BDRスケジューラが実際の現場で使われるようになりました。しかし、ゴールドラットが「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スケジューリングが実行可能なスケジュールとはならない大きな理由です。
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というと繋がりが悪くなります。同じ方法の方が繋がりはスムースです。いや、それ以上の理由があるんでしょうね。どんな理由なんでしょうか、、。
次回、考えてみます。
生産スケジューラは使いものになるのか；TOCの教訓[1]
成功事例よりもはるかに多い生産スケジューラ導入の失敗事例。今始まったことではありません。様々な改善の努力も行われています。月間雑誌「工場管理」では頻繁に取り上げられるテーマです。「あーやればいい」、「こうやらなくちゃ」、「いやいやこうであるべきだ」、、と議論は尽きません。でも、改善の兆しは一向に見えない。
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の関係をみていきます。
生産スケジューラのお得意さんは？
前回の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社の業務にあるので、手の打ちようがない」といわれて、、、。
「管理レベルの低い工場」は生産スケジューラベンダーのお得意さん？