Autonomation ในโลกของการพัฒนา Software

ในคลาส LeSS in Action ที่สอนโดย Terry Yin มีเรื่องหนึ่งที่ Terry เล่าให้ฟัง นั่นก็คือ TPS (Toyota Production System) ซึ่งตอนเราได้ยินคำนี้ก็แอบสงสัยนะ ว่าการพัฒนา Software เกี่ยวอะไรกับ Toyota นะ

Terry ก็เล่าประวัติความเป็นมาของบริษัทอย่าง Toyota ซึ่งตั้งแต่แรกเริ่มเดิมทีเลย Toyota เคยทำธุรกิจผลิตเครื่องทอผ้ามาก่อนในนามบริษัท Toyoda Automatic Loom Works, Ltd. ซึ่งในช่วงเวลานั้นเครื่องทอผ้าของ Toyoda ได้รับการยอมรับและใช้งานอย่างแพร่หลายในวงการสิ่งทอ

เครื่องทอผ้าของ Toyoda จาก https://www.allaboutlean.com/toyoda-model-g/

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

ซึ่งจะต่างออกไปจากวิธีการของ Toyoda Automatic Loom Work ที่กระบวนการผลิตผ้าของ Toyoda นี้มีความสามารถในการเพิ่มผลผลิตและลดการเสียหายของผ้า ด้วยเพียงแนวคิดง่าย ๆ ที่คนอื่นคาดไม่ถึง

แนวคิดนี้เรียกว่า JIDOKA

JIDOKA ในภาษาญี่ปุ่นมาจาก 3 คำ คือ

• JI 自 = ด้วยตัวเอง
• DO 動 = เคลื่อนไหว
• KA 化 = ทำให้กลายเป็น

JIDOKA 自動化 แปลตรงตัวว่า การทำให้เคลื่อนไหวได้ด้วยตัวเอง ตรงกับภาษาอังกฤษก็คือ Autonomation

Terry เล่าว่าตอนไปสอนเรื่องนี้ที่ญี่ปุ่นเขาเขียนคำว่า JIDOKA ไปแบบนี้ 自働化 คนญี่ปุ่นต่างหัวเราะเพราะพวกเขาคิดว่า Terry เขียนผิด แต่จริง ๆ แล้ว Terry ตั้งใจที่จะเขียนแบบนี้ โดยเปลี่ยนคันจิ 動 เป็น 働 โดยทั้ง 2 คำนี้อ่านว่า DO เหมือนกัน แต่ให้ความหมายไม่เหมือนกันเพราะ 働 คำที่ 2 นี้จะมีคันจิ 人 (มนุษย์) เพิ่มเข้าไปที่ด้านหน้า ซึ่งจะแปลว่าการทำงาน (ของมนุษย์)

แนวคิด JIDOKA คือการเพิ่มความสามารถในการหยุดกระบวนการผลิตอัตโนมัติได้ทันทีเมื่อพบปัญหาหรือข้อผิดพลาด (และเข้าไปแก้ปัญหาด้วยมนุษย์)

รูปถ่ายจากคลาส LeSS in Action

แนวคิด JIDOKA ในกระบวนการผลิต

• เครื่องจักรหรือระบบจะมีการหยุดอัตโนมัติเมื่อพบปัญหาหรือข้อผิดพลาด
• มีการแจ้งเตือนหรือส่งสัญญาณเตือนเพื่อให้มนุษย์เข้ามาแก้ไข
• สิ่งนี้ส่งเสริมการมีส่วนร่วมของพนักงานในการตรวจสอบและแก้ไขปัญหา

มีแค่นี้เหรอ ทำไมดูง่ายจัง

เรามาดูกันว่าจากแนวคิดง่าย ๆ ด้านบน มีข้อดีอย่างไรบ้าง

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

อ่านมาถึงตรงนี้ เริ่มรู้สึกคุ้นไหมครับ ว่าเราเคยเห็นแนวคิดนี้ตรงจุดไหนของการพัฒนา Software Product ของเราบ้าง

ใช่แล้ว

ภาพ Continuous Integration จาก https://www.devonblog.com/continuous-delivery/continuous-integration-best-practices/

แนวคิดนี้เหมือนกันกับ Continuous Integration (CI) เลย

CI เป็น practice ที่เกิดขึ้นจากความต้องการในการปรับปรุงกระบวนการพัฒนาซอฟต์แวร์ให้มีประสิทธิภาพมากขึ้น โดยการรวมโค้ดจากนักพัฒนาหลาย ๆ คนเข้าด้วยกันอย่างต่อเนื่อง โดยมีการรันทดสอบเพื่อป้องกันข้อผิดพลาดที่อาจเกิดขึ้นจากการรวมโค้ดในภายหลัง และเพื่อให้การทดสอบเป็นไปอย่างสม่ำเสมอ ให้แน่ใจว่าโค้ดใหม่ไม่มีข้อผิดพลาด และป้องกันไม่ให้ข้อผิดพลาดเข้าสู่ server หรือ production

จะเห็นว่ากระบวนการทั้งหมดที่เรากำหนดลงไปใน CI workflow นั้น จะเข้ากับแนวคิดของ JIDOKA เลย หากเจอปัญหา หรือ integration test ไม่ผ่าน กระบวนการ CI จะหยุดการทำงานทันที และส่งสัญญาณเตือนให้กับ Developer รับรู้ ซึ่งอาจจะเป็นในรูปแบบของภาพ workflow สีแดง หรือ เราอาจจะกำหนดให้มีเสียงร้องออกมาด้วยก็ได้ อย่างใน Class LeSS in Action นี้ ถ้าตัว workflow เกิดปัญหาขึ้นจะมีเสียงเพลง Who Let The Dogs Out ดังขึ้นมา 5555

CI workflow ของ GitHub Actions

ซึ่งหลังจากที่ Developer รู้ตัวแล้ว ก็จะรีบเข้าไปแก้ไขโค้ดของตนเองทันที เพื่อให้ CI workflow สามารถทำงานต่อได้

แล้วถ้าถามกลับกันอีกว่า Autonomation (JIDOKA) มันดีกว่า Automation ยังไง คำตอบหลาย ๆ อย่างก็อาจจะอยู่ในข้อดีของ Autonomation (JIDOKA) แล้ว

แต่จะมีอีกอย่างหนึ่งที่ Terry บอกก็คือ ถ้าหากเราต้องใช้ต้นทุน และ เวลานานมาก เช่นสัก 10 ชั่วโมงขึ้นไปในการสร้าง Automation, เราลองคิดดูก่อน ว่ามันจำเป็นจริง ๆ ไหม ถ้าการที่เข้าไปแก้ปัญหาตอนที่ Autonomation (JIDOKA) หยุดทำงาน เราใช้เวลาแก้ไขปัญหา บางทีเราอาจจะใช้เวลาแก้เพียงแค่ 5 นาทีก็ผ่านแล้ว ซึ่งต่อให้เกิดปัญหาเป็น 100 ครั้ง ก็อาจจะยังใช้เวลาไม่ถึง 10 ชั่วโมงเลยด้วยซ้ำ

เราจะเอาเวลาไปเสียทำไมตั้งหลาย 10 ชั่วโมงเพื่อทำ Automation ที่ในท้ายที่สุดก็อาจจะต้องมีมนุษย์เข้าไปตรวจสอบการทำงานในตอนท้ายสุดอยู่ดี ดีไม่ดี เราอาจจะตรวจสอบพลาดแล้วไปเจอปัญหากันอีกทีบน production เลยด้วยซ้ำ