Om lagar och rättsfall som rör skillnaden mellan bemanning och kontrakt i IT-branschen

I IT-relaterade projekt är det vanligt att talrika företags personal kallas in för att delta i ett och samma projekt. I sådana fall är det ofta så att arbetsplatsen för teknikerna som deltar i projektet skiljer sig från platsen där företaget de tillhör är beläget. Detta inkluderar situationer som så kallade kundplatsbaserade uppdrag och SES. När anställnings- och kontraktsformerna för tekniker som arbetar på plats blir oklara, finns det inte bara en risk för att det kan leda till konflikter om arbetstagares rättigheter i framtiden, utan det kan också bli en risk för att hela projektet går upp i lågor. I denna artikel kommer vi att klargöra skillnaden mellan uthyrning och kontrakt, vilka ofta blir oklara i praktiken, och förklara hur sådana kontraktsrelaterade problem kan påverka den smidiga framstegen för hela projektet.

Skillnaden mellan bemanning och kontrakt

När företaget som tar emot arbetet (eller dess underleverantörer) och företaget som beställer arbetet är olika, är det vanligt att personal skickas till platsen baserat på ett kontraktsavtal. Med andra ord, leverantören/leverantören kommer in och skickar tekniker till platsen. För mer information om vad ett kontraktsavtal är, se följande artikel.

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

I ovanstående artikel förklaras det att “fullbordandet av arbetet” är en väsentlig egenskap hos kontraktsavtalet, eftersom det är villkoret för att uppfylla skulden. Dessutom förklaras det att det är viktigt att tydligt definiera godkännandekriterierna vid kontraktstidpunkten för att förhindra problem. Observera att när du stationerar personal på plats baserat på ett kontraktsavtal, är det strikt en affärstransaktion mellan företag, så det finns ingen skyldighet för beställaren/platsen att följa arbetslagstiftningen. Men i gengäld är det inte lagligt att direkt ge order till den tekniker. Om du inte tar hänsyn till dessa punkter, även om ett kontraktsavtal har ingåtts på ytan, finns det en risk att det behandlas som en olaglig arbetskraftsförsörjning, det vill säga “falskt kontrakt”.

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

Fall där tvetydigheten mellan bemanning och entreprenad ledde till konflikt

Vi kommer att överlåta den allmänna diskussionen om “entreprenadkontrakt” och “falsk entreprenad” till innehållet ovan, och i stället fokusera på ett fall där ett projekt gick upp i lågor på grund av att skillnaden mellan bemanning och entreprenad blev otydlig. Denna tvetydighet kan inte bara leda till kränkningar av individuella arbetstagares rättigheter och konflikter mellan arbetsgivare och arbetstagare, utan kan också utgöra en risk för att hela projektet går upp i lågor, vilket blir tydligt när man tittar på följande.

Uppdrags- och kontraktskrav för skulduppfyllelse skiljer sig markant

Uppdrag och kontrakt liknar varandra i att företag skickar personal till utvecklingsplatsen. Men som nämnt tidigare, i ett kontrakt erkänns inte skulduppfyllelse i princip om inte “arbetsfärdigställandet” erkänns. I det rättsfall som citeras nedan blev det en tvist om ersättning skulle beviljas eller inte när projektet slutligen misslyckades. Om det är ett kontrakt ställs “arbetsfärdigställandet” som ett krav, medan om det är ett uppdrag kan arbetsersättning rättfärdigas endast på grundval av faktiska resultat som arbetstid.

Beställaren / leverantören (sökanden) hävdade att uppdragsavtalet hade ingåtts efteråt och att personalen hade skickats i form av ett uppdrag, och hävdade att “arbetsfärdigställandet” inte var pålagt som en skyldighet. Men domstolen förnekade detta påstående (understrukna delar, fetstil är tillagt av författaren).

Sökanden hävdade att efter det att det hade fastställts att sökanden inte kunde utveckla programmet för det aktuella systemet, hade sökanden och svaranden kommit överens om att svaranden snabbt skulle betala sökanden 550 000 yen, minskat från totalt 710 600 yen för två perioder och kostnader för genomförande av läger, från och med den 1 april Showa 61 (1986), och att svaranden skulle ta över sökandens arbete från och med samma dag, och att svaranden skulle utveckla ett textinformationssystem genom att skicka personal i form av arbetskraft från sökanden, med tre personer som personal och en enhetskostnad på 55 000 yen för två personer och 30 000 yen för en person. Resultatet av förhöret med sökandens representant stöder detta.
Emellertid förnekade svaranden att en sådan överenskommelse hade träffats, och sökanden hade ursprungligen tagit på sig att skapa programmet för det aktuella systemet från svaranden och hade en skyldighet att slutföra det. Svaranden hävdade att det var otänkbart att svaranden, som var beställaren, skulle befria sökanden från sin skyldighet att skapa det i framtiden och betala kostnaderna som sökanden hade behövt under tiden, trots att sökanden inte hade kunnat slutföra det och inte kunde överlämna programmet. Visst, om sökanden hade en skyldighet att slutföra programmet, skulle det vara rimligt att säga att svarandens påstående är korrekt.
Först och främst, i kontraktet om utveckling av programmet för det aktuella systemet, ska vi överväga om sökanden hade en skyldighet att slutföra det eller inte.
(Utelämnat) När vi tittar på bevisen kan vi inte hitta några bevis som erkänner att sökanden inte hade en skyldighet att slutföra programmet i detta kontrakt. (Utelämnat) Och även i resultatet av förhöret med sökandens representant, förutsätter han att sökanden hade en skyldighet att slutföra programmet och att kontraktet var en bulkorder och att programmet skulle utvecklas internt i sökandens företag, och han har aldrig förnekat att han hade den skyldigheten, vilket är klart. När vi tittar på dokumenten, är det klart att arbetsplanen, som inte bestrids att den har etablerats (utelämnat), förutsätter att sökanden har en skyldighet att slutföra programmet och att den beskriver schemat fram till dess att det är klart. Därför, enligt detta, tvärtom, kan vi erkänna att sökanden hade en skyldighet att slutföra programmet enligt kontraktet. (Utelämnat)
Det finns inga andra bevis som motsäger erkännandet att sökanden hade en skyldighet att slutföra programmet.
Om så är fallet, som svaranden hävdar, är det naturligt att den som inte har skapat programmet som han hade en skyldighet att slutföra, bär ansvaret för att inte ha uppfyllt sin skuld, och han kan inte begära betalning för kontraktet, och om det inte finns några speciella omständigheter, är det otänkbart att beställaren skulle befria honom från sin kontraktsmässiga skyldighet utan villkor och dessutom betala kostnaderna han hade behövt fram till dess. Sökandens representant hävdade i resultatet av hans förhör att även om programmet inte var klart, om han hade arbetat enligt beställarens instruktioner, hade han hållit sitt löfte att utföra arbetet inom den angivna tidsramen, så han trodde att han kunde begära betalning för mjukvaran för det arbete han hade utfört, men detta är ett uttalande som strider mot allmänna uppfattningar om kontrakt, och i sökandens och svarandens bransch, som utvecklar programvara, kan vi inte erkänna att det finns en praxis att betala ersättning även om arbetet inte är klart, vilket skiljer sig från allmänna uppfattningar, även i ljuset av vittnesmålen, så resultatet av förhöret med sökandens representant kan bara betraktas som hans egen åsikt och kan inte antas.

Tokyo District Court, February 22, Heisei 23 (2011)

Vad vi kan utläsa från ovanstående rättsfall

I det ovanstående rättsfallet är det särskilt värt att notera:

1. Att man inte undantar leverantörens “arbetsfullbordan” skyldighet baserat på en ytlig/formell kontrakt, utan snarare baserat på det specifika löftet om “arbetsfullbordan” mellan parterna, vilket förväntas leda till en rättvis lösning på tvisten i praktiken.
2. Att kontraktet bedöms vara ett entreprenadkontrakt eftersom “arbetsfullbordan” ställs som ett krav för skulduppfyllelse, och att bedömningar även i andra frågor bör göras baserat på branschpraxis för entreprenadkontrakt.

Detta är några av de punkter som kan övervägas.

Om vi kort sammanfattar dessa två punkter, tyder det på att domstolen lägger större vikt vid en verklig överensstämmelse mellan parterna än vid den formella titeln på kontraktet. Dessutom, när kontraktets väsen en gång har bedömts vara ett entreprenadkontrakt, verkar det som om man har strävat efter att lösa andra frågor baserat på branschpraxis för entreprenadkontrakt. När leverantörens argument avvisas, är uttryck som “uttalanden som strider mot allmänna sunt förnuft om entreprenadkontrakt” och “unika åsikter” mycket karakteristiska, och tyder på detta. Det är värt att notera att sådana saker som socialt sunt förnuft och sociala normer reflekteras i lagtolkningen och kan påverka juridisk praxis. För övrigt, för en mer detaljerad förklaring av begreppet “arbetsfullbordan”, som blev så viktigt i detta domslut, se följande artikel med hänsyn till kontexten för systemutveckling.

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

Med tanke på att entreprenadkontrakt ofta används i praktiken för systemutvecklingsprojekt, och att dess väsentliga element ligger i “arbetsfullbordan”, bör du ha en djup förståelse för detta.

Förståelse för projektledningsskyldigheter ställs också som en förutsättning

Dessutom är denna dom djupt relaterad till diskussionen om “projektledningsskyldigheter” som systemutvecklingsexperter, eller leverantörer, måste uppfylla. En allmän förklaring av dessa skyldigheter finns i följande artikel.

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

Med innehållet i ovanstående artikel i åtanke, är det klart att ansvaret för leverantörer som tar på sig arbete som experter på systemutvecklingsprojekt inte är lätt. Visst, det är självklart att det finns många situationer där samarbete från användarsidan är nödvändigt för en smidig projektframsteg. Men det är svårt att tänka sig att denna skyldighet skulle undantas utan att göra några ansträngningar, som att kalla på nödvändigt samarbete från användaren vid lämpliga tillfällen. Det är mycket svårt att skylla ansvaret för ett misslyckat projekt på användarsidan, även från detta perspektiv. Rimligheten i ovanstående dom blir lättare att känna om man förstår projektledning. Snarare kan det ha varit att denna teoretiska struktur, som gör entreprenad snarare än uthyrning till verkligheten i transaktionen, var lättare att anta för att uppnå överensstämmelse med den rimliga slutsatsen som dras från detta perspektiv.

Sammanfattning

Vi har nu gått igenom potentiella konfliktfall i projekt där skillnaden mellan bemanning och kontrakt är oklar. I dessa fall är det tydligt att det inte bara är den formella titeln på kontraktet som är viktigt, utan också de specifika löften som har utbytts mellan parterna och branschens handelsvanor. Dessutom verkar det vara viktigt att inte bara diskutera juridiska detaljer som om ett specifikt kontrakt är bemanning eller kontrakt, utan också att ha en förståelse för “projektledningsskyldigheter” som en grundläggande princip. Inom IT-projekt ser vi ofta att personal inte bara används genom bemanning eller kontrakt, utan också genom metoder som utlåning eller quasi-delegation. En mer omfattande diskussion om dessa skillnader och distinktioner finns i följande artikel.

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

Det finns många potentiella konflikter som kan uppstå från oklarheter i kontraktstyper, inte bara skillnader mellan bemanning och kontrakt. Men även om det problem du står inför är okänt, tror vi att det som är viktigt är att ha en förståelse för grundläggande frågor, inklusive “projektledningsskyldigheter”.