Entinen IT-insinööri-Asianajaja selittää sopimusasiakirjojen tarkistamisen ja debuggauksen yhtäläisyyksiä

Niin sanotun “yrityksen neuvonantaja-avustajan” tehtävien ytimessä on yrityksen päivittäin asiakkaiden ja liikekumppaneiden kanssa solmimien sopimusten tarkistaminen ja korjaaminen. Ja nämä tarkistukset ja korjaukset eivät voi olla kattavia, ellei niitä suorita henkilö, joka on perehtynyt sekä lakiin että kyseiseen liiketoiminta-alueeseen. Selitän, miksi näin on.

Kuitenkin, seuraava selitys saattaa olla vaikea ymmärtää, ellei ole insinööri tai henkilö, jolla on ohjelmointikokemusta. Monolith Law Office on lakitoimisto, jonka johtajana toimii entinen IT-insinööri ja yritysjohtaja. Se on sijoitettu “artikkeliksi, jossa entinen IT-insinööri ja yritysjohtaja johtavat lakitoimistoa ja selittävät sopimusten tarkistamista ja korjaamista insinööreille ja johtajille, joilla on ohjelmointikokemusta”.

Ja tämän sijoittelun perusteella, sopimusten tarkistaminen ja korjaaminen on työtä, joka on lähellä niin sanottua “debuggausta”.

1. Mikä on “bugi” alun perin
2. Mitä “debuggaus” tarkoittaa
3. Miten sopimukset määrittelevät algoritmit
4. Mitä sopimusten korjaaminen tarkoittaa

Aloitamme keskustelun “itsestäänselvyyksistä” insinööreille, mutta selitän alla.

Mitä ovat “bugi” ja “debuggaus”

Vika ei tarkoita “tietokoneen rikkoutumista”

Kun puhutaan “vikasta”, jotkut saattavat kuvitella tilanteen, jossa tietokoneesta nousee savua ja näyttö alkaa näyttää outoja merkkejä työskennellessäsi sillä. Kuitenkin, periaatteessa tietokone toimii vain “kuten sille on kerrottu”. Tämä pätee myös silloin, kun vika ilmenee. Toisin sanoen, “vika” tarkoittaa seuraavaa:

• Tietokone toimii kuten sille on kerrottu
• Käyttäjän kannalta sen toiminta on “odottamatonta”

Tämä on se ilmiö, jota kutsutaan “viaksi”.

Miksi “odottamattomia toimintoja” tapahtuu?

Ajatellaan esimerkiksi Mario-tyyppisen toimintapelin “seinän läpi” -bugia.

Mario-hyppy on toisen asteen funktio. Kiihtyvyys, nopeus, koordinaatit. Vaikka se on niin sanottu toisen asteen funktio, voimme esimerkiksi jakaa X:n äärettömän pieniksi osiksi, kuten “Mikä on Y, kun X=1.76582?”. Videopelien tapauksessa emme kuitenkaan voi jakaa aikaa äärettömän pieniksi osiksi. Koska näyttö päivittyy vain 30 kertaa sekunnissa (esimerkiksi). Siksi, niin sanotusti, Mario “warpaa” 30 kertaa sekunnissa.

Tässä yhteydessä, jos esimerkiksi “Mario hyppää ja pomppaa takaisin, koska yläilmoissa on seinä”, se tarkoittaa seuraavaa:

1. Edellisellä hetkellä Mario oli ilmassa
2. Seuraavalla hetkellä, Marion koordinaatit ovat seinän sisällä

Tämä on tilanne.

Tässä tapauksessa, voidaan päätellä, että “Mario osui yläilmojen seinään hypyn aikana”. Joten, luonnollisella kielellä sanottuna

Jos Marion koordinaatit ovat seinän sisällä, suoritetaan pomppimisprosessi (※1)

Tällaisen ohjelman kirjoittaminen mahdollistaa “Marion hyppää ja pomppaa takaisin, koska yläilmoissa on seinä” -prosessin toteuttamisen.

※1 näyttää oikealta, kun se kirjoitetaan näin. Ja todellakin, “tietyissä olosuhteissa” tämä prosessi on oikea.

Mutta jos ajattelemme tarkemmin, seuraavanlainen tilanne on myös mahdollinen (※2).

Tässä tapauksessa, “hetki, jolloin Marion koordinaatit ovat seinän sisällä” ei ole olemassa, joten pomppimisprosessia ei suoriteta, ja Mario pääsee livahtamaan seinän läpi.

Tämä on esimerkki “bugista”. Vaikka “seinän läpi” -bugi tapahtuisi tällaisista syistä, se ei tarkoita, että PC on rikki. PC vain suorittaa annetut toiminnot, ja ihminen arvioi, onko tämä toiminta “odottamaton” tai “bugi”. Ja tämä “bugi” johtuu siitä, että algoritmi ei ole sopiva.

“Ennakoimattomien toimintojen esiintymisen” harkitseminen

Kuitenkin, on epäselvää, tapahtuuko edellä mainittu “seinän läpi kulkeminen” todellisessa pelitilanteessa vain abstraktisti ajatellen. “Seinän läpi kulkemisen” mahdollisuus riippuu seuraavista tekijöistä:

• Mario-hahmon hyppyvoima (alkunopeus) ja onko olemassa esineitä, jotka lisäävät hyppyvoimaa
• Kuinka ohut seinä voi olla ohuimmillaan

Nämä ovat ehtoja, jotka määrittävät sen. Riippuen siitä, onko nämä ehdot täytetty, on mahdollista, että tapahtuu tilanne kuten ※2. Jos ※2 ei ole mahdollinen, niin ※1 ohjelma ei ole ongelma.

Mitä “debuggaus” työ pitää sisällään?

Joten, “debuggaus”, eli virheiden löytäminen ja niiden korjaaminen, vaatii seuraavat työvaiheet:

1. Ohjelman algoritmin lukeminen ja ymmärtäminen (vaikka yllä oleva esimerkki on luonnollisella kielellä, ohjelmat kirjoitetaan yleensä omalla kielellään, joten lukeminen itsessään voi olla haastavaa)
2. Ohjelman toiminnan tutkiminen eri olosuhteissa (esimerkiksi hyppyvoiman tai seinän paksuuden tutkiminen)
3. Tarkistaminen, ettei ohjelma käyttäydy odottamattomasti

Nämä prosessit ovat siis välttämättömiä.

Mitä sopimusten tarkistaminen työnä tarkoittaa?

Sopimusten tarkistaminen on samankaltaista työtä. Alun perin sopimus on asiakirja, joka määrittelee osapuolten, A:n ja B:n, oikeudet ja velvollisuudet tulevaisuudessa mahdollisesti tapahtuvissa tilanteissa. Se määrittelee, miten molemmat osapuolet toimivat näissä tilanteissa. Tässä mielessä sopimusta voidaan pitää “ohjelmana, joka säätelee todellista maailmaa”. Esimerkiksi,

Jos tilanne ●● tapahtuu, A:n on maksettava B:lle miljoona jeniä korvauksena.

Tällainen sopimus määrittelee tulevien tapahtumien ehdot ja vaikutukset.

Ja tämän “todellista maailmaa säätelevän ohjelman” tarkistaminen ongelmien varalta ja niiden korjaaminen, jos niitä ilmenee, on työ, joka on hyvin samankaltainen kuin “debuggaus”.

Sopimuksessa ei ole kuvattu algoritmin koko kuva

Kuitenkin, “sopimuksessa” on yksi kohta, joka voi olla vaikea ymmärtää niille, jotka eivät ole erikoistuneet lakiin, mutta se on erittäin tärkeä. Sopimus määrittelee vain “osan” algoritmista, joka säätelee osapuolten välistä suhdetta. Toisin sanoen, pelkästään sopimusta lukemalla et voi tietää koko kuvaa siitä, miten sinä ja toinen osapuoli säännellään minkä algoritmin mukaan.

Esimerkiksi, kun ostat käytetyn CD:n kaupasta, kauppa ja asiakas eivät solmi “kauppasopimusta”, mutta jos ostamasi CD:n pinnalla on naarmu, joka estää sen toistamisen soittimessa, haluat valittaa kaupalle ja odotat, että kauppa vastaa siihen. Tämä ei ole vain “koska se on palvelualan yritys” -tasoinen keskustelu, vaan teoreettisesti,

1. Sopimus on solmittu, vaikka sopimusta ei olisi
2. Siviililaki (Japanin siviililaki) määrää, että myyjällä on virhevastuu käytettyjen CD-levyjen (kutsutaan “erityisiksi esineiksi”) myyntisopimuksissa
3. Siksi siviililain määrittelemä algoritmi toimii kaupan ja asiakkaan välillä, ja kaupalla on virhevastuu

Tämä on logiikka. Ja “sopimus” on jotain, joka korvaa algoritmin, jonka siviililaki ja muut lait määrittelevät. Esimerkiksi, jos kaupan ja asiakkaan välillä on vaihdettu sopimus, jossa sanotaan “emme hyväksy jälkikäteen tehtyjä valituksia CD:n kaikista vioista”,

1. Kauppasopimus on solmittu
2. Siviililaki määrää, että myyjällä on virhevastuu tähän sopimukseen
3. Kuitenkin, sopimuksen määräysten mukaan, periaate 2 korvataan, eikä kaupalla ole virhevastuuta

Tämä on tilanne.

Sopimukset “korvaavat” siviililain ja muiden periaatteiden

Tämä pätee myös yritysten välisiin sopimuksiin, kuten järjestelmäkehitykseen. Esimerkiksi, jos kahden osapuolen välillä on tehty sopimus järjestelmän kehittämisestä,

1. sopimuksen tekeminen vahvistaa selkeästi, että sopimus on tehty
2. sopimuksen tapauksessa siviililaki määrää, että vastaanottajalla on virhevastuu
3. jos sopimuksessa on määräys virhevastuusta, tämä määräys korvaa siviililain periaatteen. Esimerkiksi, jos sopimuksessa on määräys pidemmästä virhevastuusta kuin siviililain periaate, tämä määräys on voimassa

Tämä on rakenne. Toisin sanoen, vaikka sopimuksessa ei olisi erityistä määräystä virhevastuusta, virhevastuu syntyy.

Tämä ei rajoitu vain sopimukseen tai järjestelmän kehittämiseen, vaan koskee yleisesti kaikkia yritysten tekemiä sopimuksia, kuten osakkeiden luovutusta, rahoituksen hankkimista velalla (laina), työllistämistä, osakkeiden liikkeeseenlaskua jne.

Siksi pelkästään sopimusta lukemalla et voi ymmärtää koko kuvaa “algoritmista”, joka säätelee suhdettasi toiseen osapuoleen. Jotta voisit ymmärtää koko kuvan, sinun on ymmärrettävä “oletusarvoinen algoritmi”, jonka laki, kuten siviililaki, määrittelee. Sopimus on vain keino korvata tämä “oletusarvoinen algoritmi”.

Ellei tulevia tapahtumia voida ennakoida, “debuggaus” ei ole mahdollista

Pelkästään algoritmin ymmärtäminen ei riitä, sillä emme voi varmistaa, ettei “algoritmi aiheuta odottamattomia toimintoja”. Kuten pelien “bugien” kohdalla, algoritmi on loppujen lopuksi abstrakti asia, eikä tulevia tapahtumia voida ennakoida. Ellei tulevia tapahtumia voida ennakoida, emme voi varmistaa, ettei “tällaisissa tapahtumissa ilmene odottamattomia toimintoja”.

Tämä on erityisen merkittävä ongelma uusien sovellusten, palveluiden ja muiden tuotteiden, sekä uusien liiketoimintamallien kohdalla. Kun tällaisia tuotteita tai malleja käytetään liiketoiminnan kehittämiseen, on tärkeää ennakoida, mitä tulevaisuudessa voi tapahtua. Tämä on vaikeaa, ellei alalla ole erityistä tietämystä. Lisäksi, erityisesti yritysten välisissä sopimuksissa, sekä sopijapuolen että oman yrityksen on toimittava taloudellisesti järkevästi. Tulevien tapahtumien ja niitä aiheuttavien toimijoiden toiminnan ennustamiseksi tarvitaan myös peliteoreettista ajattelua yritysjohtamisessa.

“Ennakoimaton” perustuu myös johtamispäätökseen

Lisäksi, samalla tavalla kuin tietokoneen sijaan ihminen päättää, onko jokin tapahtuma “bugi”, myös sopimuksen tuottaman seurauksen “ennakoimattomuuden” määrittäminen ei ole pelkästään oikeudellinen kysymys, vaan se liittyy johtamispäätökseen.

Esimerkiksi, on mahdollista, että “siviililain periaatteiden mukainen” algoritmi ei ole hyväksyttävä tietyssä yrityksessä tietyssä liiketoiminnassa. Tämä esimerkki eroaa aiemmista, mutta esimerkiksi siviililaki määrittelee oletusalgoritmin, jonka mukaan alihankkijan käyttö on sopimusrikkomus. Kuitenkin, on olemassa tilanteita, joissa “tietyn yrityksen tietty liiketoiminta olettaa alihankkijan käytön”. Tällaisissa tapauksissa ei pitäisi olla mahdollista hyväksyä sopimusta, joka ei salli alihankintaa, eli

• sopimusta, jossa ei mainita mitään alihankinnan mahdollisuudesta (tässä tapauksessa, kuten edellä mainittiin, sovelletaan siviililain periaatteita)
• sopimusta, jossa todetaan, että alihankinta ei ole mahdollista

vaikka se olisikin “siviililain periaatteiden mukainen”.

Lisäksi, johtamisessa on aina olemassa riski, että “tietyissä olosuhteissa joudutaan ottamaan vastuu”. Periaatteessa ei ole olemassa sopimusta, jossa ei olisi mitään “riskiä” omalle yritykselle. Se, hyväksytäänkö tämä riski vai ei, on lopulta johtamispäätös. Johtamispäätöksen tekee johtaja, ei konsultti, kuten lakimies, mutta konsultin tulisi esittää tarvittavat tiedot johtamispäätöksen tekemiseksi, kuten

• riskejä, joita ei tarvitse erikseen mainita
• riskejä, jotka vaativat merkittävän päätöksen yritykseltä ja jotka saattavat vaatia kokouksen tai vastaavan

Nämä on esitettävä selkeästi. Tämän “selkeyden” asettamiseksi myös sopimusten tarkastukseen osallistuvalla lakimiehellä on oltava tietty määrä “johtamistuntemusta”, kuten muillakin konsultointialoilla.

Yhteenveto

Kuten näemme, sopimusten tarkistaminen ja korjaaminen koostuu pääasiassa seuraavista tehtävistä:

1. Ymmärtää, miten sopimus muuttaa siviililain ja muiden periaatteiden soveltamista, ja millaiseksi algoritmiksi se muodostuu
2. Arvioida, millaisia tapahtumia voi tulevaisuudessa syntyä tämän algoritmin puitteissa
3. Tarkistaa, ettei odottamattomia toimintoja tapahdu

Ja nämä tehtävät ovat:

1. Vaikeita ilman lakien ymmärtämistä
2. Vaikeita ilman ymmärrystä sopimuksen sääntelemästä toiminnasta, kuten sovelluksista tai verkkopalveluista, liiketoimintamalleista jne.
3. Vaikeita ilman yrityksen tai liiketoiminnan sisällön ja liikkeenjohdon tuntemusta

Tämä on siis tilanne.

Sopimusten tarkistaminen ja korjaaminen on erittäin “erikoistunutta” työtä näistä syistä.

Sopimusten laadinta ja tarkastus Monolis Lakitoimistossa

Monolis Lakitoimistossa tarjoamme IT-, internet- ja liiketoimintaosaamiseen perustuvana lakitoimistona erilaisia palveluita, kuten sopimusten laadintaa ja tarkastusta neuvonantajayrityksillemme ja asiakasyrityksillemme.

Jos olet kiinnostunut, katso lisätietoja alla.