ID:80719さん

## プロジェクト詳細 ### ①どんなサービス・システムか 決済が発生した瞬間に、PayPayアプリの通知やメールで利用者に知らせる「カード利用速報」を開発・運用しています。利用状況をすぐ確認できる決済通知のUX向上に加え、身に覚えのない決済にすぐ気づける不正利用対策の役割も担っています。 ### ②あなたは何を担当したか 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年以上安定稼働を継続（うち約4秒は他システムの仕様によるデータ取得の待機時間で、自システムの処理は1〜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万円の機会損失につながっていたと試算されており、その改善に貢献した。

## プロジェクト詳細 ### ①どんなサービス・システムか PayPayグループで進められている、機能拡張版の新しいPayPayカードを立ち上げる大規模プロジェクトです。その中で、決済が発生した瞬間にメールやPayPayアプリの取引履歴で利用者へ知らせる「利用速報」を、新しいカードにも対応させる部分を担当しています。利用速報には自分たちを含め約7つのシステムが関わっています。 ### ②あなたは何を担当したか 3名のチームで、リーダーと私が利用速報機能の窓口を務めています。現行仕様の確認、他システムのメンバーやPdMとの打ち合わせ、技術面の設計(テーブル設計・判定ロジックの実装方針)、開発、テスト、リリースまでを担当しています。 ### ③どんな技術を用いたか 既存の利用速報と同じく、Java/Spring BootでAWS上に構築しています。データ保存にはMySQL、システム間のデータ連携にはKafka(データを非同期でやり取りする基盤)を使い、今回は新たにgRPC(高速なシステム間通信の方式)のクライアントも実装しました。 ### ④どんな機能を開発したか - 新しいカードの決済にも利用速報を出せるようにした(通知の種類は増やさず、既存の仕組みを新カードに適用) - メール内のリンクを新カード専用の遷移先に差し替え、利用者が迷わず移動できるようにした - 取引履歴の通知上で、既存カードの決済か新カードの決済か、またその決済手段の種類が見分けられるようにした - 特定の決済では、他システム側で決済手段が自動的に切り替わる仕様がある。切り替え自体は他システムの担当だが、私たちのシステムで判定に必要な項目を受け取れるよう連携インターフェース(IF)を拡張し、既存の取引に影響を出さない判定処理を設計・実装した。判定項目がない過去の取引は、従来のカード決済しか存在しなかったため「クレジット決済」として扱う - 決済に紐づくカード情報から利用者情報を取得する連携先が、REST API(従来の方式)からgRPCに変わったため、gRPCクライアントを新規実装した。バッチから呼ぶ新しいバージョンのREST APIを作り、その内部でgRPCを呼び出す構成にした。性能を考慮したIF整理、リトライ処理、APIキー認証、インフラ担当との調整までを1人で進め、AIも活用して約1週間で実装した ### ⑤どんな課題に取り組んだか - **ドメイン知識の習得**: 新カード特有の仕組みやクレジット決済の専門用語が多く、さらに約7システムが絡むため、他システムの仕様を把握するのに苦労しました。 - **gRPCの知見がない状態での実装**: 休日の学習とAIの活用で補いながら進めました。 - **巨大な既存テーブルへの項目追加**: 利用速報の既存テーブルは10億件を超え、毎月数千万件ずつ増えています。ここに必要な3項目を追加する方法を検討する必要がありました。 - **複雑な判定ロジック**: 特定のオーソリ(決済の可否を確認する承認処理)に対する判定が複雑で、実装方針を決める必要がありました。 - **新環境でのテスト準備**: プロジェクト用に新しいテスト環境が用意されたものの、テストユーザーの作り方が不明確でした。 ### ⑥どんな工夫をしたか - **テーブル設計**: 既存テーブルへの項目追加は、過去に別プロジェクトで経験したオンラインスキーマ変更(稼働中にテーブル構造を変える手法)でも事前検証が重い作業でした。10億件超ではその負担がさらに大きいため、既存テーブルには手を入れず、3項目を足した「v2テーブル」を新設する方針にしました。 - **今後を見据えたデータ管理**: この機能は社内でも重要度が高く、年1回程度は追加項目が出る想定です。そこでv2テーブルは保持期間を決めて件数を一定に保ち、将来の項目追加を軽い作業で済ませられるようにしました。ただし「特定条件で過去データを参照する」仕様があり、古いデータを単純には消せません。そのためプロジェクト完了後に、過去参照に必要な最小限のカラムだけを持つ履歴テーブルへ既存テーブルと古いv2テーブルのデータを退避する方針を決めました(具体的な方法やテーブル名は今後検討)。 - **段階的な切り替えと差分検証**: gRPCへの切り替えでは、バッチの環境変数(フィーチャーフラグのような設定)で、既存APIを呼ぶ処理のうち1%→25%→50%→100%分を新APIでも呼び出し、結果の差分を比較する方式を考えました。後続の処理には既存APIのデータのみを使うため、新APIに問題があっても利用者への影響は出ません。この方式の骨子は設計当初に私が提案し、チームリーダーがブラッシュアップして、詳細な実装を担当しました。 - **判定ロジックの方針とレビュー**: 3つの項目から結果を決める判定で、当初は「項目の組み合わせと結果の対応表」で表現する案を私が提案しました。実際に実装すると複雑で読みにくいとレビューで気づいて指摘し、「1項目で判定するパターン」「2項目の組み合わせで判定するパターン」「別の1項目で判定するパターン」をそれぞれ独立したメソッドに切り出す方針に変えました。自分の提案でも、実装後に可読性・保守性の観点で見直しました。 - **テスト環境**: 手順が不透明なままにせず、自分から作り方を調べて把握しました。 ### ⑦どんな成果を出したか - 現在、本番へ段階的にリリース中で、半分は完了しています。社内ベータテストまでに本番へ反映する必要があり、ここまで既存の取引への影響は出ていません。 - 差分検証によって、ある項目の値が、既存の連携先と新しい連携先とで異なるケースを事前に発見できました。連携先システムへ問い合わせて差分が発生する理由を突き詰めた結果、どちらもそれぞれの仕様どおりの値で、既存への影響は小さいと整理できました。一方で、新APIでは想定外の不正な値によるバリデーションエラーも検知し、アラートが鳴り続けたため一度切り戻しました。連携先でも原因が分からなかったため、想定外の値を受けた場合のハンドリングと、ユーザーを特定できるIDをログに出す検証ロジックを追加して調査を進めています。切り戻し後は1日で方針を決めて修正し、再リリースの準備をしています。 - 巨大テーブルへの項目追加を避けるv2テーブル方針により、今後の項目追加が少ない負担で済む見通しを立てました。