MONOLITH LAW OFFICE+81-3-6262-3248Feriali 10:00-18:00 JST [English Only]

MONOLITH LAW MAGAZINE

IT

Cosa sono i problemi legali e contrattuali legati allo sviluppo Agile?

IT

Cosa sono i problemi legali e contrattuali legati allo sviluppo Agile?

Esistono diverse metodologie per lo sviluppo di sistemi. La più classica e comune è il modello Waterfall, e molti libri di diritto che trattano lo sviluppo di sistemi si basano su questo modello. In questo articolo, discuteremo i problemi legali associati allo sviluppo di sistemi basati sul modello di sviluppo Agile, che è difficile da comprendere attraverso libri e altre fonti.

Il modello di sviluppo Agile e la legge

Spiegheremo le caratteristiche dello sviluppo Agile.

Cos’è un modello nello sviluppo di sistemi

Nei progetti di sviluppo di sistemi, esiste un modello di sviluppo come struttura per la comprensione generale del progresso. Il rappresentante di questo è il cosiddetto “modello a cascata”. In altre parole, proprio come l’acqua che scende da “monte” a “valle” di un fiume, si tratta di completare ogni fase, come la definizione dei requisiti, la progettazione, l’implementazione, i test, ecc., in un unico flusso. Questo metodo è adatto per ridurre al minimo il ritorno e il doppio lavoro delle procedure e per procedere con il lavoro in modo pianificato.

D’altra parte, nel modello di sviluppo Agile, si ripete l’implementazione di piccoli programmi e i test. Attraverso questa ripetizione di implementazione di piccoli programmi e test, si costruisce gradualmente un grande sistema. Per una spiegazione più dettagliata di questi modelli di sviluppo di sistemi e un confronto dei vantaggi e degli svantaggi di entrambi i modelli di sviluppo, si prega di fare riferimento all’articolo seguente.

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

Caratteristiche del modello di sviluppo Agile

Il grande vantaggio dello sviluppo con il modello Agile è la capacità di entrare nel lavoro effettivo con un senso di velocità. Poiché le attività di “upstream”, come la definizione dei requisiti e la creazione di documenti di progettazione, e l’implementazione del programma non sono separate, è adatto per guidare flessibilmente, compresa la risposta a aggiunte di funzionalità, correzioni e cambiamenti di specifiche. Dal punto di vista legale, i punti particolarmente importanti per il successo del modello di sviluppo Agile sono come gestire la gestione dei documenti e la gestione delle modifiche. Nel modello di sviluppo Agile, i ruoli e le responsabilità non sono chiaramente divisi come nel modello a cascata. Inoltre, poiché si tratta di un metodo che enfatizza la “velocità” di esecuzione e inizio piuttosto che la “gestione”, è facile portare a una mancanza di documenti di progettazione, specifiche e verbali.

Inoltre, in relazione alla gestione delle modifiche, il modello di sviluppo Agile è liscio nella risposta alle modifiche, quindi c’è un rischio che il progetto possa incendiarsi mentre risponde alle richieste di modifica delle specifiche a livello di campo, bypassando il processo di approvazione del decisore. In questo caso, il vantaggio del modello di sviluppo che “la risposta alle modifiche successive è liscia” può diventare un rischio di incendio del progetto.

Gestione dei documenti e del cambiamento nello sviluppo Agile

Come gestire la documentazione e i cambiamenti nel modello di sviluppo Agile?

L’importanza della gestione dei documenti

Nel contesto di un progetto di sviluppo basato sul modello Agile, una preoccupazione legale è l’accumulo di comunicazioni verbali, che può portare a una carenza di documentazione. A proposito, abbiamo discusso in dettaglio l’importanza della gestione dei documenti nei progetti di sviluppo di sistemi in un altro articolo.

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

In quell’articolo, spieghiamo l’importanza della gestione dei documenti nei progetti di sviluppo di sistemi da due prospettive: la prevenzione dei conflitti (ovvero “la gestione preventiva”) e la conservazione delle prove in caso di conflitto (ovvero “la gestione delle crisi”).

L’istituzione di un comitato di coordinamento è efficace per la gestione dei documenti

Quando si adotta il modello di sviluppo Agile, a differenza del modello Waterfall, non esiste un piano chiaro preparato in anticipo. Pertanto, non è sufficiente semplicemente gestire le discrepanze tra il piano e i risultati effettivi, e c’è il rischio che i costi, sia in termini di tempo che di denaro, possano aumentare se si lascia tutto al team di sviluppo.

Un’efficace misura in questo contesto è che il responsabile del progetto organizza regolarmente riunioni di coordinamento per facilitare il progresso del progetto. Se la scala di sviluppo è piccola, è vero che si preferisce un approccio in cui i responsabili si riuniscono di volta in volta piuttosto che organizzare regolari riunioni di coordinamento. Tuttavia, nel modello di sviluppo Agile, il rischio di non affrontare tempestivamente le questioni è particolarmente alto. Pertanto, è sicuro includere l’organizzazione regolare di riunioni di coordinamento anche nei contratti. Il modo in cui questo è stipulato nel contratto modello del Ministero dell’Economia, Commercio e Industria è come segue:

(Istituzione del comitato di coordinamento)

Articolo 12 Le parti A e B, fino al completamento del presente lavoro, al fine di discutere le questioni necessarie per garantire il regolare svolgimento del presente lavoro, quali lo stato di avanzamento, la gestione e la segnalazione dei rischi, lo stato di attuazione del lavoro congiunto e del lavoro diviso tra le parti A e B, la conferma del contenuto da includere nelle specifiche del sistema, la discussione e la risoluzione dei problemi, ecc., organizzeranno un comitato di coordinamento. Tuttavia, (omissis).

2. Il comitato di coordinamento si riunirà regolarmente alla frequenza stabilita nel contratto individuale, e inoltre, si riunirà ogni volta che la parte A o la parte B lo ritenga necessario.

3. Al comitato di coordinamento parteciperanno i responsabili e i principali incaricati di entrambe le parti, nonché coloro che i responsabili ritengono opportuno. Inoltre, sia la parte A che la parte B possono richiedere all’altra parte la partecipazione di persone necessarie per la discussione nel comitato di coordinamento, e l’altra parte deve rispondere a tale richiesta, salvo ragioni valide.

4. La parte B, nel comitato di coordinamento, redigerà e presenterà un rapporto di gestione del progresso secondo il formato concordato separatamente tra la parte A e la parte B, e confermerà lo stato di avanzamento sulla base di tale rapporto di gestione del progresso, nonché la presenza o l’assenza di ritardi, le ragioni e le misure da adottare in caso di ritardi, la necessità di modificare l’organizzazione di promozione stabilita in questo capitolo (come il cambio di personale, l’aumento o la diminuzione del personale, il cambio del subappaltatore, ecc.), lo stato di attuazione delle misure di sicurezza, la presenza o l’assenza di motivi per modificare il contratto individuale, il contenuto dei motivi per modificare il contratto individuale, se presenti, ecc., e confermerà le questioni decise, le questioni da esaminare ulteriormente e, se presenti, il programma di esame e le parti che eseguiranno l’esame.

(Omissione degli articoli 5, 6 e 7.)

Il punto chiave qui è che l’esistenza del comitato di coordinamento conferisce una certa legittimità alle clausole contrattuali, distinguendolo da altre riunioni organizzate ad hoc.

Utilizzare il comitato di coordinamento per gestire i cambiamenti

Inoltre, nello sviluppo Agile, è presupposto che le questioni su cui le due parti hanno inizialmente concordato possano essere modificate successivamente. Pertanto, è molto importante come gestire la situazione di cambiamento delle specifiche in seguito.

In questo contesto, se il comitato di coordinamento si riunisce regolarmente, la gestione dei cambiamenti diventa molto più fluida. Ad esempio, si potrebbe stabilire nel contratto che le discussioni sui cambiamenti avvengono nel comitato di coordinamento e che, se una delle parti richiede una discussione sui cambiamenti, l’altra parte ha l’obbligo di partecipare a tale discussione. (Di seguito è riportato un estratto delle disposizioni del contratto modello del Ministero dell’Economia, Commercio e Industria.)

(Procedura di gestione dei cambiamenti)

Articolo 37 Se la parte A o la parte B riceve una proposta di modifica da parte dell’altra parte (omissis), entro ○ giorni dalla data di ricezione, consegnerà all’altra parte un documento scritto (di seguito denominato “documento di gestione dei cambiamenti”) contenente le seguenti informazioni, e la parte A e la parte B discuteranno l’approvazione o meno di tale modifica nel comitato di coordinamento previsto all’articolo 12. (Omissione delle informazioni da includere)

I punti chiave della disposizione sopra riportata possono essere riassunti come segue:

  • Standardizzazione del metodo di accettazione delle proposte di modifica con un formato chiamato “proposta di modifica”
  • Impostazione di un termine per la discussione sulla proposta di modifica dopo averla ricevuta → Anche se non si utilizza una formulazione come “entro ◯ giorni”, si potrebbe considerare di sostituirla con una frase come “il più presto possibile”.
  • Unificazione del luogo di discussione sull’approvazione o meno della modifica nel “comitato di coordinamento”

In altre parole, per evitare malintesi come “ho fatto una proposta di modifica, non l’ho fatta”, “ho risposto all’approvazione o meno della modifica, non l’ho fatto”, si sta chiarificando il metodo di procedura.

È richiesta una comprensione del dovere di buona fede e del principio di lealtà

Finora, abbiamo presentato modelli di clausole contrattuali relative a “consigli di coordinamento”, “discussioni sulle modifiche”, ecc. Tuttavia, ciò che è importante per una comprensione essenziale di questi è la questione del “dovere di buona fede” e del “principio di lealtà”. In primo luogo, il modello di sviluppo agile tende a diventare difficile da procedere senza una relazione di fiducia tra il committente e il fornitore. Questo perché si dà priorità alla velocità di avvio del lavoro effettivo, e le procedure fino all’avvio sono solitamente ridotte al minimo. Pertanto, è comune nella pratica includere clausole che impongono un “dovere di buona fede” all’altra parte.

Articolo 4, paragrafo 3: Nelle discussioni sulle modifiche, si esamineranno l’oggetto della modifica, la possibilità di modifica, l’impatto della modifica sul prezzo e sulla data di consegna, ecc., e entrambe le parti discuteranno in buona fede se effettuare la modifica.

Questo serve a prevenire un approccio che tradisce l’altra parte con una teoria legale formale, come “se accettare o meno una modifica del contratto è interamente a discrezione della parte che riceve la proposta, e non c’è obbligo di accettare la costrizione”, in negoziati che sono stati condotti sulla base di una relazione di fiducia iniziale. Questo riflette anche i principi del diritto che riguardano le transazioni tra privati, non solo nello sviluppo di sistemi.

Articolo 1, paragrafo 2 del Codice Civile Giapponese

L’esercizio dei diritti e l’adempimento degli obblighi devono essere effettuati in buona fede e con lealtà.

La legge non dà sempre priorità al “contenuto del contratto” o al “testo dell’articolo” che sono puramente formali. In particolare, nelle transazioni con l’altra parte, dovrebbe essere utilizzato in modo flessibile, incorporando la “lealtà” e la “buona fede” sostanziali. Inoltre, per quanto riguarda il fatto che ciò che è imposto come “obbligo” per legge non si basa necessariamente sulla procedura del “contratto”, si veda l’articolo dettagliato di seguito.

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

Riassunto

Nel contesto di un progetto di sviluppo di sistemi basato sul modello di sviluppo Agile, è ovviamente importante comprendere il rischio che le procedure amministrative e la struttura di gestione diventino progressivamente negligenti. Tuttavia, non solo questo, è anche importante comprendere le caratteristiche flessibili che la legge ha di per sé, basate su principi come il “principio di buona fede”, e avere l’atteggiamento di utilizzarle nella pratica.

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

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.

Category: IT

Tag:

Ritorna su