豐田生產方式：愛惜老舊的設備

大野耐一在他的書中說，會計用語的折舊費、帳面價值，是為了會計與稅法方便而定出來的概念，但大多人忘記它跟設備實際的使用價值沒有一點關聯。混淆了這點，就會有以下的錯誤想法：

• "這個設備早就折舊完畢，任何時候都可把它丟掉"
• "設備的帳面價值已經等於零，若在這個設備上花錢改造，無疑是賠錢，不如換部性能好的新機器"

其實設備價值不在於形式的新舊或是出廠年份，而是看可動率的高低。幾十年的老舊設備可能因為保養得宜，至今仍維持100%的可動率，那麼價值並沒有減少。去年買的新機器如果常出問題，只有50%的可動率，那它的價值只有50%。

他書中沒有強調，但我覺得也要考量的是，新設備牽涉到新的操作流程的制定、操作方法的訓練、保養方法的訓練等成本，而且新設備穩定性也是未知的風險，這些因素都不該過於輕忽。

在軟體這一行做類比，設備不是只對應到電腦、印表機等硬體設備。使用的開發工具、Frameworks、各種工具程式庫等等，也有類似設備的地位。各種新技術推陳出新速度很快，像我過去幾年來參與的專案，所用的Java網頁技術就經歷過了純Servlet、Servlet+JSP、前兩者＋EJB、放棄EJB改用Struts、Webwork、Struts2等等。雖然在Open Source的時代，這些Frameworks是免費的，但是追逐各種新技術與新架構，花費的成本回想起來非常可觀。加上新的開發方法與工具會需要更高效能的PC來配合，作業系統不斷改版，JDK也是每一兩年就有一次的大改版。總而言之，做我們這一行總是有很高的成本投入在軟硬體更新以及開發架構的典範轉移上。

約爾談軟體裡面有一篇叫做『邊開火邊移動』。他說的不完全適用於我們身處的Open Source世界，不過仍有參考價值。他說步兵作戰最重要的是邊開火邊移動。就是移動時要對敵軍開火，讓對方低頭閃避就不能開槍打你。敵軍對你開火，即使不能殺死你，至少也可以阻止你快速前進。這段文字他寫得真好：

想想看微軟所推出資料存取策略的歷史吧。ODBC，RDO，DAO，ADO，OLEDB，還有最新的ADO.NET - 全部都是新生的！難道這些技術都是非要不可的嗎？還是一個年年都在重新發明資料存取的無能設計團隊的傑作呢？(這很可能是真正的答案。) 不過最終的結果卻剛好成為火力掩護。它讓競爭者別無選擇，只能用盡所有時間進行移植和昇級，沒有時間去寫新功能。仔細看看軟體業界。成功的公司對大公司的依賴最少，不需要花所有工夫追隨並重新實作，然後去修那些只出現在Windows XP上的問題。而跌跌撞撞的公司都花太多時間去揣測微軟未來的方向。大家都擔心.NET的出現，認為有絕對必要所以決定針對.NET重寫整個架構。事實上微軟是在對你開火，而且只是讓他們前進並阻礙你們的掩護火力，因為這就是遊戲規則，朋友。你想支援Hailstorm嗎？SOAP呢？RDF怎麼樣？ 你支援這些東西是因為客戶需要？還是因為有人對你開火而覺得應該有所反應呢？

大公司的業務團隊很瞭解火力掩護這一套。他們會去跟客戶說「沒錯，你不一定要買我們的東西。要買就要買最好的。不過記得你買的產品一定要支援(XML /SOAP / CDE / J2EE)，否則你就會被綁住了。」然後當小公司試圖接觸這個客戶時，這個聽話的技術總監就會像鸚鵡一樣說「你們支援J2EE嗎？」

儘管J2EE不會真正帶來收入，他們還是得耗盡所有的時間加上J2EE，結果完全沒機會讓產品產生區別。這是個勾選項目，會去做只是因為需要有個項目打勾表示你也有，不過沒有人會用也沒有人需要。而這就是掩護火力。

我們如果被迫換的不是微軟的新架構，而是Open Source的技術時，不一定代表有敵人刻意朝我們開火，但相同的是我們仍然會因為低頭躲砲火而不能前進。如果能儘量避免跟著這些趨勢起舞，軟體公司才有餘力讓產品往前進步。

我是看大野耐一這本書時才覺得似乎真的悟出其中道理了。大野耐一聽到汰換老舊設備的要求時，會先徹底檢討『更新設備效益的計算有沒有敷衍』，『舊設備的保養有沒有錯誤』。在他的經驗，『舊設備技術上沒辦法讓它到達我們要求的精密度』或是『舊規格零件已經找不到』的說法，不一定禁得起詳細研究與檢討。

在我擔任研發主管的期間，顯然在技術更新的判斷上就不夠專業了。老舊架構造成的不方便一定會有，但是新Framework還沒經過足夠的時間考驗，難道不會有問題嗎？確定不會很快地被更新的架構淘汰嗎？舊架構下開發的程式碼是有缺點，不好維護或是不容易理解。但是這當中有多少成份是程式技術該去克服的，多少成份其實與舊架構無關，而是當時資淺人員沒有把程式寫好所致？這是小小的不方便，還是嚴重地影響團隊效率呢？這些問題，我並沒有仔細地探究。

事實上，我自己跟其他技術人員一樣，喜歡試新玩具。現在回想起來，應該要省掉更多典範轉移的成本，將這些成本投入在產品本身的改善。與其每一兩年就訓練工程師學新的Framework，不如讓大家更專注在TDD、Refactoring等技術上，或是加強研發人員最不願意觸碰的Javascript。