Introduction

Parts 1 and 2 showed how EUC and Kami Excel rescued frontline teams in the short term but saddled organizations with long-term debt. This installment turns to the present and weighs the light and shadow of modern citizen-development platforms such as RPA and no-code/low-code tools.

They replay the Kami Excel story even as they scale larger and become more binding. Understanding their traits is essential before we examine generative AI in the next part.

Context: Japan’s “work-style reform” policies and chronic overtime issues made RPA a buzzword in the late 2010s. Vendors promised that non-engineers could automate clerical work overnight, and executives embraced the narrative as a quick compliance fix. That socio-legal backdrop explains why the country adopted RPA faster—and often more naively—than many Western peers.

The full series

The light—why they gained traction

Instant results

You can assemble small automations or applications through a GUI without writing code. Replacing daily data entry or rote tasks in days yields palpable impact for frontline teams.

The persuasive power of visualization

Flowcharts and screen mockups are easy to grasp, even for non-specialists. Executives can literally “see” a working diagram, giving them reassurance and accelerating approval.

A first step for the “citizens”

For narrow use cases such as input forms or lightweight workflows, non-engineers can indeed build solutions. This helps organizations broaden the base of people engaged in citizen development.

Shadow (1)—the wall of professional practice

Despite the promise that “anyone can do it,” serious use quickly demands the same thinking as software engineering.

  • Control structures are inevitable. Handling customer-specific branching requires conditionals; processing hundreds of records requires loops; guarding against API delays needs explicit error handling. Drag-and-drop parts aside, this is programming.

  • Data structures matter. You must unpack JSON, map hierarchical data, and normalize dates and numbers. Mere table-like thinking collapses without understanding these structures.

  • System integration remains complex. You still face token expiration, cross-system consistency, and rate limits—classic software-engineering headaches hidden behind the UI.

  • Operations and quality requirements persist. Monitoring, logging, environment parity, release rollback—without operational design, chaos follows. Because logic hides inside GUI elements, observability often worsens.

Confronted with this wall, citizen developers struggle to build and sustain production-grade systems. Specialists remain indispensable, which means the original capacity problem stays unsolved.

Shadow (2)—vendor lock-in and migration pain

Kami Excel at least lived in a file. Data could be exported to CSV, and formulas—though messy—were inspectable. Modern RPA or no-code/low-code artifacts, by contrast, are trapped within platform-specific UIs or configuration files.

  • Switching vendors often means rebuilding from scratch.
  • SaaS shutdowns or specification changes are outside customer control, and accumulated assets can become worthless overnight.
  • PaaS solutions shackle you to a specific cloud ecosystem, making relocation nearly impossible.
  • UI-based logic hampers search and discovery; sometimes you must double-click every block to see what it does.

Compared with file-based Kami Excel, the dependency and debt risk are far higher.

Shadow (3)—the “visualization bias” that seduces executives

Engineers can see that the “professional wall” is unavoidable. Executives, however, watch a GUI flow or screen layout and assume “anyone can handle this.”

Why? Because systems are normally opaque to management. When presented with arrows and forms, they believe they understand the complexity. In reality the same control logic and error handling lurk beneath, and production-ready use still demands engineering expertise.

This gap between executive optimism and technical caution accelerates adoption while inflating future debt.

Toward the era of Kami Excel 2.0

Put it together and RPA/no-code/low-code tools retrace the Kami Excel pattern. They rescue frontline teams quickly, visually reassure executives, and eventually become black boxes that weigh down the organization.

The difference is scale. Kami Excel lived in individual files; modern platforms embed themselves across entire organizations and bind teams with platform-level debt. Their lock-in is even stronger than Excel’s, earning the moniker “Kami Excel 2.0.”

Summary

  • RPA and no-code/low-code tools were embraced because of immediate wins and persuasive visualization.
  • Production use still requires knowledge of control flow, data structures, integration, and operations—citizen developers cannot shoulder it alone.
  • Platform-specific UIs make migration daunting and deepen vendor lock-in.
  • Executive “visualization bias” underestimates these risks and fuels runaway adoption.

Modern citizen development is more powerful than Kami Excel, but also more precarious. Next we will examine what changes once generative AI joins the equation.

Next: The Legacy That Generative AI Saves—and the Legacy It Abandons (Part 4 of 7)