When Japan makes cameras, they become the eyes of the world. When it makes cars, they drive on roads around the world. When it makes factory equipment, it moves production lines in other countries. And yet, the moment you open a banking app or an enterprise system, it can feel as though time is moving backward. Why is a country that makes world-class hardware slower than Korea when it comes to software?
According to the World Bank’s 2024 balance of payments statistics, Korea exported $16.5 billion in ICT services, while Japan exported $11.7 billion. The figure combines telecommunications, computer, and information services, but Korea was ahead even in absolute terms, despite having a much smaller population and economy. In the 2025 statistics, Korea also had 13 unicorn startups, compared with Japan’s eight.
I once met someone who was officially an executive at Japan’s largest telecommunications company while also serving as an executive at an IT consulting and vendor company. Seeing the names of the client company and the vendor together on one person’s business card captured the relationship at the heart of Japan’s IT industry. In Japan’s software industry, clients and vendors had long formed an ecosystem hardened through the exchange of people, careers, and systems.
In Japan, 72 percent of IT workers, including developers, belong to SI companies—in other words, vendors—while only 28 percent work at operating companies. In most other advanced countries, including Korea, the United States, the United Kingdom, Germany, France, and Canada, the opposite is true: more than half of IT workers work at operating companies. Japanese companies have many people who order and inspect systems, but relatively few who look at customer reactions and directly build the next version.
During Japan’s period of rapid growth, companies developed generalist talent over many years on the assumption of lifetime employment. It was difficult to hire hundreds of developers internally for times when projects piled up and then move them to other work. So, it is said, a collaborative structure took hold in which vendors handled specialized talent and fluctuations in schedules.
Large Japanese companies ordered systems dedicated to their own businesses from vendors, and vendors accumulated exception features for each customer. The company that built a system came to know it best, so it naturally handled the next round of maintenance as well. The more the client borrowed development capabilities from outside, the more internal knowledge it lost. And the more internal knowledge it lost, the more it depended on the same vendor.
Then came man-month contracts and multiple layers of subcontracting. Clients bought the number of people to be assigned, the length of time, and a list of features rather than the results they needed. The prime contractor then requested workers from subcontractors. Any change not written into the contract became a matter of additional cost and responsibility, rather than an improvement in quality.
Even when someone on the front line discovered an inconvenience, a developer could not fix it right away. It had to pass, one by one, through the approvals of the responsible department, the information systems department, the prime vendor, and the subcontractor. Several companies and layers of approval came between the person who found the problem and the person who could fix it. AI can fix code overnight, but in front of an approval board, it waits a month.
This structure was immediately safe for both sides. The operating company did not have to employ development staff permanently, and it could push responsibility for failure outside the contract. The vendor gained long-term maintenance revenue. In return, the operating company lost the ability to judge products and its technical knowledge, while the vendor came to work toward deadlines and inspection checklists rather than the customer’s business results.
It became possible for everyone involved to finish their part exactly while the product as a whole failed. The client received the specified features, the vendor submitted the required documents, and the inspector stamped the checklist. Whether the user could actually finish their work more quickly was never a question the contract asked. The project passed, but the user could not finish the work.
Similar things happened in Korea through the multiple layers of subcontracting at large companies’ IT affiliates and public-sector SI firms. But as competition on the internet and mobile platforms unfolded at world-leading speed, portals, games, e-commerce, financial platforms, and startups kept developers inside the company and watched metrics and customer reactions every day. The CEO’s decision reached the product team immediately, and when users dropped off, they updated the product instead of waiting for a contract change.
Japanese manufacturing found defects on the production line, fixed the process, and accumulated quality. Fixing drawings and dimensions first and requiring suppliers to follow the same specifications improved the quality of mass production. Japanese companies likely applied this successful formula to software as well.
A car door does not need to change shape the week after a car ships. But if half of the users drop off on an app’s sign-up screen, it needs to be fixed the next day, if not sooner. Hardware grows stronger by repeating a fixed answer without error. Software grows stronger by finding an answer it does not yet know together with its users. Factories gained quality by reducing change, while software organizations lost the speed of learning by blocking it.
Large Japanese companies punished accidents caused by changing things without approval severely, while Korean internet startups were more wary of losing users by failing to change things in time. In Japan, the person who delivered the agreed specifications precisely was safe. On a Korean product team, the person who launched, looked at the numbers, and built the next version survived. Organizations later call the behaviors they repeatedly reward culture.
The age of AI may expose this difference even more starkly. As the cost of creating code falls, the ability to decide what to build, read user reactions, and roll back a bad deployment becomes more valuable. Even if a developer can make a fix in an hour, if changing the contract takes a month, the product will change a month later.
The bigger problem is that software no longer stays within a single industry. Cars update their operating systems and driver-assistance features even after they leave the factory, and cameras compete through computational photography algorithms as much as through their lenses and sensors. Factory equipment continuously changes its performance through sensor data, digital twins, and AI control. Nearly everything we use, from refrigerators and medical devices to warehouses and farm machinery, is being redefined through software.
This change could create a major crisis for Japan. The software-ization of hardware does not erase Japan’s strengths. Its precision manufacturing and component technology, quality control, and knowledge of safety remain powerful assets. The problem is that products cannot evolve quickly if the authority to make decisions that move those assets remains outside the organization. The ability to deliver a finished product accurately is no longer enough. The ability to keep observing, learning from, and fixing a product after it is sold has become part of manufacturing competitiveness.
Owning software does not mean keeping the code files. The person who discovers a user’s inconvenience must be able to set priorities, make changes, deploy them, and check the results directly. Owning hardware will not be any different in the future.
It is already too late if all you can do is decide how to change the product tomorrow. If a user is stuck right now, you need to be able to fix it right now. In an era when everything is becoming software, there is one question that will determine the future of all of us, including Japan.
Right now, when a problem has just appeared, who can fix it?
