Tech Talks vol.44 – Supporting multiple PayPay Cards project

Tech Talksについて

世界約50カ国の国と地域から集まった個性豊かなプロダクトメンバーたちの声を通して、モノづくりへの姿勢や雰囲気をダイレクトにお伝えするTech Talksシリーズ。
今回は、PayPayそしてPayPayカードのエンジニアたちが、PayPayカードの複数枚発行をうけてPayPayアプリ側の対応に関してOne Teamとして立ち向かったSupporting multiple PayPay Cards projectについて、開発を通じてのチャレンジや学びを聞きました。

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

Nomo：
PayPayカードを使いPayPay経済圏で買い物をするユーザーから、「用途ごとにカードを使い分けたい」という声をいただくことがありました。しかし、PayPayカードは1人につき1枚しか発行できない状況下、他社のカードを併用し使い分けていただくしかなかったんです。

そのような声をもとに、PayPayカードを1人につき複数枚(レギュラーカード3枚、ゴールドカード1枚まで)発行できるようにしました。もちろん単純に複数枚発行できるだけではなく、発行した複数枚のカードをPayPay上でもスムーズに切り替えて使え、各カードの明細を簡単に確認できるようPayPayとPayPayカード両社でタッグを組んで開発をしました。

プロジェクトにおけるそれぞれの役割

Nomo：
本プロジェクトは2023年10月頃スタートし、2024年8月にローンチという、かなりロングスパンな案件でした。私はPayPay側でプロジェクト全体の舵取り役であるPdMとして、データ分析によるユーザーニーズの深掘りや要件定義、プロジェクト運営体制の設計と推進を行いました。PayPayカードのメンバーとは技術面、ビジネス面での定例ミーティングを頻繁に設け、密にコミュニケーションできる体制を整えました。

Shota：
私はPayPayアプリ上でのiOS アプリ側の機能開発を担当しました。PayPayカードは1枚しか持てないことを前提にシステムが作られていたため、今回の改修による影響範囲はいうまでもなく広く、一歩間違えれば大規模障害につながりかねない案件でした。これは生半可な気持ちではできない…と覚悟を決めてプロジェクトに臨みました（苦笑）。

中本：
PayPayカードのエンジニアとして、私は追加カード発行申し込み機能の設計・開発や、PayPayクレジット登録の複数枚対応、会員サイトの複数枚カード対応を行いました。これほど大規模なプロジェクトに関わることも初めてでしたし、自分にできるのか、プロジェクト参画時点では不安な部分もありました。

Manoj：
私はクロスファンクショナルチームとのコミュニケーションを担当し、全フロントエンドアプリケーションのデータを提供するBFFバックエンドサービスの開発を行いました。今回のプロジェクトは、広範囲にスコープが及びユーザーへのインパクトも大きく、要件もとても複雑でした。PRD（製品要求文書）を読むのに2、3日かかったほどです。ですがNomoさんによるドキュメントが非常に詳細だったおかげで、不明点はほとんどない状態でプロジェクトに臨めました。

開発において特にチャレンジングだった内容は？

Nomo：
先ほどShotaさんがお話されたように、PayPayアプリのシステム上ではクレジットカード1枚しか登録できないように作られていました。複数枚発行が可能となった今回は、システムのかなり根本的な部分まで手を入れて改修する必要があり、影響範囲も広く、技術面においても、とてもハードルの高いものでした。PayPay社内だけでも20以上の開発チーム、さらにPayPayカードやLINEヤフー、PayPay証券にも影響する内容だったため、進めるにあたってコンセンサスを取らなければならない関係者も多く、調整部分では正直苦労しましたね。

そしてユーザーの使いやすさを考え、UIや操作性にこだわったことも大きなチャレンジでした。たとえばホーム画面に表示させるカードについて、当初はメインの1枚だけを優先的に表示させるという案がありました。ですが、カードの使い分けについてユーザー調査をした結果、どちらかのカードに偏ることなくバランス良くカードを使い分けているユーザーが多いことがわかったので、複数枚のカードをスワイプできる形に決定しました。

Manoj：
このプロジェクトは、PayPayアプリ内のホーム、支払い、取引履歴などの重要な画面に影響を与えるものでした。万が一何か問題が発生しても影響を最小限に抑えられるよう、段階的にリリースを行いました。
一例ではありますが、ホーム画面に複数枚のカードを表示する必要があったため、新しいAPIを使用する際に遅延が増加しないように注意しなければなりませんでした。遅延が増加すると、アプリ画面が読み込まれるまでユーザーが長く待たされることになり、結果的にユーザーエクスペリエンス（UX）に大きな影響を与えます。そのため、関係者全員と密にコミュニケーションを取り、リクエストを迅速に明確化し、メンバーと協力して高品質なコードを提供しました。システムのパフォーマンスやユーザー体験を損なわないように、非常に高いRPS（毎秒リクエスト数）で複数回のパフォーマンステストを行いました。
このプロジェクトの期間と規模の大きさから、コード内で毎週のように発生する多くのコンフリクトを解消し、毎週のQAテストを通過させる必要がありました。

Shota：
アプリエンジニアとして経験を積んできた私にとって、間違いなくこれまでに関わった中でも一番大きなプロジェクトでした。単一機能を改修する場合、通常は多くても2、3画面を変更すればよいのですが、今回は本当に多くの画面に手を入れる必要がありました。しかもPayPayでは数多くのプロジェクトが同時進行しているため、1つの画面に別のプロジェクトの変更が同時に入るケースもあったんです。例えば支払い画面では同時期にPayPay商品券とPayPayクレジットの併用支払いの対応も進めていたため、コードのコンフリクトが予想されていました。不具合がなく互いのプロジェクトの変更が確実に反映されるよう、関係者と期待する動作について認識を合わせ、また開発・QA・リリースについてのタイムラインを明確にしました。考慮すべきことが多く、かなり難易度が高かったですね。相談に乗ってくれたEM や PM、オーナーシップを持って共に実装を進めてくれたアプリメンバーのおかげで何とか乗り切ることができました。

中本：
開発中に追加要件や考慮漏れが発生した時は、決められたリリース日までに対応すべくPayPayカード側もチーム一丸となって奮闘しました。途中でどうしても間に合いそうにない状況に陥り、各チームのリーダーやPMの話をまとめてスケジュールを引き直せるか経営陣に相談しに行ったこともあります。

開発で特にハードルが高かったのは、「PayPayに提供するAPIの性能改善」そして「PayPayクレジット登録関係のAPIの総切り替え」に関する部分です。

まず「PayPayに提供するAPIの性能改善」について、PayPayカードでは、PayPayアプリにカード利用状況を表示する目的で、PayPayに利用可能額や請求額など「カード利用状況」を返却するAPIを提供しています。ところが複数枚のカード情報を渡す改修を加えたことで、性能部分に課題が生じ、APIの性能が基準に満たないという状況が発生しました。そこでAPIの設計を見直し、キャッシュや並列処理を用いて性能改善を図りました。負荷試験もしっかり行い、リリースは万全の体制で行いました。リリース日まであまり時間がない中で設計の見直しを行い性能改善を図った点はチャレンジでしたね。

また「PayPayクレジット登録関係のAPIの総切り替え」については、PayPayクレジットに複数のカードを登録できるようになったことで、PayPayからPayPayカードに提供されている幾つかのAPIが刷新され、PayPayカードとしては、一般ユーザーが複数枚のカードを保有し始める前に、既存導線を用いて刷新後のAPIに全て切り替える必要があったんです。ところが刷新対象のAPIは、重要な既存の他機能で使用されていました。一歩間違えば事故になってしまう状況下、PayPayと密に連携をとりながら深夜にAPIを１つずつ慎重に切り替えていきました。切り替えが成功した時は、正直このプロジェクトで一番ホッとしましたね。

上記チャレンジ以外にも、要件を軽量化したり、テスト期間を充分に確保する、プロジェクト全体の可視化を行うなど、開発のプロフェッショナルとして諦めずに打開策を模索した結果、Day1の納期を守ってリリースすることができました。

プロジェクトでの学びは？

Shota：
当初は Wallet 画面を担当しているアプリメンバーのみでこのプロジェクトに参画する予定でした。しかしメンバーやテックリードと話し合うことによって、全体を俯瞰して見ることができるようになり、多くの関係者を巻き込んで進めることが必要だと気付きました。例えば、ホーム画面については専任のチームに協力を依頼するなど、方針転換したんです。「できる」「できない」を適切な段階で判断し、タスクをハンドリングすることがプロジェクトを成功させる上で必要だと実感しました。

Manoj：
私はコミュニケーション面で学びがありました。PayPayカードのメンバーと直接タッグを組んだのは初めてでしたが、当初はコミュニケーションに行き違いがあり、PayPayとPayPayカードではディープリンクの生成の仕方など技術的な違いがあることになかなか気付けませんでした。「相手はきっとわかっているはず」という思い込みは捨て、疑問があればできるだけ早く明確にし、自分の意見を積極的に言うことが大切だと学びました。

中本：
プロジェクト参画当初、私はいち開発メンバーでした。その後、2024年4月にエンジニアマネージャーになり、プロジェクト全体の納期や品質に責任を持つ立場になったことで、高い品質でリリース日を迎えるにはどのようにすれば良いのかを徹底的に考えるようになりました。各チームやメンバーをマネジメントする経験を通じて大きく成長できたと感じています。
今までのキャリアの中で一番大きなプロジェクトでしたし、リリース後は自分の作ったものが多くの人に喜ばれていることがわかり、大きなやりがいを感じています。

プロジェクトが成功した秘訣と、今後の展望は？

中本：
プロジェクト初期段階からPayPay、PayPayカード両社で頻繫に定例会議を行い、PayPayとPayPayカードそれぞれが提供するAPIのインターフェースを早めに決定することができました。また新しいチャレンジとしてテスト期間を通常より長めに設け、社内の約数十名にフィールドテストユーザーとして実際に複数枚カードを作ってもらいテストを徹底しました。レビューを繰り返し、他のチームも巻き込み一丸となって品質担保に取り組んだことで、大きな問題が発生することなくプロジェクトを達成できました。今回の経験は、今後、他のプロジェクトにも活かしていきたいですね。

Nomo：
プロジェクトマネジメントをしっかりと行えたことも、プロジェクト成功の大きな要因です。情報を一か所に集約し、スケジュール管理を徹底しました。そしてプロダクト部門内だけでなく、マーケティング、CS、法務、業務チームなどビジネス側の関係者とも密にコミュニケーションし、認識合わせを丁寧に行い懸念されるポイントを都度解決していったことで、プロジェクト終盤になってから「実はできていませんでした」というような事態が発覚し慌てることはほとんどありませんでした。

リリース後の成果としては当初想定の2倍以上の申し込みがあり、多くのユーザーの皆さんに使っていただいています。またさまざまなメディアにも取り上げていただき、SNS上でもたくさんのユーザーからポジティブフィードバックもいただきました。今後も継続してユーザーに対し大きい価値を生める機能開発・より大きなビジネスインパクトにつながる機能開発に取り組んでいきたいです。

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

中本：
PayPayカードにはPayPayと同様に、世界中からさまざまなバックグラウンドを持つメンバーが集まり、世の中に大きなインパクトを与えるため切磋琢磨しています。チャレンジングなプロジェクトも多く、それを乗り越えることで大きな成長を得られます。ぜひ一緒にNo.1のフィンテック企業を目指しましょう！

Manoj：
急成長を続けるPayPayは、スタートアップ企業のようにダイナミックに働き、社会に影響を与えることができる一方で、制度面も整備され安心して働くことができます。今回、プロジェクト中に子どもが生まれ育休を取得したのですが、プロジェクト途中でも育休取得が可能でしたし、復帰後はまた課題解決に向けまい進できる会社です。社会に影響を与えるような仕事がしたい方は、ぜひ安心して飛び込んでみてください。

Shota：
金融領域のプロダクトやサービスは、他の分野に比べ技術や要件が複雑で、大変そうと感じる方もいるかもしれません。ですがPayPayなら、ウォレットやApple Payとの連携など、他社ではなかなか経験できない、決済系サービスならではの機能開発にチャレンジできます。新しいことに挑戦したい人にはこれ以上ない環境だと思います。

Nomo：
大規模なシステム開発経験を積みたい方にとって、PayPayはまさに理想の環境です。そして、マイクロサービスアーキテクチャを採用するPayPayでは、自分の実装だけで開発が完結することは少なく、他モジュールと連携することではじめてユーザーに価値を提供できます。自分の責任範囲を超えて仕事ができる人ならきっとPayPayで活躍できると思います。ご一緒できるのを楽しみにしています！

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