En tidligere IT-ingeniør og advokat forklarer lighederne mellem kontraktgennemgang og fejlfinding

Kernen i arbejdet for det såkaldte “firmaets rådgivende advokat” er at kontrollere og rette kontrakter, som virksomheden indgår dagligt med klienter og forretningspartnere. Og disse kontroller og rettelser kan kun udføres tilstrækkeligt af en person, der er bekendt med både loven og det pågældende forretningsområde. Lad os forklare hvorfor.

Imidlertid kan følgende forklaring være svær at forstå for dem, der ikke har erfaring med ingeniørarbejde eller programmering. Monolith Law Office er et advokatfirma ledet af en tidligere IT-ingeniør med erhvervsledelseserfaring. Det er strengt taget positioneret som en “artikel, der forklarer kontrakt kontrol og revisioner til ledere med erfaring i ingeniørarbejde eller programmering, fra perspektivet af et advokatfirma ledet af en tidligere IT-ingeniør og erhvervsleder”.

Og med denne positionering i tankerne, er kontrol og revision af kontrakter en opgave, der ligner den såkaldte “debugging”.

1. Hvad er en “bug” i første omgang?
2. Hvad indebærer “debugging”?
3. Hvordan definerer en kontrakt en algoritme?
4. Hvad indebærer revision af en kontrakt?

Vi starter med det, der for ingeniører er “selvfølgeligt”, men lad os forklare i den rækkefølge.

Hvad er “bugs” og “debugging”?

En “bug” er ikke en “PC-fejl”

Når man hører ordet “bug”, kan man måske forestille sig en situation, hvor røg kommer ud af maskinen, mens man arbejder på en PC, og skærmen viser noget mærkeligt. Men i virkeligheden gør en PC kun, hvad den bliver bedt om. Dette gælder også, når en bug opstår. Så en “bug” er, når:

• PC’en gør præcis, hvad den bliver bedt om, men
• den opførsel er “uventet” for brugeren

Dette er fænomenet.

Hvorfor opstår “uventet opførsel”?

Lad os tage et eksempel med en “gennem-væggen” bug i et Mario-lignende actionspil.

Marios hop er en andengradsligning. Acceleration, hastighed, koordinater. Men i et tv-spil kan man ikke opdele tiden uendeligt fint, som man kan med en almindelig andengradsligning, for eksempel “hvad er Y, når X=1.76582?”. Skærmen skifter kun (for eksempel) 30 gange i sekundet. Så i virkeligheden “teleporter” Mario 30 gange i sekundet.

Med dette i tankerne, hvis vi tænker på en situation, hvor “Mario hopper og rammer en væg i luften og bliver kastet tilbage”, så er det en situation, hvor:

1. Mario var i luften et øjeblik før, men
2. I det næste øjeblik er Marios koordinater inde i væggen

Dette er situationen.

I sådanne tilfælde kan man konkludere, at “Mario ramte en væg i luften, mens han hoppede”. Så hvis man skriver et program, der siger:

Hvis Marios koordinater er inde i en væg, udfør en tilbageslagsbehandling (※1)

kan man realisere en behandling, der siger “Mario hopper og rammer en væg i luften og bliver kastet tilbage”.

※1 ser korrekt ud, så længe det er skrevet som ovenfor. Og faktisk er denne behandling korrekt “under visse betingelser”.

Men hvis man tænker nøje over det, kan følgende situation også opstå (※2).

I dette tilfælde eksisterer der ikke et øjeblik, hvor “Marios koordinater er inde i væggen”, så tilbageslagsbehandlingen udføres ikke, og Mario ender med at glide gennem væggen.

Dette er et eksempel på en “bug”. Selvom en “gennem-væggen bug” opstår af denne grund, er det ikke fordi PC’en er i stykker. PC’en gør kun, hvad den bliver bedt om, og det er mennesker, der vurderer denne opførsel som “uventet” eller “en bug”. Og denne “bug” opstår, fordi algoritmen ikke er passende.

At overveje, om “uventet opførsel” vil opstå

Men om den ovenfor nævnte “gennem-væggen” faktisk vil opstå i processen med at spille spillet er uklart, bare ved at tænke abstrakt som ovenfor. Om “gennem-væggen” kan opstå afhænger af:

• Hvor stor er Marios hoppekraft (startfart), og er der nogen genstande, der kan øge hoppekraften?
• Hvor tynd er væggen i det tyndeste tilfælde?

Dette afhænger af betingelserne. Det afhænger af, om en situation som ※2 kan opstå. Hvis ※2 ikke kan opstå, er der ikke noget problem med programmet i ※1.

Hvad indebærer “debugging”?

Derfor, for at “debugge”, det vil sige at finde og rette bugs, skal man:

1. Læse og forstå, hvilken algoritme programmet bruger (selvom ※1 er skrevet i naturligt sprog, er programmer faktisk skrevet i et specielt sprog, så det er svært at læse)
2. Overveje, under hvilke betingelser programmet fungerer (undersøge hoppekraft og vægtykkelse)
3. Overveje, om der vil opstå uventet opførsel under disse betingelser

Dette er den nødvendige proces.

Hvad indebærer det at tjekke en kontrakt?

At tjekke en kontrakt ligner denne proces. En kontrakt er i sig selv et dokument, der forudser fremtidige hændelser for parterne, A og B, og bestemmer hvilke rettigheder og forpligtelser der opstår for dem i sådanne situationer. Det bestemmer også, hvordan begge parter skal handle som et resultat. I denne forstand kan det siges at være et “program, der regulerer den virkelige verden”. For eksempel,

Hvis situationen ●● opstår, skal A betale B en erstatning på 1 million yen.

En kontrakt, der fastlægger sådanne regler, definerer betingelser og effekter for fremtidige hændelser.

Og det er netop denne proces med at verificere, om der er problemer med dette “program, der regulerer den virkelige verden”, og rette dem, hvis der er, der nødvendigvis ligner ‘debugging’.

Kontrakten indeholder ikke hele algoritmen

Der er dog et punkt i “kontrakter”, som kan være svært at forstå for dem, der ikke specialiserer sig i lovgivning, men som er yderst vigtigt. Kontrakten definerer kun en “del” af algoritmen, der regulerer parterne. Med andre ord, ved blot at læse kontrakten, kan man ikke fuldt ud forstå, under hvilken algoritme man og den anden part er reguleret.

For eksempel, når du køber en brugt CD i en butik, indgår butikken og kunden ikke en “købsaftale”, men hvis der er en ridse på CD’en, der gør den uafspilbar på en afspiller, vil du sandsynligvis klage til butikken, og du vil forvente, at butikken vil reagere. Dette er ikke bare et spørgsmål om “det er en serviceindustri”, men teoretisk set,

1. Selv uden en kontrakt er en salgsaftale indgået
2. Den japanske civillov (Borgerretten) fastsætter, at sælgeren har et ansvar for mangler i forbindelse med salg af brugte CD’er og lignende (kaldet “specifikke varer”)
3. Derfor kører algoritmen, som den japanske civillov definerer, mellem butikken og kunden, og butikken har et ansvar for mangler

Dette er logikken. Og en “kontrakt” er noget, der overskriver algoritmen, som loven definerer. For eksempel, hvis der er en kontrakt mellem butikken og kunden, der siger “vi accepterer ikke klager over nogen defekter i CD’er efter købet”, så vil det være:

1. En salgsaftale er indgået
2. Den japanske civillov fastsætter, at sælgeren har et ansvar for mangler i forbindelse med denne aftale
3. Men ifølge kontraktens bestemmelser er princippet i punkt 2 overskrevet, og butikken har ikke et ansvar for mangler

Dette er konklusionen.

Kontrakter “overskriver” principperne i den japanske civillov

Dette gælder også for kontrakter indgået mellem virksomheder, såsom systemudvikling. For eksempel, hvis en kontrakt for systemudvikling på kontraktbasis er indgået mellem to parter,

1. Det er klart, at en kontrakt er indgået ved at indgå denne kontrakt
2. I tilfælde af en kontrakt, opstår der et ansvar for mangler i henhold til den japanske civillov for den part, der har påtaget sig opgaven
3. Hvis der er en bestemmelse om ansvar for mangler i kontrakten, vil denne bestemmelse overskrive princippet i den japanske civillov nr. 2. For eksempel, hvis der er en klausul om ansvar for mangler i en længere periode end den japanske civillov, vil denne periode være gyldig

Det er strukturen. Med andre ord, selvom der ikke er nogen særlig bestemmelse om ansvar for mangler i kontrakten, vil der opstå et ansvar for mangler.

Dette er ikke begrænset til kontrakter og systemudvikling, men er en generel teori om alle kontrakter, som virksomheder indgår, såsom overførsel af aktier, finansiering gennem gæld (pengeudlån), ansættelse, udstedelse af aktier osv.

Derfor kan du ikke få det fulde billede af “algoritmen”, der regulerer forholdet mellem den anden part og din virksomhed, ved blot at læse kontrakten. For at få det fulde billede skal du forstå “standardalgoritmen” defineret af love som den japanske civillov. Kontrakten er kun noget, der overskriver denne “standardalgoritme”.

Uden at kunne forudse fremtidige begivenheder, kan vi ikke “debugge”

At forstå en algoritme er ikke nok til at verificere, om “uventet adfærd vil opstå med denne algoritme”. Ligesom med “bugs” i spil, er en algoritme i sidste ende en abstrakt ting, og hvis vi ikke kan forudse, hvilke begivenheder der vil opstå i fremtiden, kan vi ikke verificere, “om uventet adfærd vil opstå, når sådanne begivenheder opstår”.

Dette er især et alvorligt problem, når det kommer til nye produkter som apps eller tjenester, nye forretningsmodeller osv. Hvad kan der ske i fremtiden, når du udvikler en virksomhed med sådanne produkter eller modeller? Dette er svært at forudse, hvis du ikke har viden om det pågældende område. Desuden, især i tilfælde af kontrakter mellem virksomheder, handler både den anden part og din egen virksomhed under en vis økonomisk rationalitet, så en game-teoretisk tankegang om virksomhedsledelse er nødvendig for at forudsige fremtidige begivenheder og handlinger, der vil medføre dem.

Om noget er “uventet” afhænger også af ledelsesmæssige beslutninger

Desuden, ligesom det er mennesker og ikke computere, der bestemmer, om en hændelse er en “bug”, er det også et spørgsmål om ledelsesmæssige beslutninger, snarere end rent juridiske spørgsmål, at afgøre, om en konsekvens af en kontrakt er “uventet”.

For eksempel kan der være tilfælde, hvor en algoritme, der følger “principperne i den japanske civillov (Minpō)”, er uacceptabel for en bestemt virksomhed i en bestemt branche. Dette er en afvigelse fra de tidligere eksempler, men for eksempel fastsætter den japanske civillov en standardalgoritme, der siger, at “genuddelegering af opgaver af en agent er en kontraktbrud”. Men der kan være tilfælde, hvor “det er forventet, at en virksomhed naturligt vil bruge underleverandører i en bestemt forretning”. I sådanne tilfælde bør det være umuligt at acceptere en kontrakt, hvor genuddelegering er umulig, det vil sige

• Der er intet skrevet om, hvorvidt genuddelegering er tilladt (i dette tilfælde gælder principperne i den japanske civillov, som nævnt ovenfor)
• Det er klart angivet, at genuddelegering er umulig

selvom det er “i overensstemmelse med principperne i den japanske civillov”, bør det være umuligt at acceptere sådan en kontrakt.

Desuden er der altid en risiko i ledelsen for, at “man vil blive holdt ansvarlig, hvis en bestemt hændelse opstår”. Der er grundlæggende ingen kontrakter, hvor der “ikke er nogen risiko” for virksomheden. Om man accepterer denne risiko eller ej er i sidste ende en ledelsesmæssig beslutning. Det er ledelsen, der træffer ledelsesmæssige beslutninger, ikke konsulenter som advokater, men konsulenter bør præsentere den nødvendige og tilstrækkelige information for ledelsen at træffe ledelsesmæssige beslutninger, såsom

• Risici, der ikke behøver at blive påpeget hver gang
• Risici, der kræver en alvorlig beslutning for virksomheden at acceptere, og som i nogle tilfælde kræver møder osv.

Advokater, der gennemgår kontrakter, skal også have en vis fornemmelse for “ledelse” for at kunne indstille denne “grad af intensitet”.

Opsummering

Som det fremgår, kan det siges, at tjek og rettelser af kontrakter primært består af følgende opgaver:

1. Forstå hvordan principperne i den japanske civillov m.fl. bliver overskrevet af kontrakten, og hvilken algoritme det resulterer i
2. Overveje hvilke hændelser der kan opstå i fremtiden under denne algoritme
3. Undersøge om der kan opstå uforudsete handlinger i denne forbindelse

Og disse opgaver er hver især:

1. En vanskelig opgave, hvis man ikke forstår loven
2. En vanskelig opgave, hvis man ikke forstår indholdet af den virksomhed, som kontrakten regulerer, såsom apps eller webtjenester, og forretningsmodeller
3. En vanskelig opgave, hvis man ikke har en vis forståelse for virksomhedens eller projektets indhold og ledelsesfølelse

Så det er grunden.

Tjek og rettelser af kontrakter er meget “specialiserede” af disse grunde.

Information om kontraktudarbejdelse og gennemgang m.m. udført af vores firma

Monolis Advokatfirma er et advokatfirma med styrker inden for IT, internet og forretning. Vi tilbyder en række tjenester, herunder udarbejdelse og gennemgang af forskellige kontrakter, til vores rådgivende virksomheder og klientvirksomheder.

Hvis du er interesseret, bedes du venligst se detaljerne nedenfor.

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