เมื่อคนกลายเป็นอะไหล่
บทสะท้อนวงการ Software Development ในฐานะ “เครื่องจักรผลิตของ”
ในโรงงานอุตสาหกรรม เครื่องจักรถูกออกแบบมาเพื่อ “ผลิต”
มันมีสายพาน มีฟันเฟือง มีชิ้นส่วน มีเซ็นเซอร์
ทุกอย่างมีหน้าที่ชัดเจน
ถ้าชิ้นส่วนตัวหนึ่งพัง — ก็แค่ถอดออก แล้วใส่อะไหล่ใหม่เข้าไป
เครื่องจักรเดินต่อ
ผลผลิตต้องไม่หยุด
คำถามคือ
วงการ Software Development ทุกวันนี้ กำลังทำงานแบบเดียวกันอยู่หรือเปล่า?
เครื่องจักรที่ชื่อว่า “องค์กร”
ในหลายองค์กร ซอฟต์แวร์ไม่ได้ถูกมองว่าเป็น “งานฝีมือ”
แต่มันคือ “ผลผลิต”
- ต้องออก feature ให้เร็ว
- ต้อง deploy ให้ถี่
- ต้อง scale ให้ทัน
- ต้อง optimize cost
กระบวนการจึงถูกทำให้เป็นระบบ
มี sprint
มี KPI
มี velocity
มี performance review
มันดู professional
มันดูมีประสิทธิภาพ
แต่มันก็ค่อย ๆ เปลี่ยน “คน” ให้กลายเป็น “ชิ้นส่วน”
เมื่อ Developer กลายเป็นอะไหล่
ในเครื่องจักร ไม่มีคำว่า passion
ไม่มีคำว่า meaning
มีแต่คำว่า replaceable
ถ้า developer คนหนึ่งลาออก
ก็รับคนใหม่
ถ้า performance ไม่ถึง
ก็ปรับออก
Skill ถูกลดทอนเหลือเพียง checklist
- Rust ได้ไหม
- React ได้ไหม
- Kubernetes ได้ไหม
จากคนที่เคยเป็น “นักแก้ปัญหา”
กลายเป็น “resource”
จากคนที่เคยตั้งคำถามว่า
เรากำลังแก้ปัญหาอะไร?
กลายเป็น
ticket นี้ estimate กี่ point?
ปัญหาไม่ได้อยู่ที่ระบบ แต่คือวิธีมองมนุษย์
เครื่องจักรไม่ผิด
Agile ไม่ผิด
KPI ไม่ผิด
ปัญหาคือ เมื่อองค์กรเริ่มเชื่อว่า
มนุษย์คือ component
และ component ต้อง optimize
การ optimize เครื่องจักรคือเรื่องดี
แต่การ optimize คน จนลืมว่าเขามีความคิด มีความฝัน มีจังหวะชีวิต
มันทำให้ระบบเริ่มเย็นชา
Software คืองานฝีมือ ไม่ใช่สายพาน
ซอฟต์แวร์ที่ดี
ไม่ได้เกิดจากการเร่งสายพาน
แต่มันเกิดจาก
- การเข้าใจปัญหาลึก ๆ
- การออกแบบอย่างมีความรับผิดชอบ
- การทบทวนความคิด
- การโต้แย้งอย่างสร้างสรรค์
- การทดลอง
- และบางครั้ง… การล้มเหลว
สิ่งเหล่านี้วัดด้วย KPI ยาก
แต่มันวัดด้วย “คุณภาพของความคิด”
ทางเลือก: จะเป็นอะไหล่ หรือจะเป็นวิศวกร
เราอาจอยู่ในระบบที่เป็นเครื่องจักร
แต่นั่นไม่ได้หมายความว่าเราต้องคิดแบบเครื่องจักร
คำถามสำคัญไม่ใช่
องค์กรปฏิบัติกับเราอย่างไร
แต่คือ
เราปฏิบัติกับตัวเองอย่างไร
ถ้าเรามองตัวเองเป็นแค่แรงงานผลิต feature
เราก็จะกลายเป็นอะไหล่จริง ๆ
แต่ถ้าเรามองตัวเองเป็น
- นักออกแบบระบบ
- ผู้ตั้งคำถาม
- ผู้รับผิดชอบผลกระทบระยะยาว
เราจะเริ่มขยับจาก “ชิ้นส่วน”
ไปเป็น “สถาปนิกของเครื่องจักร”
บทสรุป: บางที ซอฟต์แวร์อาจไม่ควรถูกสร้างเหมือนโรงงาน
โรงงานถูกออกแบบมาเพื่อ
ความสม่ำเสมอ
ความเร็ว
และการแทนที่ได้ง่าย
แต่งานซอฟต์แวร์ที่ดีมักไม่ได้เกิดจากสิ่งเหล่านี้เพียงอย่างเดียว
มันเกิดจาก
- ความเข้าใจปัญหาอย่างลึกซึ้ง
- การออกแบบที่มีความรับผิดชอบ
- การถกเถียงกันอย่างจริงจัง
- และบางครั้ง… การใช้เวลาคิดนานกว่าที่ roadmap ต้องการ
เพราะซอฟต์แวร์ที่เราสร้าง
ไม่ได้หายไปหลังจาก deploy
มันอยู่กับผู้ใช้ไปอีกหลายปี
คำถามสุดท้าย
ผมไม่ได้คิดว่าองค์กรจะหยุดทำงานเหมือนเครื่องจักร
เพราะในโลกธุรกิจ
เครื่องจักรมีประสิทธิภาพ
และประสิทธิภาพคือสิ่งที่องค์กรต้องการ
แต่คำถามที่สำคัญกว่านั้นคือ
เราจะยอมเป็นอะไหล่ของมันหรือไม่
Developer ทุกคนต้องตอบคำถามนี้ด้วยตัวเอง
บางคนอาจเลือกเป็นเฟืองในระบบ
และนั่นก็ไม่ใช่เรื่องผิดอะไร
แต่บางคนอาจเลือกเป็นคนที่
- ตั้งคำถามกับระบบ
- เข้าใจปัญหาให้ลึกกว่า ticket
- และรับผิดชอบต่อสิ่งที่ตัวเองสร้าง
เพราะในท้ายที่สุดแล้ว
ความแตกต่างระหว่าง
“คนที่เขียนโค้ด”
กับ
“วิศวกรซอฟต์แวร์”
อาจไม่ใช่เรื่องของภาษาโปรแกรม
หรือ framework
แต่มันคือคำถามง่าย ๆ ข้อเดียว
เรากำลังสร้าง “ของ”
หรือเรากำลังสร้าง “ระบบที่มีความหมาย”
และบางที…
วันหนึ่งเมื่อเรามองย้อนกลับไปที่งานที่เราทำ
สิ่งที่เราภูมิใจที่สุด
อาจไม่ใช่จำนวน feature ที่เรา deploy
แต่อาจเป็นช่วงเวลาที่เราเลือกหยุดสายพานของเครื่องจักรไว้สักครู่
เพื่อถามว่า
“สิ่งที่เรากำลังสร้าง มันควรถูกสร้างแบบนี้จริง ๆ หรือเปล่า”
ถ้าบทความนี้ทำให้คุณหยุดคิดได้สักนิด
ก่อนจะหยิบ ticket ถัดไปขึ้นมา
บางทีคุณอาจไม่ได้เป็นแค่อะไหล่ของเครื่องจักรอีกต่อไปแล้ว
บทความคือการคิดเงียบ ๆ คนเดียว
แต่ Podcast คือการคิดดัง ๆ
ถ้าคุณอยากฟังเวอร์ชันที่ผมคิดออกเสียง
ไปเจอกันใน Late Night with UncleQuin
🎧 Spotify
▶️ YouTube
🍎 Apple Podcasts
