《失敗的本質》在日本是非常有名的一本書。作者透過分析二戰期間日本陸海軍的種種挫敗，當成一面鏡子，讓讀者看到一個組織如何在制度、文化與流程上逐步自我削弱。雖然是分析日本陸海軍的問題，但裡頭的成因分析也很適合用在組織裡。

失敗常常不是一個瞬間的錯誤，而是長期的制度性失衡和文化慣性的結果

在專案進行中，失敗通常不是單一原因造成，而是從小地方累積而成。

這邊列舉幾個有提到的原因：

• 權責分散
• 資訊封鎖與過濾：下層不敢回報實情
• 重視精神論勝於物資
• 教條化
• 缺乏反省與改進

當一個組織習慣於遮掩壞消息、崇尚服從而非質疑、或將成功指標狹隘化為單一量化目標時，它會在外部壓力來臨時顯得非常脆弱。

作者用案例拆解這些效應，試圖說明若不修正結構性缺陷，單靠個人的英勇或臨時湊合是無法逆轉整體趨勢，更不是武士道精神就能扭轉戰局。

軟體開發

資訊

像是當下層工程師不敢回報風險或使用者痛點時，高層會基於扭曲的資訊做決策。

假設不是站在第一線的開發人員，對任何問題的第一反應都是：「這個功能（隨便代入）那麼簡單，為什麼要做那麼久？」

但大部分的軟體規格，本來就是非常不明確且隨時會變動的，寫程式當中也有許多需要探索的部分。在開發的時候不只是單純把功能實現出來而已，還需要考慮到歷史因素，如何整合到現有程式碼，怎麼讓之後的開發更順利。

不要陷於過去的成功

在 LLM、AI 不斷進步的時代，很多做事的方法會逐漸轉變，在這個時代下知行合一是個很棒的做法。但不要因為過去的成功就不懷疑，或是不做任何檢討與改變。

從失敗當中學習

在軟體開發上一定會遇到 Bug / 意外等等。在比較有規模的公司當中通常會有 Incident 報告機制。假設今天系統突然掛掉無法開機。開發者、上層的反應是什麼？是生氣、推鍋、找戰犯，還是有一套標準流程，可以將意外造成的損害降至最低？

發生意外時最沒用的解決方法就是情緒化。

要從失敗中學習經驗，讓這次犯的錯不要再發生。要做到這件事，管理層需要做到不責備任何人的環境，而是從中找解法。

• 產品是大家的，把錯推給一個人代表公司制度有問題
• Codebase 是 RD 全體的歷史共業，如果把錯誤都歸因到特定的人，同樣也代表沒有好的開發流程

多年前曾經在 Reddit 很紅的文章——Accidentally destroyed production database on first day of a job, and was told to leave, on top of this i was told by the CTO that they need to get legal involved, how screwed am i?

內容講述著這位新員工在第一天不小心把生產環境的資料庫刪除了。他在某個步驟當中沒有把工具輸出的值複製上去，而是使用文件中記載的環境變數，而這個環境變數是指向生產環境的。最後這位員工當場被 Fired。

不知道大家看到這個故事的想法是什麼？是這個員工怎麼那麼粗心，都不檢查值是否正確；還是覺得一位開發者犯這種錯實在是太誇張了？如果都是用這種心態在看待事情，反而會因為意外的到來而大受打擊。

一家公司存著僥倖心態，沒有為生產環境的資料庫備份，本身就是一件早晚要付出代價的事。只有掉資料了才知道備份的重要性。一位新進員工居然可以輕鬆地把生產環境資料庫刪掉，這也代表著總有一天其他員工也能做到。

在眾多留言中，也有人分享 Netflix 的做法。

詳細情形我忘記了，但就以印象而言，他們不僅平常會演練災難發生時要如何快速備份。甚至在平時就把權限設定得很好，還鼓勵員工只要可以弄壞生產環境資料庫就給獎勵。

同樣一個問題，有公司就先責備；有公司從制度、流程下手避免人為錯誤。

不要仰賴於口號

口號需要搭配制度落地，才算是對口號的尊重。舉例來說「快速迭代、小步快跑」為口號的公司，常常就只是壓榨開發產出的藉口，而完全不尊重工程師的專業。

如果真的要落實的話，可能會體現在幾個地方：

• 對 CI/CD 相當重視，讓開發者可以無痛部署
• 知道開發速度有其極限
• 為了讓開發者可以專注在開發上，將所有基礎建設做到完善
• 重視文件與流程的建立
• 知道快速迭代下必定犧牲一部分的品質