ฟังก์ชันที่ไม่ได้ระบุไว้ในเอกสารข้อกำหนดการพัฒนาระบบ ควรจะมีการสร้างมากที่สุดเพียงใดตามกฎหมาย

โครงการพัฒนาระบบ IT ที่ใช้ในองค์กร โดยหลัก จะถูกสร้างขึ้นตามข้อกำหนดที่ได้รับการกำหนดไว้ล่วงหน้า อย่างไรก็ตาม จากมุมมองของผู้ขายที่เป็นผู้เชี่ยวชาญในการพัฒนาระบบ ที่ได้รับการมอบหมายงานพัฒนาระบบทั้งหมด ความคาดหวังของผู้ใช้งานอาจจะไม่ต่ำเพียงพอที่จะให้เพียงแค่ดำเนินการตามข้อกำหนดที่เขียนไว้ ในบทความนี้ เราจะอธิบายเกี่ยวกับ “โปรแกรมที่จำเป็นต้องมีการดำเนินการ แม้ว่าจะไม่ได้ระบุไว้ในข้อกำหนด แต่เมื่อพิจารณาจากวัตถุประสงค์ของการพัฒนา” ว่าควรรับผิดชอบในการดำเนินการดังกล่าวมากน้อยเพียงใด

ปัญหาทางกฎหมายที่เกี่ยวข้องกับการสร้างฟีเจอร์ที่ไม่ได้ระบุไว้ในข้อกำหนด

การทำงานของผู้ขายต้องมีการใช้ดุลยพินิจ

คุณสมบัติที่สำคัญของปัญหาทางกฎหมายที่เกี่ยวข้องกับสัญญาและโครงการพัฒนาระบบคือผู้ขายที่รับงานมีดุลยพินิจที่มาก.

บทความที่เกี่ยวข้อง: ความหมายของหน้าที่การจัดการโครงการในการพัฒนาระบบ

อย่างไรก็ตาม, “ดุลยพินิจ” ที่กล่าวถึงที่นี่ไม่ได้หมายความว่าจะต้องมีในทุกขั้นตอนของการพัฒนาระบบ หลังจากที่ได้ระบุขั้นตอนทั้งหมดและทำการแยกงานออกเป็นงานย่อยๆ อาจมีงานที่เป็นงานง่ายๆ มากขึ้น แต่โดยทั่วไป ก่อนที่จะแยกปัญหาออกเป็นส่วนย่อยๆ หรือกล่าวอีกนัยหนึ่งคืองานขั้นต้น ยิ่งเป็นงานขั้นต้นมากเท่าไหร่ ก็ยิ่งต้องมีดุลยพินิจที่มากเท่านั้น ซึ่งเป็นเหตุผลที่ทำให้สัญญาขั้นต้นมักจะเหมาะสมกับการมอบหมายงาน.

บทความที่เกี่ยวข้อง: การแยกแยะและความแตกต่างระหว่างสัญญาการรับเหมาและสัญญาการมอบหมายงานในการพัฒนาระบบ

การใช้ดุลยพินิจในกระบวนการพัฒนาที่เข้มงวดก็เป็นสิ่งที่ควรทำ

อย่างไรก็ตาม แม้ว่าผู้พัฒนาระบบจะมีดุลยพินิจที่มากมาย การยอมรับความต้องการของลูกค้าอย่างไม่เป็นระเบียบก็อาจนำไปสู่ความเสียหายที่มากมายในกระบวนการต่อไป ระบบ IT หนึ่ง สร้างขึ้นจากชิ้นส่วนที่ละเอียดอ่อน ดังนั้น แม้ว่าการเปลี่ยนแปลงจะดูเหมือนเป็นการเปลี่ยนแปลงที่เล็กน้อยในภายนอก แต่จากมุมมองของผู้พัฒนา อาจต้องการการเปลี่ยนแปลงที่ใช้เวลามาก นอกจากนี้ ในเรื่องของการเปลี่ยนแปลงข้อกำหนดในการพัฒนาระบบ มีบทความที่อธิบายวิธีการจัดการสถานะการเปลี่ยนแปลงจากมุมมองทางกฎหมายดังต่อไปนี้ บทความต่อไปนี้อธิบายวิธีการจัดการการเปลี่ยนแปลง แต่ยังอภิปรายถึงวิธีที่การเปลี่ยนแปลงข้อกำหนดจากมุมมองของวิศวกรส่งผลกระทบต่อธุรกิจอย่างไร

บทความที่เกี่ยวข้อง: วิธีการจัดการการเปลี่ยนแปลงในการพัฒนาระบบจากมุมมองทางกฎหมาย

ไม่ได้ยึดติดกับข้อกำหนด แต่ควรทำอะไรในฐานะผู้เชี่ยวชาญ

เพื่อให้โครงการพัฒนาระบบดำเนินไปอย่างราบรื่น การกำหนดข้อกำหนดการพัฒนาล่วงหน้า และดำเนินการตามแผนที่กำหนดไว้เป็นสิ่งที่สำคัญ อย่างไรก็ตาม มีบางสถานการณ์ที่หากเราทำเพียงแค่สิ่งที่ถูกกำหนดไว้ล่วงหน้า และทำตามที่ถูกสั่งให้ทำเท่านั้น ก็อาจไม่สามารถทำหน้าที่ในฐานะผู้เชี่ยวชาญในการพัฒนาระบบได้อย่างเต็มที่ ในสถานการณ์ที่เต็มไปด้วยความขัดแย้งนี้ ปัญหาเกี่ยวกับ “สิ่งที่ไม่ได้ระบุไว้ในข้อกำหนด แต่ควรจะถูกสร้างขึ้นมา” จึงเริ่มเป็นที่สังเกตเห็น

หน้าที่ตามกฎหมายจะถูกกำหนดตาม ‘วัตถุประสงค์’ ของเอกสารข้อกำหนดและสัญญา

เนื้อหาที่ควรจะมีการสร้างขึ้น แม้ว่าจะไม่มีการระบุไว้ในเอกสารสัญญาหรือเอกสารข้อกำหนด ก็ยังคงถูกกำหนดโดย ‘วัตถุประสงค์’ หรือ ‘ความหมายและเจตนาที่ทำให้มีการตกลงอย่างนั้น’ ของเอกสารสัญญาและเอกสารข้อกำหนดเหล่านั้น ต่อไปนี้ จะมาดูตัวอย่างคดีศาลที่เกี่ยวข้องกันบ้าง

ตัวอย่างคดีที่ปฏิเสธหน้าที่ในการสร้างระบบเนื่องจากไม่มีการระบุในเอกสาร

ในตัวอย่างคดีที่จะอ้างอิงต่อไปนี้ เป็นเรื่องที่ผู้ขายซอฟต์แวร์ได้พัฒนาระบบขึ้นมา และได้ทำการทดสอบระบบแบบชั่วคราว แต่กลับพบว่ายังขาดฟังก์ชันที่จำเป็น จึงได้เกิดข้อพิพาทที่ต้องการยกเลิกสัญญา ฟังก์ชันที่ผู้ใช้งานอ้างว่าขาดหายไปคือ “ฟังก์ชันการอัปเดตข้อมูลอัตโนมัติ” ซึ่งได้ถูกอ้างว่าเป็นจุดขายหลักของระบบนี้ แต่ศาลไม่ได้ยอมรับหน้าที่ในการสร้างฟังก์ชันนี้

ตามที่ได้รับการยืนยันดังกล่าว ไม่มีการระบุในสัญญาหรือเอกสารการออกแบบพื้นฐานและรายละเอียดว่า ฟังก์ชันที่ ③ จะเป็นส่วนหนึ่งของระบบที่จะพัฒนา

โจทก์อ้างว่า ฟังก์ชันที่ ③ เป็นจุดขายหลักของระบบนี้ที่ถูกขายให้กับโจทก์ และเน้นความจำเป็นของฟังก์ชันนี้ แต่ถ้าความอ้างอิงนี้เป็นความจริง ความสำคัญนี้ควรจะถูกระบุไว้ในสัญญาหรือเอกสารอื่นๆ และถ้าไม่มีการระบุ จะยากที่จะคิดว่าได้ตกลงกันเรื่องการพัฒนาฟังก์ชันนี้

คำพิพาทของศาลกรุงโตเกียว วันที่ 18 กุมภาพันธ์ ปี 2009 (Heisei 21)

แน่นอนว่า ถ้าดูจากคำสรุปของคำพิพาทนี้อย่างง่ายๆ ก็จะเห็นว่า “ถ้าไม่มีการระบุในเอกสารการออกแบบ ก็ไม่จำเป็นต้องสร้างฟังก์ชันที่ไม่มีการระบุ” แต่ถ้าต้องการพูดอย่างถูกต้อง ความจริงไม่ได้ขึ้นอยู่กับการระบุในเอกสารการออกแบบหรือไม่ แต่ขึ้นอยู่กับการตัดสินใจที่อ้างอิงจาก “วัตถุประสงค์” ของการระบุในเอกสารการออกแบบและสัญญา นั่นคือ “ถ้าคิดถึงเหตุผลที่ไม่ได้ระบุในเอกสารการออกแบบหรือสัญญา ก็ควรจะถือว่าไม่มีการตกลงกันเรื่องการสร้างฟังก์ชันนั้น”

ตัวอย่างคดีที่ยอมรับหน้าที่ในการดำเนินการ แม้ไม่ได้ระบุไว้

อย่างไรก็ตาม, มีตัวอย่างคดีที่ยอมรับหน้าที่ในการดำเนินการ แม้ไม่ได้ระบุไว้ในสัญญาหรือเอกสารข้อกำหนด ตัวอย่างคดีที่อ้างอิงด้านล่างนี้เกี่ยวข้องกับการพัฒนาระบบสำหรับการจัดการประวัติการใช้ยา ซึ่งไม่สามารถย้ายข้อมูลจากระบบที่มีอยู่แล้วไปยังระบบใหม่ ทำให้ไม่สามารถใช้ระบบใหม่ได้ และทำให้ผู้ใช้ต้องยกเลิกสัญญา แต่ฝ่ายผู้ขายยังคงโต้แย้งว่าการย้ายข้อมูลนั้นอยู่นอกขอบเขตของงาน

การพัฒนาระบบใหม่มักจะต้องทำงานร่วมกับการยกเลิกระบบที่มีอยู่แล้ว และการย้ายข้อมูล ความสำคัญของงานเหล่านี้และปัญหาทางกฎหมายที่เกี่ยวข้องได้รับการอธิบายอย่างละเอียดในบทความด้านล่างนี้

บทความที่เกี่ยวข้อง: ปัญหาทางกฎหมายที่เกี่ยวข้องกับการย้ายจากระบบเดิมในการพัฒนาระบบ

ระบบที่มีอยู่แล้วมีข้อมูลผู้ป่วยมากกว่า 50,000 คนที่ถูกบันทึกไว้ และฝ่ายโจทก์ได้ใช้ข้อมูลเหล่านี้เพื่อเพิ่มประสิทธิภาพในการทำงาน ดังนั้น ถ้าไม่สามารถย้ายข้อมูลผู้ป่วยจากระบบที่มีอยู่ไปยังระบบนี้ จะส่งผลกระทบต่อการทำงานในร้านขายยา ซึ่งเป็นสิ่งที่ชัดเจน และสามารถคิดได้ว่าผู้แทนของฝ่ายโจทก์จะต้องรู้จักสิ่งนี้ และก่อนที่จะทำสัญญานี้ ผู้แทนของฝ่ายโจทก์ได้ถามผู้แทนของฝ่ายจำเลยเกี่ยวกับความเป็นไปได้ในการย้ายข้อมูล ซึ่งเป็นสิ่งที่ผู้แทนของฝ่ายจำเลยยอมรับ (ตัดออก) ผู้แทนของฝ่ายโจทก์ต้องรู้ว่ามีความเป็นไปได้สูงที่จะต้องป้อนข้อมูลผู้ป่วยมากกว่า 50,000 คนด้วยมือ และยากที่จะคิดว่าจะตัดสินใจนำระบบนี้มาใช้ นอกจากนี้ ดังที่กล่าวไว้ใน (1) ฝ่ายจำเลยไม่สามารถย้ายข้อมูลประวัติการใช้ยาจากระบบที่มีอยู่ไปยังระบบนี้ และได้ทำการพิมพ์ข้อมูลลงบนกระดาษ และนำเข้าไฟล์ PDF แม้ว่าในสัญญานี้จะไม่ได้กำหนดว่าต้องย้ายข้อมูลยากที่จะคิดว่าฝ่ายจำเลยจะทำงานที่ยุ่งยากนี้เป็นบริการ

คำพิพากษาของศาลจังหวัดโตเกียว วันที่ 18 พฤศจิกายน ปี 22 ของรัชกาลฮิเซย์ (2010)

สิ่งที่สำคัญที่สุดในที่นี้คือ วัตถุประสงค์ของสัญญาและ “ความหมาย” ของรายการที่ระบุในสัญญา ถ้าทั้งสองฝ่ายได้ทำสัญญาโดยรู้ว่าการย้ายข้อมูลอยู่นอกขอบเขตของงาน ศาลได้ชี้แจงว่า ทั้งผู้ใช้และผู้ขายจะต้องมีเจตนาที่ไม่ปกติในการทำสัญญา นั่นคือ ผู้ใช้จะต้องรับงานที่มากมายด้วยมือ และผู้ขายจะต้องรับทราบว่าจะส่งผลกระทบต่องานของผู้ใช้ในอนาคต ซึ่งเป็นเรื่องที่ไม่เหมาะสมอย่างยิ่ง

สิ่งที่เราสามารถเข้าใจได้จากการตัดสินคดีทั้งสอง

ในเรื่องของการโยกย้ายข้อมูล แม้ว่าจะไม่มีการระบุในสัญญาหรือเอกสารข้อกำหนด แต่ก็ยังยืนยันว่ามีหน้าที่ในการดำเนินการ ซึ่งหนึ่งในเหตุผลอาจเกี่ยวข้องกับ “ข้อมูล” ซึ่งไม่ปรากฏในรูปลักษณ์บนหน้าจอ ส่วน “การขาดฟังก์ชันที่จำเป็น” ในส่วนแรก มันเป็นสิ่งที่ปรากฏโดยตรงบนหน้าจอหรือรูปลักษณ์ของระบบ ดังนั้น แม้ว่าจะเป็นมือใหม่ในการพัฒนาระบบ การค้นหาการลืมระบุในเอกสารข้อกำหนดก็ไม่ยาก ในทางกลับกัน ปัญหาการโยกย้ายข้อมูลมีลักษณะเฉพาะที่มือใหม่ในการพัฒนาระบบอาจจะไม่รู้จักความสำคัญของกระบวนการ ความยากของงาน หรือเวลาที่ใช้ ดังนั้น มีสถานการณ์ที่ผู้ขายที่มีความเชี่ยวชาญควรจัดการให้ราบรื่น

ดังนั้น การลืมระบุในเอกสารข้อกำหนดหรือสัญญา อาจเกี่ยวข้องกับ “หน้าที่ในการสนับสนุน” ของผู้ใช้ นั่นคือ ผู้ใช้ได้ทำหน้าที่ในการสนับสนุนในการทำสัญญาหรือการสร้างเอกสารข้อกำหนดหรือไม่ สำหรับคำอธิบายทั่วไปเกี่ยวกับหน้าที่ทางกฎหมายที่ผู้ใช้ควรทำในโครงการพัฒนาระบบ สามารถดูได้ในบทความด้านล่าง

บทความที่เกี่ยวข้อง: หน้าที่ในการสนับสนุนของผู้ใช้ที่เป็นผู้สั่งซื้อการพัฒนาระบบคืออะไร

หากคุณตรวจสอบบทความด้านบนด้วย คุณอาจจะเข้าใจว่า ในพื้นที่ที่ต้องการการสนับสนุนจากผู้ใช้ เช่น การคัดลอกฟังก์ชันที่จำเป็น และการลืมพิจารณาการโยกย้ายข้อมูล สิ่งที่เกิดขึ้นจะต่างกันอย่างมาก

ควรคิดอย่างไรเกี่ยวกับค่าตอบแทนที่เกี่ยวข้องกับการพัฒนาที่ไม่ได้ระบุในเอกสารข้อกำหนด

อีกหนึ่งประเด็นที่น่าสนใจเกี่ยวข้องกับหัวข้อของบทความนี้คือ ในกรณีที่สร้างสิ่งที่ไม่ได้ระบุในเอกสารข้อกำหนด การเรียกเก็บค่าตอบแทนเพิ่มเติมจะได้รับการยอมรับตามกฎหมายหรือไม่ สำหรับความเป็นไปได้ของการเพิ่มค่าตอบแทนและวิธีการคำนวณยอดเสนอราคาในกรณีที่เป็นไปได้ สามารถอ่านรายละเอียดได้ในบทความด้านล่างนี้

บทความที่เกี่ยวข้อง: การเพิ่มยอดเสนอราคาของการพัฒนาระบบหลังจากที่เสนอไปแล้วเป็นไปได้หรือไม่

ในบทความด้านบน ได้อธิบายว่า ความสำคัญคือว่ามีงานที่เกินขอบเขตงานที่มีความสัมพันธ์กับค่าตอบแทนหรือไม่ นั่นคือ ถ้าพูดเกี่ยวกับความสัมพันธ์กับบทความนี้ ถ้าผู้ขายตอบสนองการพัฒนาที่ไม่ได้รวมอยู่ในข้อกำหนดเริ่มแรก (ในบทความนี้ คือ ตัวอย่างที่ปฏิเสธ) ผู้ขายสามารถเรียกเก็บค่าตอบแทนเพิ่มเติมได้

สรุป

ในการพัฒนาระบบ บทบาทที่ผู้ขายควรทำ ในหนึ่งด้านคือ การตัดสินใจตามเนื้อหาของสัญญาและเอกสารข้อกำหนด แต่ถ้าพิจารณาจากมุมมองว่าพวกเขาได้รับความไว้วางใจสูงในฐานะผู้เชี่ยวชาญ ความเป็นจริงคือ การตัดสินใจไม่ได้ขึ้นอยู่กับรูปแบบเท่านั้น แต่ในการเข้าใจความเป็นจริงด้านใน ควรเข้าใจว่ากฎหมายมีบทบาทสำคัญอย่างยิ่ง