กฎหมายที่เกี่ยวข้องกับการออกจากโครงการพัฒนาระบบของสมาชิก

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

การออกจากทีมของสมาชิกเป็นส่วนหนึ่งของหน้าที่ในการจัดการโปรเจค

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

https://monolith.law/corporate/project-management-duties[ja]

การที่มีสมาชิกที่ออกจากทีมอย่างกะทันหันจากฝั่งผู้ขาย สามารถถือว่าเป็นปัญหาหนึ่งในหน้าที่ในการจัดการโปรเจคของฝั่งผู้ขาย

• การทำงานล่วงเวลามากเกินไป การทำงานในวันหยุด หรือการทำงานนานเกินไปทำให้สุขภาพเสื่อม
• ความไม่สามารถร่วมงานกันทางด้านมนุษย์ทำให้เกิดความเครียดทางจิตใจ

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

ตัวอย่างคดีสำคัญเกี่ยวกับการออกจากสมาชิก

กรณีที่การออกจากทีมของสมาชิกทำให้เกิดความล่าช้าในการส่งมอบผลงาน

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

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

https://monolith.law/corporate/user-obligatory-cooporation[ja]

แต่ศาลตัดสินว่า สถานการณ์ทั้งหมดไม่สามารถยกเว้นหน้าที่ในการจัดการโปรเจคของฝั่งผู้ขายได้ และสนับสนุนมุมมองของผู้ใช้งาน (ส่วนที่ขีดเส้นใต้และตัวหนาเป็นส่วนที่ผู้เขียนเพิ่มเติมเอง)

ผู้ขายอ้างว่า ตัวแทนผู้ใช้งานได้ทำให้ผู้รับผิดชอบจากฝั่งผู้ขายต้องออกจากงานที่รับมอบหมายนี้ เนื่องจากมีการด่าว่าและมีพฤติกรรมที่ข่มขู่และรุนแรง

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

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

คำพิพากษาของศาลจังหวัดโตเกียว วันที่ 4 ธันวาคม ปีฮีเซ 19 (2007)

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

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

นอกจากนี้ยังมีบทเรียนที่สำคัญอื่น ๆ ที่เราสามารถเรียนรู้ได้ดังนี้

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

การเตรียมรับมือกับความเสี่ยงจากการลาออกของสมาชิก

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

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

จัดระบบให้ไม่ทำให้ผู้รับผิดชอบรู้สึกโดดเดี่ยว

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

จัดการทีมงานอย่างมีสำรอง

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

ทบทวนการจัดสรรก่อนที่สภาพสุขภาพจะแย่ลง

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

จัดการการเปลี่ยนแปลงและการจัดการเอกสารในโปรเจคอย่างเข้มงวด

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

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

https://monolith.law/corporate/the-minutes-in-system-development[ja]

และเฉพาะเรื่องการเปลี่ยนแปลงข้อกำหนด มีการอธิบายอย่างละเอียดในบทความต่อไปนี้

https://monolith.law/corporate/howto-manage-change-in-system-development[ja]

สรุป

ดังที่ได้กล่าวไปข้างต้นเราได้ทำการอธิบายเรื่องของกฎหมายที่เกี่ยวข้องกับปรากฏการณ์ “การลาออกของสมาชิกในทีม” สำหรับผู้ขาย การต้องรับผิดชอบต่อผู้ใช้งานเกี่ยวกับการลาออกของสมาชิกในทีมนั้น ไม่สามารถปฏิเสธได้ว่าจะเป็นเรื่องที่ยากมากทางกฎหมาย

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

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