Cosa sono i punti da controllare nel contratto per lo sviluppo di sistemi su commissione?

Il Ministero dell’Economia, Commercio e Industria giapponese ha presentato delle clausole modello per i contratti di sviluppo di sistemi IT nelle sue “Linee guida per il miglioramento dell’affidabilità dei sistemi informativi”. Con la diffusione di Internet, l’impatto sociale di interruzioni o diminuzioni delle funzionalità dei servizi a causa di problemi nei sistemi informativi sta diventando sempre più grave. Mentre l’aumento dell’affidabilità e della sicurezza dei sistemi è una questione urgente, i contratti per lo sviluppo di sistemi IT tendono ad essere poco chiari riguardo al contenuto della transazione. Queste clausole mirano a rendere visibili tali contratti e a chiarire la divisione dei ruoli e le relazioni di responsabilità. In questo articolo, spiegheremo i punti da controllare nei contratti per i servizi di sviluppo di sistemi IT, citando le clausole del contratto modello del Ministero dell’Economia, Commercio e Industria giapponese.

Sviluppo di sistemi e contratti di appalto

Cos’è un contratto di appalto

Un contratto di appalto è definito nel codice civile giapponese come segue:

Articolo 632
Un contratto di appalto prende effetto quando una parte promette di completare un certo lavoro e l’altra parte promette di pagare per il risultato di quel lavoro.

In un contratto di appalto, l’obbligo di “promettere di completare un lavoro” è un requisito. Ad esempio, se l’obiettivo del contratto è creare un certo sistema entro una certa data, l’obbligo del fornitore è di “completare il sistema entro la data stabilita”. Se non riesce a completare il sistema entro la data promessa, potrebbe essere ritenuto responsabile per inadempimento contrattuale a causa del ritardo nell’esecuzione. Tuttavia, se vengono scoperti difetti dopo che il sistema è stato completato e consegnato entro la data stabilita, l’obbligo del fornitore è già stato adempiuto, quindi l’inadempimento contrattuale non è un problema, e diventa una questione di responsabilità per i difetti. Nel contesto dello sviluppo di sistemi, discutiamo in dettaglio in un altro articolo quando si può riconoscere il “completamento del lavoro”.

https://monolith.law/corporate/completion-of-work-in-system-development[ja]

Differenze con il contratto di mandato

In un contratto di appalto, il fornitore ha l’obbligo di completare il lavoro, quindi se il prodotto consegnato ha difetti, ha la responsabilità di garantire contro i difetti. D’altra parte, in un contratto di mandato, non c’è obbligo di completare il lavoro, quindi non c’è responsabilità di garantire contro i difetti come in un contratto di appalto. Tuttavia, se viene riconosciuto un dovere di diligenza nella gestione degli affari durante il processo, potrebbe essere ritenuto responsabile per inadempimento contrattuale, come il risarcimento dei danni. Discutiamo in dettaglio in un altro articolo quali responsabilità possono diventare un problema in un contratto di sviluppo di sistemi.

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

Modello di Clausole Contrattuali per Appalti e Punti di Controllo

Servizi di supporto per la creazione di definizioni dei requisiti

La definizione dei requisiti è un’attività che riunisce le specifiche richieste dall’utente per il sistema che intende costruire. Durante la fase di definizione dei requisiti, si discute la direzione della costruzione del sistema e si decide quale tipo di sistema costruire. Poiché non è possibile prevedere concretamente i risultati, il contratto modello del Ministero dell’Economia, Commercio e Industria giapponese (Japanese Ministry of Economy, Trade and Industry) stabilisce che si tratta di un tipo di mandato quasi. Per ulteriori dettagli, si prega di consultare l’articolo sottostante.

https://monolith.law/corporate/system-development-contract-check-quasi-mandate[ja]

Creazione del documento di progettazione esterna

(Implementazione del servizio di creazione del documento di progettazione esterna)
Articolo ○ Il secondo, dopo aver stipulato il contratto individuale specificato nell’articolo ○, svolgerà il servizio di creazione del documento di progettazione esterna del software in questione, basandosi sul documento di definizione dei requisiti stabilito secondo le disposizioni dell’articolo ○.

2. Durante l’implementazione del servizio di creazione del documento di progettazione esterna, il secondo può richiedere la cooperazione necessaria al primo, e il primo deve rispondere tempestivamente quando viene richiesta la cooperazione dal secondo.

La creazione del documento di progettazione esterna è un servizio che stabilisce l’uso di parti correlate all’interfaccia, come schermate e report. Il documento di progettazione esterna deve contenere tutte le informazioni necessarie per permettere al fornitore di sviluppare il programma basandosi su di esso. Il documento di progettazione esterna include dettagli sull’uso del formato, ma solo l’utente, che determina il contenuto del lavoro, può modificare le specifiche richieste. Tuttavia, se il documento di definizione dei requisiti, che è il risultato della fase precedente del servizio di creazione del documento di progettazione esterna, può definire chiaramente le esigenze dell’utente e il contenuto del lavoro che il fornitore deve completare, è possibile stipulare un contratto in cui il fornitore è il principale nella creazione del documento di progettazione esterna.

Il primo paragrafo stabilisce che il fornitore è il principale nell’esecuzione del lavoro, poiché questo processo è di tipo contrattuale. Tuttavia, anche in un contratto di tipo contrattuale, poiché la progettazione esterna ha un grande impatto sulla determinazione del contenuto del lavoro dell’utente, è richiesta una partecipazione attiva da parte dell’utente. Pertanto, il secondo paragrafo chiarisce che il fornitore può richiedere la cooperazione dell’utente per discutere e decidere le specifiche del sistema, e che l’utente deve rispondere tempestivamente, rendendo chiaro che la discussione delle specifiche del sistema è un lavoro congiunto tra il fornitore e l’utente.

(Stipulazione del contratto individuale relativo al servizio di creazione del documento di progettazione esterna)
Articolo ○ Il primo e il secondo, riguardo al servizio di creazione del documento di progettazione esterna, decideranno le condizioni di transazione descritte nell’articolo ○, paragrafo ○, dopo la discussione, e stipuleranno un contratto individuale relativo al servizio di creazione del documento di progettazione esterna.

Il campo di applicazione del servizio di creazione del documento di progettazione esterna è stabilito nel contratto individuale in conformità con le condizioni di transazione stabilite nell’articolo precedente.

(Riunione di discussione sulla progettazione esterna)
Articolo ○ Il secondo, al fine di chiarire o confermare i contenuti necessari per la creazione del documento di progettazione esterna, terrà una riunione di discussione sulla progettazione esterna (di seguito denominata “riunione di discussione sulla progettazione esterna” in questa sezione) a una frequenza ritenuta necessaria, e il primo parteciperà a questa riunione.

2. Anche il primo, quando ritiene necessario per la creazione del documento di progettazione esterna, può tenere una riunione di discussione sulla progettazione esterna, e il secondo parteciperà a questa riunione.

3. Se il primo intende modificare il contenuto del documento di definizione dei requisiti a seguito delle discussioni, ecc. nella riunione di discussione sulla progettazione esterna, e se ciò richiede la modifica delle condizioni del contratto individuale, come il periodo di lavoro e la commissione, si seguirà la procedura dell’articolo 33 (Modifica del contenuto del presente contratto e del contratto individuale).

Per la creazione del documento di progettazione esterna, che determina l’interfaccia come schermate e report, è essenziale il lavoro congiunto tra l’utente e il fornitore. Poiché questo processo è di tipo contrattuale, il primo paragrafo stabilisce che il fornitore è l’organizzatore della riunione di discussione e l’utente partecipa a essa. La chiarificazione o la conferma dei contenuti necessari per la creazione del documento di progettazione esterna si svolge tutte nella riunione di discussione sulla progettazione esterna, e il fornitore e l’utente sono vincolati dai risultati della discussione nella riunione.

Il secondo paragrafo stabilisce che anche l’utente può tenere una riunione di discussione sulla progettazione esterna quando ritiene necessario per l’implementazione del servizio di creazione del documento di progettazione esterna.
Il terzo paragrafo stabilisce che, se a seguito delle discussioni, ecc., l’utente intende modificare il contenuto del documento di definizione dei requisiti, e ciò può influire sul periodo di lavoro, la commissione, ecc. stabiliti nel contratto individuale, si seguirà il metodo di modifica del contenuto del presente contratto e del contratto individuale stabilito in un altro articolo.

(Consegna del documento di progettazione esterna)
Articolo ○ Il secondo consegnerà al primo il documento di progettazione esterna e la richiesta di accettazione del documento di progettazione esterna (anche nota come nota di consegna) entro la data stabilita nel contratto individuale.

Poiché questo processo è di tipo contrattuale, il fornitore consegnerà il documento di progettazione esterna, ecc. come risultato.

(Approvazione e conferma del documento di progettazione esterna)
Articolo ○ Il primo, entro il periodo stabilito nel contratto individuale (di seguito denominato “periodo di ispezione del documento di progettazione esterna”), ispezionerà se il documento di progettazione esterna è conforme al documento di definizione dei requisiti confermato secondo le disposizioni dell’articolo ○ e alle decisioni prese nella riunione di discussione sulla progettazione esterna specificata nell’articolo ○, e se non ci sono errori logici, e firmerà e sigillerà il documento di approvazione del documento di progettazione esterna come prova di conformità e assenza di errori logici da parte dei responsabili di entrambe le parti. Tuttavia, se a seguito dell’ispezione, si scopre che il documento di progettazione esterna non è conforme al documento di definizione dei requisiti confermato secondo le disposizioni dell’articolo ○ e alle decisioni prese nella riunione di discussione sulla progettazione esterna, o se si scoprono errori logici, il secondo creerà una versione corretta entro il periodo stabilito dopo la discussione e la presenterà al primo, e il primo eseguirà nuovamente l’ispezione e la procedura di approvazione sopra descritte.

2. Se il primo non esprime obiezioni per iscritto con motivi specifici durante il periodo di ispezione del documento di progettazione esterna, si considera che il primo ha approvato il documento di progettazione esterna alla fine del periodo di ispezione del documento di progettazione esterna.

3. Il documento di progettazione esterna sarà considerato confermato con l’approvazione del primo secondo i due paragrafi precedenti.

Nel processo di progettazione esterna, si confermano i requisiti necessari per l’implementazione di lavori successivi come la creazione del documento di progettazione interna, ma se la conferma dei requisiti rimane vaga, possono sorgere problemi nello sviluppo successivo. Questo articolo stabilisce la procedura per ispezionare il documento di progettazione esterna, che è la base per i lavori di sviluppo successivi, da parte dell’utente, e per confermarlo con l’approvazione dell’utente.

Il primo paragrafo stabilisce che l’utente ispezionerà la conformità del documento di progettazione esterna con il documento di definizione dei requisiti confermato in un altro articolo e con i risultati della discussione nella riunione di discussione sulla progettazione esterna, e l’assenza di errori logici. Ci possono essere casi in cui si ritiene necessaria una correzione durante l’ispezione per l’approvazione del documento di progettazione esterna, e la clausola di riserva in questo paragrafo stabilisce la procedura in questo caso.
Il secondo paragrafo è una disposizione che considera che l’utente ha approvato, anche se la firma e il sigillo di approvazione non sono stati completati, se l’utente non ha espresso obiezioni entro un certo periodo di tempo. Poiché l’approvazione o meno da parte dell’utente può rimanere vaga e causare problemi in seguito se si entra nella progettazione interna, questa disposizione mira a prevenire tali problemi.

E il terzo paragrafo stabilisce che il documento di progettazione esterna sarà considerato confermato con l’approvazione dell’utente.

(Responsabilità per la garanzia dei difetti)
Articolo ○ Dopo la conferma dell’articolo precedente, se si scopre un difetto (di seguito denominato “difetto” in questo articolo) nel documento di progettazione esterna, come una discrepanza tra il documento di definizione dei requisiti e le decisioni prese nella riunione di discussione sulla progettazione esterna specificata nell’articolo ○, o un errore logico, il primo può richiedere al secondo di correggere tale difetto, e il secondo correggerà tale difetto. Tuttavia, il secondo sarà responsabile di tale correzione solo se la richiesta è stata fatta dal primo entro ○ mesi dalla conferma dell’articolo precedente.

2. Nonostante il paragrafo precedente, se il difetto è minore e la correzione del documento di progettazione esterna richiede un costo eccessivo, il secondo non sarà responsabile della correzione specificata nel paragrafo precedente.

3. Le disposizioni del paragrafo 1 non si applicano quando il difetto è causato da documenti forniti dal primo o da istruzioni date dal primo. Tuttavia, questo non si applica se il secondo sapeva che tali documenti o istruzioni erano inadeguati e non lo ha comunicato.

Questo articolo stabilisce la responsabilità per la garanzia dei difetti relativi al documento di progettazione esterna. Il periodo di garanzia dei difetti sarà stabilito in considerazione della scala del sistema informativo, del prezzo, ecc., attraverso discussioni tra le parti.

Il primo paragrafo definisce come difetto la discrepanza tra il documento di progettazione esterna e il documento di definizione dei requisiti e le decisioni prese nella riunione di discussione sulla progettazione esterna, o un errore logico nel documento di progettazione esterna.

Il secondo paragrafo protegge il fornitore, affermando che il fornitore non è responsabile della correzione gratuita se il difetto è minore e la correzione del documento di progettazione esterna richiede un costo eccessivo, in conformità con l’articolo 634, paragrafo 1, clausola di riserva del Codice Civile.

Il terzo paragrafo è una disposizione che, in conformità con la clausola di riserva dell’articolo 636 del Codice Civile, esonera il fornitore dalla responsabilità di garanzia se il difetto è causato da istruzioni o documenti forniti dall’utente, a meno che il fornitore non sapesse che tali documenti o istruzioni erano inadeguati e non lo ha comunicato.

Si prega di notare che la responsabilità per la garanzia dei difetti è una disposizione opzionale, quindi se non si stabilisce tale disposizione, la questione sarà gestita secondo i principi generali del Codice Civile. La responsabilità per la garanzia dei difetti è un’area che sarà notevolmente influenzata dall’emendamento del Codice Civile che entrerà in vigore nell’aprile 2020, quindi dopo l’entrata in vigore dell’emendamento del Codice Civile, il modo in cui viene gestita sarà diverso. Per i dettagli, si prega di fare riferimento all’articolo seguente.

https://monolith.law/corporate/defect-warranty-liability[ja]

Servizi di sviluppo software

(Implementazione dei servizi di sviluppo software)
Articolo 〇 Il contraente, dopo aver stipulato il contratto individuale specificato nell’articolo 25, svolgerà i servizi di sviluppo software, che includono la progettazione interna e i test del sistema, in base alle specifiche del sistema definite nelle sezioni precedenti.

2. Durante l’implementazione dei servizi di sviluppo software, il contraente può richiedere la cooperazione necessaria al committente, e il committente deve rispondere tempestivamente a tale richiesta.

Nel seguente articolo, sono stabilite le clausole relative ai casi in cui lo sviluppo del software viene effettuato su base contrattuale dal fornitore. Nella fase di progettazione interna del sistema, è normale che l’oggetto di sviluppo e le specifiche siano definiti fino alla fase precedente, quindi nel contratto modello del Ministero dell’Economia, del Commercio e dell’Industria, è definito come contrattuale.

(Conclusione del contratto individuale relativo ai servizi di sviluppo software)
Articolo 〇 Il committente e il contraente, dopo aver discusso e deciso le condizioni di transazione specificate nell’articolo 〇, paragrafo 〇, stipuleranno un contratto individuale relativo ai servizi di sviluppo software.

Il campo di applicazione dei servizi di sviluppo software, ecc., sarà deciso in base alle condizioni di transazione stabilite in precedenza, mediante un contratto individuale.

(Consegna dei prodotti)
Articolo 〇 Il contraente consegnerà al committente i prodotti specificati nel contratto individuale, insieme alla richiesta di accettazione (nota di consegna), entro la data stabilita nel contratto individuale.
2. Se c’è una consegna, il committente eseguirà l’ispezione in base alle specifiche di ispezione dell’articolo successivo, in conformità con le disposizioni dell’articolo 〇 (Accettazione del software in questione).
3. Durante la consegna dei prodotti, il contraente può richiedere la cooperazione necessaria al committente, e il committente deve rispondere prontamente a tale richiesta.
4. Il rischio di perdita o danneggiamento dei prodotti sarà a carico del contraente prima della consegna e del committente dopo la consegna.

Dato che questo processo è contrattuale, il software completato, ecc., sarà consegnato come prodotto da ispezionare. Il primo paragrafo stabilisce che i prodotti devono essere consegnati insieme alla richiesta di accettazione (nota di consegna).

Il secondo paragrafo stabilisce l’implementazione dell’ispezione da parte dell’utente.
Il terzo paragrafo stabilisce l’obbligo di cooperazione dell’utente per la consegna al luogo di consegna specificato nel contratto individuale, poiché ci possono essere casi in cui è necessaria la cooperazione dell’utente (ad esempio, quando i prodotti vengono consegnati entrando nell’ufficio dell’utente, o quando vengono consegnati in uno stato operativo nell’ambiente di produzione effettivo dell’utente).
Il quarto paragrafo è una clausola sul rischio di perdita o danneggiamento dei prodotti, che divide il momento del trasferimento del rischio in base al trasferimento del controllo fisico.

(Accettazione del software in questione)
Articolo 〇 Per quanto riguarda il software in questione tra i prodotti consegnati, il committente deve ispezionarlo in base alle specifiche di ispezione dell’articolo precedente entro il periodo specificato nel contratto individuale (di seguito denominato “periodo di ispezione”) e verificare se le specifiche del sistema e il software in questione corrispondono.

2. Se il software in questione è conforme all’ispezione del paragrafo precedente, il committente deve firmare e sigillare il certificato di accettazione e consegnarlo al contraente. Inoltre, se il software in questione non supera l’ispezione del paragrafo precedente, il committente deve consegnare prontamente al contraente un documento che indica chiaramente le ragioni specifiche per la non conformità, e richiedere la correzione o il completamento. Quando le ragioni della non conformità sono riconosciute, il contraente deve correggere gratuitamente entro il periodo stabilito dopo la discussione e consegnare al committente, e il committente deve eseguire nuovamente l’ispezione specificata nel paragrafo precedente entro l’ambito necessario.

3. Anche se il certificato di accettazione non è stato consegnato, se il committente non presenta obiezioni indicando ragioni specifiche per iscritto durante il periodo di ispezione, il software in questione sarà considerato come aver superato l’ispezione specificata in questo articolo.

4. L’accettazione del software in questione sarà completata con l’accettazione dell’ispezione specificata in questo articolo.

Dato che questo processo è contrattuale, questo articolo stabilisce la procedura per l’accettazione del software consegnato.

Il primo paragrafo stabilisce che il committente deve ispezionare il software in questione in base alle specifiche di ispezione entro il periodo di ispezione e verificare se le specifiche del sistema e il software in questione corrispondono.
Il secondo paragrafo obbliga il fornitore a correggere e consegnare la versione corretta all’utente se si scopre che il software in questione non è conforme alle specifiche del sistema.
Il terzo paragrafo è una disposizione che prevede l’accettazione presunta per prevenire il ritardo dell’accettazione a causa dell’utente.
Il quarto paragrafo chiarisce che l’accettazione del software in questione sarà completata con l’accettazione dell’ispezione.

(Responsabilità per i difetti)
Articolo 〇 Dopo l’ispezione completata nell’articolo precedente, se viene scoperta una discrepanza (inclusi i bug) tra i prodotti consegnati e le specifiche del sistema (di seguito denominata “difetto” in questo articolo), il committente può richiedere al contraente di correggere tale difetto, e il contraente deve correggere tale difetto. Tuttavia, il contraente sarà responsabile per tale correzione solo se la richiesta viene fatta dal committente entro 〇 mesi dopo l’accettazione completata nell’articolo precedente.
2. Nonostante il paragrafo precedente, se il difetto è minore e la correzione del prodotto richiede un costo eccessivo, il contraente non sarà responsabile per la correzione specificata nel paragrafo precedente.
3. Le disposizioni del paragrafo 1 non si applicano quando il difetto è causato dai materiali forniti dal committente o dalle istruzioni date dal committente. Tuttavia, questo non si applica se il contraente non ha notificato che tali materiali o istruzioni erano inadeguati pur sapendolo.

Dato che questo processo è contrattuale, questo articolo stabilisce la responsabilità per i difetti dei prodotti consegnati. Il confine tra la responsabilità per l’inadempimento del debito quando l’esecuzione non è stata effettuata (il lavoro non è stato completato) e la responsabilità per i difetti dopo che l’esecuzione è stata completata in un certo senso (il lavoro è stato completato) è difficile da determinare nella pratica. C’è un precedente giudiziario (sentenza del Tribunale di Tokyo del 22 aprile 2002) che afferma che se il sistema di sviluppo dovrebbe essere considerato completato o meno dovrebbe essere basato su se il lavoro è stato completato fino all’ultimo processo previsto nel contratto iniziale. Se un difetto viene scoperto dopo la consegna e l’accettazione del software e l’ispezione è stata completata, in linea di principio, la responsabilità per i difetti sarà applicabile.

Il primo paragrafo definisce la “discrepanza con le specifiche del sistema” che si verifica nei servizi di sviluppo software come un difetto. Per quanto riguarda le carenze funzionali, ecc., che si verificano nella fase di progettazione esterna, la responsabilità sarà determinata dalle disposizioni sulla responsabilità per i difetti nella fase di progettazione esterna, ecc., non da questo articolo. Il periodo di garanzia per i difetti sarà determinato tra le parti in base alla scala del sistema informativo, al prezzo, ecc., e sarà un periodo che si ritiene ragionevole.

Il secondo paragrafo prevede una disposizione simile all’articolo 634, paragrafo 1, del Codice Civile, che prevede che se il difetto è minore e la correzione del prodotto richiede un costo eccessivo, il fornitore non sarà responsabile per la correzione.

Il terzo paragrafo è una disposizione simile all’articolo 636 del Codice Civile, che prevede che il fornitore non sarà responsabile per i difetti se il difetto è causato dalle istruzioni o dai materiali forniti dall’utente, a meno che il fornitore non abbia notificato che tali materiali o istruzioni erano inadeguati pur sapendolo.

Per ulteriori dettagli su quando un difetto viene riconosciuto e sul contenuto specifico della responsabilità quando un difetto viene riconosciuto, si prega di fare riferimento all’articolo seguente.

https://monolith.law/corporate/defect-warranty-liability[ja]

Servizi di supporto per la preparazione e la transizione del software

Nella fase di accettazione e implementazione del sistema, è comune che l’utente agisca in modo proattivo. Pertanto, nel contratto modello del Ministero dell’Economia, Commercio e Industria giapponese (METI), è previsto che l’utente sia il principale responsabile, con il fornitore che fornisce supporto in una forma semi-delegata.

Definizione della natura del contratto

Per determinare la natura di un contratto, si deve considerare l’intero contratto e il suo scopo, che può essere “fornire un prodotto finito” o “eseguire un lavoro in modo ragionevole” da parte del fornitore. Un indicatore generale è se il contenuto dell’oggetto da completare è stato definito in modo abbastanza concreto e se il progetto è stato portato avanti in vista di questo. Per quanto riguarda i punti specifici da considerare, li spieghiamo in dettaglio nell’articolo seguente.