ปัญหาเกี่ยวกับกฎหมายและสัญญาที่เกี่ยวข้องกับการพัฒนาแบบ Agile คืออะไร
มีวิธีการทางทฤษฎีในการดำเนินการพัฒนาระบบ วิธีที่เป็นคลาสสิกและทั่วไปที่สุดคือ โมเดลวอเตอร์ฟอลล์ (Waterfall Model) ซึ่งหนังสือกฎหมายที่จัดการกับการพัฒนาระบบมากมาย ก็มักจะอ้างอิงโมเดลนี้เป็นหลัก ในบทความนี้ เราจะอธิบายเกี่ยวกับปัญหาทางกฎหมายที่อาจเกิดขึ้นในการพัฒนาระบบที่อ้างอิงตามโมเดลการพัฒนาแบบอ agile ซึ่งเป็นข้อมูลที่ยากที่จะหาได้จากหนังสือหรือแหล่งข้อมูลอื่นๆ
การพัฒนาแบบ Agile และกฎหมาย
โมเดลในการพัฒนาระบบคืออะไร
ในโปรเจคการพัฒนาระบบ มีสิ่งที่เรียกว่า “โมเดลการพัฒนา” ที่ใช้เป็นกรอบการทำงานเพื่อควบคุมความคืบหน้าของโปรเจค โมเดลที่เป็นตัวแทนคือ “Waterfall Model” หรือ “โมเดลน้ำตก” ซึ่งเหมือนกับการที่น้ำจะไหลจากด้านบนลงด้านล่างของน้ำตก โดยที่จะทำงานตามขั้นตอนต่างๆ เช่น การกำหนดความต้องการ การออกแบบ การสร้าง และการทดสอบ โดยไม่มีการย้อนกลับ นี่คือวิธีการที่มุ่งเน้นที่จะลดการทำซ้ำและการกลับมาทำใหม่ และเหมาะสำหรับการทำงานที่มีการวางแผนอย่างรอบคอบ
ในขณะเดียวกัน โมเดลการพัฒนาแบบ Agile จะทำการสร้างและทดสอบโปรแกรมขนาดเล็กๆ แล้วทำซ้ำขั้นตอนนี้อีก ด้วยวิธีนี้ ระบบขนาดใหญ่จะถูกสร้างขึ้นอย่างทีละขั้นตอน สำหรับคำอธิบายที่ละเอียดขึ้นเกี่ยวกับโมเดลการพัฒนาระบบนี้ และการเปรียบเทียบข้อดีและข้อเสียของทั้งสองโมเดลการพัฒนา สามารถอ่านได้ในบทความด้านล่างนี้
https://monolith.law/corporate/legal-merits-and-demerits-of-development-model[ja]
คุณสมบัติของโมเดลการพัฒนาแบบ Agile
ข้อดีใหญ่ของการพัฒนาด้วยโมเดล Agile คือ ความรวดเร็วในการเริ่มต้นการทำงาน การกำหนดความต้องการและการสร้างเอกสารออกแบบ หรือ “ขั้นตอนด้านบน” และการสร้างโปรแกรมไม่ได้แยกจากกัน ดังนั้น การเพิ่มฟังก์ชัน การแก้ไข และการเปลี่ยนแปลงข้อกำหนด รวมถึงการปรับเปลี่ยนทิศทางการทำงาน สามารถทำได้อย่างยืดหยุ่น จากมุมมองทางกฎหมาย สิ่งที่สำคัญในการทำให้โมเดลการพัฒนาแบบ Agile ประสบความสำเร็จคือ การจัดการเอกสารและการจัดการการเปลี่ยนแปลง ในโมเดล Agile ไม่มีการแบ่งหน้าที่และความรับผิดชอบที่ชัดเจนเท่ากับโมเดลน้ำตก นอกจากนี้ การเน้นที่ “ความรวดเร็ว” ในการดำเนินการและเริ่มต้น มักจะทำให้เอกสารออกแบบ ข้อกำหนด และบันทึกการประชุมไม่สมบูรณ์
เพิ่มเติมเกี่ยวกับการจัดการการเปลี่ยนแปลง โมเดล Agile สามารถตอบสนองต่อการเปลี่ยนแปลงได้อย่างราบรื่น ซึ่งอาจทำให้เกิดความเสี่ยงที่โปรเจคจะล้มเหลว เนื่องจากการข้ามกระบวนการอนุมัติจากผู้ตัดสินใจ และตอบสนองต่อคำขอเปลี่ยนแปลงข้อกำหนดในระดับสถานที่ทำงาน ถ้าเกิดสถานการณ์นี้ขึ้น “ความราบรื่นในการตอบสนองต่อการเปลี่ยนแปลง” ซึ่งเป็นข้อดีของโมเดลการพัฒนา อาจกลายเป็นความเสี่ยงที่ทำให้โปรเจคล้มเหลว
วิธีการจัดการเอกสารและการจัดการการเปลี่ยนแปลงในการพัฒนาแบบ Agile
ความสำคัญของการจัดการเอกสาร
ในโครงการพัฒนาที่อิงตามรูปแบบการพัฒนาแบบ Agile จุดที่น่าเป็นห่วงทางกฎหมายคือการสื่อสารทางปากที่สะสมขึ้น ซึ่งจะนำไปสู่การขาดแคลนเอกสาร ในที่นี้ เราได้ทำการอธิบายรายละเอียดเกี่ยวกับเหตุผลที่การจัดการเอกสารในโครงการพัฒนาระบบเป็นเรื่องที่สำคัญในบทความต่อไปนี้
https://monolith.law/corporate/the-minutes-in-system-development[ja]
ในบทความนี้ เราได้อธิบายความสำคัญของการจัดการเอกสารในโครงการพัฒนาระบบจากมุมมองสองประการ คือ การป้องกันความขัดแย้งล่วงหน้า (หรือ “การบริหารกฎหมายเพื่อการป้องกัน”) และการรักษาหลักฐานเมื่อเกิดความขัดแย้ง (หรือ “การจัดการวิกฤต”).
การตั้งคณะกรรมการสื่อสารเป็นวิธีที่มีประสิทธิภาพในการจัดการเอกสาร
ในกรณีที่ใช้โมเดลการพัฒนาแบบ Agile จะแตกต่างจากโมเดล Waterfall ที่มีแผนที่ชัดเจนล่วงหน้า ดังนั้น การจัดการเพียงเพื่อให้แผนและผลการดำเนินงานสอดคล้องกันไม่เพียงพอ มีความกังวลว่าหากปล่อยให้สถานที่ทำงานทำตามความพอใจ ค่าใช้จ่ายทั้งทางการเงินและเวลาจะเพิ่มขึ้นอย่างมาก
ดังนั้น มาตรการที่มีประสิทธิภาพคือ ผู้รับผิดชอบควรจัดการประชุมคณะกรรมการสื่อสารอย่างประจำเพื่อให้โครงการดำเนินไปอย่างราบรื่น ในกรณีที่มีขนาดการพัฒนาที่เล็ก จริงๆ แล้ว การจัดการประชุมคณะกรรมการสื่อสารอย่างประจำอาจจะไม่ได้รับการยอมรับเท่าการที่ผู้รับผิดชอบรวมตัวกันเมื่อมีโอกาส แต่ในกรณีของโมเดลการพัฒนาแบบ Agile ความเสี่ยงที่จะพลาดการจัดการปัญหาที่ตรงต่อเวลาในการประชุมมากขึ้น ดังนั้น การจัดการประชุมคณะกรรมการสื่อสารอย่างประจำควรถูกนำมาใส่ในสัญญาและเอกสารอื่นๆ ด้วย สำหรับวิธีการกำหนด ในสัญญาแบบ Ministry of Economy, Trade and Industry (METI) ของญี่ปุ่น จะแสดงดังนี้
(การตั้งคณะกรรมการสื่อสาร)
ข้อ 12 ทั้งสองฝ่ายจะต้องจัดการประชุมคณะกรรมการสื่อสารเพื่อสนทนาเรื่องการดำเนินงาน สถานะการดำเนินงาน การจัดการและรายงานความเสี่ยง การทำงานร่วมกันและการดำเนินงานที่แบ่งหน้าที่ของทั้งสองฝ่าย การยืนยันเนื้อหาที่ควรรวมในเอกสารข้อกำหนดระบบ การสนทนาและการแก้ไขปัญหา และเรื่องอื่นๆ ที่จำเป็นสำหรับการดำเนินงานอย่างราบรื่น จนกว่างานนี้จะสิ้นสุดลง แต่ (ตัดออก)
2. คณะกรรมการสื่อสารจะต้องจัดการประชุมอย่างประจำตามความถี่ที่กำหนดในสัญญาแต่ละรายการ นอกจากนี้ จะต้องจัดการประชุมเมื่อทั้งสองฝ่ายเห็นว่าจำเป็น
3. ในการประชุมคณะกรรมการสื่อสาร ผู้รับผิดชอบและผู้รับผิดชอบหลักจากทั้งสองฝ่าย และผู้ที่ผู้รับผิดชอบคิดว่าเหมาะสมจะต้องเข้าร่วม นอกจากนี้ ทั้งสองฝ่ายสามารถขอให้ผู้ที่จำเป็นสำหรับการสนทนาในการประชุมคณะกรรมการสื่อสารเข้าร่วม และฝ่ายตรงข้ามจะต้องตอบสนอง ยกเว้นกรณีที่มีเหตุผลที่เหมาะสม
4. ฝ่ายที่รับผิดชอบจะต้องสร้างรายงานการจัดการความคืบหน้าตามรูปแบบที่ทั้งสองฝ่ายตกลงกันและส่งมอบในการประชุมคณะกรรมการสื่อสาร และตรวจสอบสถานะการดำเนินงานตามรายงานการจัดการความคืบหน้า รวมถึงการสนทนาและตัดสินใจเรื่องที่ต้องการ อาทิ เช่น มีการล่าช้าหรือไม่ ถ้ามีการล่าช้า ความจำเป็นในการเปลี่ยนแปลงโครงสร้างการส่งเสริม (การเปลี่ยนแปลงบุคลากร การเพิ่มหรือลด การเปลี่ยนแปลงผู้รับเหมาที่รับมอบหมาย) สถานะการดำเนินการด้านความปลอดภัย มีเหตุผลที่จำเป็นต้องเปลี่ยนแปลงสัญญาแต่ละรายการหรือไม่ ถ้ามีเหตุผลที่จำเป็นต้องเปลี่ยนแปลงสัญญาแต่ละรายการ จะต้องสนทนาเรื่องนั้น และยืนยันเรื่องที่ตัดสินใจ และเรื่องที่ต้องการศึกษาต่อ และถ้ามีเรื่องที่ต้องการศึกษาต่อ จะต้องยืนยันตารางเวลาการศึกษาและผู้ที่จะทำการศึกษา
(ข้อ 5, 6, 7 ถูกตัดออก)
จุดสำคัญที่สุดคือ การมีคณะกรรมการสื่อสาร และการให้ความถูกต้องตามข้อตกลงในสัญญา ทำให้มีความหมายที่แตกต่างจากการประชุมที่จัดขึ้นอย่างสะเพร่า
การนำการประชุมสื่อสารไปใช้ในการจัดการการเปลี่ยนแปลง
ในการพัฒนาแบบ Agile นั้น การที่ทั้งสองฝ่ายเปลี่ยนแปลงสิ่งที่ตกลงกันตั้งแต่แรกในภายหลังเป็นสิ่งที่ถูกตั้งเป็นข้อตกลงเบื้องต้น ดังนั้น การจัดการสถานการณ์การเปลี่ยนแปลงข้อกำหนดในภายหลังจึงมีความสำคัญอย่างยิ่ง
ในกรณีนี้ หากมีการประชุมสื่อสารเป็นประจำ การจัดการการเปลี่ยนแปลงและวิธีการจะทำให้ง่ายขึ้นอย่างมาก ตัวอย่างเช่น การประชุมเพื่อการเปลี่ยนแปลงจะทำในการประชุมสื่อสาร และในกรณีที่มีการขอประชุมเพื่อการเปลี่ยนแปลงจากฝ่ายหนึ่ง ฝ่ายตรงข้ามจะต้องมีหน้าที่ตอบสนองการประชุมนั้นตามสัญญา (ดังที่แสดงในข้อกำหนดของสัญญาแบบ Ministry of Economy, Trade and Industry ของญี่ปุ่นด้านล่างนี้)
(ขั้นตอนการจัดการการเปลี่ยนแปลง)
มาตรา 37 ฝ่าย A หรือ B ในกรณีที่ได้รับเอกสารเสนอการเปลี่ยนแปลง (ตัดออก) จากฝ่ายตรงข้าม ภายใน ○ วัน นับจากวันที่ได้รับ จะต้องส่งเอกสารที่ระบุรายละเอียดต่อไปนี้ (ที่เรียกว่า “เอกสารการจัดการการเปลี่ยนแปลง”) ให้กับฝ่ายตรงข้าม และฝ่าย A และ B จะต้อง ประชุมเพื่อสนทนาเกี่ยวกับการเปลี่ยนแปลงที่การประชุมสื่อสารตามมาตรา 12 (รายละเอียดถูกตัดออก)
จุดสำคัญของข้อกำหนดดังกล่าวสามารถจัดเรียงได้ดังนี้
- การรับการเสนอการเปลี่ยนแปลงผ่าน “เอกสารเสนอการเปลี่ยนแปลง” ที่มีรูปแบบเดียวกัน
- การตั้งกำหนดเวลาสำหรับการสนทนาเกี่ยวกับเอกสารเสนอที่ได้รับ → ไม่จำเป็นต้องเขียนว่า “ภายใน ◯ วัน” แต่อาจจะใช้คำว่า “โดยเร็วที่สุด” แทน
- การรวมการสนทนาเกี่ยวกับการเปลี่ยนแปลงทั้งหมดใน “การประชุมสื่อสาร”
นั่นคือ การทำให้กระบวนการทำงานชัดเจนเพื่อป้องกันความเข้าใจผิดเกี่ยวกับ “การเสนอการเปลี่ยนแปลง” หรือ “การตอบสนองต่อการเปลี่ยนแปลง” ที่เกิดจากการสื่อสารทางปากเป็นหลัก
ความเข้าใจในหน้าที่ซื่อสัตย์และกฎหมายที่มีศักดิ์ศรีถูกทดสอบ
จนถึงตอนนี้ เราได้แนะนำแบบฟอร์มของข้อตกลงที่เกี่ยวข้องกับ “คณะกรรมการติดต่อประสานงาน” และ “การปรึกษาเรื่องการเปลี่ยนแปลง” แต่สิ่งที่สำคัญสำหรับการเข้าใจเหล่านี้อย่างแท้จริงคือ การเข้าใจในเรื่อง “หน้าที่ซื่อสัตย์” และ “กฎหมายที่มีศักดิ์ศรี” โดยเฉพาะอย่างยิ่งในรูปแบบการพัฒนา Agile นั้น มักจะยากที่จะดำเนินการไปถ้าไม่มีความไว้วางใจระหว่างผู้สั่งซื้อและผู้รับสั่งซื้อ เพราะเรามักจะให้ความสำคัญกับความเร็วในการเริ่มต้นการทำงาน และขั้นตอนที่จำเป็นในการเริ่มต้นนั้นมักจะถูกลดลงเป็นอย่างน้อย ดังนั้น การรวมข้อตกลงที่กำหนด “หน้าที่ซื่อสัตย์” ให้กับฝ่ายตรงข้ามนั้นก็จะเพิ่มขึ้นในทางปฏิบัติ
ข้อ 4 ย่อย 3 ในการปรึกษาเรื่องการเปลี่ยนแปลง ต้องพิจารณาเรื่องที่จะเปลี่ยน ความเป็นไปได้ในการเปลี่ยน ผลกระทบที่เกิดจากการเปลี่ยนต่อค่าใช้จ่ายและกำหนดเวลา และทั้งสองฝ่ายต้องปรึกษากันอย่างซื่อสัตย์เกี่ยนกับการทำการเปลี่ยนแปลง
นี่คือการป้องกันวิธีการที่จะทำให้ฝ่ายตรงข้ามรู้สึกถูกทอดทิ้ง ด้วยการอ้างว่า “การตัดสินใจเรื่องการเปลี่ยนแปลงข้อตกลงนั้นขึ้นอยู่กับฝ่ายที่ได้รับข้อเสนออย่างเดียว และไม่มีหน้าที่ที่จะต้องยอมรับการบังคับ” ในการเจรจาที่ได้รับความไว้วางใจตั้งแต่แรก นอกจากนี้ นี่ยังเป็นการสะท้อนถึงหลักการของกฎหมายที่เกี่ยวข้องกับการซื้อขายระหว่างบุคคลธรรมดา ไม่ว่าจะเป็นการพัฒนาระบบหรือไม่
กฎหมายญี่ปุ่น บทที่ 1 ย่อย 2
การใช้สิทธิ์และการปฏิบัติตามหน้าที่ต้องดำเนินการอย่างมีศักดิ์ศรีและซื่อสัตย์
กฎหมายไม่ได้ให้ความสำคัญเฉพาะแค่ “เนื้อหาที่ระบุในสัญญา” หรือ “คำพูดในข้อบังคับ” เท่านั้น โดยเฉพาะอย่างยิ่งในการซื้อขายที่มีฝ่ายตรงข้าม ควรใช้กฎหมายอย่างยืดหยุ่นโดยรวม “ศักดิ์ศรี” และ “ความซื่อสัตย์” ที่เป็นจริง นอกจากนี้ สำหรับ “หน้าที่” ที่กำหนดโดยกฎหมาย ซึ่งไม่จำเป็นต้องมี “สัญญา” เป็นพื้นฐาน คุณสามารถดูรายละเอียดเพิ่มเติมในบทความด้านล่างนี้
https://monolith.law/corporate/system-development-unlawful-responsibility[ja]
สรุป
ในโครงการพัฒนาระบบที่อิงตามโมเดลการพัฒนาแบบ Agile การเข้าใจความเสี่ยงที่กระบวนการทำงานและระบบการจัดการอาจจะเริ่มหลุดลอยและไม่รูปธรรมเป็นเรื่องที่สำคัญอย่างยิ่ง แต่นอกจากนั้น การเข้าใจลักษณะที่ยืดหยุ่นของกฎหมายที่มีรากฐานอยู่ที่ “หลักศีลธรรม” และการนำมาใช้ในการปฏิบัติงานจริง ก็ถือเป็นเรื่องที่สำคัญเช่นกัน
Category: IT
Tag: ITSystem Development