分析工程師

分析工程師 (Analytic Engineer) 在台灣目前的就業市場，是幾乎不存在的職缺，而我認為將來很多公司會開出這個職缺。

友人的公司請我去給了一場演講，談「現代資料棧」(Modern Data Stack)。在演講結束之後的提問時段，討論最激烈的問題是關於『分析工程師』(Analytic Engineer) 這個職缺。

「現代資料棧相當不錯，只是本公司目前還沒有一位適合來擔任分析工程師的人選，而這是導入最大的困難點之一。你說，這位要受訓成為分析工程師的人選，最好是來自業務部門，嗯，所以我們要設法去業務單位去找到一位有能力、而且有意願學習程式語言的人嗎？」最先問這個問題的是現場的高階主管，臉上露出的神色似乎是在告訴我，這也太困難了吧？

「我們可以讓本來懂業務的人，受一些程式語言的訓練，讓他成為分析工程師；也可以讓本來會開發軟體的人，去深入地了解業務，讓他成為分析工程師。然而，其實業務單位已經有會寫程式的人了，根據我的經驗，每一個業務單位，總是會有一兩位用 Excel 用得很好的人，他們就是已經會寫程式的人，因為 Excel 就是一種程式開發的環境。」我提出了我的答案。

資料基礎建設

現在的企業，使用資料的頻率比過去多得多。使用資料多了，就容易得到下圖的狀況。在下圖之中，有三個不同的資料來源與二個不同的使用資料單位，且每個要使用資料的單位，就是自己任意地去組裝資料。可想而知，這個情況會隨著資料來源與使用者愈來愈多，之後變得非常複雜。

理想的情況，應該要減少重複的工作被不同的人一再地重做。畢竟，上圖中的每一條線，都是 ETL (extract, transform, load)，而 ETL 要維護是很繁碎的工作。如果有做了「資料基礎建設」來統一整合資料，就會變成下圖。(現代資料棧就是做好資料基礎建設的解決方案。)

資料專案的分工

資料基礎建設一端服務的是資料的使用者、另一端則是眾多的原始資料來源。要能做好資料基礎建設的人，一方面需要操作資料的專業，另一方面，也非常需要資料如何被使用的領域知識。

類似的問題，在應用軟體開發的情況，會有所謂的專案經理來負責與使用者的溝通。專案經理必須決定軟體專案要有哪些功能、功能開發的先後順序等等。實務上，專案經理很難把工作真的做好，常常夾在開發單位與需求單位之間。

在資料的領域，由於 ELT 的出現，我們可以有了全新的分工方式。我們可以把 EL (Extract, Load) 部分的工作，交給資料工程師負責。而 T (Transform) 的部分工作交給分析工程師。當分析工程師唯一只需要會的程式語言只有 SQL、所有需要懂的軟體開發技巧只有資料轉換、他相對於一般的軟體工程師，埋首於開發軟體的時間可以大幅減少，也因此可以花費更多的心力去與使用者開會、去了解使用者應用資料的情境。換言之，資料的領域由於有了 ELT 與分析工程師，我們不用設計一個職稱，叫做資料專案經理，專門負責溝通。新的分工方式，讓分工更加專業、也讓無效率的會議可以大幅減少。

結論

管理學普遍認為，職缺的設計是經營成效的重要關鍵。有設計良好的職缺，人的能力只要可以填滿職缺的需求，組織就可以產生效能，也因此可以做到『讓平凡的人做出不平凡的事』。

以資料基礎建設來講，分析工程師 (Analytic Engineer) 職缺它一方面所需要的知識深度，軟體與領域知識各一半，並不會困難到難以培訓。一方面，它又可以巧妙地成為資料基礎建設工作流程之中關鍵的一環。也許分析工程師此時此刻因為太過少見，而讓企業暫時還沒有做出回應，然而，假以時日，隨著現代資料棧的普及，這個職缺自然會愈來愈常見。