เมื่อเร็วๆ นี้ ผมเห็นวลี "Contract Development is Dead" บ่อยมากบนไทม์ไลน์ของผม มักจะพูดถึงในบริบทที่ AI ทำให้การพัฒนาซอฟต์แวร์เร็วขึ้นและถูกลง ส่งผลให้โมเดลดั้งเดิมอย่าง "การสร้างและส่งมอบตามที่ลูกค้าต้องการ" กำลังสูญเสียคุณค่าไปอย่างรวดเร็ว
ตอนแรกผมก็คิดว่า "นี่มันแค่วงจร hype 'X is dead' อีกแล้วรึเปล่า?"
ก็เพราะว่าผู้คนพูดกันมานานหลายทศวรรษแล้วว่า "Contract development is dead" ตั้งแต่ก่อนยุค AI เสียอีก การทำ In-house development, คลาวด์, การรับเหมาช่วงหลายชั้น, การ Offshore — ทุกครั้งก็จะมีคนบอกว่า "คราวนี้มันจะตายจริงๆ แล้วนะ" แต่ Contract development ก็ยังคงอยู่รอดเหมือนซอมบี้
จริงๆ แล้ว ผมเคยทำงานให้กับบริษัทผลิตภัณฑ์มาหลายปี เลยมักจะมองประเด็นพวกนี้จากข้างสนาม ตอนนั้นผมคิดว่างานรับจ้างพัฒนาดูยากและเป็นอะไรที่ผมไม่อยากเข้าใกล้
จากนั้น สามปีที่แล้ว ผมเข้าร่วม Hololab Inc. และตอนนี้ผมก็ทำงานใกล้ชิดกับลูกค้า รวมถึงงานรับจ้างพัฒนา (contract development) ด้วย พอเข้าไปอยู่ตรงนั้นจริงๆ คำว่า "รับจ้างพัฒนา" ก็ทำให้ผมอึ้งเหมือนกันนะ แต่ความท้าทายในการเปลี่ยนแปลงที่มาพร้อมกับเทคโนโลยีใหม่ และเสน่ห์ของตัวบริษัทเอง ก็เอาชนะใจผมได้ คิดไปคิดมา การบ่นเรื่อง "รับจ้างพัฒนา" โดยที่ยังไม่ได้ลองทำจริงๆ ก็ดูไม่ค่อยเท่เท่าไหร่
ผ่านมาสามปีแล้วนับตั้งแต่นั้น ผมเข้าร่วมทีมบริหารและเผชิญหน้ากับงานรับจ้างพัฒนาแบบตรงๆ นั่นเป็นเหตุผลว่าทำไมครั้งนี้ผมถึงอยากเผชิญหน้ากับวลี "Contract Development is Dead" โดยไม่หนีอีกต่อไป
"Contract Development is Dead" จริงหรือ?
จริงครับ
แม้กระทั่งก่อนยุค AI ก็มีการเคลื่อนไหวไปสู่ no-code ในบริบทของ DX (Digital Transformation) และกระแสการทำ in-house development แล้ว จากนั้นคลื่นของ AI (โดยเฉพาะ AI agents) ก็มาถึง และแนวโน้มนี้ก็ทวีความรุนแรงขึ้นทันที แม้แต่วิศวกรที่ไม่ใช่ก็สามารถสร้างซอฟต์แวร์ได้แล้ว
เมื่อประเด็นนี้ถูกหยิบยกขึ้นมา วิศวกรที่ใช้มันหาเลี้ยงชีพมักจะโวยวายเรื่อง "คุณภาพ" หรือ "ความปลอดภัย" โดยเถียงว่า "การพัฒนาซอฟต์แวร์ไม่ได้ง่ายขนาดนั้น"
อย่างไรก็ตาม คุณภาพที่ต้องการสำหรับซอฟต์แวร์นั้นแตกต่างกันไปตามวัตถุประสงค์และกรณีการใช้งาน ซอฟต์แวร์สำหรับลูกค้าหรือสภาพแวดล้อมการผลิตต้องการระดับบริการที่แน่นอน ในทางกลับกัน ระดับที่ต้องการสำหรับเครื่องมือภายในหรือ PoC (Proof of Concept) มักจะต่ำกว่า และนี่คือจุดที่ถูกแทนที่โดย AI agents ได้ง่าย หรือพูดให้ถูกคือ การแทนที่ได้เริ่มขึ้นแล้ว
ในเรื่องความปลอดภัยและคุณภาพ ผมรู้สึกว่าช่องว่างนั้นแคบลงทุกปีเมื่อโมเดลพัฒนาและความรู้ของมนุษย์เกี่ยวกับการใช้ AI สะสมมากขึ้น เมื่อสองสามปีที่แล้ว มุมมองหลักคือ "AI ช่วยได้ แต่ยังเร็วเกินไปที่จะให้มันเขียนโค้ด" แต่ตอนนี้ AI กลับเขียนโค้ดบ่อยกว่ามนุษย์เสียอีก เมื่อดูจากความเร็วของการเปลี่ยนแปลงนี้ แม้ในพื้นที่ที่ปัจจุบันยากจะมอบหมายให้ AI ทำทั้งหมด สถานการณ์ที่ "AI เชื่อถือได้มากกว่ามนุษย์" ก็อาจเกิดขึ้นได้ง่ายในอนาคตอันใกล้
บอกตามตรง ในฐานะวิศวกรคนหนึ่ง ส่วนหนึ่งของผมก็ไม่อยากเชื่อว่างานที่ผมทำมานั้นจะถูกแทนที่ได้ง่ายๆ แต่ผมเห็นสิ่งที่กำลังตายไปต่อหน้าต่อตาอย่างชัดเจน นี่ไม่ใช่ hype หรือการพูดเพื่อจุดยืน แต่เป็นการเปลี่ยนแปลงที่กำลังเกิดขึ้นจริง
อย่างไรก็ตาม นี่ไม่ได้หมายความว่า "contract development โดยรวมกำลังจะตาย" สิ่งที่กำลังตายไม่ใช่ contract development แต่เป็น การพัฒนาซอฟต์แวร์ที่เป็นแค่ "การสร้าง" ผมจะอธิบายว่าทำไมผมถึงคิดแบบนั้น
1. เราไม่สามารถเหมารวม "Contract Development" ทั้งหมดได้
ถึงแม้จะพูดว่า "contract development" คำเดียว เนื้อหาก็แตกต่างกันไป ตั้งแต่บริษัทที่ขายแค่ man-months ไปจนถึง SIer, ที่ปรึกษา, product partners, PMO และการสนับสนุน DX ดังนั้นคำถามที่ต้องถามไม่ใช่ "Contract development กำลังจะตายหรือ?" แต่คือ "อะไรกันแน่ที่กำลังจะตาย?"
เมื่อแยกย่อยแล้ว คุณค่าที่ลดลงเนื่องจาก AI ไม่ได้เกิดขึ้นพร้อมกันทั้งหมด แต่เกิดขึ้นเป็นระยะ คลื่นลูกแรกกระทบคุณค่าของการ "เขียนโค้ด" จริงอยู่ที่ผลิตภาพในการพัฒนาสูงขึ้น และโครงสร้างกำไรของโครงการเริ่มเปลี่ยนไป
และคลื่นนี้จะไม่หยุดแค่การเขียนโค้ด มันจะค่อยๆ แพร่กระจายไปสู่การออกแบบ การกำหนดความต้องการ และขั้นตอนการสร้างแนวคิดก่อนหน้านั้น นั่นเป็นเหตุผลว่าทำไมผมถึงอยากแยกแยะว่าคุณค่าใดจะลดลงก่อนและคุณค่าใดจะยังคงอยู่
ดังนั้น สิ่งที่กำลังตายคืองานที่ "แค่เขียนโค้ดตามที่ถูกบอก" ไม่ว่าจะเป็น contract development หรือไม่ก็ไม่สำคัญ และพื้นที่นี้กำลังหดตัวลงแล้ว
อย่างไรก็ตาม การหดตัวนั้นไม่เท่ากัน ผู้รับจ้างพัฒนาขนาดเล็กถึงกลาง และการพัฒนา in-house ขนาดเล็ก กำลังเผชิญกับคลื่นลูกใหญ่ของการทำ in-house และ generative AI อย่างเต็มที่ และโครงการต่างๆ ก็เริ่มหายไป ในทางกลับกัน ผมได้ยินว่าระบบที่ซับซ้อนสำหรับองค์กรขนาดใหญ่ยังไม่เดือดร้อนมากนัก เพราะทีม in-house เพียงอย่างเดียวจัดการไม่ได้ ผลกระทบแตกต่างกันอย่างมากตามขนาดและกลุ่มลูกค้า ดังนั้นการปนกันไปมาจึงทำให้บทสนทนาไม่ชัดเจน
2. ลูกค้าไม่ได้ซื้อ "โค้ด" ตั้งแต่แรก
เมื่อคิดว่าลูกค้าจ้างเพราะต้องการให้เขียนโค้ด คำตอบคือไม่
สิ่งที่ลูกค้าคาดหวังคือการแก้ปัญหา: พวกเขาต้องการจัดระเบียบกลยุทธ์ทางธุรกิจ คิดความต้องการร่วมกัน ขอความช่วยเหลือในการตัดสินใจ ช่วยประสานงานภายใน และลดความเสี่ยง โค้ดเป็นเพียงหนทางหนึ่งไปสู่จุดจบนั้น
เมื่อคิดแบบนี้ ตรรกะที่ว่า "โค้ดถูก = contract development ตาย" นั้นค่อนข้างสายตาสั้น วิธีการถูกลง แต่สาระสำคัญที่คาดหวังไม่ได้หายไปเลย
สิ่งนี้สอดคล้องกับประสบการณ์ของผมเองที่ทำงานทั้งในบริษัทผลิตภัณฑ์และงานรับจ้างพัฒนา มีไซต์งานรับจ้างพัฒนาที่ดำดิ่งลึกเข้าไปในธุรกิจ และมีทีมพัฒนา in-house ที่ทำตัวเหมือนผู้รับเหมาภายใน แค่สร้างสิ่งที่แผนกธุรกิจบอก การแบ่งเส้นแบ่งระหว่าง "บริษัทผลิตภัณฑ์ vs. รับจ้างพัฒนา" นั้นไม่สะท้อนความเป็นจริงอีกต่อไป
ยิ่งไปกว่านั้น นี่ไม่ใช่แค่เรื่องของ contract development เส้นแบ่งระหว่างการพัฒนาและการให้คำปรึกษาก็กำลังละลายเช่นกัน บริษัทที่ปรึกษากำลังสร้างทีมพัฒนามากขึ้น และ SIer ก็เริ่มให้การสนับสนุนธุรกิจ "SaaS กำลังจะตาย" ก็มีโครงสร้างเดียวกัน: บริษัทที่ขายแค่ซอฟต์แวร์จบ ขณะที่บริษัทที่ดำดิ่งสู่ BPO, การดำเนินงาน, ความร่วมมือ และการรับประกันผลงานกำลังเติบโต ที่ปรึกษา, SIer, SaaS และบริษัทผลิตภัณฑ์ล้วนทับซ้อนกันมากขึ้นเรื่อยๆ จุดหมายปลายทางคือ "คุณค่า" สำหรับลูกค้า
3. "การคิด" และ "การสร้าง" กำลังใกล้ชิดกันมากขึ้น
เป็นเวลานานที่ต้นทุนในการสร้างซอฟต์แวร์สูงเกินไป ดังนั้น "การคิด" และ "การสร้าง" จึงถูกแยกออกจากกันอย่างหลีกเลี่ยงไม่ได้ บทบาทถูกแบ่ง ตำแหน่งงานถูกแบ่ง องค์กรถูกแบ่ง และแม้แต่บริษัทก็มักถูกแบ่ง
AI ทำให้ต้นทุนของ "การสร้าง" ลดลง ผลที่ตามมาคือ "การคิด" และ "การสร้าง" เริ่มมาบรรจบกันโดยธรรมชาติ บทบาท ตำแหน่งงาน องค์กร และบริษัทต่างก็ใกล้ชิดกันมากขึ้น นี่คือการเปลี่ยนแปลงที่เกิดขึ้นในตอนนี้
และสิ่งที่ Agile development ต้องการบรรลุก็คือสิ่งนี้: การนำ "การคิด" และ "การสร้าง" ให้ใกล้ชิดกันมากขึ้น ในที่สุดเราก็เข้าใกล้อุดมคติที่ไม่สามารถทำได้อย่างเต็มที่ในตอนนั้น เพราะต้นทุนในการสร้างสูงเกินไป
ในความเป็นจริง ในงานลูกค้าของเราเอง กรณีที่ไม่จบแค่การพัฒนากำลังเพิ่มขึ้น สิ่งที่เริ่มต้นจากการพัฒนาทั่วไป มักจะกลายเป็น "เราอยากปรึกษาว่าจะดำเนินธุรกิจต่ออย่างไร" ขยายไปสู่ PMO, การออกแบบโมเดลธุรกิจ, การส่งเสริมโครงการ และการสนับสนุนการตัดสินใจ ทุกวันนี้ มีไซต์ที่เราใช้เวลา "สร้างธุรกิจ" มากกว่า "สร้างระบบ" ตอนแรกผมก็สงสัยว่านี่ยังเป็น contract development หรือเปล่า แต่ผมเลิกสนใจเส้นแบ่งพวกนั้นแล้ว
ช่วงนี้ผมได้ยินคำว่า FDE (Forward Deployment Engineer) บ่อยมาก และมันน่าจะเป็นส่วนหนึ่งของแนวโน้มเดียวกัน เข้าไปในไซต์ของลูกค้า คิดปัญหาด้วยกัน และเขียนโค้ดถ้าจำเป็น ไม่ใช่ "นักคิด" และ "นักสร้าง" แต่เป็น "คนที่สร้างไปพร้อมกับคิด" ความเข้าใจผิดที่พบบ่อยที่นี่คือ สาระสำคัญอยู่ที่การอยู่หน้างานหรืออยู่ใกล้ลูกค้าทางกายภาพ ไม่ใช่ มันคือการใกล้ชิดกับการแก้ปัญหา
อย่างไรก็ตาม การเปลี่ยนแปลงนี้เป็นดาบสองคม ผมเพิ่งได้ยินเรื่องนี้จากบริษัทใหญ่แห่งหนึ่ง: เริ่มต้นด้วยกลยุทธ์ทางธุรกิจ จากนั้นเริ่มพัฒนาระบบ ระหว่างทาง การสร้างกลายเป็นเป้าหมายเดียว กลยุทธ์หายไป และระบบที่ไม่ได้ใช้งานจำนวนมหาศาลก็เหลืออยู่ ความจริงนี้มีอยู่ก่อน AI นานแล้ว แต่เมื่อ AI ลดต้นทุนในการสร้าง โศกนาฏกรรมนี้จะเกิดขึ้นได้ง่ายขึ้นและในปริมาณที่มากขึ้น ยิ่งสร้างง่ายเท่าไหร่ น้ำหนักของ "สิ่งที่จะสร้าง" ก็ยิ่งหนักขึ้นเท่านั้น
ดังนั้น สำหรับ contract development ที่ดำดิ่งสู่การแก้ปัญหา AI คือลมส่ง ไม่ใช่ลมปะทะ มันห่างไกลจาก "กำลังจะตาย" มาก อย่างไรก็ตาม ช่วงเวลาที่คุณก้าวออกจากการแก้ปัญหา ลมส่งนั้นจะกลายเป็น "เครื่องผลิตสิ่งไร้ค่าจำนวนมาก"
4. ท้ายที่สุดแล้ว แหล่งที่มาของคุณค่าคือ "คน"
เมื่อมาถึงจุดนี้ ดูเหมือนว่าแหล่งที่มาของคุณค่าสำหรับ contract development, การให้คำปรึกษา และ SaaS นั้นเหมือนกัน ไม่ใช่ตัวซอฟต์แวร์ แต่เป็นคน
งานที่บริษัทไหนๆ ก็แก้ไขได้จะถูกแทนที่ งานที่ AI แก้ไขได้ก็จะถูกแทนที่เช่นกัน แต่ "มันต้องเป็นคนเหล่านี้ที่แก้ไข" ยังคงอยู่ "ฉันอยากทำงานกับคนเหล่านี้" ก็ยังคงอยู่
ดังนั้นเป้าหมายไม่ใช่การส่งมอบผลิตภัณฑ์ แต่เป็นการเป็นพันธมิตรให้ลูกค้าบรรลุคุณค่า ทำให้พวกเขารู้สึกถึงคุณค่าในตัวคน ไม่ใช่ในวัตถุ
ตัวอย่างสำคัญคือการตัดสินใจ AI สามารถสร้างตัวเลือกได้ไม่จำกัดจำนวน แต่คนที่ตัดสินใจคือมนุษย์ และคุณจะเก่งขึ้นในการตัดสินใจก็ต่อเมื่อคุณตัดสินใจ
วิธีฝึกคนก็กำลังเปลี่ยนไปเช่นกัน ในแผนกของผม เรากำลังเปลี่ยนไปสู่ "การคิด + การสร้าง" และแน่นอนว่ามีความท้าทาย แต่นี่ไม่ใช่สิ่งที่เรียนรู้ได้จากการฝึกอบรม มันเติบโตได้เฉพาะในงานเท่านั้น
ผมจะพูดถึงการจ้างงานสั้นๆ เมื่อเร็วๆ นี้ บริษัทหลายแห่งลดการจ้างงานระดับจูเนียร์เนื่องจาก AI ตรรกะคือ "ถ้า AI เขียนโค้ดได้ เราก็ไม่จำเป็นต้องมีจูเนียร์" แต่ผมเชื่อตรงกันข้าม จูเนียร์ที่เกิดมาพร้อม AI เพราะไม่มีกรอบความคิดที่ตายตัว มีศักยภาพที่จะคิดหาวิธีการใช้งานที่เราไม่เคยนึกถึง แม้ว่าในระยะสั้นการจ้างงานอาจถูกจำกัด แต่ถ้าคุณไม่สามารถสร้างสภาพแวดล้อมที่คนเติบโตได้ อุตสาหกรรมนั้นก็จะถดถอยเท่านั้น นั่นไม่ใช่ความผิดของ AI มันเป็นแค่ความล้มเหลวในการปรับตัวต่อการเปลี่ยนแปลงที่ AI นำมา
อาชีพวิศวกรไม่ได้หายไป แต่งานของวิศวกรที่ "แค่สร้าง" กำลังหายไป
การพัฒนาซอฟต์แวร์ทั้งหมดกำลังเข้าใกล้ "คุณค่า"
"Contract development is dead" เป็นความจริง อย่างไรก็ตาม ไม่ใช่ contract development ที่กำลังตาย แต่เป็นการพัฒนาซอฟต์แวร์ที่เป็นแค่ "การสร้าง" กำลังตาย อาชีพวิศวกรไม่ได้หายไป แต่งานของวิศวกรที่ "แค่สร้าง" กำลังหายไป และมันได้เริ่มขึ้นแล้ว Contract development เป็นแค่แนวหน้าเท่านั้น
ถ้าคุณถอยออกมาดูการเปลี่ยนแปลงเหล่านี้ ภาพใหญ่ก็จะปรากฏขึ้น Contract development ที่ดำดิ่งสู่ธุรกิจ บริษัทที่ปรึกษาที่มีทีมพัฒนา SaaS ที่ก้าวเข้าสู่การรับประกันผลงาน FDE ที่เข้าไปในไซต์ลูกค้า ตำแหน่งและรูปแบบทั้งหมดแตกต่างกัน แต่ทิศทางเดียวกัน การพัฒนาซอฟต์แวร์ทั้งหมดกำลังเข้าใกล้ "คุณค่า" ในแบบของมันเอง
ยิ่งไปกว่านั้น นี่ไม่ใช่แนวโน้มใหม่ วิศวกรรู้มานานแล้วว่า "แค่สร้างอย่างเดียวมันไม่พอ" และพยายามเข้าใกล้ลูกค้า ผู้ใช้ และคุณค่ามากขึ้น ตัวอย่างที่ชัดเจนคือ Agile development มันเป็นเวลา 25 ปีแล้วตั้งแต่ Agile ถือกำเนิด อุดมคติของการนำ "การคิด" และ "การสร้าง" ให้ใกล้ชิดกันมากขึ้น กำลังถูกเร่งให้เร็วขึ้นในคราวเดียวโดย AI ในช่วงไม่กี่ปีนี้ นั่นคือสิ่งที่ผมมองเห็น
ดังนั้น เราไม่ควรหมกมุ่นอยู่กับ "รูปแบบ" ของการพัฒนาซอฟต์แวร์อีกต่อไป Contract development หรือบริษัทผลิตภัณฑ์? SIer หรือที่ปรึกษา? แทนที่จะเสียพลังงานไปกับสิ่งนั้น คำถามที่ต้องถามคือ "คุณดำดิ่งสู่คุณค่าได้ลึกแค่ไหน?"
ในวันที่ 7/24 ผมจะมีการสนทนาสดในหัวข้อ "Contract Development is Dead" จนถึงเช้า
ในวันที่ 7/24 ผมจะพูดในงานที่จัดโดย Creationline ในหัวข้อ "อนาคตของ Contract Development ในยุค AI — เหนือกว่า 'Contract Development is Dead'"
https://creationline.connpass.com/event/398146/
วันศุกร์ที่ 24 กรกฎาคม 2026 เวลา 19:00–20:30 น. จัดผ่าน Zoom เข้าฟรี
ผมจะพูดคุยอย่างจริงจังและตรงไปตรงมากับ @samuraiRed และ @sasakendayo ในหัวข้อ "Contract Development is Dead"
เนื่องจากพวกเราสามคนอาจพูดในสิ่งที่พูดไม่ได้ ผมบอกผู้จัดงานในการประชุมเตรียมงานว่า "กรุณาหยุดพวกเราด้วยถ้ามันเลยเถิด" จะต้องมีความรู้สึกที่สัมผัสได้เฉพาะในเวลาจริงแน่นอน
แล้วเราจะคุยเรื่องอะไรกัน?
คำตอบคือ... Tranquilo! อย่าเพิ่งรีบร้อน!
ผมจะรอคุณอยู่นะวันนั้น
บล็อกอยู่ที่นี่:
