The Peril of IT Assets That Cannot Explain “What is Running”
Recently, two news stories were reported almost simultaneously. One was a live demo of “Mill,” an AI agent that analyzes source code and “explains” a system’s specifications and structure through conversation. The other was a Ministry of the Environment hearing regarding a project to promote the digitalization of administrative documents at welfare facilities for persons with disabilities.
At first glance, these seem like topics from entirely different dimensions: cutting-edge technology and social infrastructure. However, when viewed through the lens of “management x IT,” a single core challenge common to both emerges. That is the problem that “the responsibility (accountability) to explain to management ‘what the existing IT is doing’ has not been fulfilled until now.”
The background behind the demand for tools like “Mill” is the existence of long-black-boxed legacy systems. On the other hand, behind the stalled digitalization of welfare facilities lies not only paper-based culture and budget constraints but also the difficulty of clearly explaining and gaining agreement on the “purpose” and “effect” of digitalization among stakeholders. Both have a fundamental lack of “explanation” at their core.
The Technical Possibility for IT Accountability Shown by “Mill”
What the “Mill” demo showed was the potential for AI to extract the business logic and specifications—the “What (what it is doing)” and “Why (why it is that way)”—from the “How (how it works)” descriptions in source code and explain them in plain language.
This is technically groundbreaking, but from a management perspective, what’s important is its “application.” Traditionally, understanding the full scope of an existing system relied on the original developers—a person-dependent task requiring immense time and cost. As a result, the irrational management decision of “the cost to understand is too high, so we’ll operate without knowing” has become the norm.
Tools like “Mill” can dramatically lower this cost, opening the possibility of making “the visualization and explanation of IT assets” part of routine management. In other words, taking inventory of technical debt becomes a daily task executable as needed, not a massive once-a-year project.
Three Structural Reasons Why Accountability Has Not Been Fulfilled
So why has IT accountability not been fulfilled until now? There are three structural reasons.
1. The Language Gap
The language used by engineers and management is fundamentally different. Engineers explain using terms like “API,” “database schema,” and “migration,” but what management wants to know is “which customer process does that function support?” or “which revenue line will be affected if we change it?” This translation work has not been institutionalized within the organization.
2. Misaligned Evaluation Criteria
Because the IT department’s evaluation is overly focused on “system stability (zero downtime),” there is little incentive to “visualize and explain” existing systems, especially if it means touching them. A culture can even emerge where not touching them is seen as the safe strategy.
3. The Value of “Explanation” Itself Has Not Been Estimated
Management has also not recognized the price (time and money) for “having the system explained” as a legitimate investment. As a result, explanation has been treated as a “free and expected” service, with its quality and depth being deprioritized.
The “Explanation” Barrier Faced in the Digitalization of Welfare Facilities
The other news story, about the digitalization project for welfare facilities, sheds light on this “accountability” problem from a different angle. The challenge here is that the “beneficiaries” and the “burden-bearers” of digitalization are different.
While digitalization improves work efficiency for staff (the burden-bearers), its effects are indirect, and it’s difficult to quantify and explain the effects for the direct “beneficiaries”—the service users (e.g., improved service quality). Furthermore, in cases involving public subsidies, accountability arises from the facility operators to the administration regarding “why this tool was chosen” and “were there no other options?”
This closely resembles the situation within a company where “a business department (on the ground) cannot clearly explain the cost-effectiveness of a SaaS solution they want to introduce to management or the IT department.” “It seems kind of useful” won’t get budget approval, but calculating a strict ROI is often impractical. This dilemma blocks adoption.
The First Steps in “IT Accountability” That Management Should Take
To break through this problem, the starting point is for management itself to define and demand a “framework for accountability regarding IT.” Here are three concrete first steps.
1. Demand the Linking of a “Business Map” and a “System Map”
Create a “Business Map” outlining key customer processes (lead acquisition → contract → service delivery → billing → after-service). Then, demand that the IT department or relevant departments create a “System Map” linking each step to “which system (or SaaS) supports it and how.” Tools like Miro or Lucidchart are sufficient. This exercise itself is the first step in visualizing IT’s contribution to the business.
2. Institutionalize a “Proposal Document” Format for New IT Investments
Establish a mandatory format for proposals to introduce new tools or systems, requiring explanation of the following three points:
・The “Business Problem” Being Solved: Something that can be shown with numbers (time reduction, opportunity loss, etc.)
・Alternatives and Comparison: Why this tool? Why not a competitor’s product or in-house development?
・The Ongoing Cost of “Explanation”: The method and estimated man-hours for continuously reporting on the system’s status and effectiveness after introduction.
Recognizing this “ongoing cost of explanation” prevents person-dependency and fosters awareness of managing IT as an asset.
3. Utilize a “Mill”-like Approach for Regular Check-ups of Existing Assets
If your company has legacy systems, position the use of code-analysis AI like “Mill” not as a pre-investigation for a large-scale replacement, but as a tool for “regular health check-ups of IT assets.” The goal is not the massive objective of full comprehension, but to accumulate small, achievable “fragments of explanation,” such as “updating the dependency diagram of core modules” or “creating an index of where specific business rules are written in the code.”
Accountability is Not a Cost, But an Investment to Make IT a Management Resource
AI, represented by “Mill,” lowers the “technical cost” of fulfilling IT accountability. However, the crucial point is management’s requirement definition—who demands that explanation, for what purpose, and in what format.
The difficulty in digitalizing welfare facilities lies not in digitalization itself, but in the difficulty of the process of explaining its value to diverse stakeholders and building consensus. It is exactly the same within companies.
Management asking, “What is this system doing?” and recognizing the time and budget to answer that question not as a “cost” but as an essential “investment” to maintain and enhance the value of IT assets—this is the most reliable first step in transforming black-boxed IT into explainable, strategically utilizable true “management resources.”
IT that cannot be explained is no longer an asset; it is merely a liability that could explode at any time. The work of visualizing that liability and returning it to a manageable state is arguably the most needed practice of IT strategy in management today.
Comments