¿Qué casos han surgido donde la responsabilidad por actos ilícitos se ha convertido en un problema en el desarrollo de sistemas?

Entre los problemas legales en el desarrollo de sistemas, las disputas sobre la ubicación de varios derechos y obligaciones se llevan a cabo principalmente sobre la base de la existencia de un “contrato” firmado previamente. Sin embargo, las obligaciones legales no siempre se basan en la existencia de un “contrato” firmado previamente. La responsabilidad por actos ilícitos en la ley es un ejemplo típico. En este artículo, presentamos el concepto de “acto ilícito” que no se basa en un contrato, y explicamos la relación entre la ley de actos ilícitos y los proyectos de desarrollo de sistemas.

La conexión entre los proyectos de desarrollo de sistemas y los actos ilícitos

Varias responsabilidades en torno al desarrollo de sistemas

En los temas relacionados con el desarrollo de sistemas, cuando se habla de “ley”, lo primero que se viene a la mente son escenas donde el proyecto ha “incendiado” o hay algún tipo de disputa entre el usuario y el proveedor.

https://monolith.law/corporate/collapse-of-the-system-development-project[ja]

En el artículo anterior, se explica que, a pesar de la diversidad de casos de “incendio”, cuando se observan bajo un marco legal, se pueden organizar mediante un diagrama de flujo relativamente simple.

Además, frente a un caso específico de “incendio”, cuando se busca resolverlo mediante alguna medida legal (por ejemplo, litigio o mediación), surge el problema de quién tenía cuánta obligación (= responsabilidad). Para la discusión sobre la “responsabilidad” que está particularmente relacionada con el proyecto de desarrollo del sistema, se organiza en el siguiente artículo.

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

La mayoría de las responsabilidades se determinan en base al contrato

Dejaremos los detalles de los temas de “incendio” y “responsabilidad” en el desarrollo de sistemas a otros artículos, pero el punto importante aquí es que la mayoría de las opciones legales que se toman en las disputas relacionadas con el desarrollo de sistemas (por ejemplo, la rescisión del contrato o la reclamación de daños y perjuicios) se basan en el contenido del contrato. Por ejemplo, si consideramos ejemplos comunes de problemas relacionados con el desarrollo de sistemas, como la “responsabilidad por incumplimiento de obligaciones” y la “responsabilidad por garantía de defectos”, esto es evidente.

• Responsabilidad por incumplimiento de obligaciones → Por ejemplo, problemas como el retraso en la entrega (= retraso en el cumplimiento) o la inacabada del sistema en sí (= incapacidad para cumplir). En primer lugar, cuándo es la fecha de entrega y cuáles son los requisitos del sistema a desarrollar se determinan de acuerdo con el contrato.
• Responsabilidad por garantía de defectos → Por ejemplo, si se descubre un error después de la entrega o si se revela un gran problema con la velocidad de procesamiento. En este caso también, al final, la discrepancia con el contenido del contrato, es decir, “qué tipo de sistema se suponía que se debía hacer”, se convierte en un problema.

La responsabilidad por actos ilícitos no se basa en el contrato

Sin embargo, a diferencia de la “incumplimiento de obligaciones” y la “garantía de defectos”, que se basan en el contrato, la responsabilidad por actos ilícitos no presupone la existencia de un contrato. Esto no se limita al desarrollo de sistemas, sino que se aplica a todas las disputas en las que está involucrado el Código Civil.

En primer lugar, ¿qué es un acto ilícito? Se define en el artículo 709 del Código Civil, como se indica a continuación.

Artículo 709

La persona que infringe los derechos o intereses de otra persona que están protegidos por la ley, ya sea intencionalmente o por negligencia, tiene la responsabilidad de indemnizar los daños causados por ello.

La frase “de otra persona” es una palabra clave importante. No se limita a las partes en una relación comercial, sino que incluye a “todas las demás personas” además de uno mismo.

Un ejemplo típico de un acto ilícito es un accidente de tráfico. Si golpeas a alguien en un accidente de tráfico debido a la conducción distraída, no solo eres responsable penalmente, sino también civilmente. La responsabilidad civil aquí se refiere a la responsabilidad por actos ilícitos. En otras palabras, aunque no hayas firmado un contrato con la víctima del accidente de tráfico para “no golpear el coche”, tienes una amplia responsabilidad en relación con “otras personas”.

¿En qué situaciones se plantea el problema de actos ilícitos en el desarrollo de sistemas?

Es raro que se cuestione la responsabilidad por actos ilícitos en el desarrollo de sistemas

En cualquier caso, en las diversas disputas en torno al desarrollo de sistemas, es probable que muchos sientan que es difícil imaginar algo como una “persecución de responsabilidad que no se basa en una relación contractual”, similar a un “accidente de coche”. De hecho, en los casos judiciales pasados relacionados con el desarrollo de sistemas, no hay muchos ejemplos en los que se haya reconocido la responsabilidad por actos ilícitos.

Esto no es nada extraño. Más bien, dado que los proyectos de desarrollo de sistemas avanzan con la cooperación mutua entre el usuario y el proveedor, se podría decir que es natural. La mayoría de las disputas relacionadas con el desarrollo de sistemas se resuelven en cuestiones de clarificación de roles basadas en relaciones contractuales, como la “obligación de gestión del proyecto” y la “obligación de cooperación del usuario”.

Por ejemplo, el siguiente artículo muestra cómo organizar un caso cuando el “usuario quiere interrumpir el proyecto”.

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

Aquí, incluso si el usuario es quien ha solicitado la interrupción, también se explica la importancia de que el proveedor reflexione sobre sus propias fallas. Además, en el siguiente artículo, también se realiza una organización legal de problemas como “retraso en la entrega”. De nuevo, se puede ver que el problema es simplemente la clarificación de roles entre el usuario y el proveedor.

https://monolith.law/corporate/performance-delay-in-system-development[ja]

Al observar de esta manera, parece que las características de un proyecto de desarrollo de sistemas se simbolizan en la estrecha relación entre el “proveedor que gestiona el proyecto” y el “usuario que coopera con él”. Y esta estrecha relación contractual es, irónicamente, a veces la causa de las disputas. Por lo tanto, en este sentido, puede ser difícil decir que los casos en los que se cuestiona la responsabilidad por actos ilícitos en las disputas sobre el desarrollo de sistemas son “puntos de discusión típicos” en este campo.

Caso en el que se planteó la responsabilidad por actos ilícitos antes de la firma del contrato

Sin embargo, existen casos en los que se ha reconocido la responsabilidad por actos ilícitos por parte del proveedor. El caso citado en la sentencia a continuación es uno en el que, debido a la falta de suficiente información proporcionada por el proveedor al usuario, las diferencias en la percepción de ambas partes se hicieron cada vez más evidentes a medida que avanzaba el proyecto, y finalmente el proyecto se estancó. En este caso, la razón por la que el proyecto se estancó fue la falta de explicación por parte del proveedor en la etapa inicial de planificación y propuesta, y dado que estas acciones se llevan a cabo “antes” de la firma del contrato, incluso en la práctica, la cuestión era si se podía perseguir la responsabilidad basada en actos ilícitos, no en el contrato. (Las adiciones subrayadas y las modificaciones en negrita son adiciones del autor para facilitar la explicación.)

En la etapa de planificación y propuesta, se definen los aspectos generales de los asuntos relacionados con la concepción del proyecto y su viabilidad, como la definición de los objetivos del proyecto, los costos de desarrollo, el alcance del desarrollo y las estimaciones del tiempo de desarrollo, y también se determinan los riesgos asociados con el proyecto. Por lo tanto, la planificación y análisis de riesgos del proyecto que se requiere del proveedor en la etapa de planificación y propuesta es esencial para llevar a cabo el desarrollo del sistema. Por lo tanto, como proveedor, incluso en la etapa de planificación y propuesta, se debe considerar y verificar la funcionalidad del sistema que se propone, el grado de satisfacción de las necesidades del usuario, el método de desarrollo del sistema, la estructura de desarrollo después de recibir el pedido, y se debe explicar al usuario los riesgos previstos. Esta obligación del proveedor de verificar y explicar se considera una obligación bajo la ley de actos ilícitos basada en el principio de buena fe en el proceso de negociación para la firma del contrato, y se puede decir que el apelante, como proveedor, tiene tal obligación (la obligación relacionada con la gestión del proyecto en esta etapa).

Sentencia del Tribunal Superior de Tokio, 26 de septiembre de 2013 (Heisei 25)

En otras palabras, dado que se trata de un asunto “antes” de la firma del contrato, era difícil construir una teoría basada en la persecución del incumplimiento de las obligaciones impuestas por el contrato, pero se esperaba una resolución justa al reconocer la violación de las obligaciones basadas en actos ilícitos.

La relación entre la conducta ilícita y las obligaciones de gestión de proyectos

En el desarrollo de sistemas, donde el proveedor y el usuario colaboran desde sus respectivas posiciones, la obligación que asume el proveedor como experto en desarrollo de sistemas se llama “obligación de gestión de proyectos”. Una explicación general de lo que es la obligación de gestión de proyectos se puede encontrar en el siguiente artículo.

https://monolith.law/corporate/project-management-duties[ja]

En este fallo, no solo se plantea la cuestión de “¿Existen situaciones en las que la responsabilidad por actos ilícitos es un problema en el desarrollo de sistemas?”, sino que también ha atraído cierta atención desde el punto de vista de “¿Se impone la obligación de gestión de proyectos incluso en las relaciones antes de la conclusión del contrato?”.

¿Qué es el principio de buena fe?

Además, en el texto de la sentencia aparece el término “obligación bajo el principio de buena fe”, que se basa en el contenido del siguiente artículo.

Artículo 1, párrafo 2 del Código Civil Japonés

El ejercicio de los derechos y el cumplimiento de las obligaciones deben realizarse de buena fe y con sinceridad.

Esto se conoce como una cláusula general en el Código Civil Japonés y es un principio fundamental que es válido para todas las resoluciones de conflictos que utilizan el Código Civil. La teoría legal relacionada con los derechos y obligaciones debe desarrollarse sobre la base de la “buena fe” y la “sinceridad”.

Si consideramos el caso de esta sentencia, si el proveedor argumenta que “en la etapa de planificación y propuesta, dado que no se ha firmado ningún contrato, no hay obligación de intentar explicar de antemano”, esto carecería de sinceridad fundamental y no sería apoyado como una teoría legal. Eso es lo que significa.

Resumen

Se han presentado varios términos importantes como “actos ilícitos”, “obligaciones de gestión de proyectos” y “principio de buena fe”, pero la conexión general no es tan complicada. En el desarrollo de un sistema, el proveedor tiene una responsabilidad y obligación integral, que se representa como “obligaciones de gestión de proyectos”. Estos se derivan básicamente del contrato.

Sin embargo, las obligaciones legales no se determinan formalmente solo en base al contenido del contrato acordado previamente, sino que también se consideran individualmente, incorporando principios como el de “buena fe”. Además, la persecución de la responsabilidad civil que no presupone una relación contractual, es algo que está previsto desde el principio en la ley a través de la construcción teórica de “actos ilícitos”.

Junto con el hecho de que las obligaciones legales no necesariamente presuponen solo una relación contractual, deberíamos entender el flujo general.