豐田生產方式：剛好及時 Just in Time

(2008/5/16改版)

什麼是Just in Time?
Just in Time簡單地說，就是"必要的零件，在必要的時刻，只有必要的數目"。零件只是及時(in time)生產還不夠，如果零件太早到達，堆積在生產現場會影響效率，如果零件太多，會佔據工作空間及增加整理、清點等負擔。所以及時前面還要加上剛好（just）這個字：不只要有，還要剛剛好：不早不晚，不多不少。

TPS著重於排除一切浪費。過度生產是最大的浪費，光是庫存的成本就很高。更可怕的是，過度生產會掩蓋住其他組織內的浪費不被發現。Just in Time的觀念，就是要將零件的庫存降低到幾乎為零。但這要怎麼達到呢？


推式系統與拉式系統
傳統生產控制可以用"推式系統"來形容：由前段製程生產的物件，送往下一個製程。所以稱為『推』。1950年，豐田廠長大野耐一想出一個做法，完全是反其道而行，稱為拉式系統。後段製程依照需求向前段領取；前段製程依後段的要求而生產。由於主導權在後段製程，所以稱為『拉』。

推式系統很容易造成過度生產。從最前端的業務端而言，如果銷售速度不夠快，成品的庫存就造成壓力。如果是某個生產環節出了問題，例如有瑕疵或是缺原料，而其他上游繼續生產，則會快速產生堆積如山的半成品。有一本暢銷書『關鍵鍊』就從制約理論詳細分析生產線瓶頸的問題。不過TPS的拉式系統，是從更根源來處理這個問題。

所以拉式生產的觸發開關是交易。業務賣出一台車，就開始生產。組合車輛的最後製程觸發各組件製程，各組件又觸發上游的製程等等，依此類推。

Just in Time實際運作方法
拉式系統實際的運作方式類似便利商店。你在便利商店結帳時，你買的物品會登錄在收銀機電腦中。便利商店店長會查看紀錄，依售出的數量向總公司進貨，但如果尚有存貨會先補充上貨架。總公司會再向各供應商下單。這整個流程是由你結帳的動作觸發的。

一部汽車的零件有幾萬個，有非常多零件依靠供應商提供。所以JIT的機制不是只有豐田汽車實施，而是要供應商一併實施，整個產業上下游一起享受JIT帶來的避免浪費以及競爭力強化。

TPS的工作概念也與一般生產線不同。一般認為生產製造就是在工作。而TPS卻認為沒有即時產生附加價值的工作就不算工作，而是浪費。浪費了倉儲、運送等成本。只有做出東西很快地賣給客戶，才算是工作。

軟體過度設計的浪費
現在我們回頭看軟體開發，常見的過度生產是設計。技術人員往往會有over design的傾向。設計一個類別，希望一次就到位。為了考慮未來的所有的需要與變化，引進複雜的設計樣式，讓它具備擴充的可能性。不幸的是，未來常常不朝我們預期的方向走，擴充性可能永遠用不到。這時預留的彈性就變成另一種形式的庫存。讓程式碼變太長太複雜，太難懂。從TPS的觀點，還沒用到就預先過度設計，不算是工作，而算是浪費。

而XP主張的simple design，就是要避免這樣的過度生產，也讓寫出來的程式碼及早反應在真實系統上，實現有價值的scenario。Agile方法中，系統做功能延伸要經過兩個步驟：

1. 不改變系統行為，只refactor架構，直到要做的延伸很容易放進來。
2. 實做功能延伸

我們注意到，這就是要將擴充性留到真要擴充前才refactor。也就是說，延伸前一刻才設計。所以這是just in time的拉式系統。

延遲整合的浪費
還有一種情形，就是預先寫好程式碼，但是遲遲不能整合、執行與測試。（尤其是有一類型專案經理，只喜歡對甘特圖思考，而不喜歡直接從玩系統來了解專案進展，他們的專案最常有這種問題。）工程師看起來每天產出大量的程式碼，但是幾個月後整合時往往發現臭蟲很多，或是有誤解需求規格的意思，或是其他子系統的介接有問題。回頭看前幾個月的努力，也只能說是浪費，而不是工作。過去他們在甘特圖上呈現的進度只是假象。反觀Agile方法就不容許程式碼延遲整合。例如Continuous Integration，就是讓新程式碼不斷地整合與自動測試。

需求文件的浪費
另一種常見的過度生產是需求規格。尤其是Waterfall流程，一次列出全部的需求規格，並不區分優先順序。要等到系統建置完成上線後，才能驗證這些需求是否如當初想像地有價值。可是這麼長的時間，可能發生很多變化。計畫的時程與預算可能改變，使用者對作業的了解會變得比當初更清楚，而對需求有更好的想法。如果一開始就鉅細靡遺地列出所有需求規格的細節，到實做時通常都會有許多變動，那麼當初對細節的釐清、溝通以及文件等成本就造成浪費。（我們不是因為不喜歡這種浪費，而常抱怨客戶變更需求嗎？）XP將需求切割為user stories，儘可能讓每個story都有獨立的商業價值。一個Iteration只有一週，所以提出的需求規格在幾天內都可以驗證。這也是Just in Time的精神。

XP主張客戶參與開發
軟體開發牽涉到的"上游供應商"，主要是客戶。客戶提出需求，開發團隊才進行開發。由於Just in Time要供應商一起參與才能發揮最大效果，XP主張讓客戶與開發團隊在同樣的辦公室一起合作，做Iteration Plan以及Acceptance test。所以XP的方法，是與供應商一起完整執行Just in Time的方法。