Goodhart’s Law
เมื่อตัววัดกลายเป็นเป้า มันก็เลิกเป็นตัววัดที่ดี
ใจความสำคัญ
หัวข้อที่มีชื่อว่า “ใจความสำคัญ”“เมื่อตัววัด (measure) กลายเป็นเป้าหมาย (target) มันก็เลิกเป็นตัววัดที่ดี”
Goodhart’s Law ตั้งชื่อตาม Charles Goodhart นักเศรษฐศาสตร์ชาวอังกฤษ ผู้เขียนบทความเกี่ยวกับนโยบายการเงินของสหราชอาณาจักรในปี 1975 คำกล่าวดั้งเดิมของเขาซับซ้อนและเป็นวิชาการกว่านี้มาก คือ “Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes” (ความสม่ำเสมอทางสถิติใด ๆ ที่สังเกตได้ มักจะพังทลายลงทันทีที่มันถูกใช้เป็นเครื่องมือควบคุม) บริบทตอนนั้นคือรัฐบาลอังกฤษยุค Margaret Thatcher พยายามคุมเงินเฟ้อด้วยการตั้งเป้าปริมาณเงินในระบบ (money supply) แต่ทันทีที่ตัวเลขนั้นกลายเป็นเป้าหมายที่ธนาคารและนักลงทุนรู้ว่าถูกจับตา พฤติกรรมของตลาดก็เปลี่ยนไปจนความสัมพันธ์ทางสถิติเดิมใช้ไม่ได้อีกต่อไป
ถ้อยคำที่คนจำกันติดปากทุกวันนี้ — “เมื่อตัววัดกลายเป็นเป้าหมาย มันก็เลิกเป็นตัววัดที่ดี” — จริง ๆ แล้วเป็นการเรียบเรียงใหม่โดยนักมานุษยวิทยา Marilyn Strathern ในบทความปี 1997 ของเธอ ซึ่งเชื่อมโยงข้อสังเกตของ Goodhart เข้ากับประวัติศาสตร์การตรวจสอบ (accountability) ในสถาบันของอังกฤษ
น่าสังเกตว่ามีแนวคิดใกล้เคียงกันที่เกิดก่อนหน้านั้นด้วยซ้ำ คือ Campbell’s Law (ราวปี 1969) ของนักสังคมศาสตร์ Donald T. Campbell ที่ระบุว่า “ยิ่งตัวชี้วัดเชิงปริมาณใดถูกใช้ในการตัดสินใจทางสังคมมากเท่าไร มันก็ยิ่งถูกบิดเบือนได้ง่ายขึ้นเท่านั้น” ทั้งสองกฎพูดถึงปรากฏการณ์เดียวกันจากคนละมุม และมักถูกอ้างอิงคู่กัน
ความหมายและนัยยะ
หัวข้อที่มีชื่อว่า “ความหมายและนัยยะ”หัวใจของกฎนี้คือความแตกต่างระหว่าง ตัววัด (measure) กับ สิ่งที่เราต้องการวัดจริง ๆ (the thing we actually care about) metric แทบทุกตัวเป็นเพียง proxy หรือตัวแทนโดยประมาณของคุณค่าที่วัดตรง ๆ ไม่ได้ ตราบใดที่ metric ยังเป็นเพียงข้อมูลประกอบเฉย ๆ ไม่มีใครแคร์มันเป็นพิเศษ ความสัมพันธ์ระหว่าง metric กับคุณค่าจริงจึงยังคงซื่อสัตย์ แต่ทันทีที่มันถูกยกระดับเป็นเป้าหมาย เป็นตัวเลข KPI ที่ผูกกับโบนัส การประเมินผล หรือ “ต้องทำให้ถึง” คนก็จะหาทางที่สั้นที่สุดไปสู่ตัวเลขนั้น ไม่ใช่ทางที่นำไปสู่คุณค่าที่แท้จริง
ในวงการวิศวกรรมซอฟต์แวร์มักแยกกฎนี้เป็นสองระดับที่ต่างกัน:
- Weak Goodhart — คนจงใจ “เล่นกับตัวเลข” (gaming the metric) เช่น แบ่ง bug หนึ่งใบเป็นหลายใบเพื่อให้ยอด ticket ที่ปิดได้ดูสูงขึ้น ทั้งที่รู้ตัวว่ากำลังหลอกระบบวัดผล
- Strong Goodhart — แม้แต่คนที่ไล่ตามตัวเลขอย่างสุจริตใจ ไม่ได้ตั้งใจโกงเลย ก็ยังทำร้ายเป้าหมายที่แท้จริงได้ เพราะ proxy กับเป้าหมายจริงไม่เคยเหมือนกันเป๊ะ การเพิ่ม metric ให้สูงสุดจึงมักดันคุณค่าจริงให้ต่ำลงเมื่อเลยจุดหนึ่งไป
นัยยะสำคัญคือ Goodhart’s Law ไม่ใช่ข้อบกพร่องที่แก้ไขได้ด้วย metric ที่ “ฉลาดกว่า” เพราะไม่ว่าจะออกแบบตัวชี้วัดดีแค่ไหน มันก็ยังเป็นเพียงตัวแทนที่ไม่สมบูรณ์ของสิ่งที่วัดยากอย่างคุณภาพซอฟต์แวร์ ความพึงพอใจของผู้ใช้ หรือทักษะของทีม สิ่งที่ทำได้คือบริหารความเสี่ยงนี้ ไม่ใช่กำจัดมัน
ในบริบท Agile กฎนี้ปรากฏให้เห็นบ่อยที่สุดผ่าน velocity และ story point เดิมที story point ถูกออกแบบมาเพื่อช่วยทีมวางแผนภายในทีมเอง เป็นเครื่องมือสื่อสารความไม่แน่นอนของงาน แต่ทันทีที่ผู้บริหารเริ่มเปรียบเทียบ velocity ระหว่างทีม หรือตั้งเป้าว่า “ทีมต้องทำได้ N point ต่อ sprint” ทีมก็จะปรับตัวเลข point ให้สูงขึ้นเรื่อย ๆ โดยไม่ได้ส่งมอบคุณค่าเพิ่มขึ้นจริง (point inflation) นี่คือตัวอย่างคลาสสิกของ Strong Goodhart ที่แม้ทีมจะประมาณงานอย่างสุจริตใจ แต่แรงกดดันจากการถูกวัดเทียบกันก็ยังบิดเบือนตัวเลขได้อยู่ดี
flowchart LR
Goal[เป้าหมายที่แท้จริง] -->|ประมาณด้วย| Metric[ตัววัด metric]
Metric -->|ถูกยกเป็น| Target[เป้าหมายที่ต้องทำให้ถึง]
Target -->|คนปรับพฤติกรรม| Gaming[เล่นกับตัวเลข หรือ over-optimize]
Gaming -->|เบี่ยงเบนจาก| Goal
ตัวอย่างในโลกจริง
หัวข้อที่มีชื่อว่า “ตัวอย่างในโลกจริง”- นโยบายการเงินอังกฤษ (ต้นกำเนิด) — เมื่อรัฐบาลกำหนดเป้าปริมาณเงินในระบบเพื่อคุมเงินเฟ้อ ความสัมพันธ์ทางสถิติระหว่างปริมาณเงินกับเงินเฟ้อที่เคยแม่นยำก็พังทลาย เพราะธนาคารและตลาดปรับตัวรอบเป้าหมายนั้นโดยตรง
- การศึกษา — กฎหมาย No Child Left Behind ของสหรัฐฯ ผูกงบประมาณโรงเรียนกับคะแนนสอบมาตรฐาน ผลคือมีรายงานว่าโรงเรียนบางแห่งเลื่อนชั้นนักเรียนที่ยังไม่พร้อม หรือ “สอนเพื่อสอบ” (teaching to the test) แทนที่จะสอนเพื่อความเข้าใจจริง
- สาธารณสุข — โรงพยาบาลที่ถูกวัดผลด้วย “ระยะเวลาพักรักษาตัวเฉลี่ย” (length of stay) บางแห่งลดตัวเลขนี้ด้วยการให้ผู้ป่วยออกจากโรงพยาบาลเร็วเกินไป จนอัตราการกลับมารักษาซ้ำ (readmission) สูงขึ้น
- การนับตรวจ COVID-19 — เป้าหมาย “100,000 การตรวจต่อวัน” ของรัฐบาลอังกฤษถูกวิจารณ์ว่านับรวม “ความสามารถสูงสุดในการตรวจ” ไม่ใช่จำนวนการตรวจจริงที่เกิดขึ้น ทำให้ตัวเลขดูดีกว่าความเป็นจริง
- Lines of code และจำนวน commit — เมื่อองค์กรวัดผลงานด้วยจำนวนบรรทัด code หรือจำนวน commit นักพัฒนาบางคนเขียน code ยืดยาวเกินจำเป็นหรือแตก commit ให้ถี่ขึ้นโดยไม่ได้เพิ่มคุณค่าจริง
- Code coverage และจำนวน bug ticket ที่ปิด — การตั้งเป้า coverage percentage ทำให้บางทีมเขียน unit test ที่ไม่ assert อะไรมีความหมายเลยเพียงเพื่อให้ตัวเลขขึ้น ขณะที่ integration test ที่จำเป็นจริงกลับถูกข้าม เช่นเดียวกับการตั้งเป้า “ต้องปิด 100 ticket ต่อเดือน” ที่ดันให้ทีมปิด bug แบบผิวเผินหรือแตก bug หนึ่งใบเป็นหลายใบเพื่อดันยอด
// ตัวอย่างสัญญาณเตือน Goodhart's Law ใน code: การไล่ตาม code coverage เป็นเป้าหมาย[Fact]public void CalculateDiscount_ShouldNotThrow(){ // test นี้เพิ่ม coverage percentage แต่ไม่ assert พฤติกรรมที่แท้จริงเลย var result = OrderService.CalculateDiscount(100m, "VIP"); Assert.NotNull(result); // ผ่านเสมอ ไม่ว่าผลลัพธ์จะถูกหรือผิด}
// สิ่งที่ควรทำแทน: assert คุณค่าทางธุรกิจจริง แม้ coverage number จะไม่เปลี่ยนมาก[Fact]public void CalculateDiscount_VipCustomer_Gets10PercentOff(){ var result = OrderService.CalculateDiscount(100m, "VIP"); Assert.Equal(90m, result);}บทเรียนที่นำไปใช้
หัวข้อที่มีชื่อว่า “บทเรียนที่นำไปใช้”- ใช้ metric เป็นสัญญาณ ไม่ใช่เป้าหมายสูงสุด — ตัวเลขควรช่วยให้ทีมตั้งคำถาม ไม่ใช่เป็นสิ่งที่ต้องยัดให้ถึงไม่ว่าจะด้วยวิธีใด เมื่อใดก็ตามที่ metric ผูกกับโบนัสหรือการประเมินผลโดยตรงและเข้มงวด ให้ระวังว่ากำลังเปิดช่องให้ Goodhart’s Law ทำงาน
- ใช้หลายตัววัดประกอบกัน (portfolio of metrics) — metric เดี่ยว ๆ ถูกเล่นได้ง่ายกว่าชุด metric ที่ถ่วงดุลกัน เช่น วัด velocity คู่กับ defect rate และ customer satisfaction ไปพร้อมกัน แม้วิธีนี้จะไม่ใช่ทางแก้ที่สมบูรณ์แบบ เพราะชุด metric เองก็อาจถูก game ได้เช่นกันหากซับซ้อนพอ
- ระวังทั้ง weak และ strong Goodhart — อย่าคิดว่าปัญหาคือ “คนโกงตัวเลข” เพียงอย่างเดียว แม้ทีมที่สุจริตที่สุดก็ยังทำร้ายเป้าหมายจริงได้จากการไล่ตาม proxy อย่างเข้มข้นเกินไป
- DORA metrics และ metric สมัยใหม่ก็ไม่รอด — แม้แต่ชุดตัวชี้วัด DevOps ยอดนิยมอย่าง deployment frequency หรือ lead time for changes ก็เป็นเพียง “proxy ของ proxy ของเป้าหมาย” เท่านั้น การไล่ deploy ให้ถี่ขึ้นโดยไม่สนใจคุณภาพ ก็ทำให้ตัวเลขดีขึ้นได้โดยที่ธุรกิจไม่ได้ประโยชน์จริง
- ใช้วิจารณญาณทางวิศวกรรมเป็นหลัก — ไม่มีสูตรสำเร็จที่ขจัด Goodhart’s Law ได้ทั้งหมด สิ่งที่ทำได้ดีที่สุดคือให้คนที่มีบริบทและวิจารณญาณตัดสินใจประกอบกับตัวเลข ไม่ใช่ปล่อยให้ตัวเลขตัดสินใจแทน
- ตั้งเป้าหมายที่ระดับผลลัพธ์ (outcome) ไม่ใช่ระดับผลผลิต (output) — เช่น วัด “ปัญหาของผู้ใช้ถูกแก้จริงหรือไม่” แทน “จำนวน ticket ที่ปิด” จะลดช่องว่างระหว่าง metric กับคุณค่าที่แท้จริงลงได้บ้าง