會查這個職稱的人，動機通常有三種。有人正在看職缺，想知道進去之後每天要面對什麼；有人是公司裡決定要不要開這個缺的主管，煩惱該怎麼寫工作說明、又該怎麼判斷面試者的深淺；還有人是被指派去對接技術的窗口，想弄懂對方在講什麼。這個職稱之所以難定義，是因為它在不同規模的公司差距極大：在大公司可能只負責某個模組，在小公司卻得從需求訪談做到伺服器維護。這篇把工作內容、能力分層、判斷方式拆開來談。
同一個職稱，在不同公司差很多
在有專責分工的組織裡，這個角色多半接手已經定義好的規格，負責實作特定模組，前後有產品企劃、測試、維運各自的人。在中小企業，同一個人往往要同時處理需求釐清、資料庫設計、程式撰寫、部署上線，甚至接電話處理使用者的問題。
所以看職缺或寫職缺時，重點不在職稱，而在三個問題：這個位置前面有沒有人幫忙定義需求、後面有沒有人負責測試與維運、系統上線後由誰處理。這三題的答案，決定了實際工作內容與需要的能力組合。
寫程式只佔工作的一部分
常被低估的是溝通與釐清的時間。使用者說「這裡要能改」，背後可能是誰能改、改了要不要留紀錄、改完會不會影響已經送出的單，這些都得問出來才動手。實務上一段功能的時間分配，大致落在理解需求、設計做法、寫程式、自己測試、修正回饋這幾塊，寫程式往往不是最花時間的一段。
此外還有大量維持性的工作：查為什麼某筆資料算錯、處理環境不一致造成的問題、把別人寫過的程式讀懂再改。這些事在職缺說明上很少寫，但佔比不低，也是這個工作最需要耐性的地方。
能力可以分成三層來看
- 語言與框架層：能把邏輯正確地寫出來，理解錯誤處理、非同步、例外狀況該怎麼收。這一層最容易被檢驗，也最容易靠練習補上。
- 資料層：能設計出合理的資料表關聯、看得懂查詢為什麼慢、知道交易與鎖定會造成什麼影響。這一層決定系統在資料變多之後撐不撐得住。
- 環境層：了解程式從自己的電腦到正式主機之間會經過什麼、版本怎麼控管、出問題時怎麼從記錄檔追查。這一層做不好，會出現「我這邊是好的」這種難以收尾的狀況。
三層之外還有一項基本功：使用版本控制的習慣。沒有這個習慣的團隊，任何協作都很難進行。
比技術更難補的是把需求變成規格
技術可以學，願意花時間都補得回來。真正難找的是能把使用者含糊的描述，翻譯成可以實作、可以驗收的規格的人。這種能力具體表現在幾個地方：問得出「這個功能什麼情況會失敗」、會主動確認邊界條件、能指出兩個需求彼此矛盾、能說明某個做法的取捨而不是只回答做得到或做不到。
面對業務或老闆時，能不能用非技術的語言說明工期為什麼是這樣、風險在哪裡，也是同一種能力的延伸。缺了這一層，即使程式寫得快，做出來的東西也常常不是對方要的。
面試時可以怎麼驗證
與其問名詞定義，不如給情境。例如描述一個實際遇過的需求，請對方說明他會怎麼拆解、需要先問哪些問題、資料表大概怎麼設計、哪裡可能出錯。這樣既看得出技術深度，也看得出思考方式。
另一個有效的做法是請對方講一個自己做過而且失敗過的案例：當時判斷錯在哪裡、後來怎麼收拾、現在會怎麼做。願意誠實談失誤的人，通常對系統的風險比較有感覺。若要出實作題，題目應該貼近公司真實會遇到的情境，並允許查資料，這比考背誦更接近日常工作。
要聘人還是要委外
判斷點不是預算，而是工作的性質。需求會持續變動、系統與日常營運綁得很緊、隨時要有人回應的，適合自己聘；範圍明確、有起訖點、上線後改動不頻繁的，委外通常更有效率。
兩種做法各有必須先解決的事。自己聘要面對的是一個人扛全部系統的風險，離職時交接會很痛，因此文件、版本控管、環境建置說明不能省。委外則要處理知識留不在公司的問題，合約裡要寫清楚原始碼歸屬、文件交付內容、後續維護方式。實務上不少公司採取折衷：核心與日常維運自己顧，專案型的開發交給外部團隊。
想入行或轉職該累積什麼
比起蒐集技術名詞，更有用的是完整做完一個小系統：從資料表設計、後端邏輯、介面串接，一直到部署上線並自己維護一段時間。過程中會遇到權限、錯誤處理、資料備份這些課程裡不太談的事，而這些正是面試中最能拿出來講的材料。
另外，把作品的原始碼與開發過程留下來，比一份功能清單更有說服力。看得到提交紀錄、看得到你怎麼修正問題，對方就能判斷你的實際水準。
常見問題
系統開發工程師和前端、後端工程師怎麼區分？
前端與後端是依系統的哪一段來分工，系統開發則偏向依「完成一套可運作的系統」來描述職責，常包含需求釐清、資料庫設計與整合。實務上界線模糊，同一份工作在不同公司可能用不同名稱。看職缺時直接看工作內容條列，比看職稱可靠得多。
非資訊科系可以做這個工作嗎？
可以，這個領域相對看重實際產出。需要補的通常不是語法，而是資料結構、資料庫觀念與網路基礎，這些會影響你能不能判斷做法好壞。轉職者的優勢在於原本的產業知識，如果原本待過會計、物流或門市，對那個領域的系統需求理解會比純技術背景的人深。
公司只有一位工程師，風險在哪裡？
最大的風險是知識集中在一個人身上，請假或離職時無人接手。降低風險的做法包括：要求所有程式碼進版本控制而非放在個人電腦、環境建置步驟寫成文件、資料庫結構與部署流程留下說明、重要帳號密碼由公司保管。這些要求應該從第一天就列入工作內容。
面試時要怎麼確認對方真的寫得出來？
看實際成果最直接：請對方展示做過的系統並解釋其中一段設計為什麼這樣做，追問替代方案與取捨。若對方能清楚說明權衡理由，通常代表是自己做的。純粹的線上測驗只能篩掉基本功不足的人，判斷不出協作與思考品質。
把開發委外之後，公司還需要懂技術的人嗎？
需要，至少要有一位能看懂規格、能提出驗收條件的窗口。這個人不必自己寫程式，但要能判斷交付內容是否完整、能不能問出關鍵問題、知道帳號與原始碼該由公司保管。完全沒有這個角色的委外，最後往往連自己有哪些系統、放在哪裡都說不清楚。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
相關主題
下一步
如果你正在評估「系統開發工程師」相關的規劃，可以參考我們的系統開發需求討論，或直接與我們聯繫，我們會依你的產業與現況給出務實的建議。
