[筆記] LayerX CTO 松本勇氣：優秀的工程師會少寫程式碼
Contents
LayerX 的技術長松本勇氣提出，優秀的工程師應該是「不寫程式碼的工程師」。這句話背後的涵義是什麼？這份筆記整理了他對於技術長 (CTO) 與工程師在職責上的獨到見解，探討了技術決策、團隊管理與個人成長的核心原則。
技術長 (CTO)
應該做的事 (Should Do)
技術冒險與領先嘗試
- 不斷冒險：必須親自接觸並立即著手嘗試新技術，即使失敗也無妨。
- 維持親手感知：這樣才能作為經營團隊成員提出有根據的意見，並對決策負責。
- 專注於技術變革：抓住時機，創造出當時最需要的產品或服務。
- 建立「良好的遊樂場」：允許工程師在不影響核心業務的前提下進行技術實驗，但要確保能隨時撤退。
產品、數據與技術債務管理
- 徹底執行資料庫的結構和資料模型設計：因為數據結構是「價值之源」，且遷移成本極高。
- 做出償還技術債務的決定：在技術債務累積到一定程度時，憑藉直覺和判斷，果斷進行大規模償還。
- 策略性地忽視某些負債：以股東、客戶、社會和員工的整體最大利益為考量，暫時對某些負債視而不見。
- 將 LLM 應用於組織的全部環節：包含品質保障、單元測試撰寫、設計原型、產品規劃和新人引導等。
- 允許團隊自由使用 AI 工具：在人事費預算內自由採購。
組織發展與人才招募
- 招募工作是核心：佔據 CTO 工作的一半。
- 積極招募高潛力人才：例如曾任 CTO 的人，他們一個人的加入就能帶來巨大的改變。
- 投入於「做朋友」：建立人脈是長遠招募規劃中最基礎且重要的工作。
不應該做的事 (Should Not Do)
- 核心系統的過度冒險：在 ID 基盤等核心、基礎的部分不應過度冒險，應使用已經成熟的技術來構建。
- 忽略影響競爭力的負債：如果技術債務已導致在競爭激烈的領域中
新功能發布速度緩慢，則不能忽視它。 - 允許混亂的數據結構：不允許資料庫結構混亂。混亂的資料庫比混亂的程式碼更難以解決。
- 過早引入新技術：不應將太早、缺乏管理工具的新技術（如 Kubernetes 出現前的 Docker）應用於核心服務。
工程師 (Engineer)
應該做的事 (Should Do)
- 面向客戶與事實 (ファクトを見る)：工程師應該直接與客戶溝通並觀察事實，以理解他們真正的痛點和需求。
- 追求最小範圍的高效交付：不製作不必要的東西，專注於製作真正需要的東西。必須仔細界定規格，以最小的範圍來滿足客戶。
- 積極應用新技術：例如 QA 工程師可利用 LLM 撰寫單元測試，並參與跨職能協作。
- 立即親手接觸：親自使用新技術以獲取第一手經驗。
不應該做的事 (Should Not Do)
- 避免不必要的程式碼：優秀的工程師應該是「不寫程式碼的工程師」。如果使用現成的 SaaS 就能解決問題，就不應自行撰寫程式碼。
- 管理技術負債：即使產生技術債務，也要確保它容易被捨棄，以利未來快速調整。