2023年3月17日に、メルペイのQAエンジニアたちによる「Merpay Tech Talk〜メルカードのQA裏話〜」を開催しました。
2022年11月8日、メルペイはメルカリグループ初のクレジットカード「メルカード」の提供を開始しました。メルカードのリリースに携わった2人のQAエンジニアに、プロジェクトを終えた感想ややりがい、課題などを伺いました！
アーカイブはこちら！ https://www.youtube.com/watch?v=ux0BNsAAj2g
登壇者紹介
@fuji-kun / 株式会社メルペイ QAエンジニア
第三者検証会社でQA/PMOの経験を積み、暗号資産取引所のリードQAを経て、2021年12月メルペイに入社。現在はメルカードのリードQAを担当。
@yonn / 株式会社メルペイ QAエンジニア
2021年5月にメルペイに入社。メルカードチームのQAとして決済全般を主に担当している。最近ハマっているのは家（いえ）探し
@kj / 株式会社メルペイ QAチーム Manager of Managers
大学在学中にWeb、ゲーム、VRの事業を立ち上げたのちブロックチェーン企業の創業に参画し日本事業のプロダクトの責任者として従事。海外の国立銀行でのプロジェクトや日本のKYC高度化プロジェクトなどを進行。2018年5月にミッションに共感しメルペイに入社し、現在はDirector of Product, QA MoM, PMO Managerを務める。
「循環型社会」を加速させる新サービス「メルカード」
メルペイは「信用を創造して、なめらかな社会を創る」というミッションを掲げており、QAチームもこのミッションをもとに品質をエンジニアリングしています。
当初メルペイでは、フリマアプリ「メルカリ」における売上金が外でも使える決済サービスを運営していました。現在では「あと払い」や「貸金」などの金融事業においてもビジネスを拡大しています。
メルカリ・メルペイで、循環型金融をつくることを考えています。メルカリではモノを、メルペイではお金を循環させていきます。
さらに、最近リリースしたメルコインを利用して、ビットコインなどの投資におけるお金の流れを作ることも視野に入れています。
メルペイの主な注力領域は、決済・与信・資産運用の3つです。今回のメルカードは決済と与信をつなぐインターフェースになっています。これまでメルペイではiD決済やコード決済を扱っており、メルペイスマート払いという翌月払いや定額払いの仕組みもありました。
それを更にクレジットカードでも使えるようにするために実現したのが、今回のメルカードです。
メルカリアプリで完結するクレジットカードとしてリリースしています。
これまでメルペイでは、iD決済、コード決済の利用ができる店舗が269万箇所ありました。メルカードのリリースにより、利用可能な店舗は3900万箇所（JCB加盟店）と大幅に拡大しています。
メルカードには4つの特徴があります。1つ目は、本人確認済みのお客さまであれば、最短1分で全て登録でき、4日後には普通郵便でメルカードを受け取れます。
2つ目は、「メルカリ」アプリでの見える化・管理です。メルカードの利用履歴をすぐに確認でき、支払いの通知を受け取ることができます。利用上限金額の設定や、お支払いの一部を早めに支払いする設定も、アプリ内で完結します。
3つ目は、支払いタイミングや方法を自由に柔軟に選べることです。翌月1日から末日まで、好きなタイミングでメルカリの売上金やポイントを使用して支払いができます。
4つ目は、メルペイの立ち上げ当初から独自の与信モデルを用いていることです。従来のクレジットカードでは属性情報で判断されることが多いのに対し、メルカリやメルペイの取引データや利用実績をもとに蓄積された信用を使って与信を提供しています。これまで与信を受けられなかった方でも利用しやすくなっています。
メルカードでは、安心安全にご利用いただける機能の提供もしています。1つ目は、カードにナンバーを記載せず、アプリ上で確認する仕組みをとっていること。2つ目は、リアルタイムに利用がわかる通知がされることです。アプリ上から利用停止もできます。
メルカードは普通郵便で受け取るので、不在時でも受け取れます。普通郵便で送るとセキュリティの心配があるかと思いますが、スマホのアプリからカードをタッチしないとアクティベーションできないため、盗まれても不正利用されることはありません。
メルカードのリリースとあわせ、常時ポイント還元をスタートしました。メルカリでの利用は最大4%、お店での利用は常時1%を還元します。メルカリで売っても買っても還元率が上がっていきますので、そのような形で循環型社会をより広げていきたいと思います。
メルカードリリースの裏話と今後の課題
@kj：ここからはパネルディスカッションに入ります。視聴者が聞きたいのは「今いろいろなサービスやビジネスが走っている中で、クレジットカードを組み込むのは難しいのか？」という話だと思います。そこで、まずは「マイクロサービス横断のリリース裏話」を聞かせてください。
弊社では、バックエンドのシステムにマイクロサービスアーキテクチャを採用しています。たくさんのシステムがあり、クライアント開発を含め多くのリリースや施策が同時並行で動いています。他のQAへの影響も多いと思いますが、どのように取り組んだのでしょうか。
@fuji-kun：メルカードの決済や申し込みなどの基盤となるマイクロサービスは、既存のものだったので、それを先に改修してメルカードのマイクロサービスのものとつなぎ合わせて結合試験を行いました。既存のものはまずAPIレベルの確認をし、クライアントができたら結合試験を行いました。
サービスをつないでからいろいろな問題が出てきたり、テストを終える期限をリクエストしたもののうまくいかなかったりしました。関連するマイクロサービスが多いので、結合試験のテストの順番調整もかなり大変でした。
僕自身マイクロサービスのQAがはじめてだったので、苦労しつつも周りの人のサポートを受けて無事終えることができましたね。
@yonn：メルカードをリリースするまで、かなり大規模なプロジェクトになりました。その中ではいくつか開発するものに対して例外リストを作り、論理的に説明できる内容や結合試験でテストしなくてもいいものはスコープを狭め、リソースを効率的に使うように施策を作りました。
@fuji-kun：要件に沿ったテストを各マイクロサービスと接続した上で行いました。各マイクロサービスの中でも自分たちの専門領域から外れた部分のドメインについては、キャッチアップが大変でした。yonnさんはどうですか？
@yonn：私もメルペイに入社してからすぐ担当したのがメルカードのプロジェクトだったので、実際他のマイクロサービスの仕様については詳しくないものがかなりありました。メルカードのテストを進めながら他のマイクロサービスの仕様についても知らなければならないことが大変でしたね。
@fuji-kun：あと、リグレッションテストも大変でした。リリース前に、既存のメルカード以外のサービスに対して影響がないか、我々のメルカードの機能にデグレがないかをテストしたのですが、その範囲にも苦戦しました。
@kj：メルペイの開発ではありますが、メルカリやメルカリShopsを開発しているソウゾウでもたくさんの開発を行っているので、フリーズするとなると全て1度リリースを止めなければならず、調整コストはかなりかかります。
@fuji-kun：マイクロサービスによっては複製環境があり、各環境にはメルカード以外の施策のソースコードが反映されており、そちらはそちらで別のテストをしています。リグレッションテストでは本番に限りなく近い環境を再現するため、どの環境につなぐかをリストアップするのが大変でした。
マイクロサービスは依存関係を極力排除したアーキテクチャだと思うのですが、影響する部分はゼロではないので、影響範囲を絞るのには苦労しました。
@yonn：メルカードのリリース時期が決まっている中で影響範囲をしっかり洗い出して環境を調整した点は頑張ったと思います。
@fuji-kun：リリースに関連するマイクロサービスがあまりにも多く、ビッグバンリリースという例えを社内でしました。何度かに分割してマイクロサービスのリリースを行いました。
そのたびに本番環境で状況は変わるので、状況を整理して「何月何日にはこれがデプロイされるからこの環境でテストしよう」という対応にも苦労しましたね。
@kj：続いて、イシュアとしてカードを発行することに対する難しさについて話していきましょう。
@yonn：そうですね、クレジットカードをつくる体験が初めてだったので、まずは仕組みを把握することが大変でした。
クレジットカードは、国際ブランド・アクワイアラ・イシュアの3つの要素で構成されています。
国際ブランドは皆さんがご存知の通り、世界で広く利用しているクレジットカードのブランドを持つ会社で、JCBさん、VISAさんなどいろいろあります。メルカードでは、JCBさんのライセンスをとって発行しています。
アクワイアラは、お店の開拓審査、管理を担当する会社です。メルカードではアクワイアラもJCBさんが受け持っています。
イシュアはメルペイが担当している箇所です。クレジットカードの発行やカード入会申し込み、信用情報の照会や与信の金額の決定などの取引関連の情報の管理を担当しています。
参照記事：クレジットカード取引とメルカードマイクロサービスについて
@kj：仕組みを把握することはPM、BackendなどPJに関わるメンバー全員に関わりますね。QAエンジニアとして難しかった部分はどこになりますか？
@yonn：メルペイから発行するメルカードは後発なので、どういうお客さまが使ってくださるのかの考慮が必要でした。メルカードのメリットを最大に活かす方法を考えるのが難しかったです。
例えばセキュリティ面を考えたカードで不正利用を防止したり、決済をリアルタイムで確認できる仕組みをつくったりといった工夫をして、メルペイのメリットを生かすことに力を入れました。体験を損なわないUXになっているかどうかを気にしながらテストをしていましたね。
@fuji-kun：僕は前職でクレジットカードのプロジェクトに少しだけ携わったことがあります。前回は還元の部分のみだったので、カード発行自体を自社で挑戦するのは初めてでした。決済が複雑で、ドメインのキャッチアップに対しては不安がありましたね。
僕は@yonnさんより後にジョインしたのですが、エンジニアの方々が当たり前のように業界用語を使っていてピンときませんでした。例えばクレジットカードにおける仮決済は「オーソリ」と呼ばれるのですが、最初は意味がわからず、キャッチアップするのは大変でした。
@kj：イシュアとしてクレジットカードを発行することの難しさとして、複数社間でテストをしなければならないことも挙げられると思います。
@yonn：イシュアは大きく2種類に分けられます。メルペイで担当している領域はメルカードのサービスや本人確認機能の管理です。ですが、別途プロセッサーという領域もありますので、別の会社さんと連携し、カードの詳細情報などをプロセッサーで管理していただきました。そこでのやり取りが正確に行われているのかどうかも、メルペイのQAとして力を入れました。
@kj：クレジットカード関連の開発におけるコミュニケーションの中で、かなり複雑なドメインの知識や用語があると思うのですが、そのキャッチアップについてはいかがでしたか？
@yonn：ドメイン知識については協力会社と比較するとメルペイのほうが薄かったので、仕様を一個ずつキャッチアップしながら作りました。クレジットカードにおいてカスタマイズできることもあるので、カスタマイズによって仕様に認識のズレがあれば、結果的には大きな問題へと発展してしまうので、注意しながらやっていました。
例えば履歴を表示する際、メルカードでは仮決済と本決済をマッチングさせる機能があります。マッチングさせるには当然条件が必要です。条件を定めておかないとおかしな取引の履歴とマッチングしてしまう可能性があったので気をつけました。
@kj：@yonnさんにお聞きします。QAエンジニアはプロジェクトマネジメントの一部だと思うのですが、複数社間でのテストのスケジュール調整についてはいかがでしたか。
@yonn：定期的にミーティングをセットして、認識のすり合わせを行いました。複数社が絡んでいるため、予定通りに進まなかったときの影響が大きいので、あらかじめスケジュールにバッファを設けるようにも意識しましたね。
@kj：続いて、今回のメルカードのように新サービスリリースのQAを行うときに意識するべきことがあれば聞かせてください。
@fuji-kun：ナレッジを早い段階から準備し、リリース後に属人性を排除することだと思います。
メルカードは、今後のメルカリ全体の基盤となるプロダクトだと思います。新しいサービスや施策が今後どんどん出てくると思いますが、それらはメルカードが基盤であることを意識しながら進めています。
メルペイにはたくさんのマイクロサービスがあるため、我々メルカードのマイクロサービスのQAエンジニア以外がメルカード関連のテストをすることも増えてきました。ここで問題になるのが、属人性です。「メルカードの担当QAがやった方が効率がいい」という空気ができてしまえば、次々に我々にアサインされる状況が生まれることが考えられます。
そこで、影響する他のマイクロサービスのQAエンジニアでも対応できるよう、テストが終わった段階でナレッジを書き溜めることは、かなり意識しました。
@yonn：我々が整えた資料を他のチームの方々が有効活用してくれたことから、資料を整理した意義はあったかなと思います。
@kj：メルカード開発と同時にメルカリでGroundUP App PJという大きいプロジェクトが走っていました。メルカリアプリのコードベースを書き換えて新しいアーキテクチャやコードベースにする取り組みです。
参照記事：メルカリアプリのコードベースを置き換える GroundUP App プロジェクトの話
もともと8〜9年前にリリースしたコードベースがずっと使われ続けていたので、それを改善するためにメルペイも一部コードを改善したり、メルカードのリリースでこの改善に便乗するか否かという大きな決断をしなきゃいけないタイミングでもありました。それに対する感想や出来事を教えてください。
@yonn：このプロジェクトは去年秋頃に、メルカードは去年11月にリリースされましたので当然メルカードのプロジェクトにも影響しました。
QAとして最初にテストするアプリは、GroundUP App PJの前段階の旧アプリを使って開発しました。ですが、GroundUP App PJの開発に伴って、我々がテストするアプリもGroundUP Appベースでテストしなきゃいけなかったので、それに合わせたテストのスケジューリングがかなり大変でした。
テストした機能や基盤が変わってしまったので、それを担保してQAできるよう、結合試験などで全体的に確認しました。網羅的な確認の甲斐があって、バグはあまりありませんでした。
@kj：リグレッションテストにも影響はありましたか？
@fuji-kun：あまり影響はありませんでしたね。GroundUP App PJの皆さんのおかげです。
@kj：複数社間が関わっていることに加え、メルカリグループ内にも複数社あるので、大きいプロジェクトが同時並行で進んでいるのは大変でしたね。
@kj：メルカードをリリースしてからすでに4ヶ月ほど経過しましたが、プロジェクトをやってみての感想ややりがいについて教えてください。
@fuji-kun：リリースに至るまでは大変でしたが、大きいインシデントがなかったのでホッとしました。それは、QAのスコープやカバレッジについてしっかりと網羅して、安心安全なリリースを担保できたからです。今後のプロジェクトでも、同様の対応をとっていきたいです。
@yonn：僕は今まで物理的なものをリリースしたことがなかったため、メルペイ独自のクレジットカードを発行できたことはやりがいを感じたことの1つです。
今後も多くの方にメルカードを使っていただきたいので、もっとメルカードを成長させることが今後の課題です。
QAとしては、テストの自動化、テストのプロセスの改善、対応領域の拡大などのプランニングでさらなる成長へつながるよう、引き続き品質管理に力を入れていきたいです。
@fuji-kun：決済や申し込みなどの機能については、まさに今、テストの自動化に積極的に取り組んでいます。メルペイではscrenarigoという自社のオートメーションツールでAPIレベルの自動化を実装しています。
@kj：グロースフェーズに移り、多くの施策が出てきますね。「効率化」についても、引き続き進めていきましょう。
ドキュメント整理やテスト、コミュニケーションについて
@kj：視聴者さんから、「ドキュメントの管理ってどうしていますか？」という質問が来ています。
@fuji-kun：Confluence（コンフルエンス）でドキュメントをまとめています。管理しているレイヤーについて、決済や申し込みなどの機能ごとに細かい単位で分け、必要な情報を見つけやすいように整理しています。
他のQAチームとのコミュニケーションコストを抑える目的で、今はエッジケースのパターンに関する情報も含め、ナレッジをかなり蓄えています。
@kj：次に、「QAチーム体制や開発チームとの関わり方。次に同様のことをする場合、再検討や改善したい点はありますか？」という質問が来ています。
@yonn：メルカードのプロジェクトにおいても仕様をつくって開発・テストをする流れをとっていますが、仕様書にあまり細かく書いていない仕様については開発エンジニアからの解釈が入る場合があります。
開発の詳細については仕様を見るだけではわからないので、開発エンジニアとコミュニケーションをとる必要がありました。
情報を後追いできるようにドキュメントでまとめておくと、PMや開発エンジニア、QAのそれぞれの認識がずれる可能性は低くなると思います。
ドキュメントをまとめなくてもQAとしては開発中のコードを見れば分かります。しかし、コードを見るにあたってコストがかかり、リソース的にも良くないので、ドキュメント内に言語化しておいた方がいいでしょう。
@fuji-kun：メルペイのQAエンジニアは、コードを見て「どんな修正が入ったか」をホワイトボックスの観点で確認しているので、スキルのレベルが高いと思いました。
ドキュメントを参照するQAエンジニア本人がそれを書いているわけではないので、わかりやすいようにもう少し内容が整理されていたらよかったと思います。
@kj：仕様は開発の途中で変わることもあると思います。そういった観点で難しい点やクリアに進んだ点があれば聞かせてください。
@fuji-kun：結合テストでうまくいかないケースはありました。その対応として、シーケンスの中でAPIを1本追加するなど、仕様を大きく変えたこともあります。次に同じことをする場合、そこがなくなればかなりコストは抑えられると思います。
@kj：続いて、「クレカ特有のシナリオをどうテストしたのか」という質問が来ています。
@yonn：最初は皆で集まってシナリオを書きましたが、我々はクレジットカード未経験者が多いので、ブランドの方やプロセッサーの方にレビューしていただきました。
シナリオはカテゴリ化し、メルカード独自の仕様に合わせたことで発生するシナリオのパターンをそろえましたし、別途既存のクレジットカードであり得るユースケースを網羅し、シナリオ化を進めました。テストケースも、かなりの数がありました。
JCBさんからは、メルペイでは意識していなかったシナリオについてフィードバックをいただけたので助かりました。
@kj：実際に物理カードを持ってお店で決済するテストはありましたか？
@yonn：もちろん実施しました。一般向けに公開する前に本番でテストをしないといけないので、私から他社さんと話して本番で使えるカードを別途発行し、決済して異常がないかをテストしました。
@kj：決済する加盟店の選定も、ケースから選びましたか？
@yonn：はい。クレジットカードの決済方法もいろいろあります。例えば、カードを端末にかざすだけで決済できる、コンタクトレスという決済方法があります。それを使えるお店や、従来の決済方法を扱っているお店、使う頻度が高いお店などを選定してテストしました。
@fuji-kun：メルペイはコード決済が先にあったので、そのナレッジはかなり蓄えられています。「この加盟店は独自の動きをするから要注意」などのユースケースに沿ってテストしました。
@kj：最後の質問です。2人とも入社されたタイミングがコロナ禍で全部オンラインの環境下でした。その中でチームのコミュニケーションやチーム作りにおいて取り組んでいたことがあれば聞かせてください。
@fuji-kun：QAチームで「Gather」というバーチャルオフィスのアプリケーションを使って、何かあれば同期的にコミュニケーションを取っていました。
結合試験はとても複雑で、中でもドメインの知識に関する属人性はどうしてもQAチーム内で生まれてしまいました。たとえば@yonnさんは決済系が得意、僕は申し込みがメイン、といった具合です。
その中で結合試験で一連の流れを見なければならないので、苦手な部分を補うため、バーチャルオフィスを活用した同期的なコミュニケーションを意識しました。
@kj：例えば開発チームやPMとのコミュニケーションについてはいかがでしたか？
@yonn：リモートワークは私にとって珍しい経験だったので、慣れるまでに時間がかかりました。チャット・口頭でのコミュニケーションには、それぞれメリット・デメリットがあります。うまく使い分けてやっていくのが重要です。
特に細かい開発の課題や仕様の話し合いはチャットでは物足りないこともあったので、定期的にエンジニアと話し合う場を作るのが重要だと、このプロジェクトをやってみてわかりました。
@kj：その後リアルな対面でのコミュニケーションやチームビルディングはしましたか？
@fuji-kun：しました。そこで初めて会うメンバーもいました。
@yonn：＠fuji-kunさんと僕もオンラインではよく話していますが、対面であったのは10回もないくらい。今後はオフィスで会う頻度を高めていきたいですね。
最後に
merpay Tech Talkは、定期的にエンジニア向けのイベントを開催しています。イベント開催案内を受け取りたい方は、connpassグループのメンバーになってくださいね！
