This article is for the Money Forward Engineers Advent Calendar 2025 on December 15th.

Japanese version / 日本語

Hi! I’m Sho, a Product Development Leader for Money Forward Cloud Company Registration, a product that helps users establish companies for the Japanese market.

The Cloud Company Registration product development team I lead is highly international: over 70% of our members are non-Japanese speakers based at Money Forward Vietnam. I joined the team this past March as the first Japanese engineer. I’ve thoroughly enjoyed being the national minority in this environment.

Recently my teammates have been teaching me a lot of Vietnamese. While Vietnamese pronunciation is extremely challenging for Japanese speakers, that aspect is actually quite interesting to me.

Over the last nine months, I’ve focused on transforming our communication methods to boost team productivity and drive greater value creation. The result has been a dramatic evolution of the team over the past six months.

Achieved 3x Release Frequency, 2-3x Velocity, and Zero Critical Bugs caused by Release in Six Months

In this article, I will reflect on the core challenge we faced—Information Asymmetry.

Past Structure

Our team, in particular, has long operated with a structure consisting of non-Japanese-speaking engineers and Japanese-speaking Product Manager (PdM) and Designer.

Before I joined, the team structure looked like the diagram below:

Note: The arrows indicate the primary communication routes. Communication was still possible elsewhere, when needed, using translation tools or through the support of the Accelerator role. Additionally, while Engineering Managers regularly communicate with all stakeholders at appropriate times, these lines have been intentionally omitted in this article to maintain clarity and prevent the diagram from becoming overly complex.

At the time, the team had an “Accelerator” assigned specifically to dismantle the language barrier between Japanese and non-Japanese speakers. While not from an engineering background, the Accelerator’s interpreting and facilitation skills were crucial in supporting team collaboration.

The Core Issue: Not a Language Barrier, but “Information Asymmetry”

Money Forward set a goal to englishnize its development organization around 2021. When I joined the company in 2022, I could barely read or write in English. Even now, I can’t speak fluently or always convey subtle nuances perfectly. And yes, sometimes I still can’t fully catch what my teammates are saying. My teammates face similar challenges; not a single person on the team is a native English speaker.

The goal we currently pursue is not “Anglicization” or “Internationalization,” but Globalization. This means we don’t demand perfect English. Instead, we prioritize achieving goals by communicating our intent clearly, even if imperfectly, while fully understanding the constraints, diverse cultures, and differences in mindset (reference).

When there’s a gap between expectation and result, and you haven’t mastered the other person’s language, it’s easy to blame the “language barrier.” I felt this way too, thinking:

If we were both native speakers of the same language, things would have proceeded without issue.

However, in an environment where we can communicate imperfectly yet effectively, the fundamental issue wasn’t the accuracy of translation. The true challenge was a lack of context. In this article, I use the term “Information Asymmetry” to describe the disparity in knowledge between the Japanese-speaking and non-Japanese-speaking sides regarding the product’s background and the process of decision-making.

• Differences in “common sense” between you and the other person
• Gaps in knowledge, awareness, and priorities

Most failures to reach agreement or move forward were due to a lack of shared context.

Before I joined, the development team had translation support, but they struggled to access the full, detailed context—including internal information from the Japanese organization and the complete process leading up to development requests.

Due to this Information Asymmetry, the Past structure faced several challenges:

• Narrow Scope of Engineering Responsibility: For 2-3 years, engineers literally received detailed specifications handed down by the PdM. This led to a low resolution (deep understanding) of both user context and the rationale behind specification decisions.
• Specification Black Box: After 7-8 years since the initial release, specifications and background documentation were disorganized, making it difficult to fully grasp the product’s behavior without directly inspecting the implementation code.
• Concentrated Load on PdM: Since engineers lacked the resolution on specification rationale, they couldn’t proactively suggest changes to the PdM to mitigate technical debt. As a result, the PdM had to handle everything from detailed specification review to development requests, leading to overload.
• Bugs: Consequently, the product development team released features that overlooked hidden specifications, resulting in bugs. Both the PdM and the engineers were trapped in a cycle of shared difficulty: “I gave them detailed specs, but they couldn’t release it,” and “We built it, but it broke.”

My mission was identified as looking at the broadest scope within the team, increasing the resolution of the Japanese organizational side, and intentionally expanding the “field of view” for all engineers. I set out to tackle these issues.

The Challenge as a Connector

Given these challenges, for the first few months after joining, I took on the role of a “Connector.” I assumed full ownership of the entire flow: uniformly gathering information from all surrounding organizations, setting goals, defining priorities, and executing the plan to create a “world where the Connector is unnecessary.”

From a Passive Team to a Team Owning “What to How”

One of the first things I addressed was ending the long-standing practice of “limited information provision to engineers.” I shared with the PdM that they should stop writing detailed specifications and instead focus on sharing sufficient background information, clear expectations and detailed use cases.

As a result, even when given abstract requirements, the development team was able to define their own specifications, align with the PdM, release the feature, and eliminate release bugs. The team evolved into a structure that holds consistent accountability from considering the “What” to implementing the “How” and driving the release.

Connector Overload and the Limits of Scalability

Initially, I hoped that by broadening the team’s scope and solving abstract problems repeatedly, the team would grow. However, the load on the Connector was immense. The Connector was consulted or asked for confirmation at every step from product requirements definition to release, making the structure unsustainable and unscalable.

Furthermore, the impact of the Connector potentially misunderstanding something was huge. My actual role was complex: managing government-API-related feature development (which required comprehending Japanese specifications), acting as a technical lead, and managing team members, in addition to being the Connector. The immense load prevented me from focusing on scaling the team and the product further.

Aiming for a Fair Organization

Money Forward aims to create a “Fair Organization” where opportunities are provided uniformly to all members, regardless of nationality or background.

An environment dependent on the Connector, where the product can’t move forward without that single person, is, in my opinion, not truly a fair organization. I wanted to resolve the situation where our talented global members could not make independent decisions without the Connector, thereby making it difficult for them to gain opportunities commensurate with their true abilities.

Our goal is an organization where global members can directly access all information from the Japanese organization, make their own decisions without relying on the Connector, and drive the product forward. I believe that if I, as the Connector, were to step back, every member would become more self-reliant, grow, and be happier.

Six months later, the team has shifted to the structure shown here:

Note: Not all organizations require high-frequency communication.

The key achievement in this new structure is the successful decoupling of information access from language proficiency. While the need for linguistic translation remains, the centralized burden of linguistic and contextual mediation previously carried by the Connector has been successfully distributed across the entire system and largely automated.

Communication support is now primarily handled by the following elements:

• Structuring information using AI templates and request forms (Strategies 2 & 3, details below).
• Facilitating communication with translation tools and leveraging bilingual members (Strategies 3 & 4, details below).

While the “language barrier” has not completely disappeared, the bottleneck it created is being resolved. We have transitioned from a system relying on centralized mediation by a single individual to one that utilizes distributed support and a structured, unambiguous context-sharing system.

Context sharing has deepened with organizations closest to engineering. Each member now owns their scope of responsibility, enabling them to make decisions without needing the Connector role. Communication support is largely unnecessary. The role of the leader (myself, without the Connector title) has shifted to supporting members’ independent decision-making—a setup identical to how a leader trains a team member who shares the same native language.

As a result of the appropriate distribution of the overall development team’s workload, developers are no longer solely focused on implementing assigned tasks. Instead, the team has transformed into one that can allocate time for inter-team knowledge sharing, and now actively engages in the following activities: proactively sharing product knowledge; discussing technical debt and team challenges; and driving autonomous improvements.

Strategy for a Fair Organization: Avoiding Information Compression and Gaining Autonomy

The path to a Fair Organization was challenging. This shift was possible thanks to the cooperation of my supervisor and external teams and the hard work of our product team members including PdM, designer, etc. Notably, adding a bilingual Scrum Master and a Japanese-speaking Vietnamese engineer to the team provided a significant driving force.

We focused on the following four main strategies to fundamentally eliminate Information Asymmetry and enable autonomous decision-making:

1. Avoiding “Information Compression” Between Native Speakers

In cross-functional communication, a large amount of information was exchanged quickly between the native Japanese-speaking PdM and me. However, this often led to information compression: crucial context like the PdM’s ideas or background conditions would be omitted when the information was passed to the non-Japanese-speaking engineers. This limited their product understanding.

I didn’t notice this information compression myself. It was only revealed as a structural problem when our bilingual Scrum Master observed our communication and pointed it out. The very structure where a Connector like me compressed information was what limited the engineers’ understanding.

To address this, we quickly changed the process to avoid information compression between native speakers, creating a system where context is shared directly with the engineers, bypassing the Connector.

2. AI-Driven Standardization of Requirements and Complete Context Transfer

We established a foundation that allows the PdM to fully transfer context to non-Japanese-speaking engineers without the Connector’s support.

We developed an AI template for requirements definition used by the PdM, ensuring the following elements were always included and structured:

• Background
• User Story (with a clear persona)
• Acceptance Criteria (in GIVEN, WHEN, THEN format)

Example of structured requirements generated by the AI template (just example):

### Background

The current health checkup booking process requires phone correspondence during business hours, leading to long wait times, causing 40% of users to abandon their booking.
First-time users must visit the clinic directly to fill out extensive paper forms, which acts as a barrier to accessing preventive care.
...

### User Story

As a health-conscious individual, I want an online booking system that remembers my health checkup history and provides personalized recommendations and booking options. This will allow me to easily book the appropriate checkups without repeating the registration process or missing important follow-up screenings.

### Acceptance Criteria

Note: In practice, this is formatted as a table

ID: 1
Title: First-Time User Registration
GIVEN: A new user (unregistered) accesses the health checkup service for the first time
WHEN: They click "Book Now"
THEN: The system displays a comprehensive registration form collecting personal info, medical history, preferred clinic location, and insurance details, along with a clear privacy policy agreement.

ID: 2
Title: Returning User Visit
... (additional details)

Providing structured requirements as a set to engineers is crucial, making them easy to understand even for non-native English speakers. It also helps engineers who previously lacked context that was outside their immediate scope. I personally read the requirements definition for another product generated using this template, and I could easily understand the user and product flow without any prior background knowledge.

This structured approach means all engineers, including non-native English speakers, can largely comprehend the requirements after a single read, dramatically increasing Refinement efficiency. We saw massive benefits: reduced communication with the PdM/Connector post-development start, and QA engineers could create precise test plans without needing PdM review.

3. Standardization of External Request Flows

External requests (e.g., customer inquiries, product improvement requests from the marketing team) were also subject to the bottleneck of information compression caused by the PdM acting as a single, centralized information channel.

Structural Constraints of the Previous Flow

• Context Loss in Inquiry Handling: Because the PdM acted as the first point of contact, detailed customer inquiry information was often processed and interpreted, making it difficult for the raw data to reach the development team. This lack of necessary context, or its scattering, prolonged the time it took for non-Japanese members to identify and resolve issues.
• Delay in Initial External Feature Requests: Feature requests from the marketing team primarily flowed through the PdM, who defined and finalized the detailed specifications before passing them to the development team. This restricted engineers’ opportunity to propose efficient, technical approaches at the early stages of a request.

Tools and Effects Implemented

To prevent information compression, reduce PdM load, and enhance engineer autonomy, we implemented the following tools. This shifted the system so external teams could provide structured information directly to engineers, bypassing the PdM as much as possible:

• Introduction of Request Forms and Inquiry Forms (Slack workflow)
• Leveraging Translation Tools (Slack Bot)
• Automatic Task Creation (Jira/Asana integration)

The integration of structured request forms with task boards means requests can be submitted smoothly in Japanese. The system has evolved into one where developers can investigate and resolve issues directly among themselves, without needing the PdM’s help. This change not only relieved the PdM’s workload but also enabled the development team’s autonomous contribution.

4. Promoting Bilingual Meetings

To increase synchronous interaction and close the information gap, we have gradually increased Bilingual Meetings. Non-English speakers (Designers) and non-Japanese speakers (Engineers) participate in the same meetings, using translation tools and the help of team members who are fluent in both Japanese and English. We simultaneously utilize automatic translation in Zoom and transcription in Notion.

The increase in synchronous interactions has reliably eliminated the information disparity between Japanese-speaking and non-Japanese-speaking engineers. It is incredibly rewarding to have long-time Vietnam-based members—who have far more experience with the Company Registration product than I do—proactively proposing better designs and user experiences.

Moving Forward

In the next phase, we aim to stabilize the rapid growth achieved in the last six months and pursue even higher quality. We are working to further evolve the entire product development organization so that the team can strongly drive things forward under the next generation of global leaders, regardless of whether they have the advantage of speaking Japanese.

We still have a mountain of challenges ahead. I’ll share one related to the topics discussed here.

While information compression within our team is being resolved, the problem resurfaces when we coordinate with other multilingual teams.

The issue reliably occurs between individuals who share a common language skill set, regardless of which team they belong to. For example, a native Japanese speaker on our team is highly likely to compress information when communicating with a native Japanese speaker on an external team.

This phenomenon suggests that the challenge is not solely a simple language barrier, but a potential for information compression to occur even within a communication channel where both parties share linguistic competence, depending on the context.

Examples include cases where coordination between multiple services is required (as already provided by our company) or complex domain requirements involving foundational microservices managed by another team during inquiry handling. Can we create a mechanism where all stakeholders can autonomously make decisions and move toward problem resolution while maintaining the latest and most accurate knowledge based on our current structure? It sounds like fun!

We are surrounded by talented members who navigated this change with us, and managers and external teams who provided immeasurable support and cooperation for mutual understanding.

I believe that if we can recognize any problem, we can fundamentally solve it. We will continue to strive for a truly Fair Organization where everyone—regardless of nationality or role—contributes to product growth by thinking about the product, freely proposing ideas, making it better from various perspectives, and delivering even greater value to our users.