Artikkelin otsikko: "Mitä laki sanoo 'liekeissä' olevista järjestelmäkehitysprojekteista?"

Järjestelmäkehitysprojekti ei ole asia, joka voidaan saavuttaa yhdessä yössä. Se vaatii suuren määrän ihmisiä, organisaatioita, suuria rahasummia ja pitkän kehitysajan. Tässä artikkelissa selitämme, miten järjestelmäkehitysprojektin ‘palaminen’ voidaan järjestää oikeudellisen kehyksen puitteissa, ja kokoamme ratkaisuja ohjeellisesti.

Miksi projektit “palavat”?

Yksittäinen IT-järjestelmä toimii oikein vasta, kun se on rakennettu suuresta määrästä ohjelmistotiedostoja ja lähdekoodia, vaikka se ei olisikaan erityisen suurimittainen projekti. IT-järjestelmät ovat usein yksityiskohtaisesti ja tarkasti rakennettuja, paljon enemmän kuin mitä voisi kuvitella pelkästään käyttöliittymän kautta (tai pikemminkin, mitä yksinkertaisempi ja selkeämpi käyttöliittymä on, sitä yksityiskohtaisempi on sen taustalla oleva rakenne).

• Aikataulu on asetettu, mutta vaatimukset ja eritelmät ovat edelleen epäselviä
• Projektin jäsenet ovat liian keskittyneitä yrityksen sisäpolitiikkaan, ja moni heistä lopettaa kesken kaiken ihmissuhdestressin vuoksi
• Projektinjohtajasta lähtien koko johtoportaalla on puutteita neuvottelutaidoissa, eikä jäseniltä vaadita asianmukaista raportointia, yhteydenpitoa ja neuvottelua

Projektien “palamisen” konkreettiset syyt voivat vaihdella projektista toiseen. Kuitenkin, juridisesta näkökulmasta katsottuna, projektien “palamisen” syyt voidaan järjestää suhteellisen yksinkertaisesti useisiin eri kategorioihin.

Palon tyyppi 1: Projekti pysähtyy kesken

Järjestelmäkehityksen edetessä, tyypillinen syy sille, miksi projekti saattaa pysähtyä kesken, on kommunikaation puute käyttäjän ja toimittajan välillä. Alun perin järjestelmäkehitysprojekti vaatii toimittajan asiantuntevaa teknistä ja organisatorista kykyä järjestelmän kehittämiseen, mutta myös loppukäyttäjän yhteistyötä, jotta projekti voi onnistua.

Tästä syystä, jos yhden projektin osapuolet eivät ole selkeästi määritelleet kunkin roolia, projekti saattaa edetä epäselvyyksien vallitessa, ja syntyy eräänlainen “työn siirtäminen toiselle” -tilanne, joka estää projektin sujuvan etenemisen. Lisätietoja käyttäjän velvollisuuksista, toimittajan velvollisuuksista ja niiden oikeudellisista näkökohdista löytyy seuraavista artikkeleista.

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

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

Tässä yhteydessä on tärkeää huomata, että jokaisella osapuolella on tietty vastuu järjestelmäkehitysprojektissa. Karkeasti ottaen, vaatimusten määrittely, ulkoasun suunnittelu (eli perussuunnittelu), hyväksyntä jne., jotka eivät voi valmistua ilman käyttäjän yhteistyötä, ovat osa käyttäjän yhteistyövelvollisuutta, jonka aikaisemmat oikeustapaukset ja tuomioistuimet ovat tunnustaneet.

Toisaalta, toimittajan on myös otettava vastuu projektin sujuvasta etenemisestä ja esteiden tunnistamisesta ja poistamisesta, kun se on saanut käyttäjän yhteistyötä (ja samalla tehnyt yhteistyön pyytämiseen liittyvää kommunikaatiotyötä).

Tämän ajattelutavan mukaan, tuomioistuimet ovat osoittaneet, että käyttäjän on sisäisenä järjestelmänä hallittava hallintoa sisältäpäin, ja toimittajan on ulkoisena asiantuntijana osoitettava asiantuntemustaan ja teknistä kykyään työssään, ja molempien on kohdeltava kaikkia riitoja oikeudenmukaisesti.

Lisäksi, nämä “keskeytykset” ovat yleisiä hyväksymistilanteissa. Hyväksymisestä on yksityiskohtainen selostus seuraavassa artikkelissa.

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

Tässä tilanteessa, jos riita syntyy, objektiivisesti todennettavissa olevat todisteet, kuten aiempien projektien kehitys ja kokousten keskustelut, ovat usein tärkeitä. Siksi, asiakirjojen ennakkoon tallentaminen on usein merkittävää. Jotta omaa asemaa ei heikennettäisi, asiakirjahallinnan perusteellisuus on tärkeää. Lisätietoja järjestelmäkehityksen asiakirjahallinnan merkityksestä löytyy seuraavasta artikkelista.

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

Tyyppi 2: Käyttäjän omasta tahdosta johtuva sopimuksen purkaminen

On myös mahdollista, että projekti keskeytetään käyttäjän toiveesta. Esimerkiksi, jos yritys on aloittanut IT-järjestelmän kehittämisen, joka hoitaa henkilöstöhallinnon kokonaisuudessaan, mukaan lukien ulkomaiset toimipisteet, ja yrityksen laajentumisstrategia ulkomaille vedetään pois. Tällöin aloitettu järjestelmän kehitys saattaa olla tarpeeton myös käyttäjälle.

Alun perin, kysymys siitä, miten yrityksessä käytettävä IT-järjestelmä tulisi rakentaa, ei ole irrallinen kysymys siitä, millaisia toimintoja yrityksessä on. Siksi on mahdollista, että järjestelmän vaatimukset muuttuvat jälkikäteen, jos organisaation rakenne, liiketoimintayksiköiden järjestely tai strategia muuttuu merkittävästi.

Tällaisissa olosuhteissa, jos projekti keskeytetään kesken, syntyy useita oikeudellisia kysymyksiä. Yleensä, koska kyseessä on käyttäjän omasta tahdosta johtuva tilanne, myös toimittajalla on oikeus vaatia korvausta työn valmiusasteen mukaan. Vaikka perusteena olevat pykälät vaihtelevat sen mukaan, millainen sopimustyyppi on valittu, sisältö voidaan järjestää seuraavasti:

・Urakkasopimuksen tapauksessa: Japanilainen siviililaki 641 §
Japanilainen siviililaki 641 §
→Tilaaja voi milloin tahansa purkaa sopimuksen korvaamalla vahingot, jos urakoitsija ei ole saanut työtä valmiiksi.
・Konsultointisopimuksen tapauksessa: Japanilainen siviililaki 648 § 3 momentti (riippuen tilanteesta, myös vahingonkorvausvaatimus Japanilaisen siviililain 651 §:n mukaan)
Japanilainen siviililaki 648 §
→Jos tehtävä päättyy kesken suorituksen syystä, joka ei johdu konsultista, konsultti voi vaatia palkkiota suoritetun työn määrän mukaan.
Japanilainen siviililaki 651 §
→1. Konsultointisopimuksen voi purkaa kumpi tahansa osapuoli milloin tahansa.
→2. Jos toinen osapuoli purkaa sopimuksen toiselle osapuolelle epäedullisena ajankohtana, sopimuksen purkanut osapuoli on velvollinen korvaamaan toiselle osapuolelle aiheutuneet vahingot. Tämä ei kuitenkaan päde, jos sopimuksen purkamiseen on pakottava syy.

Yhteenveto

Jokainen järjestelmäkehitysprojekti etenee moninaisten ja monimuotoisten mutkien kautta. Kuitenkin, kun puhutaan oikeudellisista projekteista, jotka “palavat loppuun”, tässä artikkelissa esitetty kehys toimii yhtenä karttana. Järjestelmäkehitykseen liittyvät oikeudelliset kysymykset sisältävät epäilemättä erittäin monipuolisia teemoja.

Kuitenkin, samalla tavalla kuin järjestelmäkehitys vaatii rakentavaa ajattelua, myös siihen liittyvä riskienhallinta voi olla rakentavampaa, jos ei menetä näkyvyyttä koko alaan. Eikö niin?