MONOLITH LAW OFFICE+81-3-6262-3248Všední dny 10:00-18:00 JST [English Only]

MONOLITH LAW MAGAZINE

IT

Jak si vést zápis z jednání při vývoji systému z právního hlediska

IT

Jak si vést zápis z jednání při vývoji systému z právního hlediska

Když jedna společnost pověří jinou společnost vývojem systému, často se stává, že smlouva uzavřená korporátní pečetí mezi generálními řediteli a specifikace vytvořené vedoucím pracovníkem nejsou vždy jasné, co a do kdy se má vytvořit. V mnoha případech vývoje systémů se denně konají e-maily a telefonáty na úrovni odpovědných pracovníků, schůzky pořádané vedoucími pracovníky, specifikace nejasných částí, změny specifikací podle změn situace, požadavky na přidání funkcí a žádosti o spolupráci na vzniklých problémech.

Z hlediska hladkého průběhu vývoje systému a přípravy na případné spory je důležité vytváření a správa dokumentů pro hladké řízení jednoho projektu vývoje systému.

V tomto článku vysvětlíme, jak uchovávat záznamy a materiály z jednání používaných na schůzkách o pokroku vývoje systému z právního hlediska.

Proč je důležitá správa dokumentů při vývoji systémů

V projektech vývoje systémů je velmi důležité zaznamenávat obsah jednání a průběh projektu, a to i z právního hlediska. Důvody pro to lze shrnout do následujících dvou bodů:

Aby se předešlo sporům v budoucnosti

Vývoj systémů je obvykle projekt, který zahrnuje mnoho stran, jak na straně uživatelů, tak na straně dodavatelů. Proto, pokud mezi uživateli a dodavateli existují neshody ohledně toho, jakou roli každý z nich hraje a jaké povinnosti přebírá, může to ovlivnit průběh budoucího projektu.

Navíc, pokud se na projektu podílí mnoho lidí, může to znamenat, že “každý říká něco trochu jiného a není jasné, kdo má pravdu”, což může vést k problémům v komunikaci.

Z tohoto důvodu je užitečné shrnout obsah dohodnutých dohod do písemné formy, aby se ověřilo, zda mezi oběma stranami neexistují neshody. Také shromažďování informací do dokumentů, které mohou všichni zúčastnění kontrolovat (každý ve svém vlastním čase), pomáhá udržovat krok se všemi zúčastněnými.

Mimochodem, využití právních znalostí jako prostředku k předcházení vzniku sporů se někdy označuje jako preventivní právní péče.

Jako opatření pro případ budoucích sporů

Navíc, pokud bychom měli vysvětlit důležitost správy dokumentů z mírně odlišného hlediska než je preventivní právní péče, můžeme zmínit také “krizový management” v případě, že dojde k skutečnému sporu.

Představme si, že dojde k nějakému problému, projekt je přerušen před dokončením výsledku, nebo se nedaří dodržet původní termín. Představme si situaci, kdy by to mohlo vést k soudnímu sporu. Platí to jak pro uživatele, tak pro dodavatele, ale pokud nemáte své názory zaznamenané písemně, nemůžete své argumenty prokázat a můžete být znevýhodněni u soudu.

Obzvláště v případě problémů, které vznikly kvůli nedodržení termínu, mohou být otázky jako “kdy a jak byly zjištěny problémy”, “kdy byly požadovány změny specifikací”, “jak dodavatel reagoval na požadavky na přidání funkcí ze strany uživatele” často klíčovými body, které mohou ovlivnit výsledek soudního sporu. Pokud v této situaci vznikne mnoho problémů typu “řekl jsem, neřekl jsem”, bude těžké očekávat spravedlivé řešení sporu.

Co je zvláště důležité v zápisech ze schůzí o vývoji systému?

Vysvětlíme, jak správně zaznamenávat zápisy ze schůzí v rámci projektů vývoje systémů.

Druhy schůzí v rámci vývoje systémů

V projektech vývoje systémů se často plánují a průběžně konají různé schůzky. To není nic překvapivého, pokud zvážíme, že se na projektu podílí mnoho lidí. Programátoři a inženýři, kteří implementují programy na pracovišti, často pořádají pravidelné schůzky k ověření postupu práce. Mohou také provádět recenze kódu, aby se ujistili, že nejsou žádné problémy s udržitelností nebo zranitelností v oblasti bezpečnosti.

Kromě schůzí na úrovni pracovníků na pracovišti se mohou konat také schůzky, na kterých se scházejí ředitelé společnosti nebo odpovědné osoby s pravomocemi. Tyto schůzky často určují celkový směr a politiku vývojového projektu. Tyto schůzky na úrovni odpovědných osob, které se zabývají důležitými záležitostmi, se také nazývají řídící výbory (steering committees).

Řídící výbor vyžaduje zvláštní pozornost

Jak jsme již uvedli, v rámci vývoje systémů se plánují různé schůzky v závislosti na postavení a cílech zúčastněných osob. Z právního hlediska je však zvláště důležité věnovat pozornost řídícímu výboru. Ve srovnání s kontrolními schůzkami nebo recenzními schůzkami na úrovni pracovníků je důležité plně si uvědomit význam dokumentace řídícího výboru z hlediska prevence různých sporů a opatření v případě vzniku sporů. Důvody pro toto tvrzení jsou následující:

  1. Řídící výbor je schůzka pořádaná osobami na úrovni odpovědných osob, a proto se často týká důležitých rozhodnutí. Z právního hlediska je často důležité ukázat, jaké je porozumění obou stran – uživatelů a dodavatelů.
  2. Na schůzkách na úrovni pracovníků se obsah těchto schůzek obvykle odráží v různých návrzích a specifikacích, takže je nepravděpodobné, že by došlo k problému s “nedostatkem dokumentace”. (Nicméně, pokud je dokumentace i pro tyto aspekty nedostatečná, je třeba zvážit zlepšení.)

Toto jsou některé z důvodů, které lze uvést.

Případová studie týkající se zápisů ze zasedání řídícího výboru

Níže představujeme případ, kdy zápisy ze zasedání řídícího výboru byly v reálném soudním procesu považovány za důležitý důkaz. Případ uvedený v následujícím citátu rozhodnutí se týká situace, kdy projekt vývoje systému selhal v průběhu, a bylo uznáno, že dodavatel porušil své povinnosti v rámci řízení projektu. Obsah zápisů ze zasedání měl v tomto případě velký význam v soudním procesu, protože ukazoval původní pochopení situace jak ze strany dodavatele, tak uživatele.

Dodavatel upozornil, že obsah zápisů ze zasedání řídícího výboru, na kterých je založeno uznání průběhu vývoje systému v tomto případě, byl upraven uživatelem a nemusí nutně odrážet skutečný stav práce. Nicméně, řídící výbor byl zřízen s cílem rozhodovat na úrovni vyššího managementu o vývoji systému, a zástupci obou stran, dodavatele i uživatele, kteří nesli odpovědnost za realizaci vývoje systému, se zúčastnili, aby provedli celkové hodnocení, sdíleli skutečný stav a problémy týkající se plánu a pokroku práce a rozhodli o důležitých otázkách. A bylo stanoveno, že dodavatel vytvoří zápis ze zasedání, který bude obsahovat hlavní body diskuse, do následujícího pracovního dne a zaregistruje jej do databáze zápisů ze zasedání, a tím zaznamená konečná rozhodnutí zasedání. Při schvalování zápisu ze zasedání obě strany, dodavatel i uživatel, plně uznávaly význam zaznamenávání práce pomocí zápisu ze zasedání a po diskusi o jeho obsahu a formulaci jej schválily jako dokument odrážející skutečný stav zasedání. Zvláště dodavatel, jako subjekt provádějící vývoj systému, by měl být dobře obeznámen s významem a metodou vytváření takových zápisů ze zasedání. Proto lze říci, že schválený zápis ze zasedání by měl být považován za dokument odrážející skutečný stav práce řídícího výboru a pokud nejsou uznány žádné zvláštní okolnosti, je vhodné uznat, že obsah uvedený v tomto zápisu shrnuje stav řídícího výboru k danému datu.

Verdikt tokijského vrchního soudu ze dne 26. září 2013 (Heisei 25)

Postoj soudu lze chápat tak, že pokud se jedná o zápis ze zasedání vytvořený na základě dohody mezi dodavatelem a uživatelem, lze očekávat, že bude mít určitou předpokládanou sílu jako “důkaz”. Jinými slovy, je třeba být opatrný, protože pokud je zápis ze zasedání příliš lehkovážně formulován, může se stát důkazem tak, jak je.

Konkrétní položky, které by měly být zaznamenány v zápisu z jednání

Co by mělo být dokumentováno v zápisu z jednání?

Zápis z jednání má důležitý význam jako důkaz v případě soudního sporu, ale také pro hladký průběh následných jednání mezi stranami, i když k soudnímu sporu nedojde. Takže, co konkrétně by mělo být dokumentováno a zaznamenáno v zápisu z jednání? Podívejme se na to podrobněji.

Položky, které by měly být zaznamenány z pohledu dodavatele

Dodavatel má v rámci projektu povinnost řídit projekt jako odborník na vývoj systémů. Podrobnější vysvětlení toho, co tato povinnost zahrnuje, naleznete v následujícím článku.

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

Vzhledem k této povinnosti by dodavatel měl zvláště zaznamenat:

  1. Fakt, že jednotlivé fáze vývoje byly dokončeny, a datum jejich dokončení
  2. Historii odpovědí na požadavky na změnu specifikací nebo přidání funkcí přijatých od uživatele
  3. Opatření, která byla přijata pro žádost o spolupráci v případě, že pokrok vývojových prací je zdržen kvůli vlastním okolnostem uživatele, a jejich průběh

Toto jsou jen některé příklady.

Co se týče bodu 3., doplňkové informace naleznete v následujícím článku, který se zabývá otázkami, které by dodavatel měl zvážit, pokud uživatel neprovádí přijetí. V tomto článku je vysvětleno, jak se může rozhodnutí soudu výrazně lišit v závislosti na tom, jak spolupracoval dodavatel při provádění přijetí uživatelem, a to na základě citací z reálných soudních rozhodnutí.

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

Položky, které by měly být zaznamenány z pohledu uživatele

Samozřejmě, uživatel také má určitou povinnost spolupracovat na vývoji systému, který bude používán v rámci jeho vlastní organizace. Celkový obsah této povinnosti je vysvětlen v následujícím článku.

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

  1. Historie toho, co bylo sděleno dodavateli z uživatelské strany, jako jsou požadované funkce, vzhled obrazovky atd.
  2. Historie různých problémů, které nastaly během procesu dodavatele (například náhlé odchody členů týmu nebo zpoždění v plánu vývojového procesu způsobené nedostatečným průzkumem ze strany dodavatele a jejich příčiny)

Co se týče bodu 2., obzvláště náchylné k neočekávaným problémům jsou situace, kdy se současně s odstraněním starého systému provádí vývoj nového systému. Při přechodu dat ze starého systému do nového jsou často problémy, ale podrobný výklad právních problémů spojených s těmito problémy naleznete v následujícím článku.

https://monolith.law/corporate/the-transition-from-the-oldsystem[ja]

Shrnutí

Výše uvedené jsou pokyny pro zaznamenávání jednání na pracovišti vývoje systémů z právního hlediska. Je důležité nejen praktické know-how, ale také prohlubování porozumění vztahům mezi tématy jako “právo”, “vývoj systémů” a “správa dokumentů”. Právě proto, že vývoj systémů zahrnuje mnoho lidí a organizací a snadno se rozvíjí do velkých obchodních transakcí, je důležitá prevence a řešení konfliktů s ním spojených. A z potřeby uchování důkazů z právního hlediska vyplývá, že existence “dokumentů”, které mohou být objektivně ověřeny kýmkoli, má velký význam.

Samozřejmě, úplná verbalizace všech interakcí a vývoje projektu je náročná a možná ani nepraktická. Nicméně, je důležité určit, co je z právního hlediska důležité, a tyto důležité záležitosti průběžně dokumentovat. Tento bod by měl být široce uznáván všemi lidmi zapojenými do podnikání, ať už jsou odborníky na právo nebo ne.

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:

Zpět na začátek