ความหมายทางกฎหมายของการขอโทษจากผู้ขายไปยังผู้ใช้ในการพัฒนาระบบคืออะไร
ไม่จำกัดเฉพาะในการพัฒนาระบบเท่านั้น ในธุรกิจบริการทั่วไป การตอบสนองต่อการร้องเรียนจากลูกค้านั้นมีความสำคัญอย่างมาก การพัฒนาระบบก็ไม่ใช่ข้อยกเว้น มีบางครั้งที่ผู้ให้บริการทางเทคนิคหรือ “ผู้ขาย” จำเป็นต้องตอบสนองต่อการร้องเรียนจากลูกค้าหรือ “ผู้ใช้” ที่เขาได้รับ
ถ้าเราให้ความสำคัญกับการสื่อสารที่ดีระหว่างทั้งสองฝ่าย อาจมีกรณีที่ยอมรับความผิดและขอโทษเป็นวิธีที่เหมาะสม แต่อาจมีคนที่กังวลว่าการขอโทษด้วยปากหรือการส่งข้อความขอโทษอาจทำให้ความเรียกร้องที่ไม่ยุติธรรมจากฝ่ายผู้ใช้กลายเป็นความจริงที่ยอมรับได้
ในบทความนี้ เราจะมุ่งเน้นที่ “การขอโทษจากผู้ขายไปยังผู้ใช้” และอธิบายว่ามันมีความหมายอย่างไรในทางกฎหมาย
ทำไมการ ‘ขอโทษ’ ถึงเป็นปัญหาในสถานที่พัฒนาระบบ
การพัฒนาระบบเป็นหนึ่งในธุรกิจบริการ
เริ่มแรกเลย การพัฒนาระบบคือธุรกิจที่ผู้ประกอบการภายนอกเข้ามามีส่วนร่วมในรูปแบบของการทำงานแบบไอที ซึ่งสามารถกล่าวได้ว่าเป็น “ธุรกิจบริการสำหรับองค์กร” หากต้องการใช้ศัพท์ทางกฎหมาย การทำสัญญาจะเป็นรูปแบบของสัญญาจ้างงานหรือสัญญาแทนที่ ซึ่งเป็นสิ่งที่ปกติจะเกิดขึ้น สำหรับความแตกต่างระหว่างสัญญาจ้างงานและสัญญาแทนที่ มีการอธิบายอย่างละเอียดในบทความด้านล่างนี้
https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]
สำคัญของเรื่องคือ ไม่ว่าจะเป็นสัญญาแบบใด บริษัทที่รับงานจากผู้ขายจะสร้างรายได้จากทักษะทางเทคนิคและแรงงาน (และผลิตภัณฑ์ที่สร้างขึ้นจากทักษะเหล่านี้) ไม่มีสิ่งที่เปลี่ยนแปลง การบริการที่ให้โดย “คน” ที่เป็นส่วนหนึ่งของผู้ขายและการแลกเปลี่ยนค่าตอบแทนที่เกี่ยวข้องกับการทำธุรกิจ ดังนั้น การพัฒนาระบบไอทีเป็นหนึ่งในธุรกิจบริการ
ผู้ใช้งาน “ลูกค้า” จึงต้องการขอโทษ
เนื่องจากการพัฒนาระบบเป็นธุรกิจบริการ จึงคาดว่าจะมีการร้องเรียนและข้อร้องเรียนจากผู้ใช้งาน ในเวลาเดียวกัน ความสามารถในการตอบสนองต่อข้อร้องเรียนเหล่านี้ก็จะถูกต้องการจากผู้ขาย แน่นอนว่าในปัญหาจริง ผู้ขายอาจจะต้องขอโทษและตอบสนองต่อข้อร้องเรียนและการร้องเรียนต่างๆ ซึ่งอาจจะสร้างระบบการทำงานร่วมกันอีกครั้งและนำไปสู่ความสำเร็จของโครงการ
แต่อย่างไรก็ตาม ถ้าโครงการล้มเหลวในภายหลัง ลองคิดถึงสถานการณ์ที่คดีถูกนำไปศาล ผู้ใช้งานอาจจะอ้างว่า “ผู้ขายยอมรับว่ามีสาเหตุที่ต้องรับผิดชอบ” โดยอาศัยการขอโทษจากผู้ขายเป็นหลักฐาน
ปัญหาว่าผู้ใช้งานสามารถเป็นลูกค้าได้มากน้อยเพียงใด
โครงการพัฒนาระบบ แน่นอนว่าในหนึ่งด้าน คือการทำธุรกิจระหว่าง “ลูกค้า” หรือผู้ใช้งานและ “ผู้ประกอบการภายนอก” หรือผู้ขาย แต่ความซับซ้อนที่ไม่สามารถจำกัดไว้ในความสัมพันธ์นี้เป็นลักษณะเฉพาะของสัญญาที่เกี่ยวข้องกับการพัฒนาระบบ นั่นคือ ลูกค้าหรือผู้ใช้งานต้องร่วมมือกับผู้ขายในการทำหน้าที่ โครงการจะไม่สามารถสำเร็จได้ ผู้ใช้งานต้องมีหน้าที่ในการร่วมมือและทั้งสองฝ่ายต้องทำงานร่วมกันเพื่อส่งเสริมโครงการ ซึ่งเป็นสิ่งที่ได้รับการชี้แจงในคดีศาลในอดีต
https://monolith.law/corporate/user-obligatory-cooporation[ja]
เมื่อพิจารณาปัญหาทางกฎหมายเกี่ยวกับการ “ขอโทษ” จากผู้ขายถึงผู้ใช้งาน การรู้จักความซับซ้อนของความสัมพันธ์นี้เป็นสิ่งสำคัญ ความสัมพันธ์ระหว่างผู้ใช้งานและผู้ขายอาจจะเป็นความสัมพันธ์ที่เท่าเทียมและมีสภาพสุขภาพ หรืออาจจะถูกมองว่าเป็น “หนึ่งในผู้ประกอบการที่เข้ามา” ผู้ใช้งานต้องร่วมมือและทำงานร่วมกันเพื่อส่งเสริมโครงการ ซึ่งเป็นหน้าที่ทางกฎหมาย ปัญหาเกี่ยวกับการขอโทษที่ไม่เหมาะสมมักจะเกิดขึ้นเมื่อลืมความจริงที่สำคัญนี้ สำหรับจุดนี้ มันอาจจะเป็นลักษณะเฉพาะของการพัฒนาระบบซึ่งไม่ค่อยเห็นในธุรกิจบริการอื่นๆ
ศาลมอง ‘การขอโทษ’ อย่างไร
แล้วในความเป็นจริง ในกรณีคดีที่เกี่ยวข้องกับการพัฒนาระบบ การขอโทษจากฝ่ายผู้ขายถูกพิจารณาอย่างไรในทางกฎหมาย มาดูกันต่อไปนี้
ตัวอย่างคดีที่เกี่ยวข้องกับการขอโทษ 1: การขอให้ลูกค้าขอโทษอย่างลึกซึ้ง
ในกรณีนี้ หลังจากทำงานทั้งคืนและไปหาลูกค้า มีการกล่าวหาว่าเราได้ลบข้อมูล และถูกบังคับให้ขอโทษอย่างลึกซึ้ง หลังจากนั้นเราได้ส่งหนังสือขอโทษตามความต้องการของลูกค้า แต่ศาลได้แสดงความเห็นว่า หนังสือขอโทษที่ส่งในครั้งนั้นไม่ได้แสดงความจริงจากใจ
ฮ. ได้สร้างหนังสือขอโทษที่มีการอ้างถึงเรื่องนี้ แต่นั่นคือ หลังจากทำงานทั้งคืน และเข้าเยี่ยมชมสำนักงานของโจทก์ในวันที่ 4 ตุลาคม พ.ศ. 2544 (ปีฮีเซย์ 13) ฮ. ถูกตำหนิอย่างเดียวดาย และถูกบังคับให้ขอโทษอย่างลึกซึ้ง หลังจากนั้น ฮ. ได้สร้างหนังสือขอโทษตามความต้องการของโจทก์ เพื่อบรรเทาความโกรธของผู้บริหารโจทก์ ซึ่งไม่ได้เป็นความจริงจากใจของฮ. และเช่นเดียวกับหนังสือขอโทษที่น. สร้างขึ้น ก็ไม่ได้เป็นความจริงจากใจของน.
คำพิพากษาของศาลจังหวัดโตเกียว วันที่ 23 เมษายน พ.ศ. 2547 (ปีฮีเซย์ 16)
คุณลักษณะที่โดดเด่นคือ การตำหนิที่เป็น “เพียงฝ่ายเดียว” การ “บรรเทาความโกรธ” และ “ไม่ได้เป็นความจริงจากใจ” ซึ้งเป็นการตัดสินใจที่รวมถึงความรู้สึกของผู้เกี่ยวข้อง
ตัวอย่างคดีที่เกี่ยวข้องกับการขอโทษ 2: การเลือกที่จะเขียนจดหมายขอโทษหรือจ่าย 20 ล้านเยน
ในกรณีต่อไปนี้ แม้ว่าผู้ขายจะตกลงที่จะเขียนจดหมายขอโทษเกี่ยวกับความเสียหายที่ผู้ใช้งานสุดท้ายได้รับ แต่ความรับผิดชอบทางกฎหมายควรจะถูกกลับคืนให้กับผู้ขายหรือไม่ นั้นเป็นเรื่องที่ควรจะแยกออกจากกัน และมีการตัดสินใจว่าควรจะเป็นอย่างนั้น
ผู้แทนของฝ่ายฟ้องได้รับรายงานดังกล่าวแล้ว และกล่าวว่า “เนื่องจากเราได้ทราบแล้วว่า บริษัท E ทำผิด ดังนั้นเขียนจดหมายขอโทษหรือรับผิดชอบค่าใช้จ่ายในการพัฒนาซอฟต์แวร์ 20 ล้านเยน” ฝ่ายถูกฟ้องจึงปฏิบัติตามคำขอนี้ และในวันที่ 19 มกราคมของปีนั้น ได้สร้าง “จดหมายขอโทษ” ที่มีเนื้อหาขอโทษฝ่ายฟ้องเนื่องจากปัญหาที่เกิดขึ้น และส่งให้ฝ่ายฟ้อง
(ข้าม)
ควรจะถือว่าเราได้ดำเนินการอย่างที่สุดที่เป็นไปได้ในฐานะผู้ขายสินค้าของบริษัท E และไม่สามารถกล่าวว่าฝ่ายถูกฟ้องได้ละเว้นหน้าที่ตามสัญญาซื้อขายหลักทันทีเนื่องจากไม่ได้ดำเนินการเพิ่มเติม
คำพิพากษาของศาลจังหวัดโตเกียว วันที่ 11 กรกฎาคม พ.ศ. 1996 (Heisei 8)
จากคำพิพากษา สามารถอ่านเห็นได้ว่า มีการมุ่งเน้นที่วิธีการดำเนินงานจริง มากกว่าเรื่องของการกำหนดชื่อผู้รับจดหมายขอโทษแบบเป็นทางการ และมีการตัดสินใจว่าควรจะกำหนดวัตถุประสงค์ที่ควรรับผิดชอบ
สิ่งที่สามารถพูดได้ร่วมกันจากตัวอย่างคดีที่กล่าวมาข้างต้น
สิ่งที่สามารถพูดได้จากตัวอย่างคดีที่กล่าวมาข้างต้นคือ แม้ว่าผู้ขายจะตอบสนองต่อคำขอขอโทษในรูปแบบทางการ แต่ไม่ได้หมายความว่ามันจะมีความหมายที่สำคัญในการพิจารณาคดีในความเป็นจริง ความเป็นไปได้ที่การขอโทษจะเกิดขึ้นเนื่องจากเหตุผลทางธุรกิจหรือเพียงแค่เพื่อความสะดวกในการขับเคลื่อนสิ่งต่างๆ นั้น จะถูกพิจารณาอย่างละเอียดในการพิจารณาคดี ในทางกลับกัน การขอโทษที่เป็นรูปแบบทางการมากกว่า การพิจารณาถึงเหตุผลและกระบวนการที่การขอโทษได้ถูกดำเนินการ และการสร้างความสัมพันธ์ระหว่างผู้ใช้และผู้ขาย จะถูกนำมาพิจารณาในการตัดสินใจโดยรวม นี่คือทัศนคติที่ควรจะมองว่าศาลมีอยู่
ในการพัฒนาระบบ ผู้ใช้มีหน้าที่ที่จะต้องทำงานร่วมกับผู้ขาย นี่เป็นความเห็นที่ศาลได้แสดงออกมา ในกรณีที่ผู้ใช้มีความสัมพันธ์ที่ครอบงำและเข้มงวดกับผู้ขายจนไม่สามารถที่จะทำงานร่วมกันได้ การขอโทษจะมักถูกจัดการเป็นเพียงรูปแบบทางการเท่านั้น
ควรระมัดระวังในการขอโทษอย่างง่ายๆ
แม้ว่าในกรณีที่เรื่องไปถึงศาล, การขอโทษอาจไม่เป็นหลักฐานที่ชัดเจนในการตัดสิน แต่นั่นไม่ได้หมายความว่าคุณสามารถขอโทษได้อย่างง่ายๆ การขอโทษอย่างไม่คิดมากอาจนำไปสู่ความเสี่ยงในการทำให้ผู้ใช้งานมีทัศนคติที่ยืนกรานในช่วงการเจรจาก่อนที่เรื่องจะไปถึงศาล นอกจากนี้ ในช่วงเริ่มต้นของการศาลคดี หากผู้พิพากษาสร้างภาพลักษณ์จากการขอโทษ อาจทำให้ต้องใช้เวลาและความพยายามในการแก้ไขความเข้าใจผิดมากขึ้น นอกจากนี้ หากเนื้อหาการขอโทษหรือรายละเอียดในการขอโทษชี้แจงถึงความผิดของผู้ขายอย่างละเอียด อาจกลายเป็นปัจจัยที่ทำให้การตีความในขั้นตอนการยอมรับความจริงเป็นเปรียบ
ไม่ว่าจะเป็นกรณีใด ความรู้สึกไม่พอใจและการร้องเรียนเป็นปัญหาทางกฎหมายเอง ดังนั้นคุณควรพิจารณาใช้ผู้เชี่ยวชาญภายนอกในการแก้ไขปัญหาเกี่ยวกับวิธีการขอโทษอย่างไร
Category: IT
Tag: ITSystem Development