Sobre a legislação e casos judiciais relacionados à distinção entre trabalho temporário e subcontratação na indústria de TI

Em projetos de TI, é comum ver muitos profissionais de várias empresas a serem mobilizados para um único projeto. Nesses casos, o local de trabalho do técnico envolvido no projeto muitas vezes é separado da localização da empresa à qual pertence. Isto é o que acontece, por exemplo, em situações de residência permanente no cliente ou SES. A ambiguidade na forma de emprego ou contrato do técnico que trabalha no local pode não só levar a riscos de conflitos futuros sobre os direitos dos trabalhadores, mas também pode representar um risco de falha do próprio projeto. Neste artigo, vamos esclarecer a distinção, que muitas vezes se torna ambígua na prática, entre subcontratação e contratação, e explicar como esses problemas contratuais podem afetar o progresso suave de todo o projeto.

A diferença entre subcontratação e contratação

Quando o fornecedor que recebe o trabalho (ou o subcontratado) e a empresa que encomenda o trabalho são diferentes, é comum que os recursos humanos sejam enviados para o local com base num contrato de subcontratação. Ou seja, o fornecedor/recebedor do pedido intervém e envia técnicos para o local. Quanto ao que é um contrato de subcontratação, explicamos em detalhe no seguinte artigo.

No artigo acima, explicamos que o ponto essencial de um contrato de subcontratação é que a “conclusão do trabalho” se torna a condição para o cumprimento da obrigação. Também explicamos que é importante esclarecer as condições de aprovação na altura da celebração do contrato para prevenir problemas. No caso de manter pessoas no local com base num contrato de subcontratação, isso permanece como uma transação comercial entre empresas, por isso não há obrigação para o encomendador/receptor no local de cumprir a lei laboral. No entanto, em contrapartida, não é legalmente permitido dar ordens diretas ao referido técnico. Se não tiver em conta estes pontos, mesmo que à primeira vista tenha sido celebrado um contrato de subcontratação, corre o risco de ser tratado como um negócio de fornecimento ilegal de trabalhadores, ou seja, uma “subcontratação disfarçada”.

Casos de conflito resultantes da ambiguidade entre contratos de trabalho temporário e contratos de empreitada

Deixando de lado a discussão geral sobre “contratos de empreitada” e “empreitada disfarçada”, o que vamos abordar a seguir é um caso de conflito que surgiu devido à ambiguidade entre contratos de trabalho temporário e contratos de empreitada. Esta ambiguidade pode não só levar a violações dos direitos dos trabalhadores individuais e a conflitos entre empregados e empregadores, mas também pode representar um risco para todo o projeto, como se pode ver a seguir.

Os requisitos para o cumprimento das obrigações mudam significativamente entre contratos de trabalho temporário e contratos de empreitada

Os contratos de trabalho temporário e os contratos de empreitada são semelhantes no sentido de que uma empresa intervém e envia pessoal para o local de desenvolvimento. No entanto, como mencionado anteriormente, num contrato de empreitada, o cumprimento das obrigações não é reconhecido a menos que a “conclusão do trabalho” seja confirmada. No caso que citamos abaixo, a questão era se o pagamento poderia ser reivindicado num projeto que acabou por falhar. Num contrato de empreitada, a “conclusão do trabalho” é um requisito, enquanto num contrato de trabalho temporário, é possível justificar a remuneração com base apenas no tempo de trabalho real.

O lado do pedido/o fornecedor (o demandante) argumentou que o contrato de trabalho temporário foi concluído posteriormente e que o pessoal foi enviado sob a forma de trabalho temporário, e argumentou que não era obrigado a “concluir o trabalho”. No entanto, o tribunal negou este argumento (as partes sublinhadas e em negrito foram adicionadas pelo autor).

O demandante, após a confirmação de que o desenvolvimento do programa do sistema em questão pelo demandante era impossível, alegou que, a partir de 1 de abril do ano 61 de Showa (1986), entre o demandante e o réu, foi acordado que o réu pagaria rapidamente ao demandante o custo de desenvolvimento, reduzido de 710.600.000 ienes para 550.000.000 ienes, que o réu assumiria o trabalho do demandante a partir de 1 de abril do mesmo ano, e que, em relação ao desenvolvimento do sistema de informação por caracteres pelo réu, o demandante enviaria pessoal sob a forma de trabalho temporário e o número de trabalhadores temporários seria de três, com um preço unitário de 550.000 ienes para dois deles e 300.000 ienes para um deles. O resultado do interrogatório do representante do demandante é consistente com isto.
No entanto, o réu nega que tal acordo tenha sido feito, e o demandante originalmente assumiu a criação do programa do sistema em questão do réu e tinha a obrigação de completá-lo, e uma pessoa nessa posição, que não completou o trabalho e não pôde entregar o programa, o réu, que é o cliente, não deveria fazer algo irracional como isentar o demandante de sua obrigação de criação a partir de agora e pagar até o custo que o demandante incorreu durante esse período. Certamente, se o demandante tinha a obrigação de completar o programa, o argumento do réu seria razoável.
Portanto, primeiro, no contrato para o desenvolvimento do programa do sistema em questão, vamos examinar se o demandante não tinha a obrigação de completá-lo.
(Omissão) Ao olhar para as evidências, não se pode encontrar evidências que possam reconhecer que o demandante não tinha a obrigação de completar o programa em questão no contrato. (Omissão) E no resultado do interrogatório do representante do demandante, o contrato é um pedido em bloco, e o programa é desenvolvido dentro da empresa do demandante, e o demandante assumiu a obrigação de completar o programa em questão e testemunhou com base no fato de que ele tinha essa obrigação, e nunca negou que ele tinha essa obrigação. Ao olhar para os documentos, o cronograma de trabalho, que é incontestável em sua formação (omissão), é baseado na premissa de que o demandante tem a obrigação de completar o programa em questão, e descreve o cronograma até a conclusão, por isso pode ser reconhecido que é tal documento, então, ao contrário, pode-se reconhecer que o demandante tinha a obrigação de completar o programa no contrato. (Omissão)
Além disso, não há evidências que contradigam o reconhecimento de que o demandante tinha a obrigação de completar o programa em questão.
Portanto, como o réu argumenta, uma pessoa que não cumpriu a obrigação de criar um programa que tinha a obrigação de completar, mesmo que tenha a responsabilidade de não cumprir a obrigação, não pode exigir o pagamento do preço da empreitada, e a menos que haja circunstâncias especiais, o cliente não deve isentar incondicionalmente uma pessoa nessa posição de sua obrigação contratual e ainda pagar o custo que ela incorreu até agora. O representante do demandante, no resultado de seu interrogatório, testemunhou que mesmo que o programa não estivesse completo, se ele estivesse trabalhando de acordo com as instruções do cliente, ele teria cumprido sua promessa de trabalhar dentro do escopo instruído dentro do prazo, então ele poderia reivindicar o preço do software de computador para o trabalho que ele fez, mas isso é contrário ao senso comum geral sobre contratos de empreitada, e na indústria do demandante e do réu que desenvolve software, é diferente do senso comum geral, é um contrato de empreitada, e mesmo que o trabalho não esteja completo, não se pode reconhecer o fato de que há uma prática de pagar a remuneração, então o resultado do interrogatório do representante do demandante é nada mais do que sua opinião pessoal e não pode ser adotado.

Julgamento do Tribunal Distrital de Tóquio, 22 de fevereiro do ano 23 de Heisei (2011)

O que podemos aprender com o exemplo de julgamento acima

O que é particularmente notável no exemplo de julgamento acima é:

1. Ao invés de isentar a obrigação do fornecedor de “concluir o trabalho” com base na conclusão de um contrato de trabalho temporário superficial/formal, procurou-se uma resolução de conflito justa e substancial com base no conteúdo específico do acordo entre as duas partes, que é a “conclusão do trabalho”.
2. Uma vez que foi determinado que o contrato em questão era um contrato de empreitada, com base no requisito de “conclusão do trabalho”, foi decidido que o julgamento sobre outros pontos de discussão deveria ser feito com base nas práticas comerciais da indústria relacionadas aos contratos de empreitada.

Estes dois pontos podem ser resumidos da seguinte forma: o tribunal dá mais importância à concordância substancial das intenções das duas partes do que ao título do contrato superficial. Além disso, uma vez que se determina que a substância do contrato é um contrato de empreitada, parece que se busca uma resolução com base nas práticas comerciais da indústria relacionadas aos contratos de empreitada em relação a outros pontos de discussão. A rejeição da alegação do lado do pedido/fornecedor com expressões como “declaração contrária ao senso comum geral sobre contratos de empreitada” e “opinião pessoal” é muito característica, e sugere que o senso comum social e a percepção social são refletidos na interpretação da lei e têm um impacto na prática jurídica. Este é um ponto que deve ser notado juntamente com o fato de que o conceito de “conclusão do trabalho”, que foi tão enfatizado neste julgamento, é explicado em detalhes no seguinte artigo, considerando o contexto do desenvolvimento do sistema.

Considerando que os contratos de empreitada são frequentemente utilizados na prática de projetos de desenvolvimento de sistemas, e que o elemento essencial de tais contratos é a “conclusão do trabalho”, é importante ter uma compreensão profunda deste ponto.

É necessário entender as obrigações de gestão de projetos

Além disso, esta decisão está profundamente relacionada com a “obrigação de gestão de projetos” que os especialistas em desenvolvimento de sistemas, ou seja, os fornecedores, devem assumir. Uma explicação geral sobre estas obrigações pode ser encontrada no seguinte artigo.

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

Considerando o conteúdo do artigo acima, é claro que a responsabilidade dos fornecedores que aceitam trabalho como especialistas em projetos de desenvolvimento de sistemas não é de todo leve. Certamente, não há dúvida de que há muitas situações em que a cooperação do lado do usuário é necessária para o progresso suave do projeto. No entanto, é difícil imaginar que esta obrigação seja isenta sem fazer esforços, como solicitar a cooperação necessária ao usuário quando apropriado. É evidente que é muito difícil atribuir a responsabilidade pelo fracasso do projeto ao lado do usuário. A validade da decisão acima torna-se mais perceptível quando se entende a gestão de projetos. Pelo contrário, pode haver muitos aspectos em que a estrutura teórica de considerar a realidade da transação como um contrato de empreitada, em vez de um despacho, foi facilmente adotada para concordar com a conclusão apropriada derivada deste ponto de vista.

Resumo

Acima, explicamos os casos de conflito de projetos que podem ocorrer quando a distinção entre destacamento e subcontratação é vaga. Nos casos, é evidente que a substância, como as promessas concretas que foram trocadas mutuamente e os costumes comerciais na indústria, é mais importante do que o título formal do contrato. Além disso, parece que a compreensão da “obrigação de gestão de projetos”, que serve como base para as discussões legais sobre os detalhes de se o tipo de contrato individualmente concluído é um destacamento ou subcontratação, também é importante. Em projetos de TI, vemos muita utilização de recursos humanos através de métodos como destacamento e subcontratação, bem como expatriação e quase-delegação. A distinção e diferença geral, levando em conta estes, é explicada em detalhe no seguinte artigo.

https://monolith.law/corporate/difference-contract-dispatch-loan-labor-supply[ja]

Não apenas a diferença entre destacamento e subcontratação, mas também as variações de conflito que surgem da ambiguidade do tipo de contrato podem ser presumidas. No entanto, mesmo que o caso a ser tratado seja desconhecido, o que deve ser valorizado é, novamente, a compreensão de questões fundamentais, como a “obrigação de gestão de projetos”.