Юридичне значення вибачень від вендора до користувача у розробці систем

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

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

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

Чому в сфері розробки систем “вибачення” стає проблемою?

Розробка систем – це вид послуг

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

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

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

Користувачі вимагають вибачення, оскільки вони є “клієнтами”

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

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

Питання про те, наскільки довго користувачі можуть залишатися клієнтами

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

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

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

Як суд бачить “вибачення”

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

Судовий прецедент щодо вибачення 1: Вимога від користувача вклонитися в ноги

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

Х, хоча і створив вибачення з цим пунктом, але це було зроблено після того, як він відвідав офіс позивача 4 жовтня 2001 року (Хейсей 13 рік) після нічної роботи, був односторонньо суворо звинувачений, змушений вклонитися в ноги, а потім створив вибачення відповідно до вимог позивача, щоб заспокоїти гнів посадовців позивача. Це не було щирим вибаченням від Х, і так само вибачення, створене Н, не було щирим.

Рішення Токійського окружного суду від 23 квітня 2004 року (Хейсей 16 рік)

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

Судовий прецедент щодо вибачення 2: Вибір між написанням вибачення або сплатою 20 мільйонів єн

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

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

(Пропущено)

Ми повинні вважати, що він зробив все можливе як продавець продуктів E, і ми не можемо сказати, що він просто знехтував своїми зобов’язаннями за основним договором купівлі-продажу, тому що він не зробив більше.

Рішення Токійського окружного суду від 11 липня 1996 року (Хейсей 8 рік)

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

Що спільного в цих судових прецедентах

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

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

Будьте обережні, не варто легковажно вибачатися

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

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