Når et selskap gir et annet selskap i oppdrag å utvikle et system, er det ofte slik at kontrakten som inngås med de japanske representantenes stempel og kravspesifikasjonen utarbeidet av ansvarlig person, ikke nødvendigvis tydeliggjør hva som skal lages og innen hvilken frist. I mange systemutviklingsprosjekter blir spesifikasjoner som opprinnelig var uklare, spesifikasjonsendringer i tråd med situasjonsendringer, forespørsler om tilleggsfunksjoner, og samarbeid om oppståtte problemer, daglig håndtert gjennom e-post og telefonsamtaler på medarbeidernivå, samt møter ledet av ansvarlige personer.
For å sikre en smidig fremdrift i systemutviklingen og for å være forberedt i tilfelle en tvist oppstår, er det viktig å utarbeide og administrere dokumenter for å styre fremdriften av et systemutviklingsprosjekt på en effektiv måte.
I denne artikkelen vil vi forklare hvordan man fra et juridisk perspektiv kan dokumentere møtereferater og møtemateriale som brukes i fremdriftsmøter for systemutvikling.
Hvorfor dokumenthåndtering er viktig i systemutvikling
I systemutviklingsprosjekter er det svært viktig å registrere innholdet i møtene og fremdriften og historikken til prosjektet, også fra et juridisk perspektiv. Dette kan begrunnes med følgende to punkter:
For å unngå konflikter senere
Systemutvikling er vanligvis et prosjekt som involverer mange parter, både på brukersiden og leverandørsiden. Derfor, hvis det er uoverensstemmelser mellom brukersiden og leverandørsiden om hvilke roller de skal ha og hvilke forpliktelser de skal påta seg, kan dette føre til problemer i prosjektets fremdrift.
Videre, siden prosjektet involverer mange mennesker, kan det også føre til kommunikasjonsproblemer, som for eksempel at “det er små forskjeller i hva folk sier, og det er vanskelig å vite hvem som har rett”.
For å sikre at det ikke er noen uoverensstemmelser mellom partene, er det nyttig å dokumentere innholdet i avtalene skriftlig. Å samle dette i et dokument som alle involverte kan sjekke (på sitt eget tidspunkt) bidrar til å sikre at alle er på samme side.
Forresten, å bruke juridisk kunnskap for å forhindre konflikter på forhånd kalles ofte forebyggende jus.
For å håndtere konflikter som oppstår senere
Selv om dette ligner på det forebyggende juridiske perspektivet nevnt tidligere, kan vi også forklare viktigheten av dokumenthåndtering fra et litt annet perspektiv, nemlig “krisehåndtering” i tilfelle en faktisk konflikt oppstår.
La oss anta at det oppstår en konflikt, prosjektet blir avbrutt før resultatene er ferdige, eller at den opprinnelige fristen ikke blir overholdt, og at det kan ende opp i retten. Både brukersiden og leverandørsiden kan si “vi har også vårt syn på saken”, men uten skriftlige registreringer vil det være vanskelig å bevise sitt synspunkt, noe som kan føre til en ufordelaktig situasjon i retten.
Spesielt i konflikter som oppstår på grunn av “forsinket levering”, kan viktige punkter som “når og hvordan ble problemet oppdaget?”, “når ble forespørselen om endring av spesifikasjoner fremsatt?”, og “hvordan reagerte leverandøren på brukerens forespørsel om funksjonsutvidelse?” ofte være avgjørende for utfallet av rettssaken. Hvis det oppstår mange “sa, sa ikke”-problemer i slike tilfeller, vil det være vanskelig å forvente en rettferdig løsning på konflikten.
Hva er spesielt viktig i møteprotokoller for systemutviklingsmøter?
Vi vil forklare hvordan man fører møteprotokoller i systemutviklingsprosjekter.
Typer møter i systemutvikling
I systemutviklingsprosjekter blir ulike møter ofte planlagt og gjennomført fortløpende. Dette er ikke overraskende, gitt at slike prosjekter involverer mange personer. Programmerere og ingeniører som implementerer programmet på utviklingsstedet, holder ofte regelmessige statusmøter for å sjekke fremdriften. Det er også vanlig å gjennomføre kodegjennomganger for å sikre at det ikke er problemer med vedlikeholdbarhet eller sikkerhet.
Videre, i tillegg til møter på ansvarsområdenivå på utviklingsstedet, kan det også være møter hvor selskapets styremedlemmer og ansvarlige med beslutningsmyndighet samles. Disse møtene fokuserer ofte på den overordnede retningen og strategien for utviklingsprosjektet. Slike møter på ansvarsnivå kalles ofte styringskomiteer.
Styringskomiteer er spesielt viktige
Som nevnt tidligere, blir ulike møter planlagt i systemutviklingsprosjekter avhengig av deltakernes roller og formål. Fra et juridisk perspektiv er styringskomiteer spesielt viktige. Sammenlignet med statusmøter og kodegjennomganger på ansvarsområdenivå, er det viktig å dokumentere styringskomiteer nøye for å forebygge konflikter og håndtere dem hvis de oppstår. Årsakene til dette er:
Styringskomiteer involverer ofte beslutningstakere, og møtene handler ofte om viktige beslutninger. Derfor er det juridisk viktig å dokumentere hva både brukere og leverandører har forstått.
Innholdet i møter på ansvarsområdenivå blir vanligvis reflektert i ulike design- og spesifikasjonsdokumenter senere, så det er sjelden et problem med manglende dokumentasjon. (Selvfølgelig, hvis dokumentasjonen er mangelfull, bør dette også forbedres.)
Disse punktene kan fremheves.
Rettseksempler relatert til protokoller fra styringskomiteen
Nedenfor introduserer vi en sak der protokoller fra styringskomiteen ble ansett som viktig bevis i en faktisk rettssak. Den siterte dommen nedenfor omhandler en sak der et systemutviklingsprosjekt ble avbrutt underveis, og leverandørens brudd på prosjektledelsesplikten ble anerkjent. Innholdet i protokollene viste de opprinnelige oppfatningene til både leverandøren og brukeren, og dette hadde stor betydning i rettssaken.
Leverandøren påpekte at innholdet i protokollene fra styringskomiteen var endret av brukeren, og at de derfor ikke nødvendigvis reflekterte den faktiske situasjonen. Imidlertid ble styringskomiteen opprettet for å ta beslutninger på høyeste ledelsesnivå i systemutviklingsprosjektet, og både leverandørens og brukerens prosjektansvarlige deltok for å evaluere helheten, dele status og utfordringer, og ta beslutninger om viktige saker. Leverandøren skulle utarbeide protokollene innen morgenen to virkedager etter møtet, registrere dem i protokolldatabasen, og dokumentere de endelige beslutningene fra møtet. Ved fastsettelse av protokollene var både leverandøren og brukeren fullt klar over betydningen av å dokumentere arbeidet, og de vurderte innholdet og uttrykket for å sikre at det reflekterte møtets faktiske forhold. Spesielt leverandøren, som driver med systemutvikling, var naturligvis godt kjent med betydningen og metoden for å utarbeide slike protokoller. Derfor er det rimelig å behandle de fastsatte protokollene som en refleksjon av styringskomiteens faktiske arbeid, og med mindre spesielle omstendigheter foreligger, er det rimelig å anta at innholdet i protokollene oppsummerer arbeidet på den aktuelle datoen.
Tokyo Høyesterett, 26. september Heisei 25 (2013)
Rettens standpunkt er at hvis protokollene fra møtene er utarbeidet i enighet mellom leverandøren og brukeren, kan de ha en viss presumptiv kraft som “bevis”. Fra et annet perspektiv bør man være oppmerksom på at en uaktsom beskrivelse i protokollene kan bli brukt som bevis, og dette bør man være svært forsiktig med.
Hva bør inkluderes i møtereferater?
Hva bør dokumenteres i møtereferater?
Møtereferater er viktige, både som bevis i tilfelle rettssaker og for å sikre smidig fremdrift i forhandlinger mellom partene. Men hva bør konkret dokumenteres i møtereferater? La oss organisere dette nedenfor.
Hva leverandøren bør dokumentere
Leverandøren har en prosjektledelsesplikt som systemutviklingsekspert. Denne plikten er detaljert forklart i følgende artikkel.
Med denne plikten i tankene, bør leverandøren spesielt dokumentere:
Fakta og dato for fullføring av hver utviklingsfase
Historikk over svar på brukerens forespørsler om endringer i spesifikasjoner eller tillegg av funksjoner
Tiltak og deres forløp for å be om samarbeid når utviklingsarbeidet forsinkes på grunn av brukerens egne forhold
For å utdype punkt 3, forklarer følgende artikkel hva leverandøren bør vurdere hvis brukeren ikke gjennomfører inspeksjon. Artikkelen viser hvordan domstolens avgjørelse kan variere avhengig av hvor samarbeidsvillig leverandøren har vært for å gjennomføre brukerens inspeksjon, med henvisning til faktiske domsavsigelser.
Brukeren har også en samarbeidsplikt i systemutviklingen, siden det er deres interne system. Den generelle innholdet av denne plikten er forklart i følgende artikkel.
Historikk over hva brukeren har kommunisert til leverandøren om ønskede funksjoner og utseende på skjermen
Historikk over ulike problemer som oppstod i leverandørens utviklingsprosess (for eksempel plutselig avgang av medlemmer eller forsinkelser i utviklingsplanen på grunn av utilstrekkelig undersøkelse fra leverandørens side)
For å utdype punkt 2, er det spesielt sannsynlig at uforutsette problemer oppstår når utviklingen av et nytt system skjer samtidig som det gamle systemet avvikles. Problemer oppstår ofte når data fra det gamle systemet overføres til det nye systemet. Følgende artikkel gir en detaljert forklaring på juridiske problemer knyttet til slike overføringer.
Ovennevnte er retningslinjene for hvordan man bør føre møtereferater i systemutviklingsprosjekter fra et juridisk perspektiv. Det er viktig å ikke bare fokusere på praktiske metoder, men også å utdype forståelsen av sammenhengen mellom temaene “japansk lov”, “systemutvikling” og “dokumenthåndtering”. Siden systemutvikling ofte involverer mange mennesker og organisasjoner og kan utvikle seg til store kommersielle transaksjoner, er det viktig å forebygge og håndtere tilhørende konflikter. Fra et juridisk perspektiv er det nødvendig å bevare bevis, og derfor er det viktig å ha “dokumenter” som kan bekreftes objektivt av alle.
Det er utvilsomt en stor byrde og kanskje ikke realistisk å fullstendig språkliggjøre alle interaksjoner og prosjektets fremdrift. Men det er viktig å identifisere hva som er juridisk viktig og dokumentere disse viktige punktene etter behov. Dette bør anerkjennes bredt av alle som er involvert i virksomhet, uavhengig av om de er juridiske eksperter eller ikke.
An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.
