Prosjektet med systemutvikling er på en måte alltid en kamp mot tidsfrister. Når det gjelder “tidsfrister” i systemutvikling, kan vi fra et juridisk perspektiv vurdere “risikoen som blir tydelig hvis tidsfristen ikke overholdes”.
I denne artikkelen vil vi forklare i hvilke tilfeller en slik “forsinkelse i tidsfristen” behandles som en forsinkelse i oppfyllelsen og fører til juridisk ansvar som mislighold av forpliktelser.
Hva er en leveringsfrist i systemutvikling?
Generell forståelse av leveringsfrist
Generelt sett refererer “leveringsfrist” til datoen da et produkt skal leveres til kunden. Selv i utviklingsmiljøer hvor uforutsette problemer ofte oppstår, er det ikke uvanlig at leveringsfristen må overholdes strengt. Når det er en maktubalanse mellom bestiller og leverandør, er det ofte en enda sterkere tendens til å overholde leveringsfristen. I noen tilfeller kan det også være at man gir rabatter for forsinkelser eller utfører ekstra arbeid uten å kreve betaling. Uansett er leveringsfristen generelt sett viktig for å opprettholde tillitsforholdet med forretningspartnere.
Vi har forklart konseptet “fullføring av arbeid” og leveringsfrist i henhold til japansk lov i en annen artikkel.
Fra et juridisk perspektiv oppstår leverandørens plikt (gjeld) til å levere systemet når kontrakten inngås mellom leverandøren og brukeren. Leveringsfristen er den tidsbegrensningen som settes for å oppfylle denne plikten. Forsinkelse i leveringsfristen anses som en form for mislighold, nemlig forsinket oppfyllelse. Med andre ord, hvis forsinkelsen skyldes leverandørens forsett eller uaktsomhet, vil leverandøren være ansvarlig for mislighold på grunn av forsinket oppfyllelse (japansk sivil lov § 412).
1. Når det er en fastsatt frist for oppfyllelse av gjeld, er skyldneren ansvarlig for forsinkelse fra det tidspunktet fristen utløper. 2. Når det er en usikker frist for oppfyllelse av gjeld, er skyldneren ansvarlig for forsinkelse fra det tidspunktet han blir klar over at fristen er utløpt. 3. Når det ikke er fastsatt noen frist for oppfyllelse av gjeld, er skyldneren ansvarlig for forsinkelse fra det tidspunktet han mottar en anmodning om oppfyllelse.
Japansk sivil lov § 412
Å være “ansvarlig” i denne sammenhengen betyr enkelt sagt erstatningsansvar.
Når skyldneren ikke oppfyller sin gjeld i henhold til hovedinnholdet i forpliktelsen, kan kreditor kreve erstatning for skaden som oppstår som følge av dette. Det samme gjelder når skyldneren på grunn av forhold som kan tilskrives ham, ikke kan oppfylle forpliktelsen.
Japansk sivil lov § 415
Videre, hvis brukeren gir leverandøren en “rimelig periode” for å levere systemet, og leverandøren fortsatt ikke leverer innen denne perioden, kan brukeren også heve kontrakten.
Når en av partene ikke oppfyller sin forpliktelse, kan den andre parten, etter å ha gitt en rimelig frist for oppfyllelse, heve kontrakten hvis oppfyllelse ikke skjer innen denne fristen.
Japansk sivil lov § 541
For en generell forklaring på opsjonen “heving” i slike tilfeller, se følgende artikkel.
Ikke alle forsinkelser i leveranser utgjør juridisk mislighold
Hva er kriteriene og betingelsene for at en forsinkelse kan anses som juridisk mislighold?
Det faktum at en leveranse er forsinket, betyr ikke nødvendigvis at det er snakk om juridisk mislighold. For at en forsinkelse skal kunne anses som juridisk mislighold, må flere betingelser være oppfylt, som vist nedenfor.
・Leveringsdatoen må være en del av kontrakten og ikke bare en veiledende dato, og den må være avtalt mellom partene. → Forsinkelsen kan kun anses som juridisk mislighold hvis leveringsdatoen er en juridisk forpliktelse.
・Forsinkelsen må skyldes leverandørens forsett eller uaktsomhet, og leverandøren må kunne holdes ansvarlig. → Systemutvikling krever samarbeid mellom både leverandør og bruker. Hvis forsinkelsen skyldes brukerens manglende samarbeid, kan ikke leverandøren holdes ansvarlig for forsinkelsen.
Ettersom systemutvikling vanligvis er et prosjekt hvor både brukeren og leverandøren har forpliktelser, kan det hende at begge parter blir ansett for å ha brutt sine forpliktelser, og at erstatningskravene blir motregnet.
Videre, nær leveringsdatoen, vil det vanligvis bli gjennomført en “inspeksjon” av leveransen. Vi har dekket inspeksjon i detalj i en annen artikkel. Her forklarer vi situasjoner hvor leveransen ikke kan fullføres fordi brukeren ikke godkjenner inspeksjonen.
Hovedpoenget er at “forsinkelse i leveransen = juridisk mislighold” ikke er så enkelt. Årsakene til forsinkelsen kan variere, enten det er leverandørens eller brukerens feil. Det er en betydelig forskjell mellom en formell forsinkelse og en faktisk forpliktelsesbrudd.
Rettseksempler om forsinkelse i oppfyllelse
Vi vil forklare en rettsavgjørelse der det ble diskutert om det var mulig å forfølge ansvar for kontraktsbrudd på grunn av forsinkelse i leveransen.
La oss se på en rettsavgjørelse der det ble diskutert om det var mulig å forfølge ansvar for kontraktsbrudd basert på forsinkelse i oppfyllelse, som følge av forsinkelse i leveransen. Selv om det er en tvist om leveringsfristen, er det viktig å organisere saken basert på grunnleggende prinsipper for systemutvikling, som “brukerens samarbeidsplikt” og “prosjektledelsesplikt”, noe som ikke er annerledes enn andre tvister.
Eksempel der forsinkelse i oppfyllelse ble delvis tilskrevet brukerens brudd på samarbeidsplikten
I den siterte dommen nedenfor, ble det reist søksmål av brukeren som saksøker på grunn av forsinkelse i leveransen fra leverandøren. Søksmålet ble delvis akseptert i retten, men samtidig ble det påpekt at brukerens manglende samarbeid også var en medvirkende årsak, og 40 % av skadene som følge av forsinkelsen ble tilskrevet brukeren.
Etter å ha vurdert saken, kan det sies at saksøker brukeren ikke utførte passende samarbeid ved å ikke løse de utestående spørsmålene som ble reist av saksøkte innen fristen. Imidlertid, når det gjelder saksøker brukerens krav om brudd på samarbeidsplikten fra saksøkte vedrørende tillegg eller endringer i funksjonaliteten, er det anerkjent at saksøker brukeren krevde tillegg og endringer som ikke var forutsatt i den opprinnelige designspesifikasjonen, men dette utgjør ikke et brudd på samarbeidsplikten fra saksøker brukerens side, og saksøktes påstand er derfor ubegrunnet. Videre, når det gjelder saksøker brukerens overdrevne krav, er det ikke anerkjent at saksøker brukeren fremsatte overdrevne krav i forhold til kontraktsbeløpet for systemutviklingsavtalen, og påstanden er derfor ubegrunnet. Snarere kan det sies at saksøkte hadde upassende prosjektledelse ved å ikke ha oversikt over antall prosesser (per juli-august samme år) før januar 1999 (Heisei 11) og ved å foreslå urimelige tilleggskostnader og reduksjon av prosesser etter 31. mai samme år.
Tokyo distriktsdomstol, 10. mars 2004 (Heisei 16)
Ovennevnte dom anerkjente forsinkelse i oppfyllelse fra leverandørens side, men påpekte også at en del av årsaken lå i brukerens manglende løsning av de utestående spørsmålene som ble reist av leverandøren, og reduserte brukerens krav med 60 %. Dette er en behandling kjent som “medvirkningsansvar”, som også brukes i trafikkulykker der offeret har en del av skylden.
I hele dommen, inkludert innholdsfortegnelsen, dukker begrepet “samarbeidsplikt” opp mer enn 40 ganger. Som et juridisk spørsmål var det snarere skillet mellom leverandørens prosjektledelsesplikt og brukerens samarbeidsplikt som var essensen.
Eksempel der forsinkelse i oppfyllelse ble fullstendig anerkjent
Nedenfor er en dom der leverandørens ansvar for forsinkelse i leveransen ble fullstendig bevist, og forsinkelse i oppfyllelse ble anerkjent som kontraktsbrudd. I denne saken ble det reist søksmål av leverandøren etter at brukeren kansellerte kontrakten like før systemet var ferdig, men brukeren hevdet at årsaken var forsinkelse i leveransen.
Det kan ikke benektes at saksøkte ga ulike endringsinstruksjoner for designsystemet, noe som forsinket ferdigstillelsen til en viss grad. Spesielt ga saksøkte endelige endringsinstruksjoner den 23. juni 2005 (Heisei 17), så det kan ikke tilskrives saksøker at funksjonen for automatisk beregning av detaljer for side steiner ikke var ferdig. Imidlertid ble de andre endringsinstruksjonene fra saksøkte gitt innen begynnelsen av april samme år, og det er ingen grunn til å tro at planen for ferdigstillelse av designsystemet ble endret (bortsett fra delen som ble endret den 23. juni samme år). Det er ikke anerkjent at saksøker hadde ferdigstilt designsystemet til et nivå som muliggjorde faktisk drift innen slutten av juni 2005, bortsett fra delen som ble endret den 23. juni samme år, og det er anerkjent at viktige deler av systemet, som bildevisning og søkefunksjon, ikke var ferdige. (Utelatt) Det kan sees at saksøker ikke hadde tilstrekkelig styring av arbeidsprosedyrene knyttet til systemutviklingen. Basert på dette, kan det ikke anerkjennes at hovedårsaken til at saksøker ikke overholdt leveringsfristen var saksøktes instruksjoner, og det kan ikke anerkjennes at saksøker ikke hadde noe ansvar.
Tokyo distriktsdomstol, 16. februar 2007 (Heisei 19)
I denne dommen ble det påpekt at endringsinstruksjoner ble gitt omtrent en uke før leveringsfristen, og at det ikke kunne tilskrives leverandøren at denne funksjonen ikke var ferdig. Imidlertid,
Endringsinstruksjoner gitt flere måneder tidligere var fortsatt ikke fulgt opp
Etter at instruksjonene ble gitt, sendte leverandøren e-post med forventet ferdigstillelsesdato
De uferdige delene var viktige deler av systemet, som bildevisning og søkefunksjon, og manglende oppfølging av disse utgjorde et brudd på prosjektledelsesplikten
Basert på dette ble forsinkelse i oppfyllelse anerkjent som kontraktsbrudd.
Hva vi kan lære av begge dommene
Basert på begge dommene kan vi si at problemet med “leveringsfrist” i systemutvikling til syvende og sist handler om hvordan man trekker grensen mellom brukerens samarbeidsplikt og leverandørens prosjektledelsesplikt. Med andre ord, siden forsinkelse i oppfyllelse er en type kontraktsbrudd, blir spørsmålet om leverandøren har brutt noen plikter et sentralt tema. For å vurdere om de faktiske skadene som oppstod (dvs. brukerens tap som følge av forsinkelsen) kan tilskrives leverandøren, må man også vurdere hvordan man tolker brukerens samarbeidsplikt.
Oppsummering
Når man hører ordet “forsinkelse i oppfyllelse”, kan det ved første øyekast virke som en formell omskriving av “forsinkelse i levering”. Men forsinkelse i oppfyllelse er en type kontraktsbrudd. Derfor er det mer hensiktsmessig å forstå det som et “brudd på prosjektledelsesplikten”.
Problemet med “leveringsfrister” i systemutviklingsprosjekter bør ikke bare sees på som en overfladisk forsinkelse. Det er viktig å omformulere det som et spørsmål om leverandørens prosjektledelsesplikt og brukerens samarbeidsplikt.
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.
