Arbeidet med systemutvikling involverer mange mennesker både på brukersiden som bestiller og på leverandørsiden som mottar bestillingen. Derfor er det ikke lett å få alle til å gå i takt og fremme prosjektet sammen. Det sier seg selv at planlegging er ekstremt viktig i denne typen arbeid, men samtidig er det ikke alltid slik at brukeren som bestiller klarer å samle og formidle riktig informasjon kortfattet til leverandøren. Når utviklingsprosessen har kommet et stykke på vei, og det blir bedt om endringer i spesifikasjonene eller tillegg av funksjoner, er det svært viktig for leverandøren å vite om det er mulig å kreve ekstra betaling utover den opprinnelige kostnadsestimeringen.
Under hvilke omstendigheter anerkjenner japansk lov slike rettigheter? Og hvordan bestemmes beløpet for tillegg og justeringer av funksjoner? I denne artikkelen vil vi organisere og svare på disse ulike spørsmålene.
Når kan man si at det er snakk om tilleggsutvikling eller funksjonsjustering?
Ved systemutviklingsprosjekter er kontraktstypen vanligvis en entrepriseavtale eller en oppdragsavtale. Uansett hvilken av disse kontraktstypene det er snakk om, vil det som skal gjøres (plikter) og den tilhørende godtgjørelsen (rettigheter) være spesifisert i kontrakten. Derfor, hvis det legges til arbeid som ikke var inkludert i de opprinnelige arbeidsoppgavene som godtgjørelsen er basert på, kan dette betraktes som tilleggsutvikling eller funksjonsjustering. På den annen side, hvis arbeidet er inkludert i de opprinnelige spesifikasjonene, vil det bli behandlet som en del av den opprinnelige kontrakten.
For mer informasjon om forskjellene mellom entrepriseavtaler og oppdragsavtaler, se vår andre artikkel.
Hvis man derimot hevder at selv små justeringer av skrifttyper som vises på skjermen må spesifiseres på forhånd, og at disse også skal betraktes som tilleggsutvikling, kan dette i stor grad hindre smidige forretningsforhandlinger. Derfor er det ikke enkelt å trekke en klar grense når man tar hensyn til diskusjoner om slike detaljer i spesifikasjonene. Men hvis man skal gi en generell retningslinje, kan man si at:
Hvis spesifikasjonene er fastsatt, og ytterligere funksjoner blir pålagt etter dette
Hvis programmet allerede er implementert, og det blir pålagt endringer etter dette
kan slike krav ha en viss juridisk gyldighet.
Rettssak der det var omstridt om det kunne sies å være tilleggsutvikling eller funksjonsendring
Hva betyr “spesifikasjonsendring” i programvareutvikling?
Eksempel på godkjent tilfelle: Endring av spesifikasjoner etter grunnleggende design
Følgende tilfelle omhandler en endring av spesifikasjoner etter at de opprinnelige spesifikasjonene var fastsatt.
Programvareutvikling gjennomføres gjennom utviklingsfaser som inkluderer: ① kravdefinisjon, ② ekstern design, ③ intern design, ④ opprettelse av kildeprogram (programdesign, koding), ⑤ ulike tester (enhetstesting, integrasjonstesting, systemtesting) (utdrag) Opprinnelige spesifikasjoner (utdrag) realiseres gjennom arbeid etter intern design, og dette anses som omfanget av arbeidet som står i forhold til vederlagskravet i henhold til den aktuelle utviklingskontrakten. En forespørsel om endring av spesifikasjoner anses juridisk sett som et tilbud om en ny arbeidskontrakt som går utover omfanget av arbeidet i henhold til den opprinnelige kontrakten fra oppdragsgiveren. Hvis oppdragstakeren fullfører arbeidet knyttet til den ekstra oppdraget uten å presentere en tilleggspris og uten enighet om tilleggsprisen, anses det som om en ny arbeidskontrakt uten fastsatt pris er inngått mellom oppdragsgiveren og oppdragstakeren, og det er rimelig å tolke det som at en plikt til å betale rimelige tilleggskostnader for utviklingen oppstår.
Osaka distriktsdomstol, dom av 29. august Heisei 14 (2002)
Å forstå nøkkelord som “vederlagsforhold” og “ny kontrakt” er en inngangsport til å forstå denne dommen dypere.
For øvrig ble det i den nevnte dommen også påpekt et annet svært interessant punkt. Det ble fastslått at små justeringer som plassering av knapper og skrifttyper ikke faller inn under det som her kalles spesifikasjonsendringer. De relevante delene er som følger.
Imidlertid, i programvareutvikling, på grunn av dens natur, er det ikke vanlig at detaljer som skrifttyper og plassering av knapper på skjermen bestemmes i fasen for ekstern design. Med tanke på at slike detaljer vanligvis justeres i en viss grad gjennom møter mellom partene selv etter at spesifikasjonene er fastsatt, bør ikke krav om detaljering av spesifikasjoner anses som spesifikasjonsendringer.
Osaka distriktsdomstol, dom av 29. august Heisei 14 (2002)
I dommen ble det brukt et interessant begrep, “detaljering av spesifikasjoner”.
Tilfeller der noe som allerede var bestemt, ble endret i etterkant
Tilfeller der man bevisst unngikk å bestemme noe på forhånd og heller bestemte det underveis
Det kan sies at dommen viser at den juridiske behandlingen bør være forskjellig i slike tilfeller.
Andre eksempler på godkjenning
Andre saker som ble anerkjent som tilleggutvikling eller funksjonsendringer inkluderer:
Et tilfelle der antallet leverte programmer nesten doblet seg fra den opprinnelige planen (Tokyo tingrett, 22. april Heisei 17 (2005)).
Et tilfelle der arbeidstiden ble omtrent tredoblet (Tokyo tingrett, 22. januar Heisei 22 (2010)).
Ved å organisere det på denne måten, ser vi at forlengelse av arbeidstiden også kan betraktes som tilleggutvikling i vid forstand, og at denne tilnærmingen gir en viss juridisk beskyttelse.
「Enighet om tilleggsutvikling og økning av godtgjørelse」og「Etablering av den opprinnelige kontrakten」er separate problemer
Viktige punkter angående disse problemene er:
「Om en kontrakt (den opprinnelige kontrakten) for systemutvikling mellom de to selskapene i det hele tatt ble formelt etablert」
「Om en kontrakt for tilleggsutvikling (også) ble etablert i tillegg til den formelt etablerte systemutviklingen」
Rettsvesenets vurderingskriterier er forskjellige i disse situasjonene. Kort sagt, domstolene har en tendens til å:
Være strenge med hensyn til punkt 1 (de anerkjenner sjelden etablering av en kontrakt uten en skriftlig avtale)
Være relativt fleksible med hensyn til punkt 2 (de anerkjenner økning av godtgjørelse og lignende selv uten en skriftlig avtale om tilleggsutvikling)
Vi har forklart punkt 1 i detalj i en annen artikkel.
Negativt Eksempel: Tilfelle der det ble behandlet som inkludert i lignende oppdragsinnhold i henhold til japansk lov
På den annen side finnes det også rettsavgjørelser hvor økning i honorar ikke ble godkjent. I den siterte dommen nedenfor, ble det i en sak om systemutviklingskontrakt, etter at en oppdragsavtale ble inngått og innholdet i arbeidet ble endret, diskutert om en økning i honorar skulle godkjennes.
Stridsspørsmålene i denne saken er: (1) Hva er innholdet i arbeidet som saksøker har påtatt seg i henhold til den aktuelle kontrakten? (2) Ble det inngått en avtale mellom saksøker og saksøkte om å utvide omfanget av arbeidet og øke betalingen? (utdrag)
Opprinnelig er den aktuelle kontrakten en oppdragsavtale hvor det ble avtalt at beløpet skulle være den faste godtgjørelsen for saksøkers påtatte arbeid (oppdrag), og antall steg, enhetspriser osv. er kun interne dokumenter for saksøker ved beregning av oppdragsbeløpet, og økning i antall steg osv. har ingen relevans til oppdragsbeløpet. (utdrag)
Som fastslått ovenfor, ble saksøkers påtatte arbeid endret den 25. februar i Showa 62 (1987), og begrenset til systemadministrasjon, beregning av oppdragskostnader og deler av verktøyene, mens resten ble håndtert av saksøkte. Likevel forblir saksøkers arbeid innenfor rammen av utviklingsarbeidet i henhold til den opprinnelige kontrakten, og godtgjørelsen for dette arbeidet er fullt dekket av det avtalte oppdragsbeløpet i den opprinnelige kontrakten.
Tokyo distriktsdomstol, dom av 12. juni Heisei 7 (1995)
I den aktuelle dommen ble det vurdert at selv om innholdet i arbeidet som ble påtatt av leverandøren hadde blitt endret, forble utviklingsinnholdet innenfor rammen av den opprinnelige kontrakten, og skulle derfor dekkes av det opprinnelig avtalte honoraret.
Til syvende og sist, vurderes det at for å kunne kreve ekstra honorar for arbeid som ikke er inkludert, må man ta hensyn til hva slags arbeid honoraret opprinnelig ble fastsatt for.
Videre, hva slags arbeid honoraret opprinnelig var ment å dekke, vurderes ikke bare ut fra kontrakten, men også fra møtereferater og lignende dokumenter. Viktigheten av møtereferater er detaljert forklart i artikkelen nedenfor.
Hvordan bestemmes godtgjørelsen for tilleggsutvikling og funksjonsendringer?
Godtgjørelsen beregnes ved å bekrefte forholdene rundt tilleggs- og endringsutvikling av systemet.
Det er ikke uvanlig at spesifikasjoner som en gang ble ansett som endelige, endres senere i systemutviklingsprosjekter. Hver gang dette skjer, er det ikke realistisk å forberede nye skriftlige kontrakter og fortsette kontraktsarbeidet. Hvis man kan bekrefte de nye spesifikasjonene for tilleggs- og endringsarbeid og inngå en memorandum, er det greit. Men hva gjør man når prosjektet stopper opp uten å kunne gjennomføre slike prosedyrer? Hvordan beregner man godtgjørelsen i slike tilfeller?
En relevant paragraf å referere til i slike tilfeller er den følgende fra den japanske handelsloven (商法) § 512 (understreket av forfatteren).
Japansk handelslov § 512: Når en handelsmann utfører en handling for en annen innenfor rammen av sin virksomhet, kan han kreve en rimelig godtgjørelse.
Spørsmålet er hvor mye denne “rimelige godtgjørelsen” i paragrafen faktisk utgjør i konkrete situasjoner. Tidligere rettsavgjørelser viser at man ofte bruker arbeidsmengde, volum eller tidsperiode som grunnlag for å beregne kostnadene. Dette skyldes at systemutvikling i sin natur er en tjenesteytende virksomhet, hvor hovedkostnaden er lønnskostnader.
Til tross for den abstrakte formuleringen “rimelig godtgjørelse” i den japanske handelsloven, er det ikke nødvendigvis komplisert å estimere tilleggsbetalinger i slike sammenhenger. La oss se på noen rettsavgjørelser.
Case 1: Tilleggsbetaling basert på økt arbeidsmengde
Utviklingsarbeidet basert på endringen i spesifikasjonene anses å være 257,5 arbeidsdager. Ved å bruke samme utviklingskostnad per arbeidsdag som i den opprinnelige utviklingskontrakten, 32 500 yen per dag (65 000 yen per måned delt på 20 arbeidsdager), blir tilleggsutviklingskostnaden 8 368 750 yen.
Osaka distriktsdomstol, 29. august Heisei 14 (2002)
Nøkkelordet her er “per arbeidsdag”. Dette viser at man bruker arbeidsmengde som grunnlag for å beregne tilleggsbetalingen.
Case 2: Tilleggsbetaling basert på antall programmer
Ved å vurdere den rimelige godtgjørelsen inkludert tilleggene, og med tanke på at hovedkostnaden for utvikling av datasystemer er lønnskostnader som er proporsjonale med antall programmer, deles den opprinnelige kontraktsummen på 23 250 000 yen på 206 programmer, og multipliseres med 414 programmer, noe som gir en sum på 46 725 728 yen.
Tokyo distriktsdomstol, 22. april Heisei 17 (2005)
Selv om det er mange tall, er beregningen enkel. Man bekrefter enhetsprisen per program fra den opprinnelige kontrakten og bruker en enkel multiplikasjon “enhetspris × antall”.
Case 3: Tilleggsbetaling basert på tidsperiode
I kontrakten for tre måneder fra januar til mars Heisei 17 (2005) ble en godtgjørelse på 60 millioner yen fastsatt. For arbeidet fra april til september samme år, som inkluderte økt arbeidsmengde på grunn av semesterstart, anses en godtgjørelse på 120 millioner yen som rimelig.
Tokyo distriktsdomstol, 22. januar Heisei 22 (2010)
Denne avgjørelsen viser at man bruker en enkel proporsjonal beregning for å beregne tilleggsbetaling for forlenget periode.
Oppsummering
Som nevnt ovenfor, når vi ser på flere rettsavgjørelser, kan vi se visse mønstre og fellestrekk i den juridiske behandlingen av tilleggsbetaling for programmerere og ingeniører. Prinsipielt sett ser det ut til at man forsøker å beregne dette så enkelt som mulig, basert på relativt objektive indikatorer som medgått tid, formell arbeidsmengde (som leverte programmer), og arbeidstid eller -periode.
Strengt tatt, fordi man har mislyktes i å følge en nøyaktig prosedyre eller å estimere arbeidsmengden perfekt, oppstår behovet for slik tilleggsutvikling og funksjonsjusteringer. Derfor kan det virke litt tørt og kjedelig at tilleggsbetaling kun baseres på medgått tid, formell arbeidsmengde, eller arbeidstid. Men fra oppdragstakerens perspektiv, selv om man sikter mot å prioritere kundens interesser, er det meningsfullt fra et risikostyringsperspektiv at slike rettigheter også er juridisk anerkjent.
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.
