If all you have to do is implement a system, then just read the specifications and you're done! …Really?
I had just returned from a business trip to London.
The purpose of the trip was to introduce a system used in the UK into Japan.
At first, I thought:
“If it’s a UK system, all we need to do is read the specifications.”
Understand the system requirements.
Check the functions.
Then implement them in Japan.
Simple enough.
But as soon as I actually started reading the requirements, I ran into a wall.
“This simply won’t work as it is in Japan…”
A System Reflects the Business of Its Country
The reason was simple.
The business rules underlying the system itself were different between Japan and the UK.
The securities industry, in particular, has a complex, multi-layered structure of rules.
First, regulatory authorities and exchanges establish the rules.
Large banks and securities firms then translate those rules into their own business processes.
Smaller securities firms follow and support those rules.
Eventually, those rules are passed down to the end customers.
In other words, you cannot understand the whole picture by looking at the system alone.
To bring a system into Japan, you first need to understand the business structure behind the system.
Translating UK Business Rules into Japanese Business Rules
That was when I realized that this was not simply a system implementation project.
The business rules coming from the UK had to be adapted to Japanese business practices.
Then, the system had to be implemented in a way that supported those Japanese business processes.
In other words:
UK Business → Japanese Business → Japanese System
That transformation was essential.
Simply going to London does not mean you automatically understand how to implement the system in Japan.
Reading the specifications does not tell you how the system should actually work in the Japanese business environment.
That is why you need someone to serve as a bridge between the UK system and Japan.
Then I Met Some Remarkable People
During the project, there were people who came from London and stayed in Japan to provide support throughout the implementation.
At the same time, people were hired on the Japanese side who could speak English and also understood the system.
Their role was much more than that of a traditional IT specialist.
They understood the business processes on the UK side.
They understood the system architecture.
They understood the business processes in Japan.
And they could articulate the differences between the two sides and connect them.
They understood English, Japanese, business, and systems.
I was genuinely impressed when I saw how they worked.
Going Beyond “Full-Stack”
In the technology world, we often use the term “full-stack.”
It generally refers to someone who understands the entire technology stack, from the front end to the back end.
But these people were different.
They understood more than the entire system.
They understood languages. They understood systems. And they understood the businesses of both the UK and Japan.
That went beyond what I had previously understood as “full-stack.”
They connected:
Country to country.
Business to business.
People to systems.
They were the bridge between different worlds.
It Looked Like a New Way of Working
To be honest, they looked extremely busy.
But at the same time, their work looked fascinating.
I remember thinking:
“So, this kind of job exists.”
I was fascinated by it.
Looking back now, I realize that this was not simply a story about implementing a system.
The people who create real value through DX are not necessarily those who only understand technology.
Nor are they simply people who understand business.
They are people who can understand different worlds and connect them.
When introducing an overseas system into Japan, translation alone is not enough.
What is really needed is the ability to translate the business itself.
Perhaps this is one of the capabilities that future DX professionals will need most:
the ability to cross boundaries.
コメント
コメントを投稿