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

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

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

ทำไมโครงการพัฒนาระบบจึงถูก “เปลี่ยนแปลง” หลังจากที่เริ่มต้นแล้ว

การพัฒนาระบบคือการทำงานร่วมกันระหว่างผู้ขายและผู้ใช้

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

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

แม้จะมีหน้าที่ร่วมมือ แต่ผู้ใช้มักจะขอเปลี่ยนแปลง

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

เอกสารการจัดการการเปลี่ยนแปลงคืออะไร

สถานการณ์ที่ใช้เอกสารการจัดการการเปลี่ยนแปลง

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

ตัวอย่างของสถานการณ์ที่ต้องการใช้เอกสารการจัดการการเปลี่ยนแปลง ได้แก่

• ในกรณีที่มีการละเลยในการพิจารณาข้อกำหนดและการออกแบบพื้นฐาน และต้องการขอเพิ่มฟังก์ชันในภายหลัง
• ในระหว่างการพัฒนา ถ้ามีการทบทวนนโยบายธุรกิจ และต้องการเปลี่ยนแปลงข้อกำหนด

เป็นต้น

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

https://monolith.law/corporate/increase-of-estimate[ja]

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

รายการที่ควรระบุในเอกสารการจัดการการเปลี่ยนแปลง

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

(ขั้นตอนการจัดการการเปลี่ยนแปลง)
มาตรา 37 ฝ่าย ก หรือ ฝ่าย ข หากได้รับเอกสารข้อเสนอการเปลี่ยนแปลงตามมาตรา 34 (การเปลี่ยนแปลงของเอกสารข้อกำหนดระบบ) มาตรา 35 (การอนุมัติของผู้ใช้งานต่อเอกสารระหว่างกลาง) มาตรา 36 (การจัดการเรื่องที่ยังไม่ได้ยืนยัน) ภายในวันที่ ○ นับจากวันที่ได้รับ จะต้องส่งเอกสารที่ระบุรายการต่อไปนี้ (ต่อไปนี้เรียกว่า “เอกสารการจัดการการเปลี่ยนแปลง“) ให้กับฝ่ายตรงข้าม และฝ่าย ก และฝ่าย ข จะต้องสนทนาเกี่ยวกับการเปลี่ยนแปลงที่คณะกรรมการติดต่อตามมาตรา 12
① ชื่อของการเปลี่ยนแปลง
② ผู้รับผิดชอบการเสนอ
③ วันที่
④ เหตุผลของการเปลี่ยนแปลง
⑤ รายละเอียดของการเปลี่ยนแปลงที่รวมถึงข้อกำหนดที่เกี่ยวข้อง
⑥ ถ้าการเปลี่ยนแปลงต้องใช้ค่าใช้จ่าย จะต้องระบุจำนวนเงิน
⑦ ตารางงานการทำงานเพื่อการเปลี่ยนแปลง รวมถึงระยะเวลาที่ใช้ในการพิจารณา
⑧ ผลกระทบอื่นๆ ที่การเปลี่ยนแปลงจะมีต่อเงื่อนไขของสัญญานี้และสัญญาเฉพาะ (ระยะเวลาการทำงานหรือกำหนดส่งมอบ ค่าธรรมเนียมสัญญา ข้อกำหนดสัญญา ฯลฯ)

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

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

สิ่งที่ควรทราบเกี่ยวกับการจัดการการเปลี่ยนแปลง

การจัดการการเปลี่ยนแปลงส่วนใหญ่ควรทำร่วมกับการจัดการปัญหา

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

การกำหนดข้อตกลงเกี่ยวกับวิธีการปรึกษาหารือเรื่องการเปลี่ยนแปลงจะเป็นการดี

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

การปรึกษาเรื่องการเปลี่ยนแปลงและหน้าที่ซื่อสัตย์สุจริต

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

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

ตัวอย่างการระบุในสัญญา อาจจะเป็นดังนี้ (อ้างอิงจาก “แบบสัญญาพื้นฐาน/แบบสัญญาเฉพาะของ ff ที่สร้างโดยองค์กรการส่งเสริมการประมวลผลข้อมูลของญี่ปุ่น”):

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

กฎเกณฑ์เกี่ยวกับวิธีการเปลี่ยนแปลง

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

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

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

สรุป

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

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