Mikä on lainsäädännöllinen merkitys järjestelmänkehittäjän anteeksipyynnöstä käyttäjälle?
Järjestelmäkehityksen lisäksi myös niin sanotussa palvelualalla asiakkaalta saadut valitukset ovat erittäin tärkeitä. Järjestelmäkehityksessä tämä ei ole poikkeus, ja teknisiä palveluita tarjoavat toimittajat joutuvat usein vastaamaan käyttäjien valituksiin.
Kommunikoinnin parantaminen molempien osapuolten välillä on tärkeää, ja on tilanteita, joissa on järkevää kuunnella toisen osapuolen näkökulma ja pyytää anteeksi. Kuitenkin, on olemassa huoli siitä, että suullisen anteeksipyynnön tai kirjallisen anteeksipyyntökirjeen seurauksena käyttäjän epäoikeudenmukainen vaatimus saattaa tulla hyväksytyksi sellaisenaan. Ehkä jotkut teistä ovat kokeneet tämän.
Tässä artikkelissa keskitymme “toimittajan tekemään anteeksipyyntöön käyttäjälle” ja selitämme, miten se ymmärretään lain mukaan.
Miksi “pahoittelu” on ongelma järjestelmäkehityksen yhteydessä?
Järjestelmäkehitys on palvelualan osa
Alun perin, kun ulkopuolinen toimija osallistuu järjestelmäkehityksen tehtävään ulkoistamisen muodossa, sitä voidaan pitää eräänlaisena “yrityspalveluna”. Jos uskallamme tuoda esiin lakitermejä, sopimukset tehdään yleensä urakkasopimuksen tai quasi-mandaattisopimuksen muodossa. Urakkasopimuksen ja quasi-mandaattisopimuksen eroista kerrotaan yksityiskohtaisesti seuraavassa artikkelissa.
https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]
Keskustelun ydin on, että riippumatta sopimuksen tyypistä, työtä vastaanottavan toimittajan yrityksen tekninen osaaminen ja työvoima (ja niiden taustalla olevat tuotteet) ovat myynnin perusta. Koska kyseessä on kaupallinen transaktio, jossa vaihdetaan palveluita, jotka tarjotaan toimittajan “ihmisten” voimalla, ja vastaavaa korvausta, järjestelmäkehityksen tehtävä on periaatteessa palvelualan osa.
Käyttäjät vaativat anteeksipyyntöä, koska he ovat “asiakkaita”
Koska järjestelmäkehitys on palvelualan osa, on tietenkin oletettavissa, että käyttäjät esittävät valituksia ja vaatimuksia. Samalla myös toimittajilta vaaditaan kykyä vastata tarkasti näihin vaatimuksiin. On totta, että usein toimittajan anteeksipyyntö tai muu vastaava toimenpide johtaa siihen, että yhteistyöjärjestelmä rakennetaan uudelleen ja projekti ohjataan kohti menestystä.
Toisaalta, jos projekti todella epäonnistuu myöhemmin ja asia menee oikeuteen, käyttäjät saattavat väittää, että “toimittaja myöntää syyllisyytensä” perustuen toimittajan anteeksipyyntöön.
Kuinka pitkälle käyttäjät voivat olla “asiakkaita”?
Järjestelmäkehitysprojekti on kaupallinen transaktio, joka tapahtuu “asiakkaan” eli käyttäjän ja “ulkopuolisen toimijan” eli toimittajan välillä. Mutta järjestelmäkehityssopimuksen erityispiirre on sen monimutkaisuus, joka ei sovi tähän suhteeseen. Toisin sanoen, asiakkaana olevan käyttäjän on myös tuettava toimittajan velvollisuuksia, jotta projekti voidaan saattaa päätökseen. On huomautettu, että käyttäjällä on tietty yhteistyövelvollisuus ja molempien osapuolten on edettävä projektissa yhteistyössä.
https://monolith.law/corporate/user-obligatory-cooporation[ja]
Kun tarkastellaan oikeudellisia kysymyksiä, jotka liittyvät toimittajan “pahoitteluihin” käyttäjille, on tärkeää tunnistaa tämän suhteen monimutkaisuus. Käyttäjän ja toimittajan välinen suhde voi kehittyä terveeksi kumppanuudeksi, mutta se voi myös nähdä toimittajan yhtenä monista toimittajista. Ongelma epäoikeudenmukaisesta anteeksipyynnöstä tulee usein esiin, kun unohdetaan perusolettamus, että käyttäjän on myös tehtävä yhteistyötä ja pyrittävä saavuttamaan projekti. Tämä on ominaista järjestelmäkehitystehtävälle, jota ei usein nähdä muissa palvelualoissa.
Miten tuomioistuimet näkevät “anteeksipyynnöt”
Katsotaanpa siis, kuinka paljon oikeudellista merkitystä toimittajan anteeksipyynnöllä on todellisuudessa järjestelmän kehitystä koskevissa oikeudenkäynneissä.
Oikeustapaus 1 liittyen anteeksipyyntöön: Käyttäjän vaatimus nöyrtymisestä
Tässä tapauksessa, käyttäjän luona vierailun jälkeen yön yli kestäneen työrupeaman päätteeksi, käyttäjä syytti tietojen poistamisesta ja vaati nöyrtymistä. Tämän jälkeen käyttäjän vaatimusten mukainen anteeksipyyntökirje jätettiin. Kuitenkin oikeus katsoi, että tässä anteeksipyyntökirjeessä ei ollut vilpitöntä tarkoitusta.
H on laatinut anteeksipyyntökirjeen, jossa mainitaan tästä asiasta. Se on laadittu sen jälkeen, kun hän oli työskennellyt yön yli ja vieraili sitten Heisei 13 vuoden (2001) lokakuun 4. päivänä kantajan toimistossa, jossa häntä syytettiin ankarasti yksipuolisesti, vaadittiin nöyrtymään ja sen jälkeen hän laati kirjeen kantajan vaatimusten mukaisesti rauhoittaakseen kantajan johtajien vihan. Se ei ollut H:n vilpitön tarkoitus, eikä myöskään N:n laatiman anteeksipyyntökirjeen tarkoitus ollut N:n vilpitön tarkoitus.
Tokion alioikeuden päätös Heisei 16 vuoden (2004) huhtikuun 23. päivänä
On huomionarvoista, että tuomio ottaa huomioon osapuolen tunteet, kuten syytöksen “yksipuolisuuden”, “vihan rauhoittamisen” ja “vilpittömän tarkoituksen” puuttumisen.
Oikeustapaus 2 liittyen anteeksipyyntöön: Valinta kirjoittaa anteeksipyyntökirje tai maksaa 20 miljoonaa jeniä
Seuraavassa tapauksessa, vaikka toimittaja oli suostunut kirjoittamaan anteeksipyyntökirjeen loppukäyttäjälle aiheutetusta vahingosta, tuomioistuin päätti, että tämä ei tarkoita, että toimittajan tulisi laillisesti ottaa vastuu.
Kantajan edustaja sanoi vastaanotettuaan oikean raportin, “Nyt on selvää, että E-yhtiö on tehnyt väärin, joten joko kirjoita anteeksipyyntökirje tai maksa 20 miljoonaa jeniä ohjelmiston kehityskustannuksista.” Vastaaja noudatti tätä vaatimusta ja laati 19. tammikuuta samana vuonna anteeksipyyntökirjeen, jossa pahoiteltiin aiheutettua haittaa kantajalle.
(—)
On katsottava, että hän on tehnyt kaiken mahdollisen E-yhtiön tuotteen myyjänä, eikä voida sanoa, että hän on laiminlyönyt velvollisuutensa perustuen perusmyyntisopimukseen, koska hän ei tehnyt enempää.
Tokion alioikeuden päätös, 11. heinäkuuta 1996 (Heisei 8)
Tuomioistuimen päätöksestä voidaan lukea, että ei ole tärkeää, kenelle muodollinen anteeksipyyntökirje on osoitettu, vaan pikemminkin se, kuka on vastuussa, tulisi määrittää painottaen käytännön toimintatapoja.
Yhteistä edellä mainituille oikeustapauksille
Edellä mainituista oikeustapauksista voidaan todeta, että vaikka toimittaja olisi muodollisesti vastannut anteeksipyyntöön, se ei välttämättä merkitse ratkaisevaa merkitystä todellisessa oikeudenkäynnissä. Anteeksipyynnön esittämisen syy on usein vain käytännön syistä liiketoiminnan edistämiseksi, mikä on asia, joka voidaan ottaa huomioon oikeudenkäynnissä. Pikemminkin kuin tällaisen muodollisen anteeksipyynnön olemassaolo, oikeusistuimen kanta on, että tulisi tehdä kokonaisvaltainen arviointi ottaen huomioon anteeksipyynnön ja anteeksipyyntökirjeen tausta sekä se, millainen ihmissuhde käyttäjän ja toimittajan välillä on rakennettu.
Järjestelmän kehittämisessä käyttäjällä on myös velvollisuus tehdä yhteistyötä toimittajan kanssa, mikä on alun perin oikeusistuimen esittämä näkemys. Jos käyttäjän ja toimittajan välillä on ollut hallitseva ja painostava suhde, jota on vaikea kutsua yhteistyökykyiseksi, anteeksipyyntöä käsitellään todennäköisesti vain muodollisena.
Varoitus: ei ole suositeltavaa suostua kevyesti anteeksipyyntöön
Vaikka anteeksipyyntö ei usein ole ratkaiseva todiste oikeudenkäynnissä, se ei tarkoita, että anteeksipyyntöä tulisi tehdä kevyesti. Harkitsematon anteeksipyyntö voi myös aiheuttaa riskin, että käyttäjäpuoli ottaa jääräpäisen asenteen neuvotteluissa ennen oikeudenkäyntiä. Lisäksi, jos tuomari muodostaa käsityksensä anteeksipyyntökirjeen perusteella oikeudenkäynnin alkuvaiheessa, se voi vaatia paljon vaivaa ja aikaa väärinkäsitysten korjaamiseen. Lisäksi, jos anteeksipyyntö ei rajoitu vain anteeksipyynnön ilmaisemiseen, vaan anteeksipyynnön sisältö tai kirjoitettu teksti osoittaa tarkasti toimittajan laiminlyönnin, se voi olla tekijä, joka johtaa epäedulliseen tulkintaan tosiseikkojen vahvistamisvaiheessa.
Joka tapauksessa, on tärkeää ymmärtää, että valitusten ja vaatimusten käsittely on myös oikeudellinen kysymys, ja ulkopuolisten asiantuntijoiden käyttöä tulisi aktiivisesti harkita myös kysymyksessä, kuinka anteeksipyyntö tulisi tehdä.
Category: IT
Tag: ITSystem Development