『ザ・ベロシティ』のサイコロのゲームをやってみた　３　〜まとめ：１００％がベストではない〜

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

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

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

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

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

　繰り返しになりますが、工程Ａ〜Ｇまでの７つの工程を設定し、正七面体（実際にはありえませんが）のサイコロの出目により各工程の生産指示と想定します。７つの工程中、６つの工程ではサイコロを２つ振ることなるため、出目は２〜１４までとなり期待値は８です。ただし、工程Ｄ（４つめの工程）についてはサイコロを１つ振るとしており、出目は１〜７まで期待値は４となります。つまり、工程Ｄがこのラインのボトルネックとなるわけです。

　同ラインでの生産量について、前回のブログで示していますが、１０回の試行で平均は約７８（前回は誤植でした。すみません。）、在庫量は平均で１０６と、約３．８倍になっていました。

　さて、今回ですが、同著シリーズで指しているボトルネックへの対策として有名（？）な方策を取ります。まず、ボトルネックの直前の仕掛品は、ある程度十分な量にするというものです。これまでの試行では、７つの全行程は共に仕掛品として４を設定していましたが、今回、ボトルネックとなる工程Ｄについては、その３倍の１２を設定します。つまり、工程直前の仕掛品は、工程Ａ〜Ｇまで、４・４・４・１２・４・４・４となります。
　次に、工程Ａへの投入量に細工をします。これまでは、購入量も同様にサイコロを１つないしは２つ振った出目としていましたが、今回は、ボトルネックとなる工程Ｄの生産指示と同じ量を投入量とします。工程Ｄではサイコロを１つ振りますので、その出目と同じ数だけ工程Ａに投入されるということになります。なお、工程Ａ〜Ｃについては、同様にサイコロは２つ振るものとしています。

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

　結果は、次の通りとなりました。生産量ですが、最小６３最大８４で平均が約７３となり、前回の方式をオールプッシュと呼ぶのであれば、やや減少（約６％）しています。

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

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

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

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

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

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