關於IT業界的派遣與承包區別相關的法律與審判案例

在IT領域的專案中，本所常常看到許多公司的人才被動員參與同一個專案。在這種情況下，參與專案的技術人員的工作地點往往與他們所屬公司的所在地分離。這就是所謂的客戶端常駐或SES等情況。技術人員在現場工作的雇用形態和合約形態變得模糊，不僅可能導致後續的勞工權益爭議，也可能成為專案本身的風險。本文將整理在實務上容易混淆的派遣和承包的區別，並解釋這些合約問題可能對專案整體的順利進行產生何種影響。

派遣與承包的區別

當接受工作的供應商（或其再委託的業者）與發出業務的委託公司不同時，通常會根據承包合約將人員派遣到現場。也就是說，接受訂單的一方/供應商會介入並派遣技術人員到現場。

“工作的完成”是承包合約的本質特徵，也就是債務履行的條件。此外，在簽訂合約時明確檢驗的合格條件是防止問題發生的重要因素。需要注意的是，如果根據承包合約在現場常駐人員，那麼這只是企業與企業之間的商業交易，接受技術人員的訂單者/現場方並無需遵守勞動法等義務。然而，反過來說，他們也無法直接對該技術人員下達指令。如果不考慮這些因素，即使表面上簽訂了承包合約，也可能面臨被視為非法勞動供應業務，即“偽裝承包”的風險。

由於派遣與承包之間的區別變得模糊，導致爭議升級的案例

關於「承包合約」、「偽裝承包」等一般性問題，本所將在上述內容中討論，以下本所將討論的是由於派遣與承包之間的區別變得模糊而引發的項目失敗案例。這種區別變得模糊的情況不僅可能導致個人勞工權利的侵犯、勞資爭議等問題，也可能導致整個項目的失敗風險，這一點在以下的確認中應該可以清楚看出。

派遣與承包在債務履行要求上有很大的差異

派遣與承包在企業介入開發現場並派遣人員的方式上非常相似。但如前所述，如果是承包，除非「工作完成」被認可，否則原則上不會認可債務的履行。在以下引用的判決文的案例中，最終項目失敗，是否可以要求報酬成為了爭議點。如果是承包，「工作完成」將作為要求，而如果是派遣，則可以僅根據實際工作時間等實績來合理化勞動報酬。

接受訂單方/供應商（原告）主張，派遣合約是在事後簽訂的，人員是以派遣的形式被派遣的，並主張「工作完成」並未作為義務。然而，法院否定了這一主張（下劃線部分、粗體部分是筆者添加的）。

原告主張，在原告確定無法開發本案系統的程序後，於昭和六一年（1986年）四月一日原告與被告之間，就開發費用達成了以下協議：將兩期分及合宿實施手續費總計七一〇萬六〇〇〇日元減為五五〇萬日元，被告將立即支付給原告；同年四月一日以後，被告將接手原告的業務；關於文字信息系統的開發，將由原告以勞務派遣的形式派遣人員實施，派遣人員為三人，其中兩人的單價為五五萬日元，一人的單價為三〇萬日元。原告代表者的審問結果與此相符。
然而，被告否認有這樣的協議，原告原本是被被告委託製作本案系統的程序，並負有完成此項工作的義務，處於這種地位的人未能完成工作，也無法交付程序，被告作為訂單者，不可能免除原告以後的製作義務，或支付原告在此期間所需的費用，這是不合理的，被告主張。確實，如果原告負有完成程序的義務，被告的主張也是合理的。
因此，首先，本所將檢討在本案系統的程序開發合約中，原告是否沒有負擔完成義務。
（中略）根據證據，本所無法找到證據證明原告在該合約中沒有負擔完成本案程序的義務。（中略）而且，原告代表者在審問結果中也表示，該合約是一次性接單，在原告公司內部開發程序，並以原告負有完成該程序的義務為前提進行供述，並未否認過他負有該義務。從書面證據來看，無爭議的成立（中略）工程表是以原告負有完成該程序的義務為前提，記載了完成該程序的時間表的目的，因此，根據這一點，本所可以認定原告在合約上負有完成程序的義務。（中略）
除此之外，沒有與原告負有完成該程序義務的認定相反的證據。
如果是這樣，如被告所主張，未能完成負有完成義務的程序製作的人，即使需要承擔不履行債務的責任，也不能要求支付承包費用，這是理所當然的，除非有特殊情況，否則訂單者不可能無條件免除該人的合約義務，甚至支付其至今為止所需的費用。原告代表者在審問結果中表示，即使程序未完成，只要按照訂單者的指示進行工作，就能在期限內完成指定範圍內的工作，因此，對於已完成的工作部分，可以要求支付電腦軟件費用。然而，這是一種違反承包合約一般常識的言論，在原告和被告所在的軟件開發行業中，與一般常識不同，即使在承包合約中，即使工作未完成，也有支付報酬的習慣，這種事實無法從證人的證詞中認定，因此，原告代表者的審問結果只能認為是其獨特的觀點，不能採納。

東京地判平成23年（2011年） 2月22日

從上述判例中可以得出的結論

在上述的判例中，特別值得注意的是：

1. 並非以表面的、形式的派遣合約的簽訂為依據來免除供應商的「工作完成」義務，而是基於雙方當事人具體的約定內容「工作完成」，期待實質上公平的爭議解決
2. 由於「工作完成」被視為債務履行的要求，因此該合約被判定為承包合約，並且在其他論點上也應根據承包合約相關的行業內商業習慣進行判斷

本所認為，這些點是值得注意的。

簡單地總結這兩點，超過表面的合約書的標題等，法院更重視雙方當事人的實質意願的一致。此外，一旦合約的實質被判定為承包合約，則在其他論點上也應該根據與承包合約相關的行業內商業習慣來尋求解決。在駁回接受訂單方/供應商的主張時，出現了「違反承包合約一般常識的言論」、「獨特的觀點」等語句，這也可以看出這一點，非常特別。社會常識、社會通念等也反映在法律解釋中，對法律實務產生影響，這也是值得注意的一點。

考慮到在系統開發項目的實務中，承包合約常常被使用，並且其本質的要素在於「工作完成」，本所應該深入理解這一點。

對於項目管理義務的理解也是前提

此外，本判決與系統開發專家即供應商方所負的「項目管理義務」深度相關。

作為系統開發項目專家的供應商承擔的責任並不輕。確實，為了項目的順利進行，用戶方的合作在許多情況下是必要的。然而，通常難以想像在不做出如適時呼籲用戶提供必要合作等努力的情況下，該義務可以被免除。將項目失敗的責任歸咎於用戶方，從這種觀點來看，門檻非常高。上述判決的合理性，如果基於對項目管理的理解，可能會更容易感受到。反而，從這種觀點出發得出的合理結論，為了達到一致，可能在一定程度上採用了將交易實態視為承包而非派遣的理論結構。

總結: 關于IT系統的請負契約需要基礎法律理解

以上，本所對於派遣與承包區別模糊時可能引發的項目爭議案例進行了解釋。從案例中本所可以看出，比起契約書的形式標題，更重視的是彼此間交換的具體承諾事項以及行業內的商業習慣等實質內容。此外，不僅僅是對於個別簽訂的契約類型是否為派遣或承包等細節的法律討論，對於貫穿其中的基礎「項目管理義務」的理解也顯得非常重要。在IT項目中，不僅僅是派遣或承包，例如出差或準委任等方式的人力資源利用也很常見。

不僅僅是派遣與承包的區別，由於契約類型的模糊性引發的爭議變化多端。然而，即使要處理的案件是未知的，本所仍然認為最重要的是對於「項目管理義務」等基礎事項的理解。