トップ > 設計 > 続・決済基盤の技術的負債に向き合う

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

設計 組織運営

DMM アドベントカレンダー 2025

はじめに

プラットフォーム開発本部 第2開発部 購入グループの藤井（@yoshiyoshifujii）です。

前回の記事「決済基盤の技術的負債に向き合う」から約1年が経過しました。DMMに入社して最初の7週間で決済基盤の現状を観察・分析した結果を前回お伝えしました。今回は、実際に取り組んだモダナイゼーション活動について、Phase1（2025年1月〜7月）の成果と、現在進行中のPhase2（2025年8月〜2026年2月）の取り組みと学びを共有します。

前回の記事で触れたキーワード「Temporal」「CQRS」「Event Sourcing」「ストラングラーフィグパターン」を実際に決済基盤に適用し、どのような成果と課題があったのか。技術的な話だけでなく、組織的な変化やチーム体制の進化についてもお伝えできればと思います。

そして、この記事を読んでいるあなたにも、ぜひ一緒にこの挑戦に参加していただきたいと考えています。決済基盤のモダナイゼーションは、まだ道半ばです。

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

Phase1: 基盤構築から機能実装へ（2025年1月〜7月）

やったこと

Phase1では、14スプリントを通じて以下の活動を実施しました。

  • ゴール定義と体制整備

    • モダナイゼーションの戦略的ゴール設定
    • 隔週でのバリューシンクMTG開催
    • アーキテクチャ方針決定（CQRS & Event Sourcing、Temporal活用）

  • 購入ドメインの深掘り分析

    • 購入プロセスの5ステップ定義 （バスケット追加 → 発注 → 受注 → 納品 → 受取）
    • ドメイン責務の明確化 （購入、決済、ポイント、クーポン、ボーナス）
    • Temporalを使用した分散トランザクション設計

  • 複数の実装パスを検討

    • 共通レジ経由 → 最終的に採用
    • Gateway経由 → 技術的制約により断念
    • 独自レジ経由 → 規模が大きすぎて断念
    • CDCによるbinlog活用 → 技術的課題により断念

  • 基礎インフラ構築と本番接続

    • GitHubリポジトリ作成、CI/CDパイプライン構築
    • 社内コンテナオーケストレーション基盤を活用したKubernetes環境構築
    • 共通レジをFacadeとしてレガシー・モダン両システムへのリクエストをミラーリングする実装
    • 分散トレーシング（Datadog APM）の確立

※ Phase1の取り組みについては、Developers Summit 2025でも発表しています。詳しくは 発表資料 をご覧ください（ セッション情報 ）。

わかったこと

この約7ヶ月の取り組みを通じて、以下のことが明らかになりました。

  • レガシーシステムの制約は想定以上に大きい

    • 共通レジのリリースフローに3週間のブロッキング問題が存在
    • CI/CDパイプラインの機能不全（Jenkins故障）
    • 品質保証プロセスが確立していない

  • 小さなスプリントゴールによる着実な前進が重要

    • 当初の完了予測がぶれた（2月時点：5月14日〜6月18日 → 実際：7月30日）
    • しかし、最終的には「もっともらしい予測」の範囲内に収まった
    • スプリントごとの小さな成果の積み重ねが全体の前進につながった

  • ドメイン知識の整理と責務分離が成功の鍵

    • 購入プロセスの5ステップ定義により、複雑な処理フローが整理できた
    • 各ドメインの責務を明確化することで、段階的な移行が可能になった

  • 既存システムとの共存期間の運用設計が必須

    • Facadeパターンによる段階的移行は有効
    • ただし、両システムの整合性を保つための仕組みが必要

できたこと

Phase1の最終的な成果として、以下を達成しました。

  • ✅ Temporalベースの分散トランザクション管理システム構築
  • ✅ CQRS & Event Sourcing パターンの実装
  • ✅ 本番環境での分散トレーシング実現
  • ✅ テストアカウントでの電子書籍購入フロー実装

特に、 テストアカウントでの電子書籍購入 が新システムで動作するようになったことは、大きな一歩だったと考えています。

Phase2: 一般アカウント移行への挑戦（2025年8月〜2026年2月、進行中）

取り組んでいること

Phase2は現在進行中で、テストアカウントから一般アカウントへの移行というテーマに取り組んでいます。

  • Temporal Cloudへの移行

    • Phase1では、Temporal ServerをKubernetesに立ち上げていた
    • テスト環境と本番環境でTemporal Cloudへ移行完了
    • ADRを作成し、認証方式や管理方法を決定

  • 一般アカウント対応の障壁調査

    • 決済APIの本番環境実行には本物のクレジットカードが必要という課題
    • キャンセル機能の複雑性（void、return、directreturn、offlinereturn）
    • 決済を取り消すには管理画面の操作権限が必要で他部署に依頼していく必要があるという運用から気軽にデプロイできない

  • 決済領域の探索

    • 決済代行の仕様や、現行の決済システムを調査
    • Stripeを研究し、Payment IntentとPayment Elementが理想形と判明
    • Stripe採用の壁（DMMの一部サービスが規約に抵触、決済方法の未対応）

  • REA概念モデルによるドメイン整理

    • クーポンとDMMポイント（無料配布分）の扱いの矛盾を発見
    • 「値決め」「請求」「領収」という重要な概念を見出す
    • DMMポイント（購入分）が他の決済方法と併用可能な理由を解明

REA概念モデル

これまでにわかったこと

Phase2の探索を通じて、以下の重要な気づきを得ています。

  • すべてのブロック要素が複雑

    • モダナイゼーションチーム単独では解決不可
    • 決済ドメインを担っているチームとの連携が必須
    • 各ドメインの歴史的経緯を理解する必要がある

  • 決済領域は独立したプロダクトビジョンが必要

    • 購入領域と決済領域をモジュラーモノリスで一度構築し直す
    • 「Stripe的なPaymentsがある」前提で購入領域を設計
    • 将来的に決済システムが完成したら差し替え可能な設計にする

  • 概念モデルの整理が複雑性を解きほぐす

    • REA（Resource-Event-Agent）モデルによる整理が有効
    • ビジネスルールの矛盾を発見し、整理できる
    • ドメインエキスパートとの対話が不可欠

今後の方針

Phase2では、デリバリーサイクルに入り、以下のロードマップを策定しました。

2025年度のゴール：モダン化した購入システムをテスト運用から本格運用へ

  1. [Payments] PayPayテストアカウントで支払いと返金
  2. [Purchase] 指定DMMアカウントで電子書籍をPayPay決済で購入とキャンセル

2026年度のゴール：DMMポイントとクーポンを購入領域から分離

  1. DMMPointsドメインロジックの委譲
  2. Couponsドメインロジックの委譲
  3. DMMPoints無償値引きとPayPay・DMMPoints有償併用払い対応
  4. Coupon値引きとPayPay決済での購入・キャンセル対応

技術的な学び

Temporalによる分散トランザクション管理

Temporalの導入により、複雑な分散トランザクションを宣言的に記述できるようになりました。特に以下の点が有効でした。

  • ワークフローの可視化：処理の流れが明確になり、デバッグが容易に
  • 自動リトライ：一時的な障害に対する耐性が向上
  • 状態管理の簡素化：ワークフローの状態をTemporalが管理

ただし、Temporal Cloudへの移行には認証方式の検討など、運用面での課題もありました。

CQRS & Event Sourcingの実装

イベントソーシングパターンの実装により、以下のメリットを得られました。

  • 監査ログの自動生成：すべての状態変更がイベントとして記録される
  • 時系列での状態再現：任意の時点の状態を再構築可能
  • レガシーシステムとの並行稼働：ドメインイベントから現状システムのデータモデルを生成することで互換性を維持

一方で、イベントストアの設計や、イベントのバージョニング戦略については、まだ改善の余地があると考えています。

Observabilityの重要性

Datadog APMによる分散トレーシングの導入により、システムの挙動を詳細に把握できるようになりました。特に、レガシーシステムと新システムの処理時間を比較できるようになったことは、パフォーマンス改善の指針とできそうです。

組織的な学び

Phase1とPhase2を通じて、技術的な成果だけでなく、組織的な面でも多くの学びがありました。

ADRによる設計決定の文書化

Architecture Decision Record（ADR）を導入し、重要な設計決定を文書化しました。これにより、以下の効果がありました。

  • 決定の背景と理由が明確に：なぜその選択をしたのかが後から追跡可能
  • チーム内の認識統一：設計方針について共通理解を形成
  • 新メンバーのオンボーディング効率化：過去の決定を体系的に学習可能

モブプログラミングによる知識共有

モブプログラミングを実施することで、以下の効果を得られました。

  • 暗黙知の形式知化：ベテランエンジニアのノウハウが共有される
  • リアルタイムでのレビュー：品質向上とバグの早期発見
  • チームの一体感向上：共同作業による信頼関係の構築

残された課題と今後の展望

正直に共有すべき課題

モダナイゼーションの過程で、以下の課題が残っています。

  • 後続API（決済、ポイント、ボーナス）の冪等性欠如

    • リトライ時の重複処理リスクが存在
    • 各APIオーナーとの調整が必要

  • 返品・返金機能の未実装

    • 複雑な状態遷移への対応が必要
    • レガシーシステムとの整合性確保が課題

  • SLO計測の未整備

    • サービスレベル目標が定量化されていない
    • ユーザー影響の評価が困難

これらの課題は、技術的な難しさだけでなく、組織横断的な調整が必要なものも多く、引き続き取り組んでいく必要があります。

最後に

約11ヶ月間の決済基盤モダナイゼーションの取り組みを通じて、技術的な成果だけでなく、組織的な成長も実感しています。レガシーシステムの改修は、単なる技術的な課題解決ではなく、ビジネス理解、チームビルディング、そして長期的なビジョンの共有が不可欠だということを学びました。

前回の記事でも述べましたが、決済基盤のモダナイゼーションは非常にやりがいのある取り組みです。技術的な挑戦はもちろん、ビジネスへの直接的な貢献、そしてチームでの協働による成長の機会があります。

私たちは仲間を募集しています。

もしあなたが以下のようなことに興味があれば、ぜひ一緒に決済基盤の未来を作っていきましょう。

  • 大規模システムのモダナイゼーション
  • 分散システムの設計と実装
  • ドメイン駆動設計の実践
  • 継続的な改善とチーム成長

決済という重要なドメインで、レガシーシステムと向き合いながら、新しい価値を生み出していく。そんな挑戦的で刺激的な環境で、一緒に成長していきませんか？

ぜひ、私たちと一緒に決済基盤の技術的負債に向き合い、DMMの未来を支える基盤を構築していきましょう！

関連キーワード

  • DDD
  • CQRS
  • Event Sourcing
  • Temporal
  • ストラングラーフィグパターン
  • Kubernetes
  • 分散トランザクション
  • マイクロサービス
  • REA Model
  • ADR
  • モブプログラミング
  • Observability