Відношення між затримкою виконання термінів розробки системи та юридичними наслідками затримки виконання

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

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

Що таке термін виконання в системному розробці

Загальне розуміння терміну виконання

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

Ми також пояснюємо концепцію “завершення роботи” з точки зору закону та терміни виконання в інших статтях.

Термін виконання з юридичної точки зору

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

1. Коли є визначений термін виконання зобов’язання, боржник несе відповідальність за затримку з моменту настання цього терміну.
2. Коли є невизначений термін виконання зобов’язання, боржник несе відповідальність за затримку з моменту, коли він дізнався про настання цього терміну.
3. Коли термін виконання зобов’язання не встановлено, боржник несе відповідальність за затримку з моменту отримання вимоги про виконання.

Стаття 412 Японського цивільного кодексу

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

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

Стаття 415 Японського цивільного кодексу

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

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

Стаття 541 Японського цивільного кодексу

Загальний опис цієї опції “скасування” в таких випадках подробиці викладено в наступній статті.

Не всі випадки затримки поставки є порушенням зобов’язань за законом

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

https://monolith.law/corporate/user-obligatory-cooporation[ja]

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

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

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

Суть розмови полягає в тому, що “не встигаємо до дедлайну = порушення зобов’язань” – це не так просто. Затримка терміну поставки може бути винна постачальника, але також може бути винна користувача, причини можуть бути різними. Є велика різниця між формальним фактом “затримки дедлайну” і суттєвим порушенням обов’язків, яке становить “затримку виконання”.

Судова практика щодо затримки виконання

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

Приклад компенсації затримки виконання через порушення користувачем обов’язку співпраці та недбалість

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

Враховуючи вищезазначене, можна стверджувати, що позивач-користувач не виконав належну співпрацю, не приймаючи своєчасні та відповідні рішення, такі як невирішення проблем, які вимагали вирішення від відповідача до встановленого терміну.
Однак, щодо твердження відповідача про порушення обов’язку співпраці позивача-користувача у вимогах щодо додавання або зміни функцій, хоча визнається факт, що позивач-користувач вимагав додати або змінити розробку, передбачену в основному проекті, це не означає, що це становить порушення обов’язку співпраці позивача-користувача, і твердження відповідача не має підстав.
Також немає підстав для твердження відповідача про порушення обов’язку співпраці позивача-користувача у вимогах, що перевищують межі, оскільки не визнається, що позивач-користувач вимагав більше, ніж це передбачено в оплаті за доручення розробки комп’ютерної системи та інших договорів.
Навпаки, можна стверджувати, що у проектному менеджменті відповідача були невідповідні моменти, такі як визначення кількості операцій після січня 1999 року (кількість “операцій” станом на липень або серпень того ж року) та внесення пропозицій про неправильне збільшення оплати за додаткове доручення або зменшення операцій після 31 травня того ж року.

Рішення Токійського окружного суду від 10 березня 2004 року (Heisei 16)

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

У цьому рішенні словосполучення “обов’язок співпраці” з’являється більше 40 разів у всьому тексті, включаючи зміст. З юридичної точки зору, можна сказати, що суть полягала в розподілі обов’язків проектного менеджменту постачальника та обов’язку співпраці користувача.

Судовий прецедент, в якому повністю визнано затримку виконання

Нижче наведено витяг з вироку у справі, в якій повністю доведено відповідальність постачальника за затримку терміну поставки, і визнано відповідальність за невиконання зобов’язань через затримку виконання. У цьому випадку, користувач розірвав договір на межі завершення системи, через що постачальник подав до суду, але користувач стверджував, що причиною стала затримка терміну поставки.

Не можна заперечувати, що відповідач вніс різні зміни до системи дизайну, через що завершення було затримано до певної міри. Особливо відповідач, який дав остаточні інструкції змін 23 червня 2005 року (平成17年), не може бути звинувачений у тому, що функція “автоматичний розрахунок деталей бордюру” не була завершена на основі цих інструкцій.
Однак, інші зміни, внесені відповідачем, були зроблені до початку квітня того ж року, і не можна визнати, що обставини, які слід розглядати як зміну плану завершення системи дизайну, були визнані (за винятком частини, зміненої відповідачем 23 червня).
Не можна визнати, що позивач до кінця червня 2005 року завершив систему дизайну до рівня, коли можлива реальна експлуатація, за винятком частини, зміненої 23 червня, і важливі частини системи, такі як неможливість відображення зображень або неробоча функція пошуку, були незавершені.
(Пропущено) Можна припустити, що позивач не належним чином керував процедурою роботи, пов’язаною з розробкою системи.
Отже, не можна визнати, що основною причиною того, що позивач не зміг дотриматися терміну поставки, були інструкції відповідача, і не можна визнати, що позивач не має причин для звинувачення.

Вирок Токійського окружного суду від 16 лютого 2007 року (平成19年)

У цьому вироку було вказано, що не можна звинувачувати постачальника у тому, що ця функція не була завершена, зокрема, через те, що інструкції про зміну специфікацій були винесені за приблизно тиждень до терміну поставки. Однак,

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

Враховуючи це, було визнано невиконання зобов’язань на основі затримки виконання.

Що можна зрозуміти з обох рішень

Враховуючи обидва рішення, можна сказати, що проблема “терміну виконання” у розробці системи, в кінцевому підсумку, є питанням про те, як визначити межу між обов’язком користувача співпрацювати та обов’язком вендора управляти проектом. Тобто, юридична затримка виконання є одним з видів відповідальності за невиконання зобов’язань, тому питання про те, чи було якесь порушення обов’язків з боку вендора, стає ключовим питанням. І, в результаті, для того, щоб розглянути, чи можна віднести до вендора фактичні збитки, які виявилися (тобто втрати користувача, що виникли через затримку виконання), необхідно також розглянути, як розуміти обов’язок користувача співпрацювати.

Підсумки

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

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