Un abogado ex ingeniero de IT explica la similitud entre la revisión de contratos y la depuración de errores

El núcleo de las tareas del llamado “abogado asesor de la empresa” es revisar y modificar los contratos que la empresa celebra diariamente con clientes y socios comerciales. Y estas revisiones y modificaciones, inevitablemente, no pueden ser realizadas adecuadamente sin una persona que esté familiarizada tanto con la ley como con el campo de negocio en cuestión. Explicaré por qué es así.

Sin embargo, la siguiente explicación puede ser difícil de entender para aquellos que no son ingenieros o no tienen experiencia en programación. Monolith Law Office es una firma de abogados dirigida por un ex ingeniero de IT con experiencia en la gestión de empresas. En última instancia, se posiciona como un “artículo que explica la revisión y modificación de contratos, dirigido a gerentes con experiencia en ingeniería y programación, desde la perspectiva de una firma de abogados dirigida por un ex ingeniero de IT y gerente de empresa”.

Y en este contexto, la revisión y modificación de contratos es un trabajo similar al llamado “debugging”.

1. ¿Qué es un “bug” en primer lugar?
2. ¿Qué tipo de trabajo es el “debugging”?
3. ¿Cómo define un contrato un algoritmo?
4. ¿Qué tipo de trabajo es la modificación de un contrato?

Comenzaré con lo que para los ingenieros es una conversación “obvia”, pero a continuación, lo explicaré en este orden.

¿Qué son “Bug” y “Debug”?

Un “Bug” no es un “fallo de PC”

Cuando se menciona la palabra “Bug”, algunas personas pueden imaginar una situación en la que su PC emite humo y la pantalla muestra algo extraño mientras trabajan en ella. Sin embargo, en principio, una PC solo realiza las operaciones que se le indican. Esto también es cierto cuando ocurre un “Bug”. En otras palabras, un “Bug” es:

• A pesar de que la PC está funcionando como se le indicó
• El comportamiento es “inesperado” para el usuario

Este es el fenómeno.

¿Por qué ocurre el “comportamiento inesperado”?

Por ejemplo, consideremos el “Bug” de “atravesar paredes” en un juego de acción tipo Mario.

El salto de Mario es una función cuadrática. Aceleración, velocidad, coordenadas. Sin embargo, en un videojuego, a diferencia de una función cuadrática típica que permite dividir X en infinitos segmentos pequeños (por ejemplo, “¿Cuál es Y cuando X=1.76582?”), no se puede dividir el tiempo en infinitos segmentos pequeños. Esto se debe a que la pantalla solo cambia (por ejemplo) 30 veces por segundo. Por lo tanto, en cierto sentido, Mario está “teletransportándose” 30 veces por segundo.

En este contexto, si consideramos una situación en la que “Mario salta y rebota porque hay una pared en el aire”, sería una situación en la que:

1. Mario estaba en el aire un momento antes
2. En el siguiente momento, las coordenadas de Mario están dentro de la pared

Esto es lo que sucede.

En tal caso, se puede determinar que “Mario chocó con una pared en el aire mientras saltaba”. Por lo tanto, en lenguaje natural, si escribimos un programa que diga:

Si las coordenadas de Mario están dentro de la pared, realizar el proceso de rebote (※1)

Podemos lograr el proceso de “Mario salta y rebota porque hay una pared en el aire”.

※1 parece correcto tal como está escrito. Y de hecho, este proceso es correcto “bajo ciertas condiciones”.

Sin embargo, si lo pensamos bien, también podría ocurrir la siguiente situación (※2).

En este caso, no existe un momento en el que “las coordenadas de Mario están dentro de la pared”, por lo que no se realiza el proceso de rebote y Mario termina atravesando la pared.

Este es un ejemplo de “Bug”. Incluso si se produce un “Bug” de “atravesar paredes” por esta razón, no significa que la PC esté rota. La PC simplemente está funcionando como se le indicó, y es el humano quien evalúa ese comportamiento como “inesperado” o “un Bug”. Y ese “Bug” ocurre porque el algoritmo no es adecuado.

Considerar si “ocurrirá un comportamiento inesperado”

Sin embargo, si en el proceso de jugar el juego realmente ocurre el “atravesar paredes” mencionado anteriormente, no está claro solo pensando en ello de manera abstracta. Si es posible que ocurra el “atravesar paredes” depende de:

• ¿Cuánto es la fuerza de salto (velocidad inicial) de Mario? ¿Hay algún objeto que aumente la fuerza de salto?
• ¿Cuál es el grosor mínimo de la pared?

Depende de estas condiciones. Dependiendo de si es posible el caso ※2 bajo estas condiciones. Si el caso ※2 no es posible, entonces no hay problema con el programa ※1.

¿Qué tipo de trabajo es “Debug”?

Por lo tanto, para realizar “Debug”, es decir, encontrar y corregir Bugs, se necesita el siguiente proceso:

1. Leer y entender qué tipo de algoritmo es el programa (※1 está en lenguaje natural, pero en realidad los programas están escritos en un lenguaje propio, por lo que la lectura en sí misma es difícil)
2. Considerar bajo qué condiciones funciona ese programa (investigar sobre la fuerza de salto y el grosor de la pared)
3. Considerar si se producirá un comportamiento inesperado en ese momento

Esto es lo que se necesita.

¿Qué implica la revisión de un contrato?

La revisión de un contrato es similar a este proceso. En esencia, un contrato es un instrumento que regula las relaciones entre las partes, identificadas como A y B, anticipando eventos futuros. Define qué derechos y obligaciones surgirán para A y B en tales circunstancias, y cómo se comportarán como resultado. En este sentido, se puede decir que un contrato es un “programa que regula el mundo real”. Por ejemplo,

En caso de que ocurra la situación ●●, A deberá indemnizar a B con 1 millón de yenes.

Un contrato que establece tales reglas define las condiciones y los efectos para los eventos que pueden ocurrir en el futuro.

Por lo tanto, el proceso de verificar si hay algún problema con este “programa que regula el mundo real” y corregirlo si lo hay, es similar a la “depuración” (debugging).

El contrato no describe el algoritmo en su totalidad

Sin embargo, hay un punto extremadamente importante en los “contratos” que puede ser difícil de entender para aquellos que no se especializan en la ley. El punto es que un contrato solo estipula una “parte” del algoritmo que regula las relaciones entre las partes. En otras palabras, solo leyendo el contrato, no puedes conocer la totalidad del algoritmo bajo el cual tú y la otra parte están regulados.

Por ejemplo, cuando compras un CD usado en una tienda, la tienda y el cliente no firman algo como un “contrato de venta”, pero si el CD que compraste tiene un rasguño que no se puede reproducir en el reproductor, querrás quejarte en la tienda y esperarás que la tienda responda. Esto no es solo una cuestión de “porque es un servicio”, teóricamente,

1. Aunque no haya un contrato escrito, se ha celebrado un contrato de venta
2. El Código Civil japonés (Ley Civil) estipula que el vendedor tiene una responsabilidad de garantía por defectos en el contrato de venta de un “bien específico” como un CD usado
3. Por lo tanto, el algoritmo definido por el Código Civil japonés (Ley Civil) está en funcionamiento entre la tienda y el cliente, y la tienda tiene una responsabilidad de garantía por defectos

Este es el razonamiento. Y un “contrato” es algo que sobrescribe el algoritmo definido por leyes como el Código Civil japonés (Ley Civil). Por ejemplo, si hay un contrato entre la tienda y el cliente que dice “No aceptamos reclamaciones posteriores por cualquier defecto en los CD”, entonces

1. Se ha celebrado un contrato de venta
2. El Código Civil japonés (Ley Civil) estipula que el vendedor tiene una responsabilidad de garantía por defectos en este contrato
3. Sin embargo, según lo estipulado en el contrato, el principio 2 se sobrescribe y la tienda no tiene responsabilidad de garantía por defectos

Esto es lo que sucede.

El contrato “sobrescribe” los principios del Código Civil japonés y otros

Esto es igualmente aplicable en el caso de contratos celebrados entre empresas, como el desarrollo de sistemas. Por ejemplo, si se ha firmado un contrato de desarrollo de sistemas por contrato entre las partes A y B,

1. El contrato de trabajo se establece claramente al firmar el contrato correspondiente
2. En el caso de un contrato de trabajo, la responsabilidad de garantía de defectos surge en el contratista de acuerdo con las disposiciones del Código Civil japonés
3. Si el contrato tiene una disposición sobre la responsabilidad de garantía de defectos, esa disposición sobrescribe el principio del Código Civil japonés en el punto 2. Por ejemplo, si se establece una cláusula de responsabilidad de garantía de defectos por un período más largo que el principio del Código Civil japonés, la disposición de ese período será válida

Esta es la estructura. En otras palabras, incluso si no hay una disposición específica sobre la responsabilidad de garantía de defectos en el contrato, la responsabilidad de garantía de defectos surgirá.

Esto no se limita a contratos de trabajo y desarrollo de sistemas, sino que es una teoría general sobre todos los contratos que las empresas realizan, como la transferencia de acciones, la recaudación de fondos a través de deudas (préstamos de consumo de dinero), empleo y emisión de acciones.

Por lo tanto, solo leyendo el contrato, no puedes entender el “algoritmo” completo que regula la relación entre la otra parte y tu empresa. Para entender el panorama completo, debes entender el “algoritmo predeterminado” establecido por leyes como el Código Civil japonés. Esto se debe a que el contrato simplemente “sobrescribe” este “algoritmo predeterminado”.

No se puede “depurar” sin prever los eventos que podrían ocurrir en el futuro

Además, entender un algoritmo no es suficiente para verificar si “no ocurrirá un comportamiento inesperado con ese algoritmo”. Al igual que con los “bugs” en los videojuegos, los algoritmos son abstractos, y si no se anticipan los eventos que podrían ocurrir en el futuro, no se puede verificar si “no se convertirán en un comportamiento inesperado cuando ocurran dichos eventos”.

Esto es especialmente problemático en el caso de nuevos productos como aplicaciones o servicios, o nuevos esquemas de negocio. Cuando se lanza un negocio con estos productos o esquemas, es difícil prever qué podría suceder en el futuro sin conocimientos en el campo relevante. Además, especialmente en el caso de los contratos entre empresas, tanto la empresa contraparte como la propia empresa actúan bajo cierta racionalidad económica, por lo que se necesita un enfoque de teoría de juegos en la gestión empresarial para prever los eventos futuros y las acciones de la contraparte que los causarán.

La decisión de si algo es “inesperado” también se basa en el juicio de gestión

Además, al igual que es un humano y no una computadora quien decide si un evento es un “bug”, la decisión de si un resultado producido por un contrato es “inesperado” no es solo un problema de derecho puro, sino también un problema de juicio de gestión.

Por ejemplo, puede haber casos en los que un algoritmo que sigue “los principios del Código Civil japonés” sea inaceptable para un negocio en particular de una empresa. Aunque este es un cambio de tema de los ejemplos anteriores, el Código Civil japonés, por ejemplo, establece un algoritmo predeterminado que dice que “la subcontratación por parte del contratista es una violación del contrato”. Sin embargo, puede haber casos en los que “para una empresa en particular, se espera que un negocio en particular utilice naturalmente a las empresas subcontratistas”. En tales casos, un contrato que hace imposible la subcontratación, es decir,

• No se menciona nada sobre la posibilidad de subcontratación (en este caso, se aplica el principio del Código Civil japonés como se mencionó anteriormente)
• Está claramente indicado que la subcontratación es imposible

no debería ser aceptable, incluso si sigue “los principios del Código Civil japonés”.

Además, siempre hay un riesgo en la gestión de que “se te hará responsable si ocurre un cierto evento”. No existe básicamente un contrato que no represente “riesgo” para su propia empresa. La decisión de aceptar ese riesgo es finalmente una decisión de gestión. Aunque los que toman decisiones de gestión son los gerentes, no los consultores como los abogados asesores, los consultores deben presentar la información necesaria y suficiente para que los gerentes tomen decisiones de gestión, como

• Riesgos que no necesitan ser señalados cada vez
• Riesgos que requieren una decisión importante para la empresa y que pueden requerir reuniones, dependiendo del caso

Estos deben ser señalados con diferentes grados de importancia. Para establecer estos “grados de importancia”, al igual que en el caso de los consultores en otros campos, los abogados que revisan los contratos también necesitan tener un cierto sentido de la “gestión”.

Resumen

Como se ha mencionado, la revisión y modificación de contratos puede describirse ampliamente como las siguientes tareas:

1. Entender cómo los principios del Código Civil japonés y otros se sobrescriben en el contrato, y qué algoritmo resulta de ello.
2. Considerar qué eventos pueden ocurrir en el futuro bajo ese algoritmo.
3. Examinar si se producirán comportamientos inesperados en ese momento.

Y cada una de estas tareas es:

1. Una tarea difícil sin un entendimiento de la ley.
2. Una tarea difícil sin un entendimiento del contenido del negocio que regula el contrato, como una aplicación o un servicio web, y el esquema de negocio.
3. Una tarea difícil sin un cierto nivel de entendimiento del contenido de la empresa o del negocio, y la sensibilidad de gestión.

Esto es lo que significa.

La revisión y modificación de contratos es, por estas razones, muy “especializada”.

Información sobre la creación y revisión de contratos por nuestra firma

En el despacho de abogados Monolith, como una firma de abogados especializada en IT, Internet y negocios, ofrecemos servicios como la creación y revisión de varios contratos a nuestras empresas clientes y asesoradas.

Si está interesado, por favor vea los detalles a continuación.