MONOLITH LAW OFFICE+81-3-6262-3248Arkisin 10:00-18:00 JST [English Only]

MONOLITH LAW MAGAZINE

IT

Mikä on toimittajan tukivelvollisuus järjestelmäkehityksen päättymisen jälkeen?

IT

Mikä on toimittajan tukivelvollisuus järjestelmäkehityksen päättymisen jälkeen?

Järjestelmäkehityksessä on yleisesti tiedossa, että järjestelmäkehityksen erikoisammattilaiset, eli toimittajat, kantavat “projektinhallintavelvollisuuden”. Kuitenkin, oikeudellisesti on esitetty myös samankaltaista, mutta erilaista käsitettä nimeltä “tukivelvollisuus”. Tässä artikkelissa selitämme “tukivelvollisuuden” käsitettä, ottaen huomioon myös aikaisemmat oikeustapaukset.

Tukivelvollisuus

Tukivelvollisuuden yleiskatsaus

Kun puhutaan velvollisuuksista, joita toimittaja on ottanut käyttäjää kohtaan, projektinhallintavelvollisuus on yksi merkittävimmistä. Tämä on vakiintunut käsite, joka on toistuvasti mainittu aikaisemmissa oikeuden päätöksissä, ja se kattaa toimittajan velvollisuudet koko projektin ajan, toimittajan roolissaan järjestelmänkehityksen asiantuntijana.

https://monolith.law/corporate/project-management-duties[ja]

Projektinhallintavelvollisuus on erittäin tunnettu termi järjestelmänkehityksen lakikielessä, ja se on epäilemättä yksi toimittajan tärkeimmistä velvollisuuksista. Kuitenkin joissakin oikeuden päätöksissä on tunnustettu myös “tukivelvollisuuden” olemassaolo, joka on erilainen kuin projektinhallintavelvollisuus.

Tukivelvollisuus tulee ongelmaksi käyttäjän tukemisessa

Mikä sitten on tukivelvollisuus, ja miksi se on eri asia kuin projektinhallintavelvollisuus? Tukivelvollisuus tulee yleensä ongelmaksi järjestelmän kehityksen jälkeen. Järjestelmänkehitysprojekti päättyy, kun kehitettävä järjestelmä on valmis. Toisin sanoen, järjestelmänkehitysprojekti alkaa määrittelemällä, mikä järjestelmän pitäisi olla (= vaatimusten määrittely), ja päättyy, kun on varmistettu, että järjestelmä on todella valmis (= testaus tai hyväksyntä). Tässä yhteydessä on syytä huomata, että hyväksyntäprosessi on tärkeä osa “järjestelmänkehitysprojektin päättymistä”, ja tämän vaiheen aikana usein ilmenevät oikeudelliset ongelmat käsitellään yksityiskohtaisesti seuraavassa artikkelissa.

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

Kuitenkin, vaikka järjestelmänkehitysprojekti olisi uuden järjestelmän kehittämistä, on itsestään selvää, että kehitetty järjestelmä tulee olemaan käytössä liiketoiminnassa sen jälkeen. Toisin sanoen, on epäloogista sanoa, että “koska olen kehittäjä, minun tarvitsee vain luoda järjestelmä” ja jättää huomiotta, miten järjestelmää käytetään sen kehittämisen jälkeen. Ottaen huomioon nämä seikat, aikaisemmissa oikeuden päätöksissä on herännyt kysymys, pitäisikö toimittajan, joka vastaa järjestelmän kehittämisestä, myös tukea sen käyttöä. Toisin sanoen, pitäisikö toimittajan velvollisuuksiin järjestelmänkehityssopimuksessa sisältyä myös velvollisuus tukea järjestelmän käyttöä sen kehittämisen jälkeen. Koska käyttötuki ei ole osa kehitysprosessia, sitä on kutsuttu tukivelvollisuudeksi erottaakseen sen projektinhallintavelvollisuudesta.
 

Mitä oikeustapauksia on ollut, joissa tukivelvollisuus on ollut ongelmana

Toimittajan tukivelvollisuus voi sisältää myös käyttäjän toiminnan aloittamiseen asti jatkuvan tuen.

Tapaus, jossa käyttäjän liiketoiminta kärsi järjestelmätestauksen vaiheessa

Alla lainatussa tuomiossa käsitellään tapausta, jossa käyttäjä ei pystynyt hyödyntämään järjestelmää suunnitellulla tavalla järjestelmätestauksen aikana ennen järjestelmän käyttöönottoa. Tämän seurauksena käyttäjä päätti lopulta luopua järjestelmän käytöstä kokonaan. Vaikka tämä tapaus liittyi ongelmiin käyttäjän toiminnan aloittamisen yhteydessä, kysymys oli siitä, miten toimittajan vastuu voitiin perustella aiemmin solmitun järjestelmän kehittämistä koskevan urakkasopimuksen perusteella. Lopputuloksena käyttäjän vahingonkorvausvaatimus hyväksyttiin, ja perusteena oli “tukivelvollisuuden rikkominen”.

I Tukivelvollisuuden rikkominen
(A) Kanteen nostaja esitti vastaajalle 14. heinäkuuta 1997 (Heisei 9), että “Haluan, että huolehdit järjestelmästä loppuun asti, ei vain sen luomisesta, vaan myös sen toiminnasta.“, “Olemme amatöörejä, maksamme paljon rahaa, joten haluan, että voimme käyttää sitä loppuun asti.“. Vastaaja selitti, että hän pystyy rakentamaan järjestelmän, joka saavuttaa kanteen nostajan tavoitteet, ja lupasi tukea sitä, kunnes se toimii kunnolla. Tämän seurauksena kanteen nostajan ja vastaajan välillä syntyi sopimus, jonka mukaan vastaaja tukee kanteen nostajaa, kunnes tämä pystyy käyttämään järjestelmää kunnolla.
Vastaajan tukivelvollisuus kanteen nostajaa kohtaan ilmenee siitä, että “urakkasopimuksen hinta” sisältää “paketin käyttöönoton tukemisen“, josta on laskutettu 1 726 000 jeniä, ja tarjouksessa on maininta “kuuden kuukauden ilmainen ylläpito” käyttöönoton jälkeen. Lisäksi asiakirjassa, joka on otsikoitu “Tuleva SE-tuki (sisäinen kokousmateriaali)”, on vahvistettu, että SE-tukea on saatavilla “tuoreiden tilausten” ja “käyttöönoton suunnitelman (suunnitelma)” sekä “datan/käytön tarkistustyön” osalta.

(B) Vastaajan tukivelvollisuus kanteen nostajaa kohtaan tarkoittaa konkreettisesti sitä, että vähintäänkin siihen asti, kun kanteen nostaja on saanut järjestelmän täysin käyttöön, vastaajan on ① tarjottava kanteen nostajalle sopivia neuvoja järjestelmän käyttötavoista, ② osallistuttava käyttötestaukseen ja vastattava järjestelmän toimintahäiriöihin, jotka ilmenevät käyttötestauksen aikana, ③ parannettava järjestelmää käyttötestauksen tulosten perusteella, ja ④ järjestettävä käyttöönoton koulutusta operaattoreille.
Kuitenkin, vaikka käyttötestauksen aikana ilmeni useita ongelmia, vastaaja ei ottanut niitä vakavasti, vaan väitti, että ne johtuivat operaattorien koulutustason puutteista, ja vaati vain koulutuskustannuksia, eikä tarjonnut kanteen nostajalle mitään asianmukaista tukea kohti täyttä käyttöönottoa.

Tokion alioikeuden Hachiojin haara, tuomio 5. marraskuuta 2003 (Heisei 15)

Tässä tuomiossa “tuki” mainitaan noin 30 kertaa koko tuomion ajan, mukaan lukien sisällysluettelo. Käyttäjien pyynnöt asianmukaisesta tuesta on kirjattu suoraan tuomioon, mikä osoittaa, että tuomio on tehty huolellisesti harkiten tapauksen yksityiskohtia ja pyrkien oikeudenmukaiseen ratkaisuun. Erityisesti tämän tapauksen ymmärtämisen kannalta olisi kiinnitettävä huomiota seuraaviin seikkoihin:

  • Tukivelvollisuuden rikkominen käsitellään “velvollisuuden laiminlyöntinä”, minkä seurauksena määrättiin korvaamaan siitä aiheutuneet vahingot.
  • “Projektinhallintavelvollisuus” -termiä ei käytetä kertaakaan koko tuomiossa.

Nämä seikat osoittavat, että vaikka tukivelvollisuus on erillinen käsite kuin projektinhallinta, sitä käsitellään osana järjestelmän kehittämistä koskevan sopimuksen velvoitteita.

Miten tukivelvollisuuden luonne tulisi tulkita?

Järjestelmän kehittämistä ja käyttöönottoa tulee tarkastella käyttäjän yhteistyön pohjalta.

Tukivelvollisuus ei ole vielä selkeä käsite

Kuten aiemmin mainitut oikeustapaukset osoittavat, järjestelmän kehittänyt toimittaja on velvollinen tarjoamaan käyttäjälle tarvittavan tuen järjestelmän käyttöönoton yhteydessä. Tukivelvollisuuden osalta ei kuitenkaan ole yhtä paljon oikeuskäytäntöä tai muita tietolähteitä kuin projektinhallintavelvollisuuden osalta, joten sen todellinen luonne ei ole vielä täysin selvä. Erityisesti “tuki” -termi itsessään sisältää ongelman, koska ei ole täysin selvää, mitä sen pitäisi konkreettisesti tarkoittaa.

Tukivelvollisuutta ei voida tunnustaa rajoituksetta

Lisäksi yllä mainittu tuomio, joka tunnusti toimittajan tukivelvollisuuden rikkomisen, toi esiin erittäin tärkeän seikan.

Toimittajan katsotaan olevan velvollinen tarjoamaan tiettyä tukea järjestelmän käyttöönoton mahdollistamiseksi, joka on rakennettu ja toimitettu asiakkaalle sopimuksen perusteella. Kuitenkaan ei voida tulkita, että tämä tuki olisi, kuten asiakas väittää, rajaton, kunnes asiakas pystyy todella käyttämään järjestelmää, ja että se olisi ilmainen.

Tokion alioikeuden Hachiojin haara, päätös 5. marraskuuta 2003 (Heisei 15)

Jos päätehtävänä on järjestelmän “kehittäminen”, myös “käyttöönottoa” varten tarjottavaan tukeen liittyy luonnollisesti rajoituksia. Tässä päätöksessä otetaan huomioon useita erityispiirteitä, kuten käyttäjien tukipyynnöt, ennakkotarjouksen sisältö ja erityiset sopimukset tuen tarjoamisesta. Toisin sanoen, jos tukivelvollisuuden käsite laajenisi rajoituksetta, se aiheuttaisi suuren taakan toimittajalle. Tämän vuoksi velvollisuuden rikkomisen tunnustaminen itsessään tulisi tehdä jonkin verran varovaisesti.

Tukivelvollisuuden todellisuus tulisi tarkastella yhdessä käyttäjän yhteistyövelvollisuuden kanssa

Tähän mennessä keskustelu on pohjimmiltaan koskenut kysymystä siitä, “miten käyttäjät ja toimittajat jakavat työtaakan järjestelmän kehittämisen alkuvaiheessa”. Tähän liittyy epäilemättä monimutkainen kysymys siitä, kuinka paljon oikeudellista velvollisuutta toimittaja ottaa käyttöönoton yhteydessä “kehitys”-sopimuksesta. Samalla on myös pakko sanoa, että yksittäisten olosuhteiden huomioon ottaminen on vahvasti suositeltavaa.

Kuitenkin, toimittajan tukivelvollisuuden todellisen luonteen ymmärtäminen yhdessä käyttäjän yhteistyövelvollisuuden kanssa voi tehdä siitä varmemman.

https://monolith.law/corporate/user-obligatory-cooporation[ja]

Alun perin uuden järjestelmän avulla tehtävän parantamisen pyrkimys on teknisen asiantuntijan eli toimittajan ja yrityksen sisäisen tehtävätiedon omaavan käyttäjän yhteistyö. Siksi myös tukivelvollisuuden osalta on usein mahdollista määrittää sen laajuus selkeämmin määrittelemällä, mitkä asiat käyttäjän tulisi ratkaista “yhteistyövelvollisuuden täyttämisen” osana omatoimisesti.

Yhteenveto

Tässä artikkelissa olemme käsitelleet projektinhallinnan perusteita ja järjestäneet tietoa ‘tukivelvollisuudesta’, joka voidaan nähdä projektinhallinnan johdannaisena. Tukivelvollisuuden käsitteessä on edelleen monia epäselviä kohtia, mutta sen ymmärtämisessä tärkeää on ymmärtää perusasiat, kuten ‘projektinhallintavelvollisuus’ ja ‘yhteistyövelvollisuus’.

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

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.

Category: IT

Tag:

TOPへ戻る