Vad är metoden för att avbryta ett kontrakt i systemutveckling?

Projekt som systemutveckling är långvariga, och det är naturligt att förvänta sig situationer som “brand” under dess förlopp. Och även om användare och leverantörer alltid kan samarbeta, bör man också förvänta sig situationer där man överväger att avsluta kontraktet.

I denna artikel kommer vi att diskutera juridiska alternativ som “uppsägning” av kontrakt, vilket är viktigt i samband med systemutveckling.

Relationen mellan systemutveckling och uppsägning

Vad är uppsägning enligt civilrätten?

I den reviderade japanska civilrätten (Japanska civilrätten) är de allmänna bestämmelserna om “uppsägning” av ett avtal fastställda i artiklarna 540 till 548. Att säga upp ett avtal innebär att man eliminerar effekterna av ett avtal som redan har ingåtts.

I en relation mellan en användare och en leverantör, innebär det normalt att när ett avtal har ingåtts, har leverantören en skyldighet att utveckla systemet och användaren har en skyldighet att betala ersättning. Och dessa blir också båda parters “rättigheter”. Om detta skulle upphävas, skulle de skyldigheter och rättigheter som båda parter hade, återgå till tillståndet före avtalet. Därför, även om det finns skulder som ännu inte har uppfyllts, kommer skyldigheten att uppfylla dem att försvinna, och det kommer att uppstå en skyldighet att återgå till det ursprungliga tillståndet baserat på tillståndet före avtalet. Detta kallas “skyldigheten att återställa till det ursprungliga tillståndet”.

Om det samtidigt finns omständigheter där skada har uppstått, är det också möjligt att separat ersätta skadan.

Systemutvecklingspraxis och uppsägningens inblandning

För dem som är bekanta med juridisk praxis kring affärer som systemutveckling, kan “uppsägning” av ett avtal först associeras med ett uppsägningsbrev. Men juridiskt sett, även inom kontexten av systemutveckling, är de artiklar som ligger till grund för uppsägningen uppdelade i två huvudkategorier beroende på orsaken till uppsägningen.

I fall där skuldbrott (försening i uppfyllande) är orsaken

(Exempel) Om leverantören, trots att den ursprungliga leveranstiden har överskridits, inte levererar

Civilrätten Artikel 541 När en av parterna inte uppfyller sin skuld, kan den andra parten, efter att ha fastställt en rimlig period och uppmanat till uppfyllande inom den perioden, säga upp avtalet om det inte finns något uppfyllande inom den perioden.

I systemutveckling baserat på kontraktsavtal är “skulden” som leverantören, som är “en av parterna”, bär att slutföra systemet enligt kravspecifikationen och leverera det. Därför, om leverantören inte levererar trots att leveranstiden har överskridits, innebär det att leverantören inte har slutfört arbetet till leveranstiden. Så, vad menas med “slutförande av arbete” i sammanhanget av systemutveckling? Detta förklaras mer detaljerat i följande artikel.

https://monolith.law/corporate/completion-of-work-in-system-development[ja]

I fall där defektgaranti är orsaken

(Exempel) Om det finns många buggar och inkonsekvenser i data i systemet som levererats av leverantören, och det senare visar sig vara olämpligt för praktisk användning

Civilrätten Artikel 635 När det finns defekter i objektet för arbetet och det på grund av detta inte är möjligt att uppnå syftet med avtalet, kan beställaren säga upp avtalet. Detta gäller dock inte för byggnader och andra markarbeten.

Om vi ser det från perspektivet av ett systemutvecklingsprojekt, är det inte så vanligt att leverantören uttrycker en avsikt att säga upp avtalet. Normalt kan vi anta att det är användaren som uttrycker en avsikt att säga upp avtalet till leverantören.

Mer detaljerad information om defektgaranti finns i följande artikel.

https://monolith.law/corporate/defect-warranty-liability[ja]

Uppsägningsmeddelande och relaterade juridiska frågor

Ett uppsägningsmeddelande är ett dokument som används för att meddela (vanligtvis från användaren till leverantören) att ett avtal ska upphävas. Som referens kan följande lagtext användas:

Den japanska civilrätten, artikel 541: Om en part inte uppfyller sina skyldigheter, kan den andra parten, efter att ha gett en rimlig tidsfrist för uppfyllelse, upphäva avtalet om uppfyllelsen inte sker inom den tidsfristen.

När man ser på det som ett dokument relaterat till systemutveckling, kan man säga att en distinkt egenskap hos ett uppsägningsmeddelande är att det inte syftar till att främja smidig framsteg i projektet, utan snarare att avsluta det. Dessutom är det ett dokument som förväntas ha en direkt juridisk effekt.

Men som nämnts i ovanstående lagtext, till skillnad från ett avtal, kan ett uppsägningsmeddelande vara tillräckligt med en ensidig viljeyttring (förutsatt att vissa villkor uppfylls). När ett uppsägningsmeddelande presenteras från användaren till leverantören, kan det förväntas att problem som “även om jag läser uppsägningsmeddelandet, förstår jag inte varför avtalet upphävdes” kan uppstå för den ansvarige på leverantörens sida. Så hur specifikt bör användaren peka ut orsaken till uppsägningen i ett uppsägningsmeddelande?

Bör man skriva orsaken till uppsägningen i uppsägningsbrevet?

Enligt tidigare rättsfall verkar det inte vara nödvändigt att alltid specificera orsaken till uppsägningen i ett uppsägningbrev. Rättsfallet som citeras nedan handlar om en situation där ett levererat system hade brister, vilket ledde till juridiska problem. När användaren ville säga upp avtalet, uppstod frågan om hur detaljerat man behövde förstå och peka ut bristerna. Domstolen kom fram till följande:

Det är inte nödvändigt att alltid ange orsaken till uppsägningen i en uppsägningsförklaring, och det är möjligt att säga upp avtalet på grund av flera orsaker med en enda förklaring. Om man inte uttryckligen anger att man inte kommer att säga upp avtalet av andra skäl, anses uppsägningsförklaringen vara en förklaring att avsluta hela avtalet baserat på alla skäl som fanns vid tidpunkten för uppsägningen.

Tokyo District Court, 22 december 2004 (Heisei 16)

Domstolens ståndpunkt är att “det är möjligt att säga upp avtalet på grund av flera orsaker med en enda förklaring”. Med andra ord, det viktiga är om parterna i avtalet har en avsikt att säga upp det, inte att de behöver peka ut varje enskild orsak i detalj.

Detta innebär att även om något har levererats, behöver man inte avgöra vid tidpunkten för uppsägningen om det bör behandlas som ofullständigt, eller om det finns allvarliga brister och det är ett problem med garantiansvar för fel. Även om dessa subtila frågor lämnas obesvarade för tillfället, om man uttrycker sin avsikt att säga upp avtalet först, kan man senare argumentera för både försenad prestation och garantiansvar för fel som grunder för uppsägningen, även om det skulle leda till en rättegång.

• Leverans av ofullständiga varor… → Brist på prestation
• Leverans av varor med allvarliga brister… → Garantiansvar för fel

Även om man inte specificerar orsaken i detalj, är en uppsägningsförklaring fortfarande en giltig uppsägningsförklaring.

Å andra sidan, det finns fördelar med att specificera orsaken till uppsägningen i detalj och presentera uppsägningsbrevet. Om det till exempel finns en missförstånd eller skillnad i uppfattning mellan dig och leverantören, kan detta klargöras. För mottagaren av uppsägningsbrevet, om de kan identifiera orsaken, minskar också risken för framtida tvister. Därför är det faktiskt bäst att specificera orsaken till uppsägningen så tydligt som möjligt.

Vad innebär en “rimlig tid” för en uppmaning?

Ett annat möjligt problem att överväga är hur lång en “rimlig tid” är enligt paragraf 541 i den japanska civilrätten (Japanska Civilrätten). Men det verkar inte vara nödvändigt att oroa sig för mycket över detta. Detta beror på att även om det inte har fastställts en “rimlig tid” före uppmaningen, om en rimlig tid har passerat efter uppmaningen, är det möjligt att avbryta kontraktet. Dessutom, även om tiden före uppmaningen inte var “rimlig”, har det klargjorts i prejudikat att det är möjligt att avbryta kontraktet när en rimlig tid har passerat.

I systemutvecklingsprojekt, där det uppstår “brand” incidenter där förseningar i prestanda eller ansvar för defekter blir ett problem, är det sällan att leverans eller reparation av defekter slutförs även efter att en uppmaning har gjorts under en “rimlig tid”. Med tanke på detta, är det osannolikt att allvarliga tvister kommer att uppstå i praktiken över vad som utgör en “rimlig tid”.

Vi förklarar definitionen av prestandaförseningar i systemutveckling i en separat artikel.

https://monolith.law/corporate/performance-delay-in-system-development[ja]

Hur ska ett uppsägningsmeddelande meddelas?

Angående frågan om hur ett uppsägningsmeddelande bör meddelas, finns det inga problem med någon metod så länge meddelandet når fram (mer specifikt, om det kan bevisas att det definitivt nådde fram).

Därför behöver du inte vara överdrivet bekymrad över procedurfrågor. Visst, i praktiken tenderar metoder som rekommenderat brev att föredras för att undvika framtida “sade-det-inte” problem. Men om det kan bekräftas att det har nått mottagaren, finns det inga problem med enklare metoder som fax eller e-post. Men om det slutligen blir en rättegång, kommer det att vara nödvändigt att bevisa att det “nådde mottagaren”, och ur denna synvinkel kan det sägas att ett rekommenderat brev är säkert.

Sammanfattning

I denna artikel har vi ordnat information om uppsägning av kontrakt i sammanhanget av systemutveckling. Förståelse av hur man praktiskt genomför en uppsägning, samt hur man uttrycker en juridiskt giltig viljeyttring, är inte bara värdefull kunskap i sig, utan kan också lätt appliceras i andra sammanhang.