Merpay Advent Calendar 2019 の6日目は、QAエンジニアチームの @miisan がお送りします。
メルペイは2019年2月にサービスを開始しましたが、これまでメルペイの品質保証（= Quality Assurance. 以下、QA）の話を公に発信したことはほとんどなく秘密結社のように今日まできてしまいました。
今回はそんなQAチームの体制や日頃どんなことを考えながら働いているのか、ご紹介させていただきます。
・メルペイQAチームの体制
メルペイでは、上の図のような体制で構成されており、QAチームは横断的にプロジェクトに関わっています。
ただし、基本的にはスクラムを組みリリースサイクルをまわしているので、ほとんどの場合は特定のチームにコミットし仕様検討からリリース後のチェックまで、開発全体に関わっていることがほとんどです。
また、メルペイQAは継続的に行われる開発サイクルに寄り添い並走することが多く、組織としては横断的なポジションにいますが、個々人レベルでみると特定のプロジェクトに所属して活動していると言えます。
ですが、特定の人が半永続的に特定プロジェクトを担当していると、属人化や知識の偏りが起きてしまうため、これを課題感ととらえ、QAチーム内にチーム体制を導入し、変化に強い状態にしようとしているところです。オーナーシップやチーム力を高めることで、個々及びチームで考え行動できる組織にすることを目指している最中です。
・私の日常
みなさんご存知の通りキャッシュレス決済の世界は日々激動で、昨日までの話が今日変わっていることは少なくありません。
日々変わりゆくビジネスユニットに対して、当然QAエンジニアとしても柔軟で素早い決断を求められます。QAエンジニアとしては、ビジネス速度を落とさないスピード感とどれだけ激動の中心にいても守らなければいけない「品質」について考え、実践することで品質保証を担っています。
いちQAエンジニアとしてプロダクトにどのようにコミットしているのか、一部ですがお話ししたいと思います。完全に自論です。
1.当たり前品質 と 魅力的品質
よくQAはこの2つの品質について考え、品質保証することが定義されます。
当然、私達が扱うサービスは決済サービスであり、整合性や信頼性を保証する必要があります。これは言わずもがな当たり前です。ですが、こればかりを追求するとサービスとしての魅了が落ちる可能性があります。特に、まだまだ現金主義の日本においてキャッシュレスを推進するには、お客様のことを考えたUIや利便性、それも凌駕するような魅力がサービスに必須だと考えています。
せっかくプロダクト側が考えた逸材の企画も、バグだらけでは最大限の結果を出せないし、バグはなくても、その企画に魅力が少なければそれはそれで最大限の結果を出せない。そう考えると、プロダクトとエンジニアチームはより密に相互の信頼関係を構築している状態が望ましいです。
私個人としてはどんな世界観を描いているのか、その認識をまずは合わせることを意識した上で、必要ならば企画段階からコミットし、この段階で防げる仕様バグはないか確認しようとしています。
また、Be Safeの観点でいうと、どこまでのことを事前に想定できているかということが重要で、たとえば現実的には1%未満の可能性だとしても、わずかな可能性を考慮し小さな懸念についてもひろい上げ、より安全な方へチームを導くこともQAエンジニアとして大切なことだと考えています。
2.マニュアル と 自動化
メルペイではマイクロサービスアーキテクチャを採用しており、見えない部分でとても複雑にサービスが構成されています。
このあたりについては過去Techブログなどをさかのぼっていただくと、詳細を理解いただけると思います。
よく自動化の文脈で、マニュアルテストと自動テストのメリットデメリットがぶつかりあうことがあります。ただ、メルペイにおいてはリリース前からAPIの自動テストによって品質を担保したいという方針があり、私としてはメルペイのサービスにおいては有効に働いたと感じています。
私は2018年7月頃からiD決済の領域を担当しており、リリース前からBackendの大部分を自動テストを用いて検証してきました。
※iD決済は株式会社NTTドコモが提供している非接触型決済サービス「iD」に対応しており、全国の「iD」加盟店で利用が可能となってる決済手段です。
正直リリース前の開発期間はとても短く、さらにいくつもの開発物が同時に進んでいました。日々ものすごい勢いで変更がなされていくサービスに対して、手動テストだけで品質保証することがほぼ不可能だったと言える状況でした。
今振り返ると、iD決済を2019年2月に大きな問題が起きずにリリースできたことは、自動テストの効果を私は少なからず感じています。
特にiD決済はサービスの仕様上、メルペイ単体で動作保証しなければいけない範囲と、他パートナー様を交えて動作保証しなければいけない範囲がありました。リリース前の半年間はほぼ毎日接続試験を行っていました。この時の難しかったポイントは、日々進む開発物のQAと同時並行で行われる接続試験の実施の両立でした。
接続試験がはじまる前に、メルペイ内の動作保証を終わらせなければいけないですし、当然新しい開発は進んでおり、そちらも対応する必要があります。当時QAメンバーとしては私一人でそれらの対応をしていました。
外部パートナー様も巻き込むプロジェクトだったので、いつまでに何がどのレベルでできていなければいけないのかについては、PMやエンジニアとコミュニケーションを取って優先順位を明確にしながら進めました。
接続試験を実施する前には、新規開発物の影響によって接続試験を実施しなければいけない領域に影響を与えていないかについて確認するために、自動テストを用いてフォローするようにしていました。
また保守フェーズにはいった現在でも、安定して稼働している自動テストの結果を毎日確認するだけで問題の有無を確認できるので、新規開発など今自分が本当に時間をかけるべきことに時間がさける状態をリリース前から作れていたことで、今その恩恵を受けています。
保守フェーズといっても日々サービス改善は当然行っており、このリリースサイクルのスピードを落とさずに安定的に運用できている要因としても自動テストの効果はあげられます。自動テストは、すぐに確実で、継続的なテストが可能という意味でも価値が高いと感じます。
メルペイQAには、SETと呼ばれる自動化を専門に扱う部門はないため自動テストの作成・運用もQAメンバーが担ってきました。ですが最近は、QAだけでは実現できないシナリオテストケースも出てきており、Backendエンジニアの協力のもと、より自動テストに力を入れていきたいと考えているフェーズです。
サービスの性質上、さらに開発期間が短い中で品質担保するためには、テスト自動化することは重要です。ただまだまだ改善の余地はあるはずなので、先入観を持たず、All For One に取り組んでいこうとしています。
3.仕様 と 違和感
自分の担当した機能について想定したことが実現できていることは当然として、私はその周辺含めリスクや懸念がないか先回りしてパトロールすることを意識しています。
プロダクトはチームとして独立している中、QAチームは横断的にプロダクトを見ている唯一のエンジニアメンバーです。ですので俯瞰的に物事を捉え、あるチームで得た知見を別のチームへ還元できるように心がけています。
例えば、AチームとBチームで別の認識をもってプロジェクトが走り出している場合、アラートをあげるだけで認識の齟齬を早い段階で防ぐことも可能です。
正直私は、QAエンジニアとしてのキャリアも短く、QAとしてまだまだ足りないスキルがあると感じるのですが、それでも今の自分にできることってなんだろうと考えた時、「これっておかしいんじゃない？」という不自然感や違和感を、先に掴むことならできるんじゃないかと思っています。ですが、違和感に気づけるということは、”いつも通り”を知っている必要があります。いつも通り、つまり仕様が正しく定義されている必要があるので、PMには細かすぎるくらいに仕様書の定義を求めたり、細部まで認識を合わせるようにしています。
また私はサービスが2月にリリースされたとき、お客様からのお問い合わせや問題が報告された事象を昼夜問わず静かに見守っていました。
最近わかってきたことは、テストしている中で「おや？」ということはたいてい気のせいではなく、お客様もいずれ「おや？」と思う可能性があるということです。ファーストユーザとしてその違和感に気づき、チームに事前に共有することで、なめらかな体験をお客様に届けられるように努めることは今後も意識していきたいと考えています。
・メルペイQAの目指す未来
メルペイQAは「金融系テックカンパニーのQAになること」をミッションにしています。
また個人レベルでは、マネージメント、上流から下流工程及びテスト設計、実施、レビュー、テスト自動化の全てができるQAエンジニア、つまりフルスタックQAになることを方向性として定めています。
何でも屋のように聞こえるかもしれませんが、たった一つの専門性を深め極めること以上に、マルチにあらゆることができるスキルのほうがこの変わりゆくIT業界において継続的に価値を出せる人、そしてチームになれると私は感じています。
QAエンジニアというのは「品質保証をリードし、良いサービスをお客様に届けるためにあらゆることをする人」だと思うので、より良いサービスを提供するために言葉通りできることは役割をこえてやっていきたいと考えています。ですので、テストすることはあくまでそのうちのほんの一部の話です。
同時に、世の中によりよいサービスを届けることに加えて、市場に正しく私達の思いを届ける責任がQAにはあると考えています。
QAは単独では大きな価値を生み出すことは難しく、あげていったらきりはありませんが様々なステークホルダーの結晶を受け取り、その想いをそのままの形でお客様に届けることはQAの仕事の一つです。だからこそチームで、みんなでこれからも良いサービスを創りたいと願っています。
お客様や解くべき社会の課題に向きあい、そもそも私達は何を届けたいのか、それを見失わないようにQAエンジニアは時に冷静に俯瞰的に振る舞い、これからも最高の体験をお客様に届けられればいいなと思っています。
PS:メルペイではミッション・バリューに共感できるQAエンジニアを募集しています。一緒に働ける仲間をお待ちしております。ぜひここまでの話やメルペイの取り組みに興味を持った方のご連絡をお待ちしています！
明日のMerpay Advent Calendar 執筆担当は、 Backendエンジニアの @adlerさんです。引き続きお楽しみください。
