Endine IT-insenerist advokaat selgitab lepingu kontrollimise ja silumise sarnasusi

Niin-öelda “ettevõtte nõustajate advokaatide” töö keskmes on ettevõtte poolt igapäevaselt klientide ja äripartneritega sõlmitavate lepingute kontrollimine ja parandamine. Ja sellist kontrolli ja parandamist ei saa täielikult läbi viia, kui tegemist pole “inimesega, kes on põhjalikult kursis nii õiguse kui ka selle äritegevuse valdkonnaga”. Selgitan, miks see nii on.

Kuid allpool toodud selgitus võib olla raskesti mõistetav neile, kes pole insenerid ega ole programmeerimiskogemusega. Monolith Advokaadibüroo on advokaadibüroo, mille juhiks on endine IT-insener ja ettevõtte juht. See on positsioneeritud kui “artikkel, mis selgitab lepingute kontrollimist ja parandamist, suunatud juhtidele, kellel on inseneri- või programmeerimiskogemus, advokaadibüroo, mille juhiks on endine IT-insener ja ettevõtte juht”.

Ja selle positsioneerimise põhjal on lepingute kontrollimine ja parandamine töö, mis on sarnane nn “debugimisega”.

1. Mis on “bug” algusest peale
2. Mis on “debugimise” töö
3. Kuidas lepingud määravad algoritmi
4. Mis on lepingute parandamise töö

Kuigi see on inseneridele “ilmselge” jutt, alustan sellest, ja selgitan allpool.

Mis on “bug” ja “debug”?

Viga ei tähenda “arvuti riket”

Kui öelda “viga”, võib mõnel inimesel tekkida ettekujutus, et arvutiga töötades hakkab masinast suitsu tulema ja ekraanil kuvatakse kummalisi sümboleid… Kuid arvuti teeb põhimõtteliselt ainult seda, mida talle öeldakse. See kehtib ka vigade ilmnemise korral. Seega “viga” tähendab:

• Arvuti teeb täpselt seda, mida talle öeldakse, kuid
• Kasutaja jaoks on see käitumine “ootamatu”

See on see nähtus.

Miks tekivad “oletamata käitumised”?

Vaatleme näiteks “seina läbimise” viga Mario-tüüpi tegevusmängus.

Mario hüpe on teise astme funktsioon. Kiirendus, kiirus, koordinaadid. Kuid kuigi see on nn teise astme funktsioon, saab X-i lõpmata peenelt jaotada, näiteks “Mis on Y, kui X=1.76582?”. Kuid videomängude puhul ei saa aega lõpmata peenelt jaotada. Ekraan vahetub ainult 30 korda sekundis. Seega, nagu öeldakse, teeb Mario iga sekund 30 “hüpet”.

Selle põhjal, kui näiteks “Mario hüppas ja põrkas tagasi, sest üleval oli sein”, siis mis juhtum see on?

1. Mario oli eelmisel hetkel õhus
2. Järgmisel hetkel on Mario koordinaadid seina sees

Selline on olukord.

Sellisel juhul saab otsustada, et “Mario põrkas hüppamise ajal vastu seina üleval”. Seega, kui me räägime loomulikus keeles

Kui Mario koordinaadid on seina sees, tehakse põrkeprotsess (※1)

Kui kirjutate sellise programmi, saate teostada protsessi “Mario hüppas ja põrkas tagasi, sest üleval oli sein”.

※1 tundub õige, kui kirjutada nagu ülal. Ja tegelikult, “teatud tingimustel” on see protsess õige.

Kuid kui mõelda hoolikalt, võib esineda ka järgmisi olukordi (※2).

Selles olukorras ei ole “Mario koordinaadid on seina sees” hetke ja seega ei toimu põrkeprotsessi ning Mario libiseb läbi seina.

See on “vea” näide. Isegi kui sellisel põhjusel tekib “seina läbimise viga”, ei tähenda see, et arvuti oleks rikkis. Arvuti teeb ainult seda, mida talle öeldakse, ja inimene hindab seda käitumist kui “oletamata” või “viga”. Ja see “viga” tekib, sest algoritm pole sobiv.

“Eeldamatute toimingute tekkimise” kaalumine

Kuid, kas mängu mängimise käigus tekib eelmainitud “seinast läbiminek” või mitte, ei ole võimalik ainult abstraktselt mõeldes kindlaks teha. “Seinast läbimineku” võimalikkus sõltub järgmistest tingimustest:

• Kui suur on Mario hüppejõud (algkiirus) ja kas on olemas selliseid esemeid nagu hüppejõu suurendamine?
• Kui paks on sein kõige õhemas kohas?

See sõltub nendest tingimustest. Sõltuvalt sellest, kas võib esineda olukordi nagu märkus 2, on olukord selline. Kui märkus 2 ei ole võimalik, siis märkus 1 programm ei ole probleem.

Mis on “debugimine”?

Seega, “debugimine”, ehk vead leidmine ja nende parandamine, nõuab järgmisi samme:

1. Programmi algoritmi lugemine ja mõistmine (kuigi ülaltoodud näide on loomulikus keeles, on tegelikud programmid kirjutatud erikeeltes, mis muudab nende mõistmise keeruliseks)
2. Arutelu selle üle, kuidas programm toimib teatud tingimustel (näiteks hüppevõime või seina paksuse uurimine)
3. Kontrollimine, kas ei esine ootamatuid käitumisi

See on protsess, mis on vajalik.

Mis on lepingu kontrollimise töö?

Lepingute kontrollimine on sarnane protsess. Lõppude lõpuks on leping dokument, mis reguleerib osapoolte, A ja B, tulevaste sündmuste eeldusi, millised õigused ja kohustused neil tekivad, ja selle tulemusena, kuidas mõlemad pooled käituvad. Selles mõttes võib seda nimetada “programmiks, mis reguleerib reaalset maailma”. Näiteks,

Kui tekib olukord ●●, peab A maksma B-le 1 miljonit jeeni hüvitist.

Sellised lepingud, mis reguleerivad tulevasi sündmusi, määratlevad tingimused ja mõjud.

Ja see töö, mis kontrollib, kas “programmil, mis reguleerib reaalset maailma”, on probleeme ja parandab need, kui need on olemas, on paratamatult sarnane “silumisega”.

Lepingus ei ole algoritmi täielikku pilti kirjeldatud

Kuid “lepingul” on üks punkt, mis võib olla keeruline mõista neile, kes ei ole spetsialiseerunud õigusele, kuid on äärmiselt oluline. Leping on algoritm, mis reguleerib osapoolte vahelist suhet, kuid määratleb ainult selle “osa”. Teisisõnu, ainult lepingu lugemisest ei piisa, et mõista, millise algoritmi alusel teie ja teie partnerit reguleeritakse, te ei saa teada kogu pilti.

Näiteks kui ostate kasutatud CD poest, ei sõlmi pood ja klient midagi sellist nagu “müügileping”, kuid kui ostetud CD-l on mängijas mängimiseks kõlbmatu kriimustus, soovite kaebuse esitada poele ja ootate, et pood vastab sellele. See pole lihtsalt “teenindusäri” tasemel, vaid teoreetiliselt,

1. isegi kui lepingut pole, on müügileping sõlmitud
2. tsiviilseadus (Jaapani tsiviilseadus) sätestab, et müüja peab vastutama defektide eest kasutatud CD-de ja muude “konkreetsete asjade” müügilepingute puhul
3. seega, tsiviilseaduse määratud algoritm töötab poe ja kliendi vahel ning pood vastutab defektide eest

See on loogika. Ja “leping” on dokument, mis kirjutab üle tsiviilseaduse ja muude seaduste poolt määratud algoritmi. Näiteks, kui pood ja klient on sõlminud lepingu, mis ütleb, et “me ei aktsepteeri mingeid kaebusi CD defektide kohta pärast ostu”, siis

1. müügileping on sõlmitud
2. tsiviilseadus (Jaapani tsiviilseadus) sätestab, et müüja peab vastutama defektide eest selles lepingus
3. kuid lepingu sätete kohaselt kirjutatakse üle 2. põhimõte ja poel ei teki defektide eest vastutust

See on loogika.

Lepingud “kirjutavad üle” tsiviilseaduse ja muude põhimõtete

See kehtib ka süsteemiarenduse ja muude ettevõtete vahel sõlmitavate lepingute puhul. Näiteks kui A ja B vahel on sõlmitud süsteemiarenduse leping, siis:

1. Leping sõlmitakse selgelt, luues süsteemiarenduse lepingu
2. Süsteemiarenduse lepingu puhul tekib tsiviilseaduse kohaselt vastuvõtjale defekti tagatise kohustus
3. Kui lepingus on defekti tagatise kohustuse säte, siis see säte kirjutab üle tsiviilseaduse põhimõtte. Näiteks, kui on ette nähtud defekti tagatise kohustuse periood, mis on pikem kui tsiviilseaduse põhimõte, siis see perioodi säte on kehtiv

See on struktuur. Teisisõnu, isegi kui lepingus pole eraldi defekti tagatise kohustuse sätet, tekib defekti tagatise kohustus.

See ei ole piiratud ainult süsteemiarenduse või lepingutega, vaid see on üldine arutelu kõigi lepingute kohta, mida ettevõtted teevad, sealhulgas aktsiate üleandmine, rahastamine võlgade kaudu (laenamine), tööhõive, aktsiate väljaandmine jne.

Seega, ainult lepingu lugemisest ei piisa, et mõista “algoritmi”, mis reguleerib suhteid teie ja teise poole vahel. Selleks, et mõista kogu pilti, peate mõistma “vaikimisi algoritmi”, mida määravad tsiviilseadus ja muud seadused. Lepingud on lihtsalt need, mis “kirjutavad üle” selle “vaikimisi algoritmi”.

Tulevaste sündmuste ettenägemata jätmine ei võimalda “silumist”

Algoritmi mõistmine üksi ei võimalda meil kontrollida, kas “see algoritm ei põhjusta ootamatut käitumist”. Nagu mängude “vead”, on algoritm ainult abstraktne mõiste ja kui me ei suuda ette näha, millised sündmused võivad tulevikus tekkida, ei saa me kontrollida, kas “selliste sündmuste ilmnemisel ei teki ootamatut käitumist”.

See on eriti oluline uute rakenduste, teenuste ja muude toodete, uute ärimudelite puhul. Kui selliseid tooteid või skeeme kasutatakse äritegevuse laiendamiseks, tuleb mõelda, mis võib tulevikus juhtuda. See on keeruline, kui puuduvad teadmised vastavast valdkonnast. Lisaks, eriti äriühingute vaheliste lepingute puhul, tegutsevad nii teine ​​äriühing kui ka teie enda äriühing teatud majandusliku ratsionaalsuse alusel, seega on tulevaste sündmuste ja nende põhjustatud tegevuste ennustamiseks vajalik ka mänguteooria mõtlemine ärijuhtimises.

Kas on “ootamatu” sõltub ka juhtimisotsusest

Lisaks, nagu arvuti asemel inimene otsustab, kas teatud sündmus on “viga”, nii on ka lepingu teatud tagajärgede “ootamatuse” otsustamine mitte ainult puhtalt õiguslik küsimus, vaid ka juhtimisalane küsimus.

Näiteks võib olla reaalne olukord, kus “Tsiviilseadustiku põhimõtete järgi” algoritm on teatud ettevõtte teatud äritegevuse jaoks vastuvõetamatu. Kuigi see on erinev eelnevatest näidetest, määrab tsiviilseadustik näiteks pooltevahelise lepingu puhul, et “edasine delegeerimine on lepingurikkumine” vaikimisi algoritm. Kuid võib olla olukordi, kus “teatud ettevõtte jaoks on teatud äritegevus loomulikult eeldatav alltöövõtja kasutamisega”. Sellistes olukordades ei tohiks olla võimalik aktsepteerida lepingut, mis ei võimalda edasist delegeerimist, st

• midagi pole öeldud edasise delegeerimise võimaluse kohta (sel juhul kohaldatakse tsiviilseadustiku põhimõtteid nagu eespool mainitud)
• on selgelt märgitud, et edasine delegeerimine on võimatu

isegi kui see on “Tsiviilseadustiku põhimõtete järgi”, ei tohiks see olla võimalik.

Lisaks on juhtimises alati olemas risk, et “teatud asjaolude ilmnemisel tuleb vastutus võtta”. Lepingud, mis ei kujuta endast “riski” ettevõttele, ei ole põhimõtteliselt olemas. Kas aktsepteerida seda riski või mitte, on lõppkokkuvõttes juhtimisotsus. Juhtimisotsuse teeb juht, mitte nõuandja või advokaat, kuid nõuandja peaks esitama piisavalt teavet, et juht saaks teha juhtimisotsuse,

• riskid, mida pole vaja iga kord märkida
• riskid, mida tuleb aktsepteerida kui olulist otsust ettevõtte jaoks, mõnel juhul võib olla vajalik koosolek jne

ja neid tuleb märkida erineva intensiivsusega. Selle “intensiivsuse” seadmiseks on vaja ka advokaadil, kes kontrollib lepinguid, teatud määral “juhtimise” tunnetust, nagu ka teiste valdkondade nõustajatel.

Kokkuvõte

Nagu näha, võib öelda, et lepingu kontrollimine ja parandamine hõlmab suuresti järgmisi tegevusi:

1. Mõistmine, kuidas leping muudab tsiviilseaduse ja teiste põhimõtete kohaselt ning milliseks algoritmiks see lõpptulemusena muutub
2. Arutelu selle üle, milliseid sündmusi võib tulevikus selle algoritmi alusel tekkida
3. Arutelu selle üle, kas ei teki ootamatuid käitumisi

Ja ülaltoodud on igaüks

1. Raske ülesanne neile, kes ei mõista seadust
2. Raske ülesanne neile, kes ei mõista lepingu reguleerimist, näiteks äri sisu, ärimudelid nagu rakendused või veebiteenused
3. Raske ülesanne neile, kes ei mõista ettevõtte või äri sisu, juhtimistunnetust teatud määral

See on põhjus.

Lepingu kontrollimine ja parandamine on sellistel põhjustel väga “spetsialiseerunud”.

Meie büroo poolt lepingute koostamise ja ülevaatamise teenuste tutvustus

Monolis õigusbüroo on IT, interneti ja äriõiguse valdkonnas tugevaid külgi omav õigusbüroo, mis pakub erinevate lepingute koostamise ja ülevaatamise teenuseid meie nõustatavatele ettevõtetele ja klientidele.

Kui olete huvitatud, vaadake kindlasti allpool toodud üksikasju.

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