Az IT mérnökből lett ügyvéd magyarázza a szerződések ellenőrzésének és a hibakeresés hasonlóságait

Az úgynevezett “vállalati tanácsadó ügyvédek” munkájának középpontjában a vállalat által nap mint nap ügyfelekkel és üzleti partnerekkel kötött szerződések ellenőrzése és módosítása áll. És ezeket az ellenőrzéseket és módosításokat csak olyan személy végezheti el megfelelően, aki “jól ismeri a jogot és az adott üzleti területet”. Megmagyarázom, hogy miért van ez így.

Az alábbi magyarázatot azonban valószínűleg nehezen érthetik meg azok, akik nem mérnökök vagy nem rendelkeznek programozási tapasztalattal. A Monolith Ügyvédi Iroda egy olyan ügyvédi iroda, amelynek vezetője korábbi IT mérnök és vállalati vezető. Ez a cikk tehát “egy korábbi IT mérnök és vállalati vezető által vezetett ügyvédi iroda szempontjából, mérnököknek és programozási tapasztalattal rendelkező vezetőknek magyarázza el a szerződések ellenőrzését és módosítását”.

És ebben a kontextusban a szerződések ellenőrzése és módosítása hasonló munka, mint az úgynevezett “debugging”.

1. Mi az a “bug”?
2. Milyen munka a “debugging”?
3. Hogyan határozza meg a szerződés az algoritmust?
4. Milyen munka a szerződés módosítása?

Ez a sorrend, tehát az mérnökök számára “természetes” dolgokkal kezdődik, de alább magyarázom.

Mi a “bug” és a “debug”?

A “bug” nem egyenlő a “PC hibával”

Amikor “bug”-ról beszélünk, lehet, hogy olyan kép jut eszébe, mint amikor a PC-n dolgozik, és füst kezd kijönni a gépből, a képernyő pedig furcsa dolgokat mutat… Azonban a PC alapvetően csak azt csinálja, amit “megmondunk” neki. Ez a “bug” esetében is így van. Tehát a “bug” azt jelenti, hogy:

• A PC pontosan úgy működik, ahogy azt mondtuk neki,
• de a felhasználó számára ez a működés “váratlan viselkedés”.

Ez a jelenség.

Miért fordul elő a “nem várt viselkedés”

Gondoljunk például a Mario típusú akciójátékok “fal áthatolás” hibájára.

Mario ugrása egy másodfokú függvény. Gyorsulás, sebesség, koordináták. Azonban, bár ez egy másodfokú függvény, például “Mi az Y értéke, ha X=1.76582?”, az X-et végtelenül apróra lehet osztani, de a televíziós játékok esetében az időt nem lehet végtelenül apróra osztani. Ez azért van, mert a képernyő csak másodpercenként (például) 30-szor vált. Tehát, gyakorlatilag, Mario másodpercenként 30-szor “teleportál”.

Ez alapján, például, ha “Mario ugrás közben a levegőben lévő falba ütközik és visszapattan”, akkor ez a következő esetekben fordul elő:

1. Mario az előző pillanatban még a levegőben volt
2. A következő pillanatban Mario koordinátái a falban vannak

Ez az a helyzet.

Ilyen esetekben megállapítható, hogy “Mario ugrás közben a levegőben lévő falba ütközött”. Tehát, természetes nyelven kifejezve:

Ha Mario koordinátái a falban vannak, akkor végrehajtjuk a visszapattanás folyamatát (※1)

Ha ezt a programot írjuk, akkor megvalósítható a “Mario ugrás közben a levegőben lévő falba ütközik és visszapattan” folyamat.

※1, amint azt a fenti példa is mutatja, helyesnek tűnik. És valóban, “bizonyos feltételek mellett” ez a folyamat helyes.

De ha jobban belegondolunk, a következő eset is lehetséges (※2).

Ebben az esetben, “Mario koordinátái a falban vannak” pillanat nem létezik, tehát a visszapattanás folyamat nem hajtódik végre, és Mario átsiklik a falon.

Ez egy “hiba” példa. Ha ilyen okokból “fal áthatolás hiba” fordul elő, az nem jelenti azt, hogy a PC hibás. A PC csak azt a viselkedést hajtja végre, amit mondtak neki, és azt, hogy ez a viselkedés “nem várt” vagy “hiba”, az emberek értékelik. És ez a “hiba” azért fordul elő, mert az algoritmus nem megfelelő.

“A váratlan működés lehetőségének” vizsgálata

Az azonban nem biztos, hogy a játék során a fent említett “fal áthatolás” bekövetkezik-e, ha csak absztrakt módon gondolkodunk róla. A “fal áthatolás” lehetősége attól függ,

• milyen a Mario ugróereje (kezdősebesség), van-e olyan tárgy, ami növeli az ugróerőt
• milyen vastag a fal a legvékonyabb pontján

Ez a feltételektől függ. Attól függ, hogy a ※2 jelű eset lehetséges-e ezekkel a feltételekkel. Ha a ※2 nem lehetséges, akkor a ※1 programban nincs probléma.

Mi is pontosan a “debuggolás” munkafolyamata?

Ezért a “debuggolás”, vagyis a hibák feltárása és javítása munkafolyamata során a következő lépésekre van szükség:

1. Meg kell érteni, hogy milyen algoritmus a program (a fenti példa természetes nyelven van, de a programokat saját nyelven írják, ezért az olvasás önmagában nehéz)
2. Meg kell vizsgálni, hogy a program milyen feltételek mellett működik (pl. a ugróképesség vagy a fal vastagságának vizsgálata)
3. Meg kell vizsgálni, hogy nem fordul-e elő váratlan viselkedés

Ezért szükséges ez a folyamat.

Milyen munka a szerződések ellenőrzése?

A szerződések ellenőrzése hasonló munka. Alapvetően a szerződés olyan dokumentum, amely a felek, azaz az A és B közötti jövőbeni eseményeket veszi figyelembe, és meghatározza, milyen jogok és kötelezettségek keletkeznek ezen események bekövetkeztekor, és ennek eredményeként hogyan cselekszenek a felek. Ebben az értelemben a szerződés olyan ‘program’, amely szabályozza a valós világot. Például,

Ha a ●● helyzet bekövetkezik, az A félnek 1 millió jent kell fizetnie B félnek kártérítésként.

A szerződés, amely ilyen szabályokat határoz meg, meghatározza a jövőbeni események feltételeit és hatásait.

És a ‘valós világot szabályozó program’ ellenőrzése, hogy nincs-e benne hiba, és ha van, javítása, nagyon hasonló a ‘debugging’-hoz.

A szerződésben az algoritmus teljes képe nem szerepel

Van azonban egy rendkívül fontos pont a “szerződés” kapcsán, amit a jogi szakemberek könnyen megértenek, de a laikusok számára nehezebb. A szerződés csupán az algoritmus “részét” szabályozza, amely a felek közötti viszonyt szabályozza. Más szóval, a szerződés elolvasásával önmagában nem lehet megismerni az algoritmus teljes képét, amely alapján a felek viszonyát szabályozzák.

Például, ha használt CD-t vásárolunk egy boltban, a bolt és a vásárló nem köt “adásvételi szerződést”, de ha a CD-n olyan karcolás van, ami miatt nem játszható le a lejátszón, panaszt szeretnénk tenni a boltban, és elvárjuk, hogy a bolt megfelelően reagáljon. Ez nem csak a “szolgáltatásipar” szintjén értelmezhető, hanem elméleti szinten is:

1. A szerződés nélkül is létrejön az adásvételi szerződés
2. A Polgári Törvénykönyv (a ‘japán Polgári Törvénykönyv’) előírja, hogy a használt CD-k (amelyeket “meghatározott dolgoknak” neveznek) eladásával kapcsolatos szerződés esetén az eladónak hibás teljesítésért való felelőssége keletkezik
3. Ezért a Polgári Törvénykönyv által meghatározott algoritmus működik a bolt és a vásárló között, és a bolt hibás teljesítésért felelős

Ez a logika. A “szerződés” felülírja a Polgári Törvénykönyv és más jogszabályok által meghatározott algoritmust. Például, ha a bolt és a vásárló között létezik egy olyan szerződés, amely szerint “a bolt nem fogad el utólagos panaszt a CD bármilyen hibájával kapcsolatban”, akkor:

1. Létrejön az adásvételi szerződés
2. A Polgári Törvénykönyv előírja, hogy az adott szerződés esetén az eladónak hibás teljesítésért való felelőssége keletkezik
3. De a szerződés rendelkezéseinek értelmében a 2. pontban foglalt alapelv felülíródik, és a bolt nem vállal felelősséget a hibás teljesítésért

Ez a helyzet.

A szerződések a polgári törvénykönyv és más alapelveket „felülírják”

Ez a rendszerfejlesztés és más, vállalatok között kötött szerződések esetében is igaz. Például, ha egy vállalkozási szerződés jött létre két fél között a rendszerfejlesztésre,

1. A szerződés megkötésével egyértelműen létrejön a vállalkozási szerződés
2. A vállalkozási szerződés esetében a polgári törvénykönyv (japán Polgári Törvénykönyv) előírásai szerint a megbízott félre hibáztatási felelősség hárul
3. Ha a szerződésben van hibáztatási felelősségre vonatkozó rendelkezés, akkor ez a rendelkezés felülírja a polgári törvénykönyv 2. alapelvét. Például, ha hosszabb időszakra szóló hibáztatási felelősségi záradékot állapítanak meg, mint a polgári törvénykönyv alapelve, akkor ez az időszak érvényes lesz

Ez a szerkezet. Vagyis, még ha a szerződésben nincs is külön rendelkezés a hibáztatási felelősségről, a hibáztatási felelősség mégis felmerül.

Ez nem korlátozódik kizárólag a vállalkozásra vagy a rendszerfejlesztésre, hanem általánosan érvényes minden olyan szerződésre, amelyet a vállalatok kötnek, legyen szó részvények átruházásáról, adósságfinanszírozásról (pénzügyi kölcsön), foglalkoztatásról, részvénykibocsátásról stb.

Ezért a szerződés olvasása önmagában nem elegendő ahhoz, hogy teljes képet kapjunk a másik féllel és a saját vállalatunkkal kapcsolatos “algoritmusokról”. Ahhoz, hogy teljes képet kapjunk, meg kell értenünk a “polgári törvénykönyv és más törvények által meghatározott alapértelmezett algoritmusokat”. A szerződés csupán ezt az “alapértelmezett algoritmust” írja felül.

Nem lehet “debuggolni”, ha nem tudjuk előre látni a jövőben bekövetkezhető eseményeket

Az algoritmusok megértése önmagában nem elegendő ahhoz, hogy ellenőrizzük, “nem fordul-e elő váratlan működés az adott algoritmus használata során”. Ez a játékok “bugjaihoz” hasonlóan működik, az algoritmusok csupán absztrakt entitások, és ha nem tudjuk előre látni, milyen események történhetnek a jövőben, akkor nem tudjuk ellenőrizni, “nem válik-e váratlan működéssé, ha ilyen események következnek be”.

Ez különösen fontos olyan esetekben, mint az új alkalmazások, szolgáltatások és egyéb termékek, vagy az új üzleti modellek. Ha ilyen termékekkel vagy modellekkel terjeszkedünk, fontos előre látni, milyen dolgok történhetnek a jövőben. Ez nehéz lehet, ha nincs megfelelő ismeretünk az adott területről. Különösen igaz ez a vállalatok közötti szerződések esetében, ahol mindkét fél gazdaságilag ésszerű módon cselekszik. A jövőbeli események, és azokat előidéző másik fél cselekedeteinek előrejelzéséhez szükség van a vállalati menedzsmenthez kapcsolódó játékelméleti gondolkodásra is.

Az „előre nem látható” események kezelése is a vállalati döntéshozatal része

Továbbá, ahogyan a számítógép helyett az ember dönti el, hogy egy esemény „hiba”-nak minősül-e, úgy a szerződés által előidézett következmények „előre nem látható” jellegének megítélése sem csupán jogi kérdés, hanem vállalati döntéshozatali probléma.

Például előfordulhat, hogy egy vállalat egy adott üzletágában nem fogadja el a „polgári jogi alapelvek szerinti” algoritmust. Bár ez eltér az eddigi példáktól, a polgári törvénykönyv (japán Polgári Törvénykönyv) alapértelmezett algoritmusaként meghatározza, hogy a megbízott személy általi további megbízás szerződésszegésnek minősül. Azonban előfordulhat, hogy „egy adott vállalat számára egy adott üzletágban természetes, hogy alvállalkozókat használ”. Ilyen esetekben a további megbízásokat kizáró szerződések, azaz

• a további megbízások lehetőségét nem említő szerződések (ebben az esetben, ahogy korábban említettük, a polgári jogi alapelvek érvényesülnek)
• a további megbízások lehetetlenségét kifejezetten megjelölő szerződések

elfogadása nem lehetséges, még akkor sem, ha ezek „a polgári jogi alapelvek szerint” működnek.

Ezenkívül a vállalatirányításban mindig jelen van a „bizonyos okokból bekövetkező felelősségvállalás” kockázata. Alapvetően nincsenek olyan szerződések, amelyek „kockázatmentesek” a vállalat számára. A kockázat elfogadása végül is vállalati döntés. A döntést a vállalatvezető hozza meg, nem pedig a tanácsadó jogászok vagy más tanácsadói pozícióban lévő személyek, de a tanácsadóknak meg kell adniuk a vállalatvezetőnek a döntéshozatalhoz szükséges és elegendő információkat, mint például:

• a figyelmeztetést nem igénylő kockázatok
• a vállalat számára jelentős döntést igénylő kockázatok, amelyek esetlegesen megbeszélést igényelnek

Ezeket a kockázatokat megfelelő hangsúllyal kell kiemelni. Ennek a „hangsúlyozásnak” a beállításához, akárcsak más területeken dolgozó tanácsadók esetében, a szerződések ellenőrzését végző jogásznak is szüksége van bizonyos mértékű „vállalatirányítási” érzékre.

Összefoglalás

A szerződések ellenőrzése és módosítása tehát nagyjából a következő feladatokból áll:

1. Megérteni, hogy a szerződés hogyan írja felül a Polgári Törvénykönyv és más alapelveket, és ennek eredményeként milyen algoritmust alkot
2. Megvizsgálni, hogy az algoritmus alapján milyen események fordulhatnak elő a jövőben
3. Megvizsgálni, hogy nem fordul-e elő váratlan viselkedés

És mindezek:

1. Nehezek azok számára, akik nem értik a jogot
2. Nehezek azok számára, akik nem értik a szerződés által szabályozott dolgokat, például az alkalmazásokat, webes szolgáltatásokat, üzleti modelleket stb.
3. Nehezek azok számára, akik nem értik a vállalat vagy üzleti tevékenység tartalmát, üzleti érzékét

Éppen ezért a szerződések ellenőrzése és módosítása nagyon “szakmai” feladat.

Szerződéskészítés és -felülvizsgálat a mi irodánk által

A Monolis Jogi Iroda, mint az IT, internet és üzleti jog területén kiemelkedő szakértelemmel rendelkező iroda, különböző szerződések készítését és felülvizsgálatát kínálja tanácsadói és ügyfélvállalataink számára.

Ha érdekli, kérjük, tekintse meg a részleteket az alábbiakban.

https://monolith.law/contractcreation[ja]