Merpay Tech Fest 2021は、事業との関わりから技術への興味を深め、プロダクトやサービスを支えるエンジニアリングを知れるお祭りで、2021年7月26日（月）からの5日間、開催しました。セッションでは、事業を支える組織・技術・課題などへの試行錯誤やアプローチを紹介していきました。
この記事は、「QAエンジニアの立場から、お客さまに選ばれるサービスを継続的に届けるために必要なこと」の書き起こしです。
櫻井みづき氏：それでは発表を始めさせていただきたいと思います。よろしくお願いします。皆さん、はじめまして。メルペイでQAエンジニアをしています櫻井みづきと申します。本日はよろしくお願いいたします。本日は、QAエンジニアの立場から、お客さまに選ばれるサービスを継続的に届けるために必要なことと題して、お話しさせていただきたいと思います。早速ですが、本日の流れについて紹介いたします。
本日のアジェンダです。簡単に自己紹介をさせていただき、本日お伝えしたいメッセージを紹介させていただきます。そのうえで、QAエンジニアから見たメルペイについて、これまでの歴史を振り返りながらお話しします。最後に、メルペイの考える品質保証についてお話しして、お客さまに選ばれるサービスを継続的に届けるために必要なことを私なりにひもといていきたいと思います。
自己紹介
まず、改めて自己紹介になります。メルペイでQAエンジニアをしております櫻井みづきです。メルペイには2018年7月からQAエンジニアとして参画し、コアローンチ前からサービス立ち上げに携わってきました。ちょうど丸3年の月日がたちました。おもに決済まわりの領域を担当し、iD決済やオンライン決済などの新規機能のリリースにも関わっていて、信用領域を担う機能も担当しています。サービスの品質向上だけでなく、プロセスの改善や組織づくりなど幅広くいろんなことに挑戦させていただいています。個人的にはカメラとか旅行が趣味で、きれいなものがすごく好きです。
本日のメッセージ
ということで、私の自己紹介はここまでにさせていただき、本日お伝えしたいメッセージに移ります。
本日お伝えしたいメッセージになります。「早く行きたければ、ひとりで行け。遠くまで行きたければ、みんなで行け」というメッセージです。ご存知の方もいらっしゃると思いますが、これはアフリカのことわざです。フェーズや規模が変わっていったメルペイでの3年間を通して、私が感じたことをこのメッセージを添えて本日は皆さんにお伝えしていきたいと思います。
QAエンジニアから見たメルペイ
まず、QAエンジニアの視点から見たメルペイについてお話しします。
メルペイのフェーズ変遷についてです。この3年間で、市場変化や、事業、組織フェーズの変化に伴って、サービス提供のスピード感や優先度などが目まぐるしく変わっていきました。サービスローンチ以前は、まずは「サービスをお客さまに届けること」であったり、「ゼロから新しい価値を生み出すこと」が求められていました。目の前の問題解決や決断などを早く行うことが優先され、物事を一気に推し進めていくというようなスピード感がありました。ただ、サービスリリース以降は、「サービスをお客さまに届けること」だけではなく、「継続的に価値を届け続けること」が求められるようになりました。機能をリリースすることだけでなく、QCDを意識した、より早くより良い価値を提供することが重要とされるようにメルペイはフェーズと共に変化していきました。同様にプロジェクトが進むと、より大きな目標を実現することを重視するフェーズに移行し、多くの人を巻き込んでいくことが求められるようになりました。実際にQAとしての関わり方もリリース前後で変わっていきましたので、そちらを比べていきます。
サービスリリース前は、マイクロサービスごとに分れているチームごとでそれぞれの機能開発を進め、最終的に1つのメルペイサービスをリリースすることが全体として大きなマイルストーンとして置かれていました。一人一人の裁量が大きく、1チームに1人のQAエンジニアが担当してリリースまで走り切るような状態でした。要件定義やリソースの調整、スケジュールの調整であったり、自動テストの実装などもほとんどすべて1人の力で実装し、2019年2月に無事リリースを迎えることができました。まさに、ゼロから新しい価値をつくっていったようなフェーズでした。
サービスリリース後は、そこからお客さまに価値を継続的に届けることが必要となるアクションを取り続けていく必要がありました。大きく分けると3つあります。第1に、新規機能開発です。当然、リリース時の機能だけでは足りず、新しい機能の提供を止めることはできません。さらに、ただ新しい機能を開発することだけを考えればいいわけではなくなり、新規機能開発も既存機能への影響なども考えて開発する必要が出てきました。考慮するべき観点がより増えたという感じです。第2に、グロース開発です。メルペイは金融サービスとして単純にサービスを提供するだけでなく「Fun to Pay」な世界観をつくり出し、なおかつ、お客さまが使いたいと思うような魅力ある施策を提供したいと考えていました。例えば50％ポイント還元キャンペーンや、お得なクーポンなどの施策をグロース視点で推進していました。第3に、保守運用の開発です。当然、サービスを提供したあとは不具合対応やサービスの安定稼働が求められるため、既存機能の保守運用やメンテナンスも必要となります。こうして、やるべきことがどんどん拡大していき、コアローンチ前の開発体制やプロセスでは高い品質保証を実現することが難しくなっていきました。
品質保証について
では、現在の品質保証についてどのように変わってきたのか、その一例を紹介したいと思います。
まず、品質保証に欠かせないこととして、プロダクトとプロセス、そしてチームが挙げられると思います。第1に、プロダクトです。サービスや機能の品質を保証することは、価値提供につながっていきます。第2に、プロセスになります。要件定義の段階からQAエンジニアが参画し、要件定義漏れを防いだり、QAフェーズにおける不具合分析などを取り入れることも品質向上につながっていきます。第3に、これらの活動をするチームや組織と協力してQAが架け橋となり、品質改善活動に取り込むことも品質向上につながっていくと思っています。ですが、多くの場合、品質というとプロダクトやサービスそのものにフォーカスを当てがちですが、実質的にはこれら3つが相互に向上されることで「品質」が保証されると考えています。なので、QAエンジニアが担う役割としてのテスト実施は、あくまで品質保証の一部にすぎません。本日は、プロセスやチームといった観点から品質を向上させていった具体例をお話ししたいと思います。
本日お話しするのは、「定額払い」という機能をリリースしたときのお話になります。定額払いという機能は2020年7月にリリースされて「お金が理由であきらめるを無くす財布」をコンセプトに、使いすぎや、払い終わらないといった支払いに関する問題を解消して、より安心してお買い物を楽しめることを目指したサービスになります。ただ、この機能をリリースするには、かなり複雑な課題が重なりあっていました。
簡単に一言で言い表すと、とにかくプロジェクトの難度が高かったと言えます。まず技術的には、定額払いをリリースする前から積み重ねていた負債による影響であったり、データの二重書き込みによる整合性の担保の難しさ、また、アーキテクト自体の複雑性なども挙げられます。さらに、このチーム内にもマイクロサービス化を推進するチームと、定額払いを新規開発するチームが並行して開発を進めていたり、さらには、ほかのマイクロサービスとの連携など、とにかく関係者が多くプロジェクト規模がすごく大きくて、難度がどんどん上がっていったというような状態でした。
そんな中、QAエンジニアとしてどのように品質向上に関わっていたかというと、まず1つ目としては、組織づくりです。まず、チームに関する取り組みを紹介したいと思います。
先ほど課題でもお伝えしたとおり、このプロジェクトでは関係者がすごく多く、これまでよりも開発ラインが増えたというような状態でした。なので開発ラインが増えたことで、LeSSと呼ばれるlarge scale scrumのフレームワークを採用して運用を始めました。もともと1チームに1名のQAエンジニアといったような体制から、開発スピードに対応できるように、このチーム内のQAも複数ラインで分けられるようにしました。QAが佳境になる前にQAメンバーの最大稼働数を想定し、新しいQA体制をつくり直していきました。これまでメルペイQAにおいて、個々人の責務において各チームに関与してきたんですが、人数が増えて組織が大きくなっていったことで、その統括をせざるを得ないという状況になったので、各ラインにQA Leadというものを設けて縦と横のつながりをつくるようにしました。私は、この横と縦のつながりの接点に立って、チームがスムーズにワークするように働きかけていきました。
次は、プロセスに関する取り組みを紹介します。
プロセスについては、最初にやったこととして、まず、見える化の徹底や可視化することでプロジェクト全体がわかりやすい状態をつくることを意識していました。とにかく巨大なプロジェクトでQAエンジニアだけでも30名ほどいたので、一定のガイドラインを作成し、錯乱していたドキュメント類を共通化したり、一元管理するようにしました。QAチーム内でも、プロダクト全体としても”わかりやすい”状態をつくりました。ゴールがどこにあるのかを明確にすることで、個々人がそれぞれ考えて動ける状態になったことと、また、課題をわかるように整理することで、みんなで困っていることを解消することができて役割に関係なくサポートしあえる状態をつくり出せました。
もう一つプロセス改善として、テスト環境の問題を解消しなければいけませんでした。これまで同じマイクロサービスを複数人で同時にQAするという機会はそこまで多くなかったため、メルペイにはテスト環境と呼ばれる環境が1つしかありませんでした。ただ、先に申し上げたとおり、QAが並列で複数走るというような状態になり、メンバーの稼働率を下げることなく検証を進めるために、テスト環境の問題を整理する必要が出てきました。ここに関しては、アーキテクトチームの方と理想となるテスト環境の構想について相談させていただいて、マイクロサービスのQA並列化を可能にするような仕組みを導入していただきました。簡単に説明すると、Istioを使ったバーチャルサービスで、リクエストのターゲットを指定することで複製テスト環境を整備することができるようになりました。マイクロサービスとマイクロサービスをダイナミックルーティングでつなげるような仕組みになっています。メルペイでは、ある機能を検証するときに複数のマイクロサービスを経由して検証しなければいけないことが多いです。その場合、検証する機能ごとに各マイクロサービスのブランチを適切なものに指定して実行していくことで、複数名での同時検証を可能にさせることができるようになりました。このあたりの仕組みについては、より詳細を知りたいという方は、本日の16時10分から予定されているアーキテクトチームによるセッションで、ここの仕組みについての詳細な発表があるので、ぜひご参加してみてください。
このように体制を整備したり、共通認識をチームで持つこと、また、メンバーの増員から環境問題が今後ブロッカーになることを想定してプロセスを整備するなど、こういったことを進めながら各方面の方々の協力のもとプロジェクトを推進しました。こうした取り組みは、もちろんQAチームだけで実現できたものではありません。
そして、コアローンチ以降最大プロジェクトだったといっても過言ではないこの定額払いプロジェクトを通してわかったことは、プロダクト開発・運用に関わるすべてのメンバーが立場や役割を超えて、より良いサービスをお客さまに届けるために全員で品質をつくり上げていくことの重要性でした。プロダクトだけを見ているだけでも品質の向上は満たせず、プロダクト・プロセス・チーム、これらすべてを考えることが重要になっていきます。さらに品質保証というのは、QAチームだけでは実現できないもので、チームや組織の全員が品質を考えながらデリバリーに集中することがすごく大切だと感じています。
こういった全員で品質をつくり上げていくことをメルペイでは「全員品質」と呼び、メルペイではこの全員品質というマインドセットのもと、日々サービスと向き合っています。
それでは、本日のメッセージを添えて最後とさせていただきます。
これまでのメルペイでは、0→1フェーズにおいて早く行くことを優先することがすごく大事だったんですけれども、メルペイにおいて、こういったフェーズは終わったんではないかなと思っています。より大きな目標やメルペイのミッションである「信用を創造してなめらかな社会をつくる」という世界を実現するためにはより遠くまで行くことを重視する必要があり、これからのメルペイは、より大きなことを成すためにさらにメルペイ全体で進んでいきたいと思っています。これからも私たちメルペイQAは、品質保証をリードし、いいサービスをお客さまに届けるためにあらゆることをする、そんな組織でありたいと思いながら今後も品質活動を続けていきたいと思っています。
本日はご清聴いただきありがとうございました。
