系統開發的估價金額能否事後追加

系統開發這項工作，無論是發訂單的用戶端，還是接受訂單的供應商端，都需要大量的人力參與，因此，要讓所有人步調一致地推進項目並不容易。有計畫地進行這項業務極其重要，這點毋庸置疑。但同時，雖說若是發訂單的用戶是否能將適當的信息整理好，並清楚地傳達給供應商可以加快系統開發的進行，然而實際情形往往並非如此。當開發過程進行到一定階段，如果被要求更改規格或增加功能，是否可以在預先估計的金額上加價，對於接受工作的一方來說，這是非常重要的問題。

那麼，這種權利在法律上在什麼情況下會被承認呢？又或者，這種額外開發和功能修正的報酬金額應如何決定呢？本文將對這些疑問進行整理。

何時可以稱為追加開發或功能修正呢？

在系統開發的項目中，接受工作的合約類型通常是承包合約或準委託合約。無論哪種合約類型，接受工作方應該做的事情（即義務）和相應的報酬（即權利）都會一對一地在合約中表示。因此，如果後來添加了不包含在報酬金額假設的業務，那麼可以說是追加開發或功能修正。相反，如果包含在內，則會被視為按照最初的規格（即原有合約範圍內的事物）來處理。

關於承包合約和準委託合約的區別等，本所在另一篇文章中詳細解釋。

然而，如果說所有的事情，如在螢幕上顯示的字體的微調整等，都必須事先在規格中定義，否則它們都將被視為追加開發，那麼這可能會嚴重阻礙順利的商業交易。因此，如果考慮到這些規格詳細的討論，實際上並不容易劃定一致的界線。但是，如果要給出一般的指導原則，那麼：

• 規格一旦確定，就被命令添加更多的功能
• 程序的實現已經完成，然後被命令修改

在這種情況下，這種主張在法律上有一定的合理性的可能性很高。

是否屬於追加開發或功能修正成為爭點的判例

肯定例：事後變更基本設計規格的案例

以下的案例是事後變更規格的情況。

軟體開發是經過①需求定義、②外部設計、③內部設計、④源程式的創建（程式設計、編碼）、⑤各種測試（單元測試、組合測試、系統測試）的開發過程進行的（中略）初始規格（中略）是通過內部設計以後的工作實現的，這是基於本案開發委託合約的報酬請求權和對價關係的業務範圍。規格變更的申請在法律上被解釋為委託人超出初始合約業務範圍的新的業務委託合約的申請，如果受託人未提出追加工程費用，並在未達成追加費用協議的情況下完成了追加委託的業務，則應理解為在委託人和受託人之已間成立了一費用未定的新的承攬合約，並產生相當的追加開發費支付義務。

大阪地方裁判所2002年（平成14年）8月29日判決

理解這個判決的關鍵是掌握「對價關係」、「新的合約」等關鍵詞。

另外，上述判決還提出了一個非常有趣的觀點。那就是，按鈕的配置或字體等非常細節的部分的微調並不屬於所謂的規格變更。相關部分如下：

然而，在軟體開發中，由於其性質，外部設計階段並不會決定到顯示在螢幕上的字體或按鈕的配置等細節，對於細節，即使在規格確定後，也通常會根據當事人間的討論進行一定程度的修正，考慮到這一點，將這種規格的細節化要求也視為規格變更是不合適的。

大阪地方裁判所2002年（平成14年）8月29日判決

判決文中使用了一個有趣的詞語「規格的細節化」。

• 後來覆蓋了原本已經確定的事情的情況
• 在進行的過程中可以決定的事情，卻故意不決定並繼續進行的情況

在法律上的處理也應該有所不同，這也可以說是表明了這種觀點。

其他肯定例

此外，被認定為追加開發或功能修正的案例還包括：

• 交付的程式數量比原計劃增加了約一倍的案例（東京地方裁判所2005年（平成17年）4月22日判決）
• 工作期間延長了約三倍的案例（東京地方裁判所2010年（平成22年）1月22日判決）

如此整理，可以看出，工作期間的延長也被視為廣義的追加開發，並採取了一種應該給予一定的法律保護的觀點。

「關於追加開發的協議或報酬增加」和「初始合約的成立」是兩個不同的問題

關於這些問題的重要點是：

1. 「首先，兩家公司之間是否正式成立了關於系統開發的合約（初始合約）」？
2. 「一旦正式成立了關於系統開發的合約，是否又追加成立了關於追加開發的合約」？

在這兩種情況下，法院的判斷標準是不同的。簡單地說，法院：

• 對於1的情況，傾向於嚴格（在沒有合約書的情況下，不容易承認合約的成立）
• 對於2的情況，傾向於相對寬鬆（即使沒有關於追加開發的合約書，也會靈活地承認報酬增加等）

否定例：在法律上被視為包含在相同委託內容中的案例

然而，另一方面，也有報酬增加請求未獲承認的判例。在以下引用的判決文的案例中，關於系統開發的合約，一旦業務委託合約締結後，業務內容變更，因此爭議是否應認可報酬增加。

本案的爭點是，（1）在本案合約中，原告受託的業務內容是什麼，（2）對於右受託業務，原告和被告之間是否達成了擴大規模並增加代價的協議，（中略），這是問題的點。（中略）

首先，本案合約是一種承攬合約，該合約以其代價為原告的受託業務（承攬）的確定對價，受託業務涉及的步驟數、單價等只是原告在計算承攬代價時的內部資料，步驟數的增加等情況與承攬代價無關。（中略）

根據前述認定，原告的受託業務在1987年（昭和62年）2月25日被變更，只限於系統管理、承攬工程費積算和部分工具，其餘由被告負責，右變更後的原告的業務仍在初始合約的開發業務範圍內，對於右業務的對價，本案合約初期作為確定代價約定的委託代價已全部涵蓋。

東京地方裁判所1995年（平成7年）6月12日判決

在該判決中，即使變更了承包商受託的業務內容，但該開發內容仍在初始合約內容的範圍內，並且應在初始承諾的報酬中覆蓋，這是法院的判斷。

結論是，考慮到報酬金額是基於執行哪些業務來決定的，對於不包含在其中的業務，應認可追加報酬請求，這是一種立場。

而報酬金額是對執行哪些業務的對價，並不僅僅是合約書，議事錄等也將作為證據進行判斷。

追加開發與功能修正的報酬金額如何決定

在系統開發的現場，一旦確定的規格後來發生變化的情況並不罕見。每當這種情況發生時，準備新的書面契約並進行契約事務並不現實。對於需要追加和修正的事項，再次確定其規格內容，並總結簽訂備忘錄等，除非在這種情況下，否則如果在無法進行這種程序的情況下，項目突然中止，應如何計算報酬金額呢？

在這種情況下，應參考的條款是以下引述的《日本商法》第512條（下劃線部分是作者劃的）。

《日本商法》第512條：商人在其業務範圍內為他人行事時，可以請求合理的報酬。

在這條款中，“合理的報酬”在具體情況下，最終會是多少，這是問題所在。從過去的判例來看，似乎採用了根據工作的工時、分量或期間來承擔成本的觀點。這可能是因為系統開發業務本質上是一種服務業，其原價基本上是人工成本。

因此，儘管《日本商法》中的“合理報酬”這一詞語的抽象程度相對較高，但在這種情況下，估算追加報酬金額的市場價格並不需要進行太複雜的計算。以下，讓我們來看幾個判例。

案例1：認可了與工時增加成比例的追加報酬的實例

本案的規格變更基於開發工時，合計為257.5人/天，這是合理的，如果將其轉換為每人/天的開發費用與本案的開發委託契約相同，即32,500日元（在甲方3中，單價為650,000日元[每人/月]，如果一個月的工作日數為20天，則每人/天的開發費用為32,500日元。），則基於本案的規格變更要求的追加開發費用，應為8,368,750日元。

大阪地方法院2002年（平成14年）8月29日判決

“每人/天”是關鍵詞，用以表明追加報酬的計算依據。

案例2：認可了與程序數量成比例的追加報酬的實例

考慮到本案中包含追加部分的合理報酬金額，計算機系統開發的原價的大部分是技術人員的人工費，這些人工費大致與要創建的程序的數量成比例，因此，將最初的契約金額2325萬日元除以完成的206個程序的數量，將這個每個程序的單價乘以經過三次檢驗的程序數量414，得出的金額為4672萬5728日元（23250000÷206×414＝46725728），這被認為是合理的。

東京地方法院2005年（平成17年）4月22日判決

雖然出現了很多數字，但如果你冷靜地閱讀，你會發現並沒有進行很難的計算。在確認“每個程序的單價是多少”的基礎上，他們只是進行了簡單的“單價×數量”的乘法運算。

案例3：認可了與期間長度成比例的追加報酬的實例

然後，在甲方3契約中，原告在2005年（平成17年）1月至3月的3個月期間作為準委任的工作的對價，定為6000萬日元，而在同年4月以後的工作中，包含了無償工作，另一方面，與前一年相同，由於新學期的開始，註冊等系統的運行，從同年4月以後的工作量增加是可以預見的。從這些事實來看，以上述3個月的工作對價為基礎，原告在2005年（平成17年）4月至9月的6個月的工作報酬應為1億2000萬日元，這是合理的。

東京地方法院2010年（平成22年）1月22日判決

上述判決表明，對於延長的期間，也是通過簡單的比例計算來計算追加報酬。

總結

如上所述，本所列舉了一些判例，從中可以看出，對於程序員和工程師的額外報酬的法律處理，似乎有一定的法則性和共性。也就是說，原則上，本所應該根據相對客觀的指標，如投入的工時、（交付的程序等的）形式工作量、工作時間或期間等，儘可能簡單地進行計算。

從嚴格意義上的程序化或未能完美預估工時，因此產生了這種額外開發或功能修正的情況來看，只要投入了人力，或者完成了形式工作的量，或者投入了時間，就會產生額外的報酬，這可能會讓人覺得這是一個沒有任何新意的話題。然而，如果從承包方的角度來看，即使在優先考慮客戶利益的前提下進行業務，這種權利在法律上被認可的可能性，也是一種危機管理的重要話題，不是嗎？