Hva er juridiske og kontraktsmessige problemer knyttet til smidig utvikling?

Det finnes metodikker for hvordan systemutvikling skal gjennomføres. Den mest klassiske og generelle er vannfallsmodellen, og mange juridiske bøker som behandler systemutvikling, diskuterer dette basert på denne modellen. I denne artikkelen vil vi diskutere hvilke juridiske problemer som kan oppstå i systemutvikling basert på den agile utviklingsmodellen, som det kan være vanskelig å finne informasjon om fra bøker og lignende.

Agil utviklingsmodell og juridiske forhold

Hva er en modell i systemutvikling?

I systemutviklingsprosjekter finnes det noe som kalles en utviklingsmodell, som fungerer som en ramme for å få en helhetlig forståelse av fremdriften. Den mest kjente av disse er sannsynligvis “vannfallsmodellen”. Det vil si, akkurat som vann som faller fra “oppstrøms” til “nedstrøms”, gjennomfører man alle trinnene som kravdefinisjon, design, implementering, testing osv. i en enkelt gjennomgang. Målet er å redusere tilbakevendinger og dobbeltarbeid så mye som mulig, og det er en metode som er egnet for å fremme arbeid på en planlagt måte.

På den annen side, i den agile utviklingsmodellen, gjentar man prosessen med å implementere små programmer og deretter teste dem. Ved å gjenta denne iterative prosessen med å implementere og teste små programmer, bygger man gradvis opp et større system. For en mer detaljert forklaring av disse systemutviklingsmodellene, og en sammenligning av fordelene og ulempene med begge utviklingsmodellene, se følgende artikkel.

https://monolith.law/corporate/legal-merits-and-demerits-of-development-model[ja]

Egenskapene til den agile utviklingsmodellen

En stor fordel med utvikling ved hjelp av den agile modellen er at man kan gå inn i det faktiske arbeidet med en følelse av hastighet. Fordi “oppstrøms” arbeid som kravdefinisjon og opprettelse av design dokumenter, og implementering av programvare ikke er adskilt, er det egnet for å fleksibelt styre prosessen, inkludert respons på tillegg og endringer i funksjoner, og endringer i spesifikasjoner. Fra et juridisk perspektiv er det spesielt viktig å håndtere dokumentstyring og endringsstyring for å gjøre den agile utviklingsmodellen til en suksess. I den agile utviklingsmodellen er ikke roller og ansvar så klart delt som i vannfallsmodellen. I tillegg, siden det er en metode som legger vekt på “hastighet” for å komme til utførelse og igangsetting, snarere enn “styring”, kan det lett føre til mangelfull gjennomføring av ulike design dokumenter, spesifikasjoner og møtereferater.

I tillegg, i forhold til endringsstyring, siden den agile utviklingsmodellen er smidig i å håndtere endringer, er det en risiko for at prosjektet kan brenne ut ved å svare på forespørsler om spesifikasjonsendringer på bakkenivå, uten å gå gjennom godkjenningsprosessen med beslutningstakere. Hvis dette skjer, kan “smidighet i å håndtere endringer etterpå” som er en fordel med utviklingsmodellen, i seg selv bli en risiko for at prosjektet brenner ut.

Hvordan håndtere dokument- og endringsstyring i smidig utvikling

Viktigheten av dokumentstyring

I utviklingsprosjekter basert på den smidige utviklingsmodellen, er det juridiske bekymringer om at muntlige interaksjoner akkumuleres, noe som fører til mangel på dokumentasjon. For å forstå hvorfor dokumentstyring er viktig i systemutviklingsprosjekter, har vi forklart dette i detalj i følgende artikkel.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

I nevnte artikkel forklarer vi viktigheten av dokumentstyring i systemutviklingsprosjekter fra to perspektiver: forebygging av konflikter (det vil si “forebyggende juridisk arbeid”) og bevaring av bevis i tilfelle konflikt (det vil si “krisehåndtering”).

Opprettelse av kontaktutvalg er effektivt for dokumenthåndtering

Når man adopterer en smidig utviklingsmodell, er det ikke forberedt en klar plan på forhånd, i motsetning til vannfallsmodellen. Derfor er det ikke nok å bare administrere avvik mellom plan og faktiske resultater, det er en bekymring for at kostnadene vil øke både økonomisk og tidsmessig hvis det overlates til feltet.

Derfor er det effektivt at lederen tar initiativ til å holde regelmessige kontaktutvalgsmøter for å sikre en jevn fremdrift av prosjektet. Når utviklingsskalaen er liten, er det sant at det ofte foretrekkes å samle ansvarlige parter etter behov, i stedet for å holde regelmessige kontaktutvalgsmøter. Men i tilfelle av smidig utviklingsmodell, er det også en større risiko for å overse aktuelle problemer i møter. Derfor kan det sies at det er trygt å inkludere regelmessige kontaktutvalgsmøter i kontrakter og lignende. Som en måte å regulere dette på, er det vist som følger i modellkontrakten fra det japanske ministeriet for økonomi, handel og industri (METI):

(Opprettelse av kontaktutvalg)

Artikkel 12 Partene A og B skal, inntil denne tjenesten er fullført, holde et kontaktutvalg for å diskutere nødvendige saker for å sikre at denne tjenesten kan utføres jevnt, som fremdriftsstatus, risikostyring og rapportering, felles arbeid og implementering av individuelle arbeidsoppgaver av begge parter, bekreftelse av innhold som skal inkluderes i systemspesifikasjonene, diskusjon og løsning av problemer. Et kontaktutvalg skal holdes. Men, (utelatt).

2. Kontaktutvalget skal i prinsippet holdes regelmessig med en frekvens bestemt i individuelle kontrakter, og i tillegg til dette, skal det holdes når som helst når A eller B anser det som nødvendig.

3. I kontaktutvalget skal ansvarlige personer og hovedansvarlige personer fra begge parter, samt personer som lederen anser som passende, delta. I tillegg kan både A og B be den andre parten om å få nødvendige personer til å delta i diskusjonene i kontaktutvalget, og den andre parten skal svare på dette, med mindre det er en rimelig grunn.

4. B skal lage og sende inn en fremdriftsrapport i en format som er avtalt mellom A og B i kontaktutvalget, bekrefte fremdriftsstatus basert på denne fremdriftsrapporten, og diskutere og bestemme saker som nødvendig, som tilstedeværelse av forsinkede saker, årsaker og mottiltak når det er forsinkede saker, behov for endringer i fremdriftssystemet som definert i dette kapittelet (endringer i personell, økninger og reduksjoner, endringer i underleverandører, etc.), status for gjennomføring av sikkerhetstiltak, tilstedeværelse av saker som krever endringer i individuelle kontrakter, innhold når det er saker som krever endringer i individuelle kontrakter, og bekrefte saker som er bestemt, saker som skal vurderes videre, og når det er saker som skal vurderes videre, bekrefte tidsplanen for vurdering og parter som skal utføre vurderingen.  

(Artiklene 5, 6 og 7 er utelatt.)

Det viktigste poenget er at eksistensen av et kontaktutvalg gir en viss legitimitet i kontraktsklausulene, og gir en annen betydning enn møter som holdes ad hoc.

Utnytte kontaktutvalget for endringsstyring

I Agile-utvikling er det en forutsetning at saker begge parter opprinnelig var enige om, kan endres i ettertid. Derfor er det også svært viktig å håndtere situasjoner med etterfølgende spesifikasjonsendringer.

Hvis et kontaktutvalg holdes regelmessig, vil endringsstyringen bli svært smidig. For eksempel, endringsdiskusjoner kan holdes i kontaktutvalget, og hvis det er en forespørsel om endringsdiskusjon fra den ene parten, inkluderer kontrakten en forpliktelse for den andre parten til å svare på diskusjonen. (Her er et utdrag fra bestemmelsene i den japanske modellkontrakten fra Ministry of Economy, Trade and Industry.)

（Endringsstyringsprosedyre）

Artikkel 37 Part A eller B, når de mottar et endringsforslag basert på (utelatt) fra den andre parten, skal innen ○ dager fra mottaksdatoen levere et dokument som inneholder følgende punkter (heretter kalt “endringsstyringsdokumentet”) til den andre parten, og Part A og B skal diskutere godkjennelsen av endringen i kontaktutvalget som definert i Artikkel 12. (Detaljer om hva som skal inkluderes er utelatt.)

Poengene i ovennevnte bestemmelse kan oppsummeres som følger:

• Metoden for å akseptere en endringsforespørsel er standardisert med et format kalt “endringsforslag”.
• Det er en tidsfrist for datoen fra mottak av forslaget til diskusjon om det. → Selv om det ikke er angitt som “innen ◯ dager”, kan det også vurderes å erstatte det med ord som “snarest”.
• Stedet for å diskutere godkjennelsen av endringen er standardisert til “kontaktutvalget”.

Med andre ord, for å unngå misforståelser som “Jeg foreslo en endring, jeg gjorde det ikke”, “Jeg svarte på godkjennelsen av endringen, jeg gjorde det ikke”, er prosedyren for å gjøre dette klargjort.

Forståelse av plikter som ærlighet og god tro blir utfordret

Vi har så langt introdusert modellkontraktsklausuler relatert til “Kommunikasjonsråd” og “Endringsdiskusjoner”. Imidlertid er det viktig å forstå essensen av disse, som ligger i saker som “plikt til ærlighet” og “prinsippet om god tro”. I utgangspunktet kan det være vanskelig å fortsette med den smidige utviklingsmodellen uten et tillitsforhold mellom bestiller og leverandør. Dette er fordi det legges vekt på hastigheten på å starte det faktiske arbeidet, og prosedyrene som fører til oppstart er vanligvis minimert. Derfor er det ofte i praksis å inkludere en klausul som pålegger den andre parten en “plikt til ærlighet”.

Artikkel 4, avsnitt 3: I endringsdiskusjoner skal begge parter ærlig diskutere om de skal gjøre endringer, etter å ha vurdert målet for endringen, muligheten for endring, og effekten av endringen på betaling og leveringstid.

Dette er for å forhindre en tilnærming som plutselig forråder den andre parten med en formell juridisk teori, som “om man skal godta en kontraktsendring eller ikke, er utelukkende opp til den som mottar forespørselen, og det er ingen plikt til å overholde tvang”, i forhandlinger som har gått frem på grunnlag av et opprinnelig tillitsforhold. Dette reflekterer også prinsippene i loven som gjelder for private transaksjoner, ikke bare systemutvikling.

Sivilloven artikkel 1, avsnitt 2

Utøvelsen av rettigheter og oppfyllelsen av plikter må utføres ærlig og i samsvar med god tro.

Loven verdsetter ikke nødvendigvis bare “innholdet i kontrakten” eller “ordlyden i artikkelen” som er formell. Spesielt i transaksjoner med den andre parten, bør det brukes fleksibelt mens man tar hensyn til den faktiske “god tro” og “ærlighet”. For øvrig, om “plikter” som pålegges i henhold til loven nødvendigvis er basert på “kontrakt” prosedyren, er det en detaljert forklaring i følgende artikkel.

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

Oppsummering

I systemutviklingsprosjekter basert på den agile utviklingsmodellen, er det selvfølgelig viktig å forstå risikoen for at administrative prosedyrer og styringssystemer blir gradvis mer slurvete. Men det er ikke bare det, det er også viktig å forstå de fleksible egenskapene som loven i seg selv har, som er basert på prinsipper som “god tro”, og å ha en holdning til å bruke det i praksis.