หน้าที่ในการจัดการโปรเจคในการพัฒนาระบบคืออะไร

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

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

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

หน้าที่ในการจัดการโปรเจคของฝ่ายผู้ขายคืออะไร

เริ่มต้นด้วยการทบทวนหน้าที่ในการจัดการโปรเจคของฝ่ายผู้ขาย

ตามตัวอย่างคดีที่ผ่านมา หน้าที่ในการจัดการโปรเจคของฝ่ายผู้ขายมีดังนี้

– มีหน้าที่ทำงานตามข้อตกลง ดูแลการดำเนินงานอย่างต่อเนื่อง ค้นหาปัญหาที่อาจจะขัดขวางการทำงาน และจัดการกับปัญหาเหล่านั้นอย่างเหมาะสม

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

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

ดังนั้น ผู้ขายมีหน้าที่ที่จะทำงานร่วมกับผู้ใช้ในการตัดสินใจ และทำหน้าที่ให้การพัฒนาระบบสำเร็จ

หน้าที่ในการสนับสนุนของฝ่ายผู้ใช้

อย่างไรก็ตาม ในการพัฒนาระบบ ผู้ขายไม่ได้รับหน้าที่ทั้งหมดโดยเด็ดขาด ในทางปฏิบัติ ระบบ IT ที่ใช้ในองค์กรที่สั่งซื้อ โครงการพัฒนาระบบนี้ไม่ควรเป็นเรื่องที่ไม่เกี่ยวข้องกับฝ่ายที่สั่งซื้อ

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

หน้าที่ในการสนับสนุนของฝ่ายผู้ใช้มีดังนี้

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

　②ตรวจสอบผลงาน

　③ตอบสนองต่อคำขอความช่วยเหลือจากผู้ขาย

ฝ่ายผู้ใช้ต้องสื่อสารฟังก์ชันที่ต้องการจากระบบอย่างชัดเจนกับฝ่ายผู้ขาย และสนับสนุนการพัฒนาอย่างใจจริง

การจัดการโปรเจคไม่ใช่เรื่องง่าย

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

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

สิ่งที่อาจเกิดขึ้นในกรณีที่มีการละเมิดหน้าที่ในการจัดการโปรเจค

แล้วถ้ามีการละเมิดหน้าที่ในการจัดการโปรเจค จะเกิดอะไรขึ้นบ้างในทางปฏิบัติ?

ในเรื่องนี้ ไม่มีข้อบังคับที่ชัดเจนว่า “หน้าที่ในการจัดการโปรเจคคืออะไร” อยู่ในข้อความใดข้อความหนึ่ง

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

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

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

ตัวอย่างคดีศาลที่แสดงถึงหน้าที่ในการจัดการโปรเจค

ตัวอย่างคดีศาลที่อธิบายถึงหน้าที่ในการจัดการโปรเจค ได้แก่คดีต่อไปนี้

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

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

คำพิพากษาของศาลชั้นต้นโตเกียว วันที่ 10 มีนาคม พ.ศ. 2547 (ปีฮีเซ 16)

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

เราจะสรุปและจัดระเบียบเนื้อหาของคำพิพากษาข้างต้นให้ง่ายขึ้น หน้าที่ในการจัดการโปรเจคที่กล่าวถึงในที่นี้คือ

• ดำเนินการตามแผนที่กำหนดไว้ล่วงหน้า (ขั้นตอนการพัฒนา, วิธีการ, กระบวนการทำงาน, ฯลฯ)
• จัดการความคืบหน้าของงาน
• หากมี “ปัจจัยที่ขัดขวาง” ที่ทำให้งานไม่สามารถดำเนินไปอย่างราบรื่น ควรค้นหาและดำเนินการเหมาะสม

นอกจากนี้ สำหรับสิ่งที่กล่าวถึงข้างต้น

• ไม่เพียงแค่พยายามด้วยตนเองของฝ่ายผู้ขาย แต่ยังต้องทำความพยายามในการสื่อสาร โดยขอความร่วมมือจากฝ่ายผู้ใช้เมื่อจำเป็น

สามารถจัดระเบียบได้ว่าเป็นสิ่งที่รวมกัน

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

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

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

ตัวอย่างคดีที่แสดงถึงหน้าที่ในการจัดการโปรเจคที่ถูกกำหนดให้แม้ก่อนที่จะทำสัญญา

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

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

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

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

คำสั่งศาลสูงสุดของโตเกียว วันที่ 26 กันยายน พ.ศ. 2556 (2013)

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

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

มาตรา 1 ข้อ 2 ของกฎหมายญี่ปุ่น
การใช้สิทธิ์และการปฏิบัติตามหน้าที่ต้องดำเนินการอย่างซื่อสัตย์และจริงใจ

คำสำคัญที่แสดงถึงเนื้อหาด้านบนอย่างกระชับคือ “หลักศีลธรรม” ในคำสั่งศาล

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

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

สรุป: หากมีปัญหาเกี่ยวกับการผิดหมายภายใต้หน้าที่การจัดการโปรเจค ควรปรึกษาทนายความ

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

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

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

หากมีปัญหาเกี่ยวกับการผิดหมายภายใต้หน้าที่การจัดการโปรเจค ควรปรึกษาทนายความทันที