¿Qué es la finalización del trabajo en un contrato de subcontratación en el desarrollo de sistemas?

El desarrollo de sistemas suele ser un proceso que se extiende a lo largo de un período de tiempo considerable, y a menudo se pueden solicitar cambios de especificaciones o la implementación de funciones adicionales. Esto puede poner a los proveedores que aceptan el trabajo en una situación difícil, a veces sin una salida clara a la vista. Para estos proveedores, la cuestión de “¿Qué tenemos que hacer y hasta qué punto para considerar que nuestro trabajo está completo?” puede convertirse en una fuente de preocupación seria.

Además, se puede decir que el desarrollo de sistemas a menudo se lleva a cabo bajo contratos de subcontratación, que son contratos que apuntan a la “finalización del trabajo”.

En este artículo, explicaremos desde un punto de vista legal, “¿En qué momento y hasta qué punto se considera que el desarrollo del sistema está completo?”

¿Qué significa la finalización del desarrollo de sistemas?

La finalización del desarrollo de sistemas desde la perspectiva de un ingeniero

En el campo del desarrollo de sistemas, si se pregunta “¿cuándo se completa el desarrollo del sistema?”, la respuesta generalmente sería “cuando se ha terminado la fase de pruebas y se ha entregado el producto”. Ciertamente, el flujo general del desarrollo del sistema comienza con la definición de los requisitos, donde se identifican las funciones que se deben implementar, seguido de la creación de varios documentos de diseño, la implementación del programa, y finalmente, la fase de pruebas para verificar si el sistema funciona correctamente. El proceso se completa con la aceptación por parte del usuario, que es el paso final.

Por lo tanto, desde la perspectiva de un ingeniero involucrado en el trabajo concreto, la comprensión general sería que “la finalización del desarrollo del sistema = la aprobación de la aceptación”.

La finalización del desarrollo de sistemas desde una perspectiva legal

Por otro lado, desde una perspectiva legal, si se pregunta cuándo se completa el desarrollo del sistema, el foco de la discusión sería cuándo se puede decir que las obligaciones legales que el proveedor tenía bajo el contrato se han cumplido. En primer lugar, los contratos de desarrollo de sistemas se clasifican básicamente en contratos de obra o contratos de mandato.

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

Dejaré la explicación de las diferencias entre estos dos tipos de contratos al artículo anterior, pero en términos de la finalización del desarrollo del sistema, es decir, el cumplimiento de las obligaciones que el proveedor tiene, los criterios de juicio se dan de la siguiente manera:

Contrato de obra: Artículo 632 del Código Civil japonés
Artículo 632
El contrato de obra se establece cuando una de las partes se compromete a completar un trabajo y la otra parte se compromete a pagar una remuneración por el resultado de ese trabajo.
Contrato de mandato: Artículo 648 del Código Civil japonés
Artículo 648
1. A menos que se acuerde lo contrario, el mandatario no puede exigir una remuneración al mandante.
2. En el caso de que el mandatario deba recibir una remuneración, no puede exigirla hasta que haya cumplido con el mandato. Sin embargo, si la remuneración se ha determinado por un período de tiempo, se aplicará el párrafo 2 del artículo 624.
3. Si el mandato se termina a mitad de camino debido a una causa que no puede atribuirse al mandatario, este puede exigir una remuneración proporcional al trabajo ya realizado.

La finalización del desarrollo de sistemas es un problema en los contratos de obra

En cualquier caso, no solo en el contexto del desarrollo de sistemas, el problema de “cuándo se completa el trabajo” es básicamente un problema en los contratos de obra. En el caso de los contratos de mandato, más que considerar que el cumplimiento de la obligación se logra al producir un resultado o producto específico, se trata de un tipo de contrato que implica que una persona con habilidades especializadas, con cierta discreción, hace lo que debe hacer (independientemente del resultado). En los contratos de mandato, incluso si el producto final no se ha realizado como se esperaba, si el proceso de trabajo se ha llevado a cabo adecuadamente, es posible solicitar una remuneración (Artículo 648, párrafo 2), y si el cumplimiento se termina a mitad de camino debido a una causa que no puede atribuirse al mandatario, es posible solicitar una remuneración proporcional al trabajo ya realizado (Artículo 648, párrafo 3). Podríamos decir que los contratos de obra se centran en el “resultado”, mientras que los contratos de mandato se centran en el “proceso”.

Por lo tanto, en los contratos de mandato, más bien, la “obligación de cuidado” en el proceso de llevar a cabo el trabajo encargado tiende a ser un problema legal. Es decir, el problema es cuándo se puede perseguir una violación de la obligación de cuidado basada en un contrato de mandato, asumiendo que se confía en un alto grado de confianza.

Por otro lado, lo importante en los contratos de obra es la “finalización del trabajo”. Si lo que se supone que debe completarse no se completa, no se puede lograr el cumplimiento de las obligaciones que el proveedor tiene, y no se puede solicitar una remuneración, que es el principio. Sin embargo, si se ha completado, no tiene sentido cuestionar las partes del proceso intermedio. Por lo tanto, el problema de “cuándo se completa un proyecto de desarrollo de sistemas” puede ser reformulado básicamente como un problema de interpretación legal de la frase “finalización del trabajo” en los contratos de obra.

¿Cuándo se considera completado un trabajo en el desarrollo de sistemas?

Entonces, ¿cuándo deberíamos considerar específicamente que se ha “completado un trabajo”? Veamos algunos casos judiciales pasados sobre este punto.

Casos judiciales sobre la finalización del trabajo

En el caso judicial citado a continuación, se descubrieron problemas con la velocidad de procesamiento y los costos de comunicación del sistema entregado por el proveedor. A pesar de estos problemas, se discutió si se podía considerar que el trabajo estaba “completado” ya que todas las etapas de desarrollo estaban completas. Como resultado, se indicó que se podía reconocer la finalización del trabajo.

Los artículos 632 y 633 del Código Civil japonés establecen que el momento del pago de la remuneración al contratista por parte del cliente es cuando el contratista ha completado el trabajo y ha entregado el objeto del trabajo al cliente. Por otro lado, el artículo 634 del mismo código establece que si el objeto del trabajo tiene defectos, el contratista tiene la responsabilidad de garantía hacia el cliente (párrafo 1), y hasta que el contratista cumpla con su responsabilidad de garantía por los defectos del objeto del trabajo, el cliente tiene el derecho de defensa de cumplimiento simultáneo con respecto al pago de la remuneración (párrafo 2). Según estas disposiciones del Código Civil japonés, la ley distingue entre los casos en los que el resultado del trabajo es incompleto y los casos en los que el objeto del trabajo tiene defectos y los casos en los que el trabajo no está completo, y se entiende que incluso si el objeto del trabajo tiene defectos, ya sea que estos sean ocultos o evidentes, esto no significa que el trabajo no esté completo.
Por lo tanto, en cuanto a si el contratista ha completado el trabajo o no, se debe juzgar en base a si el trabajo ha terminado hasta la última etapa prevista en el contrato de trabajo original, y se entiende que es apropiado interpretar que el cliente no puede rechazar el pago del precio del contrato simplemente porque el objeto del trabajo tiene defectos, cuando el contratista ha terminado hasta la última etapa del trabajo y ha entregado el objeto del trabajo.

En el fallo anterior, se decidió que la “finalización del trabajo” se cumple si se ha completado hasta la última etapa del desarrollo del sistema. Como medida de alivio cuando hay deficiencias (a menudo llamadas “defectos” en términos legales) en el sistema que el proveedor ha creado, existe un sistema separado de responsabilidad de garantía por defectos.

Por lo tanto, incluso si interpretamos el concepto de “finalización del trabajo” de manera un poco amplia, no resultará en una injusticia para el usuario final. En resumen, sería como sigue:

【Obligación en el contrato de trabajo = Finalización del trabajo = Finalización de todas las etapas】
========
Si el trabajo no está completo…
↓
【Responsabilidad por incumplimiento de la obligación】
========
Si el trabajo está completo pero tiene defectos…
↓
【Reconocimiento del cumplimiento de la obligación y problema de responsabilidad de garantía por defectos】

El caso judicial anterior muestra cómo dividir estos problemas.

Por supuesto, en relación con el punto de “finalización del trabajo”, también podemos considerar desde el punto de vista de “aprobación de la inspección por parte del usuario”. Sobre los problemas legales cuando la inspección del usuario no avanza, explicamos en otro artículo.

https://monolith.law/corporate/estimated-inspection-of-system-development[ja]

Lo que significa la finalización de un trabajo en términos legales

En el desarrollo de sistemas, si se reconoce la “finalización del trabajo”, se considera que se ha cumplido la obligación, por lo que ya no se puede ser perseguido por la responsabilidad de “incumplimiento de la obligación”. En un contrato de obra, si no se puede decir que el trabajo está terminado, no se puede solicitar el pago, y si se ha acordado un pago anticipado u otros términos especiales, estos básicamente deben ser devueltos. Por otro lado, si se reconoce el hecho de que el trabajo está terminado, el proveedor solo tiene que asumir problemas como la garantía de defectos y la garantía de calidad del contrato.

El hecho de que el proveedor sea liberado de la responsabilidad por incumplimiento de la obligación significa que el margen para que el usuario rescinda el contrato se reduce drásticamente. Esto se debe a que la rescisión del contrato basada en la responsabilidad de garantía de defectos está limitada a casos en los que no se puede lograr el objetivo del contrato. Si el contrato es rescindido, el proveedor también pierde el derecho a solicitar el pago (es decir, en términos simples, no recibe ningún pago), por lo que en la práctica, a menudo surgen disputas sobre la “finalización del trabajo”.

Para obtener una explicación detallada sobre la “rescisión” de un contrato en el desarrollo de sistemas, consulte el siguiente artículo.

https://monolith.law/corporate/cancellation-of-contracts-in-system-development[ja]

Consideraciones relacionadas con la finalización del trabajo

Cómo considerar los cambios de especificaciones y el desarrollo adicional

Además, para el proveedor, se puede prever una situación en la que “ya se han cumplido las especificaciones que se mencionaron inicialmente, pero se nos pide que cambiemos las especificaciones y agreguemos funciones, y aunque intentamos terminar el trabajo, no podemos encontrar un punto de corte”. En tales casos, surgen problemas como “el momento de finalizar el desarrollo del sistema”. Para una explicación detallada de este caso, consulte el siguiente artículo.

https://monolith.law/corporate/increase-of-estimate[ja]

Atención también a la reforma del Código Civil japonés

Además, las disposiciones sobre la responsabilidad por garantía de defectos basada en el contrato de obra son un área que ha sido fuertemente influenciada por la reforma del Código Civil japonés, debido a la complejidad y la dificultad de entender las conexiones entre los artículos anteriores. En medio de la reforma del Código Civil japonés, para una explicación detallada de cómo interpretar lo que se llama “defecto”, consulte el siguiente artículo.

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

Resumen

En este artículo, hemos explicado el camino hacia la conexión de los proyectos de desarrollo de sistemas, que a menudo pueden verse atrapados en situaciones donde “no se ve una salida”, con la teoría legal de “finalización del trabajo”. La salida de cada proyecto puede variar según los requisitos de desarrollo, pero cuando surge una disputa sobre estos puntos, no es raro que el concepto legal de “finalización del trabajo” sirva como guía.