在進行準委託型系統開發時，合約書的檢查要點

現在，本所的國家在國民生活和社會經濟活動中的IT使用度，隨著電腦處理能力的飛躍提升和互聯網的普及等，正在急速增長。因此，由於信息系統的故障導致業務和服務的停止或功能下降的社會影響，每天都在擴大，系統的可靠性和安全性的提高已成為一個重大的課題。

另一方面，由於在立法初期沒有預見到IT系統開發這種契約的累積，交易內容往往變得模糊，訂單者（用戶）和接單者（供應商）之間密切的溝通成為了交易的前提，角色分工和責任關係的明確化已成為一個課題。

此外，由於信息系統已經由多種元素的組合構建，因此已經開始包含以前不存在的組合等相關風險。

為了提高這種信息系統的可靠性和安全性，經濟產業省已公布了指導方針，在其中，已經提出了系統開發的模型契約，並附有逐條的解釋。

本文將引用經濟產業省的模型契約條款，解釋在IT系統開發業務中，簽訂準委託型契約時的契約檢查要點。

系統開發與準託管合約

何謂準託管合約

準託管合約在民法中，是以託管合約的條文為準則來規定的。

第10節 託管
第643條 託管是當事人的一方將法律行為委託給對方，對方接受後，該行為即產生效力。
第656條 本節的規定，對於非法律行為的事務委託亦適用。

準託管合約是指某人受他人委託，以處理事務為目的的合約。受託者有義務以善良管理者的注意義務（善管注意義務）來執行業務。善管注意義務簡單來說，就是「盡全力」的意思。

與承攬合約的區別

在準託管合約中，如上所述，受託者有善管注意義務，但與承攬合約不同，並無完成工作的義務。因此，如果沒有明確的目標物，受託者就不需要承擔瑕疵擔保責任。
然而，由於受託者有善管注意義務，如果出現職務怠慢或嚴重疏忽等情況，可能需要承擔基於債務不履行的損害賠償責任，或者可能會被解除合約。

如上所述，在準託管合約中，並無完成工作的義務。相反，在承攬合約中，有完成工作的義務。以下的文章將解釋在承攬型的情況下簽訂系統開發合約的情況。

關于系統開發合約的更多信息，請參閱以下文章。

準委任型模型條文與檢查點

需求定義創建支援業務

（需求定義創建支援業務的實施）
第〇條 乙方方，在簽訂第〇條所定的個別合約後，將根據甲方方創建的信息系統構想書、系統化計劃書等，提供支援甲方方創建需求定義書的服務（以下稱為「需求定義創建支援業務」）。

2. 乙方方，基於專業的信息處理技術知識和經驗，將以良好管理者的注意力進行調查、分析、整理、提議和建議等支援業務，以確保甲方方的工作順利且適當地進行。

需求定義是將用戶希望建立的系統的需求規範（應由軟體實現的功能）整理的工作，並且這項工作大量依賴於用戶的業務內容。因此，本節規定，需求定義工作由用戶進行，供應商支援，並以準委託合約的形式進行。然而，即使是準委託，供應商也不是完全不承擔責任，作為受託者，他們有善管注意義務，如果由於疏忽這一義務，導致需求定義創建支援未能適當進行，則將承擔因違反善管注意義務而產生的債務不履行責任。

（關於需求定義創建支援業務的個別合約簽訂）
第〇條 甲方方和乙方方，將就需求定義創建支援業務，協商確定第〇條〇項記載的交易條件，並簽訂關於需求定義創建支援業務的個別合約。

關於需求定義創建支援業務的範圍等，將按照前述條款中所示的條件，在個別合約中進行決定。

（需求定義討論會）
第〇條 甲方方，為了進行需求定義書創建所需的事項的明確化或內容的確認等，將在認為必要的頻率下，召開關於需求定義書創建的第〇條所定的聯絡協議會（以下在本節中稱為「需求定義討論會」），乙方方將參加此會議並實施需求定義創建支援業務。

2. 乙方方，當認為實施需求定義創建支援業務所需時，也可以召開需求定義討論會，甲方方將參加此會議。

為了創建定義業務需求和系統的功能需求和非功能需求的需求定義書，需要用戶的業務部門和信息系統部門以及供應商的協同工作。由於本工程是準委託型，第1項規定，召開會議的主體是用戶，而提供支援的供應商將參加這個會議。需求定義書創建所需的事項的明確化或內容的確認等，都將在需求定義討論會上進行，用戶和供應商將受到討論會的討論結果的約束。

第2項規定，供應商也可以在實施需求定義支援業務所需的情況下，召開需求定義討論會。

（需求定義書的確定）
第〇條 當甲方方完成需求定義書的創建時，甲方方和乙方方將在個別合約中規定的期間（以下稱為「需求定義書的檢查期間」）內，檢查需求定義書是否符合前條所定的需求定義討論會的決定事項，並以甲方乙方雙方的負責人在需求定義書上簽名蓋章作為確認符合的證明。但是，如果檢查結果，需求定義書不符合需求定義討論會的決定事項，甲方方將在協商確定的期限內創建修訂版，甲方方和乙方方將再次進行上述的檢查和確認程序。

2. 以甲方乙方雙方的確認為準，需求定義書將被確定。

3. 如果由於第〇項的修訂，需要改變工作期間、委託費等個別合約的條件，則按照第〇條的程序進行。

需求定義是在接收到供應商的概算估價級別的估價提議後，確定實施系統設計等所需的需求的階段。如果需求仍然模糊，供應商將難以提供準確的估價，並且在後續的開發階段可能會出現問題。本條規定，用戶和供應商確認作為後續開發工作的前提的需求定義書，並通過負責人的簽名蓋章確定。在確定需求定義書的檢查中，可能會判定需要修訂，因此，第1項的但書規定了這種情況的程序。

第2項明確規定，需求定義書將由用戶和供應商雙方的確認確定。
第3項規定，如果由於第1項的但書導致需求定義書的修訂並重新檢查，導致供應商的工作量增大或需要延長時間表等，可能會導致個別合約的條件變更，應進行必要的變更。

（業務的結束和確認）
第〇條 乙方方，在確定前條的需求定義書後的○天內，將創建業務結束報告書並提交給甲方方。

2. 甲方方，將在個別合約中規定的期間（以下稱為「需求定義創建支援業務結束的檢查期間」）內，確認該業務結束報告書。

3. 甲方方，如果對該業務結束報告書的內容沒有疑義，將在業務結束確認書上簽名蓋章，並交付給乙方方，確認需求定義創建支援業務的結束。

4. 如果在需求定義創建支援業務結束的檢查期間內，甲方方沒有以書面形式明確說明具體理由提出異議，則甲方方將被視為在需求定義創建支援業務結束的檢查期間結束時，確認了業務的結束。

由於本工程是準委託型，本條規定，為了確認供應商是否根據善管注意義務適當地執行了支援工作，將通過記錄工作內容的業務結束報告書進行確認的程序。
第1項規定了業務結束報告書的提交義務。
第2項為了避免報告書的確認延遲，明確了報告書的檢查期間。
第3項規定了用戶在業務結束確認書上簽名蓋章，確認需求定義書創建支援業務結束的事項。
第4項規定了在檢查期間內，如果用戶沒有以書面形式提出異議的情況下的視為確認結束。這一規定考慮到，如果用戶由於某種原因未能及時進行確認程序，可能會導致後續工作的延遲，或者在未明確確認的情況下開始後續工作，可能會使用戶和供應商之間的責任關係變得模糊。

外部設計書製作業務

（實施外部設計書製作支援業務）
第〇條 乙方方在簽訂第〇條所定的個別合約後，將提供甲方方外部設計書製作工作的支援服務（以下稱為「外部設計書製作支援業務」）。

2. 乙方方將根據其在資訊處理技術方面的專業知識和經驗，以善良管理者的注意力進行調查、分析、整理、提議和建議等支援業務，以確保甲方方的工作能夠順利且適當地進行。

外部設計書的製作是規劃螢幕、報表等介面相關部分使用的業務。外部設計書應該包含所有基於此文件供供應商開發程式的資訊。雖然外部設計書包含了詳細化的格式使用內容，但能夠改變需求規格的只有決定業務內容的用戶端。
因此，本條款假定外部設計書由用戶負責完成，供應商則在準委託合約中作為受託人，支援外部設計書的完成。
然而，即使是準委託，供應商也不是完全不負責任，他們作為受託人需要負擔善管注意義務。因此，如果由於疏忽這種善管注意義務，導致外部設計書的製作支援未能適當進行，則可能需要承擔因違反善管注意義務而產生的債務不履行責任。

（簽訂與外部設計書製作支援業務相關的個別合約）
第〇條 甲方方和乙方方將就外部設計書製作支援業務，協商確定第4條第1項所述的交易條件，並簽訂與外部設計書製作支援業務相關的個別合約。

外部設計書製作支援業務的範圍等將在個別合約中決定。

（外部設計討論會）
第〇條 甲方方將根據需要，以適當的頻率舉行外部設計書製作相關的第〇條所定的聯絡協議會（以下在本節中稱為「外部設計討論會」），以明確化或確認製作外部設計書所需的事項，並且乙方方將參加這些會議，實施外部設計書製作支援業務。

2. 乙方方也可以在認為實施外部設計支援業務所需的情況下，舉行外部設計討論會，並且甲方方將參加這些會議。

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

決定螢幕、報表等介面的外部設計書的製作，需要用戶和供應商的協同工作。
由於本工程是準委託型，第1項規定了由主辦方和用戶主持，並由提供支援的供應商參加的形式。所有需要製作外部設計書的事項的明確化或內容確認等，都在外部設計討論會上進行，供應商和用戶都受到討論會的討論結果的約束。
第2項規定了供應商也可以在需要實施外部設計支援業務的情況下，舉行外部設計討論會。
第3項規定了，如果用戶打算根據外部設計討論會的討論等內容，改變需求定義書的內容，可能會影響個別合約所定的工作期間、委託費等，因此應按照本合約及個別合約內容的變更的程序進行。

（外部設計書的確定）
第〇條 當甲方方完成外部設計書的製作時，甲方方和乙方方應在個別合約中規定的期間（以下稱為「外部設計書的檢查期間」）內，檢查外部設計書是否符合第〇條規定的確定的需求定義書和前條所定的外部設計討論會的決定事項，並且甲方方和乙方方的負責人應為確認其符合的證明，在外部設計書上簽名蓋章。但是，如果在檢查的結果中，發現外部設計書不符合第〇條規定的確定的需求定義書和外部設計討論會的決定事項，甲方方應在協商確定的期限內製作修訂版，並且甲方方和乙方方應再次進行上述檢查和確認的程序。

2. 以前項的甲方方和乙方方的確認為準，外部設計書應視為已確定。

3. 如果由於第1項的修訂，需要改變工作期間、委託費等個別合約的條件，則應按照第〇條（本合約及個別合約內容的變更）的程序進行。

本條款規定了用戶製作的外部設計書由用戶和供應商確認，並由負責人簽名蓋章以確定的程序。
在確定外部設計書的檢查中，可能會判定需要修訂，因此第1項的但書規定了這種情況的程序。

第2項明確規定了，以用戶和供應商的確認為準，外部設計書應視為已確定。
第3項規定了，如果由於第1項的但書導致需要修訂外部設計書並重新確認，可能會導致供應商的工作量超出最初的預期，或者需要延遲時間表等，需要改變個別合約的條件，因此應進行個別合約的變更。

（業務的結束和確認）
第〇條 乙方方應在前條規定的外部設計書確定後的○日內，製作業務結束報告書，並提交給甲方方。

2. 甲方方應在個別合約中規定的期間（以下稱為「外部設計書製作支援業務結束的檢查期間」）內，確認該業務結束報告書。

3. 如果甲方方對該業務結束報告書的內容沒有疑義，則應在業務結束確認書上簽名蓋章，交付給乙方方，並確認外部設計書製作支援業務的結束。

4. 如果在外部設計書製作支援業務結束的檢查期間內，甲方方沒有以書面形式明確提出具體理由的異議，則甲方方應視為在外部設計書製作支援業務結束的檢查期間結束時，確認了業務的結束。

由於本工程是準委託型，本條款規定了為了確認供應商是否根據善管注意義務適當地實施了支援工作，應通過記錄工作內容的業務結束報告書進行確認的程序。
第2項為了避免報告書的確認延遲，明確了檢查期間。
第3項規定了用戶在業務結束確認書上簽名蓋章，以確認外部設計書製作支援業務的結束。
第4項規定了在檢查期間內，如果用戶沒有以書面形式提出異議，則視為確認了業務的結束。這個規定考慮到了如果用戶由於某種原因未能及時進行確認的程序，可能會導致後續工作的延遲，或者在未明確確認的情況下開始後續工作，可能會使用戶和供應商之間的責任關係變得模糊。

軟體開發業務

在基本設計的系統外部設計工程規定之後，接下來是詳細設計的系統內部設計工程規定。在系統內部設計工程中，通常在前階段的工作中已經定義了開發對象和規格，因此在日本經濟產業省的模型合約中，這被規定為承包型。詳細內容已在以下文章中解釋。

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

（軟體運用準備與遷移支援業務的實施）
第〇條 乙方方在簽訂第條所定的個別合約後，將為甲方方進行系統測試、導入與接收支援以及實際運用本軟體所需的運用測試業務，提供必要的支援（以下稱為「軟體運用準備與遷移支援業務」）。

2. 乙方方將根據其在資訊處理技術方面的專業知識和經驗，以善良管理者的注意力，確保甲方方的工作能夠順利且有效地進行。

以下條款規定了以準委任型進行軟體運用準備與遷移的情況。在系統接收與導入支援階段，一般由用戶主導，因此，經濟產業省的模型合約規定了用戶為主體，供應商為支援的準委任型。第2項規定了由於本工程為準委任型，供應商作為受任者需承擔善管注意義務。

（業務的結束與確認）
第 32 條 乙方方應在軟體運用準備與遷移支援業務結束後○日內，製作業務結束報告書並提交給甲方方。

2. 甲方方應在個別合約所定的期間（以下稱為「軟體運用準備與遷移支援業務結束的檢查期間」）內，對該業務結束報告書進行檢查。

3. 若甲方方對該業務結束報告書的內容無疑義，應在業務結束確認書上簽名蓋章，交付給乙方方，確認軟體運用準備與遷移支援業務的結束。

4. 若在軟體運用準備與遷移支援業務結束的檢查期間內，甲方方未以書面形式明確指出具體理由提出異議，則視為在檢查期間結束時確認了業務的結束。

本條規定了以準委任型進行軟體運用準備與遷移支援作業，並根據供應商的善管注意義務確認其是否適當執行的程序。
第2項規定了供應商應在業務結束後的所定期間內向用戶提交業務結束報告書。
第3項在明確檢查期間後，規定了用戶應對業務結束報告書進行確認。
第4項規定了用戶若未進行前2項的業務結束確認，則視為已確認。

確定合約的性質

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