Mikä on sopimuksen purkamisen menetelmä järjestelmäkehityksessä?
Järjestelmäkehitysprojektit ovat pitkäkestoisia, ja on täysin odotettavissa, että niiden edetessä saattaa ilmetä ongelmia, kuten ‘palaminen’. Vaikka olisi ihanteellista, että käyttäjät ja toimittajat voisivat aina toimia yhteistyössä, on myös mahdollista, että sopimuksen purkaminen tulee harkittavaksi projektin aikana.
Tässä artikkelissa käsittelemme sopimuksen ‘purkamista’ oikeudellisena vaihtoehtona, ja selitämme sen merkityksen järjestelmäkehityksen yhteydessä.
Järjestelmäkehityksen ja purkamisen suhde
Mitä purkaminen tarkoittaa siviililain mukaan?
Uudistetussa siviililaissa (japanilainen siviililaki) sopimuksen “purkamista” koskevat yleiset säännökset on määritelty pykälissä 540-548. Sopimuksen purkaminen tarkoittaa, että kerran solmitun sopimuksen vaikutukset poistetaan jälkikäteen.
Käyttäjän ja toimittajan välisessä suhteessa, kun sopimus on kerran solmittu, toimittajalle asetetaan velvollisuus kehittää järjestelmä ja käyttäjälle asetetaan velvollisuus maksaa korvaus. Nämä muodostavat molempien osapuolten “oikeudet”. Jos sopimus puretaan, molempien osapuolten velvollisuudet ja oikeudet palautuvat sopimuksen solmimista edeltävään tilaan. Siksi, vaikka olisi vielä suorittamattomia velvoitteita, velvollisuus niiden suorittamiseen päättyy, ja molempien osapuolten on palautettava tilanne sopimuksen solmimista edeltävään tilaan. Tätä kutsutaan “alkuperäisen tilan palauttamisvelvollisuudeksi”.
Jos samanaikaisesti on syntynyt vahinkoa, on mahdollista myös suorittaa erillinen vahingonkorvaus.
Järjestelmäkehityksen käytännön ja purkamisen yhteys
Järjestelmäkehityksen ja muiden liiketoimintaan liittyvien oikeudellisten käytäntöjen parissa työskenteleville “sopimuksen purkaminen” tuo ensimmäisenä mieleen purkamisilmoituksen. Kuitenkin, jopa järjestelmäkehityksen kontekstissa, perustana olevat pykälät jaetaan kahteen pääryhmään purkamisen syyn mukaan.
Velvollisuuden laiminlyönti (viivästynyt suoritus) perusteella
(Esimerkki) Toimittaja ei toimita tuotetta, vaikka alkuperäinen toimituspäivä on ylitetty
Siviililaki, pykälä 541: Jos sopijapuoli ei täytä velvollisuuttaan, toinen osapuoli voi määrätä kohtuullisen ajan ja vaatia suoritusta. Jos suoritusta ei ole tehty määräajassa, toinen osapuoli voi purkaa sopimuksen.
Järjestelmäkehityksen urakkasopimuksessa “velvollisuus”, jonka “toinen osapuoli”, eli toimittaja, on ottanut, on toimittaa vaatimusten mukainen järjestelmä. Siksi, jos toimittaja ei toimita tuotetta, vaikka toimituspäivä on ylitetty, se tarkoittaa, että toimittaja ei ole saanut työtä valmiiksi määräajassa. Mutta mitä “työn valmistuminen” tarkoittaa järjestelmäkehityksen yhteydessä? Tätä käsitellään yksityiskohtaisesti seuraavassa artikkelissa.
https://monolith.law/corporate/completion-of-work-in-system-development[ja]
Virhevastuun perusteella
(Esimerkki) Toimittajan toimittamassa järjestelmässä on paljon bugeja ja datan epäjohdonmukaisuuksia, ja myöhemmin käy ilmi, että se ei sovellu käytännön käyttöön
Siviililaki, pykälä 635: Jos työn tuloksessa on virheitä, eikä sopimuksen tarkoitus voida saavuttaa niiden vuoksi, tilaaja voi purkaa sopimuksen. Tämä ei kuitenkaan koske rakennuksia tai muita maanrakennustöitä.
Huomautus: Järjestelmäkehitysprojektin näkökulmasta toimittajan sopimuksen purkamista ei yleensä tapahdu. Yleensä voidaan olettaa, että käyttäjä tekee sopimuksen purkamisilmoituksen toimittajalle.
Virhevastuusta on yksityiskohtainen selitys seuraavassa artikkelissa.
https://monolith.law/corporate/defect-warranty-liability[ja]
Purkamisilmoitus ja siihen liittyvät oikeudelliset kysymykset
Purkamisilmoitus on asiakirja, jolla (yleensä käyttäjästä toimittajaan) ilmoitetaan sopimuksen purkamisesta. Sopimuslausekkeena voit viitata seuraavaan:
Siviililaki (japanilainen siviililaki) artikla 541: Jos sopijapuoli ei täytä velvollisuuttaan, toinen osapuoli voi määrätä kohtuullisen ajan ja vaatia täyttämistä. Jos täyttämistä ei tapahdu määräajassa, toinen osapuoli voi purkaa sopimuksen.
Kun tarkastellaan sitä järjestelmän kehitykseen liittyvänä asiakirjana, purkamisilmoituksen ominaisuus on, että se ei ole tarkoitettu edistämään projektin sujuvaa etenemistä, vaan lopettamaan projekti. Lisäksi se on asiakirja, jolla odotetaan olevan suora vaikutus tietyissä oikeudellisissa asioissa, mikä on myös merkittävä piirre.
Kuitenkin, kuten edellä mainitussa lausekkeessa, toisin kuin sopimukset, se on myös sellainen, joka riittää yksipuolisella tahdonilmaisulla (jos tietyt ehdot täyttyvät). Kun käyttäjä esittää purkamisilmoituksen toimittajalle, on odotettavissa, että toimittajan vastaanottava henkilö saattaa kohdata ongelmia, kuten “En ymmärrä, miksi sopimus purettiin, vaikka luen purkamisilmoituksen”. Joten kuinka yksityiskohtaisesti käyttäjän tulisi osoittaa purkamisen syy purkamisilmoituksessa?
Pitäisikö purkuperusteet kirjoittaa purkuilmoitukseen
Aiempien oikeustapausten perusteella purkuilmoituksessa ei välttämättä tarvitse mainita purkuperusteita. Seuraavassa lainauksessa on esimerkki tapauksesta, jossa toimitetussa järjestelmässä oli ongelmia, jotka johtivat oikeudellisiin ongelmiin. Kun käyttäjä ilmaisee haluavansa purkaa sopimuksen, kysymys on siitä, kuinka tarkasti hän ymmärtää ongelman ja kuinka tarkasti hänen pitäisi osoittaa se. Tuomioistuin totesi seuraavasti:
Purkamisilmoituksessa ei tarvitse välttämättä osoittaa purkuperustetta, ja useita purkuperusteita voidaan ilmaista yhdellä ilmoituksella. Jos purkamisilmoituksessa mainitaan jokin syy, mutta ei erityisesti ilmoiteta, että muita syitä ei ole, ilmoituksen katsotaan perustuvan kaikkiin sopimuksen purkamishetkellä olemassa oleviin syihin ja tarkoittavan sopimuksen täydellistä päättämistä, ellei erityisiä olosuhteita ole.
Tokion alioikeus, 22. joulukuuta 2004 (Heisei 16)
Tuomioistuimen mukaan “useita purkuperusteita voidaan ilmaista yhdellä ilmoituksella”. Toisin sanoen, tärkeää on, onko sopimuksen osapuolella halua purkaa sopimus, ei se, kuinka yksityiskohtaisesti hän osoittaa perusteet.
Esimerkiksi, vaikka tuote on toimitettu, ei ole tarpeen päättää purkamisilmoituksen vaiheessa, pitäisikö sitä pitää keskeneräisenä vai pitäisikö sitä pitää vakavan virheen vuoksi virhevastuun kysymyksenä. Vaikka nämä hienovaraiset kysymykset jätettäisiin toistaiseksi huomiotta, jos purkamisilmoitus tehdään ensin, on mahdollista väittää myöhemmin, että sopimus purettiin joko suoritusviivästyksen tai virhevastuun perusteella, vaikka asia johtaisi oikeudenkäyntiin.
- Toimitettu tuote on keskeneräinen… → Suoritusviivästys
- Toimitettu tuote on vakavasti viallinen… → Virhevastuu
Vaikka perusteita ei määriteltäisi yksityiskohtaisesti, purkamisilmoitus on voimassa purkamisilmoituksena.
Kuitenkin, jos purkuperusteet osoitetaan yksityiskohtaisesti ennen purkuilmoituksen esittämistä, se voi auttaa välttämään väärinkäsityksiä ja epäselvyyksiä kommunikaatiossa myyjän kanssa. Lisäksi, jos purkuilmoituksen vastaanottajalla on tietoa perusteista, hänellä on vähemmän huolta siitä, että asia johtaa myöhemmin riitaan. Siksi on totta, että purkuperusteet olisi hyvä kirjoittaa mahdollisimman selkeästi.
Mitä tarkoitetaan “kohtuullisella ajanjaksolla” määritellyllä ilmoituksella?
Toinen huomioitava seikka on Japanin siviililain (japanilainen siviililaki) 541 §:n mukainen “kohtuullisen ajanjakson” pituus. Tämän osalta ei kuitenkaan tarvitse olla liian huolissaan. Syynä tähän on, että vaikka “kohtuullista ajanjaksoa” ei olisi määritelty ennen ilmoituksen tekemistä, sopimuksen purkaminen on mahdollista, jos ilmoituksesta on kulunut kohtuullinen aika. Lisäksi, vaikka ilmoitukseen asti kulunut aika ei olisi “kohtuullinen”, sopimuksen purkaminen on mahdollista, kun kohtuullinen aika on kulunut. Tämä on myös selkeästi vahvistettu oikeuskäytännössä.
Järjestelmäkehitysprojekteissa, joissa suoritusviivästykset tai virhetakuuvastuut tulevat ongelmaksi, kuten “palavissa” tapauksissa, ei ole todennäköistä, että toimitus tai virheenkorjaus olisi valmis, vaikka ilmoitus olisi tehty “kohtuullisen ajanjakson” määrittämisen jälkeen. Ottaen huomioon nämä seikat, on epätodennäköistä, että “kohtuullisen ajanjakson” ympärillä syntyisi vakavia riitoja käytännössä.
Suoritusviivästyksen määritelmästä järjestelmäkehityksessä kerrotaan tarkemmin toisessa artikkelissa.
https://monolith.law/corporate/performance-delay-in-system-development[ja]
Miten purkamisilmoitus tulisi toimittaa?
Purkamisilmoituksen toimittamistavasta ei ole erityistä määräystä, kunhan ilmoitus varmasti saapuu perille (ja vieläpä niin, että sen perilletulo voidaan myöhemmin todistaa). Tämä tarkoittaa, että voit toimittaa ilmoituksen millä tahansa tavalla.
Siksi ei ole tarpeen olla liian huolissaan menettelytapojen yksityiskohdista. Käytännössä kylläkin sisällön todistamiseksi suositaan usein esimerkiksi todistettua kirjettä, jotta voidaan välttää myöhemmin mahdollisesti syntyvät “sanoin – en sanonut” -kiistat. Kuitenkin, jos voit varmistaa, että ilmoitus on saapunut vastaanottajalle, myös FAX tai sähköposti ovat hyväksyttäviä toimittamistapoja. Jos kuitenkin joudut oikeuteen, sinun on pystyttävä todistamaan, että ilmoitus on saapunut vastaanottajalle, joten tässä mielessä todistettu kirje on turvallisin vaihtoehto.
Yhteenveto
Tässä artikkelissa olemme käsitelleet sopimuksen purkamista järjestelmäkehityksen kontekstissa. Käytännön tietämys siitä, miten purkaminen toteutetaan, on tietenkin tärkeää, mutta myös laillisesti pätevän tahdonilmaisun tekemisen ymmärtäminen on olennaista. Uskomme, että tämä tieto on hyödyllistä ja sovellettavissa moniin tilanteisiin.
Category: IT
Tag: ITSystem Development