Sulla distinzione tra lavoro temporaneo e appalto nel settore IT: leggi e casi giudiziari

Nel settore IT, è comune vedere molti professionisti di diverse aziende coinvolti in un unico progetto. In tali circostanze, il luogo di lavoro del tecnico partecipante al progetto può spesso essere separato dalla sede dell’azienda a cui appartiene. Questo è tipico nei casi di cosiddetta residenza permanente presso il cliente o SES. L’ambiguità nel tipo di contratto o di impiego del tecnico che lavora sul campo può non solo comportare il rischio di futuri conflitti riguardanti i diritti dei lavoratori, ma può anche rappresentare un rischio di fallimento del progetto stesso. In questo articolo, chiariremo la distinzione, spesso sfumata nella pratica, tra distacco e appalto, e spiegheremo come tali problemi contrattuali possono influire sullo svolgimento fluido dell’intero progetto.

La differenza tra somministrazione e appalto

Quando l’azienda che riceve l’ordine di lavoro (o il fornitore a cui è stato subappaltato) è diversa dall’azienda che emette l’ordine di lavoro, è comune che il personale venga inviato sul campo sulla base di un contratto di appalto. In altre parole, il fornitore/l’azienda che riceve l’ordine interviene e invia tecnici sul campo. Per quanto riguarda la natura del contratto di appalto, abbiamo fornito una spiegazione dettagliata nell’articolo sottostante.

https://monolith.law/corporate/system-development-contact-agreement[ja]

Nell’articolo sopra, spieghiamo che l’essenza del contratto di appalto è che il “completamento del lavoro” diventa la condizione per l’adempimento del debito. Inoltre, spieghiamo che è importante chiarire le condizioni di accettazione al momento della conclusione del contratto per prevenire problemi. Quando si invia personale sul campo sulla base di un contratto di appalto, si tratta pur sempre di una transazione commerciale tra aziende, quindi l’azienda che accoglie il tecnico/il lato del campo non ha l’obbligo di rispettare le leggi sul lavoro, ecc. Tuttavia, in cambio, non è legalmente permesso dare ordini diretti a tale tecnico. Se non si tiene conto di questi punti, anche se in superficie è stato concluso un contratto di appalto, si corre il rischio di essere trattati come un’attività illegale di fornitura di lavoratori, cioè un “appalto mascherato”.

https://monolith.law/corporate/criteria-for-disguised-contract[ja]

Casi di controversia derivanti dall’ambiguità tra distacco e appalto

Tralasciando la discussione generale su “contratti di appalto” e “appalti mascherati”, ciò che tratteremo di seguito è un caso di fallimento di un progetto causato dall’ambiguità nella distinzione tra distacco e appalto. Questa ambiguità può non solo portare a violazioni dei diritti dei lavoratori individuali e a conflitti tra lavoratori e datori di lavoro, ma può anche rappresentare un rischio di fallimento per l’intero progetto, come si può vedere di seguito.

Il distacco e l’appalto cambiano significativamente i requisiti per l’adempimento del debito

Il distacco e l’appalto sono simili nel senso che entrambi prevedono che un’azienda intervenga e invii personale sul campo di sviluppo. Tuttavia, come detto in precedenza, in caso di appalto, l’adempimento del debito non è riconosciuto a meno che non sia riconosciuto il “completamento del lavoro”. Nel caso citato nella sentenza qui sotto, la questione era se il pagamento poteva essere richiesto per un progetto che alla fine era fallito. Nel caso di un appalto, il “completamento del lavoro” è un requisito, mentre nel caso di un distacco, è possibile giustificare il pagamento del lavoro solo sulla base dei risultati effettivi, come le ore di lavoro effettive.

Il lato dell’ordine/il fornitore (il querelante) ha sostenuto che il contratto di distacco era stato concluso retroattivamente e che il personale era stato inviato solo sotto forma di distacco, e ha sostenuto che non era obbligato a “completare il lavoro”. Tuttavia, il tribunale ha respinto questa affermazione (le parti sottolineate e in grassetto sono state aggiunte dall’autore).

Il querelante sostiene che, dopo che è stato confermato che il querelante non era in grado di sviluppare il programma del sistema in questione, il 1° aprile dell’anno 61 (1986) dell’era Showa, tra il querelante e l’imputato, è stato concordato che l’imputato avrebbe pagato rapidamente al querelante 550.000 yen, riducendo i costi di sviluppo di due periodi e un totale di 710.600 yen per le spese di ritiro, e che l’imputato avrebbe preso in carico il lavoro del querelante dal 1° aprile dello stesso anno, e che per lo sviluppo del sistema di informazione testuale da parte dell’imputato, il personale sarebbe stato inviato dal querelante sotto forma di distacco di lavoro, e che il numero di persone distaccate sarebbe stato di tre, con un prezzo unitario di 55.000 yen per due persone e 30.000 yen per una persona. Tuttavia, l’imputato nega che tale accordo sia stato raggiunto, e sostiene che il querelante aveva originariamente accettato di creare il programma del sistema in questione per l’imputato, e che aveva l’obbligo di completarlo, e che una persona in tale posizione, che non ha completato il programma e non è stata in grado di consegnarlo, non avrebbe dovuto fare qualcosa di irragionevole come esonerare l’imputato, che è l’ordinante, dal suo obbligo di creazione in futuro, o pagare i costi che il querelante ha sostenuto nel frattempo. Infatti, se il querelante aveva l’obbligo di completare il programma, si potrebbe dire che la posizione dell’imputato è ragionevole.
Quindi, prima di tutto, nel contratto per lo sviluppo del programma del sistema in questione, si esaminerà se il querelante non aveva l’obbligo di completarlo.
(Omissione) Guardando le prove, non si può trovare alcuna prova che possa riconoscere che il querelante non aveva l’obbligo di completare il programma in questione nel contratto di cui sopra. (Omissione) E anche nel risultato dell’interrogatorio del rappresentante del querelante, il contratto di cui sopra è un ordine globale, e il programma è sviluppato all’interno della società del querelante, e il querelante ha presupposto l’obbligo di completare il programma in questione e ha testimoniato, e non ha mai negato che aveva tale obbligo. Guardando i documenti, il piano di lavoro, che non è contestato per la sua formazione (omissione), è un documento che presupponga che il querelante abbia l’obbligo di completare il programma in questione e che descriva il programma fino al suo completamento. Pertanto, al contrario, si può riconoscere che il querelante aveva l’obbligo di completare il programma in base al contratto. (Omissione)
Non ci sono altre prove che contraddicano il riconoscimento che il querelante aveva l’obbligo di completare il programma.
Se così fosse, come sostiene l’imputato, una persona che non ha creato un programma per il quale aveva l’obbligo di completamento dovrebbe assumersi la responsabilità per il mancato adempimento del debito, e non può richiedere il pagamento del prezzo dell’appalto, a meno che non ci siano circostanze particolari, e l’ordinante non dovrebbe accordare all’ordinante l’esenzione incondizionata dal suo obbligo contrattuale e, inoltre, pagare i costi che ha sostenuto fino ad ora. Il rappresentante del querelante, nel risultato del suo interrogatorio, afferma che anche se il programma non è stato completato, se ha lavorato secondo le istruzioni dell’ordinante, ha mantenuto la sua promessa di lavorare entro il termine specificato, quindi può richiedere il pagamento del software del computer per il lavoro che ha fatto, ma questa è una dichiarazione contraria al senso comune generale riguardo ai contratti di appalto, e nel settore del querelante e dell’imputato che sviluppa software, non si può riconoscere che ci sia una pratica di pagare una remunerazione anche se non c’è un completamento del lavoro, che è diverso dal senso comune generale, in contratti di appalto, quindi il risultato dell’interrogatorio del rappresentante del querelante è solo la sua opinione personale, e non può essere adottato.

Giudizio del Tribunale di Tokyo, 22 febbraio dell’anno 23 dell’era Heisei (2011)

Cosa si può dedurre dal caso giudiziario sopra citato

In particolare, nel caso giudiziario sopra citato, vale la pena notare che:

1. Non si basa sulla conclusione di un contratto di distacco apparente/formale per esonerare il fornitore dall’obbligo di “completamento del lavoro”, ma si prevede una risoluzione equa del conflitto basata sul contenuto specifico dell’accordo tra le parti, cioè il “completamento del lavoro”.
2. Si è deciso che il contratto in questione era un contratto di appalto perché imponeva il “completamento del lavoro” come requisito per l’adempimento del debito, e si è deciso che si doveva giudicare sulla base delle consuetudini commerciali nell’industria relative ai contratti di appalto anche per altre questioni.

Per riassumere brevemente questi due punti, mostrano chiaramente che nei processi giudiziari si dà più peso alla corrispondenza sostanziale delle intenzioni delle parti rispetto al titolo del contratto e ad altri aspetti superficiali. Inoltre, una volta che la sostanza del contratto è stata giudicata un contratto di appalto, si cerca di risolvere le altre questioni tenendo conto delle consuetudini commerciali nell’industria relative ai contratti di appalto. Il fatto che si usino espressioni come “dichiarazioni contrarie al senso comune generale riguardo ai contratti di appalto” e “opinioni personali” quando si respinge l’argomentazione del lato dell’ordine/il fornitore è molto caratteristico, e mostra chiaramente questo punto. È un punto da notare insieme al fatto che il senso comune sociale e la percezione sociale sono riflessi nell’interpretazione della legge e influenzano la pratica legale. A proposito, il concetto di “completamento del lavoro”, che è stato così enfatizzato in questa sentenza, è spiegato in dettaglio nel seguente articolo, tenendo conto del contesto dello sviluppo del sistema.

https://monolith.law/corporate/completion-of-work-in-system-development[ja]

Dato che i contratti di appalto sono spesso utilizzati nella pratica dei progetti di sviluppo di sistemi, e che l’elemento essenziale di tali contratti è il “completamento del lavoro”, è importante capire bene questo punto.

La comprensione del dovere di gestione del progetto è anche un prerequisito

Inoltre, questa sentenza è strettamente correlata alla discussione sul “dovere di gestione del progetto” che il fornitore, in quanto esperto di sviluppo di sistemi, deve assumere. Una spiegazione generale di tali obblighi è fornita nell’articolo seguente.

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

Considerando il contenuto dell’articolo sopra, è chiaro che la responsabilità del fornitore, che accetta il lavoro come esperto di progetti di sviluppo di sistemi, non è affatto leggera. Certamente, non c’è bisogno di dire che ci sono molte situazioni in cui è necessaria la cooperazione dell’utente per il progresso fluido del progetto. Tuttavia, è difficile pensare che tale dovere sia esentato senza fare alcuno sforzo, come chiedere la cooperazione necessaria all’utente quando necessario. È evidente che è molto difficile attribuire la responsabilità del fallimento del progetto all’utente da questo punto di vista. La validità della sentenza sopra menzionata può essere più facilmente percepita se si ha una comprensione preliminare della gestione del progetto. Piuttosto, potrebbe esserci stato un certo grado di adozione della struttura teorica che considera la realtà delle transazioni non come un invio, ma come un contratto di appalto, al fine di raggiungere una conclusione valida derivata da questo punto di vista.

Riassunto

Abbiamo discusso dei casi di controversie di progetto che possono sorgere quando la distinzione tra distacco e appalto è vaga. Nei casi, si può vedere che ciò che conta più del titolo formale del contratto sono le promesse concrete scambiate reciprocamente e la sostanza delle pratiche commerciali all’interno dell’industria. Inoltre, sembra importante non solo la discussione legale sui dettagli di se il tipo di contratto concluso individualmente è un distacco o un appalto, ma anche la comprensione del “dovere di gestione del progetto” come base per questi. Nei progetti IT, si vedono spesso non solo distacchi e appalti, ma anche l’utilizzo di personale attraverso metodi come il distacco e la delega. Per una distinzione e differenza generale tenendo conto di questi, si prega di consultare l’articolo dettagliato di seguito.

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

Non solo la differenza tra distacco e appalto, ma anche le variazioni di conflitto derivanti dall’ambiguità del tipo di contratto possono essere immaginate. Tuttavia, anche se il caso da affrontare è sconosciuto, ciò che dovrebbe essere importante è ancora la comprensione delle questioni fondamentali, come il “dovere di gestione del progetto”.