Hvad er de vigtige punkter at tjekke i kontrakter for systemudvikling på kontraktbasis?

Det Japanske Ministerium for Økonomi, Handel og Industri har fremlagt modelklausuler for IT-systemudviklingskontrakter i deres “Retningslinjer for forbedring af pålideligheden af informationssystemer”. Med udbredelsen af internettet og lignende, er de sociale konsekvenser af driftsstop eller funktionsnedgang forårsaget af informationssystemfejl blevet mere alvorlige. På den ene side er det en presserende opgave at forbedre pålideligheden og sikkerheden af systemerne, men på den anden side har kontrakttypen for IT-systemudvikling en tendens til at blive uklar i forhold til transaktionsindholdet. Disse klausuler sigter mod at gøre dette mere synligt og klarlægge rollefordelingen og ansvarsforholdene. I denne artikel vil vi forklare, under henvisning til klausulerne i ministeriets modelkontrakt, hvad man skal være opmærksom på i kontrakter, når man indgår en kontrakt om udførelse af IT-systemudviklingsarbejde.

Systemudvikling og kontraktarbejde

Hvad er en kontrakt?

En kontrakt er defineret i civilretten som følger:

Artikel 632
En kontrakt opstår, når den ene part lover at fuldføre et bestemt stykke arbejde, og den anden part lover at betale for resultatet af dette arbejde.

I en kontrakt er det et krav, at der er en aftale om at “fuldføre et stykke arbejde”. For eksempel, hvis målet med kontrakten er at skabe et bestemt system inden en bestemt dato, er leverandørens forpligtelse at “fuldføre systemet inden den aftalte dato”. Hvis systemet ikke er færdigt inden den aftalte dato, kan leverandøren blive holdt ansvarlig for manglende opfyldelse af kontrakten. Dog, hvis systemet er færdigt og leveret inden den aftalte dato, men der senere findes fejl, er leverandørens forpligtelse allerede opfyldt, så manglende opfyldelse af kontrakten er ikke et problem, og det bliver et spørgsmål om ansvar for mangler. I systemudvikling, hvornår “arbejdet er fuldført” er detaljeret forklaret i følgende artikel.

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

Forskellen fra en agenturkontrakt

I en kontrakt har leverandøren en forpligtelse til at fuldføre arbejdet, så hvis det leverede produkt har mangler, har leverandøren et ansvar for disse mangler. I modsætning hertil har en agenturkontrakt ikke en forpligtelse til at fuldføre arbejdet, så der er ikke et ansvar for mangler som i en kontrakt. Dog, hvis der er anerkendt en pligt til at udvise omhu i håndteringen af sagen, kan der være et separat ansvar for manglende opfyldelse af kontrakten, såsom erstatningsansvar. Hvad slags ansvar der er et problem i en systemudviklingskontrakt er detaljeret forklaret i følgende artikel.

https://monolith.law/corporate/responsibility-system-development [ja]

Modelklausuler og kontrolpunkter for kontraktbaserede aftaler

Støtte til udarbejdelse af kravspecifikationer

Kravspecifikationer er en proces, hvor brugerens krav til det system, de ønsker at opbygge, samles. I kravspecifikationsfasen overvejes retningen for systemopbygningen, og det afgøres, hvilket system der skal opbygges. Da det endelige produkt ikke er konkret forestillet på dette tidspunkt, har det japanske Ministerium for Økonomi, Handel og Industri (METI) defineret modelkontrakten som en quasi-mandat. Yderligere detaljer er forklaret i artiklen nedenfor.

https://monolith.law/corporate/system-development-contract-check-quasi-mandate [ja]

Udarbejdelse af eksterne design dokumenter

(Implementering af udarbejdelse af eksterne design dokumenter)
Paragraf ○: Part B skal, efter indgåelse af den individuelle kontrakt som fastsat i paragraf ○, udføre arbejdet med at udarbejde eksterne design dokumenter for den pågældende software, baseret på kravspecifikationerne fastlagt i henhold til paragraf ○.

2. Ved implementering af arbejdet med at udarbejde eksterne design dokumenter, kan part B anmode part A om nødvendigt samarbejde, og part A skal reagere rettidigt, når de bliver bedt om at samarbejde af part B.

Udarbejdelse af eksterne design dokumenter er en opgave, der fastlægger brugen af dele relateret til grænseflader, såsom skærme og rapporter. Eksterne design dokumenter skal i princippet indeholde alle de oplysninger, der gør det muligt for leverandøren at udvikle programmet. Selvom eksterne design dokumenter indeholder detaljeret information om brugen af formularer, er det brugerne, der bestemmer forretningsindholdet, der kan ændre kravspecifikationerne. Dog, hvis kravspecifikationerne, som er resultatet af den foregående fase af udarbejdelsen af eksterne design dokumenter, klart definerer brugernes behov, og det arbejde, leverandøren skal fuldføre, er klart defineret, kan kontrakten indgås i en form, hvor leverandøren er hovedaktøren i udarbejdelsen af de eksterne design dokumenter.

Paragraf 1 fastlægger, at leverandøren er hovedaktøren i udførelsen af arbejdet, da denne proces er kontraktbaseret. Dog, selv i en kontraktbaseret aftale, da det eksterne design har stor indflydelse på fastlæggelsen af brugerens forretningsindhold, kræves der aktiv involvering fra brugeren. Derfor fastlægger paragraf 2, at leverandøren kan anmode brugeren om det samarbejde, der er nødvendigt for at overveje og fastlægge systemspecifikationerne, og at brugeren skal reagere rettidigt, hvilket klart angiver, at overvejelsen af systemspecifikationerne er et fælles arbejde mellem leverandøren og brugeren.

(Indgåelse af individuel kontrakt relateret til udarbejdelse af eksterne design dokumenter)
Paragraf ○: Part A og part B skal, efter at have drøftet handelsbetingelserne som angivet i paragraf ○, fastlægge disse og indgå en individuel kontrakt relateret til udarbejdelsen af eksterne design dokumenter.

Omfanget af arbejdet med at udarbejde eksterne design dokumenter skal aftales i en individuel kontrakt i overensstemmelse med handelsbetingelserne fastlagt i den foregående paragraf.

(Ekstern design review møde)
Paragraf ○: Part B skal, når det er nødvendigt, afholde et eksternt design review møde (herefter i dette afsnit benævnt “eksternt design review møde”) med den frekvens, der anses for nødvendig, for at afklare eller bekræfte indholdet, der er nødvendigt for at udarbejde de eksterne design dokumenter, som fastsat i paragraf ○, og part A skal deltage i dette.

2. Part A kan også, når det anses for nødvendigt for at udarbejde de eksterne design dokumenter, afholde et eksternt design review møde, og part B skal deltage i dette.

3. Hvis part A ønsker at ændre indholdet af kravspecifikationerne som følge af overvejelserne i det eksterne design review møde, og det er nødvendigt at ændre betingelserne i den individuelle kontrakt, såsom arbejdsperioden og honoraret, skal dette gøres i overensstemmelse med proceduren i paragraf 33 (ændring af indholdet af denne kontrakt og den individuelle kontrakt).

For at udarbejde de eksterne design dokumenter, der bestemmer grænseflader som skærme og rapporter, er det nødvendigt med et samarbejde mellem brugeren og leverandøren. Da denne proces er kontraktbaseret, fastlægger paragraf 1, at leverandøren er værten for mødet, og at brugeren deltager. Alle afklaringer eller bekræftelser af indholdet, der er nødvendigt for at udarbejde de eksterne design dokumenter, foretages i det eksterne design review møde, og både leverandøren og brugeren er bundet af resultaterne af mødet.

Paragraf 2 fastlægger, at brugeren også kan afholde et eksternt design review møde, når det er nødvendigt for at implementere arbejdet med at udarbejde de eksterne design dokumenter.
Paragraf 3 fastlægger, at hvis overvejelserne i det eksterne design review møde fører til, at brugeren ønsker at ændre indholdet af kravspecifikationerne, og dette påvirker betingelserne i den individuelle kontrakt, såsom arbejdsperioden og honoraret, skal dette gøres i overensstemmelse med metoden for at ændre indholdet af denne kontrakt og den individuelle kontrakt, som er fastlagt i en anden paragraf.

(Levering af eksterne design dokumenter)
Paragraf ○: Part B skal levere de eksterne design dokumenter og anmodningen om accept af de eksterne design dokumenter (også leveringsdokumentet) til part A inden den dato, der er fastsat i den individuelle kontrakt.

Da denne proces er kontraktbaseret, skal leverandøren levere de eksterne design dokumenter osv. som et resultat.

(Godkendelse og fastlæggelse af eksterne design dokumenter)
Paragraf ○: Part A skal, inden for den periode, der er fastsat i den individuelle kontrakt (herefter benævnt “inspektionsperiode for de eksterne design dokumenter”), inspicere, om de eksterne design dokumenter er i overensstemmelse med kravspecifikationerne fastlagt i henhold til paragraf ○ og de beslutninger, der er truffet i det eksterne design review møde som fastsat i paragraf ○, og om der er nogen logiske fejl, og som bevis for godkendelse af overensstemmelse og ingen logiske fejl, skal de ansvarlige for både part A og part B underskrive og stemple godkendelsesdokumentet for de eksterne design dokumenter. Dog, hvis inspektionen viser, at de eksterne design dokumenter ikke er i overensstemmelse med kravspecifikationerne fastlagt i henhold til paragraf ○ og de beslutninger, der er truffet i det eksterne design review møde, eller hvis der opdages logiske fejl, skal part B, efter at have drøftet dette, udarbejde en revideret version inden for en fastsat frist og præsentere denne for part A, og part A skal igen udføre ovenstående inspektion og godkendelsesprocedure.

2. Hvis part A ikke fremsætter indsigelser med en specifik begrundelse skriftligt inden for inspektionsperioden for de eksterne design dokumenter, anses part A for at have godkendt de eksterne design dokumenter ved udløbet af inspektionsperioden for de eksterne design dokumenter.

3. De eksterne design dokumenter anses for at være fastlagt ved part A’s godkendelse i henhold til de foregående to paragraffer.

I den eksterne design proces fastlægges de krav, der er nødvendige for at udføre det efterfølgende arbejde, såsom at udarbejde interne design dokumenter, men hvis fastlæggelsen af kravene er uklar, kan der opstå problemer i den efterfølgende udvikling. Denne paragraf fastlægger proceduren for at inspicere de eksterne design dokumenter, der er grundlaget for det efterfølgende udviklingsarbejde, og for at fastlægge dem ved brugerens godkendelse.

Paragraf 1 fastlægger, at brugeren skal inspicere, om de eksterne design dokumenter er i overensstemmelse med kravspecifikationerne og de beslutninger, der er truffet i det eksterne design review møde, og om der er nogen logiske fejl. Der kan være tilfælde, hvor det er nødvendigt at foretage rettelser som følge af inspektionen for godkendelse af de eksterne design dokumenter, og undtagelsen i denne paragraf fastlægger proceduren for sådanne tilfælde.
Paragraf 2 er en bestemmelse, der antager, at brugeren har godkendt, hvis brugeren ikke har fremsat indsigelser inden for en bestemt periode, selvom godkendelsesunderskriften og stemplet ikke er blevet afsluttet. Det er muligt, at der opstår problemer senere, hvis det er uklart, om brugeren har godkendt eller ej, når de går ind i det interne design, så denne paragraf har til formål at forhindre sådanne problemer.

Og paragraf 3 fastlægger, at de eksterne design dokumenter er fastlagt ved brugerens godkendelse.

(Fejlansvar)
Paragraf ○: Hvis der efter fastlæggelsen i den foregående paragraf opdages uoverensstemmelser mellem de eksterne design dokumenter og kravspecifikationerne og de beslutninger, der er truffet i det eksterne design review møde, eller logiske fejl (herefter i denne paragraf benævnt “fejl”) i de eksterne design dokumenter, kan part A anmode part B om at rette disse fejl, og part B skal rette disse fejl. Dog skal part B kun påtage sig dette ansvar for at rette fejl, hvis part A har anmodet om dette inden for ○ måneder efter fastlæggelsen i den foregående paragraf.

2. Uanset det foregående, hvis fejlen er mindre, og det vil kræve overdreven omkostninger at rette de eksterne design dokumenter, skal part B ikke påtage sig ansvaret for at rette fejlen som fastsat i den foregående paragraf.

3. Bestemmelsen i paragraf 1 gælder ikke, når fejlen er opstået på grund af dokumenter leveret af part A eller instruktioner givet af part A. Dog gælder dette ikke, hvis part B ikke har meddelt, at dokumenterne eller instruktionerne var upassende, selvom de vidste det.

Denne paragraf fastlægger fejlansvaret for de eksterne design dokumenter. Fejlansvarsperioden skal fastlægges til en periode, der anses for passende, efter at have taget hensyn til størrelsen af informationssystemet og betalingen osv.

Paragraf 1 definerer uoverensstemmelser mellem de eksterne design dokumenter og kravspecifikationerne og de beslutninger, der er truffet i det eksterne design review møde, samt logiske fejl i de eksterne design dokumenter som fejl.

Paragraf 2 beskytter leverandøren ved at fastlægge, at selvom der er en fejl, hvis fejlen er mindre og det vil kræve overdreven omkostninger at rette de eksterne design dokumenter, skal leverandøren ikke påtage sig ansvaret for at rette fejlen, i overensstemmelse med undtagelsen i artikel 634, paragraf 1 i civilretten.

Paragraf 3 er en bestemmelse, der er i overensstemmelse med undtagelsen i artikel 636 i civilretten, og fastlægger, at hvis fejlen er opstået på grund af instruktioner eller dokumenter leveret af brugeren, skal leverandøren ikke påtage sig fejlansvaret, medmindre leverandøren vidste, at instruktionerne eller dokumenterne var upassende, men ikke meddelte det.

Bemærk, at fejlansvaret er en valgfri bestemmelse, så hvis en sådan bestemmelse ikke er indført, vil behandlingen følge de generelle principper i civilretten. Fejlansvaret er et område, der er stærkt påvirket af den reviderede civilret, der træder i kraft i april 2020, så efter implementeringen af den reviderede civilret vil behandlingen af dette område ændre sig. Detaljerne er forklaret i følgende artikel.

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

Softwareudviklingsopgaver

(Udførelse af softwareudviklingsopgaver)
Paragraf 〇: Part B skal, efter indgåelse af den individuelle kontrakt specificeret i paragraf 25, udføre softwareudviklingsopgaver fra intern design til systemtest, baseret på systemspecifikationerne fastlagt i de foregående afsnit som en del af denne opgave.

2. Ved udførelse af softwareudviklingsopgaver kan Part B anmode Part A om nødvendig samarbejde, og Part A skal reagere rettidigt, når sådan en anmodning er fremsat af Part B.

I det følgende fastsættes bestemmelserne for, når en leverandør udfører softwareudvikling på kontraktbasis. I processen med intern systemdesign er det normalt, at udviklingsmålene og specifikationerne er defineret i de tidligere arbejdsfaser, så i modelkontrakten fra Ministeriet for Økonomi, Handel og Industri er det fastlagt som en kontraktbaseret proces.

(Indgåelse af individuel kontrakt vedrørende softwareudviklingsopgaver)
Paragraf 〇: Part A og Part B skal, efter at have drøftet handelsbetingelserne angivet i paragraf 〇, afsnit 〇, fastlægge disse og indgå en individuel kontrakt vedrørende softwareudviklingsopgaver.

Rækkevidden af softwareudviklingsopgaverne skal aftales i den individuelle kontrakt i overensstemmelse med de handelsbetingelser, der er fastlagt på forhånd.

(Levering af leverancer)
Paragraf 〇: Part B skal levere de leverancer, der er specificeret i den individuelle kontrakt, sammen med en anmodning om accept (også en leveringsnota) til Part A inden den fastsatte frist i den individuelle kontrakt.
2. Part A skal, når levering er foretaget, udføre inspektion i overensstemmelse med inspektionsspecifikationerne i næste paragraf og i overensstemmelse med bestemmelserne i paragraf 〇 (accept af denne software).
3. Ved levering af leverancer kan Part B anmode Part A om nødvendig samarbejde, og Part A skal reagere hurtigt, når sådan en anmodning er fremsat af Part B.
4. Risikoen for tab, skade osv. af leverancerne skal bæres af Part B før levering og af Part A efter levering.

Da denne proces er kontraktbaseret, vil den færdige software osv. blive leveret som et produkt, der skal inspiceres. Paragraf 1 fastsætter, at leverancerne skal leveres sammen med en anmodning om accept (også en leveringsnota).

Paragraf 2 fastsætter brugerens gennemførelse af inspektionen.
Paragraf 3 fastsætter brugerens forpligtelse til at samarbejde, da der kan være tilfælde, hvor brugerens samarbejde er nødvendigt for levering til det sted, der er specificeret i den individuelle kontrakt (f.eks. når levering sker ved at bringe det ind i brugerens kontor, eller når det leveres i en tilstand, hvor det kan fungere i brugerens faktiske driftsmiljø).
Paragraf 4 er en bestemmelse om risikoen for tab eller skade på leverancerne, og tiden for overførsel af risikoen er opdelt baseret på overførslen af fysisk kontrol.

(Accept af denne software)
Paragraf 〇: For denne software blandt leverancerne skal Part A inspicere den inden for den periode, der er fastsat i den individuelle kontrakt (herefter kaldet “inspektionsperioden”), i henhold til inspektionsspecifikationerne i den foregående paragraf og kontrollere, om systemspecifikationerne og denne software stemmer overens.

2. Hvis denne software er i overensstemmelse med inspektionen i det foregående afsnit, skal Part A underskrive og forsegle en inspektionsgodkendelsesformular og give den til Part B. Desuden, hvis denne software ikke består inspektionen i det foregående afsnit, skal Part A hurtigt give Part B en skriftlig forklaring, der klart angiver de specifikke grunde til, at den ikke bestod, og anmode om rettelser eller tilføjelser, og når grunden til, at den ikke bestod, er anerkendt, skal Part B rette den gratis inden for den periode, der er fastsat efter drøftelser, og levere den til Part A, og Part A skal udføre inspektionen specificeret i det foregående afsnit igen i det omfang, der er nødvendigt.

3. Selv hvis en inspektionsgodkendelsesformular ikke er givet, hvis Part A ikke angiver en specifik grund i skriftlig form og fremsætter en indsigelse inden for inspektionsperioden, anses denne software for at have bestået inspektionen specificeret i denne paragraf.

4. Accepten af denne software skal betragtes som fuldført ved godkendelse af inspektionen specificeret i denne paragraf.

Da denne proces er kontraktbaseret, fastsætter denne paragraf proceduren for accept af den leverede software.

Paragraf 1 fastsætter, at denne software skal inspiceres inden for inspektionsperioden i henhold til inspektionsspecifikationerne, og det skal kontrolleres, om systemspecifikationerne og denne software stemmer overens.
Paragraf 2 pålægger leverandøren en forpligtelse til at rette denne software, hvis det er konstateret, at denne software ikke er i overensstemmelse med systemspecifikationerne.
Paragraf 3 er en bestemmelse, der forhindrer, at accepten forlænges på grund af brugerens omstændigheder, ved at fastsætte en formodet acceptgodkendelse.
Paragraf 4 klart angiver, at accepten af denne software betragtes som fuldført ved godkendelse af inspektionen.

(Fejl- og mangelforpligtelse)
Paragraf 〇: Hvis der efter inspektionen i den foregående paragraf opdages en uoverensstemmelse (inklusive bugs, herefter i denne paragraf kaldet “fejl”) mellem leverancerne og systemspecifikationerne, kan Part A anmode Part B om at rette den pågældende fejl, og Part B skal rette den pågældende fejl. Dog skal Part B kun bære dette ansvar for rettelser, hvis anmodningen er fremsat af Part A inden for ○ måneder efter inspektionen i den foregående paragraf.
2. Uanset det foregående afsnit, hvis fejlen er mindre, og rettelsen af leverancerne kræver overdreven omkostninger, skal Part B ikke bære ansvaret for rettelsen specificeret i det foregående afsnit.
3. Bestemmelsen i afsnit 1 gælder ikke, når fejlen er opstået på grund af dokumenter osv. leveret af Part A eller instruktioner givet af Part A. Dog gælder dette ikke, hvis Part B ikke har meddelt, at dokumenterne osv. eller instruktionerne var upassende, selvom Part B vidste det. 　

Da denne proces er kontraktbaseret, fastsætter denne paragraf fejl- og mangelforpligtelsen for leverancerne. Grænsen mellem ansvar for manglende opfyldelse af forpligtelser i en situation, hvor opfyldelsen ikke er opfyldt (arbejdet er ikke afsluttet), og fejl- og mangelforpligtelsen i en situation, hvor opfyldelsen er afsluttet (arbejdet er afsluttet), er i praksis svær at afgøre. Der er en retskendelse (Tokyo District Court, 22. april 2002), der siger, at om systemudvikling kan betragtes som afsluttet eller ej, skal afgøres ud fra, om arbejdet er afsluttet indtil den sidste proces, der var planlagt i den oprindelige kontrakt. Hvis en fejl opdages efter levering og inspektionsgodkendelse af softwaren, vil fejl- og mangelforpligtelsen i princippet gælde.

Paragraf 1 definerer “uoverensstemmelse med systemspecifikationerne” som en fejl i softwareudviklingsopgaver. For mangler, der opstår i den eksterne designfase, bestemmes ansvaret i henhold til bestemmelserne om fejl- og mangelforpligtelse i den eksterne designfase, ikke i denne paragraf. Fejl- og mangelforpligtelsesperioden skal fastsættes som en rimelig periode gennem drøftelser mellem parterne under hensyntagen til størrelsen af informationssystemet, prisen osv.

Paragraf 2 fastsætter en bestemmelse svarende til artikel 634, stk. 1, i Civil Code, hvor det er for hårdt at kræve rettelser uden beregning fra leverandøren, selvom fejlen er mindre, og rettelsen af leverancerne kræver overdreven omkostninger.

Paragraf 3 er en bestemmelse svarende til artikel 636 i Civil Code, hvor leverandøren ikke er ansvarlig for fejl- og mangelforpligtelsen, hvis fejlen skyldes instruktioner eller dokumenter osv. leveret af brugeren, men hvis leverandøren vidste, at dokumenterne osv. eller instruktionerne var upassende og ikke påpegede det, kan leverandøren ikke undslippe fejl- og mangelforpligtelsen.

For en detaljeret forklaring på, hvornår en fejl er anerkendt, og hvad det specifikke ansvar er, når en fejl er anerkendt, se følgende artikel.

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

Software driftsforberedelse og overgangsstøtte

I systemmodtagelses- og implementeringsfasen er det almindeligt, at brugeren tager initiativet. I den modelkontrakt, som det japanske Ministerium for Økonomi, Handel og Industri (METI) har fastlagt, er det brugeren, der er hovedaktøren, og leverandøren støtter dette i form af en semi-delegeret model.

Afgørelse af kontraktens karakter

For at bestemme karakteren af en kontrakt, skal man se på kontrakten som helhed og overveje, om dens formål er at “levere et færdigt produkt” eller om det er, at leverandøren skal “udføre arbejdet på en rimelig måde”. En generel retningslinje er, om indholdet af det produkt, der skal fuldføres, er blevet bestemt i nogen grad, og om projektet er blevet fremskredet i retning af dette. For at forstå, hvilke specifikke aspekter man skal fokusere på, kan du finde en detaljeret forklaring i artiklen nedenfor.