オルタナティブ・ブログ > Godspeedな生活 >

地方都市のおじさんが思う「家族と仕事とお勉強のワークライフバランス」

『ザ・ベロシティ』のサイコロのゲームをやってみた 3 〜まとめ:100%がベストではない〜

»

 『ザ・ベロシティ』のTOC理論のうんちくは抜きにして、「とにかくやってみる」のまとめをしたいと思います。

 そもそも、ITは無形だし、製造業は有形なので、ちょっと違うんじゃないの?とのご意見もあるかと思います。このあたりについての私見は別の機会に触れるとして、少なくとも、製造業であろうが製造業でなかろうが(農林水産業でもサービス業でも)、ITはツール/手法としての重要な役割は果たしていますので、こちらのメディアをご覧になる製造業/生産技術系の方々も少なくないと思います。

 さて、前回まで、同著『ザ・ベロシティ』にふれられているサイコロのゲームをベースにして、工程内にて生産指示(キャパシティ)にばらつきがある状態を前提としながら、全体の生産量や一定期間経過後の在庫量を見てみました。また、意図的にボトルネック(制約)を設けて、同様にその生産量や在庫量を見てみました。
 ちなみに、これまでのブログは、こちらです。


 ・『ザ・ベロシティ』のサイコロのゲームをやってみた 1 〜TOC理論が指す意味あるムダのざっくり感〜
 ・『ザ・ベロシティ』のサイコロのゲームをやってみた 2 〜制約前の予測不能なダブツキ在庫〜

 今回は、制約となる工程を持つ状況下でダブついた在庫を如何に減らしていくのか?より、TOC理論っぽく言うのであれば、スループットを重視するにあたりある程度許容できる在庫量(がちゃがちゃ言われない程度の在庫量の抑制)が一つのポイントになるかと思います。

 繰り返しになりますが、工程A〜Gまでの7つの工程を設定し、正七面体(実際にはありえませんが)のサイコロの出目により各工程の生産指示と想定します。7つの工程中、6つの工程ではサイコロを2つ振ることなるため、出目は2〜14までとなり期待値は8です。ただし、工程D(4つめの工程)についてはサイコロを1つ振るとしており、出目は1〜7まで期待値は4となります。つまり、工程Dがこのラインのボトルネックとなるわけです。

 同ラインでの生産量について、前回のブログで示していますが、10回の試行で平均は約78(前回は誤植でした。すみません。)、在庫量は平均で106と、約3.8倍になっていました。

 さて、今回ですが、同著シリーズで指しているボトルネックへの対策として有名(?)な方策を取ります。まず、ボトルネックの直前の仕掛品は、ある程度十分な量にするというものです。これまでの試行では、7つの全行程は共に仕掛品として4を設定していましたが、今回、ボトルネックとなる工程Dについては、その3倍の12を設定します。つまり、工程直前の仕掛品は、工程A〜Gまで、4・4・4・12・4・4・4となります。
 次に、工程Aへの投入量に細工をします。これまでは、購入量も同様にサイコロを1つないしは2つ振った出目としていましたが、今回は、ボトルネックとなる工程Dの生産指示と同じ量を投入量とします。工程Dではサイコロを1つ振りますので、その出目と同じ数だけ工程Aに投入されるということになります。なお、工程A〜Cについては、同様にサイコロは2つ振るものとしています。

 お気づきかとは思いますが、投入量をボトルネックにあわせるという点では、制約前の工程については、プッシュではなくプルに近い状態が再現されることになります。つまり、このあたりがミソという訳です。

 結果は、次の通りとなりました。生産量ですが、最小63最大84で平均が約73となり、前回の方式をオールプッシュと呼ぶのであれば、やや減少(約6%)しています。

Graph31

 しかしながら、在庫量については、最小32最大40の平均で約35となっており、オールプッシュと比較すると約1/3となっています。グラフを見ても一目瞭然ですが、この在庫量は劇的な効果の証と言えるのかもしれません。

Graph32
今回・簡易プル型
Graph22
前回・オールプッシュ型


 20日稼働を想定した最終日における各工程の在庫量についても、ボトルネックとなる工程Dにて仕掛在庫のダブつきがみられるものオールプッシュと比較するれば、大幅に削減されているようです。また、制約前の工程A〜Cについてもその在庫量のばらつきが抑えられており、簡易的ながらもプル型のライン投入が大きく寄与していることが見えてきました。

Graph33
今回・簡易プル型
Graph23
前回・オールプッシュ型

 これまで、『ザ・ゴール』ものは全て読んでいますが、実際にざっくりながら、表計算ソフトで机上ながらも動かしてみると、「ふむふむ」と思う気持ちもより深くなるかと思います。
 私自身、製造業の現場にいた当時は、なるべく広い視野を持とうと心がけてはいましたが、やはり自部門がかわいいもので部分的な最適化に比較的力が入っていたかと、今思えばそんな感じです。

 私はTOC信者でもなく、またTOCの専門家でもありません。が、こうやってみると、中間管理的な立場であれば、部門に属していようが全体として何ができるかを考え、自分(自部門)として弱い部分にどのような貢献ができるのかというような、「よそ様のお庭の状況を真摯にに見てあげて、行動を伴う助言」も必要なのだろうと感じました。

 また、上級管理的な立場であれば、「全員が100%であることがベストではない」という一例として見てもよいかもしれないとも思います。

 私自身、ITの開発工程においても、これまでの製造業的ものづくりにて培った方法論から学ぶ姿勢はあってしかるべきだと思います。

Comment(0)