Crossing borders means working in a different language and culture. The Japan and US versions of the Mercari marketplace app are said to be the same in some places, but different in others. For members who have transferred to Mercari US and now work on the US version of the app, what do they feel puzzles them about their work?

In this series of three Mercan articles, we will focus on a trio of members who transferred to Mercari US. In part 2 of the series, we are speaking with QA (Quality Assurance) engineer Akiko Kusuda. A member of Mercari since 2016, Kusuda originally worked on developing the US version of the Mercari app while in Japan. She said that when she transferred to Mercari US in February of 2019, she ran into a wall because of the difference in skills that the company wanted employees to have.

*All photos shown in this article were taken prior to the start of working from home due to the pandemic.

Transferring in the midst of efforts to enhance the localization of the US version of Mercari

ーSo you joined Mercari in 2016. And what was it like working at the company at that time?

Well, compared to now, one thing that stands out is that in 2016 the Japan and US versions of the app used the same source code. I’m a QA engineer; I build source code in a test environment and then validate it to ensure that we can release features without any problems. At the time, regardless of what we implemented, Mercari naturally checked the effect that single features had on both the JP and the US editions of the app.

ーNow the US version of the Mercari app is developed mainly by Mercari US. And at the same time, the office in Japan develops some of the app’s features. So ever since you joined the company, you’ve been working on the US version of the app, even while you were in Japan?

Actually, I wasn’t working on the app. I was with the CXI (Customer Experience Improvement) Team where I worked on QA for the management screens that the CS teams for Mercari US and JP use. At the time, Mercari was prioritizing work on business in the US, so we were focused on developing functions for the US version of Mercari. This is why we also had QA engineers from Mercari JP working on the features for the JP version of the Mercari app. After that, I moved to a product development team and started working on the US version of Mercari.

At first, development on the US version of Mercari was in lockstep with development on the JP version. But of course, customers in Japan and in the US want different things. If we didn’t localize the US version of Mercari, we weren’t going to make it. This is why in late March of 2017, we gave up on linking the development of the JP and US versions of Mercari, and made the decision to aim for a fully localized version.

The US version of the Mercari app

Sometime after this, I had a chance to speak with the QA manager for Mercari US. We seemed to be on the same wavelength, and I just had this feeling that they would be fun to work with. I had been working on QA for the US version of Mercari from our Japan office for over three years at that point, and I had this feeling that it was about time I moved to a different team. And that’s when I decided to move on to something new.

In the US, I was in charge of the listing screen for luxury brand-name items

ーWhen you made the move to Mercari US, what sort of work were you put in charge of?

QA work is assigned for each project. Out of all of my assignments, the one that was especially memorable was when I was in charge of the listing screen for luxury brand items.

For the US version of Mercari there’s a feature called Mercari Authenticate. It is used to authenticate whether a luxury brand item listed on Mercari is authentic or not. I was in charge of that listing screen.

In concrete terms, this feature is connected to an external service that authenticates luxury brand items to see whether they are genuine. And so, a request (containing things like the item’s brand name, pictures, price, and category) is sent to another company’s API, and then that company authenticates the item for us.

There used to be the possibility that, after a user registered their item, they could change the item information, like item’s brand name, pictures, price, and category, or else delete the listing accidentally. In addition to listing up use cases to ensure that nothing has been left out upon implementing the specifications that a PM has drafted, a big part of QA work involves examining whether the operation of the app will be affected by adding a new status to the data to implement a feature.

QA Engineer Akiko Kusuda (right) poses for a photograph with other Mercari US members who also transferred from Mercari’s operations in Japan.

ー So you look for possible outcomes from a lot of different angles.

That’s right. Of course, we can also push forward to prioritize the development schedule. However, if we don’t fine-tune things, after we’ve implemented a new feature, problems can crop up, and we end up having to fix them. As a result, the labor spent on development can snowball. This is precisely why the QA engineers check these things when people first consider implementing specifications before development even starts. We ponder the effects that certain changes could have, whether the mobile app and the webpage will behave differently, and whether the planned changes will conflict with other features.

I have continued to do QA work ever since I worked at our offices in Japan. Even after I transferred to Mercari US, I didn’t miss a beat as far as QA work is concerned. Instead, I feel like the places where I did have to play catch-up were quite the test.

The training and people skills demanded of Mercari US employees

ー What did you mean when you said the places where you had to “play catch-up?”

The development team for the US version of Mercari that works out of our offices in Japan is made up of a small, select pool of talented people, and every member works toward the same goal. But at Mercari US on this side of the pond, in addition to systemizing the development structure, the number of members on our QA Team has also increased rapidly. There were a few members among our new recruits who needed training.

Up until then, I had never really had any deep involvement with training. In addition, the difference in learning styles also tripped me up.

I’m good at understanding things by sewing together information gathered from seemingly unrelated conversations. However, depending on the person, some of our members wanted to learn from systemized documents and organized information. It took me a fair amount of time to figure out what it was that people didn’t understand and what I had to do to help them to understand. People would sit next to me while we worked on development tasks, and they would take what I told them and organize it as a document. What makes sharing information and training difficult is that it’s an ongoing trial and error process.

What’s more, when it came to my work, the skills I needed in the US were different from the ones I used when I was in Japan.

ーThe skills you used in Japan were different?

Up until I transferred to Mercari US, I was the type of worker who was evaluated positively for demonstrating strength in the accuracy of the work I produced. So as long as I was good at my own job, there was no problem. But that doesn’t wash at Mercari in the US. There were some things where I could not move forward unless I could convince the person in charge on another team of my approach. But thanks to this, I became aware of the importance of having good people skills.

I get the impression that there are a lot of people at Mercari US who have excellent people skills. For example, there’s a member at the Portland office who created a tester team for testing app features. And I’m always surprised by how smoothly he manages to get these really difficult sounding requests to pass. (laughs) But he can do this because he’s able to put himself in the place of the people he’s communicating with, and that’s how he gets people to understand his position. At the moment, I’m working on strengthening my skills in this area.

“I just want to see Mercari make it in the US”

ーJust before, you said that you decided to transfer to Mercari US because you thought that it was about time you moved to a different team. Surely it crossed your mind that changing companies was also an option. What was your reason for choosing to stay on at Mercari?

I just want to see Mercari succeed in the US. The reason I stayed is that the entire Mercari Group keeps affirming that we are going to succeed in the US. I wouldn’t feel satisfied to come this far and not see us make it! That’s why I continue to work on creating a product that will be reliable for users of the US version of Mercari and that will steadily raise our reputation. I think that building this up will be our shortcut to success.

ーAmid all of this, what are you personally working on?

In the US, the standard is to automate QA work. We first have to follow that standard at Mercari US. …And with that said, we have to accept that sure, some QA work will be taken from us by machines, but since we won’t be focusing on those tasks anymore, the engineers will be able to focus on manual testing.

If we can automate the checking of basic features that thus far we have covered with regression testing (testing operations that check the scope of impact of new features), we will be able to dedicate more human resources into employing strategies that have an impact on our business by using sophisticated features, much the listing feature for luxury brand items. As we implement this style of working, I would like to build a structure that will allow us to invest our labor costs in the areas that we really should be focusing on.

Check back here for the third volume of this series, when we hear from Mercari US Backend engineer Naoki Shimizu (@Deme).