Horenso in the Git Commit: How We Hard-Coded Japanese Communication Standards into Agile Development

In Japanese organisations, Horenso (報・連・相) does not need an introduction. It is a default way of how teams:

報告 (Hōkoku) — report progress
連絡 (Renraku) — share information
相談 (Sōdan) — consult before decisions create risk

It shapes Japanese business culture around structured communication, early visibility, and the avoidance of unpleasant surprises. It is how teams reduce risk and maintain trust in complex organisations.

The challenge appears when this deeply familiar logic meets modern software development. Today, most coordination no longer happens in meeting rooms. It happens inside tools, and these tools were not designed with Horenso in mind. As a result, even technically strong delivery can feel misaligned. The code may be correct, but the flow of information around it does not always reflect the communication discipline that Japanese stakeholders expect by default.

At Unique Technologies, we chose not to treat this as a cultural gap to be “managed”. This article explains how we translated Horenso into concrete practices in Git, Agile practices, CI/CD, and incident management, and why that matters for Japanese clients.

To understand why we went this far, it helps to look at what Horenso actually enforces in Japanese organizations.

Hōkoku, Renraku, and Sōdan together define a simple rule: progress, impact, and decisions must be visible early enough to change course. This is not etiquette; it is a practical way to control risk and responsibility in complex work.

Software projects operate under the same constraints, but the environment is different. Coordination no longer happens primarily in meetings. It happens through repositories, tickets, pipelines, and release processes. If visibility into progress, impact, and decisions is missing at that level, Japanese stakeholders experience the same thing again: a delivery process that feels hard to read and difficult to trust.

In practice, this creates a clear set of expectations for software delivery:

• Stakeholders want early visibility into risks, delays, and scope changes.
• Engineers need to understand who is changing what and why, across multiple services and teams.
• Architectural and business decisions must be discoverable later, not buried in chat history.
• Distributed teams must avoid misalignment caused by time zones and language differences.

For Japanese companies, these expectations are familiar. They reflect the same discipline Horenso enforces in traditional organizations. When outsourcing software development, they are not only buying working code but also a delivery process that makes responsibility, impact, and decision-making visible.

This is why embedding Horenso into engineering practices matters and why its benefits become tangible in day-to-day delivery.

For Japanese companies, Horenso in Japanese philosophy is not academic. It is how they reduce risk in complex organisations. By embedding the Horenso principle into engineering practices, we see several benefits for both sides.

Fewer Surprises, More Predictability

Reporting, informing, and consulting are built into commit messages, pull requests, pipelines, incidents, and Agile workflows. That’s why Japanese stakeholders see fewer “sudden” issues. When something changes, there is a trace. When something goes wrong, there is a record of how it was handled. This, in turn, makes releases feel more predictable, even with distributed teams and multiple time zones.

Better Alignment Across Cultures

For global teams, what is Horenso in Japanese becomes a concrete checklist reflected in tools.

Engineers who have never worked in Horenso-driven Japanese business learn the expectations by following templates and workflows. They do not need to “guess” the cultural rules each time. This reduces friction and the feeling that “we are doing things blind”.

Stronger Sense of Shared Responsibility

When Horenso lives in the system:

• Engineers feel responsible for clear reporting and consultation.
• Managers feel responsible for reacting to the information they receive.
• The client feels that their standards are respected in the technical work.

The result is a more balanced relationship. The outsourcing partner is not just a “factory” that delivers tickets but a team that speaks the same language of responsibility.

For Japanese stakeholders, “shared responsibility” is only real when it is visible and traceable. So, Unique Technologies’ team asked a practical question: where can Horenso be inspected? The answer was not in the meeting notes. It was in the tools that the project’s history was kept.

Traditional Horenso is often taught in the context of face-to-face communication: how an employee reports to a manager, how departments inform each other, and how teams consult before making decisions. In engineering work, the real “memory” of the project lives elsewherу, that's why we mapped the classic Horenso flow to our technical reality.

We mapped the classic Horenso flow to our technical reality:

• Reporting that used to be captured in status updates, email threads, or scattered documents must also be reflected in Git history and project trackers, so progress and intent stay traceable.
• Information that used to be shared via email or meetings must be reflected in pull requests, documentation, and CI/CD notifications.
• Consultations that might otherwise happen informally now need to be visible in how we use branches, reviews, and incident channels, so decisions and trade-offs don’t disappear.

Relying on individuals to “remember to do Horenso” was not enough. We treated Horenso as a design requirement for our processes, which we call Horenso-by-design. Instead of being a soft expectation, it became something that is:

• Encoded into commit and PR templates.
• Reflected in the structure of Agile processes.
• Supported by automated notifications.
• And built into incident workflows.

With that foundation, we could work through each layer of our engineering process and ask: “If a Japanese stakeholder looked at this, would they recognize the logic of report–inform–consult?”

The most natural place to start was our version control history. Git is where every change to the system is recorded, but it can just as easily hide intent as reveal it. So we asked ourselves: what would Git look like if it consistently reflected Horenso, not only code?

Git history is not just a list of changes. For Japanese stakeholders, it can be a source of trust or a source of doubt, depending on whether it makes intent and impact visible. That is why we started by tightening the way we write commit messages.

Hokoku in Commit Messages: Report What and Why

A meaningful commit does not just say “Fix bug” or “Update code”. We encourage messages that answer three questions:

• What changed?
• Why did it change?
• How does it affect the system or the user?

For example:

• Fix incorrect tax calculation for the monthly plan (JP market rules).
• Add retry logic to the payment API client to reduce timeout errors.
• Refactor booking validation to support the new cancellation policy.

This is hokoku inside Git: a structured report from the engineer to anyone who will read this later, including non-developers who rely on clarity and traceability.

Renraku via Links and References: Inform the Right People

Renraku is about informing relevant parties about facts and decisions, not about yourself. In Git and issue tracking, this means:

• Referencing ticket IDs in commits and pull requests.
• Mentioning related services or modules.
• Tagging reviewers or stakeholders when something affects their area.

Example pull request title:
JP-1245: Update invoice layout for new consumption tax format

Inside the description:

• Link to the design or Figma.
• Short note: “Impact: affects only Japanese PDF invoices, not CSV exports.”

Now, a Japanese PM who tracks Horenso in Japanese business does not have to ask, “Who did this?” or “What does it touch?” The information is already there, compact and technical, but understandable.

Sodan via Branches and Pull Requests: Consult Before It Is Too Late

To support Sodan (consulting), we use:

• Draft pull requests labelled as “RFC” (request for comments), not ready for merge.
• Small branches focused on one change, easy to review.
• Explicit questions in the PR description, for example:
  “Is this validation logic aligned with the latest contract rules?”
  “Can we deploy this in the same release as feature X, or should it be separate?”

This makes consultation a normal part of the workflow rather than a last-minute escalation. Over time, the Git history stops being only a code log and becomes a record of how the team reported, informed, and consulted at each step.

Having brought Horenso into Git, we then turned to the patterns that structure everyday work.

Most Agile teams already have daily standups, sprint reviews, and retrospectives. The question is not whether these ceremonies exist, but whether they reflect the same discipline that Japanese managers expect from Horenso.

Standups: From “What I Did” to “What You Should Know”

A basic standup is often just: “yesterday/today/blockers”. With a Horenso communication mindset, we adjust the focus:

• Report: what was actually completed, not just started.
• Inform: what might affect others (changes in interfaces, timelines, risks).
• Consult: where we need input or decisions.

A standup update might sound like this:

“I finished integrating the new payment gateway (report).
It changes the callback payload, so the analytics pipeline and customer support scripts will be affected (inform).
I need to consult with the analytics owner on how we handle the new error codes before we roll out to production (consult).”

For Japanese stakeholders listening in or reading summaries, this pattern feels familiar. It mirrors Horenso-style meetings, just applied to technical work.

Structured Reviews and Retrospectives 

We apply the same structure to sprint reviews and retrospectives:

• In reviews, we focus not only on what was delivered, but also on which changes require attention from other teams or from the customer.
• In retrospectives, we treat incidents, delays, and successes as material for structured reporting, information sharing, and consultation on process changes.

The effect is that Agile processes stop being loosely structured conversations and turn into recurring points where Horenso is reinforced.

The last major step was to ensure that our automation, and not just our meetings, also “speaks Horenso”.

In modern projects, a significant part of communication flows not through people, but through tools: pipelines, deployment dashboards, and monitoring alerts. If those signals are unclear, no amount of good intentions in meetings can compensate.

CI/CD Pipelines

We treat CI/CD pipelines as a form of automated hokoku and renraku. Each pipeline run is expected to answer the questions a stakeholder might ask before they even ask them:

• Did the build succeed?
• Which tests failed?
• What changed in this release?
• Is it safe to deploy now?

To support this, pipelines:

• Post clear status updates to team channels.
• Produce short change summaries linking back to tickets and commits.
• Expose dashboards where environment health is visible at a glance.

Notifications such as “Service X deployed to staging” or “Release Y includes changes affecting JP billing flow” are not just for developers; they demonstrate to Japanese clients that reporting and information sharing are built into the process itself.

Incident Management

Incidents are where Horenso is tested most visibly. Quiet fixes and unclear communication erode trust quickly, especially for customers accustomed to structured reporting.

During incidents, we follow a simple but strict pattern:

• Report what happened, what the current impact is, and what is known so far.
• Inform which systems, customers, or regions are affected, and when the next update will come.
• Consult on decisions that involve trade-offs, for example, choosing between a quick workaround and a longer fix.

After resolution, we document a short incident record: what happened, root cause, and what changed in code, infrastructure, or process to prevent recurrence. For Japanese clients, this format is instantly recognizable: factual, transparent, and focused on accountability and learning.

Once these practices were in place, we needed to ensure they were not one-off efforts but part of how every new engineer starts working with us.

At this point, Horenso was already part of our delivery process. What remained was to make it consistent and repeatable across teams. Here are the steps we took:

1. Named the Principle Explicitly

We did not just say “communicate more”. We talked to teams about what Horenso in Japanese means and why it matters for our clients.

2. Introduced Horenso-Aware Templates

To make Horenso a default behavior rather than a reminder, we embedded it directly into our everyday templates:

• Commit message and PR templates with Report/Inform/Consult prompts.
• Incident report templates mirroring Horenso.
• CI/CD notification formats that carry impact and next steps, not just status.

3. Aligned Agile Workflows with Horenso

We adjusted standups, reviews, and retrospectives so that reporting, informing, and consulting became natural parts of each meeting, not accidental.

4. Embedded Horenso Into Onboarding

New engineers learn not only about tech stack and processes, but also about Horenso communication and why our Japanese clients expect it.

5. Made It Visible to Clients

In some projects, we showed Japanese stakeholders how Horenso is implemented in Git, CI/CD, and documentation. This made expectations explicit and built trust very early.

The result is a development process where Horenso is not only a cultural slogan but a concrete, inspectable part of how we work: in commit history, in pipelines, in incident logs, in meeting notes.

If you are looking for an engineering partner who can combine strong technical delivery with a deep understanding of Horenso in Japanese business, let’s talk. We will be happy to show how this approach can work for your projects and your teams.