サムネイル

最初に

はじめまして。プラットフォーム開発本部第2開発部決済グループの藤井（@yoshiyoshifujii）と申します。

2024年10月に入社し、執筆時点で約7週間が経過しました。

今回は、私が所属している決済グループで管掌している、いわゆる決済基盤と呼ばれるシステム群が抱えている技術的負債について取り上げます。この間に私が取り組んだことや気づいたことを中心に、所感や考えを述べます。

この記事をご覧いただき、ご興味を持たれた方は、ぜひ一緒に決済基盤の技術的負債に向き合っていきましょう！

なお、この記事は DMMグループ Advent Calendar 2024 の5日目の記事となります。

決済基盤の技術的負債に向き合う

DMMの決済基盤とは

DMMが提供している支払い手段には、さまざまな種類があります。支払い方法

また、提供しているサービスも多岐にわたり、デジタルコンテンツ、通販、レンタル、金融サービス、オンラインサロンなど、多種多様です。事業情報

これらの多様なサービスや支払い手段を、お客様にストレスなく選んでいただき、決済し、サービスをご利用いただけるようにする必要があります。

さらに、サービスを提供している事業部の開発者が基盤を利用してサービスを提供します。サービスを迅速に市場に送り出すためには、事業部の開発者が使いやすい基盤であることも重要です。

加えて、決済結果を会計と適切に連携し、事業部の業績として見える化することで、経営の意思決定にも活用する必要があります。

このような特徴を持つシステム群を、決済基盤と呼んでいます。

広く、浅く、全体を俯瞰して見る

決済基盤の現状を把握するため、まずは全体を広く俯瞰して観察するところから始めました。

やったこと

以下の観点で観察しました。

チームの皆さんが何に時間を費やしているのか
チームの皆さんがどのような負担を感じながら取り組んでいるのか
問い合わせ内容の傾向
インシデント発生時の対応
チーム外とのコミュニケーションパス

また、決済チームの視点から周辺のネットワークI/Oについても観察しました。

朝会やふりかえり、問い合わせ内容、インシデントレポートなど、同期および非同期で行われているコミュニケーションを観察しました。さらに、過去の議事録やドキュメントを熟読し、背景をキャッチアップしました。

この約7週間で、恐らく一番多くConfluenceを検索したのではないかと思います。

わかったこと

決済基盤を管掌するチームに注目することで、以下の点が分かりました。

問い合わせが特定の領域に集中している
対応中の問い合わせが累積している
問い合わせの種類は多岐にわたる
- 決済後にサービスが利用できない
- 返金処理が行えない
- 返金取消が失敗する
- 決済基盤の使用方法が不明
- 新しくサービスを立ち上げたいが決済基盤を使うにはどうしたらいいのか分からない
状態の不整合が発生しており、手作業で補正している
ビジネス要求が頻繁に発生している

外から見た決済基盤を知る

周辺の関係者やシステムから見た視点を把握するため、外側から決済基盤を知る取り組みを行いました。

やったこと

以下の観点から、決済基盤がどのように見えているのかを調査しました。

決済基盤を利用するサービスを運営する事業部からの視点
決済に関連するDMMポイントシステムからの視点
決済結果に関心を持つ会計部門からの視点
決済基盤そのものではなく、チームそのものに関心を持つ他部門からの視点

関係するチームの代表者とコミュニケーションを取り、課題や視点をヒアリングしました。また、提供いただいたドキュメントを確認し、問題点や改善点を整理しました。

わかったこと

外側から見えてきた課題は以下の通りです。

サービスを新しく作る際のフローが複雑になっている
- 決済代行会社との契約
- 会計処理のための識別情報付与
- 決済基盤内のモジュールやデータへの追加作業
新しい支払い手段の追加が容易ではない
決済と会計のデータが密結合している一方、組織とモジュールは分離されている

決済基盤を取り巻く背景をコンテキストマップに書き出す

ここまでで、決済基盤がどのようなアクターやシステムと関連しているのか、ざっくりとした依存関係が見えてきました。

やったこと

これらの関連性を明確にするため、コンテキストマップに書き出し、ステークホルダーを特定しました。

コンテキストマップ

この図を書くことで、決済基盤に 含まれないモノ を明確にし、基盤の変更が影響するシステムやステークホルダーを特定しました。

わかったこと

コンテキストマップを作成した結果、以下の点が明らかになりました。

決済基盤のステークホルダーが多い
技術的負債を返済する際、すべてのステークホルダーとコミュニケーションを取る必要がある
関係する範囲が広いため、負担が大きく、調整が困難になりそう

コンテキストマップを活用することで、対象範囲の明確化と影響範囲の把握ができ、コミュニケーションが取りやすくなりました。

機能と情報にディープダイブ

決済基盤の外枠が見えてきたので、次に基盤の内部に着目し、どのような機能を提供し、どのような情報を扱っているのかを深掘りしました。

やったこと

以下のアプローチで、決済基盤の内部構造を詳細に確認しました。

プラットフォームを利用するサービスに公開されているAPI仕様書の精読
ソースコードの確認（PHP、Java、Kotlin、Go）
開発環境からのテーブル構造の抽出
データ分析基盤に格納されたデータの確認

わかったこと

内部を詳細に確認することで、以下の点が明らかになりました。

「決済基盤」と呼んでいるものの、決済は購入プロセス全体の一部に過ぎない
購入プロセスは複数のシステムを呼び出す構造になっている
複数のシステムを呼び出すのであれば、整合性を保つ難易度が高くなる
データ不整合が発生する要因として考えられる

なお、ここで言う購入プロセスとは、例えば以下のようなステップを実行していくことを指します。

商品を決めた
支払い手段を決めた
決済した
商品を納品した

決済は、このプロセスの一部です。

わかったことをふまえて、決済基盤の内部をコンテキストマップにまとめました。

決済基盤のコンテキストマップ

考察

これまでの観察と調査を基に、仮説を交えながら以下の考察をしました。

仮説と考察のポイント

特定のチームに負荷が集中しているように見える
- 特に、購入プロセスを管轄するチームの負荷が高い
購入プロセスが複数のシステムに依存しているが、トランザクションを適切に扱えていない
- サービス - 購入 - 決済 - 決済代行 の各状態が不整合を起こしている
- 分散トランザクションが必要そうだが、現在の設計は十分に考慮されていない
返金や返金取消などの逆行するプロセスが設計上考慮されていない可能性がある
- これにより、状態遷移や整合性に問題が生じている
障害を前提とした実装になっていない可能性がある
- 配信保証などの設計要素が欠けていると考えられる
現状は「at most once」の挙動に見える
- 上流および下流から同期APIで相互に呼び合う設計になっていることからそうだろう
分散モノリスなアーキテクチャと言えそうだ