Monozukuri & Kaizen trong kỷ nguyên số - Phần 1: Chiếc bóng của Monozukuri & Bài toán Entropy

Màn hình máy chiếu hiển thị slide PowerPoint thứ 14 của buổi họp. Trong phòng họp trực tuyến, 8 người im lặng lắng nghe đại diện đội kỹ thuật giải trình về "Báo cáo Đánh giá Rủi ro" (Risk Assessment Report) dài 15 trang.

Nội dung của cuộc thảo luận kéo dài suốt 3 tuần qua: Nên đổi màu nút "Đăng ký" từ màu Xanh lá cây sang màu Xanh dương hay không?

Quản lý dự án lo ngại: "Màu xanh dương có thể kích thích tâm lý không ổn định của người dùng, dẫn đến tỷ lệ hủy đơn tăng lên 0.05%."
Trưởng nhóm QA yêu cầu: "Cần chạy thử nghiệm nội bộ 2 tuần trên 3 môi trường staging khác nhau và thu thập chữ ký phê duyệt (Hanko) của 4 bộ phận trước khi đưa ra quyết định cuối cùng."
Chàng kỹ sư ngồi ở góc màn hình tắt camera, thở dài. Anh nhẩm tính trong đầu: Việc đổi màu này chỉ mất đúng 1 dòng CSS, 10 giây sửa code và 1 phút để deploy lên production. Nhưng ở đây, nó cần 3 tuần họp hành, 15 trang tài liệu giải trình và hàng chục giờ làm việc của những nhân sự lương cao.

Chào mừng bạn đến với bộ phim "sitcom công sở" diễn ra mỗi ngày tại các dự án phần mềm của doanh nghiệp Nhật Bản.

Bạn đã gặp trường hợp này chưa? Có thấy quen thuộc không?

Trong quá trình làm việc và quan sát cách các doanh nghiệp Nhật Bản phát triển phần mềm, tôi dần nhận ra một nghịch lý: Lý do khiến các dự án của họ chậm chạp và cồng kềnh thường không nằm ở năng lực kỹ sư hay sự thiếu hụt công nghệ. Nó đến từ một nơi sâu xa hơn — cách công ty được tổ chức và vận hành.

Tôi luôn có cảm giác rằng những công ty này đang quản lý dự án phần mềm y hệt cách họ điều hành một dây chuyền lắp ráp ô tô hay một nhà máy thép.

Và tôi tin rằng đó chính là gốc rễ của vấn đề.

Ở một công ty công nghệ hiện đại, thay đổi này sẽ được xử lý bằng một A/B test — deploy cả hai phiên bản màu cùng lúc, để chính người dùng thực tế quyết định bằng dữ liệu hành vi sau 48 giờ. Không cần họp. Không cần Hanko. Không cần 15 trang báo cáo rủi ro. Chỉ cần dữ liệu.

Đây chính là khoảng cách giữa tư duy "Hoàn hảo tại T₀" và tư duy "Phân phối giá trị liên tục" (Continuous Value Delivery).

Khi tư duy sản xuất gặp phần mềm

Nhật Bản từng khiến cả thế giới kinh ngạc với sự thần kỳ của nền công nghiệp sản xuất. Triết lý Monozukuri (ものづくり — sự tận tâm, tỉ mỉ trong việc tạo ra sản phẩm), hệ thống sản xuất Toyota (Toyota Production System), và tiêu chuẩn Zero-defects đã tạo ra những chiếc xe hơi bền bỉ nhất, những thiết bị điện tử đáng tin cậy nhất trên thế giới.

Trong lĩnh vực phần cứng và sản xuất vật lý, tư duy này hoàn toàn chính xác:

Một lỗi nhỏ trên hệ thống phanh có thể dẫn đến tai nạn chết người và chiến dịch thu hồi (recall) trị giá hàng triệu đô.
Việc sản xuất hàng loạt đòi hỏi thiết kế phải cực kỳ hoàn hảo trước khi đúc khuôn, bởi chi phí thay đổi sau khi khuôn đã đổ là cực lớn.
Quy trình Waterfall — lập kế hoạch chi tiết, tài liệu dày cộp, kiểm thử khắt khe — không chỉ hợp lý mà còn là yêu cầu bắt buộc.

Vấn đề nảy sinh khi chính tư duy đó được áp dụng nguyên vẹn sang một lĩnh vực vận hành theo quy luật vật lý hoàn toàn khác: phần mềm.

Tại sao phần mềm không phải là chiếc xe hơi

Nếu nhìn phần mềm dưới lăng kính vật lý, nó tuân theo Entropy — định luật thứ hai của nhiệt động lực học, nói rằng mọi hệ thống đều có xu hướng tự nhiên đi về phía hỗn loạn.

Một chiếc xe Toyota Camry xuất xưởng năm 2024, nếu được bảo dưỡng đúng cách, vẫn là một chiếc Camry 2024 sau 10 năm. Nó không tự biến đổi. Đặc tả kỹ thuật (spec) của nó tại thời điểm sản xuất chính là sản phẩm cuối cùng.

Nhưng phần mềm thì ngược lại. Một hệ thống backend được thiết kế "hoàn hảo" ngày hôm nay sẽ bắt đầu lỗi thời ngay ngày mai — không phải vì code chạy sai, mà vì thế giới xung quanh nó thay đổi: nhu cầu người dùng dịch chuyển, đối thủ tung ra tính năng mới, quy định pháp lý được cập nhật, lượng traffic tăng gấp 10 lần. Code không hỏng theo nghĩa vật lý, nhưng nó "hỏng" theo nghĩa giá trị — khi nó không còn phục vụ được nhu cầu thị trường hiện tại.

Đây là sự khác biệt cốt lõi mà nhiều doanh nghiệp Nhật Bản chưa nhận ra:

Trong sản xuất, chất lượng = hoàn hảo tại thời điểm xuất xưởng (T₀). Trong phần mềm, chất lượng = khả năng thích ứng liên tục từ T₀ đến T₁, T₂, T₃...

Sự hoàn hảo tại T₀ không chỉ vô nghĩa — nó trở thành lực cản nếu kiến trúc hệ thống không được thiết kế để đón nhận sự thay đổi. Một hệ thống "hoàn hảo" nhưng cứng nhắc sẽ tốn gấp 3-4 lần công sức để sửa đổi so với một hệ thống được xây dựng với tư duy linh hoạt ngay từ đầu.

Nghịch lý của sự bền bỉ "lỗi thời"

Để hiểu tại sao tư duy "nồi đồng cối đá" lại bám rễ sâu như vậy trong tiềm thức của nhiều thế hệ, chúng ta cần nhìn về bối cảnh lịch sử.

Tư duy này từng gặt hái thành công rực rỡ và hoàn toàn hợp lý trong thời kỳ khan hiếm hậu chiến, khi thu nhập của người tiêu dùng còn hạn hẹp và chu kỳ thay đổi công nghệ còn chậm chạp (thường tính bằng hàng thập kỷ). Một chiếc tủ lạnh hay chiếc tivi chạy tốt suốt 20 năm không chỉ là niềm tự hào của Monozukuri mà còn giải quyết trực tiếp bài toán kinh tế của cả xã hội thời bấy giờ.

Tuy nhiên, trong thế giới công nghệ hiện đại, tư duy đó đang tạo ra một phản hiệu quả sâu sắc:

Sự lỗi thời trước khi hỏng vật lý: Một sản phẩm được kỳ vọng sử dụng 10 năm sẽ bị lỗi thời về cả công nghệ, tính năng lẫn thẩm mỹ và tâm lý tiêu dùng của người dùng rất lâu trước khi nó kịp hỏng hóc về mặt vật lý.
Vai trò của chủ nghĩa tiêu thụ (consumerism): Dù có những mặt trái không thể bàn cãi về lãng phí tài nguyên, nhưng ở góc độ phát triển kinh tế và công nghệ, chủ nghĩa tiêu thụ chính là động cơ thúc đẩy sự đổi mới liên tục, nâng cao trải nghiệm khách hàng và duy trì sức cạnh tranh sống còn.

Việc giữ khư khư tư duy "đồ bền" trong thời đại ngày nay vô tình kìm hãm sự đổi mới này. Và khi áp dụng nó vào phần mềm — nơi chu kỳ thay đổi được tính bằng tuần, bằng ngày — sự bền vững tĩnh lặng đó sẽ ngay lập tức biến thành sự lỗi thời của cả hệ thống.

Time-to-market: Vũ khí thực sự của kỷ nguyên số

Trong thế giới phần mềm, tốc độ đưa sản phẩm ra thị trường (Time-to-market) không chỉ là một chỉ số hiệu suất — nó là yếu tố sống còn.

Khi doanh nghiệp Nhật Bản dành 6 tháng để phê duyệt kế hoạch cho một tính năng "hoàn hảo không lỗi", đối thủ cạnh tranh toàn cầu của họ đã thử nghiệm, thất bại, rút ra bài học và cải tiến tính năng đó tới 10 lần trên thị trường thực tế.

Thế giới công nghệ hiện đại vận hành dựa trên nguyên tắc Thử & Sai (Trial and Error): tung ra sản phẩm khả thi tối thiểu (MVP), thu thập phản hồi từ người dùng thực, chấp nhận thất bại nhanh (fail-fast) và sửa sai ngay lập tức. Đây không phải là sự cẩu thả — đây là cách duy nhất để kiểm soát Entropy trong một môi trường mà yêu cầu thay đổi nhanh hơn khả năng dự đoán của bất kỳ bản kế hoạch nào.

Ngược lại, văn hóa doanh nghiệp Nhật Bản xem "thất bại" là nỗi sỉ nhục nghề nghiệp. Nỗi sợ sai dẫn đến phản xạ tự nhiên: lập kế hoạch dày đặc, viết spec chi tiết đến từng dòng code, họp hành liên miên để phân tán trách nhiệm. Họ đang cố gắng dùng quy trình tĩnh để thuần hóa một sinh vật động — và cái giá phải trả là sự lỗi thời của cả hệ thống sản phẩm trước khi nó kịp tiếp cận khách hàng.

Nhìn về phía trước

Sức mạnh lớn nhất của kỹ sư Nhật Bản — kỷ luật, sự tận tâm, đạo đức nghề nghiệp — không phải là vấn đề. Đó là những phẩm chất mà bất kỳ tổ chức công nghệ nào trên thế giới đều khao khát. Vấn đề nằm ở bộ khung tổ chức đang giam giữ những phẩm chất đó trong một mô hình vận hành không còn phù hợp.

Trong phần tiếp theo của series này, chúng ta sẽ đi sâu vào một trong những biểu hiện cụ thể nhất của tư duy sản xuất trong ngành IT Nhật Bản: phương thức phân mảnh nhân sự và chia nhỏ công việc — khi phần mềm bị băm nhỏ thành các nhiệm vụ biệt lập, khiến không một ai nắm được bức tranh toàn cảnh hay thực sự làm chủ sản phẩm cuối cùng.