Систем хөгжүүлэлтэд гэрээг цуцлах арга зам

Систем хөгжүүлэх гэх мэт төслүүд нь урт хугацааны төслүүд байдаг учраас, төслийн явцад ‘дэлбэрэлт’ гэх мэт нөхцөл байдлууд гарах нь зүй ёсны хэрэг юм. Хэрэв хэрэглэгч ба үйлчилгээ үзүүлэгчид үргэлж хамтран ажиллах боломжтой бол зүгээр ч, гэрээг цуцлах гэх мэт арга хэмжээг авах шаардлагатай болох нөхцөл байдлыг ч мөн л харгалзан үзэх хэрэгтэй.

Энэхүү нийтлэлд бид систем хөгжүүлэлттэй холбоотойгоор ‘гэрээг цуцлах’ гэх хууль ёсны сонголтын талаар, мөн түүний чухал цэгүүдийг тайлбарлаж өгөх болно.

Систем хөгжүүлэлт ба цуцлах харилцаа

Иргэний хуульд заасан цуцлах гэж юу вэ?

Шинэчлэгдсэн Иргэний хуульд (民法, Japanese Civil Code) гэрээг цуцлахтай холбоотой ерөнхий заалтууд нь 540-аас 548 дугаар зүйл хүртэл заасан байдаг. Гэрээг цуцлах гэдэг нь өмнө нь байгуулагдсан гэрээний үйлчлэлийг дараа нь устгах гэсэн үг юм.

Хэрэв хэрэглэгч ба вендорын харилцааг авч үзвэл, гэрээ байгуулагдсанаар вендорт систем хөгжүүлэх үүрэг хүлээгдэж, хэрэглэгчид төлбөр төлөх үүрэг хүлээгддэг. Эдгээр нь эргэн тойронд нь харвал, талуудын “эрх” болон хувирдаг. Хэрэв энэ нь цуцлагдвал, талуудын хүлээсэн үүрэг, эзэмшсэн эрх нь гэрээ байгуулагдсанаас өмнөх байдалд буцах болно. Иймд, хэрэв өрсөлдөөнд ороогүй өр төлбөр байгаа ч, түүнийг гүйцэтгэх үүрэг алга болох нь тодорхой бөгөөд, гэрээ байгуулагдсанаас өмнөх байдалд суурилан, харилцан анхны байдалдаа буцаах үүрэг гарч ирнэ. Энэ нь “анхны байдалд нь сэргээх үүрэг” гэж нэрлэгддэг.

Түүнчлэн, хэрэв гэмтэл учирсан бол, тусад нь хохирлыг нөхөн төлөх боломжтой.

Систем хөгжүүлэлтийн практик ба цуцлах холбоо

Бизнесийн хууль зүйн практиктай холбоотой хүмүүсийн хувьд, гэрээг “цуцлах” гэдэг нь эхлээд цуцлах тушаалыг санаанд оруулдаг байж магадгүй. Гэхдээ хууль зүйн хувьд систем хөгжүүлэлтийн контекстэд хязгаарлагдсан болохоор, цуцлах үндэслэл бүрт хамаарах заалтууд нь хоёр өөр ангилалд хуваагддаг.

Өр төлбөрийн биелүүлэлтгүй байдал (гүйцэтгэл хойшлуулалт) үндэслэсэн тохиолдол

（Жишээ）Вендор нь анх тогтоосон хугацааг давсан ч, барааг нийлүүлэхээс татгалзсан тохиолдол гэх мэт

Иргэний хууль 541-р зүйл Талуудын нэг нь өөрийн өр төлбөрийг гүйцэтгэхгүй байгаа тохиолдолд, эсрэг тал нь зохих хугацааг тогтоон түүнийг гүйцэтгэхийг уриалж, тухайн хугацаанд гүйцэтгэл байхгүй бол, эсрэг тал нь гэрээг цуцлах эрхтэй болно.

Гүйцэтгэлийн гэрээний хэлбэрээр систем хөгжүүлэлт хийхэд “талуудын нэг” болох вендор нь шаардлага хангасан системийг бүтээж, нийлүүлэх үүрэгтэй байдаг. Иймд, хугацааг давсан ч вендор нь барааг нийлүүлэхгүй байгаа тохиолдол гэдэг нь, өөрөөр хэлбэл, вендор нь хугацаанд нь ажлыг гүйцэтгээгүй гэсэн үг юм. Тэгвэл “ажлын гүйцэтгэл” гэдэг нь систем хөгжүүлэлтийн үед яг юу гэсэн үг вэ? Энэ талаар дараах нийтлэлд дэлгэрэнгүй тайлбарласан байдаг.

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

Дутагдалтай баталгаажуулалтыг үндэслэсэн тохиолдол

（Жишээ）Вендороос нийлүүлсэн системд баг болон өгөгдлийн зөрчил олон байгаа бөгөөд дараа нь жинхэнэ ашиглалтад тохиромжгүй болох нь тодорхой болсон тохиолдол гэх мэт

Иргэний хууль 635-р зүйл Ажлын зорилтод объектод дутагдал байгаа бөгөөд ингэснээр гэрээгээр тогтоосон зорилгодоо хүрч чадахгүй байгаа үед, захиалагч нь гэрээг цуцлах эрхтэй болно. Гэхдээ барилга болон бусад газрын бүтээн байгуулалтад энэ нь хамаарахгүй.

Түүнчлэн, систем хөгжүүлэлтийн төслийн хувьд хараахан, вендор талын гэрээг цуцлах санал илэрхийлэх нь тийм ч түгээмэл биш. Ер нь хэрэглэгч талын вендор руу хандан гэрээг цуцлах тохиолдлуудыг төсөөлөх нь зүйтэй.

Дутагдалтай баталгаажуулалтын талаар дараах нийтлэлд дэлгэрэнгүй тайлбарласан байдаг.

https://monolith.law/corporate/defect-warranty-liability[ja]

Тайлбар тушаал ба холбогдох хууль эрх зүйн асуудлууд

Тайлбар тушаал гэдэг нь (ихэвчлэн хэрэглэгчээс нийлүүлэгчид хандан) гэрээг цуцлах тухай мэдэгдэх зорилготой бичиг баримтыг хэлнэ. Хуулийн заалтад дурьдвал, дараах заалтыг лавлах нь зүйтэй болно.

Иргэний хууль (民法) 541-р зүйл: Нэг тал нь өөрийн үүргийг гүйцэтгэхгүй байх үед, нөгөө тал нь зохих хугацааг тогтоон түүний гүйцэтгэлийг уриалан, тухайн хугацаанд гүйцэтгэл байхгүй бол, нөгөө тал нь гэрээг цуцлах эрхтэй.

Систем хөгжүүлэлттэй холбоотой баримт бичгийг харахад, тайлбар тушаалын онцлог нь төслийг амжилттай үргэлжлүүлэх зорилготой биш, харин төслийг дуусгах зорилготой байдаг гэдгийг онцлох боломжтой. Мөн энэ нь шууд хууль эрх зүйн үр дүнг бий болгохыг хүссэн бичиг баримт болох нь түүний том онцлог юм.

Гэхдээ дээрх заалтад зааснаар, гэрээ бичигтэй ялгаатай нь, (зарим нөхцөл бүрдсэн тохиолдолд) нэг талын саналыг илэрхийлэхэд л хангалттай байдаг. Хэрэглэгчээс нийлүүлэгчид тайлбар тушаалыг өргөн барьсан тохиолдолд, түүнийг хүлээн авсан нийлүүлэгч талын хариуцсан хүнд, “Тайлбар тушаалыг уншсан ч, яагаад гэрээг цуцалсаныг ойлгохгүй” гэсэн асуудал үүсэх нь төсөөлөгдөж байна. Тэгвэл хэрэглэгч тайлбар тушаалыг бэлтгэхдээ цуцалгааны шалтгааныг хэр хэмжээнд нарийвчлан заах ёстой вэ?

Татгалзах тушаалд татгалзах шалтгааныг бичих ёстой юу

Энэ асуудалд холбогдуулан өмнөх шүүхийн шийдвэрүүдийг харахад, татгалзах тушаалд татгалзах шалтгааныг тодорхой бичих нь заавал шаардлагатай биш гэж үздэг байна. Доор иш татан авсан шүүхийн шийдвэр нь хүргэгдсэн системд алдаа гарснаас хууль зүйн асуудал үүссэн тохиолдол юм. Хэрэглэгчийн талын татгалзах саналыг илэрхийлэхдээ алдааны талаар хэрхэн нарийвчлан мэдэж, тодорхой зааж өгөх шаардлагатай талаар асуудал үүссэн бөгөөд шүүх дараах байдлаар шийдвэрлэсэн байна.

Татгалзах санал илэрхийлэхдээ заавал татгалзах шалтгааныг зааж өгөх шаардлагагүй бөгөөд олон шалтгааныг нэг санал илэрхийлэлээр хийх боломжтой бөгөөд татгалзах санал илэрхийлэхдээ тодорхой шалтгааныг дурьдсан боловч, тухайн шалтгаанаас бусад шалтгаанаар татгалзахгүй гэдгийг тодорхой зааж өгөх зэрэг онцгой нөхцөл байдал бусад тохиолдолд, тухайн санал илэрхийлэл нь татгалзах үед байсан бүх шалтгааныг үндэслэн, гэрээг бүрэн дуусгах санал илэрхийлэл гэж үзэж болно.

Токио газрын шүүхийн 2004 оны (Хэйсэй 16) 12 сарын 22-ны шийдвэр

“Олон шалтгааныг нэг санал илэрхийлэлээр хийх боломжтой” гэдэг нь шүүхийн үзэгдэл юм. Өөрөөр хэлбэл, гэрээний талуудын татгалзах санаа байгаа эсэх нь чухал бөгөөд тодорхой шалтгааныг дэлгэрэнгүй зааж өгөх шаардлагагүй гэсэн үг юм.

Өөрөөр хэлбэл, хүргэгдсэн ч гүйцэтгэл дутуу байгаа эсэх, эсвэл ноцтой доголдолтой учраас алдааны баталгаажуулалтын асуудал байгаа эсэх гэх мэт зүйлсийг татгалзах санал илэрхийлэх шатанд асуудал болгох шаардлагагүй гэсэн үг юм. Эдгээр нарийн асуудлуудыг түр зуур анхаарахгүй байхад ч, эхлээд татгалзах санал илэрхийлсэн бол, дараа нь шүүхэд хандсан тохиолдолд ч, гүйцэтгэл хойшлуулалт, алдааны баталгаажуулалтын аль алинг нь татгалзах үндэслэл болгон маргааныг шийдвэрлэх боломжтой гэсэн үг юм.

• Гүйцэтгэл дутуу бүтээгдэхүүн хүргэгдсэн… → Үүрэг гүйцэтгэл хийгдээгүй
• Ноцтой доголдолтой бүтээгдэхүүн хүргэгдсэн… → Алдааны баталгаажуулалт

Шалтгааныг нарийвчлан тодорхойлоогүй ч, татгалзах санал илэрхийлэл нь хүчинтэй байдаг.

Гэхдээ татгалзах шалтгааныг нарийвчлан зааж татгалзах тушаалыг гаргасан нь, хэрэв вендортой харилцах явцад ойлголцох асуудал эсвэл ойлголтын зөрүү гарвал, тэдгээрийг тодорхой болгоход туслах давуу талтай. Мөн татгалзах тушаалыг хүлээн авах талд, тэдгээрийн шалтгааныг ойлгож байвал, дараа нь маргааныг шийдвэрлэх асуудал бага болно. Иймд боломжтой бол татгалзах шалтгааныг тодорхой бичих нь зүйтэй гэдэг нь үнэн юм.

Хэрхэн “Тохиромжтой хугацаа” гэдгийг тодорхойлох вэ?

Мөн нэг анхаарах зүйл бол Японы Иргэний хуулийн 541-р зүйлд зааснаар, “Тохиромжтой хугацаа” гэдэг нь хэр урт байх ёстой вэ гэдэг асуудал юм. Гэхдээ энэ асуудалд хэт нягт нямбай хандаж болохгүй гэж бодож байна. Учир нь, сануулга илгээх хүртэлх хугацаанд “Тохиромжтой хугацааг тодорхойлж” байгаагүй боловч, сануулгаас хойш тохиромжтой хугацаа өнгөрсөн бол, эцсийн дүндээ гэрээг цуцлах боломжтой болдог учраас юм. Мөн сануулга илгээх хүртэлх хугацаа “Тохиромжтой хугацаа” биш байсан ч, эцсийн дүндээ тохиромжтой хугацаа өнгөрсөн үед гэрээг цуцлах боломжтой болдог нь шүүхийн шийдвэрээр ч тодорхой болсон байдаг.

Систем хөгжүүлэлтийн төслийн хүрээнд, гүйцэтгэл хоцрох эсвэл баталгаажуулалтын алдаа гарч “шатамхай” болсон тохиолдолд, “Тохиромжтой хугацааг” тодорхойлж сануулга илгээсэн ч, ихэнхдээ хүргэлт эсвэл алдааг засварлах ажил дуусах нь бага. Эдгээр зүйлийг харгалзан үзэхэд, практик дээр “Тохиромжтой хугацаа” нь томоохон маргаан үүсгэх нь бага зэрэг байдаг гэж хэлж болно.

Систем хөгжүүлэлт дээр гүйцэтгэл хоцрохыг хэрхэн тодорхойлох талаар, өөр нийтлэлд тайлбарласан байдаг.

https://monolith.law/corporate/performance-delay-in-system-development[ja]

Тайлбарлах тушаалын мэдэгдлийг хэрхэн илгээх вэ?

Тайлбарлах тушаалын мэдэгдлийг ямар аргаар илгээх нь зүйтэй вэ гэдэг асуудалд, хэрэв мэдэгдэл хүрсэн бол (өөрөөр хэлбэл, дараа нь хүрсэн гэдгийг нотлох боломжтой байхаар) ямар ч аргаар илгээсэн бол асуудалгүй гэж үзэж болно.

Иймд, процедурын асуудлаар хэтэрхий санаа зовох шаардлагагүй. Тиймээс, ‘хэлсэн-хэлээгүй’ гэсэн асуудлаас зайлсхийхийн тулд, агуулгыг баталгаажуулсан шуудан зэргийг ашиглах нь эрхэмсэг байдаг. Гэхдээ, хэрэв тушаал хүрсэн гэдгийг баталгаажуулах боломжтой бол, факс эсвэл цахим шуудан зэрэг хялбар аргуудыг ашиглахад ч асуудалгүй. Гэсэн хэдий ч, шүүх хуралдаан зэрэгт орох үед ‘хүрсэн’ гэдгийг нотлох шаардлага гарч ирэх бөгөөд энэ үүднээс агуулгыг баталгаажуулсан шуудан нь аюулгүй гэж хэлж болно.

Дүгнэлт

Энэхүү нийтлэлд бид систем хөгжүүлэлт гэх контекст дагуу гэрээг цуцлах тухай зохицуулалтыг эрэхүүлсэн. Гэрээг цуцлах арга барилын практик мэдлэгийг ойлгоход нь туслахаас гадна, хууль ёсны үндэслэлтэй санал илэрхийлэх арга замыг ойлгож авбал, энэ нь илүү өргөн хэрэглээтэй мэдлэг болох биз ээ.