MONOLITH LAW OFFICE+81-3-6262-3248Dni powszednie 10:00-18:00 JST [English Only]

MONOLITH LAW MAGAZINE

IT

Czym są problemy prawne i umowne związane z rozwojem Agile?

IT

Czym są problemy prawne i umowne związane z rozwojem Agile?

W podejściu do rozwoju systemów istnieją różne metody. Najbardziej klasycznym i powszechnym jest model Waterfall, a wiele książek prawniczych dotyczących rozwoju systemów omawia ten model jako punkt wyjścia. W tym artykule omówimy problemy prawne związane z rozwojem systemów opartych na modelu Agile, który jest trudny do zrozumienia na podstawie książek i innych źródeł informacji.

Model Agile w prawie

Opisujemy cechy rozwoju Agile.

Co to jest model w rozwoju systemów?

W projektach rozwoju systemów istnieje coś takiego jak model rozwoju, który służy jako ramy do monitorowania postępów. Najbardziej reprezentatywnym jest tzw. “model wodospadu”. To znaczy, podobnie jak woda spada z “góry” do “doliny” rzeki, przechodzi przez wszystkie etapy, takie jak definiowanie wymagań, projektowanie, implementacja, testowanie itp. Celem jest zminimalizowanie powrotów i dublowania pracy, co jest odpowiednie dla planowego prowadzenia prac.

Z drugiej strony, w modelu Agile, małe programy są implementowane i testowane na bieżąco. W ten sposób, powtarzając cykl implementacji i testowania małych programów, stopniowo tworzy się większy system. Szczegółowe wyjaśnienie tych modeli rozwoju systemów, a także porównanie zalet i wad obu modeli, można znaleźć w poniższym artykule.

https://monolith.law/corporate/legal-merits-and-demerits-of-development-model[ja]

Cechy modelu Agile

Główną zaletą rozwoju za pomocą modelu Agile jest możliwość szybkiego rozpoczęcia rzeczywistej pracy. Ponieważ zadania “upstream”, takie jak definiowanie wymagań i tworzenie dokumentacji projektowej, nie są oddzielone od implementacji programu, model ten jest odpowiedni do elastycznego prowadzenia projektu, w tym do reagowania na dodawanie i modyfikowanie funkcji oraz zmiany specyfikacji. Z punktu widzenia prawa, kluczowym elementem sukcesu modelu Agile jest to, jak zarządzać dokumentacją i zmianami. W modelu Agile, role i odpowiedzialności nie są tak jasno zdefiniowane jak w modelu wodospadu. Ponadto, ze względu na nacisk na “szybkość” wdrożenia, a nie zarządzanie, istnieje ryzyko, że dokumentacja projektowa, specyfikacje i protokoły nie będą w pełni realizowane.

Co więcej, w odniesieniu do zarządzania zmianami, model Agile jest sprawniejszy w reagowaniu na zmiany, co może prowadzić do sytuacji, w której proces zatwierdzania przez decydentów jest pomijany, a projekt staje się niekontrolowany, gdy na poziomie operacyjnym odpowiada się na żądania zmiany specyfikacji. W takim przypadku, zaleta modelu rozwoju, która polega na “sprawnym reagowaniu na zmiany po fakcie”, może sama w sobie stać się ryzykiem dla projektu.

Zarządzanie dokumentacją i zmianami w rozwoju Agile

Jak zarządzać dokumentacją i zmianami w modelu rozwoju Agile?

Znaczenie zarządzania dokumentacją

W projektach rozwojowych opartych na modelu Agile, prawne obawy wynikają z faktu, że komunikacja oparta na ustnych porozumieniach gromadzi się, prowadząc do braku dokumentacji. Szczegółowe wyjaśnienia na temat tego, dlaczego zarządzanie dokumentacją jest ważne w projektach rozwoju systemów, można znaleźć w poniższym artykule.

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

W tym artykule wyjaśniamy znaczenie zarządzania dokumentacją w projektach rozwoju systemów z dwóch punktów widzenia: prewencji konfliktów (tj. “prawo prewencyjne”) i zachowania dowodów w przypadku konfliktu (tj. “zarządzanie kryzysowe”).

Ustanowienie Rady Konsultacyjnej jest skuteczne dla zarządzania dokumentacją

W przypadku stosowania modelu Agile, w przeciwieństwie do modelu Waterfall, nie ma przygotowanego z góry jasnego planu. Dlatego nie wystarczy tylko zarządzać rozbieżnościami między planem a rzeczywistością, istnieje obawa, że koszty, zarówno finansowe, jak i czasowe, mogą gwałtownie wzrosnąć, jeśli zostawi się to na miejscu.

W związku z tym, skutecznym rozwiązaniem jest regularne organizowanie spotkań konsultacyjnych przez osoby odpowiedzialne za płynny przebieg projektu. W przypadku małych projektów rozwojowych, rzeczywiście, zamiast regularnie organizować spotkania konsultacyjne, preferowane jest spotykanie się, gdy osoby odpowiedzialne mogą się spotkać. Jednak w przypadku modelu Agile, ryzyko pominięcia aktualnych problemów na spotkaniach jest większe. Dlatego bezpieczne jest uwzględnienie regularnych spotkań konsultacyjnych w umowach itp. Sposób regulacji jest pokazany w poniższym przykładzie z modelu umowy Ministerstwa Gospodarki, Handlu i Przemysłu.

(Ustanowienie Rady Konsultacyjnej)

Artykuł 12. Strony A i B zobowiązują się do organizowania Rady Konsultacyjnej w celu omówienia postępów prac, zarządzania ryzykiem i raportowania, wspólnych prac i realizacji zadań przez obie strony, potwierdzenia treści, które powinny być zawarte w specyfikacji systemu, omówienia i rozwiązania problemów oraz innych kwestii niezbędnych do płynnego wykonania prac. Jednakże, (pominięcie).

2. Rada Konsultacyjna jest zasadniczo organizowana regularnie z częstotliwością określoną w umowie indywidualnej, a dodatkowo, jest organizowana w dowolnym momencie, gdy strona A lub B uważa to za konieczne.

3. Na Radzie Konsultacyjnej obecni są odpowiedzialni z obu stron, główni wykonawcy i osoby uznane za odpowiednie przez osoby odpowiedzialne. Ponadto, strony A i B mogą żądać od drugiej strony obecności osób niezbędnych do omówienia na Radzie Konsultacyjnej, a druga strona zobowiązuje się do spełnienia tego żądania, chyba że istnieją uzasadnione powody.

4. Strona B tworzy i składa raport o zarządzaniu postępami w formacie uzgodnionym oddzielnie między stronami A i B na Radzie Konsultacyjnej, potwierdza postępy na podstawie tego raportu, omawia i decyduje o kwestiach takich jak istnienie opóźnień, przyczyny i środki zaradcze w przypadku opóźnień, konieczność zmiany struktury promującej określonej w tym rozdziale (zmiana personelu, zwiększenie lub zmniejszenie liczby osób, zmiana podwykonawcy itp.), stan realizacji środków bezpieczeństwa, istnienie przyczyn wymagających zmiany umowy indywidualnej, treść przyczyn wymagających zmiany umowy indywidualnej, jeśli takie istnieją, i potwierdza kwestie, które zostały zdecydowane, kwestie, które wymagają dalszego rozważenia, i harmonogram i strony odpowiedzialne za rozważanie, jeśli istnieją kwestie wymagające dalszego rozważenia.

(Pominięcie punktów 5, 6 i 7.)

Kluczowym punktem jest nadanie pewnej legalności istnieniu Rady Konsultacyjnej w klauzulach umowy i nadanie jej innego znaczenia niż spotkania organizowane ad hoc.

Wykorzystanie Rady Konsultacyjnej do zarządzania zmianami

Ponadto, w rozwoju Agile, zmiana tego, co obie strony początkowo zgodziły się, jest założeniem. Dlatego bardzo ważne jest, jak zarządzać sytuacją, gdy specyfikacje są zmieniane po fakcie.

Jeśli Rada Konsultacyjna jest regularnie organizowana, zarządzanie zmianami staje się bardzo płynne. Na przykład, dyskusje o zmianach są prowadzone na Radzie Konsultacyjnej, a jeśli jedna strona wnosi o dyskusję o zmianach, druga strona ma obowiązek odpowiedzieć na tę dyskusję w umowie. (Poniżej znajduje się fragment z modelu umowy Ministerstwa Gospodarki, Handlu i Przemysłu.)

(Procedura zarządzania zmianami)

Artykuł 37. Strona A lub B, po otrzymaniu propozycji zmiany od drugiej strony (pominięcie), zobowiązuje się do przekazania drugiej stronie dokumentu zawierającego następujące informacje (zwane dalej “Dokumentem Zarządzania Zmianami”) w ciągu ○ dni od daty otrzymania, a strony A i B zobowiązują się do omówienia możliwości takiej zmiany na Radzie Konsultacyjnej określonej w artykule 12. (Pominięcie szczegółów dotyczących zawartości)

Kluczowe punkty powyższego przepisu można podsumować następująco:

  • Standardyzacja metody akceptacji wniosków o zmianę za pomocą formatu “Propozycji Zmiany”
  • Ustalenie terminu na dyskusję na temat wniosku od momentu jego otrzymania → Można to zastąpić innymi sformułowaniami, takimi jak “jak najszybciej”.
  • Standardyzacja miejsca dyskusji o możliwości zmiany na “Radzie Konsultacyjnej”

W ten sposób, aby uniknąć nieporozumień, takich jak “wnioskowałem o zmianę, nie wnioskowałem”, “odpowiedziałem na możliwość zmiany, nie odpowiedziałem”, sposób postępowania jest jasno określony.

Zrozumienie obowiązku uczciwości i zasady dobrej wiary jest kwestionowane

Dotychczas przedstawiliśmy modele klauzul umownych dotyczących “Rady Konsultacyjnej”, “Negocjacji Zmian” itp. Jednakże, kluczowe dla zrozumienia ich istoty są takie kwestie jak “obowiązek uczciwości” i “zasada dobrej wiary”. Sam model rozwoju Agile jest trudny do przeprowadzenia bez relacji zaufania między zamawiającym a wykonawcą. Dlatego, że priorytetem jest szybkość rozpoczęcia prac, a procedury prowadzące do rozpoczęcia są zazwyczaj minimalizowane. Dlatego też, w praktyce często wprowadza się klauzule nakładające na drugą stronę “obowiązek uczciwości”.

Artykuł 4, ustęp 3: W negocjacjach zmian, obie strony powinny uczciwie dyskutować o kwestiach takich jak cel zmian, możliwość ich wprowadzenia, wpływ zmian na cenę i termin dostawy.

Ma to na celu zapobieganie sytuacjom, w których, w negocjacjach, które początkowo opierały się na relacji zaufania, nagle pojawia się argument, że “decyzja o zmianie umowy jest wyłącznie w gestii strony otrzymującej propozycję, a nie ma obowiązku zgodzić się na przymus”, co zdradza drugą stronę poprzez formalistyczną argumentację prawną. Jest to również odzwierciedlenie zasad prawa dotyczących transakcji między osobami prywatnymi, nie tylko w przypadku rozwoju systemów.

Artykuł 1, ustęp 2 Kodeksu Cywilnego

Wykonywanie praw i spełnianie obowiązków musi odbywać się zgodnie z zasadą dobrej wiary i uczciwości.

Prawo nie zawsze kładzie nacisk wyłącznie na “zapisy umowy” lub “sformułowania artykułów”. Szczególnie w transakcjach z udziałem drugiej strony, powinno być stosowane elastycznie, uwzględniając rzeczywiste “dobrej wiary” i “uczciwość”. Co więcej, szczegółowe wyjaśnienia na temat tego, że “obowiązki” nałożone prawnie nie zawsze opierają się na procedurze “umowy”, można znaleźć w poniższym artykule.

https://monolith.law/corporate/system-development-unlawful-responsibility[ja]

Podsumowanie

W projektach rozwoju systemów opartych na modelu Agile, oczywiście ważne jest zrozumienie ryzyka, że procedury biurowe i struktura zarządzania mogą stopniowo stawać się niedbałe. Jednakże, nie tylko to jest ważne. Uważamy, że równie ważne jest zrozumienie elastycznych cech prawa, takich jak “zasada dobrej wiary”, i stosowanie ich w praktyce.

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.

Category: IT

Tag:

Wróć do góry