Mikä on työn valmistuminen järjestelmäkehityksen urakkasopimuksessa

Järjestelmäkehitys on yleensä pitkäaikainen prosessi, jossa saatetaan vaatia useita kertoja eritelmien muutoksia tai lisäominaisuuksien toteuttamista. Tämä voi asettaa työn suorittavan toimittajan tilanteeseen, jossa ei näy ulospääsyä. Tällaisille toimittajille kysymys siitä, “mitä ja kuinka paljon meidän on tehtävä, jotta työmme katsotaan suoritetuksi”, voi joskus olla todellinen huolenaihe.

Ja vaikka järjestelmäkehitys toteutetaan usein urakkasopimuksen perusteella, urakkasopimus on sopimus, joka tähtää “työn valmistumiseen”.

Tässä artikkelissa selitämme lain näkökulmasta, “milloin ja mitä on tehtävä, jotta järjestelmäkehitys katsotaan valmiiksi”.

Järjestelmäkehityksen valmistuminen

Teknikon näkökulmasta järjestelmäkehityksen valmistuminen

Järjestelmäkehityksen parissa työskenteleviltä kysyttäessä “milloin järjestelmäkehitys on valmis”, yleinen vastaus on “kun testausvaihe on päättynyt ja tuotokset on toimitettu”. Tavallinen järjestelmäkehityksen prosessi alkaa vaatimusten määrittelyllä, jossa määritellään toteutettavat toiminnot, minkä jälkeen laaditaan erilaisia suunnitelmia, toteutetaan ohjelma ja lopuksi varmistetaan testausvaiheessa, että kaikki toimii oikein. Prosessi päättyy, kun käyttäjä hyväksyy tuotoksen.

Näin ollen, jos katsotaan teknikon näkökulmasta, yleinen käsitys on, että “järjestelmäkehityksen valmistuminen = hyväksyntä”.

Juridinen näkökulma järjestelmäkehityksen valmistumiseen

Toisaalta, juridisesta näkökulmasta katsottuna, kun kysytään, milloin järjestelmäkehitys on valmis, keskustelun keskiössä on luonnollisesti se, milloin toimittajan sopimuksen mukaiset oikeudelliset velvoitteet on täytetty. Alun perin järjestelmäkehityssopimukset luokitellaan pääsääntöisesti joko urakkasopimuksiksi tai osakkuussopimuksiksi.

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

Jätän näiden kahden sopimustyypin eron selittämisen yllä olevaan artikkeliin, mutta jos puhutaan järjestelmäkehityksen valmistumisesta, eli toimittajan velvoitteiden täyttämisestä, niin kriteerit ovat seuraavat:

Urakkasopimus: Siviililaki 632 §
Artikla 632
Urakkasopimus syntyy, kun osapuolet sopivat, että toinen osapuoli suorittaa tietyn työn ja toinen osapuoli maksaa korvauksen työn tuloksesta.
Osakkuussopimus: Siviililaki 648 §
Artikla 648
1. Ellei erityistä sopimusta ole, vastaanottaja ei voi vaatia korvausta antajalta.
2. Vastaanottaja ei voi vaatia korvausta, ellei hän ole suorittanut tehtäväänsä. Kuitenkin, jos korvaus on määritelty ajanjakson mukaan, sovelletaan artiklan 624 2 momentin säännöstä.
3. Jos tehtävän suorittaminen on keskeytynyt kesken kaiken syystä, joka ei johdu vastaanottajasta, vastaanottaja voi vaatia korvausta suoritetun työn osuuden mukaan.

Järjestelmäkehityksen valmistuminen on ongelma urakkasopimuksissa

Kuitenkin, ei vain järjestelmäkehityksen yhteydessä, vaan yleisesti ottaen, “työn valmistumisen ajankohta” on ongelma pääasiassa urakkasopimuksissa. Osakkuussopimuksissa ei niinkään keskitytä tietyn tuloksen tai tuotoksen saavuttamiseen velvoitteen täyttämisenä, vaan sopimustyyppi korostaa enemmän ammattitaitoisen henkilön käyttämistä harkintaa ja (riippumatta lopputuloksesta) asianmukaista toimintaa. Osakkuussopimuksessa, jopa jos odotettua tuotosta ei ole saatu, korvauksen vaatiminen on mahdollista, jos tehtävät on suoritettu asianmukaisesti (artikla 648, kohta 2), ja jos suoritus on keskeytynyt kesken kaiken syystä, joka ei johdu vastaanottajasta, korvauksen vaatiminen on mahdollista suoritetun työn osuuden mukaan (artikla 648, kohta 3). Urakkasopimuksissa painotetaan “tulosta”, kun taas osakkuussopimuksissa painotetaan “prosessia”.

Näin ollen, osakkuussopimuksissa ongelmana on usein “huolellisuusvelvoite” tehtävän suorittamisen prosessissa. Eli, kun otetaan huomioon, että vastaanottajalle on annettu suuri luottamus, kysymys on siitä, milloin voidaan vaatia huolellisuusvelvoitteen rikkomista osakkuussopimuksen perusteella.

Toisaalta, urakkasopimuksissa tärkeää on “työn valmistuminen”. Jos työtä, joka pitäisi saada valmiiksi, ei ole saatu valmiiksi, toimittaja ei ole täyttänyt velvoitteitaan, eikä hän voi vaatia korvausta. Mutta jos työ on valmis, ei ole järkeä kyseenalaistaa työn välivaiheita. Näin ollen, “milloin järjestelmäkehitysprojekti on valmis” -kysymys voidaan pohjimmiltaan tulkita urakkasopimuksen “työn valmistuminen” -lausekkeen oikeudelliseksi tulkinnaksi.

Milloin työn valmistuminen tapahtuu järjestelmäkehityksessä?

Joten, milloin konkreettisesti ajatellen “työn valmistumisen” ajankohta on? Tarkastellaan tätä asiaa aiempien oikeustapausten valossa.

Oikeustapaukset liittyen työn valmistumiseen

Alla lainatussa oikeustapauksessa, myyjä toimitti järjestelmän, jossa myöhemmin ilmeni ongelmia käsittelynopeudessa ja viestintäkustannuksissa. Vaikka näitä ongelmia ilmeni, kehitysprosessi oli kokonaisuudessaan valmis, joten kiisteltiin siitä, voiko työtä pitää valmiina. Lopputuloksena työn valmistuminen hyväksyttiin.

Siviililaki (japanilainen Siviililaki) 632 ja 633 artikla määrittelevät, että urakoitsijan tulee maksaa palkkio tilaajalle, kun työ on valmis ja työn kohteena oleva esine on luovutettu tilaajalle. Toisaalta, sama laki 634 artikla määrittelee, että jos työn kohteena olevassa esineessä on vikoja, urakoitsijan on kannettava takuuvastuu tilaajalle (1 kohta), ja tilaajalla on oikeus vastustaa palkkion maksamista, kunnes urakoitsija on täyttänyt takuuvastuunsa työn kohteena olevan esineen vikojen osalta (2 kohta). Näiden siviililain säännösten mukaan, laki erottaa tilanteet, joissa työn tulos on epätäydellinen, eli tilanteet, joissa työn kohteena olevassa esineessä on vikoja ja tilanteet, joissa työ ei ole valmis, ja tulkitaan niin, että vaikka työn kohteena olevassa esineessä olisi vikoja, olivatpa ne piilossa tai ilmeisiä, se ei tarkoita, että työ ei ole valmis.
Siksi, sen suhteen, onko urakoitsija saanut työn valmiiksi, tulisi tehdä päätös sen perusteella, onko työ saatu päätökseen alkuperäisessä urakkasopimuksessa suunnitellun viimeisen vaiheen mukaan, ja tilaajan tulisi ymmärtää, että hän ei voi kieltäytyä maksamasta urakkahintaa pelkästään sillä perusteella, että työn kohteena olevassa esineessä on vikoja, kun urakoitsija on saanut työn viimeisen vaiheen päätökseen ja luovuttanut esineen.

Yllä olevassa päätöksessä “työn valmistuminen” katsottiin täytetyksi, kun järjestelmäkehityksen viimeinen vaihe oli saatu päätökseen. Jos myyjän luomassa järjestelmässä on puutteita (lakisääteisesti usein “vikoina”), on olemassa erillinen järjestelmä, joka tarjoaa korjaustoimenpiteitä, nimittäin erillinen takuuvastuujärjestelmä.

Siksi, vaikka “työn valmistumisen” käsitettä tulkittaisiin hieman laajemmin, lopulta se ei johda epäreiluuteen käyttäjän kannalta. Yhteenvetona voidaan todeta seuraavaa:

【Urakkasopimuksen velvoite = Työn valmistuminen = Kaikkien vaiheiden päättäminen】
========
Jos työ ei ole valmis…
↓
【Vastuu velvoitteen täyttämättä jättämisestä】
========
Jos työ on valmis, mutta siinä on puutteita…
↓
【Velvoitteen täyttämisen hyväksyminen ja vikojen takuuvastuun kysymys】

Yllä oleva oikeustapaus osoittaa, kuinka nämä kysymykset voidaan jakaa.

Kuitenkin, “työn valmistumiseen” liittyen, voidaan tarkastella myös “käyttäjän hyväksymistä” eri näkökulmasta. Oikeudelliset kysymykset, jotka liittyvät siihen, että käyttäjän hyväksyntä ei etene suunnitellusti, käsitellään erillisessä artikkelissa.

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

Mitä työn loppuunsaattaminen tarkoittaa lain mukaan

Järjestelmäkehityksessä, jos “työn valmistuminen” hyväksytään, se tarkoittaa, että velvollisuus on täytetty, joten velvollisuuden “täyttämättä jättämisen” vastuuta ei voida enää vaatia. Jos kyseessä on urakkasopimus, ellei työtä voida sanoa valmistuneeksi, palkkion laskuttaminen ei ole mahdollista, ja jos esimerkiksi ennakkomaksu on sovittu erityisehdolla, ne on periaatteessa palautettava. Toisaalta, jos työn valmistumisen tosiasia hyväksytään, toimittajan on kannettava vastuu virheistä ja sopimuksen mukaisesta laadunvarmistuksesta.

Se, että toimittaja vapautuu velvollisuuden täyttämättä jättämisen vastuusta, tarkoittaa, että käyttäjän mahdollisuudet purkaa sopimus pienenevät merkittävästi. Tämä johtuu siitä, että sopimuksen purkaminen virhevastuun perusteella on rajoitettu tilanteisiin, joissa sopimuksen tavoitetta ei voida saavuttaa. Jos sopimus puretaan, toimittaja menettää myös oikeuden laskuttaa palkkion (toisin sanoen, palkkio ei tule lainkaan), joten käytännössä “työn valmistumisen” ympärillä syntyy usein kiistoja.

Lisätietoja järjestelmäkehityksen sopimuksen “purkamisesta” löydät seuraavasta artikkelista:

https://monolith.law/corporate/cancellation-of-contracts-in-system-development[ja]

Huomioita työn valmistumiseen liittyen

Miten suhtaudumme eritelmien muutoksiin ja lisäkehitykseen

On mahdollista, että toimittajat voivat joutua tilanteeseen, jossa “alkuperäiset eritelmät on jo täytetty, mutta eritelmien muutoksia ja lisätoimintoja vaaditaan kannattavuuden saavuttamiseksi, eikä työtä voida päättää, koska ei ole selkeää loppupistettä”. Tällaisissa tapauksissa nousee esiin kysymyksiä, kuten “milloin järjestelmän kehitys tulisi päättää”. Tähän liittyvää selitystä on käsitelty yksityiskohtaisesti seuraavassa artikkelissa.

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

Huomioitavaa myös siviililain muutoksissa (Japanin siviililaki)

Lisäksi, sopimukseen perustuvan virhevastuun säännökset ovat alue, joka on voimakkaasti vaikuttanut siviililain muutoksiin, koska niiden yhteydet aiempiin pykäliin ovat usein monimutkaisia ja vaikeasti ymmärrettäviä. Siviililain muuttuessa, miten “virheet” tulisi tulkita, on selitetty yksityiskohtaisesti seuraavassa artikkelissa.

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

Yhteenveto

Tässä artikkelissa olemme käsitelleet polkua, joka johtaa “työn valmistumisen” lakiteoriaan järjestelmäkehitysprojekteissa, jotka saattavat helposti ajautua tilanteeseen, jossa “ei näy ulospääsyä”. Yksittäisen projektin ulospääsy riippuu kehitysvaatimuksista, mutta jos kiista syntyy näistä seikoista, “työn valmistumisen” lakikäsitteen uskotaan usein toimivan ohjaavana lankana.