Onko järjestelmän kehityksen jälkikäteinen hintakorotus mahdollista?

Järjestelmän kehittäminen on työ, joka vaatii monien ihmisten panosta sekä tilaajan että toimittajan puolelta. Tämän vuoksi kaikkien osapuolten on vaikea pysyä samassa tahdissa projektin edetessä. On itsestään selvää, että suunnittelu on erittäin tärkeää, mutta samalla on epävarmaa, pystyykö tilaaja keräämään tarvittavat tiedot ja välittämään ne selkeästi toimittajalle. Kehitysprosessin edettyä tiettyyn pisteeseen, jos tilaaja vaatii jälkikäteen muutoksia tai lisäominaisuuksia, onko mahdollista lisätä nämä kustannukset alkuperäiseen arvioon? Tämä on kysymys, joka kiinnostaa erityisesti niitä, jotka ottavat työn vastaan.

Miten tällaiset oikeudet tunnustetaan lain mukaan? Ja miten lisäkehityksen ja ominaisuuden korjauksen kustannukset määritetään? Tässä artikkelissa käsitellään näitä ja muita kysymyksiä.

Milloin voidaan puhua lisäkehityksestä tai toiminnon korjauksesta?

Järjestelmäkehitysprojekteissa työn vastaanottamisen sopimustyypit ovat yleensä urakkasopimuksia tai osittaisia toimeksiantosopimuksia. Riippumatta sopimustyypistä, työn vastaanottajan tehtävät (=velvollisuudet) ja niihin liittyvä korvaus (=oikeudet) esitetään sopimuksessa parina. Siksi, jos sopimuksen perusteella määritellyn korvauksen perusteena olevaan työhön lisätään myöhemmin tehtäviä, jotka eivät kuulu siihen, voidaan puhua lisäkehityksestä tai toiminnon korjauksesta. Päinvastoin, jos työ sisältyy sopimukseen, sitä käsitellään alkuperäisten määritysten mukaisesti (=sopimuksen puitteissa).

Urakkasopimuksen ja osittaisen toimeksiantosopimuksen eroista ja muista seikoista on yksityiskohtainen selostus toisessa artikkelissa.

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

Kuitenkin, jos kaikki, kuten näytöllä näkyvän fontin hienosäätö, määritellään etukäteen, ja kaikki katsotaan lisäkehitykseksi, se voi merkittävästi estää sujuvaa kaupankäyntiä. Siksi, kun otetaan huomioon nämä yksityiskohtaiset määrityskeskustelut, yleisen rajanvedon tekeminen ei ole helppoa. Mutta jos annetaan yleinen ohje,

• jos lisätoimintoja määrätään sen jälkeen, kun määrittely on vahvistettu
• jos korjauksia määrätään sen jälkeen, kun ohjelman toteutus on valmis

niin näissä tapauksissa voidaan sanoa, että argumentilla on suuri mahdollisuus olla laillisesti pätevä.

Oikeustapaus, jossa kiistakysymykseksi nousi, voidaanko puhua lisäkehityksestä tai toiminnon korjauksesta

Myönteinen esimerkki: Perussuunnittelun määritysten jälkikäteinen muuttaminen

Alla oleva esimerkki koskee tapausta, jossa määrityksiä muutettiin jälkikäteen.

Ohjelmistokehitys etenee seuraavien kehitysvaiheiden kautta: ① vaatimusten määrittely, ② ulkoinen suunnittelu, ③ sisäinen suunnittelu, ④ lähdekoodin luonti (ohjelmointisuunnittelu, koodaus), ⑤ erilaiset testit (yksikkötestit, yhdistelmätestit, järjestelmätestit) (keskeneräinen)… Alkuperäiset määritykset (keskeneräinen) toteutetaan sisäisen suunnittelun ja sitä seuraavien työvaiheiden kautta, ja tämän katsotaan olevan työn laajuus, joka liittyy palkkion vaatimisoikeuteen ja vastikkeeseen tämän kehitystoimeksiannon sopimuksen perusteella. Määritysten muutoksen esittäminen on laillisesti katsottuna uuden toimeksiannon sopimuksen hakemus, joka ylittää alkuperäisen sopimuksen perusteella määritellyn työn laajuuden, ja jos toimeksisaaja ei esitä lisätyön hintaa ja suorittaa lisätoimeksiannon työt ilman lisämaksun sopimista, katsotaan, että toimeksiantajan ja toimeksisaajan välillä on syntynyt uusi urakkasopimus, jossa ei ole määritelty hintaa, ja että kohtuullinen lisäkehityskustannusten maksuvelvollisuus on syntynyt.

Osakan alioikeuden päätös 29. elokuuta 2002 (Heisei 14)

“Vastikkeen suhde” ja “uusi sopimus” ovat avainsanoja, jotka auttavat ymmärtämään tämän päätöksen syvemmin.

Muuten, tässä päätöksessä tuotiin esiin toinenkin erittäin mielenkiintoinen seikka. Se on, että erittäin yksityiskohtaisten osien, kuten painikkeiden sijoittelun ja kirjasintyypin, hienosäätö ei kuulu tähän määritysten muutokseen. Asiaa koskeva kohta on seuraava:

Kuitenkin ohjelmistokehityksessä ei ole tavallista, että ulkoisen suunnittelun vaiheessa määritellään yksityiskohtia, kuten kirjasintyyppi, jolla teksti näytetään näytöllä, tai painikkeiden sijoittelu, ja yksityiskohtia voidaan muuttaa jonkin verran osapuolten keskustelujen perusteella myös määritysten vahvistamisen jälkeen. Tämän huomioon ottaen ei ole kohtuullista katsoa, että vaatimukset määritysten yksityiskohtaistamiseksi ovat myös määritysten muutoksia.

Osakan alioikeuden päätös 29. elokuuta 2002 (Heisei 14)

Päätöksessä käytettiin mielenkiintoista termiä “määritysten yksityiskohtaistaminen”.

• Tapaus, jossa jälkikäteen muutettiin jotain, jonka piti olla jo päätetty
• Tapaus, jossa jotain, joka olisi voitu päättää työn aikana, ei päätetty etukäteen ja työtä jatkettiin

Tämä saattaa viitata ajatukseen, että näiden kahden tapauksen oikeudellinen käsittely pitäisi olla erilainen.

Muita myönteisiä esimerkkejä

Muita esimerkkejä, joissa lisäkehitys ja toiminnon korjaus on hyväksytty, ovat:

• Tapaus, jossa toimitettujen ohjelmien määrä kasvoi noin kaksinkertaiseksi alkuperäiseen suunnitelmaan verrattuna (Tokion alioikeuden päätös 22. huhtikuuta 2009 (Heisei 17))
• Tapaus, jossa työskentelyaika venyi noin kolminkertaiseksi (Tokion alioikeuden päätös 22. tammikuuta 2010 (Heisei 22))

Kuten näistä esimerkeistä voidaan päätellä, työskentelyajan pidentäminenkin voidaan laajassa merkityksessä katsoa lisäkehitykseksi, joka saa tietynlaista oikeudellista suojaa. Tämä näkökulma on otettu käyttöön.

“Lisäkehitykseen liittyvät sopimukset ja palkkion korotus” sekä “alkuperäisen sopimuksen solmiminen” ovat erillisiä kysymyksiä

Tärkeä huomio näihin kysymyksiin liittyen on, että

1. “Onko kahden yrityksen välillä alun perin solmittu virallinen sopimus järjestelmän kehittämisestä (alkuperäinen sopimus)”
2. “Onko virallisesti solmitun järjestelmän kehittämistä koskevan sopimuksen lisäksi solmittu lisäkehitystä koskeva sopimus”

ovat eri asioita, ja tuomioistuimen arviointiperusteet näissä tilanteissa eroavat toisistaan. Lyhyesti sanottuna, tuomioistuin

• on ensimmäisen kohdan suhteen tiukka (ilman sopimusta sopimuksen solmimista ei helposti hyväksytä)
• on toisen kohdan suhteen suhteellisen joustava (vaikka lisäkehitystä koskevaa sopimusta ei olisi, palkkion korotus ja muut asiat hyväksytään joustavasti)

voidaan sanoa. Ensimmäistä kohtaa käsitellään yksityiskohtaisemmin toisessa artikkelissa.

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

Kielteinen esimerkki: Tapaus, jossa katsottiin, että se sisältyi samankaltaiseen sopimussisältöön lain mukaan

Toisaalta on olemassa oikeustapauksia, joissa korvauksen korotusta ei hyväksytty. Alla lainatussa tuomiossa kiisteltiin siitä, voitaisiinko korvausta korottaa, koska järjestelmän kehityssopimuksen sisältö muuttui sen jälkeen, kun palvelusopimus oli ensin solmittu.

Tämän tapauksen kiistanalaiset kohdat ovat, (1) mitä palveluita syytetty on ottanut vastaan tässä sopimuksessa, (2) onko syytetyn ja vastaajan välillä sovittu laajentaa palveluiden laajuutta ja korottaa maksua, (keskeytys), ja niin edelleen. (keskeytys)

Alun perin tämä sopimus on urakkasopimus, jossa on sovittu, että maksu on lopullinen korvaus syytetyn vastaanottamista palveluista, ja askelmäärä, yksikköhinta jne. ovat vain sisäisiä dokumentteja, joita käytetään laskemaan urakkahinta syytetyn sisällä, ja askelmäärän kasvu jne. eivät liity mitenkään urakkahintaan. (keskeytys)

Kuten edellä todettiin, syytetyn vastaanottamat palvelut muuttuivat 25. helmikuuta 1987 (Showa 62), ja järjestelmän hallinta, urakkatyön kustannuslaskenta ja osa apuohjelmista rajoitettiin, ja loput vastaaja otti hoitaakseen. Oikea muutoksen jälkeen syytetyn tehtävät ovat edelleen alkuperäisen sopimuksen mukaisen kehitystyön piirissä, eikä oikean tehtävän korvaus ole muuttunut, se on kaikki katettu alkuperäisessä sopimuksessa sovitulla lopullisella maksulla.

Tokion alioikeuden päätös 12. kesäkuuta 1995 (Heisei 7)

Kyseisessä tuomiossa päätettiin, että vaikka toimittajalle annettavien tehtävien sisältö muuttuisi, kehityssisältö kuuluu alkuperäisen sopimuksen piiriin ja sen pitäisi olla katettu alkuperäisesti sovitulla korvauksella.

Lopulta, ottaen huomioon, minkä tyyppisiä tehtäviä varten korvaus on määritetty, voidaan hyväksyä lisäkorvauspyynnöt tehtävistä, jotka eivät sisälly siihen. Tämä on kanta, jota voidaan pitää.

Ja loppujen lopuksi, minkä tyyppisten tehtävien suorittamiseksi korvaus oli määritetty, ei välttämättä määräydy pelkästään sopimuksen perusteella, vaan myös kokousmuistiot jne. otetaan huomioon todisteina. Kokousmuistioiden merkitystä käsitellään yksityiskohtaisesti alla olevassa artikkelissa.

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

Miten lisäkehityksen ja toiminnon korjauksen palkkio määräytyy?

Järjestelmän kehitystyössä ei ole harvinaista, että alun perin vahvistetut vaatimukset muuttuvat myöhemmin. Joka kerta kun näin tapahtuu, ei ole realistista valmistella uutta kirjallista sopimusta ja edetä sopimusprosessissa. Jos on mahdollista vahvistaa uudelleen korjattavat asiat ja tehdä yhteenveto esimerkiksi muistiossa, se on yksi asia, mutta miten palkkio tulisi määrittää, jos projekti epäonnistuu ennen kuin nämä toimenpiteet voidaan toteuttaa?

Tässä yhteydessä viitattava laki on seuraava lainaus kauppalaista (512 §) (alleviivattu osa on kirjoittajan tekemä).

Kauppalaista 512 §: Kun kauppias on toiminut toisen puolesta liiketoimintansa puitteissa, hänellä on oikeus vaatia kohtuullista korvausta.

Tämän lainkohdan “kohtuullinen korvaus” tulee ongelmaksi, kun mietitään, kuinka paljon se lopulta on konkreettisessa tilanteessa. Aikaisempien oikeustapausten perusteella näyttää siltä, että työn määrä, laajuus tai kesto suhteessa kustannuksiin on otettu huomioon. Tämä johtuu todennäköisesti siitä, että järjestelmän kehitystyö on luonteeltaan palvelualaa, ja sen pääkustannukset ovat henkilöstökuluja.

Siksi, vaikka kauppalaissa mainittu “kohtuullinen korvaus” on abstrakti käsite, lisäkorvauksen määrän arvioiminen tässä yhteydessä ei vaadi erityisen monimutkaista laskentaa. Katsotaanpa joitakin oikeustapauksia alla.

Tapaus 1: Esimerkki, jossa lisäkorvaus hyväksyttiin työmäärän kasvun suhteessa

Tämän tapauksen eritelmän muutoksen perusteella kehitystyön määrä on kohtuullista pitää yhteensä 257,5 henkilöpäivänä. Jos tämän muutetaan kehityskustannuksiksi henkilöä kohden päivässä käyttäen samaa 32 500 jenin (kohdassa 甲3, yksikköhinta on 650 000 jeniä henkilöä kohden kuukaudessa, ja jos oletetaan, että kuukaudessa on 20 työpäivää, henkilöä kohden päivässä kehityskustannukset ovat 32 500 jeniä.) hintaa kuin tässä kehityksen ulkoistussopimuksessa, niin tämän eritelmän muutosta koskevat lisäkehityskustannukset ovat kohtuullisesti 83 687 500 jeniä.

Osakan alioikeuden päätös 29. elokuuta 2002 (Heisei 14)

“Henkilöä kohden päivässä” on avainsana. Se osoittaa, että lisäkorvauksen laskennassa käytetään työmäärää.

Tapaus 2: Esimerkki, jossa hyväksyttiin lisäkorvaus suhteessa ohjelmien määrään

Kun tarkastellaan tässä tapauksessa lisäosuuden mukaan lukien kohtuullista korvausmäärää, suurin osa tietokonejärjestelmän kehityksen kustannuksista on teknikoiden henkilöstökustannuksia, ja nämä henkilöstökustannukset ovat yleensä suhteessa luotavien ohjelmien määrään. Ottaen tämän huomioon, alkuperäisen sopimuksen määrä, 23 250 000 jeniä, jaetaan 206 ohjelmalla, jotka valmistuivat toiseen tarkastukseen mennessä, ja tämä ohjelman yksikköhinta per ohjelma kerrotaan 414 ohjelmalla, jotka ovat läpäisseet kolmannen tarkastuksen, jolloin saadaan summa 46 725 728 jeniä (23,250,000 ÷ 206 × 414 = 46,725,728), joka hyväksytään kohtuullisena.

Tokion alioikeuden päätös 22. huhtikuuta 2005 (Heisei 17)

Numerot saattavat tuntua monimutkaisilta, mutta rauhallisesti lukiessa huomaa, ettei kyse ole monimutkaisesta laskennasta. Alkuperäisen sopimuksen perusteella on vain tarkistettu “kuinka paljon ohjelman yksikköhinnaksi arvioitiin” ja tehty yksinkertainen laskutoimitus “yksikköhinta × määrä”.

Tapaus 3: Esimerkki lisäkorvauksen myöntämisestä suhteessa työskentelyaikaan

Kantajan työskentelyä koskevassa sopimuksessa A3 määriteltiin, että 60 miljoonaa jeniä maksetaan korvauksena työstä, joka tehtiin kolmen kuukauden aikana tammikuusta maaliskuuhun vuonna 2005 (Heisei 17). Toisaalta, huhtikuusta lähtien samana vuonna, työ sisälsi myös tehtäviä, jotka suoritettiin ilmaiseksi. Kuten edellisenä vuonna, odotettiin, että työmäärä kasvaisi huhtikuusta lähtien samana vuonna, kun uusi lukukausi alkoi ja järjestelmä, joka mahdollisti kurssien rekisteröinnin jne., otettiin käyttöön. Näistä seikoista päätellen, olisi kohtuullista määrittää korvaus kuuden kuukauden työstä huhtikuusta syyskuuhun vuonna 2005 (Heisei 17) 120 miljoonaksi jeniksi, perustuen 60 miljoonan jenin korvaukseen, joka määriteltiin kolmen kuukauden työstä.

Tokion alioikeuden päätös 22. tammikuuta 2010 (Heisei 22)

Edellä mainittu päätös osoittaa, että lisäkorvaus lasketaan yksinkertaisella suhteellisella laskennalla myös pidennetylle ajanjaksolle.

Yhteenveto

Kuten yllä olevista oikeustapauksista voidaan nähdä, ohjelmoijien ja insinöörien lisäpalkkioihin liittyvät oikeudelliset kysymykset näyttävät noudattavan tiettyjä säännönmukaisuuksia ja yhteisiä piirteitä. Periaatteessa näyttää siltä, että korvaus lasketaan mahdollisimman yksinkertaisesti, perustuen sellaisiin suhteellisen objektiivisiin mittareihin kuin käytetty työaika, (toimitetun ohjelman jne.) muodollinen työmäärä ja työskentelyaika tai -jakso.

Tarkkojen menettelytapojen tai täydellisten työtuntien arviointien epäonnistumiset johtavat usein lisäkehitykseen tai toimintojen korjauksiin. Saattaa tuntua hieman kuivalta ajatukselta, että lisäpalkkioita syntyy vain sen perusteella, kuinka paljon työvoimaa on käytetty, kuinka paljon muodollista työtä on tehty tai kuinka paljon aikaa on käytetty. Kuitenkin, jos tarkastellaan asiaa palvelun tarjoajan näkökulmasta, vaikka tavoitteena olisikin asiakkaan edun etusijalle asettaminen, se, että tällaiset oikeudet ovat todennäköisesti laillisesti tunnustettuja, on merkityksellistä myös riskienhallinnan näkökulmasta.