技術盡職調查不是一場程式碼品質比賽，而準備接受查核的團隊，通常把時間花在最不相干的地方。沒有人是為了替你的抽象層打分數才來買一家公司。買方想弄清楚的其實只有兩件事：擁有這套系統要付出多少代價，以及在資金易主之後，情況可能壞到什麼程度。

換一個角度看待這件事之所以重要，是因為它會改變你該優先處理什麼。醜歸醜但跑得動、團隊看得懂、可以安全修改的程式碼，只是一則輕微的查核結果。反過來說，寫得漂亮卻只有一個人看得懂的程式碼，才是嚴重的查核結果，而真正牽動價格的，向來是後者。

所有問題背後的那個問題： 如果創辦工程師在交割後的隔週離職，這套系統還跑得下去，而且還改得動嗎？幾乎每一項會壓低出價的查核結果，都是對這個問題的具體回答。知識全積在一個人腦袋裡、沒有文件的部署流程、從來沒人核對過的授權條款、只存在於某個人記憶中的帳號密碼，反覆出現的就是這幾種。

技術盡職調查實際上在評估什麼

買方看的是四類風險，大致依照對估值的影響程度排列。

關鍵人員依賴風險。 也就是這套系統究竟靠有紀錄的流程運作，還是靠某幾個特定的人。這一項向來是殺傷力最大的查核結果，因為事後最難補救，而且直接威脅到被買下的標的本身。如果某個人請假開發就停擺，買方拿到的與其說是資產，不如說是一張人質清單。

繼續營運的成本。 讓系統持續運轉並持續演進需要什麼：基礎架構支出、授權義務、必須配置的團隊規模，以及產品藍圖裡有多少比例會被維護吃掉，而不是投入新的功能。這些數字在交割之後會原封不動出現在損益表上，所以買方查得比多數人預期的還細。

法律責任。 與商業使用相衝突的授權條款、以禁不起一次申訴的方式處理的個人資料、資安上的曝險，以及公司實際上並未落實的法遵義務。這些負擔在交易完成後會一併由買方承受。

改變的能力。 新功能能不能以可預期的節奏推出，還是每動一個地方，都得承擔弄壞另一個毫不相干功能的風險。既然收購的目的多半是把產品做大，這項能力直接牽動未來的營收預估。

程式碼品質只有透過第四點才有意義。這也是為什麼查核人員讀程式碼的時間遠比創辦人想像的短，而追問部署到底怎麼進行的時間卻長得多。

會壓低價格的查核結果

除了一個人以外沒人會部署。 只存在於某人腦中、或某人筆電裡的發版流程，不論今天跑得多順，都會被視為嚴重的營運風險。流程跑得通和流程交接得了，是兩件不同的事。

關鍵路徑上沒有測試。 這裡講的不是覆蓋率數字，查核人員基本上不看那個百分比，而是這套系統還能不能帶著一點信心去修改。營收路徑周邊沒有測試的程式碼庫，會把一份較慢的產品藍圖折算進價格裡。我們談軟體測試策略 的文章整理了哪些測試真的值得寫。

授權汙染。 專屬產品裡混進了具傳染性的開源程式碼，也就是 Copyleft 程式碼，是少數幾種不只是重新定價、而是足以直接中止交易的查核結果，而且掃描工具通常幾分鐘就找得到，根本藏不住。

沒有合法依據的個人資料。 在缺乏明確合法依據的情況下蒐集的資料、無限期保存的資料，或是放在公司自己都列不出來的地方的資料。GDPR 技術法遵 一文提到的那些做法，正是查核人員會逐項核對的內容。

對個人或供應商沒有留下紀錄的依賴。 與某家沒有簽約的供應商之間的關鍵串接，或是跑在個人帳號上的基礎架構，兩者都會被讀成未受管理的風險。凡是拿不出公司層級合約或所有權證明的東西，在買方眼中等同於不存在。

資安基本項目缺席。 要的不是滲透測試報告，而是三個具體問題：金鑰是不是躺在版本控制裡、人員離職時存取權有沒有確實收回，以及此刻是否還有未更新又對外網開放的服務。

查核人員不在意的事

這一點值得寫出來，因為準備時間有限，而且往往用錯了地方。

他們不在意你挑了哪個框架，只要還請得到會用的人就行。他們也不在意架構上的流行趨勢：一個持續交付得出來的單體式系統不構成任何查核結果。程式碼風格、命名習慣，或是沒有採用網路上某人推薦的設計模式，同樣不影響結論。

他們更不會期待技術債為零。每家公司都有，存在本身完全正常。真正重要的是團隊知不知道它在哪裡，說不說得出它的代價。能拿出一份清楚的已知問題清單的團隊，會被讀成有能力。宣稱自己一個問題都沒有的團隊，會被讀成搞不清楚狀況，查核人員只能自己去找，花的時間更久，最後寫出來的報告也更難看。

不重寫任何東西的準備方式

真正有用的事情大多以天為單位，而不是以月為單位，而且沒有一項需要動到架構。

把部署流程寫下來。 從一台空機開始，寫到系統跑起來為止。光是這一份文件，就正面處理了殺傷力最大的那一類查核結果，一個下午就寫得完。

把相依套件與它們的授權條款列出來。 自動化工具很快就能產生這份清單，而搶在查核人員之前知道答案，遠比清單本身有多乾淨來得重要。

把金鑰從版本控制裡移出來，並清點誰擁有哪些存取權。接著收回所有已經離職的人的權限。

把你已知有問題的地方寫成文件。 一份簡短誠實的已知問題登記表，附上大致的修復成本就夠了。主動交出這份表，是少數能穩定改善查核語氣的做法之一。

確認基礎架構登記在公司名下，而不是掛在個人帳號底下，並且網域、憑證與程式碼儲存庫都在公司控制之中。

這些查核結果後來會變成什麼

它們很少讓交易破局，它們會變成條件。

查核結果通常會收斂成三種處理方式之一：反映修復成本的價格調整、寫進合約的保證條款或賠償條款，以及交割前必須先完成的先決條件。真正會讓交易整個停下來的，大致只有授權汙染，以及長期被擱置的重大個資保護曝險。

換句話說，實務上的目標從來不是一套完美的系統，而是一套問題已知、範圍清楚、能用文字說明白的系統。因為量化過的問題會被算進價格，而沒有量化的問題，只會被預設成比實際情況更糟。

Mecanik 在軟體開發 業務中承接這類技術查核，多數時候站在買方這一側。規律相當穩定：查核結果好看的系統，往往不是技術上最精巧的那些，而是有人願意把事情寫下來的那些。

相關文章: 軟體原始碼信託：誰真的需要 、英國金融科技軟體開發：FCA、金流軌道與成本 、固定價格合約還是按工時計費 、英國客製化軟體開發：完整買方指南 。

常見問題

什麼是技術盡職調查？ 它是對擁有一套軟體系統要付出多少代價、以及在收購或投資之後情況可能壞到什麼程度所做的評估。它檢視的是關鍵人員依賴風險、繼續營運的成本、法律責任，以及持續修改系統的能力，而不是替程式碼品質本身打分數。

哪些查核結果最會壓低價格？ 知識集中在個別人身上，尤其是只有一個人執行得了的部署流程。其次是營收路徑上沒有任何有意義的測試、專屬產品中混入 Copyleft 程式碼造成的授權汙染、缺乏可辯護合法依據的個人資料，以及被提交進版本控制的金鑰。

查核人員會在意我們的技術債嗎？ 他們預設它就是存在的。每家公司都有，存在本身並不構成查核結果。重要的是團隊知不知道它在哪裡，說不說得出修好它要付出多少代價。一份清楚的已知問題登記表會被讀成專業能力，宣稱毫無問題則會被讀成缺乏認知，並讓查核結論變差。

我該如何準備技術盡職調查？ 寫下如何從一台空機把系統跑起來，列出相依套件與授權條款，把金鑰從版本控制中移除，重新檢視還有誰保有存取權，確認基礎架構與網域屬於公司而非個人，再準備一份誠實的已知問題登記表，附上大致的修復成本。

單一技術查核結果會讓交易完全中止嗎？ 很少。絕大多數查核結果最後變成價格調整、合約中的保證條款，或是交割前必須滿足的條件。真正會中止交易的例外，是專屬產品中的 Copyleft 授權汙染，以及長期被擱置的重大個資保護曝險。