在系統開發的規格書中未列明的功能,法律上應該實現到何種程度?

在企業中使用的IT系統開發項目原則上，都是按照預先定義的規範來製作的。然而，另一方面，考慮到供應商作為系統開發專家被全權委託開發業務的意義，用戶端的期望可能不僅僅是機械地實現規範中所寫的內容。本文將解釋對於「規範中未提及，但根據開發目的，需要實現的程式」，應該承擔多大的實現義務。

實現未在規範中的事物所伴隨的法律問題

供應商的業務需要裁量權

在與系統開發項目相關的合約以及相關的各種法律問題中，一個重要的特點是接受工作的供應商擁有大量的裁量權。

相關文章：系統開發中的項目管理義務是什麼[ja]

然而，這裡所說的「裁量權」並不一定適用於所有的系統開發過程。在詳細列出各個過程並進行細節任務的分解後，可能會出現許多接近簡單工作的任務。但是，一般來說，在這些問題的細分化之前，也就是在上游過程的業務中，越是如此，就越難以完成業務而不擁有大量的裁量權。上游過程越是與合約類型相符合，越容易適應準委任，這也是其中的一個原因。

相關文章：系統開發中的承包合約與準委任合約的區別和差異[ja]

裁量權應在嚴格的開發過程中發揮

然而，即使開發系統的供應商有大量的裁量權，也不能隨意接受客戶的要求，這將對後續的過程造成巨大的損害。一個IT系統是由許多細小的部件組成的，即使在外觀上只是微小的變化，從開發者的角度來看，也可能需要大量的工作時間來進行變更。關於系統開發的規範變更，本所在以下的文章中從法律的角度解釋了變更管理的方法。以下的文章雖然是關於變更管理的方法，但也討論了從技術人員的角度來看，規範的變更對業務有多大的影響。

相關文章：從法律的角度看，系統開發中的變更管理應如何進行[ja]

不受規範的限制，專家應該做什麼

為了順利進行系統開發項目，預先定義開發要求並按照這些要求進行計劃是非常重要的。然而，只是按照事先定義的要求做事，只是做被告知的事情，作為系統開發專家，有時候可能無法充分發揮其作用。在這種兩難的情況下，「雖然規範中沒有顯示，但應該實現的是什麼」這個問題就會顯現出來。

法律義務的確定，需依照規格書或合約的「宗旨」

即使合約或規格書中並未明確記載實施內容，本所仍需根據這些合約或規格書中的「宗旨」，也就是「以何種意義或意圖來達成這樣的決定」來確定。以下，讓本所一起來看看一些相關的判例。

由於未有記載，實施義務被否定的判例

以下引述的判例中，供應商開發的系統進行到臨時運行階段，卻因為缺乏必要的功能而導致合約解除的爭議。用戶主張缺少的是「數據自動更新功能」，並主張這是該系統的主要銷售點，但法院並未認可這一實施義務。

如上所認定，本案合約書以及基本設計書和詳細設計書中，並未有記載表明③功能是本案系統的開發對象。

原告主張，③功能是被告對原告的本案系統的主要銷售點，並強調該功能的必要性，但如果其主張成立，那麼該情況應該會在本案合約書等文件中明確記載，既然沒有，則難以認為同意開發該功能。

東京地方裁判所平成21年(2009年)2月18日

該判決確實可以簡單地得出結論，即「如果設計書中沒有記載，那麼不需要製作不存在的東西」。但更準確地說，這不僅僅是形式上是否在設計書中有記載的事實，而是基於設計書和合約書記載的「意義」進行的判斷。也就是說，「考慮到設計書和合約書中沒有記載的原因，本所可以合理地認為，也沒有對應記載的協議」。

即使未記載，實施義務也被確認的判例

另一方面，即使契約或規格書中未有記載，也有判例認為應確認實施的義務。以下引述的判例是關於開發用於管理藥物服用歷史的系統，無法從現有系統轉移數據到新系統，無法利用新系統，用戶方面進行了契約的解除。然而，供應商方面認為數據轉移不在業務範圍內，因此引發了爭議。

新系統的開發往往伴隨著現有系統的撤除和數據的轉移等工作。關於這些業務的重要性和相關的法律問題，本所在以下的文章中也進行了詳細的解釋。

相關文章：系統開發中從舊系統轉移的法律問題[ja]

現有系統中已保存超過五萬名患者的數據，原告利用這些數據來提高工作效率，如果不能將患者數據從現有系統轉移到本案系統，對藥房的調劑業務造成障礙是明顯的，原告代表也應該認識到這一點。而且，在本案契約簽訂前，原告代表對被告代表提出了關於數據轉移是否可能的問題，被告代表也承認了這一點（中略），原告代表認識到可能需要手動輸入超過五萬名患者的數據，決定引入本案系統是難以想象的。此外，如上述(1)所述，被告因無法將現有系統的藥歷數據轉移到本案系統，因此將這些數據打印在紙上，然後將其轉換為PDF文件等處理，即使在本案契約中並未預設數據轉移，被告作為服務進行這種費時的工作也是難以想象的。

東京地判平成22年11月18日 (2009年)

在這裡也重要的是，可以說是契約的目的和契約書的記載事項的「意義」。如果雙方當事人在認識到數據轉移不在業務範圍內的情況下簽訂了契約，法院指出了這一點，即用戶和供應商都以不自然的意圖簽訂了契約。也就是說，用戶接受了大量的手工作業，供應商也知道將來會對用戶的業務造成障礙，但仍然參與了項目，這是非常不合理的。

從兩個判決中本所可以了解到什麼

即使在契約和規格書中沒有關於數據遷移的記載，實施的義務也被肯定，背後的原因之一可能與「數據」這個不會在螢幕上顯示的事項有關。前述的「必要功能的缺失」本質上是直接顯示在系統螢幕和外觀上的事物。因此，即使是系統開發的新手，也不難發現規格書的遺漏。相反，數據遷移的問題對於系統開發的新手來說，其過程的重要性、業務的難度和工時等都難以認識，這是其特點。因此，也有可能是因為供應商應該專業地順利地處理這些事項。

這樣看來，規格書和契約的遺漏與用戶的「合作義務」也密切相關。也就是說，問題在於用戶是否真正履行了簽訂契約和製作規格書的「合作義務」。關於系統開發項目中用戶應履行的法律義務的全面解釋，請參見以下文章。

相關文章：系統開發訂單方即用戶端的合作義務是什麼[ja]

如果您也查看了上面的文章，那麼您可能會理解，用戶端在螢幕和必要功能的確認等方面需要大量的合作，而在數據遷移的考慮遺漏中，情況則大不相同。

如何看待不在規格書中的開發報酬

此外，與本文主題相關的另一個值得關注的問題是，如果製作了規格書中沒有的東西，是否可以在法律上認可增加報酬的請求。關於報酬增加的可行性以及可能的情況下的估價金額的計算方法等，本所在以下的文章中進行了詳細的解釋。

相關文章：系統開發的估價金額是否可以增加[ja]

在上述文章中，本所解釋了是否存在超出報酬和對價關係的業務範圍的業務是重要的。也就是說，如果供應商應對了初期規格中未包含的開發（在本文中，即否定例的情況）的開發，那麼就可以認可對此提出額外的報酬請求。

總結

在系統開發中，供應商應扮演的角色，在某一方面是根據契約和規格書的內容來決定的。然而，考慮到作為專家，他們是基於高度的信任被委託業務，其實際情況並非完全由形式決定。然而，在理解其內在實質時，本所應該理解法律在其中扮演的重要角色。