प्रणालीको निरीक्षणपछि समस्या पत्ता लागेमा समाधानका उपायहरू के हुन्?

सामान्यतया, प्रणाली विकासमा, आवश्यकताहरूको परिभाषा चरणमा निर्णय गरिएका सामग्रीहरू अनुसार प्रोग्रामको कार्यान्वयन अगाडि बढाइन्छ, र अन्ततः यो सुनिश्चित गर्न प्रयोगकर्ता र विक्रेता दुवैले पुष्टि गर्छन् कि यो निर्दिष्ट विवरण अनुसार तयार भएको छ कि छैन, र निरीक्षणको स्वीकृतिसँगै समाप्त हुन्छ।

तर, वास्तविकतामा, परीक्षण प्रक्रिया र निरीक्षणको स्वीकृतिमा पत्ता लगाउन नसकिने बगहरू वा त्रुटिहरू पछि सञ्चालन चरणमा देखा पर्न सक्छन्। एक पटक डेलिभरी स्वीकार गरिसकेपछि, जापानी कानुन अन्तर्गत के-कस्ता कानुनी उपायहरू अपनाउन सकिन्छ?

जापानमा परीक्षण प्रक्रिया पछि पनि बगहरू रहनु अस्वाभाविक होइन

प्राविधिक दृष्टिकोणबाट हेर्दा, विक्रेता पक्षको विभिन्न परीक्षण प्रक्रियाहरूको समाप्ति र प्रयोगकर्ता पक्षको निरीक्षणको सफलतापछि पनि विभिन्न बगहरू र समस्याहरू देखा पर्नु जापानमा कुनै अस्वाभाविक कुरा होइन। प्रयोगकर्ताले निरीक्षण प्रक्रियामा गर्ने काम सामान्यतया स्क्रिनमा देखिने इनपुट र आउटपुटको जाँचमा केन्द्रित हुन्छ। तर, आईटी प्रणालीहरू प्रायः प्रयोगकर्ता पक्षबाट देख्न सकिने स्क्रिनको बाहिरी रूपभन्दा बढी, पछाडिको डाटाबेस र विभिन्न गणना तथा नियन्त्रण गर्ने कार्यक्रमहरूको भागमा जटिल र सूक्ष्म संरचना राख्छन्। त्यसैले, प्रयोगकर्ता दृष्टिकोणबाट स्क्रिनमा देखिने इनपुट र आउटपुटको जाँचबाट जाँच गर्न सकिने कुरामा मूलतः सीमा हुन्छ। त्यसैले, जाँच प्रक्रियामा त्यसपछि सञ्चालन चरणमा हुन सक्ने सबै समस्याहरूको सम्भावनालाई व्यापक रूपमा परीक्षण गर्नु व्यावहारिक छैन।

उपरोक्त परिस्थितिहरू विकास कार्यभार लिने विक्रेता पक्षको दृष्टिकोणबाट हेर्दा पनि उस्तै हुन्छ। उदाहरणका लागि, कार्यान्वित कार्यक्रमको सामग्रीमा बगहरू वा समस्याहरू छैनन् भनेर पुष्टि गर्ने काम “परीक्षण प्रक्रिया” हो। तर परीक्षण प्रक्रियामा, साँच्चै सबै प्रकारका बगहरू र समस्याहरूको सम्भावनालाई पूर्ण रूपमा परीक्षण गर्न सकिन्छ कि भनेर भन्नु पर्दा, सधैं त्यस्तो हुँदैन। विकास गरिएको प्रणालीले जापानमा पूर्ण रूपमा व्यवसायमा प्रयोग गर्न थालिएपछि पनि, विक्रेता पक्षले अपेक्षा नगरेको अपरेसनहरू गरिन सक्छन्, वा ठूलो मात्रामा डाटा वास्तवमा दर्ता हुन थाल्न सक्छ, वा धेरै प्रयोगकर्ताहरूले एकै समयमा पहुँच गर्न थाल्न सक्छन्, र त्यस्तो अवस्थामा पनि बिना कुनै अवरोध प्रणालीलाई चलिरहनु पर्ने हुन्छ, जसका लागि वास्तवमा उत्कृष्ट प्राविधिक क्षमता आवश्यक पर्छ।

निरीक्षण र परीक्षण जस्ता चरणहरूमा सबै प्रकारका बगहरू र समस्याहरूलाई पूर्ण रूपमा पत्ता लगाउनु व्यावहारिक छैन, र वास्तवमा प्रयोग गर्न थालिएपछि विभिन्न समस्याहरू देखा पर्न सक्छन् भन्ने कुरा आईटी प्रणालीको विशेषता हो भन्ने कुरा बुझ्न आवश्यक छ।

सामान्यतया, ऋणको दायित्व पूरा भएको मानिन्छ

यस्ता समस्याहरू जापानमा वास्तवमा देखा परेमा, कसरी समाधान गर्ने भन्ने कुरा के हो त? हामी यसलाई कानूनी प्रक्रियाको आधारमा व्यवस्थित गर्नेछौं।

पहिलो कुरा, यदि विभिन्न बगहरू वा समस्याहरू देखा परेका छन् भने, प्रयोगकर्ताको पक्षबाट, उनीहरूले अहिलेसम्म कामको लागि जिम्मेवार रहेको विक्रेतालाई कुनै न कुनै रूपमा जिम्मेवार ठहर्याउन चाहन्छन्। तर, सामान्यतया, यदि डेलिभरी पूरा भइसकेको छ र निरीक्षणमा पनि उत्तीर्ण भइसकेको छ भने, जापानमा ऋणको उल्लंघनको आधारमा जिम्मेवारी ठहर्याउन कठिन हुन्छ।

सर्वप्रथम, जापानमा प्रणाली विकासमा हुने सम्झौताहरूमा, कुनै विशेष व्यवस्था नभएको खण्डमा, कार्यक्रमको कार्यान्वयन सम्बन्धी नियमहरू जापानी नागरिक कानुनको ठेक्का सम्झौताका नियमहरूमा आधारित हुन्छन्। ठेक्का सम्झौता के हो भन्ने बारेमा विस्तृत जानकारी तलको लेखमा दिइएको छ।

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

र ठेक्का सम्झौतामा, “कामको पूरा” हुनु नै ऋणको कार्यान्वयनको शर्त हो। यहाँ भनिएको “कामको पूरा” ले के अर्थ राख्छ भन्ने बारेमा विस्तृत व्याख्या तलको लेखमा दिइएको छ।

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

यहाँ, जापानमा भएका विगतका अदालतका उदाहरणहरूमा, ठेक्का सम्झौतामा “कामको पूरा” भन्नाले प्रणाली विकासको सन्दर्भमा सम्पूर्ण विकास प्रक्रियाको समाप्ति भन्ने अर्थ राख्छ भन्ने कुरा व्याख्या गरिएको छ। र, विकास प्रक्रिया पूरा भएपछि देखिने बग वा समस्याहरू ठेक्का सम्झौतामा रहेको दोष जिम्मेवारीको विषय बन्ने कुरा पनि व्याख्या गरिएको छ।

समग्रमा, एक पटक डेलिभरी स्वीकार गरिसकेपछि र निरीक्षणमा उत्तीर्ण भइसकेपछि, ऋणको दायित्व पूरा भएको मानिन्छ। त्यसपछि गुणस्तरको ग्यारेन्टीको समस्या, अर्थात् दोष जिम्मेवारीको खोजीको सम्भाव्यता सामान्यतया समस्या बन्ने गर्छ।

जापानी कानुन अन्तर्गत 瑕疵担保責任 (कस्सी तानपो सेकिनिन) मा आधारित जिम्मेवारीको माग गर्ने प्रक्रिया

जापानमा 瑕疵担保責任 (कस्सी तानपो सेकिनिन) मा आधारित भएर विक्रेतासँग कसरी र के क्रममा छलफल गर्नुपर्छ भन्ने कुरा बुझ्न आवश्यक छ। तलका बुँदाहरूमा यसबारे जानकारी गरौं।

पहिले बग वा त्रुटिको गम्भीरता र गहिराईको स्तरको पुष्टि गर्नुहोस्

बग वा त्रुटि पछि पत्ता लागेमा, र यो कानुनी रूपमा “瑕疵” (कस्सी) हो भनेर कुनै प्रकारको क्षतिपूर्ति माग गर्दा, बग वा त्रुटिको गम्भीरता महत्त्वपूर्ण हुन्छ। कानुनी रूपमा 瑕疵 (कस्सी) को समस्या निम्न तीन अवस्थाहरूमा विभाजित हुन्छ:

1. बग वा त्रुटि भए तापनि, यो सामान्य मात्रामा छ र कानुनी रूपमा “瑕疵” (कस्सी) मान्न सकिँदैन।
2. कानुनी रूपमा “瑕疵” (कस्सी) मा पर्छ, तर सम्झौताको उद्देश्य पूरा गर्न सम्भव छ।
3. कानुनी रूपमा “瑕疵” (कस्सी) मा पर्छ र सम्झौताको उद्देश्य पूरा गर्न सम्भव छैन।

瑕疵担保責任 (कस्सी तानपो सेकिनिन) मा आधारित जिम्मेवारीको माग गर्ने सम्भावनालाई 1 र 2 को बीचको सीमा छुट्याउँछ, र 瑕疵担保責任 (कस्सी तानपो सेकिनिन) मा आधारित सम्झौताको रद्द गर्ने सम्भावनालाई 2 र 3 को बीचको सीमा छुट्याउँछ।

धारा 634

1. कामको उद्देश्यमा 瑕疵 (कस्सी) भएको बेला, अर्डरकर्ताले ठेकेदारलाई उपयुक्त समयसीमा तोकेर, उक्त 瑕疵 (कस्सी) को मर्मतको माग गर्न सक्छ। तर, 瑕疵 (कस्सी) महत्त्वपूर्ण नभएको अवस्थामा, मर्मतमा अत्यधिक खर्च लाग्ने भएमा, यो सीमा लागू हुँदैन।

2. अर्डरकर्ताले 瑕疵 (कस्सी) को मर्मतको सट्टा, वा मर्मतसँगै, क्षतिपूर्ति माग गर्न सक्छ। यस अवस्थामा, धारा 533 को प्रावधान लागू हुन्छ।

धारा 635

कामको उद्देश्यमा 瑕疵 (कस्सी) भएको र त्यसका कारण सम्झौताको उद्देश्य पूरा गर्न नसकिने अवस्थामा, अर्डरकर्ताले सम्झौता रद्द गर्न सक्छ। तर, भवन वा अन्य जमिनको संरचनाहरूको हकमा, यो सीमा लागू हुँदैन।

यस प्रकारका “瑕疵” (कस्सी) को चरणबद्ध भिन्नताबारे थप जानकारीका लागि, तलको लेखमा विस्तृत व्याख्या गरिएको छ।

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

अर्को, विक्रेतासँग माग गर्नुपर्ने कुराहरू स्पष्ट गर्नुहोस्

अर्को चरणमा, प्रतिपक्षसँग के माग गर्नुपर्ने हो भन्ने कुरा स्पष्ट गर्नु आवश्यक छ। यदि सम्झौता रद्द गर्न चाहनुहुन्छ भने, यो 瑕疵 (कस्सी) हो भनेर मात्र प्रमाणित गर्नु पर्याप्त हुँदैन, यो “सम्झौताको उद्देश्य पूरा गर्न नसकिने” स्तरको हुनुपर्छ। यहाँ “उद्देश्य” को निर्णयमा, प्रणाली विकास परियोजना सुरु हुँदा भएका बैठकका कार्यवृत्तहरू वा विशिष्टताहरूको विवरण महत्त्वपूर्ण प्रमाण मानिन्छ। परियोजना समाप्त भएपछि पनि बग वा त्रुटि पछि पत्ता लाग्न सक्ने सम्भावना भएकाले, विकास परियोजना समाप्त भएपछि पनि विभिन्न कागजातहरूको संरक्षणमा ध्यान दिनुपर्छ।

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

रद्द बाहेक, 瑕疵担保責任 (कस्सी तानपो सेकिनिन) को रूपमा माग गर्न सकिने अन्य कुराहरूमा, क्षतिपूर्ति माग वा 瑕疵 (कस्सी) मर्मतको माग समावेश छन्।

अन्य ध्यान दिनुपर्ने कुराहरू

जापानी कानूनी कार्यहरू गर्दा, जस्तै कि सम्झौताको रद्द, विधि र तरिकामा ध्यान दिनुहोस्

यदि जापानी कानूनी प्रणाली अन्तर्गत दोषपूर्ण जिम्मेवारीको रूपमा सम्झौताको रद्द गर्ने कुरा छ भने, रद्द गर्नका लागि आवश्यक कानूनी प्रक्रियाको ज्ञान पनि हासिल गर्नु आवश्यक छ। सम्झौता रद्दको प्रभाव, वैध इच्छा व्यक्त गर्ने तरिका, र पछि समस्यामा नपर्ने गरी सूचना दिने तरिकाहरूको बारेमा विस्तृत जानकारी निम्न लेखमा दिइएको छ।

https://monolith.law/corporate/cancellation-of-contracts-in-system-development[ja]

विवादको सट्टा, वार्ताको माध्यमबाट समाधान खोज्नु उपयुक्त

यस प्रकारका कानूनी विषयवस्तुहरू, अनिवार्य रूपमा अदालतमा मात्र अर्थपूर्ण हुँदैनन्। जापानमा अदालतद्वारा विवाद समाधान दुवै पक्षका लागि धेरै बोझिलो हुन सक्छ। त्यसैले, अदालतमा पुग्नुअघि नै वार्ताको चरणमा पनि यी ज्ञानहरूलाई उपयोग गर्न सकिन्छ। अदालत बाहेकका वार्तामा कानूनी ज्ञानको महत्त्वको बारेमा विस्तृत जानकारी निम्न लेखमा दिइएको छ।

https://monolith.law/corporate/disputes-related-to-system-development[ja]

बग वा त्रुटिहरू र कार्यक्षमताको अभावलाई अलग्गै विचार गर्नु पर्छ

यदि कार्यान्वयन गरिएका कार्यहरू वा विशिष्टताहरूमा बग वा त्रुटिहरू छन् भने र आवश्यक कार्यहरू नै नभएका छन् भने, यी दुई स्थितिहरूको बहस फरक हुन्छ। यदि आवश्यक कार्यहरू पूर्ण रूपमा उपलब्ध छैनन् भने, जापानी ठेक्का सम्झौतामा “कामको पूर्णता” मान्यता प्राप्त नहुन सक्छ र दायित्वको कार्यान्वयन मान्यता प्राप्त नहुन सक्छ।

यद्यपि, आवश्यक कार्यहरू वा विशिष्टताहरू उपलब्ध नभएको भए पनि, यदि आवश्यक जानकारीको परिभाषा गर्ने चरणमा प्रयोगकर्ता पक्षले उचित जानकारी प्रदान नगरेको परिणाम हो भने, यसलाई सम्झौताको अंशको रूपमा हेर्नु नै अनुपयुक्त ठहरिन सक्छ।

सारांश

प्रोजेक्टको प्रक्रियामा उत्पन्न हुने समस्याहरू कहिलेकाहीं प्रोजेक्टको प्रगतिमा नै पत्ता लाग्न सक्छन् भने कहिलेकाहीं सञ्चालन चरणमा वा पछि मात्र पत्ता लाग्न सक्छन्। सबै प्रक्रिया सफलतापूर्वक सम्पन्न भए पनि सधैं निश्चिन्त हुन नसकिने भन्ने प्रणाली विकास प्रोजेक्टको विशेषता “瑕疵担保責任” (कासितानपो सेकिनिन) भन्ने जापानी प्रणालीमा झल्किन्छ। प्रणाली विकास प्रोजेक्टको समाप्तिपछि पनि ध्यानमा राखेर कागजात व्यवस्थापनलाई कडाइका साथ पालना गर्नु र यस प्रकारको सम्पूर्ण प्रक्रियालाई बुझ्नु महत्त्वपूर्ण मानिन्छ।