Mikä on tapa jättää pöytäkirja järjestelmäkehityksessä oikeudellisesta näkökulmasta?

Kun yritys ulkoistaa järjestelmänkehityksen toiselle yritykselle, sopimukset, jotka on tehty yritysten toimitusjohtajien lakileimoilla, ja vaatimusmäärittelyt, jotka vastuuhenkilöt ovat laatineet, eivät useinkaan selkeästi määrittele, mitä pitäisi tehdä ja milloin. Tämä johtuu siitä, että monissa järjestelmänkehitysprojekteissa päivittäin käydään läpi sähköposteja ja puheluita vastuuhenkilöiden tasolla, kokouksia, joita vastuuhenkilöt järjestävät, ja määritellään alun perin epäselviä osia, muutetaan määritelmiä tilanteen muuttuessa, pyydetään lisäominaisuuksia ja pyydetään apua ilmenneisiin ongelmiin.

Järjestelmänkehityksen sujuvan etenemisen ja mahdollisten riitojen varalta on tärkeää luoda ja hallita dokumentaatiota yhden järjestelmänkehitysprojektin sujuvan hallinnan varmistamiseksi.

Tässä artikkelissa selitämme, kuinka järjestelmänkehityksen edistymiskokousten ja muiden kokousten pöytäkirjoja ja kokousmateriaaleja tulisi säilyttää lakimiehen näkökulmasta.

Miksi dokumentinhallinta on tärkeää järjestelmäkehityksessä?

Järjestelmäkehitysprojekteissa on erittäin tärkeää pitää kirjaa kokouksissa käydyistä keskusteluista, projektin etenemisestä ja historiasta myös lain näkökulmasta. Tähän on kaksi pääsyytä:

Välttääksemme ongelmat myöhemmin

Järjestelmäkehitys on yleensä projekti, johon osallistuu useita osapuolia sekä käyttäjän että toimittajan puolelta. Siksi, jos käyttäjän ja toimittajan välillä on epäselvyyksiä siitä, kuka vastaa mistäkin ja mitä kunkin osapuolen velvollisuudet ovat, se voi aiheuttaa ongelmia projektin etenemisessä myöhemmin.

Lisäksi, koska useat ihmiset osallistuvat projektiin, kommunikaatio-ongelmat, kuten “ihmiset sanovat hieman eri asioita ja on vaikea tietää, kuka on oikeassa”, ovat yleisiä.

On hyödyllistä kirjata yhteisymmärrykseen päästyjen asioiden sisältö, jotta voidaan varmistaa, ettei osapuolten välillä ole epäselvyyksiä. Lisäksi, kun asiat kirjataan muistiin, kaikki osapuolet voivat tarkistaa samat asiat omalla ajallaan, mikä auttaa pitämään kaikki samalla sivulla.

Muuten, lain näkökulmasta ennaltaehkäisevien toimenpiteiden käyttö riitojen estämiseksi on usein kutsuttu ennaltaehkäiseväksi oikeudelliseksi toiminnaksi.

Valmistautuaksemme mahdollisiin riitoihin myöhemmin

Lisäksi, jos tarkastelemme dokumentinhallinnan tärkeyttä hieman eri näkökulmasta kuin edellä mainittu ennaltaehkäisevä oikeudellinen toiminta, voimme mainita “kriisinhallinnan” mahdollisten riitojen varalta.

Kuvitellaan tilanne, jossa jokin ongelma ilmenee, projekti keskeytyy ennen kuin lopputulos on valmis, tai alkuperäinen aikataulu ei enää pidä, ja asia päätyy oikeuteen. Sekä käyttäjän että toimittajan kannalta on tärkeää, että “minulla on oma näkökulmani tapahtuneeseen”, mutta jos kirjallisia todisteita ei ole, on vaikea todistaa omaa näkökulmaansa ja se voi johtaa epäedulliseen kohteluun oikeudessa.

Erityisesti “aikataulusta myöhästymisen” aiheuttamissa ongelmissa, kysymykset kuten “milloin ja miten ongelma havaittiin”, “milloin eritelmän muutospyyntö tehtiin”, “miten toimittaja reagoi käyttäjän pyyntöön lisätä toimintoja” voivat olla ratkaisevia tekijöitä oikeudenkäynnin lopputuloksessa. Jos tällaisissa tilanteissa syntyy paljon “sanoin, en sanonut” -tyyppisiä ongelmia, on vaikea odottaa reilua riidanratkaisua.

Mikä on erityisen tärkeää järjestelmäkehityskokouksen pöytäkirjassa?

Järjestelmäkehityksen kokoustyypit

Järjestelmäkehitysprojekteissa järjestetään usein erilaisia kokouksia. Tämä ei ole yllättävää, kun otetaan huomioon, että projekteihin osallistuu useita ihmisiä. Ohjelmoijat ja insinöörit, jotka toteuttavat ohjelmiston kehityspaikalla, pitävät usein säännöllisiä kokouksia työn etenemisen seuraamiseksi. Lisäksi saattaa olla tarpeen tarkistaa toteutetun koodin ylläpidettävyys, turvallisuus ja mahdolliset haavoittuvuudet esimerkiksi koodin tarkastelun yhteydessä.

Lisäksi kehitystiimin jäsenten kokousten lisäksi yrityksen johtajat ja vastuulliset henkilöt saattavat kokoontua kokouksiin. Näissä kokouksissa keskustellaan usein kehitysprojektin yleisestä suunnasta ja politiikasta. Tällaisia vastuullisten henkilöiden kokouksia, joissa käsitellään tärkeitä asioita, kutsutaan ohjauskomiteoiksi.

Erityisen huomionarvoinen kokous on ohjauskomitea

Kuten aiemmin mainittiin, järjestelmäkehitysprojekteissa järjestetään erilaisia kokouksia osallistujien aseman ja tavoitteiden mukaan. Lakimiehen näkökulmasta erityisen tärkeä kokous on ohjauskomitea. Ohjauskomitean dokumentoinnin merkitys on erityisen tärkeä verrattuna esimerkiksi projektin etenemisen seurantakokouksiin tai tarkastuskokouksiin. Tämä johtuu seuraavista syistä:

1. Ohjauskomitea on vastuullisten henkilöiden järjestämä kokous, jossa usein tehdään tärkeitä päätöksiä. Tämä tekee siitä tärkeän sekä käyttäjien että toimittajien näkökulmasta, ja se on usein tärkeä myös oikeudellisessa mielessä.
2. Projektin jäsenten kokouksissa keskustellut asiat heijastuvat usein erilaisiin suunnitelmiin ja määrittelyihin, joten on epätodennäköistä, että dokumentaatio puuttuisi kokonaan. (Toki, jos näissäkin asioissa dokumentaatio on puutteellista, parannuksia tarvitaan.)

Nämä ovat joitakin esimerkkejä.

Ohjauskomitean pöytäkirjoihin liittyvä oikeustapaus

Esittelemme seuraavaksi tapauksen, jossa ohjauskomitean pöytäkirjat toimivat merkittävinä todisteina todellisessa oikeudenkäynnissä. Alla lainattu tuomioistuimen päätös liittyy tapaukseen, jossa järjestelmänkehitysprojekti keskeytyi kesken kaiken, ja toimittajan projektinhallintavelvollisuuden rikkominen tunnustettiin. Pöytäkirjojen sisältö osoitti alun perin toimittajan ja käyttäjän ymmärryksen, mikä oli erittäin merkittävää oikeudenkäynnissä.

Toimittaja on huomauttanut, että ohjauskomitean pöytäkirjoihin perustuvat järjestelmänkehityksen etenemisen tunnustamiset eivät välttämättä heijasta työn todellista tilaa, koska pöytäkirjojen sisältö on korjattu käyttäjän toimesta. Kuitenkin, ohjauskomitea perustettiin tekemään päätöksiä järjestelmänkehityksen ylemmän johdon tasolla, ja sekä toimittajan että käyttäjän puolelta osallistui järjestelmänkehityksen vastuuhenkilöitä, jotka tekivät kokonaisarvioinnin, jakoivat aikataulun ja työn etenemisen todelliset tulokset ja ongelmat, ja tekivät päätöksiä tärkeistä kysymyksistä. Ja siellä keskustellut pääkohdat kirjattiin pöytäkirjaan, jonka toimittaja laati seuraavan seuraavan työpäivän aamupäivään mennessä, rekisteröi pöytäkirjatietokantaan, ja lopulliset päätökset kirjattiin pöytäkirjaan. Kun pöytäkirja vahvistettiin, sekä toimittajan että käyttäjän katsottiin ymmärtäneen työn kirjaamisen merkityksen pöytäkirjaan ja tarkastelleen sen sisältöä ja ilmaisua, ja vahvistaneen sisällön heijastamaan kokouksen todellista tilaa. Erityisesti toimittajan, joka tekee järjestelmänkehitystä ammatikseen, voidaan sanoa tietävän hyvin pöytäkirjojen laatimisen merkityksen ja menetelmän. Siksi, vahvistetut pöytäkirjat tulisi kohdella heijastavan ohjauskomitean työn todellista tilaa, ja ellei erityisiä olosuhteita tunnusteta, työn etenemisen sisältö jne. tulisi tunnustaa ohjauskomitean yhteenvetona kyseisenä päivänä pöytäkirjaan kirjattujen tietojen perusteella.

Tokion korkein oikeus, 26. syyskuuta 2013 (Heisei 25)

Oikeusistuimen kanta on, että jos kokouksen pöytäkirja on laadittu toimittajan ja käyttäjän yhteisymmärryksessä, sitä voidaan pitää “todisteena”, jolla on tiettyä oletusvoimaa. Toisesta näkökulmasta katsottuna, jos pöytäkirjaan tehdään liian huolettomasti merkintöjä, on olemassa riski, että se tulee sellaisenaan todisteeksi. Tämä on asia, johon tulisi kiinnittää erityistä huomiota.

Mitä konkreettisia asioita tulisi kirjata kokouksen pöytäkirjaan

Kokouksen pöytäkirjalla on tärkeä merkitys todisteena mahdollisessa oikeudenkäynnissä (ja myös silloin, kun oikeudenkäyntiä ei tule, se on tärkeä osapuolten välisissä neuvotteluissa). Joten, mitä konkreettisesti tulisi dokumentoida ja kirjata kokouksen pöytäkirjaan? Järjestämme sen alla.

Mitä toimittajan tulisi kirjata pöytäkirjaan

Toimittajalla on projektiin liittyen projektinhallintavelvollisuus järjestelmänkehityksen asiantuntijana. Tämän velvollisuuden sisältö on selitetty yksityiskohtaisesti alla olevassa artikkelissa.

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

Ottaen huomioon nämä velvollisuudet, toimittajan tulisi erityisesti kirjata pöytäkirjaan:

1. Kunkin kehitysvaiheen valmistumisen tosiasia ja päivämäärä
2. Käyttäjän puolelta saadut pyynnöt muuttaa määrittelyjä, lisätä toimintoja jne., ja miten niihin on vastattu
3. Jos kehitystyö on viivästynyt käyttäjän omasta syystä, mitä toimenpiteitä on tehty yhteistyön pyytämiseksi ja niiden tausta

Nämä ovat esimerkkejä asioista, jotka voidaan mainita.

Lisäksi, liittyen yllä mainittuun kohtaan 3., jos käyttäjä ei suorita hyväksyntää, toimittajan tulisi harkita seuraavia asioita, jotka on selitetty alla olevassa artikkelissa. Tässä artikkelissa selitetään, kuinka paljon toimittajan yhteistyö käyttäjän hyväksynnän suorittamiseksi vaikuttaa oikeuden päätökseen, viitaten todellisiin tuomioihin.

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

Mitä käyttäjän tulisi kirjata pöytäkirjaan

Luonnollisesti myös käyttäjällä on tietty yhteistyövelvollisuus järjestelmänkehittäjää kohtaan, koska kyseessä on yrityksen sisäisesti käytettävä järjestelmä. Tämän velvollisuuden kokonaisuus on selitetty alla olevassa artikkelissa.

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

1. Historia siitä, mitä käyttäjän tulisi kertoa toimittajalle, kuten halutut toiminnot, näytön ulkonäkö jne.
2. Historia erilaisista ongelmista, jotka ovat syntyneet toimittajan prosessissa (esimerkiksi jäsenen äkillinen lähtö tai kehitysaikataulun viivästyminen johtuen toimittajan puutteellisesta tutkimuksesta ja sen syistä)

Erityisesti yllä mainittuun kohtaan 2. liittyen, ongelmia syntyy helposti, kun vanha järjestelmä poistetaan käytöstä ja uutta järjestelmää kehitetään samanaikaisesti. Ongelmia syntyy erityisesti, kun vanhan järjestelmän tiedot siirretään uuteen järjestelmään, mutta näihin ongelmiin liittyvät oikeudelliset kysymykset on selitetty yksityiskohtaisesti alla olevassa artikkelissa.

https://monolith.law/corporate/the-transition-from-the-oldsystem[ja]

Yhteenveto

Edellä mainittu on ohjeistus siitä, kuinka kokousmuistiot tulisi jättää järjestelmäkehityksen yhteydessä oikeudellisesta näkökulmasta. On tärkeää syventää ymmärrystä paitsi käytännön “how-to” -ohjeista, myös “laki”, “järjestelmäkehitys” ja “asiakirjahallinta” -teemojen yhteyksistä. Koska järjestelmäkehitys on sellainen, joka helposti laajenee suuriksi kaupallisiksi transaktioiksi, joihin osallistuu monia ihmisiä ja organisaatioita, siihen liittyvien riitojen ennaltaehkäisy ja toimenpiteet ovat tärkeitä. Ja oikeudellisesta näkökulmasta katsottuna todisteiden säilyttämisen tarpeellisuus tarkoittaa, että “asiakirjojen” olemassaolo, joka voidaan objektiivisesti vahvistaa kenen tahansa silmissä, on merkittävä.

Toki, kaikkien vuorovaikutusten ja projektin etenemisen täydellinen kielellistäminen voi olla suuri taakka ja se ei välttämättä ole realistista. Kuitenkin on tärkeää tunnistaa, mitkä asiat ovat oikeudellisesti merkittäviä, ja edistää niiden dokumentointia tarvittaessa. Tämä seikka, että on tärkeää edetä dokumentoinnissa tarvittaessa, pitäisi olla laajalti tunnustettu kaikkien liiketoimintaan osallistuvien ihmisten keskuudessa, riippumatta siitä, ovatko he oikeuden asiantuntijoita vai eivät.