This article is the 13th of the Bill One Development Unit Blog Relay 2025!
(A few days early, but) Merry Christmas 🎅
I'm Nobu, a software engineer at the Bill One Engineering Unit.
The PO (Purchase Order) group I belong to is responsible for developing features that match invoices and purchase orders. The group consists of 4 teams in total, but only one team is based in Japan, while the other three are based at SGDC (Sansan Global Development Center) in Cebu, Philippines.
We released the "AI Auto-Matching" feature at the end of October 2025 after several months of development. This function automatically matches purchase order data with invoices registered in Bill One, at both total amount and line item levels.
(Reference: https://jp.corp-sansan.com/news/2025/1127.html)
Although we have been working together since the project began, our communication was almost entirely online. This made it difficult to fully understand the specific strengths of our SGDC members, and we worried that we weren't fully leveraging each member's unique skills.
With upcoming development projects in mind, the entire Japan-based PO team (engineers, a product manager, and a designer) traveled to Cebu to deepen mutual understanding, strengthen team bonds, and empower the group as a whole.
During the trip, we organized various relationship-building activities, including a kickoff for the next quarter, team building events, and technical exchanges.
This post highlights some of the initiatives we undertook to strengthen our global development structure.
AI Workshop
An SGDC manager had previously reached out to us, saying "We'd love to hear how the Japan team is utilizing AI." While SGDC members had been experimenting with AI tools, they were looking for ideas on broader applications beyond just coding. This business trip was the perfect opportunity to address that request. The Japan team has been promoting AI utilization as one of our OKRs since this past summer. We believed that we could help further advance AI adoption across the entire PO group by sharing our experience.
Therefore, the Japan team hosted an AI workshop. Since online resources for AI coding assistance are already plentiful, we focused on more practical, team-specific themes: "Sharing and Exploring Domain Knowledge with Notion AI" and "Efficient Code Exploration Using Coding Agents." The workshop combined practical knowhow sharing with hands-on sessions.
1. Sharing and Exploring Domain Knowledge with Notion AI
In Sansan's development process, Notion is more than just a documentation tool. It functions as a database consolidating diverse knowledge, including PBI (Product Backlog Items), specifications, and reference materials for customer success.
However, there was a challenge for non-Japanese speakers. Because much of this information is written in Japanese, traditional full-text search made it difficult for SGDC members whose primary language is English to find what they needed. Because of language barriers, essential domain knowledge was scattered and difficult to share.
The Japan team took this issue seriously and focused on LLMs as a solution. By leveraging the ability of LLMs to provide answers even when questions are asked in English about Japanese information, we should be able to bridge knowledge gaps without the hassle of translation.
Based on this hypothesis, the Japan team spent about a month creating a portal page called the "Purchasing Area AI Portal" to make information easier for Notion AI to retrieve, organizing information related to the PO area. When using this portal as context, we've devised ways to ensure response accuracy by adjusting prompts so that AI references only reliable information.
During the workshop, we explained the background and mechanics of the portal and demonstrated how to use it, followed by a 10-minute hands-on session. Participants accessed the AI portal and asked questions in English about complex specifications written in Japanese. Seeing the immediate answers firsthand helped many SGDC members realize how this tool could eliminate the stress of finding information across language barriers.
▲ A moment from the AI workshop
As usage of this AI grows, we expect to receive new feedback. Like service development, we want to continuously improve this as well!
2. Multi-Repository Code Exploration Using Coding Agents
The aforementioned "Purchasing Area AI Portal" is very convenient, but it relies on organized documents. Therefore, there are cases where it cannot answer detailed implementation-level questions. When documents cannot provide answers about existing specifications, we need to refer to the code, which is the Source of Truth.
However, this approach has its limits. Verifying complex specifications or features often requires investigating across multiple repositories. Tracking code to understand the full flow—from an API request to the final processing logic—is time-consuming. This is especially true for new members, for whom visualizing the big picture while reading code imposes a high cognitive load. To address this, we used the workshop to introduce methods for efficiently exploring multiple repositories using coding agents.
Let me briefly explain the demo setup. Many coding agents (Claude Code, Cursor, etc.) scope their operation to the directory currently opened as a workspace. To overcome this limitation, we created a dedicated directory for investigation and added symbolic links to relevant repositories (like backend and frontend) inside it.
spec_investigation/ ├── backend_repo/ <- symbolic link └── frontend_repo/ <- symbolic link
By making this spec_investigation the workspace, you can include physically separate multiple repositories in the exploration scope. (Note: While Claude Code and others can do the same with the /add-directory command, this method has the advantage of not requiring commands each time and being able to persist the configuration.)
In the demo, using this environment, we demonstrated having AI explain "specifications that Notion AI couldn't answer" and "the processing flow from frontend click events to backend DB storage," showing how AI reads through logic seamlessly across repository boundaries as needed.
In the subsequent hands-on session, we received specific feedback, such as "couldn't we speed it up more by devising prompts to narrow the exploration scope?" and "outputting a flowchart would make understanding the overall picture easier."
The demo setup was very simple - "just creating symbolic links" - but surprisingly few participants were using this method. Many were impressed by how such a simple trick could so effectively maximize a coding agent's capabilities.
This technique isn't limited to investigation. When combined with the planning features in AI tools like Cursor or Claude Code, it becomes a powerful tool for planning and designing new features that span multiple repositories. Participants clearly saw the potential, and I expect this to further drive AI adoption across the PO group.
3. AI Utilization Case Sharing from Each Team
At the end of the workshop, we set aside time for each participating team to share their current AI utilization examples. It was impressive that each team was practically incorporating AI at different phases of the development process.
Utilization for Data Analysis and Decision Making
They had ChatGPT analyze traffic and load trends, using the results to inform decisions about new feature design and whether to expand existing system limits. This is an example of using AI as a sounding board in the pre-stage of requirements definition and architecture consideration.
Automation of Documentation
An effort to streamline Pull Request creation. By passing code changes to AI, they auto-generate PR descriptions. They said this not only reduces creation effort but also creates summaries that are easier for reviewers to understand.
Improving Implementation Quality and Edge Case Exploration
During coding, they ask for suggestions for better implementation patterns and have AI identify edge case scenarios that humans alone might overlook, helping prevent bugs and improve code quality.
Through this workshop, we reaffirmed that AI can become a powerful partner for developers. In particular, I strongly felt the possibility that AI technology could remove the language barriers that SGDC members face, not just improving efficiency in implementation and investigation. We want to continue such knowledge sharing and increase productivity across the entire group.
Risk Storming
With the release of AI auto-matching, our service underwent major changes, including partial architecture renewal and integration with new external systems. It's important for the entire group to understand and have a common awareness of what risks lurk in this new configuration. Also, this initiative aims to contribute to skill development for each team's TL (Tech Lead). To grow as a software engineer, you need the ability to get a bird's-eye view of the service's overall architecture, build designs yourself, and document existing architecture for discussion. With these purposes in mind, we conducted Risk Storming (reference: https://riskstorming.com) as an opportunity to develop experience in structuring architecture, verbalizing risks, and sharing them.
Risk Storming is a workshop technique where the entire team gathers around an architecture diagram to visually identify system risks. The process is simple: first prepare a system architecture diagram, then each person writes out risks they're concerned about (single points of failure, technical concerns, etc.) on sticky notes and attaches them to the corresponding parts of the diagram.
What's important here is risk quantification. As shown in the diagram below, each risk is evaluated by the combination of Probability and Impact, with sticky notes color-coded "red, yellow, green" in order of priority. This visualizes "where risks are concentrated" in the system like a heat map. By conducting risk analysis, which tends to be siloed, with multiple people, you can prevent oversights and quickly advance consensus building on priorities (probability × impact).
Source: Risk-storming
For the practice, we proceeded based on the standard flow advocated by the official website (riskstorming.com). This time we used Miro as our collaboration tool, and all participants attached sticky notes in real-time to an architecture diagram drawn in advance on Miro.
▲ Work screen on Miro. Each member attached sticky notes like this
▲ A moment from the workshop
After everyone placed their sticky notes, we took turns explaining our identified risks, discussed them together, and adjusted the risk levels accordingly.
On a personal note, having joined the company just six months ago, I focused primarily on specific components within the AI auto-matching project. As a result, I inevitably had gaps in my understanding of domains I wasn't directly involved in.
This workshop brought together TLs from each domain, giving us the opportunity to discuss risks from multiple perspectives. It was incredibly beneficial to understand these risks and their context proactively, rather than discovering them during an incident. Typically, I might only learn about risks in other domains while troubleshooting a problem. However, being able to share potential risks calmly with other TLs has convinced me that our future development collaboration will be much smoother.
This workshop doesn't end with just finding risks. The identified risks will be added to the product backlog, and we plan to adjust priorities with other items and address them systematically.
Offline Interaction
We've covered serious technical topics so far, but I'd also like to touch on interactions that were only possible because we visited in person.
The Japan team includes one QA member based in Cebu, so this trip allowed us to hold our first-ever full team standup. Usually, we interact solely online, but gathering in a circle to share progress in the same space significantly boosted our team unity.
▲ Standup with all team members gathered offline
We also enjoyed a 'PO Group Dinner' hosted by the SGDC manager to welcome the Japan team. Since the trip was effectively only two days, our schedule was packed with daytime activities. After a tiring day of technical discussions and future planning, it was refreshing to gather as a group and bond over non-work topics. This was a true privilege of meeting in person. We were treated to local Cebu delicacies, including lechon (roasted whole pig), making for a delightful cross-cultural experience.
▲ Manager carving the lechon for everyone
▲ Lively conversation with drinks flowing
Sharing a meal allowed us to see sides of each other that rarely come out in online meetings, bringing us much closer together. Understanding the personalities behind the screens makes daily collaboration so much easier. Building this trust outside work was a key success of the trip.
Summary
Through this trip, we went beyond just work collaboration. By sharing meals and casual conversations in the office, we significantly bridged the gap with the SGDC teams. For members who had previously only interacted online, experiencing each other's personalities and enthusiasm firsthand was invaluable. This newfound mutual understanding will undoubtedly make our future communication smoother. We fully achieved our goal of deepening bonds and empowering the entire group. Leveraging the trust we built, we are now ready to tackle upcoming projects with even greater unity!
P.S.
My only regret is that due to the tight schedule, I didn't get to see the beautiful ocean, despite traveling all the way to tropical Cebu. If I have another chance to visit, I definitely want to make time for activities like island hopping!
Finally, I want to express my sincere gratitude to the SGDC members for their warm welcome and support. Thanks to them, my stay was incredibly comfortable and I thoroughly enjoyed my time in Cebu.
Sansan’s Technology Division Offers Casual Interviews
The Technology Division offers casual interviews for both mid-career and new graduate candidates. From the perspective of active engineers, we share insights into what it’s like to work in Sansan’s Technology Division and the appeal of the work itself.
If you’re thinking, “I’d like to hear directly from people who actually work there,” or “I want to know in advance what kind of people I’d be working with,” we encourage you to consider applying.
