MONOLITH LAW OFFICE+81-3-6262-3248วันธรรมดา 10:00-18:00 JST [English Only]

MONOLITH LAW MAGAZINE

IT

ปัญหาเกี่ยวกับกฎหมายและสัญญาที่เกี่ยวข้องกับการพัฒนาแบบ Agile คืออะไร

IT

ปัญหาเกี่ยวกับกฎหมายและสัญญาที่เกี่ยวข้องกับการพัฒนาแบบ Agile คืออะไร

มีวิธีการทางทฤษฎีในการดำเนินการพัฒนาระบบ วิธีที่เป็นคลาสสิกและทั่วไปที่สุดคือ โมเดลวอเตอร์ฟอลล์ (Waterfall Model) ซึ่งหนังสือกฎหมายที่จัดการกับการพัฒนาระบบมากมาย ก็มักจะอ้างอิงโมเดลนี้เป็นหลัก ในบทความนี้ เราจะอธิบายเกี่ยวกับปัญหาทางกฎหมายที่อาจเกิดขึ้นในการพัฒนาระบบที่อ้างอิงตามโมเดลการพัฒนาแบบอ agile ซึ่งเป็นข้อมูลที่ยากที่จะหาได้จากหนังสือหรือแหล่งข้อมูลอื่นๆ

การพัฒนาแบบ Agile และกฎหมาย

เราจะอธิบายเกี่ยวกับคุณสมบัติของการพัฒนาแบบ Agile

โมเดลในการพัฒนาระบบคืออะไร

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

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

https://monolith.law/corporate/legal-merits-and-demerits-of-development-model[ja]

คุณสมบัติของโมเดลการพัฒนาแบบ Agile

ข้อดีใหญ่ของการพัฒนาด้วยโมเดล 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 การเข้าใจความเสี่ยงที่กระบวนการทำงานและระบบการจัดการอาจจะเริ่มหลุดลอยและไม่รูปธรรมเป็นเรื่องที่สำคัญอย่างยิ่ง แต่นอกจากนั้น การเข้าใจลักษณะที่ยืดหยุ่นของกฎหมายที่มีรากฐานอยู่ที่ “หลักศีลธรรม” และการนำมาใช้ในการปฏิบัติงานจริง ก็ถือเป็นเรื่องที่สำคัญเช่นกัน

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.

Category: IT

Tag:

กลับไปด้านบน