ความหมายทางกฎหมายของเป้าหมายการจัดการและเป้าหมายตัวเลขในโปรเจคการพัฒนาระบบ

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

เหตุใดเป้าหมายและวัตถุประสงค์ของการพัฒนาระบบจึงกลายเป็นต้นเหตุของความขัดแย้ง

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

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

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

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

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

เมื่อรวมเนื้อหาทั้งหมดนี้ เราสามารถระบุสิ่งที่สำคัญได้สองประการ

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

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

สถานการณ์ที่เป้าหมายของผู้ใช้มีผลต่อโครงการ

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

• ค่าใช้จ่ายที่ลดลงเนื่องจากการลดการใช้แรงงาน
• การเพิ่มขึ้นของยอดขายและรายได้
• การลดเวลาทำงาน

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

ตัวอย่างคดีศาลที่เป็นปัญหาเกี่ยวกับเป้าหมายในการบริหารงานที่ผู้ใช้ตั้งขึ้น

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

กรณีที่มีเป้าหมายในการเพิ่มความเร็วในการดำเนินงาน

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

• ลดเวลาในการป้อนข้อมูลด้วยมนุษย์ลง 50%
• ทำให้การดำเนินงานด้วยระบบ IT นั้นสามารถเสร็จสิ้นภายในระยะเวลาที่กำหนด

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

และ ตามที่สรุปจากการโต้แย้งทั้งหมด ① วัตถุประสงค์ของกรณีนี้คือ “การเพิ่มประสิทธิภาพของงาน” “การสร้างพื้นฐาน CRM” “การดำเนินการจัดการที่มองเห็นได้” ฯลฯ ซึ่งเป็นสิ่งที่ค่อนข้างนามธรรม และเป้าหมายที่กำหนดไว้ เช่น “เพิ่มจุดติดต่อกับลูกค้า” “แบ่งเวลาทำงานของพนักงานสำนักงานเพื่อควบคุมภายในและสนับสนุนการขาย” “ทำให้การคาดการณ์ยอดขายเป็นไปได้ถูกต้องยิ่งขึ้น” “ควบคุมการลดราคาขายที่มากเกินไป” ฯลฯ ซึ่งเป็นสิ่งที่ค่อนข้างนามธรรม และ “ลดเวลาในการป้อนข้อมูลลง 50%” “ลดเวลาในการสร้างประมูลลง 50%” “ทำให้การเปิดเผยตามกฎหมายสามารถทำได้ภายในระยะเวลาที่กฎหมายกำหนด” ฯลฯ เป็นเป้าหมายที่กำหนด ซึ่งขึ้นอยู่กับวิธีการจัดการและการดำเนินงานของผู้ถูกกล่าวหาหลังจากการนำ SBO เข้ามาใช้ และไม่ใช่สิ่งที่บริษัทพัฒนาระบบที่สนับสนุนการนำเข้าซอฟต์แวร์แพ็คเกจของโจทก์สามารถรับมอบหมายให้บรรลุได้ ② ในบันทึกการประชุมหลังจากเริ่มต้นโปรเจคนี้ ไม่มีการระบุว่ามีการสนทนาเกี่ยวกับการบรรลุวัตถุประสงค์และเป้าหมายที่กำหนดไว้ ③ ในแผนโปรเจคนี้ มีการใช้ภาษาที่ไม่สามารถถือว่ามีลักษณะของสัญญา เช่น “เพื่อที่จะเป็นบริษัทที่เข้าสู่ตลาดหลักทรัพย์” ฯลฯ ถ้าพิจารณาจากสภาพเหล่านี้ โจทก์ได้สร้างคำบรรยายวัตถุประสงค์ของกรณีนี้ในแผนโปรเจคนี้โดยอาศัยคำอธิบายของผู้ถูกกล่าวหา เพื่อที่โปรเจคนี้จะไม่ล้มเหลว และเพื่อที่จะได้รับความเข้าใจร่วมกันเกี่ยวกับวัตถุประสงค์และผลลัพธ์ของโปรเจคนี้ แต่ไม่สามารถยอมรับว่าผู้ถูกกล่าวหาได้มอบหมายให้โจทก์พัฒนาระบบเพื่อบรรลุวัตถุประสงค์ของกรณีนี้ ดังนั้น ไม่สามารถยอมรับว่าโจทก์ได้รับมอบหมายให้พัฒนาระบบเพื่อบรรลุวัตถุประสงค์ของกรณีนี้จากผู้ถูกกล่าวหา ดังนั้น ข้ออ้างเกี่ยวกับความรับผิดชอบในการไม่ปฏิบัติตามหน้าที่และความรับผิดชอบในการรับประกันความบกพร่องไม่มีเหตุผลที่จะยอมรับ

คำพิพากษาของศาลจังหวัดโตเกียว วันที่ 28 ธันวาคม พ.ศ. 2553 (ปี 22 ของฮิเซเซ)

ความหมายทางกฎหมายของเป้าหมายการบริหารและเป้าหมายทางตัวเลขที่สามารถอ่านได้จากตัวอย่างคดี

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

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

ได้รับการประเมินในทางกฎหมายดังกล่าว

สิ่งที่สามารถอ่านเพิ่มเติมจากคำพิพากษานี้

คำพิพากษานี้ยังมีเนื้อหาที่น่าสนใจอีกหลายประการ

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

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

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

ข้อควรระวังเกี่ยวกับปัญหาทางกฎหมายที่เกี่ยวข้องกับเป้าหมายการจัดการและเป้าหมายทางตัวเลข

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

เรื่องจะเปลี่ยนไปขึ้นอยู่กับว่าการให้คำปรึกษาเสียค่าใช้จ่ายหรือไม่

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

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

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

https://monolith.law/corporate/system-flaw-measure-after-acceptance[ja]

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

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

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

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

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

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

ความรับผิดชอบทางกฎหมายนั้นต่างจากความรับผิดชอบทางจริยธรรมที่คลุมเครือ และ “การตรงกันของจินตนาการ” ระหว่างทั้งสองฝ่ายจะสร้างความรับผิดชอบตามสัญญา การเข้าใจในระดับที่เข้มข้นขึ้นนั้นสำคัญมาก