在系統開發項目中,經營目標與數值目標的法律意義是什麼

系統開發項目往往與企業或工作場所的大規模業務改進密切相關。在這裡，可能需要對用戶端企業的經營問題的解決或數值目標的達成等做出貢獻。然而，是否真的有法律義務去承諾這些經營目標呢？數值目標和經營目標的法律含義是什麼，這成為了一個問題。本文將解釋與系統開發相關的各種「目的」和「目標」所帶來的法律問題。

為何系統開發的目的和目標會成為爭議的導火線

因為它位於用戶的合作義務和供應商的裁量之間的問題

從商業交易的角度來看，系統開發項目有幾個特點。一個是，供應商的系統開發項目本身並非由供應商單獨完成，而需要用戶的合作。這種義務的存在在判例法上被明確地稱為「合作義務」。主要在以下幾個階段，用戶也需要協助系統開發：①需求定義②基本設計③成果物的驗收等。

https://monolith-law.jp/corporate/user-obligatory-cooporation[ja]

另一個特點是，供應商通常需要發揮大量的裁量權來進行業務。供應商在整個系統開發項目中應該做的事情被總結為法律術語「項目管理義務」。關於這一點，本所在以下的文章中進行了詳細的解釋。

https://monolith-law.jp/corporate/project-management-duties[ja]

總結以上內容，本所可以指出兩個重要的點：

• 用戶需要提供適當的信息給供應商，並協助供應商的開發工作。
• 供應商需要理解用戶的項目目的和目標，並進行符合這些目的和目標的工作。

由於以上兩點的情況，用戶事先提供的說明中，達成經營目標或數值目標在法律上到底應該成為供應商的義務到何種程度，也成為了問題。也就是說，用戶有義務將供應商應做的事情（不是模糊的目標等，而是具體的規格）整理出來並提供給供應商，而供應商作為專家，也有義務提供用戶真正需要的東西，而不僅僅是按照對方的要求去做。這種相互矛盾的要求之間的衝突，就是圍繞系統開發的「目標」和「目的」的爭議的特點。從法律的角度來看，提供公平解決爭議的指導原則是實務上的問題。

用戶的目標對項目產生影響的具體情況

系統開發項目往往與企業或工作場所的大規模業務改進和效率提升措施相關，因此在項目的規劃和提議階段，往往會進行關於經營問題和經營目標的聽證會。在這裡，可能會進行關於系統開發的成本效益的討論，以及通過各種數值目標的討論。

• 由於省力化而減少的人力成本
• 銷售或收益的增加
• 業務時間的縮短

例如，如果上述項目成為項目的最終目標，供應商可能會在項目前期以顧問的身份解釋系統開發的投資效益，並進行銷售等工作。

用戶端提出的經營目標成為問題的判例是什麼？

然而，供應商通常只是系統開發的專家。如果所有的責任都落在用戶端的經營目標上，那麼這可能會變得過於苛刻。

業務速度提升被設定為目標的案例

關於這個問題，以下引述的判決書中的案例，項目啟動時創建的企劃書中記載了啟動系統開發項目的目的和目標。然而，當系統實際完成並開始運營時，無法達成這些目的和目標，爭議隨之升級。最初的企劃書中記載了，系統完成並實際開始使用後，應該實現以下狀態：

• 將人工輸入的時間減少50%
• 使用該IT系統進行辦公處理，能在規定的時間內完成

用戶端因為無法實現這些結果，試圖追究供應商的債務不履行責任和瑕疵擔保責任。然而，法院並未接受這種主張（下劃線、粗體部分是作者添加的）。

然後，（中略）從辯論的全體意義來看，①本案的目的是「提高業務效率」、「建立CRM基礎」、「進行『可視化管理』」等抽象的事物，目標值也是「增加與客戶的接觸點」、「將辦公職員的勞力分配到內部控制和銷售支援」、「能更準確地預測銷售」、「抑制過度的銷售折扣」等，抽象的事物較多，「將輸入時間減少50%」、「將估價創建時間減少50%」、「法定披露能在法定日期內完成」等目標值，是在SBO導入後被告的經營管理和業務方式的存在，並且是支援軟體導入的系統開發公司，即原告，不能承擔其達成的性質，②本案項目開始後的會議記錄中，並未具體討論達成本案目的和目標值的記載，③本案項目計劃書中，「成為上市公司」等，使用的表達方式本身並不具有契約的性質，（中略）考慮到這些情況，原告基於被告的說明，在本案項目計劃書中創建了本案目的的描述，是為了確保本案項目不失敗，為了獲得對本案項目的目的和成果的共同認識，被告對原告，不能認為是委託了達成本案目的的系統開發。（中略）因此，不能認為原告承擔了被告為達成本案目的的系統開發，（中略）債務不履行責任和瑕疵擔保責任的主張都沒有理由。

東京地判平成22年12月28日（2010年）

從判例中可以讀出的經營目標和數值目標的法律意義是什麼？

如本判決所述，系統開發的目的和是否能達成數值化的目標，通常會受到許多因素的影響，如使用該系統的用戶端的經營努力等。因此，應該認為將這些責任歸咎於供應商的門檻非常高。首先，如果供應商的債務不履行責任和瑕疵擔保責任被認定，那麼這意味著「目的」和「目標」的達成被納入了契約內容的一部分。然而，在本案中，「目的」和「目標」：

• 對於抽象和模糊的事物，由於其不符合法律義務的性質，將其視為契約內容的一部分是不合理的
• 對於需要用戶端，特別是經營方面的自助努力的事物，由於供應商無法控制，將其歸咎於供應商是不適當的，將其視為契約義務的一部分是不合理的

因此，從法律角度來看，這些評價是合理的。

從本判決中可以進一步讀出的內容

本判決中還包含了一些其他的有趣內容。

• 法院也考慮到，共享系統開發項目的「目的」和「目標」可能只是用戶和供應商獲得「共同認識」的溝通努力的一部分。
• 在考慮這些項目中，這些「目的」和「目標」是多麼的本質要素時，也參考了會議記錄等。

另外，關於與系統開發項目相關的法律問題，從文件管理和會議記錄的重要性的角度，本所在以下的文章中進行了解釋。

https://monolith-law.jp/corporate/the-minutes-in-system-development[ja]

關於經營目標與數值目標的法律問題注意事項

然而，關於這些「目的」和「目標」的法律問題，本所也應該注意以下的補充事項。

諮詢服務是有償還是無償，情況會有所不同

如果不僅是系統開發項目，而且還有有償的諮詢合約，那麼情況可能會有很大的變化。如果用戶方在不考慮其經營資源的情況下，制定了實現可能性較低的執行計劃，那麼在該有償諮詢合約部分可能會被追究債務不履行責任。

成果物的瑕疵，以及功能和規格要求的不一致，是另一個問題

另外，如果一連串的「開發」項目本身存在瑕疵，即成果物中確認到問題或錯誤，則需要將這些問題與其他問題區分開來理解。在這種情況下，無需談論經營上的「目的」和「目標」，主要是成果物與所需功能要求和規格的一致性問題。例如，如果系統在事後發現瑕疵，用戶方的應對策略在以下文章中有詳細解釋。

https://monolith-law.jp/corporate/system-flaw-measure-after-acceptance[ja]

其他相關話題包括，雖然沒有包含在要求中，但認為供應商有義務進行實施的事項。這方面的詳細解釋在以下的文章中。

https://monolith-law.jp/corporate/system-development-specs-function[ja]

無論哪種情況，都應將其理解為與「目的」和「目標」相關的爭議是相似但不同的問題。

對於責任和合約等主題的基本理解也受到質疑

以上，本所對於系統開發的「目的」和「目標」相關的法律問題進行了解釋。在這些問題的爭議中，法院也認為，用戶和供應商之間的努力應該是為了保持一致，並且通常會作為溝通努力的一部分來共享。然而，即使結論的合理性可以充分理解，但在達到這一點的過程中，對於「責任」和「合約」等事物的基本理解也受到質疑。對於這些問題，本所在以下的文章中進行了解釋。

https://monolith-law.jp/corporate/responsibility-system-development[ja]

考慮到法律責任與模糊的道義責任不同，以及雙方當事人確定的「意願一致」會產生合約責任等因素，本所認為獲得更本質的理解是非常重要的。