在承包型系統開發中，契約書的重要檢查點是什麼？

日本經濟產業省在「日本資訊系統信賴度提升指南」中，提出了IT系統開發合約的模範條款。隨著網際網路的普及等因素，資訊系統的故障導致業務或服務停止、功能下降的社會影響日益嚴重。在此情況下，提高系統的可靠性和安全性已成為當務之急。然而，由於IT系統開發這種合約類型的交易內容往往不清晰，因此，這些條款旨在使其可視化，並明確劃分角色與責任關係。本文將引用經濟產業省模範合約的條款，解釋在簽訂承包型合約進行IT系統開發業務時，契約書的檢查要點。

系統開發與承包合約

何謂承包合約

在民法中，承包合約的規定如下：

第632條
承包合約的效力源於一方承諾完成某項工作，而另一方則承諾支付該工作成果的報酬。

在承包合約中，「承諾完成某項工作」是條文的要件。例如，如果合約的目的是在期限內完成某個系統的開發，則供應商的債務就是「在期限內完成系統」。如果無法在約定的期限內完成系統，可能會被課以履行遲滯的債務不履行責任。然而，如果在期限內完成並交付系統後發現有瑕疵，由於前述的供應商債務已經履行，所以不會出現債務不履行的問題，而是變成瑕疵擔保責任的問題。

與準委任契約的區別

在承包合約中，供應商負有完成工作的義務，因此，如果交付的成果物有瑕疵，則需要承擔瑕疵擔保責任。相對地，在準委任契約中，並無完成工作的義務，因此，不需要承擔承包合約中的瑕疵擔保責任。然而，在事務處理過程中，如果認定有善管注意義務，則可能需要承擔損害賠償等的債務不履行責任。

承包型模型條文與檢查點

需求定義創建支援業務

需求定義是將用戶試圖建立的系統的需求規範整理的工作。在需求定義階段，本所將考慮系統建設的方向，並決定要建立何種系統。由於成果物不能具體預期，因此日本經濟產業省的模型契約將其規定為準委託型。更多信息請參閱以下文章。

外部設計書製作業務

（實施外部設計書製作業務）
第○條 乙方應在簽訂第○條所定的個別合約後，根據第〇條的規定確定的需求定義書，進行本項軟體的外部設計書製作業務。

2.在實施外部設計書製作業務時，乙方可以要求甲方提供必要的協助，甲方在被乙方要求協助時，應適時回應。

外部設計書的製作是規劃螢幕、報表等介面使用的業務。外部設計書應該包含所有基於其供供應商開發程式的資訊。雖然外部設計書包含了詳細的格式使用內容，但能夠更改需求規格的只有決定業務內容的用戶端。然而，如果需求定義書（前期階段的成果）已經明確定義了用戶的需求，並明確了供應商需要完成的工作內容，那麼就可以以承包形式讓供應商主導製作外部設計書。

第一項規定了，由於本工程是承包型，所以供應商是業務執行的主體。然而，即使是承包型的合約，由於外部設計與用戶的業務內容確定有很大的關聯，因此需要用戶積極參與。因此，第二項明確規定了，供應商可以要求用戶提供系統規格的討論和決定所需的協助，並且用戶應適時回應，系統規格的討論是供應商和用戶的共同工作。

（簽訂與外部設計書製作業務相關的個別合約）
第○條 甲方和乙方應對外部設計書製作業務進行協商，確定第〇條第〇項記載的交易條件，並簽訂與外部設計書製作業務相關的個別合約。

關於外部設計書製作業務的範圍等，應根據前條規定的交易條件，在個別合約中進行決定。

（外部設計討論會）
第○條 乙方應根據需要，以適當的頻率舉行外部設計書製作的聯絡協議會（以下在本節中稱為「外部設計討論會」），以明確化或確認製作外部設計書所需的事項，甲方應參加此會議。

2.甲方也可以在認為需要製作外部設計書時，舉行外部設計討論會，乙方應參加此會議。

3.如果甲方在外部設計討論會的討論等過程中，想要更改需求定義書的內容，並且需要更改工作期間、委託費等個別合約的條件，則應按照第33條（更改本合約和個別合約的內容）的程序進行。

決定螢幕、報表等介面的外部設計書製作需要用戶和供應商的協同工作。由於本工程是承包型，第一項規定了討論會的主辦方是供應商，用戶應參加。所有需要明確化或確認的事項都應在外部設計討論會上進行，供應商和用戶都應受討論會的討論結果的約束。

第二項規定了，用戶也可以在認為需要製作外部設計書的時候，舉行外部設計討論會。
第三項規定了，如果在討論等過程中，用戶想要更改需求定義書的內容，並且可能影響到個別合約所定的工作期間、委託費等，則應按照另一條規定的本合約和個別合約的內容更改的方法進行。

（交付外部設計書）
第○條 乙方應在個別合約規定的期限內，將外部設計書和外部設計書驗收請求書（兼交貨單）交付給甲方。

由於本工程是承包型，所以供應商應將外部設計書等作為成果物交付。

（外部設計書的批准和確定）
第○條 甲方應在個別合約規定的期間（以下稱為「外部設計書的檢查期間」）內，檢查外部設計書是否符合第〇條的規定確定的需求定義書和第○條所定的外部設計討論會的決定事項，以及是否沒有邏輯錯誤，並將甲方乙方雙方的負責人簽名蓋章在外部設計書批准書上，作為批准並確認沒有邏輯錯誤的證明。但是，如果在檢查的結果中，發現外部設計書與第○條的規定確定的需求定義書和外部設計討論會的決定事項不符，或者發現有邏輯錯誤，乙方應在協商後確定的期限內製作修正版並提交給甲方，甲方應再次進行上述檢查和批准的程序。

2.如果在外部設計書的檢查期間內，甲方沒有以書面形式明確提出具體理由的異議，則甲方應在外部設計書的檢查期間結束時，視為已批准外部設計書。

3. 以甲方的批准為準，外部設計書應視為已確定。

在外部設計階段，將確定後續內部設計書製作等所需的需求，但如果需求的確定仍然模糊，則在後續的開發中可能會出現問題。本條規定了用戶應檢查並批准後續開發工作的前提——外部設計書，並確定其手續。

第一項規定了，用戶應檢查外部設計書與另一條規定確定的需求定義書和外部設計討論會的討論結果是否一致，以及外部設計書是否沒有邏輯錯誤。在批准外部設計書的檢查中，可能會判定需要修正，因此同項但書規定了這種情況的手續。
第二項是即使批准的簽名蓋章未完成，但如果在一定期間內用戶沒有提出異議，則視為用戶已經批准的規定。如果在內部設計開始時，用戶的批准情況仍然模糊，則可能會在後續引發問題，因此本項的目的是防止這種問題。

然後，第三項規定了，以用戶的批准為準，外部設計書應視為已確定。

（瑕疵擔保責任）
第○條 在前條確定後，如果發現外部設計書與需求定義書和第○條所定的外部設計討論會的決定事項不一致，或者有邏輯錯誤（以下在本條中稱為「瑕疵」），甲方可以要求乙方修正該瑕疵，乙方應修正該瑕疵。但是，乙方只有在前條確定後○個月內收到甲方的請求時，才需要承擔這種修正責任。

2.儘管有前項的規定，但如果瑕疵輕微，並且修正外部設計書需要過多的費用，乙方不需要承擔前項所定的修正責任。

3.第1項的規定不適用於由於甲方提供的資料等或甲方的指示導致的瑕疵。但是，如果乙方知道該資料等或指示不適當，卻沒有告知，則不在此限。

本條規定了外部設計書的瑕疵擔保責任。瑕疵擔保期間應根據資訊系統的規模、對價等因素，由雙方協商確定一個合理的期間。

第一項規定了，外部設計書與需求定義書和外部設計討論會的決定事項不一致，或者外部設計書有邏輯錯誤，應視為瑕疵。

第二項規定了，即使瑕疵輕微，但如果修正交付物需要過多的費用，則不應無償要求供應商修正，這是參照民法第634條第1項但書，以保護供應商。

第三項規定了，參照民法第636條但書，如果瑕疵是由於用戶的指示或提供的資料等導致的，則供應商可以免除擔保責任。但是，如果供應商知道該資料等或指示不適當，卻沒有告知，則不在此限。

另外，瑕疵擔保責任是任意規定，因此，如果沒有設置這種規定，則應按照民法的一般原則進行處理。瑕疵擔保責任受到2020年4月施行的修訂民法的大影響，因此，在修訂民法施行後，處理方式將與以前不同。詳細內容請參見以下的文章。

軟體開發業務

（軟體開發業務的實施）
第〇條 乙方應在簽訂第25條所定的個別合約後，根據前各節確定的系統規格書，從內部設計到系統測試進行軟體開發業務。

2.在實施軟體開發業務時，乙方可以要求甲方提供必要的協助，甲方在被乙方要求協助時，應適時回應。

以下條款規定了軟體開發供應商以承包方式進行的情況。在系統內部設計階段，通常已經定義了開發目標和規格，因此，經濟產業省的模型合約將其規定為承包型。

（與軟體開發業務相關的個別合約的簽訂）
第〇條 甲方和乙方應就該軟體開發業務，協商確定第〇條第〇項記載的交易條件，並簽訂與軟體開發業務相關的個別合約。

關於軟體開發業務的範圍等，應根據前面確定的交易條件，在個別合約中進行決定。

（交付物的交付）
第〇條 乙方應在個別合約規定的期限內，將個別合約所定的交付物與驗收請求書（兼交貨單）一同交付給甲方。
2.甲方在收到交付物後，應根據下條的檢驗規格書，按照第〇條（本案軟體的驗收）的規定進行檢驗。
3.乙方在交付交付物時，可以要求甲方提供必要的協助，甲方在被乙方要求協助時，應迅速回應。
4.關於交付物的滅失、毀損等風險負擔，交付前由乙方負擔，交付後由甲方負擔。

由於本工程是承包型，因此將完成的軟體等作為檢驗對象的成果物進行交付。第1項規定了與驗收請求書（兼交貨單）一同交付交付物。

第2項規定了用戶進行檢驗的實施。
第3項規定了用戶的協助義務，因為在交付到個別合約規定的交付地點時，可能需要用戶的協助（例如將交付物運送到用戶的辦公室，或將交付物交付到用戶的實際運營環境中）。
第4項是關於交付物發生滅失或毀損的風險負擔條款，根據物理控制的轉移來劃分風險負擔的轉移時間。

（本案軟體的驗收）
第〇條 對於交付物中的本案軟體，甲方應在個別合約規定的期間（以下稱「檢驗期間」）內，根據前條的檢驗規格書進行檢驗，並檢查系統規格書和本案軟體是否一致。

2.如果本案軟體符合前項的檢驗，甲方應在檢驗合格書上簽名蓋章，並交付給乙方。另外，如果本案軟體未通過前項的檢驗，甲方應迅速向乙方交付明確說明不合格原因的書面，並要求修正或補充，如果認可不合格的原因，乙方應在協商確定的期限內無償修正並交付給甲方，甲方應在必要的範圍內，再次進行前項規定的檢驗。

3.即使未交付檢驗合格書，如果在檢驗期間內，甲方未以書面明確說明具體原因提出異議，則本案軟體將被視為通過本條規定的檢驗。

4.以本條規定的檢驗合格為準，確認本案軟體的驗收完成。

由於本工程是承包型，因此本條規定了對交付的軟體進行驗收的程序。

第1項規定了對本案軟體進行檢驗，並檢查系統規格書和本案軟體是否一致。
第2項規定了如果發現本案軟體不符合系統規格書，供應商有義務修正。
第3項通過設定視為檢驗合格的規定，防止因用戶的原因導致驗收延遲。
第4項明確規定了檢驗合格即為本案軟體的驗收完成。

（瑕疵擔保責任）
第〇條 在前條的檢驗完成後，如果發現交付物與系統規格書不一致（包括漏洞，以下在本條中稱為「瑕疵」），甲方可以要求乙方修正該瑕疵，乙方應修正該瑕疵。但是，乙方負擔修正責任的情況僅限於在前條的驗收完成後○個月內由甲方提出請求的情況。
2.儘管有前項的規定，如果瑕疵輕微，並且修正交付物需要過多的費用，則乙方不需要負擔前項規定的修正責任。
3.第1項的規定不適用於由於甲方提供的資料等或甲方的指示導致的瑕疵。但是，如果乙方知道該資料等或指示不適當，但未告知，則不在此限。 　

由於本工程是承包型，因此本條規定了交付物的瑕疵擔保責任。在履行未完成（工作未完成）的情況下的債務不履行責任，和履行已經基本完成（工作已完成）後的情況下的瑕疵擔保責任的界限，在實務上判斷有一定的困難。有一個判例（東京地判平成14年4月22日）認為，對於系統開發，是否認為系統已完成，應以是否完成了最初的承包合約預定的最後工程為準。在軟體開發完成並交付並通過檢驗後，如果發現瑕疵，則原則上應適用瑕疵擔保責任。

第1項將在軟體開發業務中產生的「與系統規格書不一致」視為瑕疵。對於在外部設計階段產生的功能不足等，應根據外部設計階段的瑕疵擔保責任等規定來確定責任所在，而不是本條。瑕疵擔保期間應根據資訊系統的規模、對價等因素，由雙方協商確定相當的期間。

第2項規定了即使瑕疵輕微，如果修正交付物需要過多的費用，則不需要無償修正，這是參照民法第634條第1項但書的規定。

第3項參照民法第636條但書，如果瑕疵是由於用戶的指示或提供的資料等導致的，則供應商不需要負擔擔保責任，但是如果供應商知道該資料等或用戶的指示不適當，但未指出，則不能免除擔保責任。

軟體運用準備與遷移支援業務

在系統的接收和導入階段，一般來說，使用者會主動進行。因此，在日本經濟產業省的模範合約中，規定了使用者為主體，供應商為輔助的半委託型態。

確定合約的性質

為了確定合約的性質，本所需要全面考慮合約，並從其目的是「提供完成的成果物」還是供應商「合理地完成業務」這兩點來進行審查。是否有具體確定的目標物品，並且是否已經朝著該目標進行項目，這將成為大致的衡量標準。