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

MONOLITH LAW MAGAZINE

General Corporate

Kontrolní body smlouvy v případě, že se systémový vývoj provádí formou polovičního pověření

General Corporate

Kontrolní body smlouvy v případě, že se systémový vývoj provádí formou polovičního pověření

V současné době se v naší zemi rychle zvyšuje využití IT v oblasti života občanů a socioekonomických aktivit, což je důsledkem prudkého zlepšení výkonnosti počítačů a šíření internetu. Proto se sociální dopady zastavení nebo snížení funkčnosti služeb způsobené poruchami informačních systémů každý den zvyšují a zlepšení spolehlivosti a bezpečnosti systémů se stává velkou výzvou.

Na druhou stranu, celkový počet smluv o vývoji IT systémů se často stává nejasným, protože nebyl předpokládán v době legislativy. To znamená, že je výzvou zviditelnit obchodní transakce založené na těsné komunikaci mezi objednatelem (uživatelem) a dodavatelem (výrobcem), a také zřetelně definovat rozdělení rolí a vztahy odpovědnosti.

Kromě toho, protože informační systémy jsou nyní konstruovány kombinací různých prvků, začaly zahrnovat rizika spojená s kombinacemi, které dříve neexistovaly.

Pro zlepšení spolehlivosti a bezpečnosti těchto informačních systémů byly v Ministerstvu hospodářství, obchodu a průmyslu zveřejněny pokyny, v nichž jsou prezentovány modelové smlouvy pro vývoj systémů, které jsou doplněny podrobnými vysvětleními.

V tomto článku budeme diskutovat o kontrolních bodech smlouvy pro případ uzavření smlouvy typu “quasi-delegation” v oblasti vývoje IT systémů, přičemž budeme citovat ustanovení modelové smlouvy Ministerstva hospodářství, obchodu a průmyslu.

Vývoj systémů znamená vytváření podnikových systémů pomocí IT technologií.

Co je systémový vývoj a smlouva o kvazipověření

Co je smlouva o kvazipověření

Smlouva o kvazipověření je definována v občanském zákoníku formou aplikace ustanovení o smlouvě o pověření.

Oddíl 10 Pověření
Článek 643 Pověření vzniká, když jedna strana pověří druhou stranu provést právní úkon a druhá strana toto pověření přijme.
Článek 656 Ustanovení tohoto oddílu se analogicky použijí na pověření k provedení jiných než právních úkonů.

Smlouva o kvazipověření je smlouva, jejímž cílem je, aby jedna strana prováděla úkony na pokyn druhé strany. Příjemce pověření je povinen plnit své úkoly s péčí dobrého správce (povinnost péče dobrého správce). Povinnost péče dobrého správce znamená jednoduše “dělat maximum”.

Rozdíl oproti smlouvě o dílo

V případě smlouvy o kvazipověření, jak bylo uvedeno výše, příjemce pověření je povinen plnit povinnost péče dobrého správce, ale na rozdíl od smlouvy o dílo, není povinen dokončit práci. Proto, pokud neexistuje konkrétní cíl, příjemce pověření není povinen nést odpovědnost za vady. Nicméně, protože je povinen plnit povinnost péče dobrého správce, v případě zanedbání povinnosti nebo závažné nedbalosti může nést odpovědnost za škodu na základě nesplnění závazku nebo může být smlouva zrušena.

Jak bylo uvedeno výše, v případě smlouvy o kvazipověření není povinností dokončit práci. Na druhé straně, v případě smlouvy o dílo je povinností dokončit práci. V následujícím článku je vysvětleno, co se stane, když je smlouva o systémovém vývoji uzavřena jako smlouva o dílo.

https://monolith.law/corporate/checkpoints-for-contracts-of-system-development[ja]

Modelové ustanovení typu quasi-mandát a kontrolní body

Podpora při vytváření definic požadavků

(Provádění podpory při vytváření definic požadavků)
Článek X: Druhá strana, na základě uzavření individuální smlouvy stanovené v článku X, poskytne služby podpory při vytváření definic požadavků (dále jen “podpora při vytváření definic požadavků”), které jsou součástí této práce, na základě konceptu informačního systému, plánu systémového vývoje atd., které vytvořila první strana.

2. Druhá strana, na základě svých odborných znalostí a zkušeností v oblasti informačních technologií, poskytne podporu v podobě průzkumu, analýzy, organizace, návrhů a poradenství, aby se zajistilo, že práce první strany probíhá hladce a správně.

Definice požadavků je proces, při kterém se shrnují specifikace požadavků systému (funkce, které by měl software realizovat), který uživatel chce vytvořit, a je to práce, která závisí velmi na obsahu práce uživatele. V této části předpokládáme, že definici požadavků provádí uživatel a dodavatel ji podporuje ve formě smlouvy o částečném zastoupení.
Avšak, i když je to smlouva o částečném zastoupení, dodavatel není zcela zbaven odpovědnosti. Jako zástupce má povinnost pečovat a pokud tuto povinnost zanedbá a podpora při vytváření definic požadavků není provedena správně, bude nesplnění povinnosti považováno za porušení povinnosti pečovat.

(Uzavření individuální smlouvy týkající se podpory při vytváření definic požadavků)
Článek X: První a druhá strana se dohodnou na obchodních podmínkách uvedených v článku X, paragraf X, týkajících se podpory při vytváření definic požadavků, a uzavřou individuální smlouvu týkající se podpory při vytváření definic požadavků.

Rozsah podpory při vytváření definic požadavků je stanoven v individuální smlouvě podle podmínek uvedených v předchozím článku.

(Diskuse o definici požadavků)
Článek X: První strana uspořádá konzultace o vytváření definic požadavků (dále jen “diskuse o definici požadavků”) v četnosti, kterou považuje za nezbytnou pro objasnění nebo potvrzení záležitostí potřebných pro vytvoření definic požadavků, a druhá strana se zúčastní těchto diskusí a poskytne podporu při vytváření definic požadavků.

2. Druhá strana může také uspořádat diskuse o definici požadavků, pokud to považuje za nezbytné pro poskytování podpory při vytváření definic požadavků, a první strana se zúčastní těchto diskusí.

Pro vytvoření definice požadavků, která definuje požadavky na práci a funkční a nefunkční požadavky na systém, je nutná spolupráce mezi uživatelským oddělením a oddělením informačních systémů a dodavatelem. Vzhledem k tomu, že tento proces je částečně delegován, první odstavec stanovuje, že uživatel je hlavním organizátorem a dodavatel se zúčastní jako podporovatel. Všechny záležitosti potřebné pro vytvoření definice požadavků, jako je objasnění nebo potvrzení obsahu, se řeší na diskusích o definici požadavků a uživatel a dodavatel jsou vázáni výsledky těchto diskusí.

Druhý odstavec stanovuje, že dodavatel může také uspořádat diskuse o definici požadavků, pokud to považuje za nezbytné pro poskytování podpory při vytváření definic požadavků.

(Potvrzení definice požadavků)
Článek X: Pokud první strana dokončí vytváření definice požadavků, první a druhá strana provedou kontrolu, zda definice požadavků odpovídá rozhodnutím přijatým na diskusi o definici požadavků stanovené v předchozím článku, během doby stanovené v individuální smlouvě (dále jen “doba kontroly definice požadavků”), a jako důkaz potvrzení shody obě strany podepíší a opečetí definici požadavků. Pokud však kontrola ukáže, že definice požadavků neodpovídá rozhodnutím přijatým na diskusi o definici požadavků, první strana vytvoří revidovanou verzi do doby stanovené po konzultaci a první a druhá strana provedou znovu výše uvedenou kontrolu a potvrzení.

2. Definice požadavků je považována za potvrzenou potvrzením obou stran podle předchozího odstavce.

3. Pokud je třeba změnit podmínky individuální smlouvy, jako je doba práce nebo poplatek za zakázku, v důsledku úprav podle prvního odstavce, provede se to podle postupu stanoveného v článku X.

Definice požadavků je fáze, kdy se potvrzují požadavky potřebné pro provádění systémového návrhu atd., po přijetí předběžného odhadu od dodavatele. Pokud zůstanou požadavky nejasné, bude pro dodavatele obtížné provést přesný odhad a mohou vzniknout problémy v následující fázi vývoje. Tento článek stanovuje postup pro potvrzení definice požadavků, která je základem pro následující vývojové práce, tím, že ji uživatel a dodavatel potvrdí a vedoucí pracovníci ji podepíší a opečetí. Pokud je při kontrole definice požadavků zjištěno, že je třeba ji upravit, první odstavec stanovuje postup pro tento případ.

Druhý odstavec jasně stanovuje, že definice požadavků je potvrzena potvrzením obou stran.
Třetí odstavec stanovuje, že pokud je třeba změnit podmínky individuální smlouvy, například pokud se zvýší pracovní zátěž dodavatele nebo je třeba prodloužit časový plán v důsledku úpravy definice požadavků a opětovné kontroly podle prvního odstavce, měly by se provést potřebné změny.

(Ukončení práce a potvrzení)
Článek X: Druhá strana vytvoří zprávu o ukončení práce do X dnů po potvrzení definice požadavků podle předchozího článku a předloží ji první straně.

2. První strana provede kontrolu zprávy o ukončení práce během doby stanovené v individuální smlouvě (dále jen “doba kontroly ukončení podpory při vytváření definic požadavků”).

3. Pokud první strana nemá žádné pochybnosti o obsahu zprávy o ukončení práce, podepíše a opečetí potvrzení o ukončení práce a předá ho druhé straně, čímž potvrdí ukončení podpory při vytváření definic požadavků.

4. Pokud první strana nevyjádří nesouhlas s konkrétním důvodem písemně během doby kontroly ukončení podpory při vytváření definic požadavků, ukončení práce se považuje za potvrzené po uplynutí doby kontroly ukončení podpory při vytváření definic požadavků.

Vzhledem k tomu, že tento proces je částečně delegován, tento článek stanovuje postup pro kontrolu, zda dodavatel řádně prováděl podpůrné práce na základě povinnosti pečovat, pomocí zprávy o ukončení práce, která zaznamenává obsah práce.
První odstavec stanovuje povinnost předložit zprávu o ukončení práce.
Druhý odstavec jasně stanovuje dobu kontroly zprávy, aby se zabránilo prodloužení kontroly zprávy.
Třetí odstavec stanovuje, že ukončení podpory při vytváření definic požadavků je potvrzeno podepsáním a opečetěním potvrzení o ukončení práce uživatelem.
Čtvrtý odstavec stanovuje předpokládané potvrzení ukončení, pokud uživatel nevyjádří nesouhlas písemně během doby kontroly ukončení podpory při vytváření definic požadavků. Tato ustanovení berou v úvahu skutečnost, že pokud uživatel z nějakého důvodu neprovede potvrzení včas, může to způsobit zpoždění v následujících pracích, nebo může začít následující práce bez jasného potvrzení, což by mohlo způsobit nejasnosti v odpovědnosti mezi uživatelem a dodavatelem.

Vytváření externích designových dokumentů

Definování požadavků je proces, který shrnuje specifikace systému (funkce, které by měl software realizovat), který uživatel chce vytvořit, a je silně závislý na obsahu práce uživatele.

(Provádění podpory při vytváření externích designových dokumentů)
Článek X: Druhá strana poskytne služby podporující vytváření externích designových dokumentů (dále jen “podpora při vytváření externích designových dokumentů”) pro tuto práci na základě uzavření individuální smlouvy stanovené v článku X.

2. Druhá strana bude na základě svých odborných znalostí a zkušeností v oblasti informačních technologií provádět podpůrné činnosti, jako je výzkum, analýza, organizace, návrhy a poradenství, aby se zajistilo, že práce první strany proběhne hladce a správně.

Vytváření externích designových dokumentů je proces, který stanovuje použití částí souvisejících s rozhraním, jako jsou obrazovky a formuláře. Externí designové dokumenty by měly obsahovat veškeré informace, které jsou potřebné pro vývojáře k vytvoření programu. Externí designové dokumenty obsahují podrobné informace o použití formulářů, ale změny požadavků mohou provést pouze uživatelé, kteří určují obsah práce.
Tento článek předpokládá, že uživatelé jsou odpovědní za dokončení externích designových dokumentů a že dodavatelé podporují dokončení externích designových dokumentů jako příjemci v rámci smlouvy o zastoupení.
Avšak, i když je to smlouva o zastoupení, dodavatel není zproštěn veškeré odpovědnosti a má povinnost péče jako správce. Proto, pokud výsledkem nedodržení této povinnosti péče není řádná podpora při vytváření externích designových dokumentů, může být dodavatel odpovědný za nesplnění povinnosti.

(Uzavření individuální smlouvy týkající se podpory při vytváření externích designových dokumentů)
Článek X: První a druhá strana se dohodnou na obchodních podmínkách uvedených v článku 4, odstavec 1, týkajících se podpory při vytváření externích designových dokumentů a uzavřou individuální smlouvu týkající se podpory při vytváření externích designových dokumentů.

Rozsah podpory při vytváření externích designových dokumentů je stanoven v individuální smlouvě.

(Diskuse o externím designu)
Článek X: První strana uspořádá diskuse o externím designu (dále jen “diskuse o externím designu”) v frekvenci, kterou považuje za nezbytnou pro objasnění nebo potvrzení záležitostí potřebných pro vytvoření externích designových dokumentů, a druhá strana se zúčastní těchto diskusí a provádí podporu při vytváření externích designových dokumentů.

2. Druhá strana může také uspořádat diskuse o externím designu, pokud to považuje za nezbytné pro provádění podpory při vytváření externích designových dokumentů, a první strana se zúčastní těchto diskusí.

3. Pokud první strana chce změnit obsah definice požadavků na základě diskusí o externím designu a je třeba změnit podmínky individuální smlouvy, jako je doba trvání práce a poplatky, postupují podle článku X (změna této smlouvy a individuální smlouvy).

Pro vytvoření externích designových dokumentů, které určují rozhraní, jako jsou obrazovky a formuláře, je nezbytná spolupráce mezi uživatelem a dodavatelem.
Vzhledem k tomu, že tento proces je založen na smlouvě o zastoupení, první odstavec stanovuje, že hlavním organizátorem je uživatel a dodavatel se účastní jako podporovatel. Všechny záležitosti potřebné pro vytvoření externích designových dokumentů, jako je objasnění nebo potvrzení, se provádějí na diskusích o externím designu a dodavatel a uživatel jsou vázáni výsledky těchto diskusí.
Druhý odstavec stanovuje, že dodavatel může také uspořádat diskuse o externím designu, pokud to považuje za nezbytné pro provádění podpory při vytváření externích designových dokumentů.
Třetí odstavec stanovuje, že pokud uživatel chce změnit obsah definice požadavků na základě diskusí o externím designu a je třeba změnit podmínky individuální smlouvy, postupují podle postupu pro změnu této smlouvy a individuální smlouvy.

(Potvrzení externích designových dokumentů)
Článek X: Pokud první strana dokončí vytvoření externích designových dokumentů, první a druhá strana provedou kontrolu, zda externí designové dokumenty odpovídají definici požadavků potvrzené podle článku X a rozhodnutím diskuse o externím designu stanovené v předchozím článku, během období stanoveného v individuální smlouvě (dále jen “období kontroly externích designových dokumentů”), a jako důkaz potvrzení shody, vedoucí obou stran podepíší a opečetí externí designové dokumenty. Pokud však kontrola odhalí části, které neodpovídají definici požadavků potvrzené podle článku X a rozhodnutí diskuse o externím designu, první strana vytvoří opravenou verzi do dohodnutého termínu a první a druhá strana znovu provedou výše uvedenou kontrolu a potvrzení.

2. Externí designové dokumenty jsou považovány za potvrzené potvrzením obou stran podle předchozího odstavce.

3. Pokud je třeba změnit podmínky individuální smlouvy, jako je doba trvání práce a poplatky, v důsledku oprav podle odstavce 1, postupují podle článku X (změna této smlouvy a individuální smlouvy).

Tento článek stanovuje postup pro potvrzení externích designových dokumentů vytvořených uživatelem prostřednictvím kontroly uživatelem a dodavatelem a podepsání a opečetění vedoucími obou stran.
Protože kontrola potvrzení externích designových dokumentů může vyžadovat opravy, první odstavec stanovuje postup pro tyto případy.

Druhý odstavec jasně stanovuje, že externí designové dokumenty jsou potvrzeny potvrzením obou stran.
Třetí odstavec stanovuje, že pokud je třeba změnit podmínky individuální smlouvy, jako je doba trvání práce a poplatky, v důsledku oprav podle prvního odstavce, postupují podle postupu pro změnu této smlouvy a individuální smlouvy.

(Ukončení práce a potvrzení)
Článek X: Druhá strana vytvoří zprávu o ukončení práce do X dnů po potvrzení externích designových dokumentů podle předchozího článku a předloží ji první straně.

2. První strana provede kontrolu zprávy o ukončení práce během období stanoveného v individuální smlouvě (dále jen “období kontroly ukončení podpory při vytváření externích designových dokumentů”).

3. Pokud první strana nemá žádné námitky k obsahu zprávy o ukončení práce, podepíše a opečetí potvrzení o ukončení práce a předá ho druhé straně, čímž potvrdí ukončení podpory při vytváření externích designových dokumentů.

4. Pokud první strana nevyjádří námitky proti zprávě o ukončení práce písemně s konkrétním důvodem během období kontroly ukončení podpory při vytváření externích designových dokumentů, je považována za potvrzení ukončení práce po uplynutí období kontroly ukončení podpory při vytváření externích designových dokumentů.

Vzhledem k tomu, že tento proces je založen na smlouvě o zastoupení, tento článek stanovuje postup pro kontrolu, zda dodavatel řádně prováděl podpůrné činnosti na základě povinnosti péče, pomocí zprávy o ukončení práce, která zaznamenává obsah práce.
Druhý odstavec jasně stanovuje období kontroly, aby se zabránilo prodloužení kontroly zprávy.
Třetí odstavec stanovuje, že potvrzení o ukončení práce je podepsáno a opečetěno uživatelem, čímž se potvrzuje ukončení podpory při vytváření externích designových dokumentů.
Čtvrtý odstavec stanovuje předpokládané potvrzení ukončení, pokud uživatel nevyjádří námitky proti zprávě o ukončení práce písemně s konkrétním důvodem během období kontroly ukončení podpory při vytváření externích designových dokumentů. Tato ustanovení berou v úvahu skutečnost, že pokud uživatel z nějakého důvodu neprovede řádnou kontrolu včas, může to způsobit zpoždění v následující práci nebo může začít následující práce bez jasného potvrzení, což by mohlo způsobit nejasnosti v odpovědnosti mezi uživatelem a dodavatelem.

Služby vývoje softwaru

Po fázi základního návrhu, která je definována jako proces vnějšího návrhu systému, následuje fáze detailního návrhu, která je definována jako proces vnitřního návrhu systému. V procesu vnitřního návrhu systému je obvyklé, že cíle a specifikace vývoje jsou definovány v předchozích fázích práce, a proto je v modelové smlouvě ministerstva průmyslu a obchodu (japonské Ministerstvo průmyslu a obchodu) tento proces definován jako kontraktový. Detaily jsou vysvětleny v následujícím článku.

https://monolith.law/corporate/checkpoints-for-contracts-of-system-development[ja]

Podpora přípravy a přechodu softwaru

(Realizace podpory přípravy a přechodu softwaru)
Článek X: Druhá strana, po uzavření individuální smlouvy stanovené v článku, poskytne podporu potřebnou pro systémové testy, zavedení a přijetí podpory a provozní testy, které první strana provádí pro skutečné provozování tohoto softwaru (dále jen “podpora přípravy a přechodu softwaru”).

2. Druhá strana, na základě odborných znalostí a zkušeností v oblasti zpracování informací, poskytne podporu s péčí dobrého správce, aby se práce první strany prováděla hladce a efektivně.

V tomto článku a následujících se stanovují ustanovení pro přípravu a přechod softwaru, které se provádí formou kvazimandátu. V fázi podpory přijetí a zavedení systému je obvyklé, že uživatel jedná aktivně, takže modelová smlouva Ministerstva hospodářství, obchodu a průmyslu stanovuje, že uživatel je hlavním subjektem a dodavatel ho podporuje v podobě kvazimandátu.
Druhý odstavec stanovuje, že vzhledem k tomu, že tento proces je kvazimandát, dodavatel má povinnost péče dobrého správce.

(Ukončení a ověření činnosti)
Článek 32: Druhá strana vytvoří zprávu o ukončení činnosti do X dnů po ukončení podpory přípravy a přechodu softwaru a předloží ji první straně.

2. První strana provede kontrolu zprávy o ukončení činnosti během doby stanovené v individuální smlouvě (dále jen “období kontroly ukončení podpory přípravy a přechodu softwaru”).

3. Pokud první strana nemá pochybnosti o obsahu zprávy o ukončení činnosti, podepíše a opečetí potvrzení o ukončení činnosti a předá ho druhé straně, čímž potvrdí ukončení podpory přípravy a přechodu softwaru.

4. Pokud první strana během období kontroly ukončení podpory přípravy a přechodu softwaru neprotestuje písemně s konkrétním důvodem, považuje se za potvrzení ukončení činnosti po uplynutí období kontroly ukončení podpory přípravy a přechodu softwaru.

Tento článek stanovuje postup pro ověření, zda dodavatel řádně prováděl podporu přípravy a přechodu softwaru na základě povinnosti péče dobrého správce jako kvazimandát.
Druhý odstavec stanovuje, že dodavatel musí uživateli předložit zprávu o ukončení činnosti do stanovené doby po ukončení činnosti.
Třetí odstavec stanovuje, že uživatel provede kontrolu zprávy o ukončení činnosti po stanovení období kontroly.
Čtvrtý odstavec stanovuje předpokládané potvrzení, pokud uživatel zanedbá potvrzení ukončení činnosti podle předchozích dvou odstavců.

Rozhodování o povaze smlouvy

Pro určení povahy smlouvy je třeba zvážit celkový kontext smlouvy a její cíl, zda je zaměřen na “poskytnutí dokončeného výsledku” nebo na to, aby dodavatel “rozumně plnil své povinnosti”. Hrubým ukazatelem je, zda byl obsah cílového produktu, který měl být dokončen, určen do určité míry konkrétně a zda byl projekt v tomto směru prováděn.
Podrobnější vysvětlení toho, na co bychom měli konkrétně zaměřit, naleznete v následujícím článku.

corporate/contract-and-timeandmaterialcontract
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.

Zpět na začátek