この記事は、Merpay Advent Calendar 2022 の25日目の記事です。

こんにちは。メルペイCTOのnozaq（@nozaq）です。
メルペイのシステムはマイクロサービスアーキテクチャを採用し、ドメインごとにサービスが分割されています。それに合わせて、エンジニアリングチームも関連するマイクロサービス群を担当する形でドメインごとにチームが組成されており、開発から運用までを一貫して担当しています。

本記事ではマイクロサービスアーキテクチャに合わせたプロダクト開発におけるチャレンジと、それに対するメルペイの取り組みについてご紹介します。

メルペイにおけるマイクロサービス開発

メルペイでは大きく決済事業（QRコード決済やクレジットカード決済など）と与信事業（あと払いや少額融資など）の2つの領域でサービスを運営しており、これらを提供するためのバックエンドシステムはマイクロサービスに細分化されています。例えば、QRコード・非接触IC・クレジットカードなど様々なインタフェースによる決済手段を提供するマイクロサービス、それらを横断する決済履歴管理、決済・与信で共通して利用される本人確認（KYC）といった横断的な機能を提供するサービスも存在します。各バックエンドチームは特定領域のマイクロサービス群を担当しており、開発〜運用までのオーナーシップを持っています。

なにか新しい機能開発を行う場合、どこか1つのチームだけで完結することもありますが、大規模なものになってくると複数のチームを跨いだプロジェクトとなることが一般的です。下図がその概要を示しており、ドメインごとに存在する各チームが縦軸（Function）、それらを跨いだ機能開発ごとのプロジェクトが横軸（Project）となっています。

図にも記載されている通り、エンジニアだけではなくプロダクトマネージャーも領域ごとに存在しています。各プロジェクトはそれぞれプロダクトマネージャーとエンジニアから構成される複数のドメインが並列して開発を行います。このような領域を跨いだプロジェクトが常に複数並行して開発されていますが、各チームがそれらを自分たちが管理するドメイン内の開発計画として独立して管理・推進することでプロダクト開発の並列度を高めています。

複数のドメインをまたいだプロジェクトのチャレンジ

サービスを複数の領域に分割して管理することで、各チームはオーナーシップを持つ領域の開発・運用に集中できるようになります。この構造により各チームはドメイン知識を専門性高く獲得しやすくなっていく一方で、領域を横断した企画・開発で「各領域での仕様策定・設計が全体として整合しているか？」「ある領域での仕様変更が他の領域へ適切に連携されているか？悪影響を及ぼしていないか？」といった全体指揮が必要なチャレンジが新しく生まれてきます。

例えばメルペイでは今年11月に「メルカード」という物理的なクレジットカードの提供を開始しました（プレスリリース）。

メルカードのリリースにあたっては様々なチームが開発に関わりました。例えばクレジットカードネットワークの決済を処理するマイクロサービスの新規開発や、従来から提供していた「あと払い」機能でメルカードの決済を取り扱うための機能拡張、またメルカリの利用状況に応じた還元率管理や決済時の還元処理に関する開発などが並列して行われました。個別の事例紹介として連載企画：メルカードの舞台裏 – Mercard Behind the Scenes –でマイクロサービスごとの開発に関する記事が公開されています。

メルカードプロジェクトでは当然、メルカードに紐づく新しい機能に着目して開発が行われます。一方であと払いを担当する既存のマイクロサービスではその変更がどう影響するかを考える必要があります。決済領域を扱っているメンバーとあと払いを扱っているメンバーが連携して仕様策定・設計を行ったり、情報連携を漏らさずに行うためにお互いの領域における懸念事項の相互理解が求められます。それぞれの領域が完全に独立して開発できるのが理想ではありますが、密な連携が発生するケースをゼロにすることはできません。例外的な連携が求められるケースでの情報の取りこぼしが起きないように気をつける必要がでてきます。

サービス・システムを俯瞰すべき他部門連携のチャレンジ

プロダクト・エンジニアリング組織内のコミュニケーション以外にも、他部門とのやり取りにおいてもチャレンジは存在します。上述したメルカードの例では、メルカードを使った決済はあと払いとなるので、割賦販売法という法律の要件を満たす必要があります。この確認はコンプライアンスチームが担当しました。ここで確認すべき事項は「決済が起きた際の処理」などに留まらず、メルカードの申し込み・審査・利用・請求などサービス・UX全体を通して「メルカードによるあと払い」が法要件を満たしているか？といった幅広いものになります。メルカードプロジェクト内にはこれを開発するドメインが複数に分かれていますが、コンプライアンス確認ではあくまでサービス全体を見ていくために情報の取りこぼしがないように担当の割り振りや情報の再統合をしていく必要があります。

別の例としては、運用時のシステムリスク管理が挙げられます。メルペイでは金融サービスを提供する上で可用性の維持をはじめとする高い運用品質が求められるため、システムリスクの管理を高度化していくためのIT Riskチームをエンジニアリング部門とは別に設置しています。IT Riskチームはメルペイのシステム全体のうちリスクが高い部分はどこなのか、サービスの成長に合わせてシステムのキャパシティが適切に増強されているか、発生した障害が適切に振り返られてシステムの改善につなげられているか、などを分析したりエンジニアリングチームと共に課題の改善に取り組んだりしています。ここでもIT Riskチームとしては「メルペイのシステム全体」を分析対象とするのに対して、エンジニアリング部門としてはマイクロサービスごとにオーナーシップが分散しているため、横断した分析を行うためには全チームとコミュニケーションを取っていく必要があり範囲を絞らないと非常にコストが高い取り組みとなってしまいます。

マイクロサービスが非効率なのか？

こういったチャレンジを眺めた時に、「マイクロサービスだから全体を見渡すのが大変なのではないか、例えばモノリスにしたら解決するのか？」という疑問が自然に湧いてきますし、実際にメルペイ内でもこういった問いかけがなされることはあります。そもそもマイクロサービスで得られているメリットは何でしょうか？

メルペイでは複数の金融事業を提供していますが、メルカリの売上金を使った決済サービスは資金決済法、あと払いサービスでは割賦販売法、融資サービスでは貸金業法などそれぞれの事業で異なる法要件が存在し、それらはプロダクト・システムにおける満たすべき重要な制約事項です。システムをサービス分割し、それぞれに対してオーナーシップを持ったチームを配置することで多くのケースにおいて機能開発・拡張といった変更の影響をサービス内に閉じ込めることで決済サービスの変更が融資サービスへ影響を与えないような仕組みになり、また各チームはオーナーシップを持つ領域に関する深いドメイン知識を蓄えていくことができています。こういった明確なドメイン境界が無ければある変更が及ぼす影響を捉えることがより難しくなり、開発の独立性やスピードが著しく落ちてしまうことが予測できます。

それを踏まえると異なる複数の金融事業を営んでいるというドメインの複雑性を適切に取り扱い、ある程度大規模な組織において開発並列度をあげていく上で、ドメインを分割していくこと自体は必要な取り組みです（「マイクロサービス」いう形かどうかは別としても）。「ドメインごとの独立性を維持しながら、分散された情報をどう再集約していくか？」というのはメルペイの事業複雑性・組織規模に対して本質的なチャレンジだと考えられます。

メルペイでの取り組み

ここでは情報を再集約していくための私たちの取り組みをいくつかご紹介したいと思います。

まず組織面での取り組みとして、2023年よりドメインを担当するプロダクトマネージャー・エンジニアを含むチームを「プログラム」というより大きい単位のバーチャルチームとして集約し、プログラムごとにプロダクト・エンジニアリングのリーダーをアサインする体制への移行を予定しています（下図）。

図内でJourneyと名前がついているものが決済サービスや与信サービスなどの関連するお客さま体験を集めたプログラム、それらに対して共通機能を提供するプログラムがFoundationやEnablingです。マイクロサービスにオーナーシップを持っている各チームは変わらず存在しており、各プログラムに所属します。ロードマップの管理やプロジェクトの推進をこのプログラム単位で行っていくことで、関連する領域内での情報集約を行いやすく、また他部門とのコミュニケーション起点を取りまとめやすくする効果を期待しています。この取り組みについては Towards the new Product & Engineering at Merpay – 5th anniversary editionでも詳しく紹介されています。

また、マイクロサービスを横断した分析を容易にするための取り組みとしては各マイクロサービスの情報を集約・可視化する社内システムを開発しています。【書き起こし】Microservice Dashboard Introduction and Deep Dive – Yuta Uekusa【Merpay Tech Fest 2022】でも詳しく説明されていますが、各マイクロサービスがどのような情報を取り扱っているか・依存しているサービスはなにか・SLOはどのように設定されているか・担当チームはどこか・どの程度のコストがかかっているか、といったメタデータを集約したダッシュボードが2019年から開発されており、様々なニーズに合わせて継続的に機能拡充されています。

関連するトピックとして金融サービスでは定期的に実行されるバッチ処理が業務上の重要な役割を担っているケースが多く、マイクロサービスの集約とは別にバッチ処理に関する情報の自動集約も今後取り組んでいく計画が立てられています。

最後に、システム障害などのインシデント対応についてプロダクト・エンジニアリング組織全体でレビューを行っていくためのバーチャルチーム・会議体を設置しました。基本的にインシデント対応は担当チームで完結して行われることが多く、振り返りの内容もチームの外には出ない事が多かったのですが、チーム横断で発生しがちなインシデントの共通傾向はあるだろうか？メルペイ全体として高まっているリスクはないか？といった俯瞰的な分析を「インシデント」という軸で情報を再集約することで行えるようになってきました。この取り組みについては メルペイにおけるインシデントマネジメントとナレッジシェア で詳しく紹介されていますのでそちらもご参照ください。

おわりに

最後まで読んでいただきありがとうございました。

本記事ではメルペイにおいてサービスを切り分けていくことで事業の複雑さ・開発の並列化を実現すると共に、そこから生じるチャレンジを重要な分析軸を定めて情報を再集約していくことで解決しようとしている取り組みについて紹介しました。プロダクト開発に取り組む組織の方々にとって何かの参考になれば幸いです。

メルペイではソフトウェアエンジニア・プロダクトマネージャーや、本記事で紹介したIT Riskチームメンバーなども募集しておりますので、ご興味ある方はぜひキャリアページもご確認ください。

それでは皆様、メリークリスマス & 良いお年を！