Аналогії між перевіркою договорів та налагодженням: пояснення від адвоката-екс-IT-інженера

Основним завданням так званого “юридичного радника компанії” є перевірка та виправлення договорів, які компанія щодня укладає з клієнтами та партнерами. І ці перевірки та виправлення не можуть бути належно виконані без “особи, яка добре розуміється на законодавстві та своїй сфері діяльності”. Дозвольте пояснити, чому це так.

Однак, наступне пояснення, можливо, буде важко зрозуміти для тих, хто не має досвіду в інженерії або програмуванні. Наша юридична фірма Monolith Law Office керується колишнім IT-інженером з досвідом управління компанією. Це стаття, в якій “юридична фірма, керована колишнім IT-інженером та керівником компанії, пояснює перевірку та виправлення договорів для керівників з досвідом в інженерії та програмуванні”.

І на основі цього позиціонування, перевірка та виправлення договорів схожі на так звану “відладку”.

1. Що таке “баг”?
2. Яким є процес “відладки”?
3. Як договір визначає алгоритм?
4. Яким є процес виправлення договору?

Починаючи з того, що для інженерів є “очевидним”, я пояснюю в наступному порядку.

Що таке “баг” та “дебаг”

“Баг” – це не “поломка ПК”

Коли ми говоримо про “баг”, можливо, у вас виникає образ ПК, з якого йде дим, а екран відображає щось незрозуміле… Однак, ПК, в основному, працює “за інструкціями”. Це стосується і випадків, коли виникає “баг”. Тобто “баг” – це:

• ПК працює відповідно до інструкцій, але
• для користувача його поведінка є “несподіваною”

Це явище.

Чому виникає “несподівана поведінка”

Наприклад, давайте подумаємо про “баг” з проходженням через стіни в іграх типу “Маріо”.

Стрибок Маріо – це квадратична функція. Прискорення, швидкість, координати. Однак, якщо це звичайна квадратична функція, то, наприклад, “Яке значення Y при X=1.76582?” можна розбити на безліч маленьких частин, але в відеоіграх час не можна розбити на безліч маленьких частин. Екран оновлюється лише 30 разів на секунду (наприклад). Тому, по суті, Маріо “телепортується” 30 разів на секунду.

В цьому контексті, коли Маріо стрибає і відскакує від стіни в повітрі, це відбувається, коли

1. Маріо був в повітрі мить тому, але
2. в наступний момент координати Маріо знаходяться всередині стіни

Це випадок.

В такому випадку, можна визначити, що “Маріо вдарився об стіну під час стрибка”. Тому, якщо ми використовуємо природну мову,

Якщо координати Маріо знаходяться всередині стіни, виконується обробка відскоку (※1)

Якщо написати програму таким чином, можна реалізувати обробку “Маріо стрибає і відскакує від стіни в повітрі”.

※1, якщо написати так, виглядає правильно. І насправді, “при певних умовах” ця обробка є правильною.

Але якщо добре подумати, можливі такі випадки (※2).

У цьому випадку, момент “координати Маріо всередині стіни” не існує, тому обробка відскоку не відбувається, і Маріо проходить через стіну.

Це приклад “багу”. Навіть якщо через це виникає “баг проходження через стіни”, це не означає, що ПК зламався. ПК просто виконує дії, які йому наказано, і людина оцінює ці дії як “несподівані” або “баг”. І цей “баг” виникає тому, що алгоритм не є відповідним.

Розгляд “чи виникає несподівана поведінка”

Однак, чи виникне “проходження через стіни” під час гри, як описано вище, не відомо, якщо думати абстрактно. Чи може виникнути “проходження через стіни” залежить від:

• Сили стрибка Маріо (початкова швидкість), чи є предмети, які підвищують силу стрибка
• Яка товщина стіни в найтоншому місці

Це залежить від умов. Залежно від того, чи можливий випадок ※2, програма ※1 не є проблемою.

Яким є процес “дебагу”

Отже, для “дебагу”, тобто знаходження та виправлення багів, потрібно:

1. Прочитати алгоритм програми (※1 використовує природну мову, але насправді програми написані на власній мові, тому читання само по собі є складним)
2. Розглянути, при яких умовах ця програма працює (дослідити силу стрибка та товщину стіни)
3. Розглянути, чи не виникає несподівана поведінка при цьому

Цей процес є необхідним.

Що таке перевірка договорів?

Перевірка договорів схожа на цей процес. Власне кажучи, договір – це документ, який передбачає можливі події в майбутньому для сторін, визначає, які права та обов’язки виникають у них у таких випадках, і регулює, як вони повинні діяти. В цьому сенсі, це можна назвати “програмою, що регулює реальний світ”. Наприклад,

У випадку виникнення ситуації ●●, сторона А відшкодовує стороні Б 1 мільйон єн.

Такий договір, який регулює такі ситуації, визначає умови та наслідки для майбутніх подій.

І перевірка цієї “програми, що регулює реальний світ”, на наявність проблем та їх виправлення, якщо такі є, неодмінно нагадує “відлагодження”.

У договорі не вказано повну картину алгоритму

Однак, у такому понятті, як “договір”, є один важливий момент, який може бути важким для розуміння для тих, хто не спеціалізується на праві. Договір визначає лише “частину” алгоритму, який регулює відносини між сторонами. Іншими словами, просто читаючи договір, ви не зможете дізнатися, під яким алгоритмом ви та ваш партнер регулюєте свої відносини.

Наприклад, при купівлі б/в CD в магазині, магазин і покупець не укладають щось на зразок “договору купівлі-продажу”, але якщо на поверхні купленого CD є подряпини, які не дозволяють його відтворювати на програвачі, ви, ймовірно, захочете пожалітися магазину, і очікуєте, що вони відреагують. Це не просто рівень “тому що це послуга”, а теоретично:

1. Навіть без договору, договір купівлі-продажу укладено
2. Цивільний кодекс (Японський Цивільний кодекс) встановлює, що продавець несе відповідальність за дефекти в продукції, такій як б/в CD (відомий як “специфічний товар”)
3. Отже, алгоритм, визначений Цивільним кодексом, працює між магазином і покупцем, і магазин несе відповідальність за дефекти

Це логіка. І “договір” – це те, що переписує алгоритм, визначений законами, такими як Цивільний кодекс. Наприклад, якщо між магазином і покупцем було укладено договір, який стверджує, що “магазин не приймає жодних скарг на будь-які дефекти CD після продажу”, то:

1. Договір купівлі-продажу укладено
2. Цивільний кодекс встановлює, що продавець несе відповідальність за дефекти в продукції
3. Однак, відповідно до умов договору, принцип 2 переписується, і магазин не несе відповідальності за дефекти

Це те, як це працює.

Договір “перезаписує” принципи Цивільного кодексу

Це стосується також договорів, що укладаються між компаніями, наприклад, у сфері розробки систем. Наприклад, якщо укладено договір про розробку системи між сторонами А і Б, то:

1. Чітко встановлюється, що договір про розробку системи укладено внаслідок укладання цього договору
2. У випадку договору про розробку системи, відповідно до положень Цивільного кодексу, виникає обов’язок сторони-виконавця гарантувати відсутність дефектів
3. Якщо в договорі є положення про відповідальність за дефекти, то це положення “перезаписує” принцип Цивільного кодексу, згаданий у пункті 2. Наприклад, якщо встановлено умову про відповідальність за дефекти на термін, що перевищує принцип Цивільного кодексу, то цей термін вважається дійсним

Отже, структура виглядає так. Тобто, навіть якщо в договорі немає конкретного положення про відповідальність за дефекти, відповідальність за дефекти все одно виникає.

Це не обмежується лише розробкою систем або виконанням робіт, але стосується загальних питань всіх договорів, які укладають компанії, таких як передача акцій, залучення коштів через борг (позики), наймання працівників, випуск акцій та інше.

Тому, просто читаючи договір, ви не зможете повністю зрозуміти “алгоритм”, який регулює відносини між вами та вашою компанією. Щоб зрозуміти цей “алгоритм”, вам потрібно розуміти “дефолтний алгоритм”, який встановлюється законами, такими як Цивільний кодекс. Договір лише “перезаписує” цей “дефолтний алгоритм”.

Не можна “відлагоджувати”, якщо не враховуєте можливі події в майбутньому

Також, розуміння алгоритму само по собі не дозволяє перевірити, чи “не виникне непередбачувана поведінка з цим алгоритмом”. Це подібно до “багів” у грі: алгоритм – це в кінцевому рахунку абстрактна річ, і якщо ви не врахуєте, які події можуть виникнути в майбутньому, ви не зможете перевірити, “чи не стане це непередбачуваною поведінкою, якщо такі події виникнуть”.

Це особливо важливо для нових продуктів, таких як додатки або сервіси, нових бізнес-схем. Це стає серйозною проблемою, коли ви розгортаєте бізнес з такими продуктами або схемами. Що може статися в майбутньому? Це важко передбачити, якщо у вас немає знань у відповідній галузі. Крім того, особливо у випадку контрактів між компаніями, обидві сторони, включаючи вашу компанію, діють на основі певної економічної раціональності, тому для прогнозування майбутніх подій та дій іншої сторони, які їх викликають, потрібно грати в теорію гри в управлінні компанією.

Чи є подія “несподіваною” залежить від управлінського рішення

Крім того, так само як людина, а не комп’ютер, визначає, чи є подія “багом”, визначення, чи є певний результат, який приносить договір, “несподіваним”, також не є простою юридичною проблемою, але є питанням управлінського рішення.

Наприклад, може бути реальний випадок, коли алгоритм “згідно з принципами Японського цивільного кодексу” є неприйнятним для певного бізнесу певної компанії. Це відрізняється від попередніх прикладів, але, наприклад, Японський цивільний кодекс встановлює дефолтний алгоритм, що “повторне доручення виконавцем є порушенням договору”. Однак, може бути випадок, коли “для певної компанії, певний бізнес, очевидно, передбачає використання підрядних компаній”. У таких випадках, договір, який робить неможливим повторне доручення, тобто

• Нічого не вказано про можливість повторного доручення (у цьому випадку, як зазначено вище, застосовується принцип Японського цивільного кодексу)
• Чітко вказано, що повторне доручення неможливе

не може бути прийнятий, навіть якщо він “згідно з принципами Японського цивільного кодексу”.

Крім того, в управлінні завжди є ризик, що “ви будете відповідальні, якщо виникне певна обставина”. Договір, який “не має ризику” для вашої компанії, в основному не існує. Чи приймати цей ризик, в кінцевому рахунку, є управлінським рішенням. Управлінські рішення приймаються керівниками, а не консультантами, такими як юридичні радники, але консультанти повинні надавати достатню інформацію, необхідну для прийняття управлінських рішень,

• Ризик, який не потребує постійного вказівки
• Ризик, який приймається як важливе рішення для даної компанії, що може вимагати зустрічей тощо

і вони повинні вказувати на ці речі з різним ступенем інтенсивності. Для цього налаштування “інтенсивності”, так само як і в інших областях консультації, адвокат, який перевіряє договір, також повинен мати певне розуміння “управління”.

Підсумки

Таким чином, перевірка та виправлення договорів в основному включає в себе наступні роботи:

1. Розуміння того, як принципи Цивільного кодексу та інших законів переписуються договором, і якими в результаті стають алгоритми
2. Розгляд можливих майбутніх подій за цими алгоритмами
3. Перевірка на випадок непередбачуваної поведінки

І кожен з цих пунктів є:

1. Важкою роботою для тих, хто не розуміє закону
2. Важкою роботою для тих, хто не розуміє змісту бізнесу, яким керує договір, наприклад, додатків або веб-сервісів, бізнес-схем тощо
3. Важкою роботою для тих, хто не має достатнього розуміння змісту підприємства або бізнесу, а також бізнес-інтуїції

Ось чому це так.

Перевірка та виправлення договорів є дуже “спеціалізованими” через ці причини.

Інформація про створення та перегляд договорів нашим бюро

Юридичне бюро “Monolis” як юридична фірма, що спеціалізується на IT, Інтернеті та бізнесі, надає послуги зі створення та перегляду різноманітних договорів для наших корпоративних клієнтів та клієнтів-компаній.

Якщо вас цікавить, будь ласка, ознайомтеся з деталями нижче.

https://monolith.law/contractcreation[ja]