作為系統開發訂單的用戶端應承擔的合作義務是什麼

系統開發的工作，隨著開發系統的規模越大，需要投入的人力和工時也就越多。因此，不僅是承接開發的供應商方，訂購系統開發的訂購人也需要承擔一定的合作義務。

這與一般的訂購和接單關係有所不同。例如，如果不是IT系統，而是向裁縫店訂製定制的西裝，訂購者即客戶（用戶）方並不需要承擔特定的「義務」。「義務」主要由接單者即裁縫店（供應商）方承擔。正因為需要大量的人力和工時的IT系統，用戶也需要與供應商「合作」，這就是其結構。

本文將解釋在不能完全依賴供應商的系統開發中，用戶方需要承擔哪些法律義務。

既然是自家的系統，不能只是全盤托出

即使是一個系統開發項目，往往也會有許多人和組織參與其中。不僅需要精通編碼技術的工程師和程序員，為了將這些人員的輸出整合成一個成果，專案經理的角色也變得非常重要。

然而，即使供應商擁有高技術力和組織力，也不可能僅靠供應商的力量就完成系統開發。例如，只在該公司內部使用的公司內部術語，以及該公司特有的業務知識等，僅靠供應商一方的努力是無法了解的。隨著系統開發規模的擴大，一般來說，該系統將被許多人和業務所使用的公司本身往往也是大型企業。為了使系統開發項目成功，實際上，在電腦工作之前，整理這些業務邏輯往往佔據了很大的比重。

因此，用戶端不應該因為「我不是IT技術專家」這樣的理由而採取被動態度，反而應該積極提供信息，以使項目的進行更加順利。在這個意義上，用戶在系統開發項目中所扮演的角色，實際上並不小。

根據判例，用戶的合作義務是什麼

那麼具體來說，在系統開發項目中，用戶端所承擔的合作義務是什麼呢？對於這一點，過去的判例留下了許多線索。

在審判中，供應商（被告）的交貨期延遲，由於用戶（原告）的決策延遲等原因，用戶對開發的合作義務是否存在成為了爭議點。對於此案，法院認定了用戶端的合作義務違反，否定了供應商端的債務不履行責任。（雖然承認了契約的解除，但也認可了六成的過失抵銷。）

本案的電算系統開發合約是所謂的訂製系統開發合約，這種訂製系統開發合約，承包商（供應商）無法單獨完成系統，委託人（用戶）在開發過程中，需要進行內部意見調整，統一觀點，明確向承包商表達需要什麼功能，與承包商一起，討論需要的功能，最終確定功能，並且，確定螢幕和帳票，驗收成果物等角色分工。

東京地裁平成16年3月10日判決（2004年）

本判決不僅表明系統開發本身是與用戶端的共同工作，而且對於「具體應在哪些方面進行合作」這一點的說明，似乎非常富有啟示。

讓本所嘗試將上述判決文的語言翻譯成系統開發的IT術語。

可以這樣整理。這些都是無論IT系統的專業性有多高，都不能單獨完成而不需要用戶的合作的事情。需要的功能和螢幕佈局應由用戶明確化，而是否實現了所需的功能也只有用戶才能確認。

另外，就像供應商被賦予項目管理義務一樣，用戶也被賦予合作義務，因此，如果用戶在上述過程中違反合作義務，反過來，供應商可能會對用戶提出基於債務不履行或侵權行為的損害賠償請求。

對於事後的規格變更請求，本所該如何理解？

再者，如果本所將系統開發項目視為用戶和供應商的共同工作，那麼本所可以進一步討論更進階的問題。這個問題就是，「如果用戶在事後要求增加功能或進行修正，導致無法按時完成工作，那麼這應該由誰負責？」

一般來說，系統開發的過程包括需求定義、基本設計、詳細設計、製造（程式實現）和測試等步驟，目標是盡可能避免工作回溯（這通常被稱為瀑布模型）。然而，由於某些原因，如果發現前期工作存在缺陷，則可能會導致工作回溯，這在現實中經常發生。

在這種情況下，如果無法按時完成工作，本所應該如何看待呢？從過去的判例來看，根據額外工作發生的時間，結論可能會有所不同。

如果額外工作發生在確定外部設計等規格之前

前述的判例指出，如果在基本設計階段（即在程式實現階段之前）收到用戶的額外開發請求，那麼提出這種要求本身並不特別違反合作義務。

對於用戶向供應商提出在基本設計階段對要建立的系統提出各種要求，這在像本案這樣的系統開發過程中是很正常的，而且，對於沒有專業知識的原告用戶，判斷這些要求是否需要額外的委託費用或延長交付期限等，或者是否會對工作過程造成困擾，是很困難的。因此，不能說原告用戶應該自我克制提出可能導致額外委託費用或延長交付期限等要求。相反，如果原告用戶提出了需要額外委託費用或延長交付期限等要求，那麼負有項目管理義務的被告應該告知原告用戶這一點，並要求撤回要求或討論延長交付期限等問題，以避免開發工作受到影響。

東京地方裁判所2004年（平成16年）3月10日判決

該判決確認了用戶也有一定的合作義務，並指出應該考慮到用戶並非系統開發的專家。也就是說，用戶並非系統開發的專家，因此，在確定開發系統的內容之前，他們可能會提出各種各樣的要求（有時甚至可能不熟悉訂購過程），這並不奇怪。更何況，如果他們的要求需要重新審視交付期限等，那麼要求他們「自己意識到這一點」是過分的。

然而，這裡對供應商的義務，實際上是指他們應該努力進行溝通，例如要求延長交付期限（或者，如果不能改變交付期限，則建議撤回額外的要求）。因此，這並不意味著他們有義務接受所有用戶的要求，並且必須按照原定的日期交付所有產品。因此，本所需要注意這一點。

如果額外工作發生在製造或測試階段確定規格之後

如果本所從上述判決的內容中推斷出，如果在規格已經確定之後進行額外開發，那麼結論可能是什麼，本所可以在一定程度上預測出來。在這種情況下，這種要求可能會被拒絕。確實，無論規格確定之前還是之後，用戶和供應商方對開發工作的理解程度都存在很大的差距。

然而，如果在規格確定之後改變或增加訂單內容，則可能需要重新進行工作。在這種情況下，即使是因為「他們是客戶，所以自然會提出各種要求」而為交付延遲辯護，也往往很困難。此外，如果有很多規格變更或功能增加在事後發生，那麼這可能會引起疑問，即在事前已經完成的基本設計等上游工作階段是否存在用戶的合作義務違反。

從這些方面來看，對於在規格一度確定之後進行的規格變更，如果這導致了交付延遲，那麼將其視為供應商的責任可能並不現實。從前述的判決文中，本所可以合理地推斷出這種含義。

此外，這種判斷往往不僅基於契約，還基於與系統開發進度相符的會議記錄等證據。

總結：重要的是不要忘記需求定義是用戶端的過程

雖然需求定義是供應商展示技術的一個重要環節，但首先本所應該意識到這本質上是用戶端的業務。即使是由外部專家協助建立的系統，只要該系統是公司內部使用的，那麼在法律上，本所認為該系統應該在公司的治理範疇內。

如果用戶端在開發過程中不願意合作，即使專案出現問題，法院也可能對用戶端持嚴格的立場。首先，本所應該認識到這一點。