靠人月估算維生的各位，現在大概都在煩惱：「在 AI 時代，這種估算不會是詐欺吧？」
當實作和設計文件的撰寫都會由 AI 來做時，就 აღარ有東西可以用人月慢慢疊上去了。
那開發費到底是由什麼決定的呢？常見的說法是「客戶獲得利益的幾%」這種成果報酬思維，但我認為那也有點偏題。
這篇文章只主張一件事：廠商能收取的金額上限，取決於「客戶如果自己用 AI 來做，會花多少錢」。
這不是我突發奇想，而是對價格策略教科書裡早就有的概念做延伸應用。接下來我會連同證據一起，落實到具體的計算方法。
估算會以「時間」為單位，是因為原價成本，而不是價值
客戶想要的是系統，不是廠商的工時。
即使如此，人月制度之所以能延續下來，是因為工作需要人力，而人事成本又佔了原價的大半。只要把成本逐步加總，至少不容易虧損。
人月制度的問題其實早就眾所皆知。Frederick Brooks 在 1975 年的《人月神話》中指出，人與月能互換的，只是那些彼此不需要溝通、可以各自分工的工作而已。
IPA 的《軟體開發數據白皮書》在 2018–2019 年版中也顯示，「工期與工時呈立方根比例」的傾向（2016–2017 年版收錄了 4,000 件以上專案）。這類迴歸式的前提，都是以人類團隊實際動手為基礎建立的。
這裡先做一個思想實驗。
- 實作與設計文件撰寫的成本幾乎是零
- 也不考慮 AI 的使用費
- 但與客戶開會和溝通的成本仍然存在
在這個前提下，幾乎就沒有東西可以再用人月去堆了。以原價成本加總來決定價格的方法，在這裡就失效了。
製作成本真的已經接近零了嗎
老實說，以 2026 年的時點來看，「完全不需要實作」仍然只是思想實驗。證據其實分歧得很明顯。
小型的新任務，能在不到一半的時間內完成。 Microsoft 與 GitHub 研究人員在 2023 年做的對照實驗中，針對用 JavaScript 實作 HTTP 伺服器的任務，使用 Copilot 的組別比沒使用的組別快了 55.8% 完成（Peng 等人，2023）。
但在成熟的大型程式碼庫中，反而會變慢。 METR 於 2025 年 2 月到 6 月進行的隨機對照試驗中，16 位長期參與大型開源軟體的開發者實作了 246 個真實任務。使用 AI 之後，完成時間反而增加了 19%，而他們自己原本預期會快 24%（InfoQ 解說）。
方向上來說，製作成本確實會下降；但能降到什麼程度，會因對象而完全不同。
以下請把它當成「製作成本已經小到足夠低的世界」來閱讀。即使還沒低到那個程度，成本越下降，本文的公式就越有用。
價格上限由「客戶的替代方案」決定
價格策略教科書早就這樣寫了
行銷裡有一個概念叫做「顧客經濟價值（EVC: Economic Value to the Customer）」。其起點可追溯到 1979 年 Forbis 與 Mehta 的論文，之後由 Thomas Nagle 的《The Strategy and Tactics of Pricing》加以體系化。公式很簡單：
經濟價值 ＝ 參考價值（對客戶而言的次佳替代方案價格）＋ 差異化價值（比替代方案多出來的價值）
客戶不會付超過與次佳方案之間差額的錢。
協商學中的 BATNA（談判破裂時的最佳替代方案；Fisher 與 Ury 在 1981 年《Getting to Yes》中提出）也是從另一個角度說同一件事。
AI 之後改變的是「次佳替代方案」的內容
過去，系統開發的替代方案是「找另一家廠商」。所以比價時，比的也是人月單價。
當製作成本幾乎趨近於零時，替代方案裡就多了「客戶自己用 AI 做」。廠商的競爭對手不再只是其他公司，而是客戶本人加上 AI。
因此，廠商能收取的金額上限可以這樣寫：
廠商上限 ＝ 客戶自己做的總成本 − 交給廠商後，客戶仍需承擔的成本
「利益的幾%」只不過是上限的上限
客戶從系統得到的利益，確實是可支付金額的天花板。但實際上，在那之前，自己做的成本就會先成為天花板。
就算是能帶來 1 億日圓利益的系統，如果客戶自己用 200 萬日圓的工夫就能做出來，那就沒有理由付給廠商超過 200 萬日圓。
下限則是廠商自身的原價（開會、驗證、承擔責任的成本）。上限與下限之間，就是協商學所說的 ZOPA（可協議區間）。
把「自己做要花多少」拆成 5 項
以下是我自己的整理。即使實作幾乎為零，客戶自己做時仍無法省掉的成本有 5 種。
成本內容廠商能否降低決定成本要做什麼、做到哪裡的時間幾乎無法降低（只能整理論點）翻譯成本把業務語言轉成 AI 能使用的規格，過程中的反覆試錯可大幅降低驗證成本確認做出來的東西是否正確、能否在業務上使用可部分降低（例如測試觀點設計）責任成本發生故障或資訊外洩時的損失 × 發生機率可透過合約承擔啟動成本讓 AI 與開發環境進入可用狀態，並學會使用方法幾乎可歸零
關鍵在於，即使交給廠商，決定成本也不會從客戶那裡消失。
因為最後還是客戶在做決定。
廠商真正能定價的，只是剩下 4 項裡「客戶自己做會特別貴的部分」。
用假想案例來算算看
以下數字全部都是說明用的假值。 並非實際資料。
假設一家有 50 名員工的公司，想把原本靠紙本和 Excel 處理的進銷存作業，改成業務應用程式。負責人是總務課長，時薪先假設為 5,000 日圓。處理的內容包含往來廠商資訊，所以若外洩，損失先假設為 2,000 萬日圓。
項目課長自己用 AI 做交給廠商（課長需承擔的部分）決定20 小時20 小時翻譯80 小時10 小時（回答訪談）驗證40 小時15 小時（驗收確認）啟動20 小時0 小時工時計算總和 × 5,000 日圓160 小時 = 80 萬日圓45 小時 = 22.5 萬日圓責任（2,000 萬日圓 × 發生機率）機率 5% 時為 100 萬日圓廠商將機率降到 1% 並承擔，課長側為 0 日圓合計180 萬日圓22.5 萬日圓廠商上限是 180 萬日圓 − 22.5 萬日圓 ＝ 157.5 萬日圓。
下限則是廠商端的原價：30 小時 × 1 萬日圓 ＝ 30 萬日圓，再加上承擔責任的期望損失 2,000 萬日圓 × 1% ＝ 20 萬日圓，合計 50 萬日圓。可協商範圍就是 50 萬到 157.5 萬日圓。
調整數字就會看出來的事
- 如果負責人是社長（時薪 2 萬日圓），上限會升到 330 萬日圓。 因為自己做要 420 萬日圓，交給廠商後仍有 90 萬日圓的成本。地位越高的人，時間越貴，廠商分到的空間也越大。
- 如果 AI 變得更聰明，讓翻譯與驗證成本降到一半以下，上限會降到 117.5 萬日圓。 自己做的成本會變成 140 萬日圓，其中 100 萬日圓是責任成本。
- 如果處理的資料就算外洩也無所謂，責任成本消失，上限就會幾乎只剩時間費。 這就是最接近「不需要廠商」的狀態。
有趣的是，這個系統能為公司帶來多少利益，在計算裡一次都沒有出現。
另外，AI 越進步，上限中責任成本所占的比例就越大。最後廠商賣的，會從「工作」變成「承擔責任」。
在日本，替代方案還是很貴；但這不會持續太久
日本超過 7 成的 IT 人才在供應商端。 IPA 的《IT 人才白皮書 2017》顯示，隸屬 IT 企業的 IT 人才比例，日本是 72.0%，美國是 34.6%。在《DX 白皮書 2023》更新後的數字中，日本（2020 年）為 73.6%，美國（2021 年）為 35.1%，幾乎沒有變化（Cloud Watch）。
日本的委託方常常缺乏能做的人，也缺乏能判斷的人。因為翻譯成本與驗證成本都很高，所以廠商能維持的上限也比較高。
但這不是因為廠商真的創造了那麼多價值，而是因為客戶的替代方案太弱。AI 會把翻譯成本往下壓，因此這塊空間會逐漸被吃掉。
在替代方案變便宜的市場裡，越厲害的人越守不住價格。 Hui、Reshef、Zhou 的研究（Organization Science, 2024）指出，在 ChatGPT 公開後的 Upwork 上，文字類自由工作者的月接案數下降 2%，月收入下降 5.2%（Olin Business School）。研究也暗示，過去實績越高的頂尖族群受到的影響越大（INFORMS）。不過作者也明確說這是短期效果，這點要打折看待。
在能夠量化成果的領域，價格已經開始往「被取代的工作」靠攏。 Intercom 的客戶支援 AI「Fin」是每解決 1 件收 0.99 美元，HubSpot 則從每次對話 1 美元，改成每解決 1 次對話收 0.50 美元（SaaStr）。被拿來比較的，是人類客服的人工成本，也就是客戶的替代方案。
套用到各種流程模型
瀑布式與敏捷常常被稱為「開發方法」，但更精確地說，瀑布式與迭代式是流程排列方式的模型（流程模型）。敏捷則是價值觀與原則的總稱，而 Scrum 依照《Scrum Guide》自我定義為輕量級框架。以下統稱為流程模型。
流程模型客戶自己做時昂貴的部分廠商能定價的地方瀑布式一開始就決定完整需求（前半段集中在決策與翻譯）需求定義推進、階段性核准的設計迭代式／螺旋式先決定要先處理哪個風險風險盤點與驗證計畫原型製作如果只是看樣品來選，成本較低較少（替代方案最便宜的模型）敏捷（Scrum）每個衝刺中的決策與驗收協助產品負責人輔助、代行驗證瀑布式是建立在「之後再改就很貴」的前提上，敏捷則是建立在「做之前不先確認會造成浪費」的前提上。當製作與重做都變得免費時，兩者的前提都會崩解。
剩下的，只是「決定」與「確認」之間不斷來回。流程模型之間的差異，最後只剩下這種往返要怎麼排程而已。
【然後就進入不需要估算的世界】這個計算，會由客戶交給 AI 來做
到目前為止，我都是站在廠商角度來寫。
但這個計算式，客戶只要對 AI 說「這個如果我自己做，要花多少錢？」就能直接在客戶端運算。
那麼，估價單就不再是「人月累積表」，而是「與自己做相比的對照表」。
廠商該寫的，不是「要幾人月」，而是「你如果自己做，翻譯、驗證、責任會花這麼多；交給我們，能減少到這個程度」。
無法把這個差異說清楚的廠商，會在沒有察覺對手其實不是別家公司，而是客戶與 AI 這組合的情況下，一步步輸掉。
而且，如上所見，AI 越進步，差異內容就越往責任成本集中。最後留下來的廠商工作，大概就是「一起做決定」與「出事時負責」。這兩件事，都無法用人月估算。
順帶一提，這篇文章也是邊跟 AI 對話邊寫的。如果要算自己寫會花多少時間，我怕得不敢算。
結語：請到留言區幫忙估價
這 5 種成本的拆法，以及上面假想案例的數字，還只是粗略的草稿。
歡迎指正：「我們這個產業的替代方案不是那樣」、「責任成本的估算太保守了」之類的意見。
如果可以，也請把你下一個案件的「客戶自己做要花多少」留言分享出來。
參考文獻
- Frederick P. Brooks Jr.《人月神話》（原著 1975 年）
- IPA「《軟體開發數據白皮書 2018–2019》」
- Sida Peng 等人「The Impact of AI on Developer Productivity: Evidence from GitHub Copilot」（2023 年）
- METR「Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity」（2025 年、InfoQ 解說）
- Thomas Nagle 等人《The Strategy and Tactics of Pricing》
- Roger Fisher、William Ury《Getting to Yes》（1981 年）
- IPA「《IT 人才白皮書 2017》」、「《DX 白皮書 2023》」（Cloud Watch）
- Xiang Hui、Oren Reshef、Luofeng Zhou「The Short-Term Effects of Generative Artificial Intelligence on Employment」Organization Science（2024 年、INFORMS）
- SaaStr: HubSpot Switching AI Pricing From Per Use To Per Resolution
- 《Scrum Guide 2020 年 11 月版（日文）》
原文出處：https://qiita.com/kotowazaman/items/3a82a47b39bacf7f02d7
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
