Wat zijn de juridische en contractuele problemen rond Agile-ontwikkeling?

Er zijn methodologieën voor het voortzetten van systeemontwikkeling. De meest klassieke en algemene is het watervalmodel, en veel juridische boeken die systeemontwikkeling behandelen, worden besproken op basis van dit model. In dit artikel zullen we de juridische problemen bespreken die kunnen ontstaan bij systeemontwikkeling op basis van het Agile ontwikkelingsmodel, waarvoor het moeilijk is om informatie te verkrijgen uit boeken en dergelijke.

Agile Ontwikkelingsmodel en Juridische Zaken

Wat is een model in systeemontwikkeling?

In systeemontwikkelingsprojecten bestaat er een ontwikkelingsmodel als een raamwerk voor het begrijpen van de algehele voortgang. Het meest bekende hiervan is het zogenaamde ‘watervalmodel’. Dit model is vergelijkbaar met het water van een rivier dat van ‘bovenstroom’ naar ‘benedenstroom’ stroomt, waarbij elke fase van de eisen, ontwerp, implementatie, testen, enz. in één keer wordt doorlopen. Het doel is om herhaling en dubbel werk zoveel mogelijk te verminderen en het werk op een geplande manier uit te voeren.

Aan de andere kant, in het Agile ontwikkelingsmodel, wordt een klein programma geïmplementeerd en vervolgens getest, en dit proces wordt herhaald. Door deze iteratieve werkzaamheden van het implementeren en testen van kleine programma’s te herhalen, wordt geleidelijk een groter systeem opgebouwd. Voor een meer gedetailleerde uitleg van deze systeemontwikkelingsmodellen en een vergelijking van de voor- en nadelen van beide ontwikkelingsmodellen, zie het volgende artikel.

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

Kenmerken van het Agile Ontwikkelingsmodel

Een groot voordeel van ontwikkeling met het Agile model is dat je snel aan de slag kunt gaan met het daadwerkelijke werk. Omdat de ‘bovenstroom’ taken zoals het definiëren van eisen en het maken van ontwerpen niet gescheiden zijn van de implementatie van het programma, is het geschikt voor flexibel sturen, inclusief het toevoegen en wijzigen van functies en het wijzigen van specificaties. Vanuit juridisch oogpunt zijn documentbeheer en wijzigingsbeheer bijzonder belangrijk voor het succes van het Agile ontwikkelingsmodel. In het Agile model zijn de rollen en verantwoordelijkheden niet zo duidelijk verdeeld als in het watervalmodel. Bovendien, omdat het een methode is die de ‘snelheid’ van uitvoering en aanpak benadrukt in plaats van ‘beheer’, kan het gemakkelijk leiden tot onvolledige ontwerpen, specificaties en notulen.

Verder, in relatie tot wijzigingsbeheer, omdat het Agile model soepel reageert op veranderingen, kan er een risico zijn dat het project in brand vliegt als het goedkeuringsproces voor de besluitvormer wordt overgeslagen en er op locatieniveau wordt gereageerd op verzoeken om specificatiewijzigingen. In dat geval kan het voordeel van het ontwikkelingsmodel, namelijk ‘soepele reactie op latere wijzigingen’, zelf een risico worden voor het in brand vliegen van het project.

Documentbeheer en verandermanagement in Agile-ontwikkeling

Belang van Documentbeheer

In ontwikkelingsprojecten gebaseerd op het Agile ontwikkelingsmodel, is een juridisch punt van zorg dat mondelinge communicatie zich opstapelt, wat leidt tot een tekort aan documentatie. Overigens, waarom documentbeheer belangrijk is in systeemontwikkelingsprojecten in de eerste plaats, wordt in detail uitgelegd in het volgende artikel.

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

In het genoemde artikel wordt het belang van documentbeheer in systeemontwikkelingsprojecten uitgelegd vanuit twee perspectieven: preventie van geschillen (oftewel ‘preventief juridisch werk’) en het bewaren van bewijsmateriaal in geval van een geschil (oftewel ‘crisisbeheer’).

De oprichting van een communicatieoverleg is effectief voor documentbeheer

Wanneer het Agile ontwikkelingsmodel wordt aangenomen, is er in tegenstelling tot het watervalmodel geen duidelijk plan vooraf voorbereid. Daarom is het niet voldoende om alleen de discrepantie tussen planning en prestaties te beheren, er is een zorg dat de kosten zowel financieel als in tijd zullen oplopen als het aan het veld wordt overgelaten.

Daarom is het effectief om maatregelen te nemen zoals de projectleider regelmatig een communicatieoverleg laat houden voor een soepele voortgang van het project. Bij kleinere ontwikkelingsprojecten is het inderdaad vaak de voorkeur om bijeen te komen wanneer de verantwoordelijken elkaar kunnen ontmoeten, in plaats van regelmatig een communicatieoverleg te houden. Echter, in het geval van het Agile ontwikkelingsmodel is er een groter risico dat tijdige problemen niet worden aangepakt in vergaderingen. Daarom is het veilig om de regelmatige organisatie van een communicatieoverleg ook in contracten op te nemen. De manier van voorschrijven wordt als volgt aangegeven in het modelcontract van het Ministerie van Economie, Handel en Industrie (METI) van Japan.

(Oprichting van een communicatieoverleg)

Artikel 12 Partij A en Partij B zullen, tot de voltooiing van deze taak, een communicatieoverleg houden om de voortgang, risicobeheer en rapportage, gezamenlijk werk en de uitvoering van individuele taken door beide partijen, de inhoud die moet worden opgenomen in de systeemspecificaties, de bespreking en oplossing van problemen, en andere noodzakelijke zaken voor de soepele uitvoering van deze taak te bespreken. Echter, (weggelaten).

2. Het communicatieoverleg zal in principe regelmatig worden gehouden op de frequentie bepaald in het individuele contract, en daarnaast zal het op elk moment worden gehouden wanneer Partij A of Partij B dit noodzakelijk acht.

3. Aan het communicatieoverleg zullen de verantwoordelijken van beide partijen, de hoofdverantwoordelijken en degenen die de verantwoordelijken geschikt achten, deelnemen. Bovendien kunnen Partij A en Partij B de aanwezigheid van degenen die nodig zijn voor de discussies in het communicatieoverleg van de andere partij verzoeken, en de andere partij zal hieraan voldoen, tenzij er een redelijke reden is om dit niet te doen.

4. Partij B zal een voortgangsrapport opstellen in de vorm die apart is overeengekomen tussen Partij A en Partij B en dit indienen bij het communicatieoverleg, en zal de voortgang controleren op basis van dit voortgangsrapport, en zal, indien nodig, de aanwezigheid van vertragingen, de redenen en maatregelen voor vertragingen, de noodzaak om de promotiestructuur zoals bepaald in dit hoofdstuk te wijzigen (verandering van personeel, toename of afname, verandering van onderaannemer, enz.), de uitvoering van beveiligingsmaatregelen, de aanwezigheid van redenen om het individuele contract te wijzigen, de inhoud van de redenen om het individuele contract te wijzigen, enz. bespreken, en zal de besloten zaken, de zaken die verder onderzocht moeten worden, en de planning en de partijen die het onderzoek zullen uitvoeren, bevestigen als er zaken zijn die verder onderzocht moeten worden. 

(De volgende paragrafen 5, 6 en 7 zijn weggelaten.)

Het belangrijkste punt is dat de aanwezigheid van een communicatieoverleg een zekere legitimiteit geeft aan de contractclausules, en het een andere betekenis geeft dan ad hoc vergaderingen.

De weg naar het benutten van de communicatiecommissie voor verandermanagement

In Agile ontwikkeling is het een gegeven dat zaken waarover beide partijen aanvankelijk overeenstemming hadden bereikt, achteraf kunnen worden gewijzigd. Daarom is het ook uiterst belangrijk hoe je de situatie van dergelijke latere specificatiewijzigingen beheert.

Als er regelmatig een communicatiecommissie wordt gehouden, wordt het verandermanagement en de manier waarop het wordt uitgevoerd zeer soepel. Bijvoorbeeld, het is afgesproken dat veranderingsdiscussies worden gevoerd in de communicatiecommissie, en als er een verzoek tot veranderingsdiscussie is van de ene partij, wordt de verplichting voor de andere partij om aan die discussie deel te nemen in het contract opgenomen. (Hieronder volgt een uittreksel uit de bepalingen van het modelcontract van het Japanse Ministerie van Economie, Handel en Industrie.)

(Procedure voor verandermanagement)

Artikel 37 Partij A of B, wanneer zij een wijzigingsvoorstel ontvangen van de andere partij (weglating)…, zal binnen ○ dagen na ontvangst van dit voorstel een document (hierna “veranderingsbeheerdocument” genoemd) met de volgende punten aan de andere partij overhandigen, en partij A en B zullen overleggen over de goedkeuring van deze wijziging in de communicatiecommissie zoals bepaald in artikel 12. (De volgende punten worden weggelaten)

De belangrijkste punten van de bovenstaande bepaling kunnen als volgt worden samengevat:

• Het proces voor het accepteren van een wijzigingsverzoek is gestandaardiseerd in een “wijzigingsvoorstel” formaat.
  
• Er is een deadline gesteld voor de datum van ontvangst van het voorstel tot de datum van de discussie erover → Dit hoeft niet noodzakelijkerwijs te worden aangegeven als “binnen ◯ dagen”, maar kan ook worden vervangen door woorden als “zo snel mogelijk”.
  
• De plaats voor het bespreken van de goedkeuring van de wijziging is gestandaardiseerd in de “communicatiecommissie”.
  

Met andere woorden, om te voorkomen dat er misverstanden ontstaan zoals “Ik heb een wijzigingsverzoek gedaan, ik heb het niet gedaan”, “Ik heb gereageerd op de goedkeuring van de wijziging, ik heb het niet gedaan”, is de procedure duidelijk gemaakt.

Begrip van plicht tot oprechtheid en goede trouw wordt in vraag gesteld

We hebben tot nu toe modelcontractclausules geïntroduceerd met betrekking tot zaken als ‘communicatieoverleg’ en ‘wijzigingsoverleg’. Echter, voor een fundamenteel begrip van deze zaken, is het belangrijk om aandacht te besteden aan zaken als ‘plicht tot oprechtheid’ en ‘goede trouw’. De Agile ontwikkelingsmethode kan moeilijk vooruitgaan zonder een vertrouwensrelatie tussen de opdrachtgever en de opdrachtnemer. Dit komt omdat de nadruk ligt op de snelheid van het starten van het daadwerkelijke werk, en de procedures die leiden tot de start worden meestal tot een minimum beperkt. Daarom is het in de praktijk gebruikelijk om clausules op te nemen die de ‘plicht tot oprechtheid’ opleggen aan de andere partij.

Artikel 4, lid 3: Bij het overleg over wijzigingen zullen beide partijen te goeder trouw overleggen over het onderwerp van de wijziging, de mogelijkheid van de wijziging, de invloed van de wijziging op de prijs en de leveringstermijn, enz., en of de wijziging zal worden doorgevoerd.

Dit is bedoeld om te voorkomen dat men plotseling de andere partij verraadt met een formeel juridisch argument, zoals “Of men instemt met een contractwijziging of niet, is geheel aan de discretie van de partij die het verzoek ontvangt, en er is geen verplichting om te voldoen aan dwang”, in onderhandelingen die tot nu toe zijn gebaseerd op een vertrouwensrelatie. Dit weerspiegelt ook de principes van het recht dat van toepassing is op transacties tussen particulieren, niet alleen op systeemontwikkeling.

Artikel 1, lid 2 van het Burgerlijk Wetboek (Japanse Burgerlijk Wetboek)

De uitoefening van rechten en de nakoming van verplichtingen moeten te goeder trouw en oprecht worden uitgevoerd.

De wet respecteert niet alleen de formele ‘inhoud van het contract’ of ‘de bewoordingen van de clausules’. Vooral in transacties waarbij de andere partij betrokken is, moet het flexibel worden gebruikt, rekening houdend met de substantiële ‘goede trouw’ en ‘oprechtheid’. Overigens, het feit dat de ‘verplichting’ die wettelijk wordt opgelegd, niet noodzakelijkerwijs gebaseerd is op de procedure van het ‘contract’, wordt in detail uitgelegd in het volgende artikel.

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

Samenvatting

In systeemontwikkelingsprojecten gebaseerd op het Agile ontwikkelingsmodel is het uiteraard belangrijk om de risico’s te begrijpen die gepaard gaan met een geleidelijke verslapping van administratieve procedures en managementstructuren. Echter, het is niet alleen dat. Het is ook belangrijk om de flexibele kenmerken van de wet, die geworteld zijn in principes zoals de ‘goede trouw’, te begrijpen en deze in de praktijk te brengen.