豐田生產方式：自働化

（2008/5/16改版）

要自動生產也要自動停止
自働化一辭的解釋是，舊有的自「動」化生產要再加上「人」的感應力跟判斷能力，所以用這個怪字。簡單說，除了自動生產也要自動偵測問題後停機。我不了解日本人對漢字的感知，無法理解這個詞的奧妙之處。可是姑且不論字詞是否妥當，自働化的概念是很了不起的創舉。

豐田原先是做織布機起家。當時織布機織布，如果絲線斷掉的話，就必須重織一遍。豐田佐吉發明的織布機，如果線斷了或是用完，會自動停機，絕不生產瑕疵產品。

自働化的特色
這個理念到了TPS汽車生產時，做了更進一步的推廣。自動生產設備會同時自動偵測瑕疵，一有瑕疵就立即停機，不持續產出瑕疵品。另一方面，如果任何工作人員發現瑕疵，也應立即中斷生產線。所謂中斷，不只是停這台機器，而是整廠生產動作全部停下來，免得其他零件生產過度，造成庫存。大家一起找出問題的根源，調整設備或流程讓問題不再出現。然後才繼續生產。這個做法有幾個特色︰

1. TPS重視排除浪費。瑕疵是很大的浪費。對付瑕疵需要額外的品管能量。瑕疵造成信任的問題，增加管理的難度。萬一瑕疵品到客戶手上會造成客服成本及商譽上的代價。不像一般的生產線管理，設個品管的關卡，將不良品剔除；TPS排除瑕疵的作法，是從根源讓不良品絕跡。也可以說，TPS的整個團隊都是品管與流程改善的團隊。
2. TPS認為庫存是一大浪費，每個零件都應該一生產出來，就該在最短的時間內組合進成品，交到客戶手上。所以一個環節停止，就整廠都停止。
3. 整廠中斷生產，也是突顯問題的一種極端手法，展現根除瑕疵的決心。一有瑕疵，不只是修復，而是作業人員一起分析出問題根源(Root-Cause analysis)，修正設備或改善流程後才重新啟動生產。反之，如果是人站在機器旁，一遇到異常就用人工取代機器，表面是維持產能，實質上卻掩蓋問題，永遠消除不了異常。
   
4. 要做到這個程度，前提是平時瑕疵率就該降到非常低。瑕疵是很罕見的，才能那麼認真地處理每一個瑕疵。如果每天都發生二十個瑕疵的話，可能整個生產就會完全停擺。
5. 哲學一點來說，TPS看待每個零件都不只是零件。零件上同時也附帶著生產管理的資訊，告訴你生產線是否正常運作。
   

不信任是最大的浪費
以軟體的觀點來看，瑕疵（臭蟲）造成不信任，不信任是許多浪費的根源。專案經理跟工程師間不信任。客戶跟開發團隊間不信任。傳統軟體工程的各項措施，如各式文件與會議、peer review、稽核、測試等，都是源自不信任。

Extreme Programming應有超低的瑕疵率
Extreme Programming雖然省下了許多傳統軟體工程的文件以及繁文縟節，但是對於瑕疵卻是不惜各種代價要消除。pair programming、continuous integration、客戶參與、自動測試等等，都是為了消除瑕疵。Kent Beck在他的書Extreme Programming Explained第二版中提到，一個成熟的XP團隊，每個月只會遇到一兩個瑕疵。

用Continuous Integration自動偵測
Continuous Integration就是自動偵測瑕疵的機制。如果失敗，像TPS自働化一樣，團隊必須將修復它視為最優先的工作。不過不見得有必要到停止所有開發活動，因為不一定有因瑕疵而導致半成品堆積的危險。

由於Continuous Integration測出的問題做修正，算是開發的正常過程；其實Agile團隊的用語裡，瑕疵指的是沒有被自動測試覆蓋到的問題。

瑕疵處理
XP怎麼處理瑕疵呢？簡單說步驟如下，讓同樣的問題永不再發生︰

1. 補充自動整合測試，讓它測出這個瑕疵
2. 補充自動單元測試，讓它測出這個瑕疵
3. 修正程式，讓程式通過單元測試與整合測試
4. 做根源分析，檢討流程的不足，讓這類產生瑕疵的原因絕跡
   

根源分析︰五個為甚麼
Kent Beck書中還解釋根源分析，跟TPS一樣要問自己五次為甚麼：

• 為甚麼這個瑕疵沒被測到？ 因為我們不知道加總結果可能是負數。
• 為甚麼我們不知道加總結果可能是負數？ 因為這只有Jack了解，但Jack不在我們Team
• 為甚麼Jack不在我們team? 因為他還在另一個舊專案，只有他會。
• 為甚麼只有他會？ 因為高層不願意幫所有人辦教育訓練
• 為甚麼高層不願意幫所有人辦教育訓練？ 因為他們不知道花兩萬元成本很可能可以省下五十萬
  

以我個人參與過的XP專案，瑕疵率都還過高，可能跟自動測試沒做好有關。不過，軟體瑕疵率要降到一個月只出現一兩個，這真的有可能嗎？其實瑕疵量的多寡，除了反應系統的穩定度以外，也跟使用人數及使用量有關。有的瑕疵是跟瀏覽器版本有關，有的瑕疵只會發生在某些語系的作業系統。個人的看法是，需要做根源分析的瑕疵，應該還是需要挑選過。