Що таке закон, що стосується 'полум'я' проектів розробки систем?

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

Чому проекти “займаються”

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

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

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

Тип вогню 1: Коли проект зупиняється на півдорозі

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

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

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

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

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

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

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

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

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

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

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Тип вогню №2: Випадок, коли користувач самостійно відмовляється від послуг

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

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

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

・У випадку договору підряду: стаття 641 Японського цивільного кодексу
Стаття 641 Японського цивільного кодексу
→ Замовник може в будь-який час розірвати договір, відшкодувавши збитки, якщо підрядчик не завершив роботу.
・У випадку договору доручення: стаття 648 пункт 3 Японського цивільного кодексу (в залежності від обставин, можливо вимагати відшкодування збитків за статтею 651)
Стаття 648 Японського цивільного кодексу
→ Якщо виконання доручення припиняється на середині через причини, які не можуть бути пов’язані з винуватцем, виконавець може вимагати оплати відповідно до ступеня виконання роботи.
Стаття 651 Японського цивільного кодексу
→1. Доручення може бути розірвано будь-якою зі сторін в будь-який час.
→2. Якщо одна зі сторін розриває доручення в невигідний для іншої сторони час, вона повинна відшкодувати збитки іншій стороні. Однак, це не стосується випадків, коли є необхідні причини.

Тип вогню №3: Виявлення недоліків у системі, що була поставлена, пізніше

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

Тобто, навіть якщо система спочатку працювала без проблем, можуть виникнути такі ситуації:

• Зі збільшенням кількості даних, що реєструються, швидкість обробки починає знижуватися
• Система, яка здавалася працездатною при виконанні щоденних основних завдань, може мати помилки при виконанні спеціальних операцій, які виникають кілька разів на місяць або рік
• Навіть якщо здається, що результати виводяться правильно, логіка може бути неправильною (наприклад, навіть якщо на вхід від користувача подається 1+1 і правильно виводиться “2”, це не означає, що обчислювальний процес виконується правильно. Часто помилки логіки не виявляються, якщо просто оперувати інтерфейсом. У цьому сенсі, тестування вимагає певного рівня “технічних навичок”.)

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

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

Пункти, які слід розглянути в цьому випадку, можна узагальнити так:

https://monolith.law/corporate/defect-warranty-liability[ja]

Таким чином, це можна узагальнити.

Підсумки

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

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