Likheterna mellan kontraktsgranskning och felsökning förklaras av en advokat som tidigare var IT-ingenjör

Kärnan i det så kallade “företagets rådgivande advokats” arbete är att kontrollera och korrigera kontrakt som företaget dagligen ingår med klienter och affärspartners. Och dessa kontroller och korrigeringar kan bara utföras till fullo av någon som är väl insatt i både lagstiftningen och det specifika affärsområdet. Jag kommer att förklara varför detta är fallet.

Observera dock att följande förklaring kan vara svår att förstå för dem som inte har erfarenhet av ingenjörsarbete eller programmering. Monolith Law Office är en advokatbyrå ledd av en före detta IT-ingenjör med företagsledningserfarenhet. Detta är strikt sett en artikel som förklarar kontraktskontroll och korrigeringar för företagsledare med erfarenhet av ingenjörsarbete eller programmering, från perspektivet av en advokatbyrå ledd av en före detta IT-ingenjör och företagsledare.

Med denna positionering i åtanke, är kontraktskontroll och korrigeringar liknande arbete som det så kallade “debugging”.

1. Vad är en “bug” från början?
2. Vad innebär “debugging”?
3. Hur definierar ett kontrakt en algoritm?
4. Vad innebär det att korrigera ett kontrakt?

Jag kommer att börja med att förklara saker som kan tyckas självklara för ingenjörer, men jag kommer att förklara dem i följande ordning.

Vad är “bugg” och “felsökning”?

En bugg är inte ett “PC-fel”

När vi talar om en “bugg” kan vissa kanske föreställa sig en situation där rök kommer ut från datorn medan de arbetar på den och skärmen visar konstiga tecken… Men i grund och botten gör en dator bara vad den blir tillsagd att göra. Detta gäller även när en bugg uppstår. Med andra ord är en “bugg”:

• Trots att datorn gör som den blivit tillsagd,
• Är dess beteende “oväntat” för användaren

Detta är fenomenet vi kallar för en bugg.

Varför uppstår “oförutsedda beteenden”?

Låt oss till exempel tänka på buggen “genom väggen” i ett Mario-typ actionspel.

Marios hopp är en andragradsekvation. Acceleration, hastighet, koordinater. Men, även om det är en så kallad andragradsekvation, kan du till exempel dela upp X oändligt fint, som “Vad är Y när X=1.76582?”, men i TV-spel kan du inte dela upp tiden oändligt fint. Det beror på att skärmen bara byter (till exempel) 30 gånger per sekund. Därför, kan man säga att Mario “teleporterar” 30 gånger per sekund.

I detta sammanhang, om vi till exempel tänker på ett scenario där “Mario studsar tillbaka eftersom det finns en vägg i luften när han hoppar”, skulle det vara ett scenario där

1. Mario var i luften ett ögonblick tidigare, men
2. Nästa ögonblick, blir Marios koordinater inne i väggen

Det är sådana fall.

I sådana fall kan man bedöma att “Mario träffade en vägg i luften medan han hoppade”. Därför, om vi uttrycker det i naturligt språk,

Om Marios koordinater är inne i väggen, utför en studsning (※1)

Om du skriver ett program som detta, kan du realisera en process där “Mario studsar tillbaka eftersom det finns en vägg i luften när han hoppar”.

※1, så länge du skriver som ovan, ser det ut att vara korrekt. Och faktiskt, under “vissa förutsättningar” är denna process korrekt.

Men om du tänker noga, kan följande situation också uppstå (※2).

I detta fall finns det ingen stund då “Marios koordinater är inne i väggen”, och därför kommer ingen studsning att utföras, och Mario kommer att glida genom väggen.

Detta är ett exempel på en “bugg”. Även om en “genom väggen-bugg” uppstår av dessa skäl, betyder det inte att datorn är trasig. Datorn utför bara det beteende den har blivit tillsagd att göra, och det är människor som bedömer detta beteende som “oförutsedda” eller “buggar”. Och dessa “buggar” uppstår eftersom algoritmen inte är lämplig.

Att överväga “om oväntade händelser kan inträffa”

Men, om det faktiskt uppstår en “genom-väggen” händelse under spelets gång, som nämnts ovan, är det oklart om man bara tänker på det abstrakt. Om en “genom-väggen” händelse kan inträffa eller inte beror på:

• Hur stark är Marios hoppkraft (startfart), finns det några föremål som ökar hoppkraften?
• Hur tjock är väggen i dess tunnaste tillstånd?

Det beror på dessa villkor. Beroende på om det finns en situation som ※2 under dessa villkor, är det vad det handlar om. Om ※2 inte kan inträffa, då finns det inget problem med ※1 programmet.

Vad innebär “felsökning”?

Följaktligen, för att utföra “felsökning”, det vill säga att hitta och rätta till buggar, krävs följande process:

1. Att förstå vilken typ av algoritm programmet är (ovanstående ※1 är naturligt språk, men eftersom program faktiskt är skrivna på ett unikt språk, är det svårt att förstå dem)
2. Att överväga under vilka förhållanden programmet fungerar (undersöka saker som hoppkraft och väggtjocklek)
3. Att överväga om det finns något oväntat beteende

Detta är den process som krävs.

Vad innebär det att kontrollera ett kontrakt?

Kontraktskontroll liknar denna process. Ett kontrakt är i grunden ett dokument som reglerar rättigheter och skyldigheter för parterna, kallade A och B, med tanke på potentiella framtida händelser. Det bestämmer hur båda parter ska agera under dessa omständigheter. I den meningen kan det beskrivas som ett “program som reglerar den verkliga världen”. Till exempel,

Om situationen ●● uppstår, ska A betala B en miljon yen i skadestånd.

Sådana kontrakt definierar villkor och effekter för framtida händelser.

Och att verifiera om det finns några problem med detta “program som reglerar den verkliga världen”, och att korrigera dem om det finns några, är en process som nödvändigtvis liknar “felsökning”.

Kontraktet beskriver inte hela algoritmen

Det finns dock en punkt i “kontrakt” som kan vara svårt att förstå för de som inte specialiserar sig på lagar, men det är extremt viktigt. Kontraktet definierar endast en “del” av algoritmen som reglerar mellan parterna. Med andra ord, genom att bara läsa kontraktet kan du inte veta hela bilden av vilken algoritm du och den andra parten regleras under.

Till exempel, när du köper en begagnad CD i en butik, ingår butiken och kunden inte något som ett “köpekontrakt”, men om det finns en repa på CD-skivan som gör den ospelbar på spelaren, vill du klaga till butiken, och du förväntar dig att butiken ska svara på det. Detta är inte bara en fråga om “det är en tjänstindustri”, teoretiskt sett,

1. Även utan ett kontrakt, har ett köpeavtal ingåtts
2. Civilrätten (Japansk Civilrätt) stipulerar att säljaren har ett felansvar för försäljningsavtal för begagnade CD-skivor och liknande (kallade “specifika varor”)
3. Därför kör algoritmen som definieras av civilrätten mellan butiken och kunden, och butiken har ett felansvar

Det är logiken. Och ett “kontrakt” är något som skriver över algoritmen som definieras av lagar som civilrätten. Till exempel, om det finns ett kontrakt mellan butiken och kunden som säger “vi accepterar inte efterföljande klagomål om några defekter på CD-skivor”,

1. Ett köpeavtal har ingåtts
2. Civilrätten stipulerar att säljaren har ett felansvar för detta avtal
3. Men enligt bestämmelserna i kontraktet skrivs princip 2 över, och butiken har inget felansvar

Det är så det blir.

Kontrakt kan ‘skriva över’ principer som civilrätten

Detta gäller även för kontrakt som ingås mellan företag, till exempel inom systemutveckling. Om ett kontrakt för systemutveckling på uppdrag har ingåtts mellan part A och B, gäller följande:

1. Genom att ingå kontraktet är det klart att ett uppdragskontrakt har ingåtts
2. I fallet med ett uppdragskontrakt uppstår ett ansvar för felgaranti för den part som tar emot uppdraget enligt civilrätten
3. Om det finns en bestämmelse om felgaranti i kontraktet, skriver den bestämmelsen över principen i civilrätten. Till exempel, om det finns en klausul om felgaranti för en längre period än civilrättens princip, blir den perioden giltig

Detta är strukturen. Med andra ord, även om det inte finns någon särskild bestämmelse om felgaranti i kontraktet, uppstår ett felgaranti ansvar.

Detta är inte begränsat till uppdrag och systemutveckling, utan är en allmän teori om alla kontrakt som företag ingår, såsom aktieöverlåtelser, finansiering med skuld (lån för konsumtion av pengar), anställning och aktieutgivning.

Därför kan du inte få en fullständig bild av ‘algoritmen’ som reglerar relationen mellan den andra parten och ditt företag genom att bara läsa kontraktet. För att få en fullständig bild måste du förstå ‘standardalgoritmen’ som fastställs av lagar som civilrätten. Kontraktet är bara något som skriver över den ‘standardalgoritmen’.

Om man inte kan förutse framtida händelser kan man inte “felsöka”

Att bara förstå en algoritm räcker inte för att kunna verifiera om “oväntade beteenden inte kommer att uppstå med den algoritmen”. Precis som med “buggar” i spel, är algoritmer i grunden abstrakta, och om man inte kan förutse vilka händelser som kommer att inträffa i framtiden, kan man inte verifiera om “oväntade beteenden inte kommer att uppstå när sådana händelser inträffar”.

Detta är särskilt problematiskt när det gäller nya produkter som appar eller tjänster, eller nya affärsmodeller. När man utvecklar en verksamhet med sådana produkter eller modeller, vad kan då hända i framtiden? Detta är svårt att förutse om man inte har kunskap inom det relevanta området. Dessutom, särskilt i företagskontrakt, agerar både det andra företaget och ditt eget företag under vissa ekonomiska rationaliteter, så för att förutse framtida händelser och det andra företagets handlingar som leder till dem, behöver man också en spelteoretisk tankegång i företagsledningen.

Om något är “oförutsett” baseras också på ledningsbeslut

Ytterligare, precis som det är en människa och inte en dator som bestämmer om en händelse är en “bugg”, är det inte bara en ren juridisk fråga att avgöra om en konsekvens som ett kontrakt medför är “oförutsett”, utan det är också en fråga om ledningsbeslut.

Till exempel, det kan realistiskt sett finnas fall där en algoritm som följer “principerna i civilrätten (japansk civil lag)” är oacceptabel för en viss verksamhet i ett företag. Även om detta avviker från de tidigare exemplen, fastställer civilrätten till exempel en standardalgoritm som säger att “omkontrakt av en entreprenör är ett kontraktsbrott”. Men det kan finnas fall där “för ett visst företag, är det förväntat att en viss verksamhet naturligtvis kommer att använda underleverantörer”. I sådana fall bör det vara omöjligt att acceptera ett kontrakt där omkontrakt är omöjligt, det vill säga

• ingenting är uttryckligen angivet om möjligheten till omkontrakt (i detta fall, som nämnt ovan, tillämpas principerna i civilrätten)
• det är uttryckligen angivet att omkontrakt är omöjligt

även om det är “enligt principerna i civilrätten”.

Det finns också alltid en risk i företagsledningen att “hållas ansvarig om en viss händelse inträffar”. Det finns i princip inga kontrakt som “inte innebär någon risk” för företaget. Om man ska acceptera den risken eller inte är slutligen ett ledningsbeslut. Det är företagsledaren som fattar ledningsbeslut, inte någon i en konsultativ position som en rådgivande advokat, men konsulten bör presentera tillräcklig information för att ledaren ska kunna fatta ledningsbeslut,

• risker som inte behöver påpekas varje gång
• risker som, om de accepteras, skulle innebära ett betydande beslut för företaget och som kan kräva möten etc.

och de måste peka ut dessa med olika grader av betydelse. För att ställa in dessa “grader av betydelse” krävs det, precis som i andra konsultområden, att advokaten som granskar kontraktet också har en viss känsla för “ledning”.

Sammanfattning

Således kan man säga att kontroll och korrigering av kontrakt huvudsakligen innebär följande arbetsuppgifter:

1. Förstå hur principerna i civilrätten (Japansk civilrätt) och liknande lagar har skrivits om av kontraktet, och vilket slags algoritm som har skapats som ett resultat
2. Överväga vilka händelser som kan inträffa i framtiden under denna algoritm
3. Undersöka om det finns något oväntat beteende som kan uppstå i detta sammanhang

Och var och en av dessa uppgifter:

1. Är svårt att utföra utan en förståelse för lagen
2. Är svårt att utföra utan en förståelse för innehållet i verksamheten som kontraktet reglerar, till exempel en app eller webbtjänst, och affärsmodellen
3. Är svårt att utföra utan en viss förståelse för företaget eller verksamheten och affärsinstinkter

Det är därför det är så.

Kontroll och korrigering av kontrakt är mycket “specialiserade” av dessa skäl.

Information om kontraktsskapande och granskning av vår byrå

På Monolis juridiska byrå, som en advokatbyrå med styrkor inom IT, internet och affärer, erbjuder vi tjänster som att skapa och granska olika kontrakt till våra rådgivande företag och klientföretag.

Om du är intresserad, vänligen se detaljerna nedan.

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