エンジニアと立ち話。Vol.30 @ matsu（メルペイQAエンジニア）ちょっとお話いいですか？

メルカリで働くソフトウェアエンジニアにちょこっとお話を聞いていく本シリーズ。第30回ではメルペイQAエンジニア@matsuにちょこっと話を聞きました。

一般的なQAエンジニアの仕事とは、ソフトウェアの品質保障を目的とした品質計画の立案や動作テスト、管理を行うことです。

メルペイのQuality Assurance（以下、QA）チームのミッションは、お客さまに選ばれる品質で決済サービスを提供すること。お客さまのお金を扱う決済サービスを新たにリリースするために、品質は必ず担保しないといけません。では、2019年2月の決済サービス「メルペイ」リリースの裏で、QAチームとしてどんな苦労や挑戦があったのでしょうか？　本連載でお馴染み、メルペイVP of Engineeringの@hidekが聞いてきました。

バグ発見から、原因を突き止めるまでが気持ち良い。それがQA

@hidek：いやあ、@matsuさんをインタビューするの、ウケる（笑）。こういうの面倒臭がるタイプだけど、メルペイリリースの立役者である、@matsuさんやQAチームの頑張りはちゃんと伝えたいんですよね！　ということで、立ち話をさせていただきますよ。まず、@matsuさんの入社時期と担当してきたことを教えてください。

@matsu：2017年1月にメルカリに入社して、US版メルカリのQAチームに半年、その後はJP版メルカリのCSツールなどのQAを担当していました。

@hidek：そもそも、なぜQAに興味があったんですか？

@matsu：もともとゲームが好きで、それに携わる仕事がしたかったんです。そのため、前職の第三者検証会社では、ソーシャルゲームのQAをやっていました。

@hidek：メルカリもメルペイも、ゲームとは違いますよね？

@matsu：そうですね。QAの仕事をやっていくうちに、自分の性格に合っていると思うようになったんです。

@hidek：（話を遮り）そうそう、僕自身もQAに向いているタイプだと思っているんです。こう見えて、僕も細かいディテールから入るのが好きなんですよね。テスト駆動型開発（最初にテストを書き、そのテストが動作する必要最低限な実装をとりあえず行った後、コードを洗練させていく開発手法）など、重箱の隅をつつくような作業というか、見る範囲が広くて深いのが自分に合っていて。バグを見つけると「おっ」と思うし、それがQAエンジニアとしていいのかどうかと言うとわかりませんが、作業としては好きなんですよ。

@hidek（メルペイVP of Engineering）

@matsu：えっ、意外ですね。そうは思いませんけどね（笑）。でも、僕もバグを見つけて、その原因までたどり着けるとすごく気持ちいいです。コードを書いた人よりも先に見つけられると、さらに気持ちいい。性格が悪いのかもしれませんが（笑）。

@hidek：（笑）。「問題の原因を見つけて解決する」というのは、完全にエンジニアリングの根源だと思いますよ。ちなみに、メルペイに異動を決めた理由は何だったのでしょうか？

@matsu：2018年2月、社内公募に手を挙げ、メルペイに異動しました。新しいサービスの立ち上げが自分の経験になりそうだと思って、挑戦してみることにしたんです。

メルペイを予定通りリリースできたのは、QAチームが「出そう」と言ってくれたから

@hidek：@matsuさんがメルペイに異動し、サービスがリリースされるまでは開発期間が長くありました。QAチームが本領発揮するタイミングは、やはりサービスのリリース前になると思うのですが、それまでの間はどうでしたか？

@matsu：リリースまでの1年間は、本当に準備期間でしたね。当時メルカリグループとしても進めていたマイクロサービスの検証経験があるメンバーも、フィンテックの経験があるメンバーもいませんでした。すべてが手探りで、リリースに向けての準備が山積みだったんです。

@matsu（メルペイQAエンジニア）

@hidek：そして、メルペイのリリース日が決まり、QAとしていよいよ本領発揮するわけですが、ぶっちゃけ、どうでしたか？　@matsuさんは全体進捗管理マネージャーとしての役割も担っていたので、大変だったと思うんですけれど。

@matsu：めっちゃくちゃ大変でしたよ（笑）。でも、正直やれると思っていました。QAチームのなかでもメルカリグループに長く在籍しているメンバーの一人だったので、全体感がわかることもあり、不安はなかったですね。リリースするためにできることは、全部やりたいと思っていました。

@hidek：@matsuさんが頑張ってくれたおかけで、プロジェクトを進めることができたと思ってますよ。いろいろあったと思いますが、特に何が大変でしたか？

@matsu：何が大変かというと、検証できないところがあることですね。マイクロサービスはつなぎ合わせてみないとわからないところがありますし、何よりサービスとしても大きなリリースだったので、まあ「バグる」わけです。とは言え、段階的なリリースなので「こっちのリリースを待つと、テスト期間はこれしかない。そうなるとリリース無理じゃん」となって。

@hidek：テスト環境に正解はないし、解決しなきゃいけない問題も多いし。金融サービスだから、ちょっと出して引っ込めるようなカナリアリリース（新機能を一部ユーザーのみが利用できるようにリリースして、問題がなければ全体に向けていくデプロイ手法）もカジュアルにできない。さらに、品質として100％の完成度で出さなければならない状況だったので、本当に大変だったと思いますよ……。

@matsu：最初のリリースまでは、やれることをやれたと思っています。でも、力尽きましたね（笑）。5月まで忙しくて。

@hidek：今だから話せるいい話がありまして。決済サービスはセンシティブなので、メルペイに関してもリリース日については社内で何度も話し合いを重ねてきました。でも、改めて振り返ると、@matsuさんから「出しましょう」と言ってもらえたことで、リリースへの勢いがついたように感じています。「ここで出そう」とQAチームが言い、そして実際にリリースできたのは、嬉しかったですね。

@matsu：僕も嬉しかったです。

@hidek：否定しているわけではありませんが、QAエンジニアには、品質100％じゃないと出せないという人が多い。そのため、なかにはリリースに対して慎重になり、遅らせる判断する人もいたりします。しかし、@matsuさんは、前向きに出そうとしてくれました。褒めてますよ（笑）。

@matsu：とにかく早く出したいというのがあったんで。いくら頑張っても、バグがゼロにはならないです。落とすところは落とし、天秤にもかける判断は必要でした。

@hidek：@matsuさんは歯に衣着せぬ言い方しますよね。「これ無理っすよ」とか（笑）。

メルペイならではのQAの難しさとは

@hidek：メルペイだからこそのQAの難しさって、他にありますか？

@matsu：決済サービスなので、失敗ができないですよね。正直、Webサービスは失敗してもリカバリーできるけど、「お金」を扱うサービスは絶対に失敗できない。あとは、銀行や加盟店など、APIの接続接点が多いという難しさもあります。お客さまからすると、全部含めて「メルペイ」の体験なので、その品質はいいものでないといけません。

@hidek：QAチームには、協力会社の方もいらっしゃいます。協力会社と言うと、消極的な意見が出ることもあります。でも、サービスには繁忙期とそうでない時期があり、協力会社の方と組むことで、柔軟に動けるようになります。一方でコミュニケーションの問題などがあるかもしれませんが、実際どうでした？

@matsu：基本的に、協力会社の方がいるのは良いと思っていますね。自分たちができることに時間を割くべきですし、リグレッションテストなど、第三者視点で見てもらうと、見つからなかったバグを発見できることもあるので助かっています。テストなどの仕組みづくりはメンバーでしっかりつくり、スケールするところは外部の方々と進めていく。QAは自動化できるところもありますが、結局のところ人の手は必要ですからね。

@hidek：話を変えて、今のQAチームの雰囲気や体制はどうですか？

@matsu：今は2〜3人のチームで2〜3プロジェクトを持つようにしています。タスクを交換できるようにし、同じチームのなかでリソース調整可能にしているんです。

@hidek：なるほど、理想的ですね。最後に、今後やっていきたいことはありますか？

@matsu：QAチームとしても個人としても、もっと自動テストに強くなっていきたいですね。あとは、マイクロサービスに最適なテストアーキテクチャなんかを考えていけたらいいなと思います。

@hidek：いいですね。今後メルペイの開発組織としても、QAメンバーにはマイクロサービスの理念やアーキテクチャーにも強くなってほしいと思っています。マイクロサービスって、銀の弾丸のように聞こえるけど、やっていることはけっこう泥臭いんですよね。

@matsu：みんなマイクロサービスをやっていることは発信していますが、テストをどうしているのかなど、ノウハウがあまり外に出ていないなと思っていて。僕たちの知見をどんどん外にフィードバックしていきたいですね。QAの何が難しいって、正解がないことなので。

@hidek：それは開発も同じです。だから組み合わせなんですよね。引き出しの数で、テストエンジニアのキャリアとして豊かになります。QAチームをエンジニアリングの組織下にしているのは、QAもエンジニアリングだという考えがあるからです。SREチームもQAチームもみんなエンジニアで、いろんな引き出しを持っていることが重要。個人的にも、仕事としてQAって面白いと思っていますしね。