सिस्टम विकास एक रातमा पूरा हुने परियोजना होइन, यसमा धेरै मानिसहरू, संगठनहरू, ठूलो पूँजी र लामो विकास अवधि जस्ता धेरै स्रोतहरूको लगानी आवश्यक पर्दछ। यस लेखमा, सिस्टम विकासमा परियोजनाको ‘जल्ने’ घटना जापानी कानूनी ढाँचामा कसरी व्यवस्थापन गर्न सकिन्छ भन्ने विषयमा व्याख्या गरिनेछ र समाधानका लागि मार्गदर्शन प्रदान गरिनेछ।
प्रोजेक्टहरू किन ‘आगलागी’ हुन्छन्?
एउटा आईटी सिस्टम, त्यो जति ठूलो प्रोजेक्ट नभए पनि, धेरै प्रोग्राम फाइलहरू र सोर्स कोडहरूको संचयमा मात्र सही रूपमा काम गर्न सक्छ। स्क्रिनमा देखिने प्रयोगकर्ताको अनुभवले तपाईंलाई कल्पना गर्न सक्दैन जति (वा शायद, स्क्रिनमा देखिने प्रयोगकर्ताको अनुभव जति सरल र स्पष्ट छ, त्यस्तो आईटी सिस्टम उति नै सूक्ष्म र विस्तृत निर्माण गरिएको हुन्छ।
डेडलाइन मात्र पहिले निर्धारित गरिएको हुन्छ र विशेषताहरू र आवश्यकताहरू अस्पष्ट रहँदै समय बित्दै जान्छ।
सदस्यहरू आन्तरिक राजनीतिक समस्याहरूमा मात्र ध्यान केन्द्रित गर्छन् र मानव सम्बन्धहरूको तनावले गर्दा धेरै सदस्यहरू बीचमा छाड्न पुग्छन्।
पीएम सहितको प्रबन्धन स्तरमा पनि वार्तालाप क्षमताको अभाव छ र सदस्यहरूलाई उचित रिपोर्टिङ, सम्पर्क र परामर्श माग्ने काम गरिँदैन।
तर विशिष्ट प्रोजेक्टका लागि विशिष्ट ‘आगलागी’ कारणहरू विभिन्न हुन सक्छन्। तथापि, कानूनी दृष्टिकोणबाट हेर्दा, प्रोजेक्टका ‘आगलागी’ कारणहरूलाई केहि वर्गीकरणहरूमा सापेक्ष रूपमा सरल तरिकाले व्यवस्थित गर्न सकिन्छ।
जापानमा प्रोजेक्ट अचानक रोकिएमा: वर्गीकरण १
सिस्टम विकासको प्रगतिमा, प्रोजेक्ट अचानक रोकिनुको मुख्य कारणको रूपमा प्रयोगकर्ता पक्ष र विक्रेता पक्षबीचको सञ्चारको अभाव देखा पर्छ। सिस्टम विकास भन्नाले, विक्रेता पक्षको विशेषज्ञता र संगठनात्मक क्षमता आवश्यक छ भने, अन्तिम प्रयोगकर्ता पक्षको सहयोग पनि अत्यावश्यक हुन्छ।
त्यसैले, एक प्रोजेक्टमा दुवै पक्षले के कस्तो भूमिका निर्वाह गर्ने भन्ने कुरामा अस्पष्टता रहँदा, कामको दबाब एक अर्कामा थोपर्ने जस्तो अवस्था सिर्जना हुन्छ र यसले प्रोजेक्टको सुचारु रूपमा अगाडि बढ्न बाधा पुर्याउँछ। प्रयोगकर्ता पक्ष र विक्रेता पक्षका कर्तव्यहरूको कानूनी विचार गर्ने बारेमा तलका लेखहरू हेर्नुहोस्।
दुवै पक्षले कस्तो जिम्मेवारी बहन गर्नुपर्छ भन्ने विषयमा विस्तृत जानकारी उपरोक्त लेखहरूमा छ, तर यहाँको मुख्य कुरा यो हो कि एक सिस्टम विकास प्रोजेक्टमा प्रयोगकर्ता र विक्रेता दुवैले निश्चित जिम्मेवारी बहन गर्दछन्। सामान्य विभाजनको रूपमा, आवश्यकता परिभाषा, इन्टरफेस डिजाइन जस्ता कामहरू प्रयोगकर्ता पक्षको सहयोग बिना सम्पन्न हुँदैनन्, र यस्ता क्षेत्रमा प्रयोगकर्ता पक्षको सहयोगी कर्तव्यलाई पूर्वका निर्णयहरूले स्वीकार गरेका छन्।
त्यसैगरी, विक्रेता पक्षले पनि प्रयोगकर्ता पक्षको सहयोग प्राप्त गरेर (र साथै सहयोग माग्ने सञ्चारमा प्रयास गरेर) प्रोजेक्टलाई सुचारु रूपमा अगाडि बढाउने र अवरोधका कारणहरू पत्ता लगाई तिनीहरूलाई हटाउने समग्र जिम्मेवारी बहन गर्दछ।
यस्तो सोचका आधारमा, आन्तरिक सिस्टमको रूपमा, प्रयोगकर्ताले आन्तरिक गभर्नेन्स लागू गर्ने कर्तव्य र विक्रेताले बाह्य विशेषज्ञको रूपमा विशेषज्ञता र प्राविधिक क्षमता प्रदर्शन गर्दै काम गर्ने कर्तव्य दुवै पक्षले देखाउँछन्, र यस्ता विवादलाई न्यायिक रूपमा समान रूपमा व्यवहार गर्ने दृष्टिकोण अदालतले देखाएको छ।
यस्तो ‘अचानक रोकिने’ घटना विशेष गरी परीक्षणको समयमा धेरै हुन्छ। परीक्षणको विषयमा तलको लेखमा विस्तृत विवरण छ।
यस्तो अवस्थामा, विवादमा परेमा, त्यहाँ प्रोजेक्टको प्रगति र बैठकका विवरणहरू जस्ता वस्तुगत रूपमा प्रमाणित गर्न सकिने प्रमाणहरूलाई महत्व दिइन्छ। त्यसैले त्यहाँ अग्रिम रूपमा दर्ता गरिएका कागजातहरूले ठूलो अर्थ राख्ने गर्दछ। आफ्नो स्थिति अनुकूल नबनाउनका लागि, कागजात व्यवस्थापनको पूर्णता महत्त्वपूर्ण छ। सिस्टम विकासमा कागजात व्यवस्थापनको महत्वको दृष्टिकोणबाट, तलको लेखमा विस्तृत विवरण गरिएको छ।
जापानमा प्रयोगकर्ताको स्वविवेकले अनुबन्ध रद्द गर्दा
प्रोजेक्ट मध्यमा अनुबन्ध रद्द भएको अवस्था के हो?
प्रोजेक्टको मध्यमा, प्रयोगकर्ताको इच्छाअनुसार, परियोजना रोकिने अवस्था पनि सम्भावित छ। उदाहरणका लागि, विदेशी शाखाहरू समेत समावेश गरी मानव संसाधन प्रबन्धनलाई एकीकृत गर्ने आईटी प्रणाली निर्माण सुरु गरेको अवस्थामा, कम्पनीको विदेशी बजार प्रवेश रणनीति नै परित्याग गरिएको भए। यस्तो अवस्थामा, त्यो प्रणालीको विकास अब प्रयोगकर्ताका लागि आवश्यक नहुन सक्छ।
मूलतः, कम्पनीमा प्रयोग हुने आईटी प्रणाली कसरी निर्माण गर्नुपर्छ भन्ने प्रश्न नै, पहिले कम्पनीमा कुन कुन कार्यहरू छन् भन्ने प्रश्नसँग अत्यन्तै नजिकको सम्बन्ध राख्दछ। त्यसैले, संगठनात्मक संरचना र व्यवसाय विभागको परिवर्तन, रणनीतिक पुनरावलोकन जस्ता कारणले गर्दा, पछि परियोजनाका लागि आवश्यक (वा अनावश्यक) प्रणालीका आवश्यकताहरू परिवर्तन हुन सक्छ।
यस्ता परिस्थितिहरूले गर्दा प्रोजेक्ट मध्यमा रोकिने अवस्था पनि विभिन्न कानूनी समस्याहरू उत्पन्न गर्न सक्छ। यस्तो अवस्थामा सामान्यतया, प्रयोगकर्ताको स्वविवेकले गर्दा, पूरा भएको प्रतिशत अनुसार पारिश्रमिक माग गर्ने अधिकार वेन्डर पक्षलाई पनि प्रदान गरिन्छ। कुन प्रकारको अनुबन्ध प्रयोग गरिएको थियो भन्ने कुरामा आधारित कानूनी धारामा भिन्नता हुन सक्छ, तर त्यसको सामग्री तल यसरी व्यवस्थित गरिएको छ:
・ठेक्का अनुबन्धको हकमा: जापानी नागरिक संहिता (民法) को धारा ६४१ जापानी नागरिक संहिता धारा ६४१ → ठेकेदारले काम सम्पन्न नगरेसम्म, आदेशकर्ताले कुनै पनि समयमा क्षतिपूर्ति गरी अनुबन्ध रद्द गर्न सक्छ। ・अर्ध-जिम्मेवारी अनुबन्धको हकमा: जापानी नागरिक संहिता धारा ६४८ को तेस्रो उपधारा (परिस्थितिअनुसार, धारा ६५१ अनुसार क्षतिपूर्ति माग गर्न सकिन्छ) जापानी नागरिक संहिता धारा ६४८ → जब जिम्मेवारी ग्रहणकर्ताको दोषले होइन भन्ने कारणले गर्दा कार्यान्वयन मध्यमा समाप्त हुन्छ, तब ग्रहणकर्ताले गरेको कार्यको प्रतिशत अनुसार पारिश्रमिक माग गर्न सक्छ। जापानी नागरिक संहिता धारा ६५१ → १. जिम्मेवारी कुनै पनि पक्षले कुनै पनि समयमा रद्द गर्न सक्छ। → २. यदि कुनै पक्षले अर्को पक्षलाई असुविधाजनक समयमा जिम्मेवारी रद्द गर्छ भने, त्यो पक्षले अर्को पक्षको क्षति क्षतिपूर्ति गर्नुपर्छ। तर, यदि अपरिहार्य कारण छ भने, यो सीमित हुन्छ।
जापानमा प्रणाली वितरणपछि त्रुटि पत्ता लागेको अवस्था
प्रणाली वितरणपछि तुरुन्तै समस्या पत्ता लागेको अवस्थामा के गर्ने?
प्रयोगकर्ताहरूले प्रायः प्रणालीको प्रदर्शनलाई स्क्रिनमा गरिएको क्रियाकलापबाट बुझ्ने गर्दछन्, तर डाटाबेसको डिजाइन वा सबै प्रकारका क्रियाकलापहरूलाई ध्यानमा राखेर परीक्षण वस्तुहरू तयार गर्नु नै सेवा प्रदायकका लागि चुनौतीपूर्ण हुन सक्छ।
अर्थात्, प्रयोग सुरु गर्दा प्रणाली समस्यारहित चलेको देखिन्छ तर,
डाटाको मात्रा बढ्दै गएसँगै प्रक्रिया गति धीमो हुँदै जान्छ
दैनिक मूल कार्यहरूमा समस्यारहित चलेको देखिने प्रणाली पनि, केही महिना वा वर्षमा एक पटक हुने विशेष क्रियाकलापमा बगहरू उत्पन्न हुने देखिन्छ
सतहमा, नतिजाहरू सही उत्पादन गरिरहेको जस्तो देखिन्छ तर वास्तवमा लजिक सही हुँदैन (उदाहरणका लागि, प्रयोगकर्ताले ‘1+1’ भनेर प्रविष्टि गर्दा ‘2’ को उत्पादन सही देखिन्छ तर, यसको गणना प्रक्रिया सही हुनुपर्छ। तर कुनै पनि गणना सूत्र प्रविष्टि गर्दा ‘2’ को उत्पादन फर्काउने गलत लजिक, स्क्रिनमा मात्र क्रियाकलाप गर्दा पत्ता लाग्न सक्दैन। परीक्षण प्रक्रियामा पनि यस अर्थमा ‘प्राविधिक क्षमता’ को माग गरिन्छ।)
यस्ता घटनाहरू वास्तवमा घट्न सक्छन्। यदि यस्ता मामलाहरूलाई कानूनी दृष्टिकोणबाट विश्लेषण गर्ने हो भने, यसको सम्भावना विक्रेताको परियोजना प्रबन्धनको कर्तव्य उल्लंघन, अर्थात् जापानी सिभिल कोड (民法) अनुसारको अपूर्ण प्रदर्शनको समस्या हुन सक्छ।
यस अवस्थामा, यदि अनुबन्धमा विशेष नियमहरू तयार गरिएको छैन भने, सामान्यतया ठेक्का अनुबन्ध सम्बन्धी प्रावधानहरू लागू हुन्छन्।
त्यस केसमा विचार गर्नुपर्ने मुख्य बिन्दुहरू यस प्रकार छन्:
・काम पूरा भएको छैन भन्ने अवस्था →काम पूरा नभएकोले त्यसको प्रतिफलको रूपमा भुक्तानी पनि हुँदैन, तर यदि यसको कारण प्रयोगकर्ताको सहयोग गर्ने कर्तव्य उल्लंघनमा छ भने, विक्रेताले पनि क्षतिपूर्ति दाबी गर्न सक्छ।
・काम त पूरा भएको छ तर, अनुबन्धित उद्देश्य पूरा गर्न सकिएको छैन भन्ने अवस्था →कानूनी दोष (民法635条) भएको मानिन्छ। प्रयोगकर्ताले अनुबन्ध खारेज गरेको अवस्थामा, विक्रेताले भुक्तानी माग गर्न सक्दैन। उल्टो, प्रयोगकर्ताले विक्रेतासँग क्षतिपूर्ति दाबी गर्न सक्छ। (यस प्रकारको अवस्थाको विस्तृत विवरण अर्को लेखमा उल्लेख गरिएको छ।)
・काम पूरा भएको छ र अनुबन्धित उद्देश्य पनि पूरा गर्न सकिएको छ, तर केही क्षतिपूर्ति वा दोष मर्मत गर्नुपर्ने सामान्य दोषहरू देखिएको छ →विक्रेताबाट भुक्तानी माग गर्न सकिन्छ तर प्रयोगकर्ताबाट क्षतिपूर्ति पनि सम्भव छ। त्यसैले, दुवै पक्षबाट उल्लेखित रकम आपसमा मिलान गरिन्छ।
・काम पूरा भएको छ र त्यसको सामग्रीमा कुनै दोष पनि छैन →मूल रूपमा यो लेखमा उल्लेखित ‘विवाद’ मामला होइन, सामान्य रूपमा भुक्तानी माग गरिएको छ र परियोजना पूरा भएको छ।
यसरी व्यवस्थित गरिएको छ।
सारांश
प्रत्येक सिस्टम विकास परियोजना विविध र बहुआयामी चुनौतीहरूमा पर्दै अगाडि बढ्छ। तर, जब कानूनी परियोजनाहरूको ‘आगलागी’ को कुरा आउँछ, यस लेखमा प्रस्तुत गरिएको ढाँचा एक प्रकारको दृष्टिकोणको रूपमा काम गर्दछ। सिस्टम विकाससँग सम्बन्धित कानूनी समस्याहरू निश्चित रूपमा धेरै विविध विषयहरू समावेश गर्दछन्।
तर सिस्टम विकासको कामले यस्तै रचनात्मक सोचको आवश्यकता पर्दछ भने, त्यससँग जोडिएको जोखिम व्यवस्थापन पनि, क्षेत्रको समग्र दृष्टिकोणलाई नबिर्सी, अझ रचनात्मक रूपमा अगाडि बढाउन सकिन्छ।
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.
