Về pháp luật và ví dụ vụ án liên quan đến việc phân biệt giữa việc phái cử và thầu trong ngành công nghiệp IT
Trong các dự án IT, thường thấy nhiều nhân lực từ nhiều công ty được huy động cho một dự án. Trong những trường hợp như vậy, nơi làm việc của kỹ sư tham gia dự án thường không cùng với vị trí của công ty mà kỹ sư đó thuộc về. Điều này tương đương với việc kỹ sư làm việc tại chỗ tại khách hàng hoặc SES. Việc mơ hồ về hình thức lao động và hợp đồng của kỹ sư làm việc tại hiện trường không chỉ có nguy cơ phát triển thành tranh chấp về quyền lợi của người lao động sau này, mà còn có thể trở thành rủi ro gây cháy nổ cho chính dự án. Trong bài viết này, chúng tôi sẽ sắp xếp sự phân biệt giữa việc phân công và việc nhận thầu, thường bị mơ hồ trong thực tế, và giải thích ảnh hưởng mà những vấn đề xung quanh hợp đồng có thể gây ra cho sự tiến triển suôn sẻ của toàn bộ dự án.
Sự khác biệt giữa việc phái cử và nhận thầu
Khi công ty đặt hàng (hoặc nhà thầu phụ của họ) và công ty giao việc khác nhau, thì việc gửi nhân lực đến hiện trường dựa trên hợp đồng nhận thầu thường được thực hiện. Nói cách khác, nhà thầu/nhà cung cấp đứng giữa và gửi kỹ sư đến hiện trường. Về hợp đồng nhận thầu là gì, chúng tôi đã giải thích chi tiết trong bài viết dưới đây.
https://Monolith.law/corporate/system-development-contact-agreement[ja]
Bài viết trên giải thích rằng, việc “hoàn thành công việc” là điều kiện thực hiện nghĩa vụ cốt lõi của hợp đồng nhận thầu. Ngoài ra, việc làm rõ tiêu chí chấp nhận khi ký kết hợp đồng là quan trọng để ngăn chặn sự phát sinh của rắc rối. Khi gửi người đến hiện trường dựa trên hợp đồng nhận thầu, điều này chỉ giới hạn trong giao dịch thương mại giữa các công ty, do đó, không có nghĩa vụ tuân thủ luật lao động đối với bên đặt hàng/nhà thầu nhận người. Tuy nhiên, ngược lại, việc ra lệnh trực tiếp cho kỹ sư đó không được pháp luật công nhận. Nếu không chú ý đến những điểm này, ngay cả khi hợp đồng nhận thầu đã được ký kết trên bề mặt, có nguy cơ bị xem là việc cung cấp lao động bất hợp pháp, tức là “nhận thầu giả”.
https://Monolith.law/corporate/criteria-for-disguised-contract[ja]
Vụ việc tranh chấp phát triển từ việc mơ hồ giữa việc phân công và hợp đồng thầu
Để trao đổi về các khái niệm chung như “Hợp đồng thầu”, “Thầu giả mạo”, chúng tôi sẽ để lại nội dung trên. Dưới đây, chúng tôi sẽ nêu lên một vụ việc mà dự án đã gặp rắc rối do sự mơ hồ trong việc phân biệt giữa việc phân công và hợp đồng thầu. Sự mơ hồ trong việc phân biệt này không chỉ có thể dẫn đến vi phạm quyền của người lao động cá nhân, mâu thuẫn giữa người lao động và người sử dụng lao động, mà còn có thể dẫn đến rủi ro toàn bộ dự án. Điều này có thể được hiểu rõ hơn khi xem xét các điểm dưới đây.
Yêu cầu thực hiện nghĩa vụ thay đổi lớn giữa việc phân công và hợp đồng thầu
Việc phân công và hợp đồng thầu đều giống nhau ở chỗ là doanh nghiệp can thiệp và gửi nhân viên đến nơi phát triển. Tuy nhiên, như đã nói trước đó, nếu là hợp đồng thầu, việc thực hiện nghĩa vụ sẽ không được công nhận cho đến khi “công việc hoàn thành” được chấp nhận. Trong vụ việc được trích dẫn trong phán quyết dưới đây, việc liệu có thể yêu cầu thanh toán tiền công cho dự án đã bị đình trệ đã trở thành vấn đề tranh chấp. Nếu là hợp đồng thầu, “hoàn thành công việc” sẽ được đặt ra như một yêu cầu, trong khi nếu là việc phân công, bạn có thể biện minh cho tiền công lao động chỉ bằng cách làm việc thực tế, như thời gian làm việc.
Bên nhận đơn hàng / nhà cung cấp (nguyên đơn) đã khẳng định rằng hợp đồng phân công đã được ký kết sau sự kiện và rằng nhân viên đã được gửi đi dưới hình thức phân công, và đã khẳng định rằng họ không bị yêu cầu “hoàn thành công việc”. Tuy nhiên, tòa án đã phủ nhận lập luận này (phần được gạch chân, in đậm là những phần mà tác giả đã thêm vào).
Nguyên đơn, sau khi việc không thể phát triển chương trình hệ thống này bởi nguyên đơn đã được xác định, đã khẳng định rằng vào ngày 1 tháng 4 năm Showa 61 (1986), giữa nguyên đơn và bị đơn, về chi phí phát triển, tổng cộng 710.600.000 yên cho hai kỳ và phụ cấp tổ chức trại đã được giảm xuống còn 550.000.000 yên và bị đơn sẽ thanh toán ngay cho nguyên đơn, bị đơn sẽ tiếp quản công việc của nguyên đơn từ ngày 1 tháng 4 năm đó trở đi và về việc phát triển hệ thống thông tin văn bản bởi bị đơn, nguyên đơn sẽ gửi nhân viên theo hình thức phân công lao động để thực hiện, số lượng nhân viên phân công là ba người, và đơn giá là 550.000 yên cho hai người và 300.000 yên cho một người. Tuy nhiên, bị đơn đã phủ nhận việc thỏa thuận như vậy đã được thực hiện, và nguyên đơn, nguyên lai đã nhận thầu việc tạo chương trình hệ thống này từ bị đơn, và đã có nghĩa vụ hoàn thành nó, và người ở vị trí như vậy không hoàn thành việc hoàn thành, và không thể chuyển giao chương trình, bị đơn, người đặt hàng, không có lý do gì để miễn nghĩa vụ tạo ra sau này cho nguyên đơn, hoặc để thanh toán cho nguyên đơn cho các chi phí mà nguyên đơn đã phát sinh trong thời gian đó. Chắc chắn, nếu nguyên đơn có nghĩa vụ hoàn thành chương trình, thì điều mà bị đơn đề nghị cũng là hợp lý.
Phán quyết của Tòa án Tokyo ngày 22 tháng 2 năm Heisei 23 (2011)
Vì vậy, trước hết, về việc nguyên đơn có nghĩa vụ hoàn thành trong hợp đồng phát triển chương trình hệ thống này hay không, chúng tôi sẽ xem xét.
(Trích dẫn) Khi xem xét các bằng chứng, không thể tìm thấy bằng chứng nào có thể công nhận rằng nguyên đơn không có nghĩa vụ hoàn thành chương trình trong hợp đồng này. (Trích dẫn) Và, ngay cả trong kết quả thẩm vấn đại diện nguyên đơn, hợp đồng này là một hợp đồng nhận thầu toàn bộ, và chúng tôi sẽ phát triển chương trình trong công ty, và nguyên đơn đã giả định rằng chúng tôi có nghĩa vụ hoàn thành chương trình này và đã khai thác, và chúng tôi đã không từ chối việc chúng tôi có nghĩa vụ này một lần nào. Điều này rõ ràng. Khi xem xét các tài liệu, không có tranh chấp về việc thành lập (trích dẫn) bảng tiến độ, nguyên đơn, giả định rằng chúng tôi có nghĩa vụ hoàn thành chương trình này, và ghi chú lịch trình cho đến khi hoàn thành. Vì vậy, theo điều này, ngược lại, chúng tôi có thể công nhận rằng nguyên đơn đã có nghĩa vụ hoàn thành chương trình theo hợp đồng. (Trích dẫn)
Ngoài ra, không có bằng chứng nào phản đối việc công nhận rằng nguyên đơn có nghĩa vụ hoàn thành chương trình này.
Nếu vậy, như bị đơn đã khẳng định, người không thực hiện việc tạo chương trình mà họ có nghĩa vụ hoàn thành sẽ chịu trách nhiệm vì không thực hiện nghĩa vụ, và họ không thể yêu cầu thanh toán tiền thầu, điều này là hiển nhiên, và trừ khi có hoàn cảnh đặc biệt, người đặt hàng sẽ không thỏa thuận với người ở vị trí như vậy để miễn điều kiện nghĩa vụ hợp đồng của họ, và thêm vào đó, họ sẽ trả cho họ các chi phí mà họ đã phát sinh cho đến nay. Đại diện nguyên đơn, trong kết quả thẩm vấn của mình, khẳng định rằng ngay cả khi chương trình không hoàn thành, nếu tôi làm việc theo hướng dẫn của người đặt hàng, tôi đã thực hiện công việc trong phạm vi được chỉ định trong thời hạn, vì vậy tôi có thể yêu cầu tiền phần mềm máy tính cho phần công việc mà tôi đã làm, nhưng đây là lời nói trái với quan niệm thông thường về hợp đồng thầu, và trong ngành công nghiệp của nguyên đơn và bị đơn, người phát triển phần mềm, không thể công nhận sự thật rằng có một thói quen thanh toán tiền công ngay cả khi công việc không hoàn thành trong hợp đồng thầu, mà quan niệm thông thường khác nhau, dựa trên lời khai của nhân chứng, kết quả thẩm vấn đại diện nguyên đơn chỉ là quan điểm riêng của họ và không thể được chấp nhận.
Điều có thể rút ra từ ví dụ phán quyết trên
Điểm đáng chú ý đặc biệt trong ví dụ phán quyết trên là,
- Không miễn trừ nghĩa vụ “hoàn thành công việc” của nhà cung cấp dựa trên việc ký kết hợp đồng phân công hình thức / bề mặt, mà dựa trên nội dung cam kết cụ thể giữa hai bên là “hoàn thành công việc”, mong đợi một giải pháp tranh chấp công bằng và thực tế
- Điểm được xem xét là hợp đồng thầu từ việc đặt “hoàn thành công việc” làm yêu cầu thực hiện nghĩa vụ, và các vấn đề khác cũng nên được xem xét dựa trên thói quen thương mại trong ngành liên quan đến hợp đồng thầu
Điều này có thể được coi là điểm.
Nếu tổng kết hai điểm trên một cách đơn giản, nó cho thấy rằng trong việc giải quyết tranh chấp, sự đồng lòng về ý định thực tế giữa hai bên được coi trọng hơn tiêu đề hợp đồng hình thức / bề mặt. Ngoài ra, một khi bản chất của hợp đồng được xem là hợp đồng thầu, các vấn đề khác cũng được giải quyết dựa trên thói quen thương mại trong ngành liên quan đến hợp đồng thầu. Khi từ chối lập luận của bên nhận đơn hàng / nhà cung cấp, việc sử dụng các cụm từ như “lời nói trái với quan niệm thông thường về hợp đồng thầu”, “quan điểm riêng” là rất đặc trưng, cho thấy rằng các quan niệm xã hội và quan niệm xã hội được phản ánh trong việc giải thích pháp luật và ảnh hưởng đến thực hành pháp lý. Điều này cũng là một điểm đáng chú ý. By the way, về khái niệm “hoàn thành công việc” mà đã được coi trọng đến mức này trong phán quyết này, chúng tôi đã giải thích chi tiết trong bài viết dưới đây dựa trên ngữ cảnh phát triển hệ thống.
https://Monolith.law/corporate/completion-of-work-in-system-development[ja]
Trong thực tế của dự án phát triển hệ thống, hợp đồng thầu thường được sử dụng, và yếu tố cốt lõi của nó là “hoàn thành công việc”, vì vậy bạn nên hiểu sâu sắc về điều này.
Hiểu biết về nghĩa vụ quản lý dự án cũng được yêu cầu làm tiền đề
Ngoài ra, phán quyết này cũng liên quan sâu đến “nghĩa vụ quản lý dự án” mà các chuyên gia phát triển hệ thống, hay còn gọi là nhà cung cấp, phải gánh vác. Chúng tôi đã giải thích về nghĩa vụ này một cách tổng quát trong bài viết dưới đây.
https://Monolith.law/corporate/project-management-duties[ja]
Xét về nội dung của bài viết trên, ta có thể thấy rằng trách nhiệm của nhà cung cấp, người nhận công việc với tư cách là chuyên gia trong dự án phát triển hệ thống, không hề nhẹ nhàng. Đúng là, không thể phủ nhận rằng có không ít tình huống cần sự hợp tác từ phía người dùng để dự án diễn ra suôn sẻ. Tuy nhiên, việc không thực hiện những nỗ lực như kêu gọi sự hợp tác cần thiết từ người dùng và nghĩa vụ này được miễn trừ là điều khó có thể tưởng tượng. Việc đổ lỗi cho người dùng khi dự án thất bại cũng rất khó từ góc độ này. Sự hợp lý của phán quyết trên có thể dễ dàng cảm nhận hơn nếu nó dựa trên sự hiểu biết về quản lý dự án. Thậm chí, có thể có một số khía cạnh mà cấu trúc lý thuyết của việc chọn thầu thay vì phái cử để phù hợp với kết luận hợp lý được đưa ra từ góc độ này đã được chấp nhận dễ dàng hơn.
Tóm tắt
Chúng tôi đã giải thích về các vụ tranh chấp dự án có thể xảy ra khi việc phân biệt giữa việc phái cử và thầu không rõ ràng. Trong các vụ việc, hơn là tiêu đề hợp đồng hình thức, những điều đã được hứa cụ thể với nhau và thực chất như thói quen kinh doanh trong ngành được coi trọng hơn. Thêm vào đó, không chỉ là cuộc thảo luận pháp lý về loại hợp đồng cụ thể đã được ký kết là phái cử hay thầu, mà cả những kiến thức về “nghĩa vụ quản lý dự án” – một nền tảng chung cho tất cả những điều này cũng rất quan trọng. Trong các dự án IT, không chỉ giới hạn ở việc phái cử và thầu, việc sử dụng nhân lực thông qua các phương pháp như điều động hoặc ủy quyền cũng thường xuyên được thấy. Chúng tôi đã giải thích chi tiết về sự phân biệt và khác biệt toàn diện, bao gồm cả những điều này, trong bài viết dưới đây.
https://Monolith.law/corporate/difference-contract-dispatch-loan-labor-supply[ja]
Không chỉ giới hạn ở sự khác biệt giữa việc phái cử và thầu, có thể tưởng tượng ra nhiều biến thể của các tranh chấp bắt nguồn từ sự mơ hồ của loại hợp đồng. Tuy nhiên, ngay cả khi phải đối mặt với một vụ việc chưa biết, điều quan trọng nhất vẫn là kiến thức về các vấn đề cơ bản như “nghĩa vụ quản lý dự án”, không phải sao?
Category: IT
Tag: ITSystem Development
