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

MONOLITH LAW MAGAZINE

IT

Mikä on laki, joka liittyy järjestelmäkehitysprojektin jäsenen lähtöön?

IT

Mikä on laki, joka liittyy järjestelmäkehitysprojektin jäsenen lähtöön?

Järjestelmäkehitysprojekteissa on tavanomaista jakaa jokainen vaihe ja tehtävä pienempiin osiin ja edetä mahdollisimman suunnitelmallisesti. Kuitenkin, riippumatta siitä kuinka paljon painotamme suunnitelmallisuutta, on olemassa ongelmia, joita emme voi ennakoida tai välttää, kuten ihmisiin liittyvät ongelmat. Erityisesti projektiin osallistuvien jäsenten äkilliset sairauspoissaolot tai irtisanoutumiset ovat riskejä, joita emme voi täysin estää, riippumatta siitä kuinka paljon panostamme niiden hallintaan. Tässä artikkelissa selitämme, miten laki liittyy projektiin osallistuvien jäsenten irtisanoutumiseen.

Jäsenen lähtö ja projektinhallinnan velvollisuudet

Ensinnäkin, järjestelmäkehitysprojekteissa katsotaan, että palveluntarjoajalla on kattava velvollisuus varmistaa projektin sujuva eteneminen. Palveluntarjoajan on arvioitava tarvittavat henkilöstöresurssit, aikataulu, budjetti ja työmäärä projektin sujuvan etenemisen varmistamiseksi, pyydettävä tarvittaessa käyttäjältä yhteistyötä ja hallittava projektin etenemistä. Näitä velvollisuuksia kutsutaan “projektinhallinnan velvollisuuksiksi”, ja niiden olemassaoloa on korostettu useissa aikaisemmissa oikeustapauksissa.

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

Äkillisten lähtijöiden ilmestyminen palveluntarjoajan puolella voidaan katsoa olevan yksi projektinhallinnan velvollisuuksien kysymyksistä.

  • Henkilöstön ylityöt ja viikonlopputyöt aiheuttavat fyysisiä ongelmia
  • Ihmisten väliset ristiriidat aiheuttavat psyykkistä stressiä

Projektissa äkillisesti lähtevien henkilöiden syitä voi olla monia. Kuitenkin nämä ovat periaatteessa palveluntarjoajan työvoiman hallinnan ongelmia. Siksi, vaikka tällaiset olosuhteet johtaisivat lopulta toimitusaikojen viivästymiseen, mahdollisuus vapautua velvollisuuden rikkomisesta on pieni. Toisin sanoen, palveluntarjoajalta odotetaan asennetta, jossa otetaan huomioon tällaisten äkillisten poissaolojen mahdollisuus ja hallitaan projektin etenemistä suunnitelmallisesti.

Tärkeitä oikeustapauksia jäsenen eroamiseen liittyen

Esittelemme esimerkkejä tapauksista, joita jäsenen eroaminen voi aiheuttaa projektin kehityksessä.

Tapaus, jossa jäsenen lähtö johti toimitusajan viivästymiseen

Alla lainattu oikeustapaus koskee tilannetta, jossa projektin eteneminen ei sujunut suunnitellusti jäsenen äkillisen lähdön jälkeen, mikä johti toimitusajan viivästymiseen. Tässä tapauksessa käyttäjän edustaja oli ottanut uhkaavan asenteen toimittajan edustajaa kohtaan, mikä oli myös aiheuttanut psykologista stressiä.

Käyttäjä, joka halusi vaatia toimittajalta vastuuta sopimuksen rikkomisesta viivästymisen vuoksi, ja toimittaja, joka halusi vaatia käyttäjältä vastuuta yhteistyövelvollisuuden rikkomisesta tämän uhkaavan asenteen vuoksi, olivat syvästi erimielisiä tapauksesta.

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

Kuitenkin tuomioistuin päätti, että nämä seikat eivät vapauta toimittajaa projektinhallintavelvollisuudestaan ja tuki käyttäjän näkemystä (alleviivatut ja lihavoidut osat ovat kirjoittajan lisäyksiä).

Toimittaja väittää, että käyttäjän edustaja on pakottanut toimittajan edustajan lähtemään projektista loukkaamalla häntä hyökkäävällä ja painostavalla käytöksellä.

Kyllä, käyttäjän edustaja myöntää sanoneensa voimakkaasti “Eikö sinulla ole motivaatiota?” ja “Tämä sopimus on ohi. Kun lähden tästä huoneesta, se on ohi.” marraskuussa 2003 (Heisei 15) tapaamisessa. Kuitenkin, tämä johtui siitä, että vaikka perussopimuksessa määriteltiin, että lokakuu 2003 (Heisei 15) oli prototyyppijakso, kehityksen tavoitteen lisäominaisuuksia ei sisällytetty vaatimusmäärittelydokumenttiin, ja vaikka kommentteja lisättiin esitettyyn vaatimusmäärittelydokumenttiin, toimittaja ei vastannut niihin. Tämä johtui toimittajan työn viivästymisestä ja sen vastauksesta, eikä sitä voida pitää liiallisena käytöksenä.

C:n lähtö projektista sairauden vuoksi, vaikka syy ei ole selvä, vaikka stressi projektin työtaakan vuoksi olisi ollut syynä, se olisi periaatteessa toimittajan työvoiman hallinnan ongelma, eikä sitä voida laittaa käyttäjän syyksi.

Tokion alioikeuden päätös 4. joulukuuta 2007 (Heisei 19)

Yllä olevassa oikeustapauksessa tuomioistuin otti huomioon tosiasian, että käyttäjä oli “voimakkaasti” painostanut toimittajaa, mutta ei lopulta vapauttanut toimittajaa vastuusta. Taustalla on ajatus, että olisi epäreilua syyttää käyttäjää, joka oli painostanut toimittajaa “voimakkaasti”, kun otetaan huomioon toimittajan huono reagointi. Tämä päätös perustui ajatukseen, että järjestelmän kehitysprojekti perustuu toimittajan projektinhallintavelvollisuuden täyttämiseen ja käyttäjän yhteistyövelvollisuuden täyttämiseen. Tässä yhteydessä tuomioistuin päätti, ettei käyttäjän yhteistyövelvollisuuden rikkomista pitäisi tunnustaa. Tämä merkitys ilmenee ilmaisusta “ei voida pitää liiallisena käytöksenä”.

Mitä voimme oppia yllä mainituista oikeustapauksista

Lisäksi voimme saada seuraavat tärkeät opetukset:

  • Kun projektiin osallistuva henkilö joutuu jättämään projektin sairauden vuoksi, ja jos ajatellaan, että käyttäjä on vastuussa tästä, toimittajan on pystyttävä osoittamaan syy-yhteys käyttäjän toiminnan ja henkilön poistumisen välillä → Kuitenkin syy-yhteyden osoittaminen ei yleensä ole helppoa.
  • Vaikka käyttäjän toiminnan seurauksena työkuorma kasvaa suuresti ja henkilö sairastuu, ja tämä voidaan todistaa, yleensä lopulta katsotaan, että kyse on toimittajan työvoiman hallinnan ongelmasta → Jos kiinnitämme huomiota siihen, että tuomioistuimen päätöksessä käytetään voimakasta ilmaisua “liiallinen käytös”, meidän pitäisi olettaa, että tilanteet, joissa toimittaja voi välttää vastuun työvoiman hallinnasta, ovat melko harvinaisia.

Miten varautua jäsenen lähtöön

Mitkä ovat toimenpiteet projektijäsenen lähtöongelmien estämiseksi?

Kuten yllä mainittiin, vaikka henkilöstössä ilmenisi äkillisiä puutteita, on erittäin vaikea syyttää siitä käyttäjiä. Saattaa olla tilanteita, joissa joudutaan tekemään valtavia lisäkehityksiä tai jälkikäteen pakotetaan tekemään rajuja muutoksia, mutta fyysisen ja henkisen rasituksen sekä työkuorman välisen syy-seuraussuhteen todistaminen ei ole helppoa. Ottaen huomioon nämä seikat, on tärkeää pikemminkin valmistautua projektijäsenten sairauspoissaoloihin ja terveydellisiin ongelmiin ja kehittää henkilöstöjärjestelmää.

Jos tämä asia joutuisi oikeuteen, on selvää, että palveluntarjoaja olisi erittäin epäedullisessa asemassa. Siksi tärkeintä on pikemminkin toteuttaa toimenpiteitä tällaisten riitojen estämiseksi. Mahdollisia toimenpiteitä ovat seuraavat:

Valmistaudu järjestelmään, joka ei jätä vastuuhenkilöitä yksin

On tärkeää, että vastuuhenkilö ei osallistu neuvotteluihin yksin, vaan että useampi henkilö osallistuu neuvotteluihin. Tämä voi auttaa estämään psykologisen eristäytymisen.

Pyri joustavaan henkilöstöjärjestelyyn

On tärkeää, että henkilöstöjärjestelyissä on joustavuutta. Vaikka henkilöstön joustava varmistaminen voi johtaa kustannusten nousuun, jos otetaan huomioon viivästymisestä johtuvat vahingonkorvauskustannukset ja mahdollisuus, että lisää henkilöstöä lähtee ongelmatilanteissa, voi olla järkevää varmistaa henkilöstöä alusta alkaen jonkin verran joustavasti.

Tee henkilöstöjärjestelyjen tarkistus ennen terveydentilan huononemista

Jos yksi henkilö lähtee, muun henkilöstön työkuorma kasvaa, mikä voi johtaa pahenevaan kierreeseen, jossa lisää henkilöstöä lähtee. Tällaisen kierteen estämiseksi on tärkeää tehdä henkilöstöjärjestelyjen tarkistus ennen kuin terveydentila huononee vakavasti.

Toteuta projektin muutos- ja dokumentinhallinta perusteellisesti

Vaikka tiimin jäsenen lähtemisen ja käyttäjän yhteistyövelvollisuuden rikkomisen välisen syy-seuraussuhteen todistaminen ei ole helppoa, on tärkeää toteuttaa muutostenhallinta ja dokumentinhallinta perusteellisesti. Tämä johtuu siitä, että vaikka tiimin jäsenen lähtemisen syytä ei voitaisi todistaa, jos on olemassa tilanne, jossa työkuorma on niin suuri, että se johtaa vastuuhenkilön sairauspoissaoloon, siinä voi olla elementtejä, jotka tukevat käyttäjän yhteistyövelvollisuuden rikkomista. Tällaiset seikat voivat olla perusteita, jotka tukevat esimerkiksi velvollisuuden laiminlyönnin tai virhevastuun perusteltuutta, jos projektin “palaminen” johtaa siihen, että palveluntarjoajaa syytetään velvollisuuden laiminlyönnistä tai virhevastuusta.

Seuraavassa artikkelissa käsitellään dokumentinhallinnan merkitystä järjestelmäkehitysprojekteissa.

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

Erityisesti muutostenhallinnan osalta seuraavassa artikkelissa käsitellään yksityiskohtaisesti.

https://monolith.law/corporate/howto-manage-change-in-system-development[ja]

Yhteenveto

Olemme käsitelleet oikeudellista keskustelua, joka liittyy ilmiöön nimeltä “tiimin jäsenen lähtö”. On totta, että toimittajille on erittäin vaikeaa oikeudellisesti vaatia käyttäjiltä vastuuta jäsenen lähdöstä.

Kuitenkin, vaikka tällaisia olosuhteita olisi, on tärkeää, ettei väärinymmärrä, että “oikeudellinen keskustelu ei ole hyödyllinen tiimin jäsenen lähtöön liittyvissä ongelmissa”. Julkaistun oikeustapauksen ajatteluprosessi itsessään kyseenalaistaa, kuinka määritellä rajat “toimittajan projektinhallintavelvollisuuden” ja “käyttäjän yhteistyövelvollisuuden” välillä, puhumattakaan siitä, että tällaiset riitojen ehkäisemiseen tarkoitetut toimenpiteet johdetaan usein laskemalla taaksepäin odotetuista riitatilanteista.

On tärkeää ymmärtää, että “oikeusjuttu on haitallinen” ei tarkoita, että “laki ei ole hyödyllinen”, vaan pikemminkin, että “ennaltaehkäisevän oikeudellisen näkökulman merkitys on tärkeä”.

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へ戻る