Prawo dotyczące „spalenia” projektów rozwoju systemu

Projekt związany z rozwojem systemu nie jest czymś, co można osiągnąć z dnia na dzień. Wymaga zaangażowania wielu osób i organizacji, ogromnych środków finansowych oraz długiego okresu rozwoju. W tym artykule omówimy, jak zjawisko “spalenia” projektu w kontekście rozwoju systemu może być uporządkowane w ramach japońskiego prawnego układu ramowego. Przedstawimy również wytyczne dotyczące rozwiązań tego problemu.

Dlaczego projekty “płoną”

Każdy system IT, nawet jeśli nie jest to projekt o wyjątkowo dużym zasięgu, działa poprawnie tylko dzięki skumulowanemu nakładowi wielu plików programu i kodu źródłowego. Często jest tak skomplikowany i precyzyjnie wykonany, że trudno to sobie wyobrazić, patrząc tylko na interfejs użytkownika (a im prostszy i bardziej zwięzły jest interfejs użytkownika, tym bardziej prawdopodobne jest to).

• Termin dostawy jest ustalony na początku, ale specyfikacje i wymagania pozostają niejasne, a czas mija
• Wiele członków zespołu jest zbyt skupionych na problemach polityki wewnętrznej i rezygnuje z powodu stresu związanego z relacjami międzyludzkimi
• Brakuje zdolności negocjacyjnych na poziomie zarządzania, w tym u PM, i nie wymaga się od członków odpowiedniego raportowania, komunikacji i konsultacji

Przyczyny “płonących” projektów mogą być różne w zależności od projektu. Jednak z prawnego punktu widzenia, przyczyny te można dość prosto zorganizować według kilku typów.

Typ 1 pożaru: Przypadek, gdy projekt zatrzymuje się w połowie

Typowym powodem, dla którego rozwój systemu może zatrzymać się w połowie, jest brak komunikacji między stroną użytkownika a dostawcą. Projekt rozwoju systemu z natury wymaga nie tylko specjalistycznej wiedzy technicznej i organizacyjnej ze strony dostawcy, ale także współpracy ze strony użytkownika, który ostatecznie będzie korzystać z tego systemu.

Jeśli więc projekt jest prowadzony bez jasnego zrozumienia, jakie role obie strony mają do spełnienia, może dojść do sytuacji przypominającej “przerzucanie obowiązków”, co z kolei utrudnia płynne prowadzenie projektu. Szczegółowe rozważania prawne dotyczące obowiązków strony użytkownika i dostawcy można znaleźć w poniższych artykułach.

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

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

Chociaż szczegółowe informacje na temat odpowiedzialności każdej ze stron można znaleźć w powyższych artykułach, kluczowym punktem tej dyskusji jest to, że zarówno użytkownik, jak i dostawca mają pewne obowiązki w projekcie rozwoju systemu. Na przykład, w przypadku definicji wymagań, projektowania wyglądu, takiego jak ekrany (tj. podstawowe projektowanie), i akceptacji, które nie mogą być zakończone bez współpracy ze strony użytkownika, orzecznictwo i precedensy uznają obowiązek współpracy ze strony użytkownika.

Z drugiej strony, dostawca również ma ogólny obowiązek zapewnienia płynnego przebiegu projektu i identyfikacji oraz eliminacji przeszkód, po otrzymaniu współpracy ze strony użytkownika, jak opisano powyżej (i jednocześnie, po podjęciu wysiłków na rzecz komunikacji, aby uzyskać taką współpracę).

Na podstawie tego podejścia, sądy wskazują na obowiązek użytkownika do wprowadzania zarządzania z wewnątrz jako wewnętrznego systemu, oraz na obowiązek dostawcy do wykazania swojej specjalistycznej wiedzy i umiejętności technicznych jako zewnętrznego eksperta i do podejmowania działań w sposób sprawiedliwy wobec wszelkich konfliktów.

Scenariusz, w którym takie “zatrzymanie” jest najbardziej prawdopodobne, to moment akceptacji. Szczegółowe wyjaśnienia na temat akceptacji można znaleźć w poniższym artykule.

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

W takich przypadkach, jeśli dojdzie do konfliktu, dowody, które można obiektywnie potwierdzić, takie jak przebieg poprzednich projektów i treść dyskusji, są często kluczowe. Dlatego dokumenty zapisane wcześniej często mają duże znaczenie. Aby nie zaszkodzić swojej pozycji, ważne jest, aby dokładnie zarządzać dokumentacją. Szczegółowe wyjaśnienia na temat znaczenia zarządzania dokumentacją w rozwoju systemów można znaleźć w poniższym artykule.

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

Typ 2 pożaru: Przypadek rezygnacji z własnej inicjatywy użytkownika

Można również przewidzieć sytuacje, w których projekt jest zatrzymywany na życzenie użytkownika. Na przykład, firma zaczęła tworzyć system IT do zarządzania zasobami ludzkimi, włączając w to placówki zagraniczne, ale strategia ekspansji za granicę, która sama w sobie jest strategią rozszerzania kanałów sprzedaży, została wycofana. W takim przypadku, rozwój systemu, który właśnie zaczęliśmy, może stać się niepotrzebny nawet dla użytkownika.

Przede wszystkim, kwestia, jak powinien być zbudowany system IT używany w firmie, nie jest niezależna od problemu, jakie operacje są przeprowadzane w firmie. Dlatego też, w wyniku znacznych zmian w strukturze organizacyjnej i reorganizacji działów biznesowych, a także radykalnej rewizji strategii, wymagania systemu, które stają się potrzebne (lub niepotrzebne), mogą się zmienić po fakcie.

W takich okolicznościach, przerwanie projektu w trakcie może również prowadzić do różnych problemów prawnych. W takim przypadku, zazwyczaj, ze względu na własną inicjatywę użytkownika, dostawcy są również przyznawane pewne prawa prawne, takie jak żądanie wynagrodzenia proporcjonalnego do stopnia ukończenia. W zależności od rodzaju umowy, której używano, podstawa prawna może się różnić, ale jej treść jest zorganizowana w następujący sposób:

・W przypadku umowy o dzieło: Artykuł 641 Kodeksu cywilnego (Japońskiego Kodeksu Cywilnego)
Artykuł 641 Kodeksu cywilnego
→Zamawiający może w każdej chwili rozwiązać umowę, odszkodowując wykonawcę za szkody, dopóki praca nie zostanie ukończona.
・W przypadku umowy quasi-zlecenia: Artykuł 648 ustęp 3 Kodeksu cywilnego (w zależności od okoliczności, możliwe jest również żądanie odszkodowania na podstawie artykułu 651 Kodeksu cywilnego)
Artykuł 648 Kodeksu cywilnego
→Jeżeli wykonanie zlecenia zostanie zakończone w trakcie z powodu przyczyn, które nie mogą być przypisane zleceniobiorcy, zleceniobiorca może żądać wynagrodzenia proporcjonalnego do stopnia wykonania.
Artykuł 651 Kodeksu cywilnego
→1. Zlecenie może być w każdej chwili rozwiązane przez każdą ze stron.
→2. Jeżeli jedna ze stron rozwiąże zlecenie w momencie niekorzystnym dla drugiej strony, ta strona musi odszkodować drugą stronę za szkody. Jednakże, nie dotyczy to przypadków, gdy istnieją nieuniknione okoliczności.

Typ 3 pożaru: Kiedy niedociągnięcia w dostarczonym systemie ujawniają się później

Użytkownicy często oceniają jakość systemu na podstawie odczuć z interakcji z interfejsem, jednak z punktu widzenia osoby przyjmującej zlecenie, trudniejsze jest zaprojektowanie bazy danych czy wyznaczenie punktów testowych, uwzględniając wszystkie możliwe metody operacji.

W związku z tym, nawet system, który wydawał się działać bez problemów na początku, może z czasem zacząć wykazywać niedociągnięcia, takie jak:

• Spowolnienie prędkości przetwarzania wraz ze wzrostem ilości rejestrowanych danych,
• System, który wydawał się działać bez problemów podczas codziennych operacji, okazał się mieć błędy podczas rzadkich, specjalnych operacji,
• Nawet jeśli wyniki wydają się być poprawnie generowane na powierzchni, logika może być błędna. Na przykład, nawet jeśli na wejście “1+1” system poprawnie zwraca “2”, nie oznacza to, że przeprowadza prawidłowe obliczenia. Może zwracać “2” niezależnie od wprowadzonego równania. Błędy logiczne są często trudne do wykrycia tylko przez interakcję z interfejsem. W tym sensie, pewien poziom “umiejętności technicznych” jest wymagany podczas procesu testowania.

Takie sytuacje mogą rzeczywiście wystąpić. Jeśli analizować takie przypadki z prawnego punktu widzenia, mogą one stanowić naruszenie obowiązków zarządzania projektem przez dostawcę, co oznacza problem niewłaściwego wykonania zgodnie z prawem cywilnym (japońskie Prawo Cywilne).

Jeśli nie ma specjalnych ustaleń w umowie, zasady dotyczące umów o dzieło będą miały zastosowanie.

Punkty do rozważenia w takim przypadku można podsumować następująco:

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

Można to podsumować w ten sposób.

Podsumowanie

Każdy projekt rozwoju systemu przechodzi przez różne i złożone zakręty. Jednakże, jeśli mówimy o “zapaleniu” projektu z prawnego punktu widzenia, ramy przedstawione w tym artykule staną się pewnego rodzaju mapą. Problemy prawne związane z rozwojem systemów z pewnością obejmują wiele różnych tematów.

Jednakże, podobnie jak praca nad rozwojem systemu wymaga konstruktywnego myślenia, zarządzanie ryzykiem związanym z tym również może być przeprowadzane w bardziej konstruktywny sposób, jeśli nie stracimy z oczu całego obrazu dziedziny.