1990年台の後半でしたか、当時は米国に赴任中でした。そこで出会ったのがＴＯＣ（制約理論）です。これがまた、ＪＩＴとは間逆なことを言っている。 ＪＩＴを懐疑的な目で見始めたころでしたので、タイミングよくＴＯＣに関心が向いていきました。
ＪＩＴと縁を切ったわけではありません。研究の対象としては、やっぱり、ＪＩＴは手放せません。むしろ、ＴＯＣを理解するためにもＪＩＴは必要でした。 米国でも「Lean vs TOC」の対立は話題でしたから。
ＪＩＴにのめり込んだようにＴＯＣにものめり込みましたね。当時はＴＯＣの教祖様はご存命でありました。演説、 ではなくて、講義を聴いているとカリスマ性が感じられ、迫力もあって、初めて聴いたとき、やっぱり度肝を抜かれました。 ＪＩＴは理論がなかったけれど、ＴＯＣはTheory of Constraintsというだけあって、理論がベースにあるという印象がありました。 理論に飢えていたのかな。こんなことでＴＯＣのとりこになってしまいました。
ＴＯＣの理論とは一体なにか。制約理論といわれれば垣根はぐっと低くなります。制約は、生産ラインではボトルネック。生産ラインの能力はボトルネックで決まるんだ。 そして、どんな複雑な生産ラインもボトルネックで決まるんだから、 ボトルネックで改善、管理をすれば、生産ラインぜんたいをコントロールすることができると。
理論といっても、実は簡単な理論でした。Simple is best.なんていってました。こんな簡単な理屈で、 複雑・長大な生産システムをコントロールすることができるとは。これは、目からうろこ。ＪＩＴ用語で思考停止気味だったこともあって、 ＴＯＣは新鮮でしたね。で、しばらくＴＯＣにどっぷりの日々をすごすことになります。
ＴＯＣのＤＢＲ（ドラムバッファーロープ）とＪＩＴ。初めは、対象としているのが生産ラインだ、ということ意外に共通項は見つかりませんでした。 ことごとく反対。ＪＩＴはバランスラインでＤＢＲはボトルネックライン。ＤＢＲでは、この世にバランスした生産ラインなど存在しないっていうんです。 存在し得ない生産ラインがトヨタにはある、、のかな。そんなわけはない。ならば、トヨタの生産ラインはバランスラインではないのか。いや、限りなくバランスラインに近い生産ラインだが、 ＴＯＣではそれはバランスラインとは言わないってことなのかな？当時は、こんな程度の疑問でしたが、、、
ＤＢＲに期待したことは、創始者が物理学者だという触込みがあってか、ＤＢＲの生産理論でした。 ボトルネックがどうのうこうのではなくて、ＤＢＲを支える基本的なロジックを知りたかったんです。で、ＡＧＩ(Avraham Y. Goldratt Institute)の専門コースも受講しました。 国際コンファランスにも毎年のように参加しました。創始者に直接質問をぶつけてみました。側近にもいろいろ聞きました。
で、一番ＤＢＲについて詳しい情報を得たのは、創始者著の「The Haystack Syndrome」という本でした。 副題が「Sifting Information Out of the Data Ocean」。データの海からインフォーメーションをふるいわける、というほどの意味ですが、 こだわっているのが、インフォーメーションとデータの違い。書によれば、 インフォーメーションとは「問われている質問にたいする答」、データとは「現実の物事や事象などを説明、描写する文字列」。
ここで、問われている質問とは、現有の生産ラインで最大のスループット（＝売上－直接費）を得るための実行可能なスケジュールを立てる方法はいかに？ ということ。あふれんばかりの雑多なデータの中から、必要なデータを探して、質問に対する答、つまり、 実行可能な最も効率の良いスケジュールをつくる。その考え方が書かれているのが「The Haystack Syndrome」だ、ということがわかったんです。
この本、日本では「ゴールドラット博士のコストに縛られるな！」という題で、ダイヤモンド社から出版されていますが、スケジューリングの考え方がテーマなのに、 日本語の題は、ちとズレていますね。
実は、原書は1部、2部、3部とありますが、日本語版では3部はないんですよ。3部にＤＢＲのスケジューリングの詳細について書いてあります。 1部と2部はなぜＤＢＲのスケジューリングはこのようにしなければならないのか、について、長々と説明しているんです。 その部分は、日本語題名「「ゴールドラット博士のコストに縛られるな！」がぴったし。
「生産ラインの能力はボトルネックで決まる。だから、ボトルネック工程の効率を最大になるようにスケジューリングすれば、生産ラインの能力を最大限発揮させることができる。」
このくだりは、分かりやすくて、すごく説得力がありますね。反論が見当たらない。重箱の隅をつつくようなけちも付けられない。完璧だ、と思いましたね。 「The Haystack Syndrome」の第3部スケジューリングを読むまでは、、。
第3部は部題が示すとおりＤＢＲのスケジューリング方法が詳細に書かれています。巷のＤＢＲ用ソフトは、これを読んでつくったといわれているんです。それぐらい詳細に書いてある。 詳細に、というよりか、論理的に、といったほうがいいかもしれませんが。
創始者は、スケジュールは実行可能でなければならない、と強く主張しています。その背景は、 それまでのスケジューリングはＭＲＰベースが大半で、ＭＲＰでは時間制御が大雑把できちんとした、実行可能なスケジューリングができなかったんです。 スケジューリング自体が論理的に合っていないわけですから、それを元に実行しても、スケジュール通りにならない。ＤＢＲの考え方でスケジューリングすれば、 簡単に実行可能なスケジュールができる、というのが創始者の考えです。そのスケジューリングの方法が書いてあるのが第3部です。
ですから、第3部にはＤＢＲの真髄が書かれている、、のではないか。ＴＯＣコミュニティでのうわさも、そんな感じでした。 「ＤＢＲを理解するためにはThe Haystack Syndromeの第3部を読め」。 ＴＯＣの国際会議などで何人かに言われた言葉です。
そんな大事な部分を日本語版では、なぜ、省いたのか？ＤＢＲのスケジューリング方法を書いた本だ、という痕跡も残らないぐらいに、題名までモディファイして。
実は、第3部もちゃんと日本語に翻訳されていたんです（日本語原稿はまだ私の手元にあります）。翻訳者は「ザ・ゴール」を初めとする創始者の著著の多くの翻訳を手がけた方です。 「ザ・ゴール」シリーズは、ご承知のように、小説形式で一般向けです。ところが、「The Haystack Syndrome」はそうじゃないんです。もう少し正確にいうと、第1部と第2部は、 小説形式とまではいかないが、読み物、という感じですが、第3部は工学書的で、専門書的で、マニュアル的なんです。 ＤＢＲのスケジューリングに興味のある人以外は、誰も読まないでしょうね。
商業的な理由で、ダイヤモンド社は出版直前に第３部を削除したんです。ＤＢＲの本質を知ろうと思っていた私にとっては、 この第3部は、これこそ探していたもの、だったわけです。で、一生懸命読みました。ところが、読んでいくうちに、シンプルさがだんだんなくなっていくんですよ。 すべての工程のスケジュールをつくるのではなくて、ボトルネックのスケジュールだけをつくればいいんだよね、これは簡単だ、って。
実行可能なスケジューリングはシンプルな考え方でできている、と思っていました。ボトルネック工程だけスケジューリングすればいい。 これなら簡単で、且つ実行できるスケジューリングができるわ、と。