Development Platforms and Platformers: On Rising to the Global Standard Ken Wakasa, Mercari CTO

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. For this first article, we interviewed Mercari CTO Ken Wakasa (@kwakasa), the man who coined the name “RFS.”

＊The mask is removed only when taking pictures.

A Career in Engineer-Driven Companies

ーYour first job was at Fujitsu Laboratories, right? Why did you want to work there?

To be honest with you, I hadn’t given the choice of my first job much thought. (laughs) It’s just that I majored in informatics engineering in university, and one of my research lab colleagues got a job at Fujitsu after graduation. It was a really interesting experience from a technical perspective, developing frameworks to run on supercomputers and the like, but our customers weren’t regular people; they were university labs and financial institutions. I thought that I wanted to work on a product that was more closely related to the lives of regular, everyday people, so I moved to Sun Microsystems, with its head office located in Silicon Valley.

Ken Wakasa (@kwakasa)

ーWhat did you do at Sun Microsystems?

Sun Microsystems is the company that developed Java, so I was involved with development of the Java Runtime Environment (Java Virtual Machine and Java Core Runtime). At the time, Japan was still home to the world’s most state-of-the-art mobile phones, so my thinking was that I would be able to work on even more dynamic content for cellular devices. Sun Microsystems is the kind of engineer-driven company that epitomizes the Silicon Valley model, so it was very attractive to me as a company. I had plenty of opportunities to visit Silicon Valley on business trips, and my time there really convinced me that software engineers are going to change the world.

ーAnd after Sun Microsystems, you moved to Sony, correct?

The U.S. dotcom bubble burst in 2001, with many companies starting to downsize. This didn’t really extend to Sun Microsystems’ Japan operations, but thinking about my career, I decided to change jobs so I could try something new. Probably the biggest reason I chose Sony is that I knew several people working at Sony already, and they said Sony would offer me a ton of interesting projects to work on. The Playstation 2 was booming at the time, and demand for software engineers at Sony was on the rise.

ーAnything from that time that really stuck with you?

Sony has this document they call The Founding Prospectus, and it says that the company exists “to establish an ideal factory that stresses a spirit of freedom and open-mindedness, and where engineers with sincere motivation can exercise their technological skills to the highest level.” I think of it as saying engineers should make interesting products, sell those around the world, and thereby change the world we live in. This was far and above the most engineer-driven company I had worked for at that point. I ended up staying there for about four years. The managers and engineers there are all full of vim and vigor, and the culture really embodies the “leave ‘em speechless” approach extolled by Sony’s founding members.

Two Big Lessons from Developing Global Services

ーWhy did you ultimately move to Google?

I was invited by a former coworker from Sun Microsystems. It was that time when Google Maps, Gmail, and other Google services aside from the search engine were starting to see widespread use. I decided to move because it seemed like somewhere I could really contribute, utilizing my career up to that point. My experience there still serves me well today. During my time there, I learned two big lessons. The first was ’not to take the easy way out with localization’.

ーWhat do you mean?

I was in charge of developing the route feature for Google Maps at the time. Japan’s cities are extremely complex when it comes to traffic information, since there are so many pedestrian walkways, pedestrian-use roads, and crosswalks. The geographical data for Japan that Google Maps was using at the time included detailed road network information, including these pedestrian roads. I initially thought that it would be more efficient to localize the logic to match this particular characteristic of Japan’s data. But the ultimate conclusion was that we couldn’t scale up the service without creating a single, global database. We split the duties between several engineers and made a model that reflected these new requirements.

ーThat seems like it would take a ton of time.

It took a little less than two years. (laughs) But it’s thanks to our hard work that now, every user enjoys the same Google Maps experience, regardless of where they are in the world. If we had made a localized version for each country, there’s no way the service would have been able to grow to what it is today. Google did the same thing with its search engine, as well. When they want to add some kind of feature, they try to make the change to the core system components. Normally, you wouldn’t want to mess with those core components, right?

ーRight. But fixing those core components will reduce costs and risks in the long term, more than short-sightedly relying on some cheap-to-add features.

Precisely. There was one other lesson I learned, as well. That’s to avoid giving preferential treatment to other services in the same ecosystem. I was actually thinking about changing jobs once I closed the book on my time with Google Maps. However, the company I was thinking about moving to was acquired and merged into Google. I no longer had any reason to change jobs at that point. (laughs)

Eventually, I moved to the Android dev team, where I went on to develop the framework and core applications for Android OS. Android was originally a different company, so its decision-making process was separate from Google. If other teams at Google had asked them to add a special API for specific services, they definitely would have refused. They would do it if the service was going to be public, but not if it was just for use at Google.

ーTalk about getting stuff done.

But I came to feel that was truly what was needed to make Android a functional OS. In truth, Android had about a million active users at the time I joined them, but this number would grow to over a billion in the following five years or so. I think a big reason that they were able to grow to that size is because they held fast to that neutral position.

You Need a Solid Foundation to Create a Place for Users

ーAfter that, you worked at Apple and LINE, and then you finally joined Mercari. What lessons from that time have informed your work today?

At LINE, I learned what it means to users when a service becomes more than a service—that is, when a service becomes an indispensable facet of society, the kind that we might call an “ecosystem” or “platform.” If I had to put it in my own words, I guess I would call it “creating a space for users.” After LINE, it was that idea of creating a space for users that resonated with me and led me to join Mercari.

ーMercari’s mission is to create value in a global marketplace where anyone can buy & sell. Is that what resonated with you?

Essentially, that mission means creating a place for companies and individuals outside of Mercari. For us to achieve that mission, we have to heed the lessons of those who have created these kinds of ecosystems and platforms before us, walking the same path though it may differ significantly. Building a strong foundation is part of that. Without a solid foundation, we can’t create that kind of space for everyone.

ーAnd that helps us achieve the goals of this “RFS” project. But why does Mercari need to pursue RFS now exactly?

The biggest reason is that we got the green light from the upper management. Shintaro (Shintaro Yamada, Mercari CEO) has actually been telling us that we need to increase development speed for the last year or so. He had pointed out that our overemphasizing quality was causing delivery and release timing to lag behind. We kind of knew this was happening, but there were other more pressing issues with the development infrastructure that prevented us from ensuring a consistent development speed.

ーSpecifically, what kind of problems with the infrastructure were you facing?

Software runs through a combination of components working in unison that all impact each other in different ways. The fact was that Mercari’s infrastructure was facing bloat from the sheer number of modules. Furthermore, it was impossible to tell at a glance how certain components were being used or their dependencies. This meant that we couldn’t mess with these modules without first checking the entirety of the infrastructure.

ーThat took a lot of time and led to development delays?

Yes. This is why we advocated for greater investment in infrastructure improvement. We finally received approval for that in May 2021. I had also just been appointed Mercari CTO at the time, giving me the chance to spearhead this project.

Mercari as Big Tech

ーYou made a commitment to RFS as soon as you were appointed CTO, right? What is your role in RFS specifically?

I think my biggest role is to explain the necessity of RFS to people both within and outside the company. What is the issue? What are we trying to solve? The more people understand that, the easier it will be for engineers to act.

I think just explaining the project as creating new development infrastructure makes it more difficult to understand. If this was about adding a new feature, it would be easy enough to just say, “We’ve added this new feature,” and be done with it. But with something like this that is happening behind the scenes so to speak, where others can’t see, I expect that some people would fail to grasp a clear idea of what we’re doing.

ーKind of like fixing the plumbing or a gas line.

Indeed. Mercari has thankfully grown into a service with over 20 million monthly active users. However, it goes without saying that in the beginning, we never envisioned reaching this size. The system we originally designed is now reaching its limit. That’s why we need to get this infrastructure in place now. This is the path we must take if our service is to continue to grow.

That being said, it’s incredibly difficult for us to make changes of this size while keeping the service available to users. This is the same example that RFS project lead Minoru Tsuka (@mtsuka) gave, but it’s a little like trying to replace a jet engine while the plane is still in flight.

ーSounds difficult…

You have to remember that global tech companies, what people call “big tech,” do this kind of intricate, tasking work all the time. If we can do this, we can be considered on the same level as these “big tech” giants. That’s why we make sure to recognize our engineers working on this difficult behind-the-scenes work, and many of our engineers do take great pride in the work they’re doing. That’s the kind of culture we want to continue to build at Mercari.

ーSynchronized swimmers look so graceful on the water’s surface, but you know they’re kicking their legs like mad underwater.

I think that’s the phase Mercari is in as a company. While things look great in many respects, there is plenty of important work to be done behind the scenes. If we cannot finish that work now, then we will never achieve our lofty mission. This project is a prerequisite.

ーMercari is thought of as a complete service, but there’s actually a lot of challenges waiting to be addressed, I guess.

Mercari has become a huge service, and I can’t say that we have everything we need to continue that growth. There are still hidden possibilities for growth and a mountain of issues to solve if we are to achieve it. I think the RFS project that we’re working on represents a turning point from a technical perspective, as Mercari finally sheds its startup identity.

The RFS project is also the kind of challenging opportunity that only comes around once in a company’s lifespan. Once a company reaches a certain size, members are only entrusted with a small portion of the massive project. But Mercari today is still the size where you can be involved while keeping the entirety of the project in view. This is an extremely rare opportunity which, without a doubt, will prove to be a huge chance for any engineer to grow. If you think you have what it takes, then I invite you to grab your climbing gear and join us in scaling these perilous heights.

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!