Nobu Sato

Eighty percent of Japanese companies use the cloud. For what?

Eighty percent usethe cloud.For what?

Series「Five numbers to read before entering Japan」 · Part 5 of 5

Japan's Ministry of Internal Affairs and Communications runs a survey on communications usage every year. The 2024 results: more than 80% of Japanese companies use cloud services. Ten years earlier the figure was in the 40s.

Eighty percent can be used to prove anything. People who want to say Japan lags on digital will say the US passed 90% long ago. People who want to say it doesn't lag will say 80% is mainstream. Neither touches the question that actually matters to a software company entering Japan: what are those 80% using the cloud for?

Split by use

The same survey breaks it down. File storage and data sharing: 71%. Internal information sharing and portals: 58%. Email: 57%. Business systems such as payroll, accounting and HR: just over 50%. Schedule sharing: also just over 50%.

In other words, 80% use the cloud, but most use the shallowest layer: they moved files from local disks to the internet. Companies that have actually put business processes in the cloud are around half, and they cluster in payroll and accounting, areas with statutory formats where a company doesn't have to define its own process.

At the end of 2025 the SME support agency asked a thousand SMEs whether they were doing or considering DX: 39% said yes. That doesn't contradict the above. Storing files in the cloud isn't DX, and 60% of SMEs don't feel they need it.

File storage / sharing71.0%Internal portal57.6%Email56.8%Payroll / accounting / HR52%Schedule sharing51%Share of cloud-using companies · MIC 2024

Fig.1Among companies using the cloud, share by purpose. File storage 70%; business systems barely half. Payroll and scheduling are given only as "over 50%" in the survey text and shown here as 51–52.

The usual readings: behind, or not behind

Both readings try to answer "what stage is Japan at," which is a researcher's question. The entrant's question is different: what kind of product can this market absorb right now?

The method's reading: product strategy precedes sales

My order for designing an entry is: two maps first, then product, then sales, then organization. The product step asks: what is the market's structure of acceptance, and in what form does my product have to arrive to be absorbed?

The structure these numbers describe: customers are used to putting things in the cloud, not to handing processes to it. They accept substitution tools, storage and communication, and lag visibly on tools that change how they work. There's a structural reason. Business processes in Japanese companies are highly company-specific; every firm is different. A SaaS product that asks customers to follow the software's process meets, in Japan, the sentence "our way is different."

HQ's product mostly grew up in a market where processes are standardized and customers are willing to adapt to the software. Transplant it unchanged into a market where 80% store files, half run processes, and every process is different, and the failure to sell isn't a sales problem. It's a mismatch between product form and the structure of acceptance.

The action: shape the product to the structure of acceptance

The entry decision this number changes: what to change in the product first.

Three directions. One: put the entry point in the layer customers already use. Files and email are what 70% use; a new tool that enters as "manage the files you already have in the cloud" gets in far faster than one that enters as "replace your workflow." Two: make processes configurable rather than preset. Japanese customers will ask to do it their way, and the product needs room for that, even if the home version never did. Three: sell substitution first, change second. In year one you sell "the same as what you do now, but in the cloud"; in year two you sell efficiency. Reverse the order and year one ends at the door with "our way is different."

This is also the other side of the Conway's law post: the answer to which block of functionality the Japan team should own is here. Localization isn't translating the interface. It's building the layer that makes processes configurable, and the Japan team should own that block completely.

Check yourself

The product you plan to bring into Japan: does it let customers put what they already have into the cloud, or does it ask them to change how they work? If the latter, discount year-one sales forecasts on the assumption that half the market isn't ready.


Shorter notes that don't make it into a full article go on LinkedIn. Follow me there.

Writing about launching in Japan, in three languages.