Reading Through the Lens of a PM: Core System Operations Log 5: Improvement Is Not Rebuilding — It Is About Accumulating Judgments

Episode 4 organized the current core system architecture and the decision-making behind it.

So, given these existing systems as a premise, how should we go about making improvements?

When looking at core systems, there are many moments when you feel like "I want to reset everything and rebuild from scratch." I think it's natural to feel that way when faced with the complexity of the configuration, technical debt, and the gap from the ideal.

In reality, however, completely rebuilding a core system is not easy. Operations cannot be stopped, data migration is highly difficult, and there are many hidden dependencies. Even if a rebuild were possible, there is a chance that similar problems would arise in a different form.

So, what do we do?

This article deals with approaches to improvement other than "rebuilding from scratch."

Improving a core system does not mean redesigning from zero. It means revisiting past decisions as a given, reassessing judgments in light of the current situation, and gradually changing the structure.

In this article, we will organize from a PM perspective how to improve existing systems through the lens of "gradually replacing judgments."

1. Introduction: Why Do We Want to "Rebuild from Scratch"?

Many of you probably have various frustrations with core systems.

• Input is difficult
• There are too many fields, and it's unclear what affects what
• Having to access multiple systems is inconvenient
• Small improvement requests take an enormous amount of time or get rejected
• etc...

When these things continue, it's natural to gradually become frustrated and think, "Why don't we just rebuild everything from scratch!?" However, as I have discussed up to this point, the reason things have come to this state lies in the historical background.

While keeping the system running, trying to address requirements as they arise has led to this situation. While I deeply empathize with the desire to rebuild from scratch, I believe it is not realistic, at least in most real-world cases.

• Technical debt
• Increasingly complex configurations
• Entangled operations

We should not follow the emotional "desire to reset" while ignoring these realities.

2. One Step at a Time. And What Is Improvement?

Now, assuming you understand that a full overhaul of a core system comes with extremely high difficulty due to factors such as

• Difficulty of data migration
• Risk of operational downtime
• Learning costs
• Hidden specifications and operations
• Unexpected dependencies

—what should we do?

The answer is very mundane and unexciting, but there is no choice but to improve little by little, one step at a time.
It will involve taking steps like picking up pieces of trash from the floor one by one.

We will optimize within constraints, while being mindful of various limitations, stakeholders, and existing operations.

We will carefully investigate the scope of impact, identify bottlenecks, set priorities, estimate the cost of changes, assess risks, and then go around explaining all of this to stakeholders before moving forward.

There is no drastic revolution in this. But by continuing to walk a path of correcting small distortions one by one, when you look back one day, you will find that great results have accumulated. And what happens at each of those small steps is not redesigning, not rebuilding, but gradually replacing past judgments.

Rather than denying the past, we understand the path that led here, understand the current situation, and improve little by little. Make a small change, feed back what we learned, and make another small change. Repeat.

3. The Attitude Required of a PM

So, what kind of attitude is required of a PM who adopts this small, continuous improvement as a basic policy?
Initially, what came to mind was

• Prioritizing business continuity over optimization
• Making the granularity of decision-making finer and clarifying accountability
• Having a sense of balance and speaking about the future affirmatively rather than negatively

among other elements.

Rather than blaming the past with "Why was it designed this way," thinking about "Given the current situation, how can we improve next?"
I believe that attitude is crucial for continuous improvement.

However, I recently realized that there is something more fundamental than these elements—something that is absolutely necessary beneath them all.
That is respect.

Respect for stakeholders and all parties involved.
Respect for the history of how things came to be.
Respect for the current state of affairs.

Without this kind of respect, no one will follow along on the long, steady journey of improvement.
For efforts that aim to change things drastically in the short term, respect may not be strictly essential.
But in the improvement and operation of core systems, I believe respect is indispensable.

4. Summary

There is no magical solution for improving core systems.
Nor is it the case that breaking everything down and rebuilding it will make things clean.

In reality,

• Without stopping operations
• With consideration for users
• Facing constraints head-on
• Steadily accumulating small improvements

a steady, persevering effort is required.

It is by no means glamorous work.
But I believe that those small accumulations, when looked back upon years later, will have led to significant improvement.
And the foundation that supports that improvement is not technology alone.

The history of how things came to be, the current operations, and respect for the people involved.

Improving a core system is not simply the work of changing a system—it is the endeavor of gradually replacing judgments toward the future, while confronting the history of the people and operations involved.