प्रणाली विकासको विशिष्टिकरणमा नभएका कार्यहरू कानूनी रूपमा कति सम्म कार्यान्वयन गर्नुपर्छ?

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

विक्रेताको कार्यमा विवेक आवश्यक हुन्छ
सिस्टम विकास जस्तो परियोजनासँग सम्बन्धित सम्झौता र यससँग सम्बन्धित विभिन्न कानूनी समस्याहरूको ठूलो विशेषता यो हो कि काम लिने विक्रेताले ठूलो विवेक राख्नुपर्छ।
सम्बन्धित लेख: सिस्टम विकासमा परियोजना व्यवस्थापन कर्तव्य के हो[ja]
तर, यहाँ भनिएको “विवेक” भनेको सिस्टम विकासको सम्पूर्ण प्रक्रियामा लागू हुने कुरा होइन। प्रत्येक प्रक्रियालाई विश्लेषण गरी, साना कार्यहरूमा विश्लेषण अघि बढाएपछि, साधारण कामको नजिकको काम धेरै हुन सक्छ। तर, सामान्यतया यस्ता समस्याहरूको विभाजन अघि, अर्थात् माथिल्लो प्रक्रियामा काम गर्दा, ठूलो विवेक बिना कामको सम्पन्नता कठिन हुन्छ। माथिल्लो प्रक्रिया जति बढी हुन्छ, सम्झौताको प्रकारको रूपमा उप-आदेशसँग राम्रोसँग मेल खाने कारण पनि यही हो।
सम्बन्धित लेख: सिस्टम विकासमा ठेक्का सम्झौता र उप-आदेश सम्झौताबीचको भिन्नता[ja]
विवेक, कडा विकास प्रक्रियामा पनि प्रदर्शन गर्नुपर्ने कुरा हो
तर, सिस्टम विकास गर्ने विक्रेतासँग ठूलो विवेक छ भने पनि, “बिना योजना” ग्राहकको मागलाई स्वीकार गर्नुले पछि आउने प्रक्रियामा ठूलो क्षति पुर्याउँछ। एउटा IT सिस्टम साना भागहरूको समूहबाट बनेको हुन्छ, जसले गर्दा बाहिरी रूपमा सानो परिवर्तन भए पनि, विकासकर्ताको दृष्टिकोणबाट ठूलो परिमाणको परिवर्तन आवश्यक हुन सक्छ। सिस्टम विकासको निर्दिष्ट परिवर्तनको सन्दर्भमा, परिवर्तनको व्यवस्थापनको तरिका कानूनी दृष्टिकोणबाट व्याख्या गरिएको लेख निम्न छ। यो लेख परिवर्तन व्यवस्थापनको तरिका व्याख्या गर्दछ, तर प्राविधिक दृष्टिकोणबाट निर्दिष्ट परिवर्तनले काममा कति ठूलो प्रभाव पार्छ भन्ने पनि छलफल गर्दछ।
सम्बन्धित लेख: कानूनी दृष्टिकोणबाट, सिस्टम विकासमा परिवर्तन व्यवस्थापन कसरी गर्ने[ja]
निर्दिष्टमा नअल्झिएर, विशेषज्ञको रूपमा के गर्नुपर्छ?
सिस्टम विकास परियोजनालाई सहज रूपमा अघि बढाउनका लागि, विकासको आवश्यकताहरू पहिले नै परिभाषित गरी, त्यसको आधारमा योजनाबद्ध रूपमा अघि बढ्नु महत्त्वपूर्ण छ। अर्कोतर्फ, पहिले नै परिभाषित आवश्यकताहरूको आधारमा मात्र भनिएको कुरा मात्र गरेर, सिस्टम विकासको विशेषज्ञको रूपमा पर्याप्त भूमिका निर्वाह गर्न नसकिने अवस्थामा पनि हुन्छ। यस्ता द्विविधामा, “निर्दिष्टमा देखाइएको छैन तर कार्यान्वयन गर्नुपर्ने कुरा के हो?” भन्ने समस्या स्पष्ट हुन्छ।
जापानी कानून अन्तर्गत कानूनी दायित्वहरू, विशिष्टता र सम्झौतापत्रको “उद्देश्य” अनुसार निर्धारण गरिन्छ
कार्यान्वयन गर्नुपर्ने कुराहरूको सामग्री, सम्झौतापत्र वा विशिष्टतामा उल्लेख नभए पनि, ती सम्झौतापत्र वा विशिष्टतामा उल्लिखित कुराहरूको “उद्देश्य” अर्थात् “कसरी र किन यस्तो निर्णय गरियो” भन्ने बुँदाबाट निर्धारण गरिन्छ। तल, केही न्यायिक उदाहरणहरू सहित यसलाई हेरौं।
जापानी कानूनी प्रणाली अन्तर्गत उल्लेख नभएको कारण कार्यान्वयनको दायित्व अस्वीकृत गरिएको न्यायिक निर्णय
तल उद्धृत गरिएको न्यायिक निर्णयमा, एक विक्रेता द्वारा विकास गरिएको प्रणालीको सन्दर्भमा, अस्थायी सञ्चालनसम्म पुगेपछि आवश्यक कार्यक्षमताको कमी भएको भन्दै सम्झौताको रद्दको माग गर्दै विवादमा परिणत भएको थियो। प्रयोगकर्ताले अभाव भएको दाबी गरेको “डेटा स्वचालित अद्यावधिक कार्यक्षमता” थियो, जुन यस प्रणालीको मुख्य बिक्री बिन्दु भएको दाबी गरिएको थियो, तर अदालतले यस कार्यान्वयनको दायित्वलाई स्वीकार गरेन।
उपरोक्त मान्यताका अनुसार, यस सम्झौतापत्र साथै आधारभूत डिजाइन दस्तावेज र विस्तृत डिजाइन दस्तावेजमा, ③ कार्यक्षमता यस प्रणालीको विकासको लक्ष्य भएको कुरा देखाउने कुनै उल्लेख छैन।
मुद्दाकर्ताले ③ कार्यक्षमता प्रतिवादीको मुद्दाकर्ताप्रति यस प्रणालीको मुख्य बिक्री बिन्दु भएको जस्ता दाबी गर्दै, सो कार्यक्षमताको आवश्यकतालाई जोड दिन्छ, तर यदि उक्त दाबी सही हो भने, त्यसको उल्लेख यस सम्झौतापत्र आदि मा स्पष्ट रूपमा गरिनुपर्ने थियो, र त्यो नभएको अवस्थामा, सो कार्यक्षमताको विकासमा सहमति भएको मान्न गाह्रो छ।
टोक्यो जिल्ला अदालत निर्णय, हेइसेई 21 (2009) फेब्रुअरी 18
उक्त निर्णयलाई सरल रूपमा निष्कर्ष मात्र निकालेर हेर्दा, “डिजाइन दस्तावेजमा उल्लेख नभएको कारण, नभएको कुरा बनाउन आवश्यक छैन” भन्ने कुरा पनि भन्न सकिन्छ। तर, अझ सही रूपमा भन्नुपर्दा, डिजाइन दस्तावेजमा उल्लेख छ कि छैन भन्ने औपचारिक तथ्यमा मात्र होइन, ती डिजाइन दस्तावेज र सम्झौतापत्रको उल्लेखको “उद्देश्य”लाई ध्यानमा राखेर निर्णय गरिएको हो। अर्थात्, “डिजाइन दस्तावेज वा सम्झौतापत्रमा उल्लेख नभएको कारणलाई विचार गर्दा, त्यस उल्लेखसँग मेल खाने सहमति पनि नभएको मान्नु उचित हुन्छ” भन्ने कुरा हो।
記載 नभए पनि कार्यान्वयनको दायित्वलाई स्वीकार गरिएको जापानी न्यायिक मिसाल
अर्कोतर्फ, सम्झौतापत्र वा विशिष्टतामा उल्लेख नभए पनि कार्यान्वयनको दायित्व स्वीकार गर्नुपर्ने भनेर ठहर गरिएको जापानी न्यायिक मिसाल पनि छ। तल उद्धृत गरिएको न्यायिक मिसालमा, औषधिको सेवन इतिहास व्यवस्थापन गर्नको लागि प्रणालीको विकासमा, पुरानो प्रणालीबाट नयाँ प्रणालीमा डाटा स्थानान्तरण गर्न नसक्दा, नयाँ प्रणालीको उपयोग गर्न नसकिएको र प्रयोगकर्ता पक्षले सम्झौताको रद्द गर्ने निर्णय गरेको घटना हो। तर, विक्रेता पक्षले डाटा स्थानान्तरणलाई आफ्नो कार्यक्षेत्र बाहिरको काम भनेर विवादमा उत्रिएको थियो।
नयाँ प्रणालीको विकासमा प्रायः पुरानो प्रणालीको हटाउने र डाटा स्थानान्तरण जस्ता कार्यहरू समावेश हुन्छन्। यस्ता कार्यहरूको महत्त्व र यससँग सम्बन्धित कानूनी समस्याहरूको बारेमा, तलको लेखमा पनि विस्तृत रूपमा व्याख्या गरिएको छ।
सम्बन्धित लेख: प्रणाली विकासमा पुरानो प्रणालीबाट स्थानान्तरणसँग सम्बन्धित कानूनी समस्याहरू[ja]
पहिलेको प्रणालीमा ५०,००० भन्दा बढी बिरामीहरूको डाटा सुरक्षित गरिएको थियो, र वादीले यी डाटाहरूको उपयोग गरेर कार्यको दक्षता बढाउने प्रयास गरिरहेको थियो। त्यसैले, बिरामीको डाटालाई पुरानो प्रणालीबाट नयाँ प्रणालीमा स्थानान्तरण गर्न नसक्दा, फार्मेसीमा औषधि वितरण कार्यमा बाधा पुग्ने स्पष्ट थियो र वादीको प्रतिनिधिले पनि यो कुरा स्वाभाविक रूपमा बुझिरहेको थियो। साथै, सम्झौता हस्ताक्षर गर्नु अघि, वादीको प्रतिनिधिले प्रतिवादीको प्रतिनिधिलाई डाटा स्थानान्तरणको सम्भावनाको बारेमा सोधेको कुरा प्रतिवादीको प्रतिनिधिले पनि स्वीकार गरेको छ (बीचमा हटाइएको), वादीको प्रतिनिधिले ५०,००० भन्दा बढी बिरामीहरूको डाटा हातले प्रविष्ट गर्नुपर्ने सम्भावना उच्च रहेको बुझेर पनि, नयाँ प्रणालीको कार्यान्वयनको निर्णय गरेको कुरा सोच्न गाह्रो छ। साथै, माथि उल्लिखित (१) अनुसार, प्रतिवादीले पुरानो प्रणालीको औषधि इतिहास डाटालाई नयाँ प्रणालीमा स्थानान्तरण गर्न नसकेकाले, उक्त डाटालाई कागजमा मुद्रण गरेर, यसलाई पीडीएफ फाइलमा समावेश गर्ने जस्ता प्रक्रिया गरिरहेको छ, जबकि सम्झौतामा डाटा स्थानान्तरणलाई आधारभूत मानिएको थिएन, प्रतिवादीले सेवा रूपमा यस्ता समय लाग्ने कार्यहरू गरेको कुरा सोच्न गाह्रो छ।
टोकियो जिल्ला अदालतको निर्णय, हेजी २२ (२०१०) नोभेम्बर १८
यहाँ पनि महत्त्वपूर्ण कुरा भनेको, सम्झौताको उद्देश्य र सम्झौतापत्रमा उल्लेखित विषयहरूको “भावना” हो। यदि डाटा स्थानान्तरणलाई कार्यक्षेत्र बाहिरको काम भनेर बुझेर दुवै पक्षले सम्झौता गरेको भए, प्रयोगकर्ता र विक्रेता दुवैले अस्वाभाविक उद्देश्य राखेर सम्झौता गरेको कुरा अदालतले औंल्याएको छ। अर्थात्, प्रयोगकर्ताले ठूलो मात्रामा हातले काम गर्नुपर्ने भएको थियो र विक्रेताले पनि प्रयोगकर्ताको कार्यमा बाधा पुग्ने कुरा थाहा पाउँदा पनि परियोजनामा संलग्न भएको थियो, जसले गर्दा यो अत्यन्तै अव्यावहारिक कुरा भएको हो।
दुवै निर्णयबाट के बुझ्न सकिन्छ
डाटा स्थानान्तरणको सन्दर्भमा, सम्झौतापत्र वा विशिष्टतापत्रमा उल्लेख नभए पनि कार्यान्वयनको दायित्वलाई स्वीकार गरिएको पृष्ठभूमिमा, “डाटा” भन्ने कुरा, जुन स्क्रिनमा प्रत्यक्ष देखिने कुरा होइन, यससँग सम्बन्धित भएको देखिन्छ। अगाडिको “आवश्यक कार्यक्षमताको अभाव” भनेको, मूलतः प्रणालीको स्क्रिन वा बाहिरी रूपमा प्रत्यक्ष देखिने कुरा हो। त्यसैले, प्रणाली विकासको अनुभव नभएका व्यक्तिहरूका लागि पनि, विशिष्टतापत्रको उल्लेख छुटेको कुरा पत्ता लगाउन त्यति कठिन हुँदैन। तर, डाटा स्थानान्तरणको समस्या भने, प्रणाली विकासको अनुभव नभएका व्यक्तिहरूका लागि यसको प्रक्रियाको महत्त्व, कार्यको कठिनाई वा समयावधि जस्ता कुराहरू बुझ्न गाह्रो हुन्छ। त्यसैले, विक्रेता पक्षले यसलाई विशेषज्ञताको साथमा सहज रूपमा व्यवस्थापन गर्नुपर्ने कुरा मानिएको हुन सक्छ।
यसरी हेर्दा, विशिष्टतापत्र वा सम्झौतापत्रको उल्लेख छुट्नु, प्रयोगकर्ताको “सहयोग दायित्व”सँग पनि नजिकको सम्बन्ध राख्ने समस्या हो भन्न सकिन्छ। अर्थात्, प्रयोगकर्ताले सम्झौताको निष्कर्ष र विशिष्टतापत्रको निर्माणमा साँच्चै “सहयोग दायित्व” पूरा गरेको हो कि भन्ने समस्या हो। प्रणाली विकास परियोजनामा, प्रयोगकर्ताले पूरा गर्नुपर्ने कानूनी दायित्वहरूको सामान्य व्याख्या तलको लेखमा विस्तृत रूपमा समेटिएको छ।
सम्बन्धित लेख: प्रणाली विकासको अर्डरकर्ता भएको प्रयोगकर्ता पक्षले बोक्ने सहयोग दायित्व के हो[ja]
उपरोक्त लेख पनि सँगै हेर्दा, स्क्रिन र आवश्यक कार्यक्षमताको पहिचान जस्ता प्रयोगकर्ता पक्षको सहयोगको माग धेरै हुने क्षेत्र र डाटा स्थानान्तरणको विचार छुटेको अवस्थामा, कुरा धेरै फरक हुने कुरा स्वाभाविक रूपमा बुझ्न सकिन्छ।
जापानमा विशिष्टिकरणमा नभएको विकासको लागि पारिश्रमिक कसरी विचार गर्ने?

यस लेखको विषयसँग सम्बन्धित अर्को चासोको विषय भनेको, जापानमा विशिष्टिकरणमा नभएको वस्तु बनाएको अवस्थामा, थप पारिश्रमिकको दाबी कानूनी रूपमा मान्य हुन्छ कि हुँदैन भन्ने कुरा हो। पारिश्रमिकको थपको मान्यता र सम्भव भएको अवस्थामा अनुमानित रकमको गणना विधि आदिको बारेमा, तलको लेखमा विस्तृत रूपमा व्याख्या गरिएको छ।
सम्बन्धित लेख: जापानमा प्रणाली विकासको अनुमानित रकमको पछि वृद्धि सम्भव छ कि?[ja]
उपरोक्त लेखमा, पारिश्रमिक र प्रतिफल सम्बन्धमा रहेको कामको दायरा भन्दा बढी काम भएको छ कि छैन भन्ने कुरा महत्त्वपूर्ण हुन्छ भन्ने कुरा व्याख्या गरिएको छ। अर्थात्, यस लेखसँगको सम्बन्धमा भन्नु पर्दा, प्रारम्भिक विशिष्टिकरणमा समावेश नभएको विकास (यस लेखमा भनेको नकारात्मक उदाहरणको विकास) मा, यदि विक्रेता सहमत हुन्छ भने, त्यहाँ थप पारिश्रमिकको दाबीलाई मान्यता दिन सकिन्छ।
सारांश
जापानमा प्रणाली विकासको सन्दर्भमा, विक्रेताले निभाउनुपर्ने भूमिका प्रायः सम्झौता पत्र र विशिष्टताहरूको सामग्री अनुसार निर्धारण हुन्छ। तर, विशेषज्ञको रूपमा उच्च विश्वासको आधारमा काम सुम्पिएको हुँदा, यसको वास्तविकता केवल औपचारिकतामा आधारित भएर निर्धारण हुँदैन भन्ने कुरा बुझ्न सकिन्छ। तथापि, यसको वास्तविकता बुझ्नका लागि पनि, जापानी कानुनले ठूलो भूमिका खेल्छ भन्ने कुरा बुझ्न आवश्यक छ।
Category: IT
Tag: ITSystem Development