Likheten mellom kontraktssjekk og feilsøking forklart av en tidligere IT-ingeniør advokat

Kjernen i arbeidet til det som kalles “selskapets rådgivende advokat” er å sjekke og korrigere kontrakter som selskapet inngår daglig med klienter og forretningspartnere. Og disse sjekkene og korrigeringene kan bare utføres tilstrekkelig av noen som er “kjent med både loven og det aktuelle forretningsområdet”. La meg forklare hvorfor.

Imidlertid kan forklaringen nedenfor være vanskelig å forstå for de som ikke er ingeniører eller har erfaring med programmering. Monolith Law Office er et advokatfirma ledet av en tidligere IT-ingeniør med bedriftsledelse erfaring. Det er strengt tatt posisjonert som “en artikkel som forklarer kontraktssjekk og korrigeringer, rettet mot ledere med erfaring i ingeniørarbeid og programmering, fra et advokatfirma ledet av en tidligere IT-ingeniør og bedriftsleder”.

Og med denne posisjoneringen i tankene, er sjekking og korrigering av kontrakter en oppgave som ligner på det som kalles “debugging”.

1. Hva er egentlig en “bug”
2. Hva innebærer “debugging”
3. Hvordan definerer en kontrakt en algoritme
4. Hva innebærer korrigering av en kontrakt

Jeg vil begynne med å forklare ting som er “selvfølgelige” for ingeniører, men la meg forklare i rekkefølgen ovenfor.

Hva er “bug” og “debugging”

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

Når vi hører ordet “bug”, kan noen av oss forestille oss en situasjon der røyk kommer ut av maskinen mens vi jobber på PC-en, og skjermen viser noe merkelig… Men i grunn, en PC vil bare “gjøre som den blir fortalt”. Dette gjelder også når en bug oppstår. Med andre ord, en “bug” er:

• PC-en utfører oppgavene som den blir fortalt, men
• For brukeren er denne oppførselen “uventet”

Dette er fenomenet vi kaller en “bug”.

“Uforutsette oppførsel” – hvorfor oppstår det?

La oss tenke på en “gjennom-veggen” feil i et Mario-lignende actionspill, for eksempel.

Marios hopp er en andregradsfunksjon. Akselerasjon, hastighet, koordinater. Men selv om det er en andregradsfunksjon, kan vi for eksempel dele X uendelig fint i “Hva er Y når X=1.76582?”, men i tilfellet med videospill kan vi ikke dele tiden uendelig fint. Dette er fordi skjermen bare bytter (for eksempel) 30 ganger i sekundet. Derfor kan vi si at Mario “warper” 30 ganger i sekundet.

Med dette i tankene, la oss tenke på et scenario der “Mario hopper og treffer en vegg i luften og spretter tilbake”. Dette skjer når:

1. Mario var i luften et øyeblikk tidligere, men
2. I det neste øyeblikket, blir Marios koordinater inne i veggen

Dette er situasjonen.

I slike tilfeller kan vi konkludere med at “Mario traff en vegg i luften mens han hoppet”. Derfor, hvis vi skriver et program som sier:

Hvis Marios koordinater er inne i en vegg, utfør en sprett-tilbake handling (※1)

Vi kan realisere en prosess der “Mario hopper og spretter tilbake fordi det er en vegg i luften”.

※1 ser riktig ut så lenge vi skriver det på denne måten. Og faktisk, under “visse forhold” er denne prosessen korrekt.

Men hvis vi tenker nøye etter, kan det også være situasjoner som den følgende (※2).

I dette tilfellet eksisterer ikke et øyeblikk der “Marios koordinater er inne i veggen”, og derfor blir ingen sprett-tilbake handling utført, og Mario ender opp med å gli gjennom veggen.

Dette er et eksempel på en “bug”. Selv om en “gjennom-veggen bug” oppstår av denne grunnen, betyr det ikke at PCen er ødelagt. PCen utfører bare oppførselen som den har blitt fortalt, og det er mennesker som vurderer denne oppførselen som “uforutsett” eller “en bug”. Og denne “buggen” oppstår fordi algoritmen ikke er passende.

“Å vurdere om det kan oppstå uforutsette handlinger”

Imidlertid, om den ovennevnte “gjennom veggen” oppstår i løpet av faktisk spill, er det uklart bare ved å tenke abstrakt som nevnt ovenfor. Om “gjennom veggen” kan skje eller ikke, avhenger av:

• Hvor stor er Marios hoppkraft (startfart), og finnes det gjenstander som øker hoppkraften?
• Hvor tykk er veggen i det tynneste tilfellet?

Dette avhenger av disse forholdene. Avhengig av om det er mulig med situasjoner som i ※2, er det det det kommer an på. Hvis ※2 ikke er mulig, er det ingen problemer med ※1-programmet.

Hva innebærer “feilsøking”?

Derfor, for å utføre “feilsøking”, det vil si å finne og rette feil, er det nødvendig å:

1. Forstå hvilken type algoritme programmet er (selv om det ovenfor er skrevet i naturlig språk, er programmer faktisk skrevet i et unikt språk, noe som gjør forståelsen vanskelig)
2. Vurdere under hvilke forhold programmet fungerer (undersøke ting som hoppkraft og veggtykkelse)
3. Vurdere om det oppstår uventet oppførsel under disse forholdene

Dette er altså prosessen som er nødvendig.

Hva innebærer det å sjekke en kontrakt?

Sjekking av kontrakter ligner på denne prosessen. En kontrakt er i utgangspunktet et verktøy for å regulere hva partene, A og B, vil ha av rettigheter og plikter i fremtidige hendelser, og hvordan de vil handle som et resultat. I denne forstand kan det sies at det er et ‘program som regulerer den virkelige verden’. For eksempel,

Hvis situasjonen ●● oppstår, skal A betale B en million yen i erstatning.

En kontrakt som regulerer på denne måten definerer betingelser og effekter for fremtidige hendelser.

Og arbeidet med å verifisere om det er noen problemer med dette ‘programmet som regulerer den virkelige verden’, og korrigere dem hvis det er noen, er nødvendigvis lik ‘feilsøking’.

Kontrakten inneholder ikke hele algoritmen

Det er imidlertid et viktig punkt med “kontrakter” som kan være vanskelig å forstå for de som ikke er spesialisert i loven. Kontrakten definerer bare en “del” av algoritmen som regulerer partene. Med andre ord, ved å bare lese kontrakten, kan du ikke vite hele bildet av hvilken algoritme du og den andre parten er regulert under.

For eksempel, når du kjøper en brukt CD i en butikk, inngår ikke butikken og kunden en “kjøpekontrakt”, men hvis det er en ripe på CD-overflaten som gjør den uavspillbar på en spiller, vil du sannsynligvis klage til butikken, og du vil forvente at butikken skal svare på det. Dette er ikke bare et spørsmål om “det er en tjenesteytende industri”, men teoretisk sett,

1. selv uten en kontrakt, er en salgskontrakt inngått
2. Den japanske sivilloven (Minpō) bestemmer at selgeren har en garanti for mangler i salgskontrakten for en brukt CD, etc. (kalt “spesifisert vare”)
3. Derfor kjører algoritmen definert av den japanske sivilloven (Minpō) mellom butikken og kunden, og butikken har en garanti for mangler

Dette er logikken. Og en “kontrakt” er noe som overskriver algoritmen definert av lover som den japanske sivilloven (Minpō). For eksempel, hvis det er en kontrakt mellom butikken og kunden som sier “Vi aksepterer ingen klager om noen defekter i CDene etter kjøpet”,

1. en salgskontrakt er inngått
2. Den japanske sivilloven (Minpō) bestemmer at selgeren har en garanti for mangler i denne kontrakten
3. Men, i henhold til bestemmelsene i kontrakten, er prinsippet i punkt 2 overskrevet, og butikken har ingen garanti for mangler

Det er slik det er.

Kontrakter “overskriver” prinsippene i lover som den japanske sivilloven

Dette gjelder også for kontrakter inngått mellom bedrifter, som for eksempel systemutviklingskontrakter. For eksempel, hvis en kontrakt for systemutvikling på kontraktsbasis er inngått mellom partene A og B,

1. Det er klart at en kontrakt er inngått ved å inngå denne kontrakten
2. I tilfelle av en kontrakt, oppstår det et ansvar for garanti for mangler på grunn av bestemmelsene i den japanske sivilloven
3. Hvis det er en bestemmelse om ansvar for mangler i kontrakten, vil denne bestemmelsen overskrive prinsippet i den japanske sivilloven. For eksempel, hvis det er en klausul om ansvar for mangler for en lengre periode enn prinsippet i den japanske sivilloven, vil denne perioden være gyldig

Strukturen er slik. Med andre ord, selv om det ikke er noen spesiell bestemmelse om ansvar for mangler i kontrakten, vil det oppstå et ansvar for mangler.

Dette er ikke begrenset til kontrakter og systemutvikling, men er en generell teori om alle kontrakter som bedrifter inngår, som overføring av aksjer, finansiering med gjeld (lån for forbruk av penger), ansettelse, utstedelse av aksjer, osv.

Derfor kan du ikke forstå hele “algoritmen” som regulerer forholdet mellom den andre parten og ditt eget selskap bare ved å lese kontrakten. For å forstå hele bildet, må du forstå “standardalgoritmen” som er definert av lover som den japanske sivilloven. Kontrakten er bare noe som overskriver denne “standardalgoritmen”.

Uten å kunne forutse fremtidige hendelser, kan vi ikke “feilsøke”

Å forstå en algoritme alene er ikke nok til å verifisere om “uventet oppførsel vil oppstå med denne algoritmen”. Dette er likt som med “bugs” i spill, algoritmer er i utgangspunktet abstrakte, og uten å forutse hvilke hendelser som kan oppstå i fremtiden, kan vi ikke verifisere “om det vil bli uventet oppførsel når slike hendelser oppstår”.

Dette er spesielt et alvorlig problem når det gjelder nye produkter som apper eller tjenester, eller nye forretningsmodeller. Hva kan skje i fremtiden når du utvikler en virksomhet med slike produkter eller modeller? Dette er vanskelig å forutse uten kunnskap om det aktuelle feltet. Spesielt i tilfelle av kontrakter mellom selskaper, både motpartens selskap og ditt eget selskap handler under en viss økonomisk rasjonalitet, så for å forutsi fremtidige hendelser og handlingene som fører til dem, er det også nødvendig med en spillteoretisk tilnærming til bedriftsledelse.

Om noe er “uventet” er også basert på ledelsesvurdering

I tillegg, akkurat som det er mennesker, ikke PCer, som bestemmer om en hendelse er en “bug”, er det også et spørsmål om ledelsesvurdering, ikke bare et rent juridisk spørsmål, om en konsekvens som en kontrakt medfører er “uventet” eller ikke.

For eksempel, det kan være tilfeller der en algoritme som følger “prinsippene i den japanske sivilloven (Minpō)” er uakseptabel for en bestemt virksomhet i et bestemt selskap. Dette er en annen diskusjon enn de tidligere eksemplene, men for eksempel, den japanske sivilloven (Minpō) har en standard algoritme som sier at “re-delegasjon av oppgaver av en delegat er en kontraktsbrudd”. Men det kan være tilfeller der “for et bestemt selskap, er det forventet at en bestemt virksomhet vil naturlig bruke underleverandører”. I slike tilfeller, en kontrakt som gjør re-delegasjon umulig, det vil si

• Det er ikke spesifisert om re-delegasjon er tillatt eller ikke (i dette tilfellet, som nevnt ovenfor, vil prinsippene i den japanske sivilloven (Minpō) gjelde)
• Det er spesifisert at re-delegasjon er umulig

skulle ikke kunne aksepteres, selv om det er “i henhold til prinsippene i den japanske sivilloven (Minpō)”.

I tillegg, i ledelsen er det alltid en risiko for å “bli holdt ansvarlig hvis en viss hendelse oppstår”. Det er i utgangspunktet ingen kontrakter som “ikke innebærer noen risiko” for selskapet. Om man skal akseptere denne risikoen eller ikke er til slutt en ledelsesvurdering. Det er ledelsen, ikke konsulenter som juridiske rådgivere, som tar ledelsesbeslutninger, men konsulenter bør gi tilstrekkelig informasjon som er nødvendig for ledelsen å ta ledelsesbeslutninger, som

• Risikoer som ikke trenger å bli påpekt hver gang
• Risikoer som, hvis akseptert, vil være en stor beslutning for selskapet og kan kreve møter osv.

De må peke på disse med forskjellige grader av alvorlighet. For å sette disse “grader av alvorlighet”, trenger advokater som sjekker kontrakter, akkurat som konsulenter i andre felt, også en viss grad av “ledelses” følelse.

Oppsummering

Som vi har sett, kan det sies at kontroll og korrigering av kontrakter hovedsakelig består av følgende oppgaver:

1. Forstå hvordan prinsippene i den japanske sivilloven og lignende er overskrevet av kontrakten, og hvilken algoritme dette resulterer i
2. Vurdere hvilke hendelser som kan oppstå i fremtiden under denne algoritmen
3. Vurdere om det kan oppstå uforutsette atferd i denne prosessen

Og hver av disse oppgavene er:

1. En vanskelig oppgave uten en forståelse av loven
2. En vanskelig oppgave uten en forståelse av innholdet i virksomheten som kontrakten regulerer, for eksempel en app eller en nettjeneste, og forretningsmodellen
3. En vanskelig oppgave uten en viss forståelse av selskapet eller virksomheten og forretningsfølelsen

Dette er grunnen til at det er slik.

Kontroll og korrigering av kontrakter er derfor svært “spesialisert” av disse grunnene.

Informasjon om kontraktsopprettelse og gjennomgang av Monolis Advokatfirma

Monolis Advokatfirma, som har styrker innen IT, internett og forretningsjus, tilbyr tjenester som opprettelse og gjennomgang av ulike kontrakter til våre klienter og rådgivende selskaper.

For de som er interessert, vennligst se detaljene nedenfor.