委託開發‧維運的合約該怎麼簽？── 從 IPA《模型交易‧合約書》學習準委任與承攬的區分使用

「明明簽的是一次性承攬合約，卻在需求還沒確定的情況下就開始開發，最後為了『完成的標準』該怎麼算而起爭執。」

「雖然簽了月費維運合約，但雙方對於維運範圍到底涵蓋到哪裡，認知卻不一致。」

「請廠商報價時被告知『需求定義要用準委任』，卻不明白為什麼要依工程分開簽約。」

系統開發委外時，會發生問題的原因，往往不是技術層面，而是合約的形式。這種情況並不少見。

其實，這個問題有公開的「範本」可以參考，那就是 IPA（獨立行政法人資訊處理推進機構）公布的《資訊系統‧模型交易‧合約書》。

本文將以這份模型合約為基礎，用委託方也能理解的語言，整理委託開發或維運（無論是委託的一方或承接的一方）時，合約應該如何架構。

另外，本文是根據 IPA 公開資料所做的一般性解說，並非法律意見。個別的合約問題，請務必諮詢律師等專業人士。

1. 先講結論

關於系統開發與維運的合約，先整理 IPA 模型交易‧合約書所呈現的思考方式。

• 不把整個開發工程綁在同一份合約裡，而是依工程分開簽約（多階段合約）
• 「要做什麼」尚未確定的企劃‧需求定義工程，採用準委任合約
• 「要做什麼」已確定後的內部設計～開發‧測試工程，原則上採用承攬合約（外部設計則視案件而定，兩種都可能採用）
• 維運等持續性業務，原則上採用準委任合約
• 委託方也負有協力義務，例如決定需求、提供資訊等
• 規格變更不以口頭方式往來，而是透過文件化的變更管理程序處理

一言以蔽之，這是依循「對尚未確定的事物不承諾完成責任，對已確定的事物承諾完成責任」這項原則，依工程區分使用不同合約形式的思考方式。

2. IPA《資訊系統‧模型交易‧合約書》是什麼

《資訊系統‧模型交易‧合約書》是彙整系統開發委託合約範本及其解說的公開文件。

這份文件最早由經濟產業省於 2007 年公布，作為以委託開發（含部分企劃）與維運為對象的第一版。其背景是使用者企業（委託方）與 IT 廠商（受託方）之間，對合約內容的認知經常出現落差，導致糾紛頻傳。

之後，修訂工作由 IPA 接手，為因應 2020 年 4 月施行的修正民法，第二版於 2020 年 12 月 22 日公布。第二版整理了後面會提到的契約不適合責任、成果完成型準委任合約的定位等內容。

另外，適用範圍需要留意。第一版、第二版原本是以企業核心系統等規模較大的客製開發（瀑布型）為對象，設想的是雙方都具備系統部門與法務體制的企業之間的交易。對於中小規模交易，或活用套裝軟體‧SaaS 的情況，另外備有以「套裝軟體、SaaS/ASP 活用、維運」為對象的追補版系列模型合約。應先確認自家的交易比較接近哪一種，再把條文當作思考方式的基礎來使用，而不是原封不動地照抄套用，這樣的距離感才正確。本文所介紹的，也是不分規模都能派上用場的「思考方式」部分。

這份模型合約具有以下特徵。

• 由使用者企業、IT 廠商、業界團體、法律專家共同討論制定，經過中立設計，不會偏向任何一方
• 合約範本以 Word 格式公開，可依自家交易情況修改後使用
• 除了條文本身，還附有「為什麼要這樣規定」的解說
• 也公布了用於決定開發合約資安規格的指引等附屬文件

也就是說，這份資料無論是要製作合約書的草稿，還是要比對確認對方提出的合約書內容，都能派上用場。

該看哪個版本

IPA 的網頁上並列著好幾種版本，建議先確定自家的交易比較接近哪一種，再點開對應的版本，才不會迷失方向。

本文以下的說明，皆以最基本的第二版正編為前提。

3. 核心是「多階段合約」── 為什麼要依工程分開簽約

模型交易‧合約書思考方式的核心，就是多階段合約。

系統開發大致上會依循以下工程進行。

企劃‧需求定義（決定要做什麼）
        ↓
設計‧開發‧測試（做出決定好的東西）
        ↓
驗收‧導入支援（把做出來的東西套用到業務上）
        ↓
維運（持續運作）

所謂多階段合約，就是不把這些工程綁在同一份合約裡，而是依工程（或工程的群組）分開簽約的方式。

實際的文件結構 ── 基本合約書與個別合約書的兩層

聽到「依工程分開簽約」，可能會以為要依工程數量分別製作獨立的合約書，但模型合約書實際採用的是基本合約書與個別合約書的兩層結構。為了在打開範本時不至於困惑，先掌握這個結構。

• 軟體開發委託基本模型合約書（基本合約書）── 訂定專案整體共通事項的合約，原則上每個專案簽訂一份。用語定義、再委託、協作與角色分工、負責人、聯絡協議會、變更管理程序、保密、智慧財產權、損害賠償等條文都放在這裡。
• 個別合約書 ── 在著手個別業務之前，依業務逐一簽訂。單位包括需求定義製作支援業務、外部設計書製作（支援）業務、軟體開發業務、軟體維運準備‧移轉支援業務等。在這裡決定的是具體的作業內容與範圍、合約類型（承攬還是準委任）、作業期間或交付期限、角色分工的細節、委託費用與支付方式、交付物、檢驗‧確認相關事項等。

也就是說，「依工程而變化的事項」全部歸到個別合約書那一側，要選承攬還是準委任，也是在個別合約書中決定。基本合約書中也訂有「個別合約書的條款優先於基本合約書」的規定。

維運則備有與開發不同的合約書（資訊系統維運委託基本模型合約書），這裡同樣採用基本合約書與個別合約書的兩層結構。由於維運業務的種類多樣，無法製作統一的範本，因此明確採取「只把共通條款放進基本合約書、個別的委託業務則在個別合約書中訂定」的思考方式。個別合約書預計會附上兩份文件：記載制式化服務內容的業務規格書，以及記載對象系統、實施地點、角色分工等因客戶而異事項的受託條件明細。

第二版正編所收錄的合約文件如下。

為什麼要分開呢？理由很單純，因為依工程不同，「能夠承諾的事」也不同。

在需求定義結束之前的階段，要做的東西的內容與分量都還沒確定。若在這個時間點就確定整個開發的金額與交付期限，會發生以下兩種情況之一。

• 受託方為了因應不確定的風險，提出偏高的金額
• 低價承接的受託方，之後主張「那超出範圍」，與委託方發生爭執

另一方面，若需求定義已經完成，要做的東西已經確定，受託方就能以較切合實際的精確度進行報價與完成的承諾。

多階段合約是以「需求定義結束後，重新針對開發部分報價」為前提的方式。從委託方的角度來看，雖然總金額無法在一開始就確定，會有些不安，但比起用沒有依據的金額把整體先定下來，結果反而能減少糾紛與無謂的成本，這就是模型合約所採取的立場。

4. 準委任與承攬 ── 兩種合約類型的差異

在多階段合約中，會依工程區分使用準委任合約與承攬合約。這兩者的差異，是本文最重要的重點。

先簡短整理本章會出現的用語。

接著，將承攬與準委任的差異整理成表格。

承攬合約 ── 承諾完成的合約

承攬是承諾「會完成這個成果物」的合約。受託方負完成責任，若未完成，原則上無法請求報酬（不過，即使專案中途終止，若已完成的部分能夠切分出來且對委託方有利益，有時仍可依比例獲得報酬）。

若交付物與合約內容不符，受託方須負契約不適合責任。這是 2020 年施行的修正民法，將原本的「瑕疵擔保責任」重新架構而來的制度，委託方除了可以請求修補（要求對方修好）之外，在訂定期限請求修補卻未獲處理等特定條件下，也可以請求減少報酬。不過，若不符情形是因委託方所提示的規格或指示本身所導致，除非受託方明知該問題卻未告知，否則原則上無法提出上述請求。模型合約第二版已反映了這項修法。

由於承攬是以完成為交換、承擔強烈責任的合約，適合用在能明確定義「以什麼作為完成標準」的工程。

準委任合約 ── 承諾以專家身分工作的合約

準委任是承諾「會以專家身分執行業務」的合約。受託方不負完成責任，取而代之的是負有善管注意義務，也就是以專家身分執行業務時，須盡通常應有注意的義務。

聽到「沒有完成責任」，委託方或許會感到不安。但這並不代表「可以偷工減料」。若以專家身分卻執行了不恰當的工作，仍會因違反善管注意義務而被追究責任。

此外，修正民法也明文規定了準委任的一種報酬支付方式，稱為成果完成型。與依所執行業務比例支付報酬的履行比例型（以時薪結算為代表方式，也可能採用定型業務按月固定收費的形式）相對，成果完成型是對合意的成果支付報酬。在有需求定義書之類成果物的準委任業務中，採用這種類型可以做成「雖是準委任，但成果物的交付與報酬相互連結」的形式。

依工程區分使用

模型交易‧合約書大致設想了以下的區分方式。

這裡重要的是，這並非「承攬對委託方有利」「準委任對受託方有利」這種單純的說法。

若把尚未確定階段的工作硬是套用承攬，會在完成標準模糊的狀態下，只承諾了完成責任，結果演變成「完成了/沒完成」的各說各話。選擇符合工程性質的合約類型，最終才能保護雙方。

5. 維運合約中應事先決定的事項

開發結束後的維運，潛藏著與開發不同的糾紛種子。最常見的是「月費保養費用到底涵蓋到哪裡」的認知落差。

雖然統稱為維運，實際上是性質不同的業務集合。

• 運行監控、備份、定期維護
• 操作方法等的諮詢對應
• 故障發生時的初步調查‧復原對應
• 缺陷修正
• 追隨作業系統或中介軟體的更新
• 功能新增‧畫面變更等改造

其中，監控‧諮詢對應‧初步調查這類持續性業務，原則上採用準委任型。另一方面，能夠明確定義內容的功能新增或改造，不應曖昧地含括在維運合約中，而應個別報價，以承攬形式切分出來，這樣比較安全。

光用文字說明不容易有實感，這裡舉出劃分界線的例子。線要劃在哪裡是由合約決定的事，因此以下終究只是「常見的折衷做法」。

第四行的「畫面新增一個項目」，從委託方的角度看似乎微不足道，但實際上會牽動設計‧實作‧測試‧發布的整套流程。事先訂下「畫面或報表的項目增減，屬於另外報價」這類不會產生判斷分歧的準則，就能減少每次的協商。

簽約時，建議至少將以下事項以文件形式事先決定。

• 月費（定額）範圍內含的作業，與不含的作業之間的界線
• 諮詢或故障對應的受理時段，以及開始對應為止的大致時間
• 故障重要程度的分級，以及各分級對應的處理方針
• 超出定額範圍的作業發生時，報價‧發包的程序
• 開發時的契約不適合責任（免費修正的對象）與維運合約（有償對應）之間的關係

特別是最後一點，很容易被忽略。交付後不久發現的缺陷，究竟屬於開發合約契約不適合責任的範圍，還是維運合約應對應的範圍，若不在合約中明確訂定期間與條件，就容易成為爭執點。

6. 委託方也有義務 ── 協力義務與專案管理義務

雖然話題稍微擴大一些，但模型交易‧合約書的解說以及過往的判例中，反覆呈現出一個重要的思考方式：系統開發是委託方與廠商的共同作業，雙方都有應盡的義務。

• 廠商方須以專家身分適當管理專案，若有風險須予以說明，這是專案管理義務
• 委託方則負有協力義務，包括決定需求、提供業務內容相關資訊、在期限內做出必要的決策等

也就是說，若委託方以「專業的事我不懂」為由，把一切都交給廠商，也就是所謂的「全部丟給對方」，需求就無法確定，一旦專案失敗，委託方的協力義務也可能被追究。

模型交易‧合約書中，內建了將雙方角色分工文件化，並透過聯絡協議會（定期會議）共享進度與課題的機制。與其把它當成合約範本，不如當成共同營運專案的規則手冊來讀，對委託方而言也是收穫豐富的資料。

7. 規格變更要用「變更管理程序」處理

開發過程中出現「果然還是想把這個畫面改成這樣」的要求，是無法避免的事。問題不在於出現變更本身，而在於只用口頭或 email 往來就把變更推進下去。

• 委託方認為「原本以為只是輕微的變更」
• 受託方則認為「已經處理了，但工時增加了，想請求追加費用」

口頭或 email 的往來雖然也能留下交涉的紀錄，但由於沒有一份雙方正式就變更範圍‧費用‧交付期限都達成合意的文件，一旦演變成這種狀態，就容易變成各說各話。

模型交易‧合約書中訂有變更管理程序，大致流程如下。

提出變更提案（雙方皆可提出）
        ↓
以書面（變更提案書）呈現內容‧影響範圍‧對費用與交付期限的影響
        ↓
雙方協商
        ↓
達成合意則留下書面紀錄後實施變更／未達成合意則維持現狀

重點在於，不只是變更的內容，還要把對費用與交付期限的影響一併合意之後，才著手進行。雖然作為程序多了一道手續，但正是這道手續，能防止「說了/沒說」的爭執。

8. 敏捷開發有專用的模型合約

到目前為止說明的，都是以先確定需求再進行開發的瀑布型為前提的合約。

另一方面，對於邊做邊調整需求的敏捷開發，IPA 於 2020 年 3 月 31 日公布了專用的模型合約，稱為《資訊系統‧模型交易‧合約書（敏捷開發版）》。

敏捷開發版的特徵如下。

• 合約類型以準委任合約為前提。因為這是一種在開發過程中持續新增‧變更功能、重新檢討優先順序的手法，與一開始就確定成果物的承攬並不相容
• 開發方法採用 Scrum，並將角色分工（如產品負責人）納入合約
• 附有簽約前的檢查清單，設計上會先讓委託方與受託方確認專案目的以及對敏捷開發的理解程度，再進入簽約階段

這並不是「因為是敏捷開發所以合約可以曖昧」，而是「正因為是回應變化的開發，才更要透過合約明確角色與進行方式」的設計。

總結

整理從 IPA 資訊系統‧模型交易‧合約書中，可以學到的委託開發‧維運合約思考方式。

• 不把整體開發綁在同一份合約，而是依工程分開簽約（多階段合約）
• 決定「要做什麼」的企劃‧需求定義採準委任，做已確定事物的內部設計以後的開發原則上採承攬（外部設計則兩者皆可能採用）
• 承攬伴隨完成責任與契約不適合責任，準委任伴隨善管注意義務，受託方所負責任的性質不同
• 維運原則上採準委任，定額範圍與個別報價的界線須於簽約時文件化
• 委託方也負有協力義務，全部丟給對方會讓專案失敗
• 規格變更須納入變更管理程序，與費用‧交付期限的影響一併合意
• 敏捷開發有以準委任為前提的專用模型合約

模型合約的範本與解說，可以從 IPA 的網站以 Word 格式免費下載。無論是即將委託開發的人，還是被提示合約書的人，都值得花時間看一次的資料。

給正在考慮委託系統開發‧維護的您

要適切選擇合約形式，前提是必須先整理清楚「要做什麼」「委託範圍到哪裡」「委託方與受託方之間如何分工」。

合同會社小村軟體在承接 Windows 業務應用程式與 Web 系統的委託開發‧維護諮詢時，會依循本文所介紹的多階段合約思考方式，將需求整理階段與開發階段分開提案。即使開發範圍或成果物的整理都還沒開始，也歡迎從確認目前的業務內容開始諮詢。

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

承攬合約與準委任合約有什麼差異？

承攬合約是對「完成決定好的成果物」支付報酬的合約，受託方負完成責任與契約不適合責任。準委任合約則是對「以專家身分執行業務」支付報酬的合約（成果完成型的準委任，是對合意的成果支付報酬），受託方負善管注意義務（以專家身分謹慎執行業務的義務），但不負完成責任。能明確定義要做的東西與完成標準的工程，適合採用承攬；以委託方為主體進行檢討的支援工程，或持續性的業務，則適合採用準委任。

為什麼需求定義建議採用準委任合約？

因為需求定義是由委託方主導決定「要做什麼」的工程，廠商站在支援檢討的立場。此外，在開始階段很難具體確定成果物，若在這個階段就承諾完成責任（承攬），完成的標準會變得模糊，成為糾紛的原因。IPA 的模型交易‧合約書中，企劃‧需求定義工程也是設想採用準委任型。

維運合約適合採用承攬還是準委任？

運行監控、諮詢對應、故障初步調查這類「持續性業務」，不適合「完成」這個概念，因此原則上採用準委任型。另一方面，能明確定義內容與完成標準的功能新增或畫面改造，可以個別切分出來，以承攬形式簽約。重要的是，在簽約時就以文件明確劃分月費維運合約中含括哪些內容、哪些屬於另外報價。

IPA 的模型交易‧合約書可以直接拿來用嗎？

模型合約書以 Word 格式公開，前提是要依自家的交易情況修改後再使用。由於它是以不偏向使用者企業或 IT 廠商任一方的中立立場製作，因此可以當作合約書的草稿，或是確認對方提出的合約書時的比較基準來使用。不過，個別的合約判斷，建議諮詢律師等專業人士。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。