Impacting the entire domestic tech industry. The true story behind Mercari’s efforts to bolster their technical foundation—the RFS Project.

Mercari: Taking a Step Toward Becoming a “Truly Global Tech Company”
In the reuse market, which is valued at over 1 trillion yen, Mercari has continued to make great strides as the industry leader. This year marks the ninth anniversary of the company’s founding and its unwavering mission to “Create value in a global marketplace where anyone can buy & sell.” The next phase they are looking toward is becoming a global tech company second to none in the world. In this special feature, we bring you a glimpse of where Mercari is today and what the future holds for the company as it continues to evolve.

In October 2021, Mercari launched their RFS Project, an initiative to strengthen their service and feature development foundation.
RFS stands for “Robust Foundation for Speed” and the goal of the project is to drastically strengthen the shared business foundation and resolve complex technical issues lurking therein to support non-continuous growth for the entire Mercari Group.

RFS Project information page

Minoru Tsuka is the Director of Developer Productivity Engineering on the RFS Project. At Yahoo!, where Tsuka worked for 12 years, he witnessed the dramatic transformation of the company from a venture to a major corporation, becoming one of Japan’s leading tech companies.

Tsuka says, “For Mercari to aim for a spot alongside global tech companies such as GAFA, it’s essential to build a flexible engineering organization that can withstand unceasing change going forward.”

What impact will the RFS Project, or in other words, a stronger technical foundation, have on Mercari in the future? To find out more, we talked to Mr. Tsuka.

※This article has been translated and reprinted from the contents of “Engineer Type”.

A shift to strengthening the technical foundation. This is our make-or-break moment if we’re aiming for the global stage.

ーCould you provide some background on the RFS Project launched in October 2021?

Let’s start at the beginning. From about a year ago, I had been frequently speaking to CTO Wakasa about how we should be investing in the technical foundation from an early stage.

All companies, including Mercari, naturally want to focus on developing new features.

Doing so makes it easy to communicate to users and the public that you’re actively improving services, and it’s easier for engineers to feel that they’re contributing.

Although that’s OK for a startup, continuing to focus resources on releasing new features creates a foundation bottleneck at some point, making it difficult to scale products. That point has come for Mercari as well in the last few years.

With this in mind, as mentioned by Mercari CEO Jeff in an article posted on Engineer Type recently, a stronger technical foundation is essential to becoming a truly global tech company.

In a previous Mercari article, I talked about the occasion I met Mark Zuckerberg and asked him what he would invest in if he had the funds to challenge to something new. He immediately replied, “I’d invest more than half of my resources in the platform at an early stage.”

In other words, if we want to become a company with a global influence on technology, we need to focus that much more on investing in the foundation.

The Mercari Engineering Division is particularly diverse in terms of the features it deals with, including microservices, monolithic architecture, and modular monoliths. In order to achieve more free and unconstrained feature development in the future, a solid foundation is essential.

After discussing this with the management and Mr. Wakasa, things began moving forward in earnest in October 2021.

ーI believe you have experience in strengthening the development platform at your previous employer, Yahoo!, isn’t that right?

Yes I do. The development organization at Yahoo! at that time was structured like an inverted triangle. Imagine the top of the inverted triangle as close to the users, such as the frontend, and the bottom as the infrastructure.

Normally, development requests go from the frontend to the backend, and then to infrastructure. In other words, when you have a lot of people in the frontend in an inverted triangle structure, the infrastructure team can’t handle the huge number of requests coming from that frontend side. It prevents engineers from actually implementing the requested improvements, resulting in a bottleneck at the bottom.

At that time, Yahoo! wanted to make the structure into a triangle, or maybe trapezoid at least .

Simply put, it meant that the CTO had to top-down order the transfer of hundreds of engineers from the frontend to infrastructure.

I think it was quite a pushy way to do things, but I also think it was one correct way to make the company more sustainable and improve cost performance concerning planning.

Is there anything similar going on at Mercari?

If nothing is done at Mercari, I believe there is the chance that we could end up with similar problems.

The circumstances are of course different at Mercari and Yahoo!, so a simple comparison isn’t possible. Even so, I want our company to avoid falling into a situation where it’s already too late by the time we notice the problem. That’s as true for me now as it was back then.

This idea of solid investment in the technical foundation as a way to proactively eliminate development bottlenecks was the reason for moving forward with the RFS Project in earnest.

Becoming an organization that demonstrates everything with numbers – “No measurement, no improvement”

It’s been three months since the start of the RFS Project. Can you give some specifics on how it’s moving forward?

We’re figuring out the current system, identifying what’s still unclear, and working to improve those aspects. It’s one step at a time.

For example, at any IT company, there’s always at least one system for which knowledge of the system is lost when someone quits, but the company keeps using the system, right? This is rather common in web-related domains, and forgive the phrase, but people will keep using the system while praying to high heaven that it doesn’t break.

We have the courage to take the lid off of such systems and analyze them. Sometimes the system is too elaborate, making it difficult to improve. But in those cases, we take the time to completely rebuild them into optimized systems.

Measurement is also essential to this process.

Because I’m the so-called “foreman” for this project, it’s up to me to explain what’s going on with a given system.

I need to be able to logically explain everything, determining if there was a point to revamping a certain feature or determining whether there is enough value given the great cost required to improve the foundation.

I need to see the numbers to explain. Without that numerical data, you can’t tell if anything has actually improved, so your explanation has to rely on your feeling about the thing. Relying too much on pure “feeling” gets you into delusional territory, and it’s impossible to assess good from bad.

Manabu Miyasaka, my boss at Yahoo! (current Deputy Governor of the Tokyo Metropolitan Government) naggingly said “No measurement, No improvement,” and it really is true.

We eliminate ambiguity and ensure that all activities within the Engineering Division can be measured using numbers. That’s another major goal of the RFS Project.

ーSo you’re making sure everything can be measured numerically. It seems like quite a difficult task, so how is it going?

You’d be surprised what you can measure numerically when you put your mind to it. Things you think can’t be measured are a matter of deciding how, and once you create the criteria, you can measure the thing in relation to that criteria.

For example, to measure the lead time for resolving a certain issue, you measure time from when an issue is entered, to the pull request and review, and then deployment. The shorter the time, the higher productivity is.

Or perhaps you could say that the more tasks are accomplished in a certain time, the higher productivity is.

Other items include measuring how much money a microservice is making per PV and the cost per PV, etc.

By continuously measuring everything like this, you can always see the team’s and system’s performance, which allows you to essentially learn whether or not a feature has been improved.

Mercari is soil for raising problem-solvers

Ensuring that everything is numerically represented seems like it would help foster a similar mindset among members regarding performance reviews and other development as well, right?

I think it does. For some time, Mercari has focused on evaluating people and business through numbers, however, this probably serves to strengthen that mindset.

From a development perspective, clear metrics make it easier for engineers to make decisions. However, that also makes it much harder to cut corners in my opinion.

For example, up to now, it may have been possible to develop a feature simply because you wanted to, but that won’t be true in the future.

If the feature development proposal goes through, the engineer must explain the impact. “This is the metric for measuring whether or not the improvements we implemented are contributing, and this metric will be improved by XX%. We’ll release the feature and check the results to see how they improved.”

The feature itself doesn’t provide any value; what’s important is what metric it improves and by how much. And those metrics clarify everything going forward, as well.

I think each engineer will have to change their mindset and hone their ability to explain a feature based on numbers.

Even so, I think experiencing this process is highly advantageous for engineers.

Engineering is merely a means to solve problems, and the larger the impact a resolved problem has, the more valuable it is.

Enabling data-based proposals and thinking about results should make it possible to create greater value.

To put it another way, I think engineers should be able to become professional problem solvers.

I’ve always thought that many of the engineers at Mercari enjoy solving difficult problems, and I believe that their problem-solving thinking and skills can be further refined.

I see. The RFS Project has just started, but what kind of transformations do you see at Mercari in the future when it is completed?

Developing the technical foundation will, first of all, make it easier to create products. That’s because previous foundation bottlenecks and costs for adjusting various related areas should be significantly reduced.

I think this will allow the entire Mercari Group to commit to helping generate further user value.

A stronger foundation should help engineers build their careers as well. It’s easier for engineers to produce results at a tech company that invests in the technical foundation.

For example, many Google and Amazon engineers end up moving on to a new company after one or two years. Despite being a relatively short period of time, that happens because they’ve produced good results, have been positively evaluated, and see how moving can increase their compensation. In just one or two years of work, their performance is good enough to move on to the next step in their careers.

Our current efforts into enhancing the technical foundation will bring about the same future at Mercari, as well.

Furthermore, if Mercari is able to produce these kinds of problem-solvers one after the other, it could result in a future unicorn company, maybe creating more Japanese corporations that can stand toe-to-toe with worldwide tech companies.

The RFS Project won’t just help in-house engineers at Mercari, but also contribute to the overall tech industry in Japan. That’s my hope.

Reporting by Kanako Ishikawa
Photography by Yota Akamatsu
Editing by Kotomi Kasai (Editorial Staff)