O prawie i przykładach sądowych dotyczących rozróżnienia między delegowaniem a kontraktowaniem w branży IT

W projektach związanych z IT często zdarza się, że wielu specjalistów z różnych firm angażuje się w jeden projekt. W takich sytuacjach, miejsce pracy inżyniera biorącego udział w projekcie często jest oddzielone od lokalizacji firmy, do której należy. Przykładem mogą być sytuacje, gdy pracownik jest stale zatrudniony u klienta lub w ramach tzw. SES. Niejasność dotycząca formy zatrudnienia lub umowy pracownika może prowadzić nie tylko do ryzyka konfliktów dotyczących praw pracowniczych, ale także do ryzyka “spalenia” całego projektu. W tym artykule wyjaśnimy różnicę między delegowaniem a kontraktem, które często są mylone w praktyce, oraz jakie problemy związane z umowami mogą wpływać na płynne prowadzenie całego projektu.

Różnica między delegowaniem a kontraktem

Kiedy firma zlecająca pracę (lub podmiot, do którego prace są dalej zlecone) różni się od firmy zlecającej, często zdarza się, że na podstawie umowy o dzieło pracownicy są wysyłani na miejsce pracy. Innymi słowy, podmiot przyjmujący zamówienie/wystawca pośredniczy w wysyłaniu techników na miejsce pracy. Co więcej, szczegółowe wyjaśnienia na temat tego, czym jest umowa o dzieło, można znaleźć w poniższym artykule.

https://monolith.law/corporate/system-development-contact-agreement[ja]

W powyższym artykule wyjaśniamy, że istotną cechą umowy o dzieło jest to, że “ukończenie pracy” staje się warunkiem wykonania zobowiązania. Wyjaśniamy również, że ważne jest, aby jasno określić warunki akceptacji podczas zawierania umowy, aby zapobiec problemom. W przypadku stałego umieszczania osób na miejscu na podstawie umowy o dzieło, jest to tylko transakcja handlowa między firmami, więc strona zlecająca/przyjmująca techników nie ma obowiązku przestrzegania prawa pracy. Jednak w zamian, nie jest prawnie dozwolone wydawanie bezpośrednich poleceń tym technikom. Jeśli nie weźmie się pod uwagę tych kwestii, nawet jeśli na pierwszy rzut oka zawarta została umowa o dzieło, istnieje ryzyko, że zostanie ona uznana za nielegalne dostarczanie pracowników, czyli “fałszywy kontrakt”.

https://monolith.law/corporate/criteria-for-disguised-contract[ja]

Przypadek sporu wynikający z niejasnego rozróżnienia między delegowaniem a kontraktem

Omijając ogólną dyskusję na temat “kontraktu” i “fałszywego kontraktu”, poniżej omówimy przypadek, w którym projekt zakończył się niepowodzeniem z powodu niejasnego rozróżnienia między delegowaniem a kontraktem. Takie niejasne rozróżnienie może prowadzić nie tylko do naruszenia praw pracowników i sporów między pracodawcą a pracownikiem, ale także do ryzyka niepowodzenia całego projektu, co można łatwo zrozumieć, sprawdzając poniższe informacje.

Wymagania dotyczące wykonania zobowiązań znacznie się różnią między delegowaniem a kontraktem

Delegowanie i kontrakty są podobne w tym, że firma pośredniczy w wysyłaniu personelu na miejsce rozwoju. Jednak, jak wcześniej wspomniano, w przypadku kontraktu, wykonanie zobowiązań nie jest zasadniczo uznawane, dopóki nie zostanie potwierdzone “ukończenie pracy”. W przypadku cytowanego poniżej wyroku, punktem spornym było, czy można uznać roszczenie o wynagrodzenie w przypadku, gdy projekt ostatecznie zakończył się niepowodzeniem. W przypadku kontraktu, “ukończenie pracy” jest wymagane jako warunek, podczas gdy w przypadku delegowania, możliwe jest uzasadnienie wynagrodzenia za pracę tylko na podstawie rzeczywistych wyników, takich jak rzeczywiste godziny pracy.

Strona zlecająca / dostawca (powód) twierdził, że umowa o delegowanie została zawarta po fakcie, a personel był wysyłany wyłącznie w formie delegowania, i twierdził, że “ukończenie pracy” nie było wymagane jako obowiązek. Jednak sąd odrzucił ten argument (podkreślenia i pogrubienia dodane przez autora).

Powód twierdzi, że po potwierdzeniu, że powód nie jest w stanie opracować programu dla systemu, 1 kwietnia (1986) roku, między powodem a pozwanych, koszty rozwoju zostały obniżone z 7106000 jenów za dwa okresy i dodatek za organizację obozu do 5500000 jenów, które pozwany miał szybko zapłacić powodowi, a pozwany miał przejąć pracę powoda od 1 kwietnia tego samego roku, a co do rozwoju systemu informacji tekstowej przez pozwanego, powód miał wysłać personel w formie delegowania pracy, a liczba delegowanych pracowników miała wynosić trzy osoby, a cena jednostkowa miała wynosić 55000 jenów dla dwóch osób i 30000 jenów dla jednej osoby. Wyniki przesłuchania reprezentanta powoda są zgodne z tym.
Jednak pozwany zaprzecza, że taka umowa została zawarta, a powód pierwotnie zobowiązał się do stworzenia programu dla systemu na rzecz pozwanego i miał obowiązek go ukończyć, a osoba w takiej pozycji, która nie ukończyła go i nie mogła przekazać programu, pozwany, który jest zamawiającym, nie mógłby zrzec się obowiązku tworzenia go przez powoda ani zapłacić za koszty, które powód poniósł w międzyczasie, co jest nieracjonalne. Rzeczywiście, jeśli powód miał obowiązek ukończenia programu, argument pozwanego jest uzasadniony.
Dlatego najpierw rozważymy, czy powód miał obowiązek ukończenia programu w umowie dotyczącej rozwoju programu dla systemu.
(Omitted) Patrząc na dowody, nie można znaleźć dowodów, które potwierdzałyby, że powód nie miał obowiązku ukończenia programu w umowie. (Omitted) A reprezentant powoda, w wyniku jego przesłuchania, stwierdził, że umowa była umową o przyjęcie zamówienia na całość, a program był rozwijany wewnątrz firmy powoda, a powód przyjął na siebie obowiązek ukończenia programu i zeznał na tej podstawie, i nigdy nie zaprzeczył, że miał taki obowiązek. Patrząc na dokumenty, nie ma sporu co do powstania (omitted) harmonogramu, który zakłada, że powód miał obowiązek ukończenia programu i opisuje harmonogram do jego ukończenia. Dlatego, na podstawie tego, można uznać, że powód miał obowiązek ukończenia programu na mocy umowy. (Omitted)
Nie ma innych dowodów, które przeczyłyby ustaleniu, że powód miał obowiązek ukończenia programu.
Jeśli tak, jak twierdzi pozwany, osoba, która nie wykonała programu, na którym miała obowiązek pracować, ponosi odpowiedzialność za niewykonanie zobowiązań, ale nie może żądać zapłaty za kontrakt, co jest oczywiste, i chyba że istnieją szczególne okoliczności, zamawiający nie powinien zwalniać takiej osoby z jej obowiązków na mocy umowy bezwarunkowo i dodatkowo płacić za koszty, które poniosła do tej pory. Reprezentant powoda, w wyniku jego przesłuchania, stwierdził, że nawet jeśli program nie został ukończony, jeśli pracował zgodnie z instrukcjami zamawiającego, wykonał pracę w zakresie, który został mu nakazany w terminie, więc uważa, że może żądać zapłaty za oprogramowanie komputerowe za wykonaną pracę, ale to jest wypowiedź sprzeczna z ogólnym rozumieniem kontraktu, i w branży powoda i pozwanego, które rozwijają oprogramowanie, nie można uznać, że istnieje praktyka płacenia wynagrodzenia, nawet jeśli praca nie jest ukończona, w kontrakcie, co jest różne od ogólnego rozumienia, nawet w świetle zeznań świadków, więc wyniki przesłuchania reprezentanta powoda są tylko jego własnymi poglądami i nie mogą być przyjęte.

Wyrok Sądu Okręgowego w Tokio z 22 lutego 2011 roku (2011)

Co można odczytać z powyższego przykładu sądowego

W powyższym przykładzie sądowym szczególnie warto zwrócić uwagę na:

1. Nie zwalniając dostawcy z obowiązku “ukończenia pracy” na podstawie zawarcia umowy o delegowanie na zasadzie formalnej i powierzchownej, ale opierając się na konkretnej umowie między obiema stronami dotyczącej “ukończenia pracy”, oczekiwano na sprawiedliwe rozwiązanie sporu w rzeczywistości
2. Umowa została uznana za kontrakt, ponieważ “ukończenie pracy” było wymagane jako warunek wykonania zobowiązań, a inne kwestie były również rozstrzygane na podstawie zwyczajów handlowych w branży dotyczącej kontraktów

Można uważać, że te dwa punkty są istotne.

Podsumowując te dwa punkty, pokazują one wyraźnie, że w sądzie większą wagę przywiązuje się do rzeczywistego porozumienia między stronami, niż do tytułu umowy czy innych powierzchownych aspektów. Ponadto, po stwierdzeniu, że istota umowy jest kontraktem, rozwiązanie innych kwestii było również podejmowane z uwzględnieniem zwyczajów handlowych w branży związanej z kontraktami. Odrzucenie argumentów strony zlecającej / dostawcy za pomocą zwrotów takich jak “wypowiedź sprzeczna z ogólnym rozumieniem kontraktu” i “indywidualne poglądy” jest bardzo charakterystyczne i pokazuje wyraźnie, że tak jest. Warto zwrócić uwagę na punkt, że społeczne normy i powszechne przekonania są odzwierciedlane w interpretacji prawa i wpływają na praktykę prawną. Nawiasem mówiąc, na temat koncepcji “ukończenia pracy”, która była tak ważna w tym wyroku, omówiliśmy szczegółowo w poniższym artykule, biorąc pod uwagę kontekst rozwoju systemów.

https://monolith.law/corporate/completion-of-work-in-system-development[ja]

Biorąc pod uwagę, że kontrakty są często stosowane w praktyce projektów rozwoju systemów, a ich istotnym elementem jest “ukończenie pracy”, powinniśmy zrozumieć to głęboko.

Rozumienie obowiązków zarządzania projektem jest również wymagane jako założenie

Warto zauważyć, że ten wyrok jest ściśle związany z “obowiązkami zarządzania projektem”, które powinien ponosić dostawca, będący specjalistą w dziedzinie rozwoju systemów. Ogólne wyjaśnienie tych obowiązków jest dostępne w poniższym artykule.

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

Biorąc pod uwagę treść powyższego artykułu, łatwo zrozumieć, że odpowiedzialność dostawcy, który przyjmuje pracę jako specjalista w dziedzinie rozwoju systemów, nie jest wcale lekka. Oczywiście, nie ma wątpliwości, że w wielu przypadkach potrzebna jest współpraca ze strony użytkownika, aby projekt przebiegał płynnie. Jednakże, trudno sobie wyobrazić, że dostawca mógłby być zwolniony z obowiązku, jeśli nie podejmie żadnych starań, takich jak odpowiednie wezwanie użytkownika do współpracy. Staje się jasne, że przypisanie odpowiedzialności za niepowodzenie projektu do użytkownika jest bardzo trudne z tego punktu widzenia. Możliwe, że łatwiej będzie zrozumieć słuszność powyższego wyroku, jeśli założymy, że rozumienie zarządzania projektem jest podstawą. Możliwe, że teoria konstrukcji, która zakłada, że rzeczywistość transakcji jest umową o wykonanie prac, a nie umową o świadczenie usług, była częściej przyjmowana, aby osiągnąć zgodność z właściwym wnioskiem wynikającym z tego punktu widzenia.

Podsumowanie

Powyżej omówiliśmy potencjalne konflikty projektowe, które mogą wystąpić, gdy różnica między delegowaniem a zleceniem jest niejasna. W przypadkach, które omówiliśmy, ważniejsze od formalnego tytułu umowy są konkretne obietnice, które zostały wymienione między stronami, a także praktyki handlowe w branży. Dodatkowo, wydaje się, że ważne jest również zrozumienie “obowiązku zarządzania projektem” jako podstawy dla indywidualnie zawartych umów, niezależnie od tego, czy są to umowy o delegowanie czy zlecenie, a nie tylko dyskusje prawne dotyczące szczegółów takich umów. W projektach IT, nie tylko delegowanie i zlecenie, ale także inne metody wykorzystania personelu, takie jak delegowanie lub quasi-delegowanie, są powszechne. Szczegółowe omówienie ogólnych różnic i różnic z uwzględnieniem tych aspektów znajduje się w poniższym artykule.

https://monolith.law/corporate/difference-contract-dispatch-loan-labor-supply[ja]

Nie tylko różnice między delegowaniem a zleceniem, ale także różne warianty konfliktów wynikających z niejasności typu umowy mogą być przewidywane. Jednakże, nawet jeśli sprawa, którą trzeba rozwiązać, jest nieznana, to co jest naprawdę ważne, to zrozumienie podstawowych kwestii, takich jak “obowiązek zarządzania projektem”.