MONOLITH LAW OFFICE+81-3-6262-3248Hverdager 10:00-18:00 JST [English Only]

MONOLITH LAW MAGAZINE

IT

Forskjellen og distinksjonen mellom kontrakten for systemutvikling og quasi-delegasjonskontrakten

IT

Forskjellen og distinksjonen mellom kontrakten for systemutvikling og quasi-delegasjonskontrakten

I forbindelse med bestilling og mottak av systemutvikling, blir det inngått kontrakter med forskjellige titler, som kontrakt for oppdrag, kontrakt for tjenesteoppdrag, og kontrakt for systemutvikling.

I henhold til loven, er det en forskjell mellom kontrakter hvor den ene parten utfører en tjeneste (som for eksempel utviklingsarbeid), og den andre parten betaler for denne tjenesten. Disse kontraktene er delt inn i kontrakter for arbeid og kontrakter for quasi-kommisjon.

For å si det enkelt,

  • Kontrakt for arbeid: En kontrakt hvor “du kan motta betaling hvis du leverer det som er lovet”
  • Kontrakt for quasi-kommisjon: En kontrakt hvor “du mottar betaling, og gjør ditt beste for å yte en innsats som tilsvarer denne betalingen”

er de to typene kontrakter.

Er systemutvikling en kontrakt eller en semi-delegasjon?

Systemutvikling har som mål å skape et “avtalt” system, og ifølge ovennevnte distinksjon kan det tenkes å være en kontraktsjobb, men det er ikke så enkelt. Dette skyldes at systemutvikling er litt forskjellig fra den typiske kontraktsjobben som loven antar.

En typisk kontraktsjobb er for eksempel en skreddersydd dress. I tilfellet med en dress, når målene er bestemt, er det lett for partene å forestille seg det ferdige produktet, og det er også lett å bedømme om det ferdige produktet samsvarer med bestillingen. I motsetning til dette, i systemutvikling, er det vanligvis ingen dokumenter som lett gir en oversikt over systemet, og det kan sies at det er vanskelig for bestilleren å få en oversikt over helheten. I tillegg har systemet som skal utvikles en spesiell egenskap ved at det gradvis konkretiseres gjennom forskjellige prosesser.

Derfor er det ofte et problem å skille mellom om kontrakten i en viss fase av systemutvikling, spesielt i de tidlige stadiene, er en “kontraktsjobb” som lover å fullføre jobben, eller en “semi-delegasjonskontrakt” som gjør sitt beste. Og avhengig av denne distinksjonen, hvis jobben ikke blir fullført, kan belønningen som systemutviklingsselskapet får bli null, noe som fører til at en av partene blir pålagt en overdreven og stor økonomisk byrde, så det er viktig å skille mellom hvilken kontrakt det er.

Derfor vil jeg forklare forskjellen mellom kontraktsjobber og semi-delegasjonskontrakter, hvilken kontrakt du bør inngå, og kriteriene for å skille mellom de to.

Forskjellene mellom kontraktskontrakter og quasi-delegasjonskontrakter i henhold til japansk sivillov

Først vil jeg forklare forskjellene mellom bestemmelsene i japansk sivillov om kontraktskontrakter og quasi-delegasjonskontrakter, samt hvordan de håndteres når en spesiell avtale er inngått.

Kontrakt for utførelse av arbeid: Mottak av betaling, oppsigelse, ansvar for mangler, underkontrakter og spesielle avtaler

En kontrakt for utførelse av arbeid er en avtale der en part (entreprenøren/leverandøren) lover å fullføre et bestemt arbeid, og den andre parten (bestilleren/brukeren) lover å betale for resultatet av dette arbeidet (kontraktsprisen).

“Fullføring av arbeidet” kan for eksempel være når begge parter er enige om at “prosjektplanen”, “kravspesifikasjonen”, “grunnleggende design”, “programmering”, “systemer” og andre leveranser er ferdigstilt.

Mottak av betaling

Hvis arbeidet ikke er fullført, kan ikke entreprenøren/leverandøren motta betaling. Hvis du ønsker å bli betalt før arbeidet er fullført, må du inngå en spesiell avtale om forskuddsbetaling. I systemutviklingsprosjekter basert på kontrakter for utførelse av arbeid, er “fullføring av arbeidet” et svært viktig konsept. Dette er forklart mer detaljert i artikkelen nedenfor.

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

I tillegg, i systemutvikling, er “fullføring av arbeidet” vanligvis anerkjent etter en “akseptansetest”.

https://monolith.law/corporate/estimated-inspection-of-system-development[ja]

Selv om en spesiell avtale er inngått, hvis arbeidet ikke blir fullført på grunn av prosjektavslutning eller lignende, må entreprenøren/leverandøren returnere den allerede mottatte betalingen til bestilleren/brukeren som en urettmessig fortjeneste. Dette er den største forskjellen fra en agenturkontrakt.

Oppsigelse

Hvis ingen av partene har brutt sine forpliktelser (brudd på løfter), kan bestilleren/brukeren kompensere for skader og si opp kontrakten før arbeidet er fullført. I dette tilfellet vil “skaden” være beløpet som entreprenøren/leverandøren har brukt, minus kostnadene som kunne ha blitt spart ved å bli fritatt for plikten til å fullføre arbeidet, fra den betalingen som kunne ha blitt mottatt. På den annen side kan ikke entreprenøren/leverandøren si opp kontrakten.

Hvis en spesiell avtale er inngått som sier at kontrakten ikke kan sies opp med mindre den andre parten misligholder sine forpliktelser, vil entreprenøren/leverandøren ikke ha risikoen for å bli sagt opp når som helst, selv om det ikke er noe brudd på kontrakten.

Ansvar for mangler

Hvis det er mangler ved arbeidets mål, kan bestilleren kreve retting av mangelen, erstatning for skade, og hvis kontraktens mål ikke kan oppnås, kan kontrakten sies opp.

En mangel betyr en feil eller defekt, og er anerkjent når kvaliteten eller ytelsen som målet skal ha i henhold til kontraktens formål, mangler. Hvis systemet ikke oppfyller de spesifiserte spesifikasjonene eller ytelsen etter at den siste prosessen som var planlagt i kontrakten er fullført, vil dette bli ansett som en “mangel”.

I en rettsavgjørelse om systembygging for et universitet, ble det bestemt at en feil relatert til lekkasje av personlig informasjon ikke var en mangel, men at mangelen på nødvendig eksklusiv kontroll i det aktuelle systemet var en “mangel”. Det er mulig å inngå en spesiell avtale om å ikke påta seg ansvar for mangler, eller å forkorte perioden for å påta seg ansvar.

For mer informasjon om ansvar for mangler, se artikkelen nedenfor.

https://monolith.law/corporate/defect-warranty-liability[ja]

Underkontrakter

Entreprenøren/leverandøren kan fritt inngå underkontrakter. Hvis en spesiell avtale er inngått som forbyr underkontrakter, kan ikke underkontrakter inngås.

Godtgjørelse, oppsigelse, ansvar for mangler, og spesielle avtaler i semi-fiduciære kontrakter

En semi-fiduciær kontrakt er en avtale der en part (leverandøren) er betrodd av en annen part (brukeren) for å utføre administrative oppgaver. Leverandøren har en plikt til å utøve sine evner og utføre oppgavene på en rasjonell måte, i henhold til plikten til en god forvalter. Med andre ord, det handler om å “gjøre sitt beste”.

Et typisk eksempel er medisinsk behandling, hvor det ikke er ansvar for å oppnå helbredelse, men det er en forpliktelse til å tilby en behandlingsprosess som er over standardnivået.

En stor forskjell fra kontraktsarbeid er at det ikke er nødvendig å ta ansvar for resultatet av arbeidet.

Godtgjørelse

I motsetning til kontraktsarbeid, kan leverandøren motta betaling selv om arbeidet ikke er fullført, så lenge administrasjonen er riktig utført. Hvis oppdraget avsluttes midt i utførelsen på grunn av årsaker som ikke kan tilskrives leverandøren, kan leverandøren kreve betaling i forhold til den allerede utførte ytelsen.

Det skal bemerkes at i endringene i Obligasjonsloven (japansk Obligasjonslov) som ble kunngjort i 2017 (trådte i kraft i april 2020), er det nå en bestemmelse som sier at selv i semi-fiduciære kontrakter, kan det være tilfeller der betaling blir gjort for oppnådde resultater, og i slike tilfeller kan betaling generelt kreves etter at resultatene er fullført.

Det er en annen artikkel som forklarer i detalj om det er mulig å øke den fastsatte betalingen basert på utviklingsprosessen for systemet.

https://monolith.law/corporate/increase-of-estimate[ja]

Oppsigelse

Selv om det ikke er noen mislighold fra den andre parten, kan både brukeren og leverandøren, i motsetning til kontraktsarbeid, si opp kontrakten når som helst.

Hvis en spesiell avtale er inngått som sier at den ikke kan avsluttes med mindre det er mislighold fra den andre parten, vil det ikke være noen risiko for at den blir avsluttet uten grunn når som helst, som nevnt ovenfor.

Det er en annen artikkel som forklarer i detalj de juridiske problemene når systemutviklingen blir avbrutt på grunn av brukerens omstendigheter.

https://monolith.law/corporate/interrruption-of-system-development[ja]

Ansvar for mangler

Det er ingen bestemmelser om ansvar for mangler, i motsetning til kontraktsarbeid. “Ansvar for mangler” og “inspeksjon” som nevnt tidligere, er begreper som bare dukker opp i kontraktsarbeid. Imidlertid har leverandøren en plikt til å “gjøre sitt beste”, og hvis de ikke utfører oppgavene på en rasjonell måte, kan det være risiko for krav om erstatning for mislighold eller oppsigelse.

Spesielt for leverandører i systemutvikling, er det forpliktelser som prosjektledelsesplikt.

Re-oppdrag

I motsetning til kontraktsarbeid, kan leverandøren generelt ikke re-oppdra. Hvis du vil re-oppdra, inngår du en spesiell avtale om det.

Denne delen er ofte et problem i praksis, og krever forsiktighet. Hvis du inngår en kontrakt for et semi-fiduciært utviklingsprosjekt uten en spesiell avtale om tillatelse til re-oppdrag, basert på vurderingen at “siden det er systemutvikling, bør re-oppdrag være mulig med mindre det er spesifikt angitt”, kan du ende opp i en situasjon der “det faktum at du re-oppdraget” i seg selv kan bli sagt å være et brudd på kontrakten.

Det er også forpliktelser som brukeren, som er bestiller, må oppfylle

Det skal bemerkes at diskusjonen så langt hovedsakelig har handlet om forpliktelsene som leverandøren, som er mottakeren, må oppfylle. Imidlertid, i scenarier med systemutvikling som krever mange hender og mye tid, pålegges det også en viss “samarbeidsplikt” for brukeren, som er bestilleren. Vi forklarer dette punktet i detalj i en separat artikkel.

https://monolith.law/corporate/user-obligatory-cooporation[ja]

Hvilken skal du velge: kontrakt for utførelse av arbeid eller kontrakt for delvis delegasjon av arbeid?

Hva er fordelene og ulempene med kontrakter for utførelse av arbeid og delvis delegasjon av arbeid?

Fordeler og ulemper for utviklingsfirmaer/leverandører

For utviklingsfirmaer/leverandører er en fordel med å velge en “kontrakt for utførelse av arbeid” at hvis de klarer å redusere antall involverte personer og gjøre jobben godt, kan de tjene mer enn med delvis delegasjon. I motsetning til delvis delegasjon, er utførelse av arbeid forpliktet til “å fullføre jobben”, noe som betyr at så lenge jobben er fullført, har de oppfylt sin forpliktelse, uavhengig av hvor mye de har klart å redusere kostnadene ved å redusere antall personer eller effektivisere arbeidet.

Ulempene er:

  • De kan ikke garantere å motta betaling før jobben er fullført
  • Hvis det oppstår uforutsette arbeidstimer for å fullføre arbeidet som oppfyller kravene, kan de ende opp med å bære kostnadene for ekstra arbeid og potensielt gå i minus
  • De bærer ansvaret for mangler
  • Hvis det oppstår uforutsette arbeidstimer for å fullføre arbeidet som oppfyller kravene, kan de ende opp med å bære kostnadene for ekstra arbeid og potensielt gå i minus
  • De bærer ansvaret for mangler

Dette er noen av punktene.

Fordelene med å velge en “kontrakt for delvis delegasjon av arbeid” er som følger:

  • De kan motta betaling selv om jobben ikke er fullført
  • De kan få dekket kostnadene for økte arbeidstimer
  • De trenger ikke å bære det tunge ansvaret for å fullføre jobben og lage noe uten mangler
  • I motsetning til kontrakter for utførelse av arbeid, er delvis delegasjon av arbeid forpliktet til “å gjøre en innsats som tilsvarer betalingen”, noe som gjør det lettere å forutsi kostnadene for å oppfylle denne forpliktelsen på forhånd

Fordeler og ulemper for bestillere/brukere

For bestillere/brukere er fordelene med å velge en “kontrakt for utførelse av arbeid” som følger:

  • De trenger ikke å betale før jobben er fullført (de kan få tilbakebetalt selv om de har betalt på forhånd)
  • Beløpet de skal betale er fast, så de trenger ikke å bære kostnadene for økte arbeidstimer på grunn av ekstra arbeid, etc.

Ulempen er at de kan bli presentert med et høyt estimat for å unngå risikoen for tap.

Fordelen med å velge en “kontrakt for delvis delegasjon av arbeid” er at de kan forvente et lavere estimat enn med kontrakter for utførelse av arbeid. Ulempen er at de ikke kan pålegge delegatet/leverandøren ansvaret for å fullføre jobben, og hvis det oppstår uforutsette arbeidstimer, kan de ende opp med å bære kostnadene for ekstra arbeid og økte arbeidstimer.

Rettspraksis

I rettspraksis har det vært tilfeller der kontrakter ble vurdert som delvis delegasjon av arbeid opp til bekreftelsen av kravdefinisjonen og grunnleggende design, og som kontrakter for utførelse av arbeid for arbeid fra etter grunnleggende design til enhetstesting.

Hvilken type kontrakt bør inngås, kontrakt for utførelse av arbeid eller kontrakt for delvis delegasjon av arbeid?

Det kan være aktuelt å inngå en kontrakt av typen modellkontrakt avhengig av prosessen, men det bør avgjøres og forhandles basert på individuelle omstendigheter i hver bedrift, fra både et forretningsmessig og juridisk perspektiv, som vanskelighetsgraden og innholdet i utviklingsmålet, det beløpet de ønsker å motta/kan forberede, den andre partens intensjoner og maktforholdet mellom de to partene, og om de i det hele tatt kan forestille seg det ferdige produktet og beskrive det i kontrakten.

For juridiske problemer og punkter som bør vurderes i tilfelle av manglende betaling, se følgende artikkel for en detaljert forklaring.

https://monolith.law/corporate/no-payment-by-user[ja]

Kriterier for å skille mellom kontrakt og underkontrakt

Hva er bestemmelsen av kontraktens natur?

“Å bestemme om kontrakten er en kontrakt eller en underkontrakt” er et spørsmål som oppstår i hvilke situasjoner, og hva slags problem er det?

Hvis det ikke er noen spesifikk avtale mellom partene om hvorvidt den aktuelle virksomheten (eller kontrakten) er en kontrakt eller en underkontrakt, det vil si at det ikke er inngått noen spesiell avtale, og denne klausulen er ikke angitt i kontrakten, hvilken type kontrakt som er definert i den japanske sivilloven vil bli anvendt, vil være basert på en etterfølgende vurdering av “hvilken type kontrakt er det”, og denne vurderingen vil bli gjort basert på visse kriterier.

Dette er hva det betyr.

For øvrig, dette er et problem med bevisstheten om at

  1. Det er en forutsetning at en kontrakt om systemutvikling er inngått
  2. Er denne kontrakten en kontrakt eller en underkontrakt

Men før dette problemet er det et problem med “Er det i det hele tatt en kontrakt om systemutvikling?”. Jeg forklarer dette punktet i detalj i en annen artikkel.

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

Og, som nevnt i punkt 2 ovenfor, forutsatt at systemutviklingen er etablert, hvilken kontrakt det er, vil avgjøre hvem av partene som skal bære en urimelig stor sum penger, og det vil bli et stort problem.

Det er ikke uvanlig at det ikke er angitt “kontrakt” eller “underkontrakt” i kontrakten, selv om det er angitt, er substansen forskjellig, og det er en misforståelse mellom partene. Derfor vil jeg forklare kriteriene for å skille mellom kontrakt og underkontrakt.

Kontraktens natur bestemmes ved å ta hensyn til forskjellige elementer

For å bestemme kontraktens natur, ser vi på hele kontrakten, og om formålet er “å levere det ferdige produktet” eller om leverandøren “utfører arbeidet på en rasjonell måte”. Det er et poeng om prosjektet har gått fremover med et visst konkret innhold av det produktet som skal fullføres.

Vi vil bestemme kontraktens natur ved å ta hensyn til følgende elementer.

Utviklingsselskapets prestasjoner

Hvis det er en historie med å lage systemer av samme grad eller høyere, er det sannsynlig at det vil bli dømt at “det var planlagt å fullføre det naturlig, det var en plikt å fullføre det, og det var en avtale om å betale for det ved ferdigstillelse”, og det vil være mer som en kontrakt.

Er målet på prosesskartet “fullføring”?

Hvis det er fullført, er det sannsynlig at det vil bli dømt at “det var en plikt å fullføre det”, og det vil være mer som en kontrakt.

Klarhet i innholdet av produktet i kontraktens innhold / beskrivelse på kontrakten

Jo klarere, jo mer sannsynlig er det å bli dømt at “det var planlagt å fullføre noe med klare krav”, og det vil være mer som en kontrakt.

Er betalingen basert på en enhetspris?

Hvis ja, er det sannsynlig at det vil bli dømt at “det var en forutsetning at betalingen ville oppstå ved ferdigstillelse, og det var en plikt å fullføre det”, og det vil være mer som en kontrakt.

Er betalingen etter fullføring?

Hvis ja, er det sannsynlig at det vil bli dømt at “det var en plikt å fullføre det”, og det vil være mer som en kontrakt.

Forekomst av aksept, defektsgaranti, og garantiklausuler

Hvis det er, er det sannsynlig at det vil bli dømt at “det var en plikt å fullføre det” og “aksept, defektsgaranti, og garantiklausuler ble forberedt på den forutsetningen”, og det vil være mer som en kontrakt.

Forekomst av kontrakt eller underkontrakt ordlyd

Selvfølgelig er ordlyden også en viktig hensyn. Men det er ikke bare ordene “kontrakt” eller “underkontrakt” som bestemmer, så du må være forsiktig med hvordan du skriver kontrakten.

I tillegg blir denne vurderingen gjort ikke bare på grunnlag av kontrakten, men også på grunnlag av bevis som møtereferater som ble opprettet i løpet av systemutviklingen. Jeg forklarer viktigheten av møtereferater i detalj i følgende artikkel.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Oppsummering

“Kontrakt” og “semi-kommisjon” kan virke like, men de har helt forskjellige juridiske effekter. Det er tryggere å søke ekspertvurdering når du inngår en kontrakt. Vårt firma har avansert kunnskap om saker som systemutviklingskontrakter. Ikke nøl med å kontakte oss for en uformell samtale.

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.

Category: IT

Tag:

Tilbake til toppen