Tech Talks vol.47－The KAIZEN Project Undertaken by All QA Members

Tech Talksについて

世界約50カ国の国と地域から集まった個性豊かなプロダクトメンバーたちの声を通して、モノづくりへの姿勢や雰囲気をダイレクトにお伝えするTech Talksシリーズ。
今回は、PayPayのサービス品質を支えるQAメンバー全員がワンチームで推進した、リグレッションテスト業務の“KAIZEN”プロジェクトについて伺いました。

膨大なリグレッションテストの効率化が至上命題だった

今回のプロジェクト概要とミッションは？

Kelvin：
QAチームが行っているリグレッションテスト（プログラム変更や修正により、システム上に該当箇所以外への影響がないかどうかを確認するテスト）の手作業を減らすプロジェクトです。テストケースの最適化やテスト手法の改善、テストの自動化などを通じ、通常3日間のテストを1日で完結させることがゴールでした。普段、QAチームはサービス領域ごとに担当分野を持ち稼働しますが、チャレンジングな目標をクリアするにはQAチーム全体で課題に対処する必要がありました。本KAIZENプロジェクトの担当者である私と、所属するQA Serviceチームに加え、普段は金融サービスQAチームで稼働しているYusakuさん、ペイメントQAサービスチームのPrasadさん、また業務の自動化に強いQA TechチームのAmitさんといったQAメンバーとワンチームで動きました。

Amit：
QA業務の改善に際し、テストの自動化比率を70％から90％に上げるのがミッションでした。自動化率90％という数値は業界水準を鑑みてもチャレンジングで、最初に目標を聞いたときは、「実現可能なのか？」と思いました。ですが、QAメンバー同士の相互協力はもちろん、現場でサービスを開発しているPMなどQA以外のメンバーとも連携し、課題を一つひとつクリアしました。

QAチームが直面していた課題は何でしたか？

Yusaku：
給与デジタル払いやPayPayカード情報の表示など、PayPayにさまざまな機能が増えていくにつれ、リグレッションテストの範囲が膨れ上がっていました。マニュアル（手動）での実行が必要なケースも多く、以前は数千ケースのテストに3日間を要し、平均十数名のメンバーが工数を割いてマニュアルでテストしていました。ですが、予算や人員、リソースには限りがあります。可能な限り自動化を達成し、技術的に困難な部分も、テスト頻度や優先順位を見直し、効率化が必要でした。一方、6,700万人（2024年12月時点）のユーザーが利用するPayPayサービスの品質を担保する責任もあるため、効率化と品質を両立するチャレンジが求められたのです。

「最後の砦」としてPayPayを支えつつ、90％近いテストの自動化を達成

プロジェクトにおけるそれぞれの役割を教えてください

Prasad：
私の役割は、自動化を通じリグレッションテストの工数を削減することでした。ワーキンググループを組織し、テスト内容の理解と分類に努めました。そこで生じた技術的な課題や自動化の余地を整理したうえで、他社事例やQAツールの調査・分析を行い、メンテナンス性や可読性の高い「ページオブジェクトモデル」に基づくフレームワークを構築し、テストの効率化に貢献しました。

Amit：
私もPrasadさんと同じく自動化の促進が役割でした。また、自動化チームのリーダーとして、自動化目標の達成に向けた戦略立案やプロジェクトマネジメントなども求められました。アジャイル的に改善を続ける中でも開発部門とは密な連携を心がけ、週次・月次でのMTGやレトロスペクティブの設定、月次レビューを主導し、効率化の一方で開発部門の求めるユーザー第一の品質保証ができるよう務めました。

Kelvin：
Yusakuさんと協力してテストケースの必要性を検証し、テストケース最適化の基準となるガイドラインづくりを行いました。ガイドラインには細かなテストの実行頻度やテストケースの優先順位を決めるための規定や条件が含まれ、各チームで活用されました。最終的に、テスト内の手作業を約70％削減することに成功し、テストをより素早く完了できるよう改善しました。

Yusaku：
私は、普段から携わっている金融サービス・請求書払い領域のテスト最適化を担当しました。蓄積されたテスト結果と不具合発生状況を洗い出し、Kelvinさんと作成したガイドラインに基づき、テストの実施頻度や優先度を再検討しました。具体的には、不具合の発生頻度が低いケースは優先度を下げつつ、重複した内容やリグレッションテストの目的にそぐわないケースを見つけ出し、作業を削減しました。同時に、テストケースの削減によってサービス品質に影響が生じないよう、削減後の不具合を見逃さないための仕組みづくりにも注力しました。

プロジェクトで一番大変だったことは？

Yusaku：
私たちの構築しているフローで本当に問題が発生しないか、常に不安と隣り合わせだったことです。私たちQAチームは、サービスが世の中に出る前に不具合を検知する「最後の砦」に近い存在です。つまり、私たちが不具合を見逃せば、ユーザーの皆さまに不具合のあるサービスが届いてしまう。正直、重圧に押しつぶされそうでした。ですが、私たちQAチームには過去の膨大なテストデータがあります。「明確な根拠に基づいて設計したフローだから、きっと大丈夫だ」と自分に言い聞かせ、アグレッシブなテスト削減を行う姿勢は変えませんでした。

Kelvin：
同感です。実は、最初に作成した新ガイドラインは、今思えばかなりコンサバティブな内容でした。「これでは削減目標を達成できない」と感じ、新機能やサービスのリリース時、影響を受ける領域に関連するコード変更がない場合、テストをスキップ可能にする優先順位付けを行うなど、より削減にドライブをかける形に調整しました。そのため精神的に苦しい時期もありましたが、「これをやればきっと楽になり、別のクリエイティブな作業に工数を割けるようになる」という想いが支えになりました。並行する別の施策としてテスト速度向上に資するツールの開発や、テストの実行方法を見直すなど、サービス品質に与える影響が少ないメソッド改善にも取り組んだ結果、リスクを最小限に抑えた業務改善に成功しました。

Prasad：
自動化の難しいテストケースに直面したことです。例えば、PayPayの根幹を担う「決済コードのスキャン」は、人為的なスキャンが発生する都合上、自動化が難しい作業でした。ですが、現場からの要望もあり「なんとか実現したい」と、活用している自動テストツールのドキュメントや機能を徹底的に調べ上げ、アイデアを募って自動化の道を探りました。ネットで調べても技術的な解決策が見当たらない命題に挑むのはチャレンジングでしたが、最終的にはコード決済をアプリ上で疑似的に再現し、自動化に成功しました。

Amit：
フレームワークの改善に必要な、テストケースの分類と理解が大変でした。最初の2～3週間、改善そのものには着手できず、各ケースの分類と理解に没頭しました。それぞれの機能を担当している開発チームに毎回問い合わせるのは骨が折れましたが、各ケースを正確に理解できたことで、フレームワークの改善がスムーズに進みました。

プロジェクトの成果と、今後の展望を教えてください

Amit：
目標に掲げていたリグレッションテスト期間を1日に短縮することに成功しました。また、自動化率も90％近くを記録しました。フロー変更を起因とする大きな不具合もなく、ホッと胸をなで下ろしています。成功要因は、QAチームを中心に部門間の密な連携ができたこと、そしてプロジェクトメンバー全員が改善の必要性を共有し、同じ熱量で改善に取り組めたことだと思います。普段携わっているPayPayカード内でも自動化の体制を構築できるよう、今回の経験を活かしたいです。

Kelvin：
工数削減により生産性は40％以上向上し、リグレッションテストの総所要時間は60％以上短縮されるなど、大幅な時間短縮と効率化が実現しました。一方、今回はQAチーム内での改善にとどまったため、今後は開発部門全体を巻き込んだ業務改善に着手したいです。今回以上に多くのステークホルダーと議論を交わす必要があると思われるので、PayPayが大切にする価値観“PayPay 5 senses”の一節である「Ego is not welcome,
Communication is necessary」の精神を意識し、生産的な議論を通じて成果を出していきたいです。

最後に、読者へのメッセージをお願いします！

Kelvin：
圧倒的なユーザー数を誇るPayPayにおいてQAを担当し、サービス品質を担保していることは私の誇りです。困難な目標を前にしても、常に新しいことに挑戦し、その過程を楽しめる方にとって、PayPayは最適な場所だと思います。

Amit：
PayPayは日本の決済市場に革命を起こしたサービスです。技術力があるに越したことはありませんが、大規模なサービスを支えるためには、柔軟な思考とメンバー間の協力、過去の経験からの学びが欠かせません。私も今回のプロジェクトでの学びを、PayPayカードにおける自動化体制構築に活かしていきます。

Yusaku：
精神的にタフな時期もありましたが、チャレンジングな課題に対して、前向きに解決策を考え、実行できたのは収穫でした。QAマネージャーとして死守すべきユーザー体験を念頭に動くのはもちろんのこと、環境の変化を楽しめる人に向いている会社です。

Prasad：
今回の自動化方法を考えるために、ツールの仕様を隅々まで理解し、新しいソリューションを話し合った時間は、私にとって技術的な学びになりました。また、各部門が直面している課題に対し、自分が先頭に立って技術的な解決策を示し、リーダーシップを発揮する経験ができたことも収穫でした。技術者として成長したい方、ぜひPayPayの門をたたいてみてください。

※募集状況、社員の所属等は取材当時のものです。