ID:80719さん

## プロジェクト詳細 ### ①どんなサービス・システムか 決済が発生した瞬間に、PayPayアプリの通知やメールで利用者に知らせる「カード利用速報」を開発・運用しています。身に覚えのない決済にすぐ気づけるようにする、不正利用対策のための機能です。 ### ②あなたは何を担当したか 2024年4月から4人前後のチームで、この機能の詳細設計・実装・テストを担当しています。参画から2年以上、新機能の追加とサービスの安定運用の両方に継続して携わっています。 ### ③どんな技術を用いたか バックエンドはJava/Spring BootでAWS上のマイクロサービスとして構築しています。決済データを他システムに送る仕組みにはKafka(データを非同期でやり取りするための基盤)、データの保存にはDynamoDBとMySQLを使い分けています。外部のAPIとの通信は、REST APIからより高速なgRPCへの移行を進めています。 ### ④どんな機能を開発したか - 連携がエラーで失敗しても自動で再送する「リカバリバッチ」を新規開発し、通知漏れを防止 - 通信経路をKafka経由に変更し、他システム障害の影響を受けにくい構成に改善 - 配信対象ユーザーの増加に対応するため、処理を分散させる仕組みを導入 - 事業側からの機能追加・仕様変更の要望に継続的に対応 - 外部APIをREST→gRPCへ移行中(通信の安定性・保守性向上のため) ### ⑤どんな課題に取り組んだか 利用速報は多くの外部システムと連携しているため、自分たちの管理外で起きた障害の切り分けや原因調査が難しいという課題がありました。 ### ⑥どんな工夫をしたか 過去、PayPay側からの問い合わせで初めて障害に気づいたことがあり、原因はAWSのデータベース(DynamoDB)障害でした。この反省から、5分間データが連携されなければ自動でアラートが鳴る仕組みを追加し、自分たちで異常に気づける体制に変えました。またテスト用データの準備が煩雑だったため、決済パターンごとにデータを自動生成できるツールを自作し、テスト準備の負担を減らしました。 ### ⑦どんな成果を出したか - 決済発生から平均5〜6秒でPayPayへの通知連携を完了し、2年以上安定稼働を継続 - 障害を外部からの指摘ではなく自分たちで検知できる体制を構築 - テストデータの準備時間を約5分に短縮 - 関連するバックエンドは6リポジトリあり、脆弱性対応も含め月1回以上のペースでリリースを継続 新卒入社後、最初に配属されたのがこのプロジェクトでした。Webアプリやバックエンドの知識がほぼない状態から3年以上携わり、自力の調査やAWSの実操作を通じて、システム全体を理解する力を身につけてきました。

## プロジェクト詳細 ### ①どんなサービス・システムか PayPayカードにおける「決済手段アイコン表示」は、PayPayアプリの取引履歴とミニアプリ「PayPayカード」の請求明細で、タッチ決済・Apple Pay・Google Pay・QUICPayなどどの決済手段で支払ったかをアイコンで一目で分かるようにする機能である。カード利用速報と同じ「クッション」システムの一部として実装されている。 ### ②あなたは何を担当したか MVP1（2025年1〜5月）はバックエンド4人・フロントエンド1人のチーム体制で開発し、自身はバックエンドのIF連携（API・ファイル拡張）とアイコン判定用データへの変換部分を担当した（画面実装は専任のフロントエンドメンバーが担当）。明細まわりのナレッジがチーム内になかったため、率先して既存のフロー・仕組み・表示ロジックの調査・理解に取り組み、開発を推進した。MVP2（2025年9月、約3週間）では、カラー券面の判定ロジック追加とフロントの表示ロジック改修、およびテストを担当し、バックエンド・フロントエンドを1人で兼任した。 ### ③どんな技術を用いたか バックエンドはJava / Spring BootでAWS ECS Fargate上に実装し、MySQL・DynamoDBをデータストアとして利用した。MVP2のフロントエンド改修はTypeScript / Nuxt.jsで実装した。 ### ④どんな機能を開発したか - 連携元システムから決済手段の判定に使えるデータを受け取れるよう、API・ファイル双方のIF拡張を実施した（MVP1）。連携元にはアイコン判定に必要な情報が不足しており、そのままでは取引履歴・請求明細でどの決済手段かを表示できなかった課題を解消した - 受け取った判定元データを、アイコン表示用のデータへ変換するロジックを実装した（MVP1）。これにより取引履歴・請求明細それぞれの画面表示要件に合わせたアイコン判定が可能になり、専任のフロントエンドメンバーが画面表示を実装できる状態を整えた - カード券面デザイン（ブルー・ピンク・ラベンダー）に応じたアイコン出し分けの判定ロジックをバックエンドに追加し、フロント側の表示ロジックも自身で改修した（MVP2）。あわせてテストを実施し、複数券面を保有するユーザーがどのカードの明細か視覚的に判別しやすくなった ### ⑤どんな課題に取り組んだか MVP1着手時点では明細まわりのナレッジがチームに蓄積されておらず、既存のデータフローや表示ロジックの理解が課題だった。MVP2は明細のドメイン知識を要する改修を約3週間という短期間でリリースする必要があった。 またMVP1では、本番リリース前のカナリアリリースで、社員の一部ユーザーでアイコンが表示されないという不具合が発覚した。原因調査の結果、アイコン判定に使っていたユーザー情報の項目が、一部ユーザーでnullになるエッジケースが存在することが判明した。この項目は入会時に値が変化する仕様で、会員データの作成フロー上一時的にnullになりうるためスキーマ上null許容になっており、「有効な会員であれば必ず値が入っている」という思い込みに基づいて判定ロジックを実装していたことが原因だった。 さらにMVP1のリリース後、明細ファイルを生成する別システム側で、本改修に伴う生成フロー内のソート処理変更が原因のインシデントが発生した。一部パターンの明細データで表示が崩れるという事象で、明細フローは複雑で全体を理解しているメンバーが限られているという課題があった。 ### ⑥どんな工夫をしたか MVP1では自ら率先して既存のフロー・仕組み・表示ロジックを調査・理解し、チームの開発推進に貢献した。MVP2ではバックエンド・フロントエンドを1人で兼任することで仕様理解から実装までの調整コストを抑え、短期間でのリリースを実現した。 カナリアリリースで発覚したnullエッジケースについては、本番DBから該当項目のデータを抽出し、実際に発生しうる値のパターンを洗い出した上で、判定ロジックがすべてのパターンを正しく処理できるよう修正した。本番相当のデータで事前に問題を検知できるカナリアリリースの仕組みを活かし、リリース前に不具合を修正できたことで、思い込みで実装したロジックの穴を本番影響が出る前に防ぐことができ、本番では問題なくリリースできた。 明細ファイル生成システムのインシデントでは、明細フローへの理解が限られたメンバーにしかない状況の中、自身が蓄積してきた知識を活かして率先して原因追及・リカバリ対応にあたった。影響を受けたユーザーの特定、問題のあるデータパターンの洗い出し、期待される表示と実際の問題表示の差分整理を自ら行い、インシデントを起こしたチームと連携してリカバリを進めた。 ### ⑦どんな成果を出したか カナリアリリースで検知したnullエッジケースを本番リリース前に修正したことで、自システム範囲では障害・不具合なく本番リリースを完了した。あわせてバッチ処理の性能検証も行い、既存処理と同等のパフォーマンスを維持できることを確認した上でリリースした。 決済手段アイコン表示により、これまで取引履歴・請求明細からは判別できなかった「どの決済手段で支払ったか」をユーザー自身がアプリ上で確認できるようになり、身に覚えのない決済への気づきや、家族カードの利用状況把握を、問い合わせなしで自己解決できる場面を増やした。 明細ファイル生成システムのインシデントでは、明細フローを理解しているメンバーが限られる中、自身が持つドメイン知識をもとに影響ユーザーの特定・問題データパターンの洗い出し・期待値との差分整理を主導し、インシデント発生チームだけでは時間を要したであろう原因特定とリカバリ対応を早期に進められる体制を作った。また本プロジェクトを通じて明細まわりのドメイン知識を深く理解したことで、その後の関連案件や問い合わせにも柔軟に対応できるようになった。

## プロジェクト詳細 ### ①どんなサービス・システムか PayPayカードの「ネットキャッシング」は、カードのキャッシング枠を使った借入をアプリ上で申し込める機能である。カード利用速報などと同じ「クッション」システム（PayPayカードの一部機能を提供する共通基盤）の一部として実装されている。 ### ②あなたは何を担当したか キャッシング領域を担当する新規チームにサポートとして参加し、フロントエンドを担当した。体制は5人ほどだったが、実際に手を動かしたのは自身ともう1人のみ。自身はUI・デザイン・文言まわりの修正を主に担当し、もう1人が生体認証まわりの追加実装を担当した。開発途中でそのメンバーが他案件にリソースを取られたため、以降の不具合改修とQAテストのサポートはすべて自身が引き継いだ。 ### ③どんな技術を用いたか フロントエンドはTypeScript / Nuxt.jsで実装した。生体認証のロジック自体は他機能ですでに実装されていたものを流用し、ネットキャッシング申込のフローに組み込んだ。 ### ④どんな機能を開発したか - ネットキャッシング申込時の本人確認を、暗証番号入力から生体認証に置き換えることで、暗証番号を失念したユーザーの離脱を防ぎ、借入申込の完了率向上を狙った。 - ネットキャッシング申込フローに生体認証を組み込み、カード暗証番号の入力に代えて生体認証で申込を完了できるようにした。既存の生体認証ロジックをキャッシング申込のフローにハンドリングする実装と、それに伴うUI・デザインの修正が主な対応内容である - feature flagによる切り替えでリリースできるようにし、安全に段階的なリリースを可能にした。また先行して一部の社員のみに公開してFTを実施し、安定に動作してることを確認した上でユーザー公開を行った。 ### ⑤どんな課題に取り組んだか 従来のネットキャッシング申込はカード暗証番号の入力が必須で、暗証番号を覚えていないユーザーの離脱が発生しており、月間約4000万円の機会損失につながっていると試算されていた。この課題を解消するため、ミニアプリ側の申込フローに生体認証を導入することになった。 また、新規チームであるためキャッシング領域やクッションシステムのドメイン知識がチーム内に十分になく、途中で実装担当のメンバーが他案件へ移ったことで、不具合改修とQAサポートを自身1人で巻き取る必要があった。他メンバーは主に設計や、関連する別システム側のテスト調整対応を担っており、クッション側の担当ではなくサポートやリプレイス中の別システムが主業務だったため、リリースフローや既存システムへの理解が深いのは自身のみという状況だった。QA担当者も新規参画者に近く、ナレッジが不足している状態だった。 ### ⑥どんな工夫をしたか feature flagによる切り替えでミニアプリ側のみ生体認証を有効化し、安全にリリースできる体制を整えた。QA担当者やチームメンバーに対して、リリースフローや既存システムの知識が不足している部分を都度サポートしながらQAテストを進め、リリース稼働までこぎつけた。 ### ⑦どんな成果を出したか ミニアプリ側でネットキャッシング申込に生体認証を導入した結果、暗証番号を思い出せずに離脱するユーザーが大きく減少し、離脱率は1割未満まで改善した。従来は月間約4000万円の機会損失につながっていたと試算されており、その改善に貢献した。