วิธีการจัดการเมื่อการพัฒนาระบบถูกหยุดชะงักเนื่องจากสภาพการณ์ของผู้ใช้งาน

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

ในบทความนี้ เราจะจัดเรียงลักษณะเฉพาะของสัญญาในการพัฒนาระบบ และอธิบายวิธีการตอบสนองในสถานการณ์ดังกล่าว

ความสำคัญของการพิจารณาเรื่องการหยุดงานที่เกิดจากความต้องการของผู้ใช้

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

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

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

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

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

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

เริ่มต้นด้วยการจัดเรียงเหตุผลที่ต้องการยกเลิกสัญญา

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

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

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

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

ตรวจสอบข้อบังคับที่เป็นหลักสำคัญสำหรับการเรียกร้องค่าตอบแทนและค่าเสียหาย

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

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

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

และในกรณีของสัญญาแทนและสัญญาทำจ้าง กฎหมายญี่ปุ่นกำหนดดังนี้

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

b.) ในกรณีของสัญญาทำจ้าง
การเรียกร้องค่าเสียหาย: กฎหมายญี่ปุ่น มาตรา 641
ผู้ว่าจ้างสามารถยกเลิกสัญญาได้เมื่อใดก็ตามโดยชดใช้ค่าเสียหาย ถ้าผู้รับจ้างยังไม่ได้ทำงานเสร็จ

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

อย่างไรก็ตาม ในกรณีของค่าเสียหายตามกฎหมายญี่ปุ่น มาตรา 641 มักจะมีกรณีที่สัญญาเฉพาะระหว่างผู้ขายและผู้ใช้ได้กำหนดว่าจะไม่รวมเป็นส่วนหนึ่งของค่าเสียหาย ในกรณีเช่นนี้ สัญญาที่ทั้งสองฝ่ายทำกัน (= สัญญา) จะมีความสำคัญมากกว่า และกฎหมายญี่ปุ่นที่กล่าวถึงจะไม่มีผล ดังนั้น ควรให้ความสำคัญ

การพยายามเพิ่มการพิสูจน์ความสามารถในการทำงานและความเสียหาย

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

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

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

สิ่งที่ผู้ใช้ควรพิจารณาจากมุมของตนเองคืออะไร

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

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

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

https://monolith.law/corporate/system-development-contract[ja]

สรุป

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

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