Despre legile și cazurile de judecată legate de distincția dintre delegare și contractare în industria IT

În proiectele din domeniul IT, este frecvent să vedem o mulțime de talente din diverse companii mobilizate pentru un singur proiect. În astfel de cazuri, locul de muncă al inginerilor care participă la proiect poate fi adesea separat de locația companiei la care aceștia sunt angajați. Acest lucru se aplică în cazul așa-numitelor detașări la client sau SES. Faptul că statutul de angajare și tipul de contract al inginerilor care lucrează pe teren devin neclare poate duce nu numai la riscul de a genera dispute legate de drepturile lucrătorilor în viitor, dar și la riscul de a provoca probleme grave pentru proiect în sine. În acest articol, vom clarifica diferența, adesea neclară în practică, între detașare și contractare, și vom explica cum aceste probleme legate de contract pot afecta progresul fără probleme al întregului proiect.

Diferența dintre delegare și contractare

Când compania care comandă lucrarea (sau furnizorul care primește comanda) și compania care comandă lucrarea sunt diferite, este obișnuit ca personalul să fie trimis la fața locului pe baza unui contract de contractare. Adică, furnizorul / partea care primește comanda intervine și trimite un inginer la fața locului. De asemenea, explicăm în detaliu ce este un contract de contractare în articolul de mai jos.

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

În articolul de mai sus, explicăm că esența unui contract de contractare este că “finalizarea lucrării” devine o condiție pentru îndeplinirea obligației. De asemenea, explicăm că este important să clarificăm condițiile de acceptare la momentul încheierii contractului pentru a preveni apariția problemelor. De asemenea, atunci când se trimite personal la fața locului pe baza unui contract de contractare, acesta rămâne o tranzacție comercială între companii, astfel încât partea care comandă / partea de pe teren care acceptă inginerul nu are obligația de a respecta legea muncii. Cu toate acestea, în schimb, nu este permisă legal să dea ordine directe acestui inginer. Dacă nu se ține cont de aceste aspecte, chiar dacă la suprafață a fost încheiat un contract de contractare, există riscul de a fi tratat ca o afacere ilegală de furnizare a forței de muncă, adică “contractare falsă”.

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

Cazuri de conflict dezvoltate din cauza ambiguității diferenței dintre delegare și subcontractare

Lăsând deoparte discuția generală despre “contractul de subcontractare” și “subcontractarea falsă”, ceea ce vom aborda în continuare este un caz de eșec al unui proiect care a început din cauza ambiguității diferenței dintre delegare și subcontractare. Această ambiguitate nu numai că poate duce la încălcarea drepturilor lucrătorilor individuali și la conflicte între angajați și angajatori, dar poate deveni și un risc de eșec pentru întregul proiect, așa cum se poate vedea clar din următoarele.

Îndeplinirea obligațiilor se schimbă semnificativ între detașare și contractare

Detașarea și contractarea sunt similare în sensul că o companie intervine și trimite personal la locul de dezvoltare. Cu toate acestea, așa cum am menționat anterior, în cazul contractării, îndeplinirea obligațiilor nu este recunoscută în principiu decât dacă este recunoscută “finalizarea lucrării”. În cazul citat mai jos, s-a discutat dacă plata poate fi solicitată în cazul în care proiectul a eșuat în cele din urmă. În cazul contractării, “finalizarea lucrării” este impusă ca o cerință, în timp ce în cazul detașării, este posibil să justificați plata muncii doar pe baza rezultatelor reale, cum ar fi orele de lucru efective.

Partea care a primit comanda / furnizorul (reclamantul) a susținut că contractul de detașare a fost încheiat ulterior și că personalul a fost trimis în continuare sub formă de detașare, susținând că “finalizarea lucrării” nu a fost impusă ca o obligație. Cu toate acestea, instanța a negat această afirmație (partea subliniată și bolduită a fost adăugată de autor).

Reclamantul susține că, după ce a devenit clar că reclamantul nu poate dezvolta programul pentru acest sistem, pe 1 aprilie 1986 (Showa 61), între reclamant și pârât, s-a convenit că pârâtul va plăti rapid reclamantului costurile de dezvoltare, reduse de la 7.106.000 de yeni la 550.000 de yeni, și că pârâtul va prelua activitățile reclamantului începând cu 1 aprilie, iar cu privire la dezvoltarea sistemului de informații textuale de către pârât, se va implementa prin detașarea personalului în formă de muncă de la reclamant, cu trei persoane detașate, cu un preț unitar de 55.000 de yeni pentru doi dintre ei și 30.000 de yeni pentru unul dintre ei. Rezultatele interogării reprezentantului reclamantului sunt în concordanță cu aceasta.
Cu toate acestea, pârâtul neagă că a existat un astfel de acord, iar reclamantul, care inițial a preluat crearea programului pentru acest sistem de la pârât, avea obligația de a-l finaliza, și este absurd ca pârâtul, care este comandantul, să exonereze reclamantul de obligația sa de a crea în continuare sau să plătească costurile pe care reclamantul le-a avut în acest timp. Într-adevăr, dacă reclamantul avea obligația de a finaliza programul, argumentul pârâtului este rezonabil.
Prin urmare, mai întâi, în contractul de dezvoltare a programului pentru acest sistem, vom examina dacă reclamantul nu avea obligația de a-l finaliza.
(Omis) Privind dovezile, nu putem găsi dovezi care să permită recunoașterea faptului că reclamantul nu avea obligația de a finaliza acest program în acest contract. (Omis) Și reprezentantul reclamantului, în rezultatele interogării sale, a declarat că acest contract este o comandă în bloc, și că programul este dezvoltat în cadrul companiei reclamantului, și a depus mărturie presupunând că reclamantul a avut obligația de a finaliza acest program, și nu a negat niciodată că a avut această obligație. Privind documentele, (omis) planul de lucru, care este recunoscut ca fiind stabilit, presupune că reclamantul are obligația de a finaliza acest program, și este un document care notează programul până la finalizare. Prin urmare, potrivit acestuia, dimpotrivă, putem recunoaște că reclamantul avea obligația de a finaliza programul în conformitate cu contractul. (Omis)
Nu există alte dovezi care să contrazică recunoașterea faptului că reclamantul avea obligația de a finaliza acest program.
Dacă este așa, așa cum susține pârâtul, este natural ca cei care nu au îndeplinit obligația de a crea un program să aibă responsabilitatea pentru neîndeplinirea obligațiilor, dar nu pot solicita plata pentru contractare, și, în absența unor circumstanțe speciale, nu este posibil ca comandantul să exonereze necondiționat persoana în această poziție de obligațiile sale contractuale și, în plus, să plătească costurile pe care le-a avut până acum. Rezultatele interogării reprezentantului reclamantului, chiar dacă programul nu este finalizat, dacă a lucrat conform instrucțiunilor comandantului, a îndeplinit promisiunea de a lucra în cadrul instrucțiunilor în termenul limită, deci poate solicita plata software-ului computerului pentru munca pe care a făcut-o, este o declarație care contrazice bunul simț general cu privire la contractele de contractare, și în industria reclamantului și a pârâtului, care dezvoltă software, nu putem recunoaște faptul că există o practică de a plăti remunerația chiar dacă nu există finalizarea lucrării, care este diferită de bunul simț general, în lumina mărturiei martorilor, deci rezultatele interogării reprezentantului reclamantului sunt doar o opinie personală și nu pot fi adoptate.

Hotărârea Tribunalului Districtual Tokyo, 22 februarie 2011 (Heisei 23)

Ce putem înțelege din cazul juridic menționat mai sus

În particular, în cazul juridic menționat mai sus, merită să acordăm atenție următoarelor aspecte:

1. Nu exonerează obligația furnizorului de a “finaliza munca” pe baza încheierii unui contract de delegare superficial și formal, ci se așteaptă la o rezolvare a conflictului echitabilă și substanțială, bazată pe conținutul promisiunii specifice a ambelor părți de a “finaliza munca”.
2. Deoarece “finalizarea muncii” este impusă ca o cerință pentru îndeplinirea obligațiilor, contractul respectiv este considerat un contract de subcontractare, iar în alte puncte de discuție, ar trebui să se ia o decizie bazată pe obiceiurile comerciale din industrie legate de contractele de subcontractare.

Se poate considera că acestea sunt aspectele notabile.

Dacă rezumăm aceste două puncte, putem considera că, mai mult decât titlul unui contract superficial, concordanța intențiilor substanțiale ale ambelor părți este accentuată în instanță. De asemenea, odată ce esența contractului este considerată un contract de subcontractare, se pare că s-a încercat o rezolvare care ține cont de obiceiurile comerciale din industrie legate de contractele de subcontractare și în alte puncte de discuție. Apariția unor expresii precum “declarații care contravin bunului simț general în legătură cu contractele de subcontractare” și “opinii proprii” atunci când respingerea argumentelor părții care primește comanda / furnizorului este foarte caracteristică și pare să indice clar acest lucru. Ar trebui să acordăm atenție și faptului că lucruri precum bunul simț social și noțiunile sociale sunt reflectate în interpretarea legii și pot influența practica juridică. De altfel, conceptul de “finalizarea muncii”, care a fost atât de accentuat în această decizie, este explicat în detaliu în articolul de mai jos, luând în considerare contextul dezvoltării sistemului.

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

Având în vedere că contractele de subcontractare sunt adesea utilizate în practica proiectelor de dezvoltare a sistemelor și că elementul esențial al acestora este “finalizarea muncii”, ar trebui să înțelegem profund acest lucru.

Înțelegerea obligațiilor de management al proiectelor este, de asemenea, presupusă

De asemenea, această decizie este strâns legată de discuția despre “obligațiile de management al proiectelor” pe care le au specialiștii în dezvoltarea de sisteme, adică furnizorii. O explicație generală a acestor obligații este prezentată în articolul de mai jos.

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

Luând în considerare conținutul articolului de mai sus, este clar că responsabilitatea furnizorilor care acceptă lucrări în calitate de experți în proiecte de dezvoltare a sistemelor nu este deloc ușoară. Desigur, nu este nevoie să spunem că există multe situații în care este necesară cooperarea utilizatorilor pentru progresul fără probleme al proiectului. Cu toate acestea, este greu de crezut că obligațiile lor vor fi scutite fără a face eforturi, cum ar fi solicitarea cooperării adecvate de la utilizatori. Este clar că este foarte dificil să se atribuie responsabilitatea pentru eșecul proiectului utilizatorilor din acest punct de vedere. Validitatea deciziei de mai sus poate fi mai ușor de simțit dacă se presupune o înțelegere a managementului proiectului. Mai degrabă, este posibil ca teoria contractului de subcontractare, nu de delegare, să fi fost adoptată pentru a se potrivi cu concluzia corectă derivată din acest punct de vedere.

Rezumat

Am explicat mai sus despre cazurile de conflict ale proiectului care pot apărea atunci când distincția dintre delegare și contractare este ambiguă. În cazurile prezentate, se pare că substanța, cum ar fi promisiunile concrete care au fost schimbate reciproc și obiceiurile comerciale din industrie, este mai importantă decât titlul formal al contractului. În plus, se pare că nu numai discuțiile legale detaliate despre tipul de contract care a fost încheiat individual, fie că este vorba de delegare sau contractare, ci și înțelegerea despre “obligația de management al proiectului”, care este baza acestora, este importantă. În proiectele IT, se observă o utilizare largă a personalului prin metode precum delegarea și contractarea, dar și prin alte metode, cum ar fi detașarea sau delegarea semi-oficială. O distincție generală și diferențe care iau în considerare aceste aspecte sunt explicate în detaliu în articolul de mai jos.

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

Există multe variații de conflicte care provin din ambiguitatea tipului de contract, nu doar diferența dintre delegare și contractare. Cu toate acestea, chiar dacă cazul cu care trebuie să ne ocupăm este necunoscut, ceea ce ar trebui să fie important este, totuși, înțelegerea aspectelor fundamentale, cum ar fi “obligația de management al proiectului”.