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

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

เหตุผลที่โครงการจึงถูก ‘ลุกเป็นไฟ’

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

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

เหตุผลที่ทำให้โครงการลุกเป็นไฟอาจแตกต่างกันไปตามโครงการ แต่ถ้ามองจากมุมมองทางกฎหมาย เหตุผลที่ทำให้โครงการลุกเป็นไฟสามารถจัดเรียงได้อย่างง่ายดายโดยอาศัยหลายๆ ประเภท

ประเภทการเผาไหม้ที่ 1: กรณีที่โปรเจคถูกยุติกลางคัน

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

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

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

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

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

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

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

ประเภทการเผาไหม้ที่ 2: กรณีที่ผู้ใช้ยกเลิกด้วยเหตุผลของตนเอง

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

ในทางปฏิบัติ ปัญหาเกี่ยวกับวิธีการสร้างระบบ IT ที่ควรใช้ในองค์กร ไม่สามารถแยกจากปัญหาว่า “มีธุรกิจอะไรบ้างในองค์กรนั้น” ดังนั้น การเปลี่ยนแปลงอย่างมากในโครงสร้างองค์กร การปรับปรุงแผนกธุรกิจ หรือการทบทวนกลยุทธ์อย่างรากฐาน อาจส่งผลต่อความต้องการ (หรือไม่ต้องการ) ของระบบที่เปลี่ยนแปลงหลังจากนั้น

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

・กรณีสัญญาจ้างงาน: มาตรา 641 ของประมวลกฎหมายแพ่งและพาณิชย์ญี่ปุ่น (Japanese Civil Code)
มาตรา 641 ของประมวลกฎหมายแพ่งและพาณิชย์ญี่ปุ่น
→ ผู้รับจ้างยังไม่ได้ทำงานเสร็จสิ้น ผู้ว่าจ้างสามารถยกเลิกสัญญาโดยชดใช้ค่าเสียหายได้ทุกเวลา
・กรณีสัญญามอบหมาย: มาตรา 648 ข้อ 3 และ มาตรา 651 ของประมวลกฎหมายแพ่งและพาณิชย์ญี่ปุ่น (ขึ้นอยู่กับสถานการณ์ อาจมีการเรียกเก็บค่าเสียหายตามมาตรา 651)
มาตรา 648 ของประมวลกฎหมายแพ่งและพาณิชย์ญี่ปุ่น
→ ถ้าการปฏิบัติตามสัญญาสิ้นสุดในระหว่างดำเนินการเนื่องจากเหตุผลที่ไม่สามารถย้อนกลับไปยังผู้รับมอบหมาย ผู้รับมอบหมายสามารถเรียกเก็บค่าตอบแทนตามสัดส่วนของการปฏิบัติที่เสร็จสิ้นแล้ว
มาตรา 651 ของประมวลกฎหมายแพ่งและพาณิชย์ญี่ปุ่น
→ 1. สัญญามอบหมายสามารถยกเลิกได้ทุกเวลาโดยทุกฝ่าย
→ 2. ถ้าฝ่ายใดฝ่ายหนึ่งยกเลิกสัญญามอบหมายในช่วงเวลาที่ไม่เป็นไปในทางที่ดีต่อฝ่ายตรงข้าม ฝ่ายนั้นต้องชดใช้ค่าเสียหายให้กับฝ่ายตรงข้าม แต่ถ้ามีเหตุผลที่ไม่สามารถหลีกเลี่ยงได้ จะไม่มีข้อจำกัดนี้

สรุป

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

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