Conway’s Law คืออะไร? โครงสร้างองค์กรกำหนดหน้าตาระบบ

Conway’s Law คืออะไร? โครงสร้างองค์กรกำหนดหน้าตาระบบ

ทำไมบริษัทที่มีแผนกขนส่ง แผนกคลังสินค้า และแผนกขายแยกกัน จึงมักมีระบบ TMS, WMS และ CRM ที่คุยกันไม่รู้เรื่อง ทั้งที่ลงทุนซื้อซอฟต์แวร์ชั้นนำมาทั้งหมด? คำตอบอาจไม่ได้อยู่ที่เทคโนโลยี แต่อยู่ที่ผังองค์กรของบริษัทเอง

แนวคิดนี้เรียกว่า Conway’s Law ซึ่งเป็นหนึ่งในหลักการที่ถูกอ้างถึงบ่อยที่สุดในวงการวิศวกรรมซอฟต์แวร์ และกำลังกลับมามีความสำคัญอีกครั้งในยุคที่องค์กรพยายามนำ AI และ AI Agent เข้ามาเชื่อมงานข้ามแผนก บทความนี้อธิบายที่มา ความหมาย ตัวอย่างในธุรกิจจริง และวิธีนำไปใช้ออกแบบองค์กรอย่างเป็นระบบ

Conway’s Law คืออะไร

Conway’s Law มาจากข้อสังเกตของ Melvin Conway นักวิทยาการคอมพิวเตอร์ชาวอเมริกัน ในบทความเรื่อง How Do Committees Invent? ซึ่งเขาเขียนในช่วงปี 1967 และตีพิมพ์ในปี 1968 ใจความสำคัญคือองค์กรที่ออกแบบระบบใดๆ ก็ตามจะได้ผลงานที่เป็นสำเนาของโครงสร้างการสื่อสารภายในองค์กรนั้น

ชื่อ Conway’s Law ถูกตั้งขึ้นภายหลังโดย Fred Brooks ผู้เขียนหนังสือ The Mythical Man-Month ที่นำแนวคิดนี้ไปเผยแพร่จนเป็นที่รู้จักในวงกว้าง

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

ที่สำคัญคือ Conway’s Law ไม่ใช่กฎธรรมชาติที่พิสูจน์ได้แน่นอนทุกกรณี แต่เป็นแนวโน้มที่มีงานวิจัยสนับสนุนจำนวนมาก เช่น งานของนักวิจัยจาก Harvard Business School และ MIT ที่เรียกสมมติฐานนี้ว่า Mirroring Hypothesis และงานวิจัยของ Microsoft ที่พบว่าตัวชี้วัดด้านโครงสร้างองค์กรทำนายจำนวนข้อบกพร่องของซอฟต์แวร์ได้ดีกว่าตัวชี้วัดด้านโค้ดบางประเภท

ทำไมโครงสร้างองค์กรจึงกำหนดระบบ

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

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

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

ตัวอย่าง Conway’s Law ในธุรกิจและโลจิสติกส์

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

แอปติดตามพัสดุที่ลูกค้าใช้ยาก:
เมื่อบริษัทขนส่งแบ่งทีมตามประเภทบริการ เช่น ทีมขนส่งทางบก ทีมขนส่งทางอากาศ และทีมขนส่งข้ามพรมแดน ลูกค้ามักต้องใช้หลายแอปหรือหลายหน้าจอเพื่อติดตามสินค้าเดียวกัน ประสบการณ์ที่กระจัดกระจายนี้สะท้อนโครงสร้างภายในที่กระจัดกระจายนั่นเอง

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

Conway’s Law กับการนำ AI Agent มาใช้

ประเด็นที่น่าสนใจที่สุดในปัจจุบันคือ AI Agent ไม่ได้ทำให้ Conway’s Law หายไป แต่อาจทำให้ปรากฏชัดขึ้น เพราะ Agent ต้องเข้าถึงข้อมูล เครื่องมือ และสิทธิ์การตัดสินใจข้ามหลายระบบจึงจะทำงานแทนคนได้จริง

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

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

Inverse Conway Maneuver: ออกแบบทีมให้ได้ระบบที่ต้องการ

ถ้าโครงสร้างองค์กรกำหนดโครงสร้างระบบ ก็ย่อมกลับทิศได้เช่นกัน คือเริ่มจากสถาปัตยกรรมเป้าหมายที่ต้องการ แล้วปรับโครงสร้างทีมให้สอดคล้อง แนวทางนี้เรียกว่า Inverse Conway Maneuver หรือ Reverse Conway Maneuver ซึ่งถูกเผยแพร่ในวงการวิศวกรรมซอฟต์แวร์โดยชุมชนอย่าง ThoughtWorks

ขั้นตอนพื้นฐานมีดังนี้

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

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

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

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

Team Topologies: กรอบปฏิบัติที่นิยมใช้

หนังสือ Team Topologies ของ Matthew Skelton และ Manuel Pais (2019) นำ Conway’s Law มาแปลงเป็นกรอบการออกแบบทีมที่นำไปใช้ได้จริง โดยเสนอทีมสี่ประเภท

Stream-aligned team:
ทีมที่รับผิดชอบกระแสงานหนึ่งของธุรกิจโดยตรง เช่น การสั่งซื้อของลูกค้ากลุ่มหนึ่ง และเป็นทีมประเภทหลักที่ควรมีมากที่สุด

Platform team:
ทีมที่สร้างแพลตฟอร์มภายใน เช่น ชั้นข้อมูลกลางหรือโครงสร้างพื้นฐาน AI เพื่อลดภาระของทีมอื่น

Enabling team:
ทีมผู้เชี่ยวชาญที่ช่วยสอนและยกระดับทักษะของทีมอื่นชั่วคราว เช่น ผู้เชี่ยวชาญด้าน AI ที่ลงไปทำงานร่วมกับทีมคลังสินค้า

Complicated-subsystem team:
ทีมที่ดูแลส่วนที่ซับซ้อนและต้องการความเชี่ยวชาญเฉพาะสูง เช่น โมเดลปรับเส้นทางขั้นสูง

กรอบนี้ยังกำหนดรูปแบบการทำงานร่วมกันของทีมไว้สามแบบ คือ Collaboration, X-as-a-Service และ Facilitating เพื่อให้รู้ชัดว่าทีมใดควรคุยกันใกล้ชิด และทีมใดควรสื่อสารผ่านบริการที่กำหนดสัญญาไว้ชัดเจน นอกจากนี้ยังให้ความสำคัญกับภาระทางปัญญาของทีม เพื่อไม่ให้ทีมรับผิดชอบมากเกินกว่าที่จะเข้าใจได้ทั้งหมด

ข้อควรระวังในการนำไปใช้

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

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

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

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

แนวทางเริ่มต้นสำหรับผู้บริหาร

ผู้บริหารที่ต้องการนำ Conway’s Law ไปใช้สามารถเริ่มจากคำถามง่ายๆ สามข้อ

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

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

สรุป

Conway’s Law เตือนเราว่าระบบที่องค์กรสร้างขึ้นเป็นภาพสะท้อนของวิธีที่คนในองค์กรสื่อสารกัน ไม่ว่าจะเป็นระบบข้อมูลโลจิสติกส์ ประสบการณ์ลูกค้า หรือโครงการ AI ก็ตาม หากโครงสร้างองค์กรแยกส่วน ระบบก็จะแยกส่วนตามไปด้วย

ข่าวดีคือหลักการนี้ใช้ได้สองทาง ด้วย Inverse Conway Maneuver และกรอบอย่าง Team Topologies องค์กรสามารถออกแบบทีมให้สอดคล้องกับระบบและกระบวนการที่ต้องการได้อย่างตั้งใจ ในยุคที่ AI Agent ต้องทำงานข้ามหน้าที่มากขึ้น การออกแบบโครงสร้างองค์กรให้เอื้อต่อการไหลของข้อมูลและความรับผิดชอบแบบครบวงจร จึงเป็นรากฐานที่ควรวางก่อนการลงทุนในเทคโนโลยีชิ้นถัดไป