失敗を武器に変える。決済手段追加でチームの開発効率に再現性をもたらすまで

サムネイル

はじめに
取り組んだこと
まとめ
これからの展望
最後に

はじめに

こんにちは、DMM.com の西です。
普段は決済関連のプロダクトの機能開発、運用業務に携わっています。

今年の9月に、DMM.comではあと払いペイディでの支払いに対応しました。
合同会社DMM.comが運営するサービスでペイディの直接決済が可能に

私はこの開発を推進する立場でしたが、チーム全体の集合知が問題の早期発見・解決に大きな役割を果たしていることを強く実感しました。

DMM.comでは、ニーズやトレンドに合わせ、スピード感を持って決済手段を追加することが求められています。

しかし、DMM.comの決済基盤は長期間にわたって運用されており、システムが複雑化しています。
また、決済手段ごとに接続仕様が異なるため、その差分がどう現行システムに影響するかを評価しながら組み込んでいくという動き方が必要になります。

この評価プロセスでは、さまざまな観点での調査や確認を複数人・複数チーム間で繰り返し実施します。
そのため、認識齟齬や手戻りによる遅延リスクを下げるために、定常的に経験者への負荷が集中してしまうという課題がありました。

このプロジェクトでは、決済手段を追加するだけでなく、これらの課題にも実践を通じて向き合い、改善することを目標としました。

取り組んだこと

過去の過ちを繰り返さない

最初から結論になりますが、このプロジェクトで一番効果があったと感じることです。一連の開発を通して得られた失敗経験は、次のプロジェクトで重要な情報源となります。

私は、前回のプロジェクトで過去のナレッジに大きく助けられたため、将来のプロジェクトで何かの参考になればと思い逐次ストックしていました。

大まかな情報としては下図のイメージで、各工程/フェーズで過去に発生した課題をリスト形式でまとめています。

課題のイメージ

決済手段の追加という観点では、大きく下記の2点が既存システムへの影響を測る変数となります。
この2点の解像度がどれだけ高いかがプロジェクトのスピードと質を左右すると考えています。

決済手段ごとの振る舞い
既存システムの振る舞い

また、これらが組み合わさった結果、過去にどういう課題が発生したかをストックしています。

変更後のシステムでは上記の2点が共存する形になりますが、振る舞いがどう顕在化するかは下記4つのフェーズに分類できると考えています。

開発前に把握できた振る舞い
開発途中で新しく分かった振る舞い
結合テスト / QAテストの中で分かった振る舞い
本番運用フェーズで分かった振る舞い

私自身、No.3までは意識できていたのですが、No.4の時点ではすでに開発プロジェクトが終了していることや別のプロジェクトが進行していることもあり、観測対象として疎かになっていることに気づきました。

しかし、No.4で得られる振る舞いは社内でどれだけテストをしても分からない振る舞いとなるため、後続のプロジェクトでは重要視される情報になります。
いくつか例を挙げると、下記のようなものです。

リリース後はどの程度のトラフィックが発生するか
- 定期的にセール等も打つため、この時のトラフィックはどの程度発生するか
決済フローの中で、特定のデバイスでのみ意図しない振る舞いをすることがないか
どの程度の決済成功率になるか、決済フローの中でどの程度の離脱が発生しうるか
- それをトラッキングして改善活動ができるか
不正利用がどの程度発生するか（チャージバックなど）
決済プロバイダー側のシステムメンテナンスの頻度
偶発的な処理遅延の頻度
クラウド障害などの大規模障害が発生した場合、決済不整合がどの範囲まで及ぶか、どのような復旧フローが発生するか

地道ですが、下記のような活動を草の根的に続けていくことが重要と考えます。
ドキュメントを充実させたとしても、時間の流れとともに忘れ去られ、内容も古くなっていくため、特定の誰かに知見が偏らない取り組みを継続する必要があります。

これらの情報を1つずつ集約し、後続のプロジェクトのメンバーが情報を閲覧できること
レビュー等に積極的に参加し、これらの知見を直接伝えていくこと

属人化からの脱却

新しい決済手段をDMM.comに組み込むにあたり、主に下記の情報を元にイメージを固めていきます。

導入しようとしている決済手段の仕様
過去に得られたナレッジ

主に、下記のような作業内容となります。

導入しようとしている決済手段がどのような決済フローを持っているか
- DMM.comの購入フローに組み込んだ場合にどのようなイメージになるか
  - 事前にアカウント連携が必要か
  - 決済結果がいつ確定するか
決済プロバイダーのシステム仕様の調査（API仕様など）
- 決済プロバイダーの仕様に沿ったリクエストを作れるか
- DMM.comのシステムで必要なAPIが提供されているか
- エラーコード等をDMM.comのシステム仕様とどうマッピングするか
  - 新たなエラーケースがないか
変更範囲の洗い出し
- 新しい仕組みが必要な箇所、既存の拡張で済む箇所
基本設計、レビュー
バックログアイテムを作成し、スプリントに配置
テスト項目の整備、テスト
リリース計画、リリース日の確定

導入しようとしている決済プロバイダーの仕様を踏まえて、具体的に既存システムのどこにどのような変更を入れるかを判断する必要があります。実際にソースコードを読まないと把握や考慮が難しい点もあり、一定の運用経験も必要になります。

また、決済手段の追加という性質上、どうしてもスピード感を重視せざるを得なくなります。
ソフトウェアの品質とスピードを維持しつつローンチするには、過去に経験のある人が手を動かさざるを得ない状況になっていました。

プロジェクトの時間軸で見た場合、経験のある人にお願いすることで一時的なスピードは上がると思いますが、長い目で見ると下記の問題を引き起こす可能性が高まります。

前回の担当者が異動したり、退職した場合に知見が失われてしまう
- ドキュメントを残しても全ての情報を書くことは難しい
- ドキュメントは継続的にメンテされないと時間経過とともに内容が古くなる
チーム編成が変わった場合、類似のプロジェクトで同じパフォーマンスを出せる保証がなくなる
- 前回の担当者が別のプロジェクトにリソースを割いている場合など
ボトルネックが肥大化し、チームの成長機会を失うことにつながる

また、経験の少ない人とプロジェクトを進めることで、相互に知見を獲得できたり、今後の類似プロジェクトで戦力になる人員が増えるなど、これらのメリットの大きさを感じました。

経験豊富なエンジニアがいつでも支援に入れる体制であったため、レビューや開発のサポートなどを手厚くすることで、手戻りや作業遅延を最小化することに努めました。

停滞を素早く検知して対処する

開発メンバーが多拠点にまたがることから、一部の開発メンバーとはリモートワーク環境でのコミュニケーションとなりました。
特に、困った場合などは検知がしにくい状況となることから、アラートを上げやすくすることに努めました。

そこで、プロジェクト期間中、開発メンバーの気づいた人が毎日スレッドを立ち上げる取り組みを行いました。 (下図参照)

slack_message

とある日には55件のやり取りが発生していたこともあり、Slackでメッセージを一つ用意しておくだけでも、
進捗遅延のアラートや相談がしやすくなっていることが分かりました。

これは実験的に始めた取り組みでしたが、問題が起こった場合にスムーズに状況を把握できるようになり、チームで軌道修正をしやすくなったと感じた点でした。

この作業スレッド文化は、別のプロジェクトでも引き継がれています。

AIエージェントの活用

2025年に入り、AIエージェントの進歩が凄まじいものになっています。
当時、Devin、Clineが社内利用できる状況であったため、これらを活用しながら開発を進めていました。

当時は生成AIの活用がまだ試行錯誤の段階だったこともあり、既存コードの仕様調査やプロトタイプコードの実装の用途で使うことが多かったです。

また、当時はAIツールを活用した開発も十分に浸透しておらず、AIツールにどこまで委ねるかの判断が各個人に依存していました。
これは手戻りの可能性があったため、活用を推進しながらも、キックオフ時にルールを明文化し開発チーム内で合意して進めました。

調査、壁打ちで用いる分は問題ないが、ストーリーをDevin、Clineに丸投げして実装しないこと。
変更意図を説明できるように実装すること。

今日では、AWSが提供するKiroをはじめとした仕様書駆動開発、Codexなど、高性能なAIエージェントの利用が拡大しており、 DMM.comでもAIエージェントの利用が日ごとに盛んになっています。

まとめ

上記の結果、前回の類似対応と比較して73%の工数減を達成して完了しました 🎉（45人月→12人月）

このプロジェクトを共に進めていたPjMの星野も、プロジェクトマネジメント観点の記事を公開していますので是非ご一読ください。(シリーズ1 12/5)
DMMグループ Advent Calendar 2025

これからの展望

2025年に入り、本格的に決済基盤を根本からモダナイズする動きが進行しています。
自チームで管轄しているプロダクトの最初のコミットログについても、2013年となっています。

Jira

約12年間稼働してきた決済基盤を分析する中で、下記のような示唆を得ています。

プロダクトの責務が曖昧になってしまっている
- 責務が曖昧になっていることで、拡張性が低くなってきている
- 機能拡張時の影響範囲が広く、スピード感を落とす一因になっている
システムの複雑化により、運用負荷が高まりつつある
分散システムとしてあるべき姿になっていない点がある
- 耐障害性に改善の余地が見られる

私も3ヶ月ほど前から、決済基盤のモダナイズを推進するチームに参加し、あるべき形に作り変えるべく日々向き合っています。モダナイズを進める中で得た知見については、来年のアドベントカレンダーでご紹介できればと思います。

来年以降はより活動を加速し、「スムーズに買えなかった」という体験を1件でも減らせるように取り組んでいければと思います。