Solving business problems from a system development perspective
Currently I work in 2 teams. My primary duties are with the Business Planning Department in the Operations Division, where I am responsible for planning merchant management and screening operations. Alternately, I work in the Development Team in the Enterprise Engineering Department (EE), where I piece together the system development requirements together with the engineers for the development to happen.Planning & development. How do the 2 roles relate?
Take the merchant related operations for example; it’s necessary to establish screening standards to ensure smooth merchant screening. To do this, it’s important to work closely with the sales team before the actual sales activities begin, to fix a standard and organize the information necessary for the screening. This is something that falls under the ‘planning’ tasks I work on, as part of the Operations Division.
When there’s something launched like the government’s cashless rewards program, the number of applications to become a PayPay merchant surges, which means a significant increase in the screening volume. The processing of merchant applications in particular can be as high as a couple thousand reviews per day, which is an enormous amount of work if done manually. That’s why we decided to introduce a web crawling system* in advance. This decision bore fruit, and it now only takes 3 to 4 people to do the reviews, thanks to the automated checks performed using the information captured by the system. The related system development an EE job, completed in a very short period of time.
Normally, it is difficult to develop everything in advance, but luckily enough, I was there to act as a bridge between the 2 teams when they had to decide on what should be developed to prevent the suspension of the service and what should be done manually for the time being, which I guess is the value that I’m able to add by being in a position that allows me to quickly sort out the issues from both business and system development perspectives. (*) A system that automatically performs Internet searches.How did you acquire the skills to manage projects from two different perspectives?
I was seconded from SoftBank to PayPay last year, but before that I was involved in the launch of SoftBank’s BPO center in Dalian, China, as well as BPO centers in Weihai and Suzhou in the Shandong Province. After a while, I became the only Japanese person looking after BPO, with the rest of the staff being all local Chinese members. The experience from back then of managing a center with hundreds of employees to ensure smooth operations and in having to make the right decisions at the right time helps me what I do now. The speed of business at PayPay is overwhelmingly fast though, so working out what the best solution is while plummeting ahead is new. It’s a bit hard to pin down in words, but doing just that – working out the best solution when in top gear, not just by myself but coming up with all sorts of “ideas” together with the people around me to identify what’s best, is something that I find very appealing.So, you find PayPay’s ‘speed’ appealing – can you tell us a little more about that?
The speed of business in SoftBank is pretty fast compared to an average business, but PayPay is even faster. Given PayPay’s velocity, the business details are basically never fixed months in advance. That means, the key to success is how quickly we can address decisions made with little time left.
Normally, the schedule of a given project is drawn-up after it receives approval and the app development plan is devised. Based on that, the business side decides on the rules and scheme, after which, the operations & sales teams start their preparations. The EE team is responsible for non-product related systems, and we first sync up with the business side when any fixes or new development work becomes necessary, but I can say that at this point, not a lot of things are fixed. It’s not as though there’s a path already paved ahead, so there’s some guess work involved, like “hmm… I guess this is the extent to which I should be prepared for now”, while of course, everything is progressing at breakneck speed.
Back when I was in Dalian, the planning phase never took so much time; conversely, I had to put in a lot of hard work to establish operational structures and work long hours. I would say that what I do now is more complex, but you know what? I enjoy it. Decisions are made quickly. The business moves ahead so quickly. But since everyone is willing to communicate as much as possible to drive things forward, the fast pace feels more exciting than distressing. Forming an image of the future to come – then actually chiseling it out from amongst all the uncertainties that remain. That’s where I get my thrills.Isn’t it difficult to stay prepared when things are so fast?
It is difficult – you need to stay alert, always anticipating what will come next, together with ensuring just enough resources for when it does come, otherwise things won’t be completed on time, causing trouble for merchants and the sales team. That’s why it’s necessary to keep aligned with the sales team to know exactly when and how much things are required. Not breaking stride and ensuring the service does not halt is the bare minimum requirement.A little more about your work in the EE team – are you also involved in the actual system development work?
I actually can’t write any code (laughs). I’m more of a project manager or business analyst, rather than an engineer. The development work won’t go ahead without ensuring everyone – the sales team and other teams – are on the same page along the way including the requirements, which is what I tend-to.Is there anything you put an effort into in your relationship with the engineers, given you are a member of the development team who does not do any development work?
Since there are many team members who have much more technical knowledge than I do, I keep focused on sorting out the core assumptions for the development, what structure is needed, what the schedule should be – the things that need to be clarified before the development begins. Whether or not I’m doing a sufficient job of it, I’m not sure, but I also try to provide short term goals in addition to the end-goals. Things will not succeed without that, so I make a conscious effort to provide clarity in particular when it’s related to development work.
As with any job, there are times when issues occur between team members, not to mention other problems that are difficult to handle. When this happens, I try to debunk the problem from a different perspective than that of the engineer, such as whether a different approach can be taken or whether it is really necessary or not, to try to solve the problem.
While “not working in the office” is becoming the norm, going into the office on occasion can help to strike a good balance
It was quite a challenge at first.
For example, there are many development related things that can be solved simply by asking the person sitting next to you. It isn’t as easy to do that now. No matter how much we communicate through the morning sync-ups we do online, there are still things that are not easily resolved or can’t be done the way we used to.
As a rule, I don’t go into the office, but where possible, I do want to have weekly or monthly team meeting in the office so that we can all get together to solve problems and review schedules. Sometimes there are team members who have never had the chance to meet each other in person, and I believe that actually meeting in person does help with better communication later on.
In that way, compared to when working in the office was the norm, going into the office now means having a specific purpose to do so, like solving all the problems that have kept piling up or reviewing various schedules as a team and making a decision then and there. Going into the office in this way has become more purposeful, which is one thing that we’ve gained as a result of the COVID-19 crisis. There are many things that require more than one hand. That’s why having a forward-looking team ready to actively support each other is needed.
PayPay is a fast-paced business, and there are many things I can’t get done by myself. There’s always the support of my team, other teams, and third party partners involved, and of course I provide active support wherever I can too. That’s the sort of relationship I want to maintain, which is the same as acting as the bridge between the 2 teams I belong to.Lastly, what do you think is the best thing about PayPay?
Everyone at PayPay always is willing to go the extra mile – they work hard, with a positive attitude. The environment is very open and flat, which makes working here fun. I think I enjoy working at PayPay because I identify with that sort of a culture.Thank you Kazuaki, it was a delight to hear from you!