Cosa sono le responsabilità per inadempimento del contratto nello sviluppo di sistemi e software? Spiegazione dei punti di revisione

Cosa dovrebbe fare legalmente se ci fosse un errore nel sistema ordinato dopo la consegna?
Se il metodo di funzionamento è difficile, la velocità di elaborazione è lenta, o la funzione ordinata non è disponibile… Come committente, si dovrebbe sollevare la questione della “responsabilità per inadempimento contrattuale” nei confronti del fornitore che ha sviluppato il sistema.
La “responsabilità per inadempimento contrattuale” è stata introdotta in sostituzione della “responsabilità per vizi” che è stata abolita con la revisione del Codice Civile Giapponese nel 2017 (anno 2017 del calendario gregoriano). Pertanto, è necessario prestare attenzione a come questa revisione influisce sullo sviluppo di sistemi e software.
Spesso si verificano problemi dopo la consegna. Per evitare tali problemi, spiegheremo il contenuto della “responsabilità per inadempimento contrattuale” e l’impatto della revisione.
Modifiche al Codice Civile Giapponese sulla Responsabilità per Inadempimento Contrattuale

La “Legge di modifica di alcune parti del Codice Civile Giapponese” è stata promulgata il 2 giugno 2017 (anno 29 dell’era Heisei) ed è entrata in vigore il 1 aprile 2020.
La parte del Codice Civile Giapponese che stabilisce le regole più fondamentali relative ai contratti è chiamata “Diritto delle obbligazioni”.
Il Diritto delle obbligazioni non era stato sostanzialmente rivisto da quando fu istituito nel 1896 (anno 29 dell’era Meiji), circa 120 anni fa.
La revisione di questa volta è stata effettuata per adeguare il diritto alle esigenze della società attuale.
Le modifiche specifiche sono molteplici, ma tra queste, l’introduzione del concetto di “responsabilità per inadempimento contrattuale” è uno dei principali punti di modifica.
Di conseguenza, ciò che era precedentemente chiamato “responsabilità per vizi” è stato sostituito con “responsabilità per inadempimento contrattuale”.
Cosa si intende per “Non Conformità Contrattuale”

Per “Non Conformità Contrattuale” si intende la mancanza delle funzionalità, qualità, prestazioni o condizioni che dovrebbero essere presenti in base all’accordo tra le parti o alla natura e allo scopo del contratto.
Questo concetto di “Non Conformità Contrattuale” è stato introdotto in sostituzione del precedente termine “difetto” a seguito della revisione del Codice Civile Giapponese.
Nel contesto dello sviluppo di sistemi e software, si verifica una “Non Conformità Contrattuale” quando il sistema completato non corrisponde alle specifiche stabilite in anticipo, o quando il sistema o il software non possiede le funzionalità o le prestazioni che dovrebbe normalmente avere in base alla sua natura.
Nella valutazione della presenza o meno di una “Non Conformità Contrattuale”, si dà particolare importanza all’accordo tra le parti e alla natura e allo scopo del contratto.
Di conseguenza, è importante documentare lo scopo dello sviluppo del sistema o del software e le circostanze dell’ordine, per chiarire quali erano le richieste e le aspettative del committente.
Casi in cui i problemi del software corrispondono a “non conformità del contratto”

Quando il software presenta problemi e la riparazione è ritardata
Innanzitutto, si può considerare il caso in cui si verificano problemi non trascurabili nel software e non è possibile affrontarli prontamente, come quando è necessario tornare alla fase di progettazione per la correzione.
Ad esempio, esiste un precedente giudiziario in cui è stato riconosciuto come “difetto”, che corrisponde alla “non conformità del contratto” attuale, il caso in cui si sono verificati problemi come il fatto che il processo di ricerca del sistema di interrogazione dell’inventario introdotto richiede più di 30 minuti, e si è dovuto rispondere alle domande dei clienti creando un registro dell’inventario scritto a mano (sentenza del Tribunale Distrettuale di Tokyo, 22 aprile 2002 (anno 14 dell’era Heisei)).
Quando i problemi si manifestano progressivamente
Inoltre, anche se ogni singolo problema è minore e non richiede molto tempo per essere corretto, si può considerare il caso in cui i problemi si manifestano ripetutamente e ci vuole molto tempo per correggere tutti i problemi e far funzionare correttamente il sistema.
Ad esempio, se si verificano ripetutamente problemi nel sistema di interrogazione dell’inventario introdotto, e non è chiaro quanti problemi si verificheranno in futuro e quanto tempo ci vorrà per correggerli, e non è possibile svolgere le normali operazioni aziendali utilizzando il sistema, si può dire che c’è una “non conformità del contratto”.
Casi in cui un difetto del software non costituisce una “non conformità del contratto”

Se il difetto è stato riparato senza ritardi o se sono state prese misure alternative
Secondo la giurisprudenza, anche se un utente segnala un bug o un altro difetto, se il difetto è stato riparato senza ritardi o se sono state prese misure alternative ritenute adeguate dopo aver consultato l’utente, non si considera un “difetto” (sentenza del Tribunale Distrettuale di Tokyo, 18 febbraio 1997 (anno 9 dell’era Heisei)).
Nello sviluppo di sistemi e software, è impossibile programmare in modo da evitare completamente i bug, e l’insorgenza di alcuni difetti è inevitabile.
Quindi, anche se c’è un difetto, se si prendono misure come la riparazione senza ritardi, non dovrebbe essere considerato un “difetto”.
Questo può essere considerato allo stesso modo anche sotto l’attuale concetto di “non conformità del contratto”.
Il giudizio su “senza ritardi” e simili è basato su prove come i verbali creati durante il processo di sviluppo del sistema.
Per ulteriori dettagli sull’importanza di queste prove, si prega di consultare l’articolo sottostante.
https://monolith.law/corporate/the-minutes-in-system-development[ja]
Se un individuo specifico non è in grado di comprendere facilmente il metodo di funzionamento
Per quanto riguarda l’usabilità e la facilità d’uso, poiché queste sono in gran parte soggettive, se un utente generico non può utilizzarlo, viene considerato una “non conformità del contratto”.
Il fatto che un individuo specifico non sia in grado di comprendere facilmente il metodo di funzionamento non significa che ci sia una “non conformità del contratto”.
Se un difetto si verifica a causa di qualcosa al di fuori del lavoro del fornitore
Se un difetto si verifica a causa di qualcosa che non ha nulla a che fare con il lavoro di sviluppo del fornitore che sviluppa il sistema o il software, non si può dire che ci sia una “non conformità del contratto” nel sistema o nel software stesso.
Ad esempio, se un difetto si verifica a causa di un problema con l’hardware, che il fornitore non è responsabile di procurare, non viene considerato una “non conformità del contratto”.
[Nota] Se un difetto si verifica a causa di istruzioni errate dell’utente
Se un difetto si verifica nel sistema o nel software completato a causa di istruzioni errate dell’utente, anche se si riconosce che c’è una “non conformità del contratto” nel sistema, ecc., il fornitore non è generalmente responsabile per la non conformità del contratto.
Ad esempio, se un difetto si verifica nel software sviluppato sulla base delle specifiche concordate a causa di una spiegazione errata su una questione che solo l’utente può conoscere durante lo sviluppo del sistema aziendale, il fornitore non ha alcuna responsabilità.
Si ritiene che dietro a questa decisione ci sia l’idea che anche l’utente, come committente dello sviluppo del software, ha un “obbligo di cooperazione”. Per ulteriori dettagli, si prega di consultare l’articolo sottostante.
https://monolith.law/corporate/user-obligatory-cooporation[ja]
Questioni che il committente/acquirente può richiedere sulla base della responsabilità per inadempimento contrattuale

In questo articolo, spiegheremo il contenuto della responsabilità per inadempimento contrattuale relativo allo sviluppo di sistemi e software, tenendo conto delle modifiche apportate dalla revisione.
Richiesta di riparazione
Se un difetto è valutato come un inadempimento contrattuale, il committente può richiedere la sua riparazione.
Prima della revisione, non era possibile richiedere la riparazione se il difetto in questione non era significativo e se la riparazione richiedeva un costo eccessivo. Questa limitazione è stata eliminata con la revisione.
Tuttavia, anche dopo la revisione, se “l’inadempimento contrattuale non è significativo e la riparazione richiede un costo eccessivo”, potrebbe non essere possibile richiedere la riparazione se la riparazione è impossibile.
Richiesta di risarcimento danni
Se un sistema o un software difettoso impedisce le normali operazioni commerciali o richiede costi extra, il committente può richiedere un risarcimento danni.
Prima della revisione, era possibile richiedere un risarcimento danni indipendentemente dalla presenza o meno di negligenza, a meno che non ci fossero accordi speciali.
Tuttavia, con la revisione, se l’esecutore ha una causa di esonero da responsabilità (una causa che non può essere attribuita alla colpa del debitore), non sarà possibile richiedere un risarcimento danni.
Di conseguenza, se il fornitore può dimostrare una causa di esonero da responsabilità, non sarà responsabile per il risarcimento danni.
Risoluzione del contratto
Il contratto di sviluppo può essere risolto a causa dell’inadempimento contrattuale del sistema o del software.
In un caso giudiziario che abbiamo già presentato, è stato riconosciuto il diritto di risolvere il contratto perché il sistema di interrogazione dell’inventario richiedeva più di 30 minuti per il processo di ricerca, il tempo di elaborazione era eccessivamente lungo, e si verificavano problemi come l’impossibilità di utilizzare il terminale stesso (Sentenza del Tribunale Distrettuale di Tokyo, 22 aprile 2002 (anno 14 dell’era Heisei, 2002 nel calendario gregoriano)).
Prima della revisione, era possibile risolvere il contratto solo se il difetto impediva di “raggiungere l’obiettivo del contratto”. Tuttavia, questa limitazione è stata eliminata con la revisione.
Tuttavia, anche sotto la legge modificata, è importante notare che se il grado di inadempimento contrattuale è “minore”, la risoluzione non sarà riconosciuta.
Richiesta di riduzione del compenso
Il diritto di richiedere una riduzione del compenso è stato introdotto con la revisione.
Se ci sono difetti nel sistema e il committente ha richiesto la loro riparazione, ma la riparazione non è stata effettuata nonostante sia passato un periodo di tempo ragionevole, il committente può richiedere una riduzione del compenso.
Periodo di responsabilità
- Richiesta di riparazione
- Richiesta di risarcimento danni
- Risoluzione del contratto
- Richiesta di riduzione del compenso
Il periodo in cui è possibile esercitare questi diritti è limitato.
Specificamente, è possibile esercitare i diritti solo se il committente ha notificato al fornitore l’esistenza di un inadempimento contrattuale nel sistema o nel software “entro un anno dalla scoperta”.
Prima della revisione, il periodo di esercizio dei diritti era limitato a “entro un anno dalla consegna” del sistema o del software. Pertanto, si può dire che il periodo in cui è possibile esercitare i diritti è stato esteso con la revisione.
Inoltre, indipendentemente da questa limitazione di tempo, i diritti riconosciuti sulla base della responsabilità per inadempimento contrattuale sono soggetti anche alle disposizioni sulla prescrizione.
Quindi, ad esempio, se si scopre l’esistenza di un difetto per la prima volta 11 anni dopo aver ricevuto la consegna del sistema o del software, i diritti come il diritto di richiedere un risarcimento danni saranno scaduti dopo il periodo di prescrizione di “dieci anni”, indipendentemente dal fatto che si notifichi l’inadempimento contrattuale “entro un anno dalla scoperta”.
Rifiuto del pagamento del compenso
Il committente può rifiutare di pagare l’intero compenso fino a quando il fornitore non ha effettuato la riparazione o il risarcimento danni.
Punti chiave delle disposizioni contrattuali considerando la non conformità del contratto

Le disposizioni sulla responsabilità per la non conformità del contratto sono facoltative e possono essere limitate o abbreviate in termini di responsabilità e periodo di esercizio dei diritti attraverso accordi speciali tra le parti.
Quindi, in questo articolo, spiegheremo le disposizioni contrattuali che dovrebbero essere prese in considerazione in relazione alla responsabilità per la non conformità del contratto nello sviluppo di sistemi e software.
Punto 1: Eventi e ambito di applicazione della non conformità del contratto
Se ci sono problemi con il sistema o il software, il committente vorrà probabilmente perseguire la responsabilità del fornitore per la non conformità del contratto.
Tuttavia, come fornitore, non è accettabile essere perseguitati per la responsabilità della non conformità del contratto solo perché non si è soddisfatti delle specifiche.
Inoltre, il fornitore potrebbe aumentare significativamente il preventivo per proteggersi da rivendicazioni ingiuste di responsabilità per la non conformità del contratto, il che sarebbe svantaggioso anche per il committente.
Quindi, è importante che il committente indichi per iscritto quali obiettivi ha e quali funzioni vuole che il sistema abbia, e che queste informazioni siano correttamente riflette nel documento di specifiche, al fine di chiarire gli eventi e l’ambito di applicazione della non conformità del contratto.
Si potrebbe anche considerare di chiarire che, se il sistema o il software viene consegnato esattamente come specificato nel documento di specifiche, non sarà considerato non conforme al contratto, anche se ci sono problemi con le specifiche.
Questa disposizione può prevenire la responsabilità per la non conformità del contratto a causa delle preferenze del committente, nonostante lo sviluppo sia stato effettuato secondo le specifiche.
Punto 2: Chiarificazione del periodo di garanzia
Il periodo di esercizio dei diritti per la responsabilità della non conformità del contratto inizia non “al momento della consegna” del prodotto, ma “al momento della scoperta” della non conformità del contratto.
Inoltre, anche se si applica un termine di prescrizione separato, il periodo è al massimo “dieci anni”, che è un periodo di tempo molto lungo.
Per il fornitore, la necessità di fornire una garanzia gratuita per un periodo così lungo come “dieci anni” in alcuni casi è un grande onere, e deve inevitabilmente essere incluso nel preventivo.
D’altra parte, per il committente, potrebbe essere più vantaggioso stabilire un periodo di garanzia flessibile in base al periodo di utilizzo del sistema o del software, in termini di costi e altri fattori.
Quindi, si potrebbe considerare di stabilire un periodo di garanzia flessibile in base al contenuto del sistema, ecc.
Punto 3: Risposta in caso di non conformità del contratto
In caso di non conformità del contratto, è possibile limitare i diritti che possono essere esercitati, tra quelli riconosciuti dal codice civile, come richieste di risarcimento danni o risoluzione, attraverso un accordo tra le parti.
Come committente, è necessario capire bene quali limitazioni sono state imposte nel contratto.
Riassunto: Consulta un avvocato per la redazione di un contratto che include la “responsabilità per inadempimento contrattuale”

A seguito della riforma del Codice Civile Giapponese, sono emerse importanti implicazioni legali anche per lo sviluppo di sistemi e software.
Non è possibile affermare in modo categorico se un malfunzionamento del sistema consegnato rientra nella “inadempimento contrattuale” e quale responsabilità può essere richiesta.
Inoltre, per prevenire i conflitti in anticipo, è essenziale avere un’ampia discussione tra il committente e il fornitore durante la fase del contratto di sviluppo.
Se avete dubbi sulla redazione del contratto, non esitate a consultare un avvocato specializzato.
Category: IT
Tag: ITSystem Development