¿Hasta qué punto se debe implementar legalmente una función que no está en la especificación de desarrollo del sistema?

Los proyectos que desarrollan sistemas de TI utilizados en las empresas se crean, en principio, de acuerdo con las especificaciones definidas previamente. Sin embargo, si consideramos el significado de que el proveedor esté a cargo del desarrollo como experto en desarrollo de sistemas, las expectativas del lado del usuario pueden no ser bajas solo porque se implementa mecánicamente lo que está escrito en las especificaciones. En este artículo, explicaremos hasta qué punto se debe asumir la obligación de implementar un programa que, aunque no esté descrito en las especificaciones, es necesario implementar a la luz del propósito del desarrollo.

Problemas legales asociados con la implementación de elementos no especificados

Se requiere discreción en las tareas del proveedor

Una de las características más destacadas de los contratos y diversos problemas legales relacionados con los proyectos de desarrollo de sistemas es que el proveedor que acepta el trabajo tiene una gran discreción.

Artículo relacionado: ¿Qué es la obligación de gestión de proyectos en el desarrollo de sistemas?[ja]

Sin embargo, la “discreción” a la que nos referimos aquí no necesariamente se aplica a todo el proceso de desarrollo del sistema. Después de identificar cada proceso y avanzar en la identificación de tareas detalladas, puede haber muchas tareas que se acercan al trabajo simple. Sin embargo, en general, cuanto más se convierte en el trabajo de los procesos iniciales antes de la subdivisión de estos problemas, más difícil se vuelve llevar a cabo el trabajo sin tener una gran discreción. También se puede decir que la razón por la cual los contratos de tipo de agencia son a menudo más compatibles con los procesos iniciales se debe a este punto.

Artículo relacionado: Diferencia y distinción entre contratos de obra y contratos de agencia en el desarrollo de sistemas[ja]

La discreción también debe ser ejercida dentro de un estricto proceso de desarrollo

Sin embargo, incluso si el proveedor que desarrolla el sistema tiene una gran discreción, aceptar las solicitudes del cliente de manera informal puede causar un gran daño en los procesos posteriores. Un sistema de TI está compuesto por una colección de pequeñas partes, por lo que incluso un cambio aparentemente menor puede requerir un cambio significativo en el tiempo de trabajo desde el punto de vista del desarrollador. Además, hay artículos que explican cómo manejar la gestión de cambios en las especificaciones de desarrollo de sistemas desde un punto de vista legal. El siguiente artículo discute cómo manejar la gestión de cambios, pero también discute cuánto impacto puede tener un cambio en las especificaciones desde el punto de vista de un ingeniero en el trabajo.

Artículo relacionado: ¿Cómo se debe manejar la gestión de cambios en el desarrollo de sistemas desde un punto de vista legal?[ja]

¿Qué se debe hacer como experto sin estar limitado por las especificaciones?

Para avanzar sin problemas en un proyecto de desarrollo de sistemas, es importante definir los requisitos de desarrollo con anticipación y proceder de manera planificada de acuerdo con ellos. Por otro lado, solo haciendo lo que se te ha dicho de acuerdo con los requisitos definidos previamente, hay momentos en los que no puedes desempeñar plenamente tu papel como experto en desarrollo de sistemas. En medio de este dilema, surge el problema de “¿qué debería implementarse, aunque no esté indicado en las especificaciones?”.

Las obligaciones legales se determinan de acuerdo con el ‘propósito’ de las especificaciones y contratos

El contenido de lo que se debe implementar, incluso si no está escrito en el contrato o en las especificaciones, aún se determina a partir del ‘propósito’ de lo que está escrito en esos contratos y especificaciones. Es decir, se decide a partir de ‘qué significado o intención tenía el acuerdo cuando se hizo’. A continuación, examinaremos algunos ejemplos de casos judiciales.

Ejemplo de juicio en el que se negó la obligación de implementación debido a la falta de descripción

En el caso judicial citado a continuación, el sistema desarrollado por el proveedor avanzó hasta la fase de operación provisional, pero se generó un conflicto cuando se solicitó la rescisión del contrato debido a la falta de funciones necesarias. La función que el usuario afirmó que faltaba era la “función de actualización automática de datos”, y se argumentó que esta era un punto de venta principal del sistema en cuestión, pero el tribunal no reconoció esta obligación de implementación.

Como se ha reconocido anteriormente, no hay ninguna descripción en el contrato de este caso, ni en el documento de diseño básico ni en el documento de diseño detallado, que indique que la función ③ es objeto de desarrollo en el sistema de este caso.

El demandante argumenta que la función ③ era un punto de venta principal del sistema del demandado para el demandante, y enfatiza la necesidad de dicha función, pero si sus argumentos son correctos, debería haberse especificado en el contrato de este caso, y es difícil pensar que se acordó el desarrollo de dicha función sin esa especificación.

Fallo del Tribunal de Distrito de Tokio, 18 de febrero de 2009 (Heisei 21)

Es cierto que si se extrae solo la conclusión de este fallo de manera simple, se podría decir que “si no está descrito en el documento de diseño, no es necesario crear lo que no está”. Sin embargo, para ser más precisos, no se trata de un hecho formal como si estuviera descrito en el documento de diseño, sino de un juicio basado en el “propósito” de la descripción en el documento de diseño y el contrato. En otras palabras, “si se considera la razón por la que no se hizo ninguna descripción en el documento de diseño o el contrato, es razonable pensar que tampoco hubo ningún acuerdo correspondiente a esa descripción”.

Casos judiciales que afirmaron la obligación de implementación incluso sin especificación

Por otro lado, existen casos judiciales que han sostenido que se debe reconocer la obligación de implementar, incluso si no se especifica en el contrato o en las especificaciones. El caso judicial citado a continuación se refiere al desarrollo de un sistema para gestionar el historial de medicación, en el que no se pudo transferir los datos del sistema existente al nuevo sistema, impidiendo su utilización, y el usuario terminó rescindiendo el contrato. Sin embargo, el proveedor argumentó que la transferencia de datos estaba fuera del alcance de su trabajo, lo que llevó a una disputa.

El desarrollo de un nuevo sistema a menudo implica la eliminación del sistema existente y la transferencia de datos. La importancia de estas tareas y los problemas legales asociados se explican en detalle en el siguiente artículo.

Artículo relacionado: Problemas legales asociados con la transición desde el antiguo sistema en el desarrollo del sistema[ja]

Ya se habían guardado los datos de más de 50,000 pacientes en el sistema existente, y el demandante estaba tratando de mejorar la eficiencia de la administración utilizando estos datos, por lo que si no se pudieran transferir los datos de los pacientes del sistema existente al sistema en cuestión, sería evidente que esto causaría problemas en la dispensación de medicamentos en la farmacia, y se puede suponer que el representante del demandante estaba consciente de esto. Además, antes de la conclusión del contrato en cuestión, el representante del demandante preguntó al representante del demandado sobre la posibilidad de transferir los datos, lo cual el representante del demandado también reconoce (omisión), por lo que es difícil pensar que el representante del demandante decidió introducir el sistema en cuestión a pesar de reconocer que probablemente tendría que introducir manualmente los datos de más de 50,000 pacientes. Además, como se mencionó en (1)I, el demandado no pudo transferir los datos de historial de medicamentos del sistema existente al sistema en cuestión, por lo que imprimió los datos en papel y los incorporó en un archivo PDF, entre otras cosas. A pesar de que la transferencia de datos no se presupuso en el contrato en cuestión, es difícil pensar que el demandado realizó este trabajo laborioso como un servicio.

Fallo del Tribunal de Distrito de Tokio, 18 de noviembre de 2010 (Año 22 de Heisei)

Lo que es importante aquí también es el “propósito” del contrato y los elementos especificados en el contrato. Si ambas partes contrataron con el entendimiento de que la transferencia de datos estaba fuera del alcance del trabajo, el tribunal señaló que tanto el usuario como el proveedor habrían contratado con intenciones inusuales. Es decir, el usuario habría asumido una gran cantidad de trabajo manual, y el proveedor habría abordado el proyecto sabiendo que causaría problemas en el trabajo del usuario en el futuro, lo cual es una historia muy irracional.

Lo que podemos aprender de ambas sentencias

En cuanto a la migración de datos, incluso si no se menciona en el contrato o en las especificaciones, se cree que una de las razones por las que se afirmó la obligación de implementación es que se trataba de “datos”, un tema que no se refleja en la apariencia de la pantalla. La “ausencia de funciones esenciales” mencionada anteriormente es algo que se refleja directamente en la pantalla/apariencia del sistema. Por lo tanto, incluso para un principiante en el desarrollo de sistemas, no es tan difícil detectar omisiones en las especificaciones. Por otro lado, el problema de la migración de datos tiene la característica de que es difícil para un principiante en el desarrollo de sistemas reconocer la importancia del proceso, la dificultad del trabajo y el tiempo requerido. Por lo tanto, se cree que también había circunstancias en las que era fácil tratarlo como un asunto que el proveedor debería manejar suavemente con su experiencia.

Desde este punto de vista, la omisión en las especificaciones o en el contrato puede considerarse un problema estrechamente relacionado con la “obligación de cooperación” del usuario. En otras palabras, se trata de si el usuario realmente ha cumplido con su “obligación de cooperación” en la celebración del contrato y la elaboración de las especificaciones. Para una explicación general de las obligaciones legales que el usuario debe cumplir en un proyecto de desarrollo de sistemas, consulte el siguiente artículo.

Artículo relacionado: La obligación de cooperación que el usuario, como cliente del desarrollo del sistema, debe asumir[ja]

Si también verifica el artículo anterior, es probable que comprenda que la solicitud de cooperación del usuario, como la identificación de la pantalla y las funciones esenciales, es un área importante, y que la omisión en la consideración de la migración de datos es un tema completamente diferente.

¿Cómo debemos considerar la remuneración por el desarrollo que no está en las especificaciones?

Otro punto de interés relacionado con el tema de este artículo podría ser si es legalmente permisible cobrar una remuneración adicional por crear algo que no está en las especificaciones. En cuanto a la posibilidad de aumentar la remuneración y cómo calcular el monto estimado en tales casos, se explica en detalle en el siguiente artículo.

Artículo relacionado: ¿Es posible aumentar el monto estimado después del desarrollo del sistema?[ja]

En el artículo anterior, se explica que es importante si hubo o no tareas que excedieron el alcance del trabajo en relación con la remuneración y la relación de contraprestación. En otras palabras, en relación con este artículo, si el proveedor responde al desarrollo de algo que no está incluido en las especificaciones iniciales (el caso negativo en este artículo), se puede permitir una solicitud de remuneración adicional.

Resumen

En el desarrollo de sistemas, el papel que debe desempeñar el proveedor se determina, en cierto aspecto, de acuerdo con el contenido del contrato y las especificaciones. Sin embargo, teniendo en cuenta que se les confía el trabajo en base a una alta confianza como expertos, también se entiende que la realidad no se decide simplemente por la formalidad. No obstante, para comprender esta realidad, es importante entender que la ley juega un papel importante.