兩個政府資料集，一份土地報告，零個分析師

以前要做一份土地報告，得從一個地方調地籍資料、從另一個地方調實價登錄，再用人工拼成客戶看得懂的東西。那是幾個小時的工，而且每次做法都一樣。

現在一個 app 就做完了。你搜一個地號，它建出候選清單、附上實價登錄的比較案例，然後編成報告。

兩個政府資料集，一份輸出。Demo 四十秒，效果很好。

Demo 不等於專案

政府開放資料不是一個有 API、有客服合約的資料庫。它是一些機構發布的檔案，那些機構對你沒有任何義務，格式是照他們自己的理由決定的，而且會在沒人預告的時間點改變。

真正吃掉時間的是這些：

• 兩個資料集用不同方式描述同一塊地。 地籍和實價登錄對「一筆土地是什麼」不一定有共識，而且兩邊都沒錯。總得有東西每次都用同一套邏輯做決定。
• 什麼才算一個有效的比較案例。 大家會以為這是查表。它其實是關於距離、時間和使用分區的判斷——判斷錯了，報告會很有自信地沒有用，那比一份空報告更糟。
• 資料不足時報告要說什麼。 有些地號附近根本沒有近期成交。誠實的輸出是明講「這裡沒有資料」，而不是拿最近的東西湊一個估值出來。

最後這一點決定了整個設計。一份從不承認資料缺漏的報告，遲早會被抓到。而一個估值工具被抓到一次之後，那間辦公室就再也沒有人會打開它。

自動化是把工作往前搬，不是消滅它

有 app 之前，人的時間花在拼裝。有 app 之後，時間花在決定「資料不配合的時候工具該怎麼辦」——而這比 demo 看起來的頻率高得多。

這是這筆交易誠實的版本。你沒有刪掉工作。你把它往上游搬，從重複性的變成需要判斷的，而且只做一次，不是每份報告做一次。這划不划算，完全取決於你要產出幾份報告。

一個月一份，不划算。一個月五十份，很明顯划算。有意思的都在中間，而該問的問題不是「這能不能自動化」——幾乎什麼都能——而是「這件事我們還會再做幾次」。

換到你身上不成立的部分

台灣的地籍和實價登錄資料是以可用的形式發布的。這是一個真實的優勢，而且不是每個地方都有。土地資料的品質各國差異極大，在登錄不完整或不是機器可讀的地方，這個專案會變成一個穿著軟體外衣的資料取得問題。

在估算類似的案子之前，先去把原始檔案拿下來打開。文件不算。要打開的是檔案本身。一個資料集「被描述成什麼」和「實際裝了什麼」之間的落差，就是這類專案出事的地方，而查清楚只要一個早上。

*這項工作由老魚（余啟彰）在他自己的實務中完成，時間在 FDE Taiwan 之前與並行。它屬於團隊的合併實績，不是 FDE Taiwan 的客戶案子。*

政府資料的管線工作不好看，而且它就是這份工作的大部分。如果這是你問題的形狀，那正是派駐式工程存在的理由——有個人進到你的團隊裡把它接起來，而不是跟你描述它。