MONOLITH LAW OFFICE+81-3-6262-3248हप्ताका दिनहरू 10:00-18:00 JST [English Only]

MONOLITH LAW MAGAZINE

IT

सिस्टम विकासमा कानूनी दृष्टिकोणबाट बैठकको कार्यवृत्त कसरी राख्ने?

IT

सिस्टम विकासमा कानूनी दृष्टिकोणबाट बैठकको कार्यवृत्त कसरी राख्ने?

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

प्रणाली विकासलाई सहज रूपमा अगाडि बढाउन र जापानमा कुनै विवाद उत्पन्न भएमा तयारीको दृष्टिकोणबाट, एक प्रणाली विकास परियोजनाको प्रगति सहज रूपमा व्यवस्थापन गर्नका लागि, कागजातहरूको तयारी र तिनीहरूको व्यवस्थापन महत्त्वपूर्ण हुन्छ।

यस लेखमा, प्रणाली विकासको प्रगति बैठकहरूमा प्रयोग गरिने बैठकको कार्यवृत्त र बैठक सामग्रीको संरक्षण गर्ने तरिकाबारे जापानी कानूनी दृष्टिकोणबाट व्याख्या गरिनेछ।

जापानमा प्रणाली विकासमा कागजात व्यवस्थापन किन महत्त्वपूर्ण छ

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

पछाडि विवाद उत्पन्न नगर्नका लागि

प्रणाली विकास, प्रायः प्रयोगकर्ता पक्ष र विक्रेता पक्ष दुवैमा धेरै पक्षहरूलाई समेटेर अघि बढ्ने परियोजना हुन्छ। त्यसैले, प्रयोगकर्ता पक्ष र विक्रेता पक्षले कति भूमिका लिन्छन् र के कर्तव्यको रूपमा स्वीकार्छन् भन्ने बिषयमा दुवै पक्षको बुझाइमा असहमति भएमा, पछि परियोजनाको प्रगति अवरुद्ध हुन सक्छ।

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

दुवै पक्षको बुझाइमा असहमति छैन भनेर सुनिश्चित गर्नका लागि, बनेको सहमतिको सामग्रीलाई लेखेर राख्नु लाभदायक हुन्छ, र सम्बन्धित व्यक्तिहरूले (आफ्नो समय अनुसार) जाँच गर्न सक्ने सामग्रीमा संकलन गर्नुले सम्बन्धित व्यक्तिहरूको कदम मिलाउन मद्दत पुर्याउँछ।

वैसे, विवादको उत्पत्ति हुनुअघि नै रोकथाम गर्नका लागि कानूनी ज्ञानको उपयोग गर्नुलाई प्रायः रोकथाम कानूनी व्यवस्थापन भनिन्छ।

पछाडि विवाद उत्पन्न भएमा समाधानको उपायको रूपमा

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

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

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

जापानमा सिस्टम विकास बैठकको कार्यवृत्तको रूपमा विशेष रूपमा महत्त्वपूर्ण के हो?

सिस्टम विकास परियोजनामा बैठकको कार्यवृत्त कसरी राख्ने भन्ने बारेमा व्याख्या गर्दैछौं।

सिस्टम विकासमा हुने बैठकका प्रकारहरू

सिस्टम विकास परियोजनामा, विभिन्न बैठकहरू समय-समयमा आयोजना गरिँदै अगाडि बढ्ने गर्छन्। यो कुरा आफैंमा, धेरै व्यक्तिहरू संलग्न हुने परियोजना भएकोले, कुनै अनौठो कुरा होइन। प्रोग्रामको कार्यान्वयन विकास स्थलमा गर्ने प्रोग्रामर र इन्जिनियरहरूले पनि, नियमित रूपमा कामको प्रगति स्थिति जाँच गर्नका लागि जाँच बैठकहरू आयोजना गर्ने स्थलहरू धेरै हुनेछन्। साथै कार्यान्वित कोडमा, मर्मतयोग्यता र सुरक्षा पक्षमा कमजोरी जस्ता समस्याहरू छैनन् भनेर जाँच गर्नका लागि, वास्तविक कोड हेर्दै समीक्षा गर्ने जस्ता अवस्थाहरू पनि हुनेछन्।

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

विशेष रूपमा ध्यान दिनुपर्ने बैठक स्टेयरिङ कमिटी

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

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

जस्ता बुँदाहरू उल्लेख गर्न सकिन्छ।

जापानमा स्टेयरिङ कमिटीको बैठकको कार्यवृत्तसँग सम्बन्धित न्यायिक मिसाल

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

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

टोकियो उच्च अदालत निर्णय, हेइसेई २५ (२०१३) सेप्टेम्बर २६

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


जापानमा बैठकको कार्यवृत्तमा समावेश गर्नुपर्ने विशेष बुँदाहरू


बैठकको कार्यवृत्तमा दस्तावेजीकरण गर्नुपर्ने रेकर्डहरू के हुन्?

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

जापानमा विक्रेता पक्षको दृष्टिकोणबाट रेकर्डमा राख्नुपर्ने बुँदाहरू

विक्रेता पक्षले परियोजनामा, प्रणाली विकासको विशेषज्ञको रूपमा परियोजना व्यवस्थापनको दायित्व वहन गर्छ। यो दायित्वको विशेषता के हो भन्ने बारेमा तलको लेखमा विस्तृत रूपमा व्याख्या गरिएको छ।

https://monolith-law.jp/corporate/project-management-duties


यस दायित्वलाई ध्यानमा राख्दै, विक्रेता पक्षले विशेष रूपमा रेकर्डमा राख्नुपर्ने कुराहरूमा समावेश छन्:

    1. प्रत्येक विकास चरण पूरा भएको तथ्य र त्यसको मिति

    1. प्रयोगकर्ता पक्षबाट प्राप्त विनिर्देश परिवर्तन वा कार्यक्षमता थप्ने अनुरोधहरूमा कसरी प्रतिक्रिया दिइएको थियो भन्ने इतिहास

    1. प्रयोगकर्ता पक्षको आफ्नै कारणले विकास कार्यको प्रगति अवरुद्ध भएको अवस्थामा, सहयोगको लागि अपनाइएका उपायहरू र त्यसको प्रक्रिया

उपरोक्त ३. बुँदासँग सम्बन्धित रूपमा, उदाहरणका लागि, यदि प्रयोगकर्ता पक्षले निरीक्षण नगरेको अवस्थामा विक्रेता पक्षले विचार गर्नुपर्ने बुँदाहरू तलको लेखमा व्याख्या गरिएको छ। तलको लेखमा, विक्रेता पक्षले प्रयोगकर्ताको निरीक्षणको कार्यान्वयनको लागि कति सहयोगी थियो भन्ने आधारमा अदालतको निर्णय कसरी फरक पर्न सक्छ भन्ने कुरा वास्तविक निर्णयको उद्धरण गर्दै व्याख्या गरिएको छ।

https://monolith-law.jp/corporate/estimated-inspection-of-system-development


जापानमा प्रयोगकर्ता पक्षको दृष्टिकोणबाट रेकर्डमा राख्नुपर्ने बुँदाहरू

अवश्य पनि, प्रयोगकर्ताले पनि आफ्नै आन्तरिक प्रयोगको लागि प्रणाली भएकाले, प्रणाली विकासमा विक्रेता पक्षको विकास कार्यमा निश्चित सहयोगको दायित्व वहन गर्छ। यस दायित्वको समग्र सामग्री तलको लेखमा व्याख्या गरिएको छ।

https://monolith-law.jp/corporate/user-obligatory-cooporation


    1. आवश्यक कार्यक्षमता, स्क्रिनको बाहिरी रूप आदि, प्रयोगकर्ता पक्षबाट विक्रेता पक्षलाई सूचित गर्नुपर्ने कुराहरूको इतिहास

    1. विक्रेता पक्षको प्रक्रियामा उत्पन्न भएका विभिन्न समस्याहरूको इतिहास (उदाहरणका लागि, सदस्यको अचानक प्रस्थान वा विक्रेता पक्षको अनुसन्धानको कमीका कारण उत्पन्न भएको विकास प्रक्रियाको तालिकाको ढिलाइ र त्यसको कारण)

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

https://monolith-law.jp/corporate/the-transition-from-the-oldsystem

सारांश

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

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

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.

Category: IT

Tag:

माथि फर्कनुहोस्