A 40-page specification. A development team that followed every line of it. And then, at the demo, the client says it quietly: 「動くけど、これじゃない」 — it works, but this isn’t what I wanted.
Nobody did anything wrong. Yet both sides have just lost three weeks. After six years working with Japanese companies, we have come to see that most trouble on offshore projects in Japan does not come from the engineering team’s ability, but from a gap in information that an accurate translation cannot close.
Drifting apart is not a translation problem
If language were the only cause, hiring a better interpreter would fix it. In practice, plenty of projects with an N1-level interpreter still drift — because in any business requirement, the written words are only the top layer. Three layers underneath usually go unrecorded:
- The requirement nobody wrote down. The client writes “monthly revenue report” assuming everyone knows that means the fiscal year starting in April.
- The business context. A field that looks harmless may be serving an approval process only the accounting team knows about.
- Unspoken quality expectations. A screen that is 4px off is not a “small detail” — it is a signal about how careful the whole team is.
None of this is in the document, so there is nothing to translate. It only surfaces when somebody asks the right question.
Four common causes
- Translating the words without understanding the business. When a client says something vague, a language-only interpreter faithfully reproduces exactly that vagueness — honest, but useless — and the developers fill the gap themselves. A BrSE stops and asks: “Which field determines priority?”
- Documents written on shared assumptions. Japanese specifications are usually written for a reader already inside the organisation — someone who knows the process and who approves what. An offshore team has none of those assumptions, so the same document describes two different systems.
- Mismatched reporting rhythms. Japanese working culture puts weight on 報告・連絡・相談: if something looks off, you report it immediately, even without a solution. A week of silence does not read as “all fine” — it reads as “not in control”.
- Decisions passing through several approval layers. A seemingly small question can take a week to clear 稟議. The way to handle it is to batch the questions that need approval, send them earlier than you need them, and work on what does not depend on the answer while you wait.
How a BrSE differs from an interpreter
| Project interpreter | BrSE (bridge engineer) | |
|---|---|---|
| Joins from | When a meeting is scheduled | The requirements phase |
| Output | Translated content | Clarified specification, minutes with decisions |
| When a requirement is vague | Reproduces the same vagueness | Asks until it is implementable |
| On spotting a risk | Out of scope | Raises it, proposes alternatives |
| Accountable for | Accuracy of the translation | Both sides understanding the same thing |
The last row is the crux: an interpreter’s job is done when the sentence has been carried across accurately; a BrSE’s job is done only when both sides genuinely understand the same thing.
Three questions to test a partner
- Who will talk to us directly in Japanese, and does that person have an engineering background? If the answer is “we have an interpreter”, ask who is accountable when a requirement is misunderstood.
- What do we receive after each meeting? A good answer is minutes with conclusions and a list of open decisions.
- If a team member leaves the project, how is the business knowledge retained?
Why a Lab model reduces drift
That third question points at something rarely discussed: with discrete, project-by-project work, every start means learning the business from scratch again. The Lab-type model addresses exactly that — a stable team works as a department of the client, so business knowledge accumulates instead of resetting. By the second year, communication cost drops not because everyone’s Japanese improved, but because there is less left to explain.
In short
Offshore projects in Japan rarely drift because the developers lack skill. They drift because three layers of information never make it from one side to the other — and only someone who understands the business, understands the engineering, and speaks Japanese can carry them across.
At CONCRETE, our BrSE team speaks with Japanese clients directly, with no interpreter in between, and joins from the requirements phase. As a member company of ARCHIPELAGO Inc. in Tokyo, we can also arrange for a Japanese PM to work alongside the engineering team in Vietnam. See our engagement models or get in touch.