Systemutvikling er vanligvis en langvarig prosess, og det kan ofte kreves endringer i spesifikasjoner eller implementering av nye funksjoner flere ganger. For leverandørene som tar på seg arbeidet, kan dette noen ganger føre til en situasjon hvor det er vanskelig å se slutten. For slike leverandører kan spørsmålet om “hva som må gjøres og til hvilken grad for å anse arbeidet som fullført” bli en alvorlig bekymring.
Videre kan det sies at systemutvikling ofte utføres under en oppdragsavtale, som er en kontrakt som har som mål å “fullføre arbeidet”.
I denne artikkelen vil vi forklare fra et juridisk perspektiv, “på hvilket tidspunkt og til hvilken grad systemutvikling må være fullført for å anses som ferdig”.
Hva innebærer fullføring av systemutvikling?
Hva fullføring av systemutvikling betyr for teknikere
På en systemutviklingsarbeidsplass, hvis man spør “Når er systemutviklingen fullført?”, vil svaret generelt være noe som “Når testfasen er avsluttet og produktet er levert.” Den vanlige prosessen for systemutvikling starter med kravspesifikasjon, som innebærer å identifisere nødvendige funksjoner, etterfulgt av utarbeidelse av ulike designspesifikasjoner, implementering av programmet, og til slutt testfasen for å bekrefte at alt fungerer korrekt. Prosessen avsluttes med brukerens akseptanse.
Derfor, fra en teknikers perspektiv, er det vanlig å forstå “fullføring av systemutvikling” som “godkjent akseptanse”.
Hva fullføring av systemutvikling betyr fra et juridisk perspektiv
På den annen side, fra et juridisk perspektiv, når man spør når systemutviklingen er fullført, vil diskusjonen naturligvis dreie seg om når leverandøren har oppfylt sine juridiske forpliktelser i henhold til kontrakten. Kontrakter for systemutvikling klassifiseres generelt som enten oppdragskontrakter eller konsulentkontrakter.
For en detaljert forklaring av forskjellene mellom disse to kontraktstypene, se artikkelen ovenfor. Når det gjelder fullføring av systemutvikling, det vil si oppfyllelse av leverandørens forpliktelser, er de relevante lovbestemmelsene som følger:
Oppdragskontrakt: Japansk sivilrett §632 §632 En oppdragskontrakt trer i kraft når en part forplikter seg til å fullføre et arbeid, og den andre parten forplikter seg til å betale for resultatet av dette arbeidet. Konsulentkontrakt: Japansk sivilrett §643 §648 1. En konsulent kan ikke kreve betaling fra oppdragsgiveren uten en spesiell avtale. 2. En konsulent kan kreve betaling etter å ha utført oppdraget, med mindre det er avtalt betaling basert på tidsperioder, i hvilket tilfelle §624(2) gjelder. 3. Hvis oppdraget avsluttes før fullføring av grunner som ikke kan tilskrives konsulenten, kan konsulenten kreve betaling i forhold til det utførte arbeidet.
Fullføring av systemutvikling er et problem i oppdragskontrakter
Generelt, i konteksten av systemutvikling, er det oppdragskontrakter som skaper problemer når det gjelder “når arbeidet er fullført”. Konsulentkontrakter fokuserer mer på prosessen enn på spesifikke resultater. I henhold til loven kan en konsulent kreve betaling selv om det forventede resultatet ikke er oppnådd, så lenge arbeidet er utført på en passende måte (§648(2)). Hvis oppdraget avsluttes før fullføring av grunner som ikke kan tilskrives konsulenten, kan konsulenten kreve betaling i forhold til det utførte arbeidet (§648(3)). Man kan si at oppdragskontrakter er “resultatorienterte”, mens konsulentkontrakter er “prosesorienterte”.
Derfor, i konsulentkontrakter, er det juridiske problemet ofte “omsorgsplikt” i utførelsen av det tildelte arbeidet. Dette innebærer å vurdere når det er mulig å holde konsulenten ansvarlig for brudd på omsorgsplikten, gitt den høye tilliten som er plassert i dem.
På den annen side, i oppdragskontrakter, er “fullføring av arbeidet” det viktigste. Hvis arbeidet som skal fullføres ikke er fullført, kan ikke leverandøren kreve betaling. Men hvis arbeidet er fullført, er det ingen grunn til å fokusere på mellomliggende stadier. Derfor kan spørsmålet om “når systemutviklingsprosjektet er fullført” i hovedsak oversettes til en juridisk tolkning av “fullføring av arbeidet” i oppdragskontrakter.
Når er arbeidet fullført i systemutvikling?
Hva er kravene for å kunne si at arbeidet er fullført?
Så, når kan vi konkret anse at arbeidet er fullført? La oss se på tidligere rettsavgjørelser om dette emnet.
Rettsavgjørelser om fullføring av arbeid
I den følgende rettsavgjørelsen ble det oppdaget problemer med systemet som leverandøren hadde levert, som for eksempel behandlingstid og kommunikasjonskostnader. Selv om slike problemer ble funnet, var hele utviklingsprosessen fullført, og spørsmålet var om dette kunne anses som “arbeidets fullføring”. Resultatet var at arbeidet ble ansett som fullført.
Japansk sivilrettslov (民法) § 632 og § 633 fastsetter at tidspunktet for betaling av vederlag til entreprenøren er når entreprenøren har fullført arbeidet og overlevert arbeidsobjektet til bestilleren. På den annen side fastsetter § 634 at hvis arbeidsobjektet har mangler, er entreprenøren ansvarlig for disse (første ledd), og inntil entreprenøren har oppfylt sitt ansvar for manglene, har bestilleren rett til å holde tilbake betalingen (andre ledd). Ifølge disse bestemmelsene i japansk sivilrettslov, skiller loven mellom tilfeller der arbeidsresultatet er ufullstendig på grunn av mangler i arbeidsobjektet og tilfeller der arbeidet ikke er fullført, og det forstås at selv om arbeidsobjektet har mangler, enten de er skjulte eller åpenbare, anses arbeidet som fullført. Derfor, om entreprenøren har fullført arbeidet eller ikke, bør vurderes ut fra om arbeidet er fullført til siste trinn som opprinnelig avtalt i kontrakten, og bestilleren kan ikke nekte å betale vederlaget bare fordi arbeidsobjektet har mangler.
I den ovennevnte dommen ble det vurdert at “arbeidets fullføring” er oppfylt så lenge den siste fasen av systemutviklingen er fullført. Som en løsning på mangler i systemet som leverandøren har laget (ofte referert til som “mangler” i juridisk terminologi), finnes det et eget system for ansvar for mangler.
Derfor, selv om begrepet “arbeidets fullføring” tolkes noe bredt, vil det ikke nødvendigvis føre til urettferdighet for brukeren. Oppsummert kan dette uttrykkes som følger:
【Forpliktelse i en entreprisekontrakt = Arbeidets fullføring = Fullføring av alle faser】 ＝＝＝＝＝＝＝＝＝＝＝ Hvis arbeidet ikke er fullført… ↓ 【Ansvar for kontraktsbrudd】 ＝＝＝＝＝＝＝＝＝＝＝ Hvis arbeidet er fullført, men det er mangler… ↓ 【Erkjenne oppfyllelse av forpliktelsen, men ansvar for mangler】
Den ovennevnte rettsavgjørelsen viser hvordan man kan skille mellom disse problemene.
Videre, når det gjelder “arbeidets fullføring”, kan vi også vurdere det fra perspektivet “brukerens godkjenning”. Vi har en egen artikkel som forklarer juridiske problemer når brukerens godkjenning ikke går som planlagt.
I en oppdragsavtale kan man kreve betaling etter at arbeidet er anerkjent som fullført.
Innen systemutvikling, når “arbeidets fullføring” er anerkjent, betyr det at forpliktelsen er oppfylt, og man kan ikke lenger holdes ansvarlig for mislighold av forpliktelser. I en oppdragsavtale kan man ikke kreve betaling med mindre arbeidet er fullført, og selv om det er avtalt forskuddsbetaling, må disse i utgangspunktet tilbakebetales. På den annen side, hvis det er anerkjent at arbeidet er fullført, vil leverandøren kun være ansvarlig for mangelsansvar og kvalitetsgarantier i henhold til kontrakten.
At leverandøren frigjøres fra misligholdsansvar betyr at muligheten for at brukeren kan heve kontrakten blir betydelig redusert. Dette er fordi heving av kontrakten basert på mangelsansvar er begrenset til tilfeller hvor kontraktens formål ikke kan oppnås. Hvis kontrakten heves, mister leverandøren også retten til å kreve betaling (med andre ord, de vil ikke motta noen betaling), noe som ofte fører til tvister om “arbeidets fullføring” i praksis.
For en detaljert forklaring om “heving” av kontrakter innen systemutvikling, se artikkelen nedenfor.
Hvordan håndtere endringer i spesifikasjoner og tillegg i utvikling
For leverandører kan det oppstå situasjoner der de allerede har oppfylt de opprinnelige spesifikasjonene, men blir bedt om å gjøre endringer eller legge til funksjoner, noe som gjør det vanskelig å avslutte arbeidet. I slike tilfeller oppstår spørsmålet om når man skal avslutte systemutviklingen. En detaljert forklaring på dette finner du i artikkelen nedenfor.
Vær oppmerksom på endringer i den japanske sivilretten
Reglene for ansvar for mangler i kontrakter har tradisjonelt vært komplekse og vanskelige å forstå, og dette området er sterkt påvirket av endringer i den japanske sivilretten. Hvordan man bør tolke “mangler” i lys av disse endringene, er detaljert forklart i artikkelen nedenfor.
I denne artikkelen har vi forklart veien fra systemutviklingsprosjekter, som ofte kan virke som om de “ikke har noen utvei”, til å knytte dem til det juridiske konseptet “fullføring av arbeid”. Selv om utgangen for hvert enkelt prosjekt kan variere avhengig av utviklingskravene, er det ikke uvanlig at det juridiske konseptet “fullføring av arbeid” kan være en veiledende tråd når det oppstår tvister rundt disse punktene.
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.
