香港大火敲響台灣警鐘:當消防變成「技術債」,我們還有多少時間?

香港大火不是意外,而是一筆被拖延多年的「消防技術債」一次性爆炸。老舊設備、易燃帆布、被塞滿的逃生通道、年年未測試的火警系統──這些看似小問題,累積起來就是奪命的系統性風險。
真正可怕的不是沒有設備,而是沒有人知道它還能不能動。台灣許多大樓也有同樣盲點:透明不足、檢查走形式、改善永遠拖延;看似安全,只因文件上蓋了章。
香港已經用生命提醒我們:限期改善不是改善,文件上的「完成」救不了人。每一棟大樓都需要一位真正把安全放第一順位的人,否則風險會持續累積,直到某一天再也收不回。
台灣還有多少時間?答案就在我們願不願意現在開始還債、每 30 天讓大樓更安全一點。

註:本文經災難醫療與救災防治專家石富元醫師審閱/提供建議

如何用Scrum 災害防治
如何用Scrum 災害防治

香港大火:不是意外,而是複雜系統被迫揭露真相

畫面裡的火光混著濃煙,不只是香港的災難,更像是一座城市被迫揭開真相的瞬間。
那不是一場「意外」,而是多年累積的複雜系統,在某一天徹底失衡。

我們其實都明白:建物完成之後,就會逐漸老舊,其消防安全,一直像是一筆越滾越大的「技術債」。 只是我們不願面對,不知道什麼時候應該要處理。也沒有系統能迫使我們面對。

AnyConv.com S 10944628 0
香港大火現場示意圖——複雜系統在壓力下瞬間崩潰,是多年技術債累積的極端後果

在教 Scrum 時,我常說敏捷不是工程師的方法,而是面對複雜世界的方式。香港這場火,正是這句話最沉痛的註解。 當你把城市消防安全視為一個「產品」,整個城市的問題會瞬間變得清晰── 我們缺的不是法規,而是長期欠下的技術債。

消防安全就是技術債:忽略越久,代價越大

這些技術債長什麼樣子? 像是「設備還能用就先不換」、 「帆布不耐燃沒關係先完工」、 「逃生通道之後會清」、 「火警偶爾不響應該還好」、「法規的安全標準沒有出大事就不用去提高」… 不是不知道,而是被忽略太久。

技術債有一個特性: 你越不處理,它越會在最糟的時刻爆開。 香港這場火,就是一次典型的技術債破產。

如果願意承認老舊大樓本來就會累積風險,那麼主管機關的角色就不能只是「開罰單」。 他們真正應該做的,是協助每一棟大樓制訂一份能被落實的「償債計畫」。 讓改善成為連續動作,而不是一次性的口號。

AnyConv.com S 10944629 0
老舊大樓的技術債日益累積,風險已悄悄成形

透明不足:城市消防最致命的盲點

而要償債,第一步永遠是透明。 Scrum 把透明視為第一支柱,因為沒有透明,就沒有檢視,也沒有辦法調適。 然而,台灣與香港的問題恰好都出在這裡── 資訊都在,但沒有人看得到。

  • 大樓的消防設備幾歲了?
  • 外牆帆布是否阻燃?
  • 防火區劃是否被破壞?
  • 火警系統上次測試是哪一年?是否落實?

 這些不是不存在,而是散落在報告、櫃子、會議紀錄、廠商文件裡。 住戶不知道,管委會不追蹤,主管機關也無從掌握。

在 Scrum 裡,透明的目的不是責備,而是讓所有人能站在同一份「真實」面前。 沒有真實,就談不上改善。

檢查 ≠ 檢視:簽名不會救命,演練才會

然而即便有透明,檢視本身也常常流於形式。 我看過太多城市與企業的演練,外表認真,內部潦草。表格填一填、章蓋一蓋,演練走一走,年年如此。但真正出事的時候,我們都心裡清楚:那些檢查根本不算「檢視」。

Scrum 的檢視強調固定節奏、誠實呈現,以及會觸發改善行動。 如果我們把每次消防安檢當成 Sprint Review,就必須問: 這次檢查,是否真正拉近我們與「更安全的大樓」之間的距離? 還是只是又多一份「看似已完成」的文件?

真正的安全,不是靠文件,而是靠演練與實測。你踏實做過的,才算數。

然而就算看見問題,要改善也往往太慢。限期改善看起來合理,但半年的改善清單往往卡在:產權、費用、排程、住戶意願、決議協商。 最後期限到了,什麼都沒動,或是進度嚴重落後。這不是惡意,而是系統本身做不到。

AnyConv.com S 10944627 0
設備老化、外牆帆布與阻燃材料檢測不足,形成城市版的「技術債」——越拖越危險

Scrum 式改善:30 天讓一棟大樓真正變更安全

Scrum 告訴我們:在複雜環境裡,最有效的方法不是大型計畫,而是「小步快跑」。 如果把限期改善換成 Sprint 節奏── 每 30 天完成一件具體、可驗證的改善── 整個城市都會變得不一樣。

  • 這個月清空避難逃生動線。
  • 下個月全面測試火災警報系統。
  • 再下個月更換不耐燃的建材及物料。
  • 再下一個月進行避難演練和動線調整。
  • 一年後,大樓會比現在安全十倍。

不是因為做了什麼大工程,而是因為「持續變好」。

誰是這棟大樓的 PO?──安全需要真正負責的人

但要變好,必須有人負責排序。Scrum 把這個角色叫 Product Owner(PO)。PO 是那個能說「等等,這件事最重要」的人。

然而在大樓裡,最缺的就是 PO。管委會由住戶輪流擔任,專業不足;預算永遠不夠,改善永遠延後;外觀整修比內部安全更容易被支持。大家都關心,但沒有人「負責」。

也許未來台灣需要新的制度:高風險大樓需要「外部 PO」; 一定規模以上的大樓需要「專業防災 PO」。只有有人真正負責,改善才會發生。

香港大火帶來的提醒是殘酷的──我們不能再只用「依法行政」的邏輯治理複雜系統。消防安全不只是年度檢查,而是一個需要長期維運的產品。

Scrum 恰好提供了三個非常實用的啟發:

1.承認技術債,把改善拆成小步驟
2.並讓 PO 決定優先順序去完成
3.透明、檢視、調適,看似簡單,但卻是少數能讓複雜系統「真的變好」的方法

透明、檢視、調適,看似簡單,但卻是少數能讓複雜系統「真的變好」的方法

以 Scrum 的 30 天節奏拆解改善項目,比「半年一次限期改善」更能真正降低大樓風險
以 Scrum 的 30 天節奏拆解改善項目,比「半年一次限期改善」更能真正降低大樓風險

香港是一面鏡子。照見的不只是我們未來可能面臨的風險, 也照見我們還來得及選擇的道路。

Scrum 不是用來預防所有災難的。但它提供了讓我們在複雜世界裡「持續變得更安全」的方法。當城市願意把安全當作產品來管理、願意還債、願意小步快跑──我們就不必在下一次新聞裡,再次用「又一場悲劇」來提醒彼此。

願我們從這次開始,真的學會。

註:感謝災難醫療與救災防治專家石富元醫師的審閱及提供建議