Meet the Engineering Manager Who Calls the Difficulties of Mercari’s Transaction Infrastructure a “Golden Opportunity”

Mercari launched as a service in 2013, and in eight years managed to exceed 20 million monthly active users. But right now, a large-scale revamp of our development platforms is happening behind the scenes to support our front-facing growth.

We call this project Robust Foundation for Speed (RFS for short). It is meant to support disruptive growth across all of Mercari Group, by solving complex technical challenges and drastically strengthening the foundation shared across our businesses.

In this Mercan series, we interviewed four key people leading this very large-scale project. We walked through each of their careers as we took a look at their involvement in this project and why this project is happening now. Following our interviews with Mercari CTO Ken Wakasa and RFS Project Owner Minoru Tsuka, we spoke with Hidenori Goto (@hidenorigoto). Hidenori is the Engineering Manager of the Backend team responsible for Mercari’s Transaction area.

＊The mask is removed only when taking pictures.

Turning a microcomputer into his first programming tool as a child

ーSo why did you choose to become an engineer?

I don’t really think of the path that led me to become an engineer as something I chose. Ever since I was a child, I thought that I would work as a programmer. When I was in elementary school, microcomputers—which were the precursors to personal computers—were all the rage. My father bought one as a toy, and I asked him to let me use it while he was playing with it.

Back then, unlike the computers we have now, you would enter commands on the screen using BASIC language, and the terminal would generate sounds or draw simple graphics. But at that time, watching as the microcomputer operated exactly as I had programmed it was a thrill for me. So as an elementary school student, I was really into playing video games, but I was also keen on creating things by programming things on the family microcomputer.

ーFascinating! So even as a child you already had it in your mind that you wanted to work in programming. And when you joined the work world, did you jump right onto an engineering career path?

Actually, there were a few twists and turns along the way. In high school, I dedicated myself to studying for my exams and forgot about computers for a time. The university I got into wasn’t big on IT, but rather the sciences, so that was my path for a while. But one day it just occurred to me that the path I was on was too academic and wasn’t for me.

When I went back and took stock of what I wanted to do, I remembered that I used to like programming. So I went and bought a computer, and when I tried programming, it hit me that this was obviously what I wanted to do for a living. After that, I started over by studying computer science on my own and got ready to start looking for work.

ーWhat sort of work experience have you amassed since then?

At first, I joined a small software house (generic name for a company whose business activities include such things as software development and sales) as a part-timer and improved my skills while working on creating programs; I eventually started working at that company full time. After that, much like when I tried to start my own small company, I would say that I was more often involved in creating and designing software as a software engineer and working up close on development.

ーOnce you started working, did you still enjoy writing computer code the way you did when you were a child?

Sure I did. That’s because I also had the experience of writing code that was useful to people. The joy I get out of writing code and the drive I feel to create something that will serve others remain unchanged.

Hidenori Goto （@hidenorigoto）

Awareness of a particular problem made him an engineering manager

ーSo after you had gained experience as an engineer, did you then take up your role as a manager at Mercari?

As far as my career goes, in essence, yes. I became a manager when I joined Mercari. When I started working at Mercari, my perspective was that of a soloist developer, so I did tend to think that if I could solve whatever problems existed with the software itself, all would be well. But now that three years have passed since I joined the company, I feel I have some insight into the issue of the same problems reoccurring if a development organization and its people don’t operate well.

ーWhat do you mean?

Well, Mercari is of course growing nicely as a service, and the company has expanded its business to the size it is now. I would say the force behind our rise is the company’s appetite for growth and new things. This hunger has resulted in huge contributions to the company’s growth, which is great, but at the same time it also has a negative aspect. Namely, we have not been very proactive about methodically getting rid of things that have outlasted their purpose.

ーSo if I understand this correctly, you’re saying that in the past we’ve tended to gravitate toward creating new things, but have had less success getting rid of what we no longer need. Would you say that’s still the case?

Well, I think we could benefit from having more systematic mechanisms for getting rid of things that have served their purpose. For example, there have been times where our product managers and development teams finish creating a feature… But then, a new quarter rolls around, and we begin working on something entirely new. And then when the feature we created before is no longer needed, I find that we’re unable to decide quickly about whether to delete it.

This issue is no one’s fault. But that said, software maintenance must be taken care of by people, and there’s only so much that one person can grasp by themself. In that sense, I feel that it’s necessary—for our engineers in particular, but also for our organizations—to always keep in mind how we can “keep It simple.”

ーSo is there anything that you or the members on your team have started working on recently to tackle these kinds of challenges?

Looking at examples of what we have done thus far, I would say that we’ve included periodic refactoring in our OKRs and focused on deleting code. But our engineers’ reactions to these things have differed from person to person. Our more experienced engineers know how important refactoring is, so they agree with including it in our OKRs and taking action on it. However, neither I nor the engineers I work with think that continuing to work this way is the right way to go. Asking whether refactoring is contributing to our business is a slightly different matter from asking whether the company is evaluating the contributions of refactoring.

ーI suppose that things that contribute to the growth of the company, like creating new things, tend to draw attention, which makes it hard for something like refactoring to get acknowledged.

Yes, and that’s why it’s important for us to keep growing the business and keeping our software small and simple. I think this is especially important for teams responsible for our development platform. The mission of Camp 4 is a good example of this. We are charged with Mercari’s transaction area and are now working on Robust Foundation for Speed. The camp’s mission is to contribute to business growth and keep the service and the team healthy.

ーI hope you don’t mind me asking, but when you first joined Mercari, was there anything that differed from what you were expecting?

There were a number of things. Before I joined the company, I thought that the foundation PHP code of the Mercari API was more organized than it turned out to be. But when I actually looked at the code, my impression was that I was probably going to have to really put my back into it (laughs).

ーIt sounds like when you were on the outside of the company looking in, you had the impression that things were a little more systematized than they turned out to be.

Yes, I did. The features of Mercari’s backend systems were well crafted. However, ideas about feature groups (in other words, how the architecture should be put together) were not discussed very actively. So for example, currently, if Mercari adds even just a single new shipping method to the existing features, it’s quite the ordeal.

That’s because making this change isn’t a matter of just working with the team that handles shipping systems. We also have to coordinate with the teams related to listings and payments in order to make decisions. And this doesn’t happen just with shipping, but rather with all kinds of features. This is also what slows down our development speed.

ーAre we working on any initiatives to tackle challenges like this?

One of the ideas I have is to take the abstraction concept that people were working on at Mercari US (Mercari’s US-based business) and adopt it here in Japan too.

At Mercari US they have a concept called “Orders” in the transactions area. However, at Mercari JP, only items, users, and transactions exist individually. For transactions on Mercari, only one item can be handled at a time. Mercari US inserted an “orders” concept between transactions and items, which allows them to do things like bundle the transactions of several items with just a few operations, or redistribute funds to contribute to a given area within a single order. I think that if we were to add this concept to Mercari JP, it would open up a host of possibilities.

RFS triggers actions in the transactions feature of the Mercari API

ーMoving on, I understand that Mercari will be focusing on RFS going forward. Could you tell us a little about this? How will you be involved with this project as far as the transactions area is concerned?

For starters, there’s a committee for this project, and it’s structured to drive the activities of each camp. Basically, for the areas that each camp is charged with, the planning and actions roll out according to the course that RFS sets out for us. I’m the engineering head for Camp 4, so the rough outline of my work entails methodically finding and specifying the vision and problems that coincide with RFS and moving forward with these.

Recently, for the area of the transactions feature, which was chosen as the most challenging primary focus area, I worked on specifying a problem, starting a project, and designing an action plan to enable our members to do their work. We now have a plan in place for my team, so our members are actually doing the work. By applying this sort of strategic design ahead of time, starting next quarter everyone on the team will have the same understanding of a well-conceived goal, and I expect us to be able to operate with a certain amount of speed from day one.

ーWhat was your first impression of Mercari’s foundation compared to what you have seen at other companies?

Well at first, I thought it was going to be hard to work with the source code. But the problem wasn’t just with the source code. It looked to me like we would have to methodically create a systematic architecture concept, and that also seemed like it would be hard to deal with.

My previous company was a much smaller organization than Mercari, so when it came to engineering it was possible to look at the entire operation when making decisions. We also had success with modularization. That experience made me feel that there was a need at Mercari for the “abstract concepts” I mentioned earlier.

ーCould you explain exactly what Camp 4 is working on?

Well, for the monolithic repository that is the Mercari API, there are both transaction features and non-transaction features, and currently the transaction features are tightly coupled with a variety of other features. This is what makes it so difficult for us to make changes to just the transaction features. This is where Camp 4 comes in. To begin, we are trying to remake the transaction features so that they are loosely coupled.

In order to accomplish this, we need to investigate how many and what types of features are closely coupled and have an understanding of the content qualitatively. In this quarter we are moving ahead with our investigation by conducting analysis activities aimed at understanding the content of the Mercari API and creating such things as scripts that can automatically detect parts of the API that are tightly coupled. In the next quarter we plan to actually start refactoring the code.

“My basic motivation is coming up with root solutions to problems.”

ーFor your work on this RFS project, what would you say motivates you the most?

Well, as a programmer, I’ve always stuck firmly to my basic motivation, which is that I want to solve problems methodically and from the root. Thus far, I’ve had a lot of experiences where I was disappointed because I was unable to do that. For the RFS that we’re looking at now, I think this is likely a project that we can resolve by tackling the root of the problem. That’s what motivates me.

ーComing up with fundamental solutions feels like it could be a big endeavor that could leave a mark on Mercari’s history. Is that part of what motivates you?

Yes, it is. What I’m involved in at the moment is an area for which Mercari has taken a lot of initiatives in order to grow our business. To be honest, if we were to leave things as they are now, Mercari would still function perfectly fine. However, for Mercari to grow further and develop on a global scale, the company still has a lot of changes to make. This involves more than just engineering, so it is an especially difficult challenge to tackle.

I think this is precisely why dealing with this project from the standpoint of a manager is such a big challenge. And I don’t know if I could find this kind of experience at any other company. I even think that this just might be a once-in-a-lifetime chance, so I really don’t want my efforts to be half-hearted (laughs). I definitely want to take this opportunity to make something tangible and to be able to turn around and say, “Yes! We made that!”

ーWhat would you like job searchers to know about the work you are doing on RFS that might entice them to join your team?

Well, what I can say is that the level of engineering for the work we’re doing on RFS is highly sophisticated. But I think that precisely because of this, once Mercari and other companies start to create and scale various services going forward, the skills and experience our engineers acquire from having worked on this initiative will serve them very well.

Furthermore, working with us will give them a chance to work on a colossal product that uses PHP, and to work in an area that supports the most important part of our business. For a PHP engineer, the chances of coming across another opportunity like this are slim. I feel that the rarity of our work is also tied to the advantages of working on RFS at this particular time.

ーI think another thing that makes our company an attractive choice is that we provide an environment that makes it easy for engineers to work on bold changes like RFS.

I think you hit the head on the nail with that one. With projects like this, what tends to happen at other companies a lot of the time is that even if the engineers want to work on something, the company says “no, not possible.” But at Mercari, this project was written into the OKRs, and rather than telling our people “no,” our work place backed people’s efforts to do more.

Of course, this isn’t a platform for our engineers to vent their grievances (laughs). Among engineers, there’s actually something called “anger-driven development,” so if there are any engineers out there who are feeling a little down about their jobs, I think this will be a good chance for them to work at a place where they can get their fill of initiatives at the office.

In conclusion

We hope that this article helped you better understand one of the key people leading Robust Foundation for Speed. We are looking for members who can help us achieve the goals of this gigantic project.

If you’re interested, please click the link below to learn more. You will find more technology-focused Mercari Engineering articles written by various project members, as well as information about our hiring events.

We’re looking forward to meeting you! Click here to apply!