こんにちは、メルペイCredit Design（クレジットデザイン）チームでBackendエンジニアをしている吉田拓矢（@tk8）です。

私が所属するCredit Designチームではお客さまの「信用」を創造し、そこに価値をもたらすサービスの提供をしています。代表的なサービスは「メルペイスマート払い」。これは、「メルカリ」における過去の利用実績を元に、利用限度枠が決まり、メルペイで購入した代金を翌月にまとめて清算できるあと払いサービスです。

そんな私ですが、このたび、2021年1〜3月期のMVP賞を受賞することができました。メルペイのミッションである「信用を創造して、なめらかな社会を創る」においても重要なサービスの一つであるメルペイスマート払いに関して次の実績を評価されました。

1：サービスリリース初期からの大きな技術的負債解消に向けたプロジェクトをリードし続け解消することができた
2：技術的負債の解消でサービスの一層の安定化や機能開発における複雑性を解決

今回の受賞を機に、これまでの活動を振り返ってみたいと思います。

技術的負債と戦う

メルペイスマート払いは、2019年4月に提供を開始したサービスです。なので、記事執筆現在では、まだ2年と少ししか経っていません。「2年で大きな技術的負債？」と感じる方もいらっしゃるかもしれないので、まずはリリース当初の話を少ししたいと思います。

当初、メルペイスマート払いのサービス提供に向けた開発は、メルペイのマイクロサービスアーキテクチャに則り、独立した開発を想定していました。しかし、開発工数とお客さまに提供開始したい時期には大きなギャップがありました。

そこで、「メルカリ月イチ払い」というメルペイスマート払いの前身にあたるサービスのコード資産をうまく活用し、サービスを実現するという大きな決断をしました。メルカリ月イチ払いのコード資産はメルカリ初期のころから開発されてきたモノリシックなシステムに実装されていたもの。そのため、モノリシックシステムにある主要機能と新しい機能を実装したマイクロサービスにデータを二重書き込みし、連携させることで機能を実現。サービスを無事にリリースしました。

しかしこの大きな決断によって、リリース当初から以下のような問題を抱えることになりました。

・ データの二重書き込みによる整合性担保の難しさ
・ モノリシックシステムとマイクロサービスにまたがる機能の分散や重複によるロジックの複雑性やアーキテクチャ自体の複雑性
・ モノリシックシステムに実装されているコードの歴史的要因による複雑性
・ 上記のような要因による運用コストの高さ

私が担当した技術的負債の解消に向けたプロジェクトのゴールは「モノリシックシステムから脱却しデータの二重書き込みやロジックの分散や重複の排除」。いわゆる、マイクロサービス化でした。

マイクロサービス化は“考古学”で考える

先ほど述べたように、マイクロサービス化の対象はメルペイリリース前から運用されていたシステムです。運用歴も比較的長く、度重なる仕様変更や特殊な対応により、データのバリエーションやロジックの複雑性は単純なコードリーディングで理解できる範囲を大きく超えていました。

こうした複雑なシステムを過去の経緯と紐付けて「コードがなぜこうなっているのか」などの開発背景を読み解き、現状を正しく理解することを“考古学”と呼びます。考古学は現状を正しく理解し、どのように・どのようなかたちに移行させるかを考える上でとても重要な考え方の1つでした。

さて、現状の把握と合わせて重要になるのが「進め方」です。

私たちが提供しているサービスは、今やお客さまの生活には欠かせない社会インフラの一つを担っているといっても過言ではありません。もちろん、サービスを止めてデータや機能を移行し、マイクロサービス化することも可能です。そうすれば、考慮すべきポイントが減り、難易度を大きく下げることができる。しかし、サービスを止める判断は、許容できません。

そこで、お客さまが当たり前のように使える状態を安定的に提供し続けられるよう、ユースケースに基づいたいくつかのフェーズに分けて開発やリリースを実施しました。また、リリース時は段階的なデータの移行やマイクロサービス側機能への処理の切り替えを行い、問題が起きたときに切り戻しができるようリスクヘッジもしました。

今振り返ると、ほとんどのフェーズでは優秀な開発チームとQAチームのおかげで切り戻しを行うことはありませんでした。でも、あるフェーズにおいて、既存ロジックを移行するだけでは機能実現が難しく、ほぼ0→1での機能開発と既存データを考慮しつつ、かけ合わせた処理および処理フローの切り替えが必要でした。このフェーズではリリース時に考慮しきれなかったデータや想定できていなかったエッジケースなどで問題を検知し、何度も切り戻しを実施。さらに止血し、調査・修正するといった、まるでいたちごっこのようなこともありました。ですが、切り戻しができるおかげで被害を最小限にとどめて、走り切ることができました。

また、個人的には技術的難易度や、やり切っておかないと予定されている新機能のリリースブロッカーになるためにデッドラインがあり、精神的にも厳しいフェーズでした。でも、Be a ProでAll for Oneなメンバーの動きがあったため、乗り切ることができたと思っています。

マイクロサービス化とサービス成長の両立

そんなマイクロサービス化をリリース当初から進めてきましたが、その間にもサービスの改善でよりUXを磨いたり、新機能開発などで新たな価値をお客さまに届けたりするなど、メルペイのミッション実現に向けて止めることはできません。

その中でも代表的なのが、2020年7月7日に提供を開始した「定額払い」です。これは「『お金が理由であきらめる』を無くす財布」をコンセプトに、「使いすぎ」「払い終わらない」といった支払いに関する問題を解消し、より安心してお買い物を楽しめることを目指したサービスです。

「定額払い」は、まだマイクロサービス化が未完成なときに開発を行う必要がありました。そのため、マイクロサービス化を担当するチームと定額払い担当チームで並行して進めました。（定額払いを他のマイクロサービスとして開発することも検討しましたが、あるべき姿を考えたときにこの判断は必然だったと思います）。まだないものを設計して開発することは不可能に近いので、できるだけ具体的な姿をチーム間で確認しながら同じ目線で進められるように意識しました。

そんな紆余曲折ありながらも、着実に進めてきたマイクロサービス化。約2年かけて、プロジェクトのゴールにしていたアーキテクチャに移行し、リリース当初から抱えていた問題を解決することができました！

これからも引き続き安定したサービス運用でお客さまに価値を届け、より一層のスピード感で「信用を創造して、なめらかな社会を創る」というメルペイのミッション実現に向けて邁進していきます！