The "Three Walls" of Technical Debt Hindering DX Advancement. What solutions emerge when we thoroughly confront the root causes of this debt?

Technical debt accumulates through the development and functional enhancements of systems and software. This debt, stemming from system complexity, has become a major factor hindering companies' digital transformation (DX) initiatives. That said, technical debt is something that inevitably arises. It is crucial to understand your company's debt situation and implement solid strategies for repayment.

This time, we explore the theme: "Can technical debt hindering DX advancement be resolved by revising organizational structures?" We examine the root causes of technical debt. Beyond "revising technology and development frameworks," we also consider hints for resolution from the perspective of "transforming the entire organization."

Could "Technical Debt" Hindering Organizational DX Lead to Economic Losses of Up to 12 Trillion Yen?

Amid growing momentum for corporate DX initiatives in recent years, the issue of technical debt has drawn significant attention. Technical debt refers to a situation where, during system development or subsequent modifications, an overemphasis on "efficiency" alone leads to system complexity, causing operational/maintenance costs and development effort to balloon.

In essence, "technical debt" is a metaphor for the increasing burden of system maintenance, likened to "technical borrowing." Just as interest accumulates at a higher rate the more functions are added, the burden of system modifications grows.

The root cause of technical debt often lies in the business environment, where rapidly changing marketing demands and other requirements lead to systems being built by piecing together technologies in an ad-hoc manner to meet these demands. This means that even if a system starts out simple, it frequently becomes increasingly complex over time.

The Ministry of Economy, Trade and Industry's 2018 "DX Report" already addressed the issue of technical debt. According to this report, if systems aren't overhauled to eliminate the debt incurred by legacy systems (those subject to technical debt), economic losses could reach up to 12 trillion yen per year after 2025. This problem is termed the "2025 Cliff," and nationwide support initiatives are underway.

The report also indicates that approximately 80% of companies carry technical debt from legacy systems, and about 70% feel that "legacy systems are hindering DX advancement." So, how should companies tackle this technical debt, which could potentially cause negative growth amounting to trillions of yen annually?

Technical debt that accumulates over time. What are effective repayment methods?

Before exploring solutions to eliminate technical debt, let's first examine the primary factors that cause it. While debt often accumulates due to a complex interplay of various causes, three main reasons can be identified:

Cause 1: Insufficient consideration during the development process

Cases where insufficient requirements definition, development time, or testing during system or software development later exacerbate the debt.

Cause 2: Inherent "Invisibility" of System Development

Software languages and system states are highly specialized, making them difficult for non-engineers to grasp. Consequently, members from other departments like sales or planning often struggle to understand the true state of the technical debt. They tend to unilaterally communicate only their department's needs. As engineers relentlessly respond to these demands, discrepancies in the system accumulate. Often, by the time the issue is noticed, it's already too late.

Cause 3: Due to the "Variability" Unique to System Development

As mentioned in the previous chapter, software used by companies in their business operations must adapt to various conditions—such as their own business processes, organizational structure, commercial practices, and CX design. It cannot be a "build-and-done" project; it must continue to evolve even after completion. To keep pace with changes in IT technology and the business environment, frequent additions of new features can lead to increasingly awkward expansions over time, causing technical debt to balloon.

While the term "debt" inevitably carries negative connotations, as evident from these causes, technical debt is not inherently evil. At the time of development or implementation, it was likely the optimal solution. However, over time, it often becomes increasingly unsuitable for the system.

To address these issues, solutions include technical approaches like "API (Application Programming Interface)" for real-time integration of multiple systems and "cloud utilization," as well as organizational approaches like "DevOps (short for Development and Operations)," where development and operations teams collaborate to enable flexible and rapid development.

For example, a company operating a D2C Inc. business initially built its system as a massive, monolithic application bundling numerous functions. However, as functions became increasingly intertwined within the platform, technical debt gradually accumulated. This slowed development speed, ultimately hindering business diversification.

Therefore, they decided to break down the monolithic system into independent modules based on function. As a result, the development teams responsible for each function could pursue development efficiency.

The choice of approach to repay technical debt rests with each company. In some cases, it may require not only reassessing technology and processes but also reevaluating organizational structure.

The "three barriers" that cause technical debt are the true obstacles hindering DX advancement

Now, let's consider the path to repaying technical debt from the perspective of organizational transformation. While devising strategies to repay technical debt, some companies may find their "organizational debt" coming to light. In such cases, separating "technical debt" and "organizational debt" can reveal the true challenges your company currently faces.

In the previous chapter, we explained that technical debt can arise due to the "invisibility" inherent in system development. The development department and other departments, such as sales and planning, perceive the world of systems and software differently and use different languages. This often leads to miscommunication and fragmentation, which can gradually build into significant barriers within the organization. This organizational culture itself is termed "organizational debt" and, like technical debt, is considered a factor hindering a company's digital transformation (DX).

Let's break down the main causes of this organizational debt into "three walls."

・The First Wall: "The Wall of Prejudice"

When accumulated technical debt within an organization is perceived as "something undesirable," people tend to avoid confronting the debt's actual content. This phenomenon is termed the "Wall of Prejudice" in this article.

・The Second Wall: The Wall of Uncertainty

As systems grow complex, the true state of technical debt becomes unclear, turning it into a black box. This state of not knowing what is happening is termed the "Wall of Uncertainty" here.

・Third Wall: "The Wall of Disconnection"

Communication breakdowns frequently occur between development teams and other departments within an organization. We'll call this the "Wall of Disconnection." When this wall arises, both development and other departments may fail to even designate a contact person, leading to a complete breakdown in communication channels.

How can these three walls be overcome? Let's examine an example of a company that tackled these barriers and successfully repaid its technical debt.

This company, which operates an e-commerce site, prioritized speed and conducted crash development in a period far shorter than usual. This resulted in a mountain of technical debt, including coding with unreadable source code. They found themselves in a situation where significant resources were consumed by site renovations and adding new features.

1.Breaking Down the "Wall of Prejudice"

To grasp the true state of the debt, they removed the "wall of prejudice" and conducted thorough research. This led them to choose the lower-risk approach of "accumulating small improvements" over "rebuilding from scratch."

2.Breaking Down the "Wall of Uncertainty"

We meticulously identified the technical debt that had become a black box while reviewing the composition of legacy systems like the OS and middleware. By removing the "wall of uncertainty," we updated the system to one that anyone could understand.

3.Breaking Down the "Barrier of Disconnection"

We shared the problems we faced, including the negative aspects of technical debt, with management. Through persistent persuasion and efforts to overcome the "barrier of disconnect," we secured a commitment to allocate resources—people, materials, and money—toward repaying the debt.

The most critical point for resolving organizational debt is likely the third step: transforming the organizational structure to eliminate the "barrier of disconnect." While this wall may seem high at first glance, building an organization that fosters cross-departmental communication and mutual understanding not only repays technical debt but also cultivates an organizational culture that doesn't neglect debt. This, in turn, could become a tailwind for further transformation, potentially setting us on a cycle where "DX improvement," "user experience enhancement," and "business growth" all run smoothly.

Technical debt is estimated to cause economic losses of up to 12 trillion yen per year by 2025. As we've seen, technical debt can be resolved by addressing it correctly. To achieve a fundamental solution, tackling the "wall of bias," "wall of ignorance," and "wall of disconnection" is crucial. And if you're going to tackle it, why not adopt a proactive mindset—aiming not just to "reduce negative debt to zero," but to "transform negative debt into significant positive value"—and pursue multifaceted, layered effects like organizational growth and accelerated DX?