FDE的成果怎麼測量、怎麼簽約｜把工時設計成投資而非營收

大家好，我是株式會社TIMEWELL的濱本。

這是FDE實務系列的第九篇。至今寫了現場的技術、一週的運轉方式、市場的數字。這次寫的是支撐這一切的前提，也就是成果怎麼測量、怎麼簽約。

我們一直說FDE的工時是投資而不是營收。這句話聽起來不錯，但如果成果的測量方式與合約的型態和委外開發沒有不同，那只是換個說法。以時間賣工時、驗收就結束、不把學習帶回去的話，那就是換了名字的委外。這篇文章不隱瞞地寫出我們測量什麼、在合約寫什麼、什麼歸客戶、什麼回流產品。想先確認自家的合約接近哪一種型態，可以先看WARP的頁面。

測量什麼。不是技術指標，而是當事人的一天

先寫測量什麼。我們不以技術指標測量成果。準確率95%、回應時間2秒、可用率99.9%。這些是產品品質的指標，不是成果的指標。成果的指標在當事人的一天裡。等待核准有沒有從47分鐘變成12分鐘、退件每週減少幾件、月底結算的加班減少幾小時。

測量方法如影片分析的文章所寫。放下可運作之物之前，計算同一項作業。放下的隔週再計算一次。差異就是成果。沒有拍攝同意的話，用觀察的五欄記錄計算。計算方法不變，差異就能比較。

為什麼不以技術指標測量？理由有兩個。一是以技術指標測量，評估會在上線前就結束。準確率95%在會議室的展示就能達成，等待核准12分鐘要當事人每天使用才能達成。二是如曾領導Palantir商用部門的人所寫，FDE是客戶事業的「沒有權限的CEO」，對事業的成果而不是產出物負責¹。事業的成果無法用技術指標寫。

指標分三層。經營層用產業指標，事業部主管用本期的數字，現場用一天的時間。如訪談的文章所寫，三層對同一個案子期望不同。所以指標也放三個，在第一週找出三者朝同一方向的那一點。若能畫出「縮短現場的等待核准，事業部的出貨前置時間就會縮短，連到經營層說的交期競爭力」這條線，就在這條線上測量三者。畫不出線的案子，我們不接。

工時是投資不是營收。我們看的三個比率

接著是工時的看法。a16z的Joe Schmidt在2025年6月寫道，放棄短期毛利率、買下深度。即使把實作做厚、暫時降低利潤率，也要買下掌握業務入口的護城河，這是經營上的判斷²。同樣是a16z的Marc Andrusko在2026年1月整理道，真正的型態明確持有時間區隔的部署與工程師對ARR的比率，成熟客戶的工程工時會遞減³。

我們看的比率有三個。第一，每位客戶的現場工時變化。從第一週到第八週，我們的工程師在現場的時間是否在減少。沒有減少的話，不是當事人還無法碰辭典，就是卡在寫入的階段。第二，型的回流數。從那個案子產出了幾個成為產品標準功能的型。零的話，那個案子只由分枝構成，對下一位客戶沒有幫助。第三，再利用率。在下一位客戶那裡，從前一位客戶回流的型被用了幾個。這個比率越高，下一位客戶第一天交出程式碼的速度越快。

這三者和委外開發的指標方向相反。委外的現場工時是營收，越多越好，學習是客戶的資產，不會回流。FDE的現場工時越少越好，學習越回流產品越好。所以工時是投資。既然是投資，看不到回收前景的案子就不能接。看起來一個型都不會產出的案子，也就是只有那家公司獨有分枝的案子，比起我們更適合委外開發。這點我們坦白告知。

Palantir的數字顯示這些比率長期會怎樣。前FDE回憶，該公司在2016年前後被視為服務公司，但持續把學習回流產品，2023年達到80%的毛利率⁴。工時作為投資回收之後，利潤率會接近軟體的水準。

合約的型態。不是承攬也不是人月，而是時間區隔、成果指標與結束條件

寫合約的型態。日本的系統開發合約大致分為承攬與準委任。民法中，承攬是承諾完成工作以取得報酬的合約，準委任是委託處理法律行為以外事務的合約，兩者被放在不同的類型⁵。屬於哪一種，由合約的內容而非名稱決定。

FDE是兩者都不好放的工作。承攬承諾完成，但FDE每週更新可運作之物，完成的定義每週在變。準委任以時間賣工時，但待得越久營收越多的結構，和越早離開價值越高的FDE目的相反。所以我們把以下六項寫進合約，再與法務確認法律上的類型。

條款	寫什麼
期間	在現場的期間以45到90天區隔。延長要重寫目的、另立合約
成果指標	三層的指標，以及放下前後的計算方法。技術指標作為品質條件另外放
學習的歸屬	型歸我們的產品，分枝歸客戶的擴充，辭典的內容歸客戶
寫入的四項條件	權限、事前模擬、重大判斷時人的介入、稽核記錄。四項齊備前不寫回正式環境
追加需求的處理	是型就放進產品藍圖、不另收費；是分枝就用設定吸收，或說明理由後拒絕
結束條件	當事人能自己更新辭典、成果指標當事人自己看得見、型已回流產品

費用的結構也分成兩部分：產品的使用費，以及時間區隔的部署費用。部署費用綁定期間與成果指標，不以工時累積決定。以工時決定，待久一點的動機就會進入合約；以期間決定，早點離開的動機就會進入合約。

這個型態不是我們的發明。AWS在2026年6月成立的FDE組織，把結束時客戶能自行運作的狀態，也就是留下可運作之物、文件與受過訓練的內部人員，放在設計的核心⁶。Anthropic與FIS的合作明記，嵌入FDE的目的不是持續駐點，而是交出知識讓FIS能自行運作⁷。OpenAI的實作專門公司公開了從價值診斷開始、選出少數優先工作流程的典型做法⁸。一開始就決定結束、以業務測量成果、交出學習。我們把三家發布共通的型態，落實為合約的條款。

學習的歸屬。型歸產品、分枝歸客戶、辭典內容歸客戶

合約中最容易起爭議、也最重要的，是學習的歸屬。FDE在客戶的現場學習業務。說學到的東西會回流產品，客戶會覺得「你要把我們的業務知識帶走嗎」。理所當然。所以分成三類寫進合約。

型回流我們的產品，歸我們。「核准可能有多階段」「例外依類別分岐」「急件需要另一條路徑」這些結構。這是a16z的Andrusko稱為可重複使用的基元的東西，是資料模型與工作流程的元件³。它不屬於任何一家公司的業務，而是業務一般的結構。

分枝作為客戶端的擴充持有，歸客戶。「那張紙由會計的田中先生保管」「這張表單只在月底用」這些只有那家公司才有的步驟。不放進產品，作為設定或擴充放在客戶的環境。

辭典的內容歸客戶。就是本體論的文章寫的那家公司的名詞、動詞、關係、狀態、例外。回流產品的是「訂單有狀態」這個結構，不是「這家公司訂單的狀態是受理、待核准、已核准、已出貨」這個內容。內容歸客戶，我們不會帶到下一位客戶那裡。

把這個三分法明記在合約裡，客戶才能安心讓我們看現場。不明記的話，FDE看起來就像帶走業務知識的人，現場的當事人就只會給你看「應該有的業務」。明記歸屬，在成為法務問題之前，是為了在現場被展示真正業務的條件。

與委外開發的差異

從合約的觀點列出與委外開發的差異。

觀點	委外開發	FDE
工時的性質	營收，待越久越好	投資，每位客戶越少越好
成果的測量	驗收（是否照規格）	當事人一天的指標（放下前後的差異）
變更的處理	追加費用與重新報價	是型就不另收費，是分枝就設定或拒絕
學習的歸屬	客戶的資產	型歸產品，分枝與辭典內容歸客戶
結束方式	驗收後撤離	當事人自行運作，我們不再被需要
延長的動機	內建於合約	不放進合約

最大的差異是不把延長的動機放進合約。委外開發的工時是營收，延長是自然的動機。FDE以期間決定費用、以成果寫結束條件，所以延長是伴隨目的重寫的另一份合約。這個設計，就是把FDE和委外開發切開的線。

另一個差異是變更的處理。委外開發中需求變更就是追加費用與重新報價。FDE中，變更若是型就放進產品藍圖不另收費，若是分枝就用設定吸收或說明理由後拒絕。a16z壓力測試中的「能否對客製化說不」³，要合約有這個條款才說得出口。

我們的實務與限制

坦白說，這個型態不是在每個現場都組得起來。

有些現場放不了成果指標。無法計算當事人一天的業務，例如判斷本身就是工作、無法用時間測量的業務。這種情況我們會找退件件數、判斷時使用的資訊數量這類替代指標，找不到的話就不以這個型態承接。

有些現場守不了期間。資安審查很長、資料的持有者定不下來、當事人抽不出時間。一週的文章寫的速度條件不齊備的現場，45到90天的區隔守不住。我們在第一次會議確認這些條件，不齊備的話不是延長期間，而是把開始延後到條件齊備。

有些現場產不出型。只由那家公司獨有的分枝構成的業務，看起來一個對下一位客戶有用的型都不會產出的案子。這種情況工時無法作為投資回收，比起我們，委外開發對客戶也更合適。這點在業務洽談的場合坦白告知。

還有我們的容量。小公司能同時進入的現場數有限。問的人、做的人、回流產品的人是同一個人，是速度的理由，同時也是容量的上限。這個上限我們不隱瞞。

總結

FDE的工時能說是投資，是因為成果以當事人的一天測量、每位客戶的現場工時遞減、型回流產品、在下一位客戶被再利用。合約不是承攬也不是人月，而是由45到90天的期間、三層的成果指標、學習的三分法（型歸產品、分枝歸客戶、辭典內容歸客戶）、寫入的四項條件、追加需求的處理、以自行運作為結束條件的六項條款組成。費用分成產品使用費與時間區隔的部署費用，不以工時累積決定。

與委外開發的分界線，是不把延長的動機放進合約。待得越久營收越多的合約是委外，越早離開價值越高的合約是FDE。

想以這個型態重組自家AI導入的合約，或想分辨發包對象的合約屬於哪一種型態，歡迎參考WARP的方案，或透過個別諮詢和我們聊聊。下一篇是系列最終回，寫怎麼培養FDE：工程師養成現場能力的研修與評價。

Footnotes

1. Sorry, that isn't an FDE（Ted Mabrey，2024年9月21日）。「沒有權限的CEO」、對事業成果而非產出物負責依該文（筆者譯） ↩

2. Trading Margin for Moat: Why the Forward Deployed Engineer Is the Hottest Job in Startups（Joe Schmidt，a16z，2025年6月） ↩

3. The Palantirization of everything（Marc Andrusko，a16z，2026年1月16日）。時間區隔的部署、工程師對ARR比率、可重複使用的基元、壓力測試依該文 ↩ ↩² ↩³

4. Reflections on Palantir（Nabeel S. Qureshi，2024年10月15日） ↩

5. 民法（明治二十九年法律第八十九號）第632條（承攬）、第656條（準委任）。e-Gov法令檢索，日文 ↩

6. AWS invests $1 billion to embed AI forward deployed engineers with customers（Amazon，2026年6月30日） ↩

7. FIS Brings Agentic AI to Banking with Anthropic, Starting with Financial Crimes（FIS，2026年5月4日） ↩

8. OpenAI launches the OpenAI Deployment Company（OpenAI，2026年5月11日） ↩