開発チームはどのように「メルカード」の仕組みを実現したのか　カードネットワークの組み込みと、情報取り扱いに対する工夫

メルカードチームとして開発したもの

t-iwamoto（以下、t-iwamoto）：裏側の仕組みや技術的なところ（の話も）含めて、次はバックエンドのエンジニアのshiwakuさんから「メルカード」のバックエンドの舞台裏みたいなところの説明をしてもらいます。じゃあshiwakuさん、お願いしまーす。

yuichi.shiwaku氏（以下、yuichi.shiwaku）：メルカードのバックエンドのドライバーみたいなところで、バックエンドエンジニアのshiwakuが、いくつかかいつまんで説明させてもらえればと思います。

本日提示している資料ですが、2022年末のアドベントカレンダーで、メルカリエンジニアリングブログに今日参加しているメルカードのメンバー以外に、関連した開発を行なってもらった決済基盤部分の拡張の話や、先ほど（話が）あった「常時還元プログラム」の話も一連のシリーズとして掲載しているので、気になった方はそちらを後ほどチェックしてもらえればと思います。

では軽く、メルカリのチームで取り扱った部分を中心に紹介させてもらえればと思っています。今回開発したサービスは、先ほどのプロダクトの紹介の中でも何度か話題に上がっていた部分で、コード決済、ネット決済など、さまざまな決済手段を提供していることが説明されていました。

（画面を示して）メルペイ、特に我々メルカードチーム（が開発した機能）や、コード決済などが提供している、かなりざっくりとした開発のコンポーネント、サービスのイメージはこのようになっています。（※1）

先ほど言っていた与信管理や、メルカリの売上を取り扱うレイヤーが一番下にあるのですが、それらと我々メルカードなどのコード決済の間には、決済基盤というかなり巨大な仕組みが用意されています。そこがさまざまな処理を担ってくれていることで、コード決済、メルカード、履歴といったところに、共通のお客さま体験を提供するための共通な仕組みとして存在しています。

今回、我々メルカードチームとして開発したコンポーネントは、この決済基盤をメルカードの仕組みを実現するために追加開発をしてもらうみたいなところの上に乗っかっていて、コード決済、ネット決済、そしてすでに提供したiD決済、バーチャルカードに加え、物理カードであるメルカードの決済システムを乗せたかたちになっています。

エンジニアの方だとメルカリの開発体制は何度か聞いていたりすることもあるかと思うのですが、メルペイ・メルカリはマイクロサービスアーキテクチャを採用しているので、メルカードはその中の1つの新しいマイクロサービスとして開発を行いました。

“ナンバーレス”をどのように実現したか

（スライドを示して）ナンバーレスカードのサービスを提供するところは今回我々も取り組んでいて、その中ではカード情報をメルカリのアプリやメルペイの中でどういうふうに取り扱うのかという話が、けっこう大きい課題になってきます。

今回に関しては、カード情報を取り扱う会社の「プロセッサー」といわれているレイヤーと提携して、そちらの独自のAPIを提供してもらって、メルペイの中でカード情報を表示するかたちで提供を実現しています。

なのでメルペイとしては、カード情報という生のものを極力取り扱ったりはしないように、システムとしては保存せず、あくまでもお客さまの端末上で表示するところにとどめることで、機能の実現を図っています。

先ほど（お話しの）あった、申し込みから利用開始のところで、アクティベートしてから使えるようにすることを実現しています。

配送に関して、メルカードは通常の配送手段として普通郵便を使っているのですが、お客さまの手元に（カードが）ちゃんと届いて、本人確認ができたアプリ上で有効化しないと利用できないということを機能として提供することで、「安全に配送できますよ」というところを実現しています。

カードネットワークをどのように組み込んだのか

今回提供しているクレジットカード機能みたいな部分ですが、概要はクレジットカード取引のメルカードの記事（部分）でざっくりと解説してもらっています。（※2）

今日解説したいところは、カードネットワークをメルカードで新たに組み込んだのかみたいな話です。（視聴者の方としても）そこが気になる部分だったかもしれないので、軽く既存のものとの比較を置いています。実はメルペイに関しては、リリース当初から提供しているiD決済がほぼ似たような同様のサービス、仕組みとしては提供されていました。

ただ今回に関しては、それらはリリース当初の要件に従ってある程度実装されていたり、特にiDの決済に特化して実装されている部分・設計されている部分があったので、メルカードに関しては今回新たなサービスとして新規に設計・開発は行うかたちを採りました。

（画面を示して）こういったかたちで、メルペイは細かくマイクロサービスを立ち上げたりするのですが、それを支える（ものを）普通に開発しようとした時に、マイクロサービス立ち上げる、1つのサービスを立ち上げるのはけっこう大きなコストがかかるし、運用上の課題を持つ方が多いと思います。メルペイのマイクロサービスの立ち上げを支える仕組みみたいなところ（の話）が、Vol. 4の記事に記載されています。（※3）

どういった取り組みをしているのかという内容を記事でまとめてもらっています。まずメルペイの開発プロセスを立ち上げる時に「新しいサービスを立ち上げるのか」「アーキテクチャをどうしましょうか」みたいなことをディスカッションするためのベースとして、Design Docという資料を作成して、それを基に他のチームのレビューや既存のサービスとの比較をして、大まかな設計を進めていきます。

この際にセキュリティチームなどとのレビューを行うので、特にカード情報の取り扱いとか、先ほどあった「メルペイではどこまで取り扱うようにして、それをどういうふうに実現していくのか」みたいなところ。特にCSとのオペレーション（の視点）で「どうしましょうか」みたいなところまでレビューを行って、設計を進めていくかたちにしています。

それができたら次はマイクロサービスを立ち上げていくのですが、1から全部ゼロイチで立ち上げようとするとなかなかコストがかかって大変なので、メルカリもメルペイもそうですが、メルペイの社内ではmercari-echo-jpというボイラーテンプレートに相当するプロジェクトが用意されていて、その中で共通基盤をどんどん拡張していくような、共通の機能やログの設計がデフォルトのものとしてセットされています。

それらをベースに立ち上げていくかたちになっていて、最初から全部ゼロイチで立ち上げるのではなくて、最初からロジックを書けるぐらいまで整備が整っています。

あとはコードレビューをどうしたのかみたいなところになってくるんですが、けっこう特徴的な部分としては、自動テストやそれを実現するためのプルリクエストを立ち上げるとテスト環境が自動で立ち上がるようなところが環境として整備されているので、かなりスムーズに開発やQAができるようになってきています。

というところで、どういったかたちで新しいサービスを立ち上げたのか、メルペイで取り組んでいるものがこの資料で網羅されているかなと思うので、チェックしてもらえればと思います。

ちょっと時間が長くなってしまいましたが、開発としては以上とします。

t-iwamoto：はい。shiwakuさんありがとうございます。

文中の※の記事はこちらです。※1　https://engineering.mercari.com/blog/entry/20221202-mercard-behind-the-scenes-02/※2　https://engineering.mercari.com/blog/entry/20221203-mercard-behind-the-scenes-03/※3　https://engineering.mercari.com/blog/entry/20221204-mercard-behind-the-scenes-04/