Jakie są prawa w przypadku niepowodzenia projektu z udziałem podwykonawców (ponownie zleconych)?

Projekty rozwoju systemów nie zawsze kończą się transakcjami handlowymi tylko między użytkownikiem zlecającym pracę a dostawcą przyjmującym zamówienie. W niektórych przypadkach, przewidując potrzebę dodatkowego personelu lub wprowadzenia technicznej wiedzy, której nie ma u dostawcy pierwotnego, może być wykorzystywana podwykonawstwo (ponowne zlecenie). W takich sytuacjach, jeśli projekt nagle się załamie, spory mogą nie ograniczać się tylko do dwóch stron: użytkownika i dostawcy. Jak więc dokonuje się oceny odpowiedzialności, gdy projekt, który był prowadzony na podstawie skomplikowanych relacji między trzema lub więcej stronami, nagle się załamie? W tym artykule omówimy ryzyko “zapalenia” projektu specyficzne dla podwykonawstwa (ponownego zlecenia) oraz wytyczne dotyczące reagowania na takie sytuacje.

Jak wykorzystanie podwykonawstwa (ponownego zlecenia) zmienia praktykę prawną w rozwoju systemów?

Konflikty, które obejmują wiele stron, mogą ewoluować w skomplikowane sprawy, co jest powodem do obaw. Jednak nawet w takich przypadkach, ważne jest, aby mieć podstawową wiedzę na temat natury konfliktów między użytkownikami a dostawcami. Projekty rozwoju systemów zwykle postępują poprzez współpracę między dostawcą, który jest ekspertem technicznym, a użytkownikiem, który posiada bogatą wiedzę o działalności firmy. W trakcie długotrwałego projektu, wymagana jest ścisła współpraca między stronami. Dobrym przykładem jest sytuacja, gdy projekt zostaje przerwany z powodu użytkownika. Szczegółowo omawiamy to w poniższym artykule.

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

W powyższym artykule wyjaśniamy, że nawet jeśli użytkownik zdecyduje się na przerwanie rozwoju systemu, odpowiedzialność prawna nie zawsze spoczywa na użytkowniku. Nie jest łatwo ustalić, kto powinien ponieść odpowiedzialność za przerwanie projektu. Jeśli obie strony mają różne postrzeganie sytuacji, odpowiedzialność może łatwo się odwrócić, co może prowadzić do eskalacji konfliktu. Terminy takie jak “obowiązek współpracy” nałożony na użytkownika i “obowiązek zarządzania projektem” nałożony na dostawcę były często używane w wyrokach sądowych w przeszłości. Ta “walka” między obowiązkami stanowi podstawowy model praktyki prawnej w rozwoju systemów, który staje się bardziej skomplikowany, gdy zaangażowane są podwykonawstwa (ponowne zlecenia).

Do jakiego stopnia sięga skuteczność rozwiązania umowy, gdy projekt doznał niepowodzenia?

Na przykład, jeśli z jakiegoś powodu umowa między użytkownikiem a dostawcą zostanie rozwiązana, zakres tego wpływu staje się problemem. Jeśli cały projekt pozostaje wyłącznie problemem między dwiema stronami, skutki rozwiązania umowy ograniczają się do zwolnienia obu stron z obowiązków względem siebie, czyli do “przywrócenia stanu pierwotnego”. Jednakże, jeśli relacje między podwykonawcą (podwykonawcą), który nie zawarł bezpośredniej umowy, a dostawcą pierwotnym zostaną jednocześnie rozwiązane, może to spowodować nieprzewidziane straty dla podwykonawcy (podwykonawcy), a czasami może to prowadzić do okrutnych sytuacji. Jednakże, jeśli podwykonawca (podwykonawca) i dostawca pierwotny są nadal związani, mimo że projekt, który jest podstawą dla podwykonawstwa (podwykonawstwa), już doznał niepowodzenia, to również może prowadzić do nieracjonalnej sytuacji. Jak więc powinniśmy uporządkować tę kwestię?

Ważne precedensy dotyczące zakresu wpływu rozwiązania

Zakres wpływu rozwiązania umowy między użytkownikiem a dostawcą, który może służyć jako punkt odniesienia, jest wyrażony w wyroku Sądu Okręgowego w Tokio z dnia 24 grudnia 2012 roku (rok 24 ery Heisei). W tym procesie zakres wpływu dobrowolnego rozwiązania umowy między użytkownikiem a dostawcą pierwotnym stał się problemem, ale wyrok ten wskazał, że ta skuteczność wpływa również na relacje między dostawcą pierwotnym a podwykonawcą (podwykonawcą).

W niniejszym procesie, mimo że wyraziłem zamiar rozwiązania części umowy podwykonawczej dotyczącej tej samej pracy, jest to fakt, że część umowy pierwotnej dotyczącej tej samej pracy została dobrowolnie rozwiązana 20 kwietnia 2009 roku (rok 21 ery Heisei), jak to wynika z faktu przedstawionego w punkcie (3)U, na mocy tego dobrowolnego rozwiązania, część umowy podwykonawczej dotyczącej tej samej pracy, ponieważ nie istnieje już przedmiot wykonania, jest uważana za naturalnie zakończoną, więc nie ma innego wyjścia, jak stwierdzić, że wyrażenie zamiaru rozwiązania, które pozwany wyraził później, nie ma żadnego znaczenia prawnego.

Wyrok Sądu Okręgowego w Tokio z dnia 25 grudnia 2012 roku

W tym wyroku stwierdzono, że na skutek wpływu dobrowolnego rozwiązania, umowa podwykonawcza jest “naturalnie zakończona”. Można przypuszczać, że prawidłowość tego wniosku jest jeszcze większa, zwłaszcza gdy chodzi o prace o niskiej uniwersalności, które nie mają szczególnego sensu bez zlecenia od użytkownika. W tym wyroku stwierdzono również, że podwykonawca (podwykonawca) nie może żądać wynagrodzenia, ale jeśli próbujemy rozwiązać wszystkie przypadki dobrowolnego rozwiązania w ten sposób, może to prowadzić do problemów z punktu widzenia sprawiedliwości sądowej. Dlatego uważamy, że standardy oceny dla takich przypadków nie są jeszcze w pełni ustalone.

Możliwość żądania wynagrodzenia przez podwykonawcę (podwykonawcę) powinna być uporządkowana według przyczyny rozwiązania

W wyżej wymienionym precedensie, wydaje się, że stwierdzono, że podwykonawca (podwykonawca) zasadniczo nie może żądać wynagrodzenia, jeśli umowa została dobrowolnie rozwiązana między użytkownikiem a dostawcą pierwotnym. Jednakże, aby dojść do bardziej sensownego wniosku na ten temat, wydaje się, że konieczne jest uporządkowanie go według przyczyny rozwiązania. Na przykład, jeśli umowa została rozwiązana z powodu zaniedbania dostawcy pierwotnego, a dobrowolne rozwiązanie zostało dokonane bez zgody podwykonawcy (podwykonawcy), uważa się, że jest to sprawiedliwe, aby umożliwić podwykonawcy (podwykonawcy) żądanie wynagrodzenia. Z drugiej strony, jeśli dostawca pierwotny nie jest uznany za winnego, zwłaszcza jeśli podwykonawca (podwykonawca) zawarł umowę o wykonanie prac, odbiór wynagrodzenia nie jest możliwy od samego początku, więc nie ma innego wyjścia, jak uznać, że żądanie wynagrodzenia jest niemożliwe. Kwestia podziału ryzyka w relacjach “bez winy – bez winy” jest kwestią “obciążenia ryzykiem” w prawie cywilnym.

Artykuł 536
1. Z wyjątkiem przypadków przewidzianych w dwóch poprzednich artykułach, jeżeli nie można przypisać winy żadnej ze stron, a zobowiązanie nie może być wykonane z powodu tego, dłużnik nie ma prawa do otrzymania przeciwnego świadczenia.

Obciążenie ryzykiem jest jednym z bardzo ogólnych tematów dotyczących prawa cywilnego, niezależnie od IT czy rozwoju systemów. Typowym przykładem jest na przykład umowa sprzedaży, w której produkt jest niszczony przed dostarczeniem z powodu nagłego, dużego kataklizmu naturalnego. Uważa się, że stosunek między dostawcą pierwotnym a podwykonawcą (podwykonawcą) również będzie podlegał zastosowaniu przepisów dotyczących obciążenia ryzykiem, jeśli problemem staje się to, jak regulować relacje “bez winy – bez winy”.

Uwagi dotyczące rozwiązania umowy z udziałem podwykonawców (zleconych ponownie)

W związku z powyższym tematem, w umowach zawieranych między głównym dostawcą a podwykonawcą (zleconym ponownie), mogą być zawarte klauzule, które przewidują, że płatności od użytkowników są dokonywane dopiero po otrzymaniu płatności. Jednakże, nawet jeśli taka klauzula jest zawarta, uważa się, że termin płatności dla podwykonawcy (zleconego ponownie) nadejdzie, gdy główny dostawca nie ma już perspektyw na otrzymanie płatności. Innymi słowy, nawet jeśli taka klauzula jest zawarta, istnieją ograniczenia w odmawianiu płatności podwykonawcy (zleconemu ponownie) na jej podstawie. W kontekście problemów prawnych związanych z podwykonawstwem (zleconym ponownie), warto zwrócić uwagę na zakres wpływu rozwiązania umowy oraz na powyższe kwestie.

Podsumowanie

Gdy projekt rozwoju systemu postępuje, angażując podwykonawców (ponowne zlecenie), sprawy mogą się skomplikować. W związku z tym, trudno jest rozstrzygnąć sprawę za pomocą prostego procesu, takiego jak nałożenie obowiązku rekompensaty strat na stronę, która naruszyła obowiązki, takie jak “obowiązek współpracy” użytkownika czy “obowiązek zarządzania projektem” dostawcy. Kłopotliwość przypadków “awarii” projektów, które angażują trzy lub więcej stron, wydaje się być bardzo dobrze widoczna w aspektach takich jak zakres wpływu rozwiązania umowy. W tej kwestii, oprócz oczekiwania na dalsze gromadzenie precedensów sądowych, ważne jest również formułowanie argumentów na podstawie indywidualnych przypadków.