Merpay Tech Fest 2022 は、事業との関わりから技術への興味を深め、プロダクトやサービスを支えるエンジニアリングを知ることができるお祭りで、2022年8月23日（火）からの3日間、開催しました。セッションでは、事業を支える組織・技術・課題などへの試行錯誤やアプローチを紹介していきました。
この記事は、「与信領域 Micro Service 小話」の書き起こしです。
@giga：今回僕たちから、与信領域のMicro Serviceの小話というテーマでパネルディスカッションし ていきたいと思います。よろしくお願いします。
自己紹介
@giga：僕は@gigaといいます。金融系のエンジニアや外資コンサル、クラウド会計の事業者を経てメルペイに入社しました。金融機関で働くことが多く、ブロックチェーンなどの先端テクノロジーも使っていました。今は与信事業という信用創造のプロダクト作りに邁進しています。よろしくお願いします。
@mitu：@mituです。今はメルペイで与信管理領域のバックエンドのテックリードをしています。スマホ向けゲームのバックエンドエンジニアとしてキャリアをスタートしました。2019年にはOrigamiに入社し、金融事業に携わりました。よろしくお願いします。
@shuuk：僕は現在与信のMLチームのマネージャーをしています。もともとWebエンジニアでしたが、AIコンサルとして転職し、その後はデータアナリストとしてメルペイに入社しました。さらにその後、MLエンジニアにジョブチェンジして現在に至ります。よろしくお願いします。
本日のテーマ
@giga：本日のテーマとして、与信領域のマイクロサービスの小話を3つあげています。
1つ目はメルペイの与信領域のマイクロサービスの歴史を振り返ること、2つ目はマイクロサービスの境界線を引く難しさや面白さにどんなものがあったのか、3つ目として手探りの経験から得られた学びや今後の展望をお伝えしたいと思います。
メルペイスマート払い、定額払いについて
@giga：早速お話しするにあたって、メルペイスマート払いやメルペイスマート払い（定額払い）の歴史に踏み込んでいきたいと思います。
メルペイスマート払いとは
@giga：僕らはメルペイスマート払いやメルペイスマート払い（定額払い）という形で、与信のサービスを提供しています。
メルペイスマート払いとは、クレジットカードに似たようなサービスです。メルカリで買い物をしたりお店でメルペイを使ったりしたときに、購入代金を後払いできます。
ご利用限度枠はお客さまごとに異なっており、金額を決定して利用できるようにするのが与信領域の仕事です。
メルペイスマート払いの変遷
@giga：続いて、メルペイスマート払いの変遷についてお話しします。
2019年4月にメルペイあと払いが生まれ、11月にメルペイスマート払いにリブランディングされました。これが、メルペイスマート払いのはじまりです。
2020年7月にはメルペイスマート払い（定額払い）が生まれ、分割払いができるようになりました。後にd払いやメルペイの共通QRコードが作られ、バーチャルカードも発行されました。
システムの裏側では、AI与信という機械学習を活用した与信の仕組みを作り、ライセンスを取得しています。これは、日本で僕たちメルペイにしかない仕組みです。
現在は、「また新しい与信を生み出していこう」というステージにいます。
メルペイスマート払いのAI活用
@giga：続いて、メルペイスマート払いのAI活用についてです。
メルカリ・メルペイでは過去の情報からお客さまの行動をインプットして、未払いになる確率をAIで算出して利用限度枠を決めています。
一括清算と定額清算
@giga：メルペイの清算方法はメルペイスマート払いとメルペイスマート払い（定額払い）でわかれており、利用の翌月に一括で支払うパターンと、数か月に分けて定額で支払うパターンの2つがあります。
お客さま目線では支払方法が変わるだけですが、システムの裏側では法令のカテゴリーが異なります。メルペイスマート払い（定額払い）では割賦販売法に基づいて指定信用情報機関とお客さま自身の信用情報や履歴を照会し、与信可能な利用限度枠を計算しています。
メルペイと与信領域のマイクロサービス
@giga：続いて、メルペイの与信領域のマイクロサービスがどのような構成になっているのかについてお話しします。
そもそもマイクロサービスとは
@giga：マイクロサービスは、ビジネスドメインごとに分割された独立してデプロイ可能なサービス群です。
サービス同士はネットワークを介して通信するので、マイクロサービス単体でサービスを形成するものもあれば、複数のものを結合してはじめて1つのサービスになるものもあります。分割した単位をまとめ、1つのサービスで構成されたシステムをモノリスと呼びます。
Code決済やiD決済など、図の中の四角い箱の単位はあくまでメルペイの決済領域のイメージです。実際はもっと細かいのですが、このような単位があるというイメージとして表示しています。
なぜマイクロサービスを採用するのか
@giga：では、どうしてマイクロサービスを採用するのでしょうか。一般論として、大きく2つの理由があると言われています。
1つはサービス同士の開発やデプロイ・リリースを個別にできるので、スケーラビリティが上がることです。開発スピードの向上や平行開発が実現できますし、マイクロサービスの単位が複数あることでチームごとにどのような技術を使うか、裁量の余地が生まれます。
もう1つは、複雑のドメインを分割してチームに割り当てられることです。1つのチームが責任を負えるドメインの粒度・大きさには限界があります。ほどよい単位に分割することで、それぞれチームごとの領域にフォーカスできます。
メルペイ開発初期には、大量のエンジニアが同時並行で金融ドメインを作っていました。しかし、内容がかなり複雑で分割してシステムを完成させる必要があったので、マイクロサービスの形がとられました。
与信領域のマイクロサービス構成（WIP含む）
@giga：上の図は、今後僕らが目指していくマイクロサービスの構成案で、大きく4つにわかれています。
AIが与信を行うCreditScoreや与信の金額計算を行うCreditLine、メルペイスマート払いの申し込みや利用者を管理するDeferredPay、法令に関わる指定信用情報機関に照会する、あるいは情報を登録するためのCreditInfoです。
システムの変遷〜それぞれの歴史のタイミングで何が起きたのか？
@giga：ここから歴史の話に戻り、変遷のタイミングでどのような問題が起きたか、また学びがあったかをお話しします。
先ほどお伝えしたように、メルペイあと払いが2019年4月から5月に、メルペイスマート払い（定額払い）が翌年7月に出来上がりました。それぞれのタイミングで何が起きたのかをお話ししていきます。
メルペイあと払いリリース
@giga：まずは、メルペイあと払いのリリースについてです。
ここでは、機械学習のモデルを活用して信用度を算出するフローを作ったり、一括清算で翌月払いの方式をとっていたり、ここで基礎となる与信の計算の仕組みをつくりました。
続いて、このときのシステム構成について見ていきます。
@giga：一見シンプルな構成に見えますが、どのような考えで作ったのでしょうか。
@shuuk：機械学習を用いてお客さまの信用度を予測するCreditScoreと、お客さまに利用限度枠を提供して利用していただくDefferedPayで構成されています。
CreditScoreが信用度をつくり、信用度を利用限度枠に変換する必要があるためこれを定期バッチで変換をします。定期的にDefferedPayのデータベースに流し込み、DefferedPayはそれを参照しつつ、リアルタイムの処理を加えた上で利用していただきます。
年齢や不正対策などリアルタイム判定したいものがあるので、DefferedPay側にも利用限度枠の修正ロジックが入っているのです。
@giga：今のお話は、上の図の吹き出し部分の通りです。シンプルな構成なので大きな問題もなく運用できていたと思うのですが、苦労したポイントはありますか。
@shuuk：最初はシンプルな構成に思えたのですが、お客さまの反応を見つつ機能やロジックを追加した結果、定期バッチが積み重なって巨大な定期バッチになってしまいました。
こちらはルールベースの処理で、MLエンジニアが得意とする機械学習の領域とはずれています。そのため、MLエンジニアとしてこれを運用し続けるのはつらいという話が出はじめました。
@mitu：バックエンド側では、運用における苦労よりマイクロサービスならではの難しさを感じました。
リアルタイムで見るべきもののバリデーションに必要な情報をDeferredPayが持っていない場合、他のサービスからゲットする必要があります。ですが、他のサービスのキャパシティ上限値を考慮するとリクエスト数に耐えられない場合もあり、別の方法でデータを取らなければなりませんでした。
メルペイスマート払い（定額払い）リリース
@giga：ここからはメルペイスマート払い（定額払い）のリリースについても話を伺いたいと思います。
メルペイスマート払い（定額払い）のリリースで起こったことは、割賦販売法に準拠したフローが必要になったことと、他社の借入状況を考慮した利用限度枠計算が必須になったことです。
このあたりもシステム構成ベースで見ていこうと思います。
@giga：メルペイスマート払い（定額払い）では、登場人物が増えました。これによって何が起きたかを聞かせてください。
@mitu：このタイミングでの大きなポイントは、CICの照会が必須化したことです。
CIC照会とは、CICに加盟している会員会社（クレジット会社等）との契約内容や支払い状況等の信用情報を確認できる制度です。
引用：https://www.cic.co.jp/mydata/index.html
@mitu：図の中で赤文字で示した部分がCIC照会に関わる部分です。
定期バッチやDeferredPayからCIC照会の依頼が来て、CreditInfoというマイクロサービスで依頼ベースでCIC照会を行うのが当時のプロセスでした。ですが、DeferredPayからのCIC照会依頼と定期バッチからの依頼は内容が違いましたし、定期バッチ側は利用限度枠について信用度による計算とCIC照会結果による計算の2つの軸が発生してしまい、ロジック的に所在が散財してしまうという問題がありました。
もともと定期バッチという信用度をベースに計算する大きなアーキテクチャがあり、メルペイスマート払い（定額払い）をリリースするタイミングで工数も削減しようとした結果、利用限度枠の計算を2つに分割して配置することにしたのです。これが、後々大きく響いてくる選択でした。
@giga：先ほどの図ではCreditScoreのところに定期バッチがありましたが、今回は枠から外れていますね。このあたりはCreditScoreチーム側で何か思うところとかあったのでしょうか。
@shuuk：もともと定期バッチが重かったのですが、法令要件を考慮しなきゃいけない、あるいはCICの照会者を抽出するロジックを作らなければいけない中で、とてつもなく巨大なバッチになることは目に見えていました。
MLチームでは工数的にもスキル的にも運用しきれないと考え、バックエンドにお願いできないかという話をしたのです。しかしバックエンドはバックエンドでCIC照会において大変複雑なプロトコルを解読する必要があり大変なので、間に設置しました。
当時の苦労話
@giga：ここからは苦労話に移りたいと思います。爆発しているところが3箇所くらいありますね。定期バッチはとくに爆発度合いが大きいです。
@mitu：定期バッチが宙に浮いてしまったことで、MLの人間もバックエンドの人間も関わる中途半端な立ち位置になってしまいました。
定期バッチは今までMLチームが改修していました。メンテナンスをし続けなければいけないのですが、MLチームだけでもバックエンドチームだけでも対応できません。そこでそれぞれのチームから1、2人を一時的にアサインし、暫定的な対応チームを作っていました。この対応方法は、1年くらい続いていましたね。
MLのドメインやCIC照会のドメイン自体大きいものなのですが、それに加えてお互いのドメインを理解しつつ定期バッチに手を加えなければならず、チームでの認知負荷の高さが問題になっていました。
また、暫定的なチームでの対応になるので、定期バッチをメンテナンスし続けるオーナーがいませんでした。依頼する人と依頼をこなす暫定チームがいて、対応するというサイクルを続けていて、中身だけを見ると悲惨な状態でしたね。
@shuuk：明確なオーナーがいないのでオペレーションで作業漏れが発生したり、インシデントが発生したときにお見合いになったりといった懸念がありました。個人の努力で カバーしましたが、組織的な動きが出来ていなかったと思います。
@giga：プロジェクトごとの暫定チームなので、リリースが終わったら解散するということですよね。
@shuuk：解散したのかどうかも定かではありません……。
@giga：メンバーがある程度固定であれば、過去の情報をもとにどうにかなるのかなと思います。メンバーが入れ替わってしまうとキャッチアップが大変ですが、固定すると属人性も出そうです。
@mitu：当時大きく問題にならなかったのは、対応を担当したのが僕と@shuukさんだけだったからです。僕たちの中だけで完結したからまだ何とかなりましたが、誰かを新たにアサインするとなるとやりづらかったのです。
僕たち以外をアサインするコストが高く、なかなか実行できませんでした。
現在（WIP含む）
@giga：メルペイスマート払い（定額払い）のリリースまではとても苦労されていたのですね。続いて、今後どうしていこうとしているのかについて触れていこうと思います。
具体的には、大きく2つあります。1つは、利用限度枠計算に責任を持つチームをつくること。もう1つは、複雑化したロジックやワークフローを整理することです。
ここはどのような課題から生まれたのでしょうか。チーム編成については、オーナーが不明だったというお話がありましたね。複雑化したロジックやワークフローについては、どのような問題がありましたか。
@mitu：基本的には定期バッチに対して1つのチームを立てるところからスタートしました。
定期バッチは利用限度枠の計算が大きな役割でした。かつそこに利用限度枠の計算というドメインのオーナーがいないという話になっていた結果、利用限度計算という1つのドメインに責任持つチームを作るという着地点に落ち着きました。
それを整理したときに、どうしても今のフローは無駄がありコミュニケーションパスが多いという課題があがり、フローもあわせて整理することになったのです。
@shuuk：利用限度枠の計算処理はよく見ると3カ所に分離しています。全部をにらみながらでないと設計もままならない状況でした。改修のコストもかなり高いですし、CIC照会をしなければならないCreditInfoが利用限度枠という別のドメインももっているので、QAするときに両方QAしなきゃいけないという工数の問題も出てきます。
@giga：せっかくマイクロサービス化したのに、それらをつなげないときれいにQAできないので開発負荷が上がる状態ですね。
@giga：それを踏まえてどうなるかというのが、この図ですね。CreditLineが増え、登場人物が4人になりました。ここで新しくCIC照会結果から結果を受け取って利用限度枠を計算するようになったのです。このあたりのポイントについても簡単に聞かせてください。
@mitu：基本は利用限度枠の計算がCreditLineという1つのマイクロサービスに収まっているのが大きなポイントです。利用限度枠の計算を1つのマイクロサービスに閉じ込めたことで、それぞれのマイクロサービスのやりとりがきれいにできるようになりました。
今回は抽象的に変えているところもあるので伝わりづらいと思うのですが、たとえばAPIのリクエストの流れなどはとてもきれいになっています。
CreditScoreが信用度予測に集中できる環境に着地できたことも大きいです。当初のメルペイあと払いのリリース時からモヤモヤを抱えていた状態でしたが、本来あるべき姿にだいぶ近づきました。
@giga：ここに至った最後の姿はきれいだと思うのですが、いろいろと手探りで行ってきたこともあると思います。その部分についてお話を伺いたいと思います。
問題解決のためにやったこと
@giga：メルペイスマート払い（定額払い）のリリース時はいろいろな問題が起きていたと伺いました。その中でもいろいろ対応されてきたと伺いましたが、このあたりはどのような課題認識から対応を行ったのでしょうか。
@mitu：問題を認知してから半年くらいは、組織としてこうしたいという話をしてもなかなかタイミングが取れない状態が続きました。リスクに関する話題については、ちょこちょこ周りにコミュニケーションをとりながら共有していましたね。「組織的に法令違反やレピュテーションのリスクが起きてしまうのでこのように解決したい」という意見をボトムアップで相談しました。
その結果、CTOなどトップダウンに落としこめる立ち位置の人を巻き込みつつ、うまく対応できたと思います。最終的に@shuukさんに巻き取ってもらいましたが、そのあたりはいかがでしたか？
@shuuk：エンジニアだけであたふたしていても前に進まないので、ビジネス部門にも相談しました。ただ、たとえばマイクロサービスの話はエンジニアなら理解できますが、ビジネス部門ですとそのような用語を使ったコミュニケーションが取りづらいです。そのため、法令違反など相手が理解できる言葉でリスクを説明するように心がけました。
@mitu：共通言語で語るのは大切ですね。当時はチームとして動いてなかったので、メルペイではPMを軸にプロジェクトを回すことが多いのですが、今回の場合暫定チームなのでPMがいなかったのです。とりあえずPMを当ててほしいと思っていたところ、@gigaさんが今年の年始に入社されて動きやすくなりましたね。
学びから得られたアンチパターン
@giga：続いて、どのような教訓や反省があったのか振り返っていただければなと思います。
@mitu：得られた学びは、大きく3つあります。
1つ目が、開発領域・技術だけの境界線だけではダメだということです。
今回は、歴史の中で、メルペイあと払いリリース・メルペイスマート払い（定額払い）リリース・現在の3つのポイントについて解説しました。メルペイあと払いリリースではドメインの規模が小さかったので、開発領域・技術だけの境界線でもうまく回りました。
しかしメルペイスマート払い（定額払い）のリリースでは、MLチームはMLだけ、バックエンドチームはバックエンドだけという思想が働いたところ、先ほど紹介したような問題が起こってしまいました。
ドメインはMLやバックエンドだけではなく、ビジネスなど大きな組織の流れの中で構成されているので、組織の構造とセットで考えた方がうまく回るケースが多いのです。
2つ目も、メルペイスマート払い（定額払い）のリリース時に起こった問題です。締め切りドリブンによって、既存の機能を流用しつつ新しいものを一時的に増やしました。当時は一時的なつもりはなかったと思いますが、結果として暫定的に増やしてしまい、境界線が曖昧なまま改修を進めてしまいました。
タイミングの問題があるので、それが絶対的な悪ではありません。ですが、これが負債だと認識した上で対応することが大事だと思います。
3つ目は、とにかくドメインのオーナーはきちんとつけようという話です。暫定対応が重なるといいことがないので定点的に観測していく仕組みを作るべきですし、なければボトムアップ的に声を上げられる組織を作ることが大切です。
@giga：はじめから構成をきれいに作れることはなくて、試行錯誤しながらやってきたのだと思います。
その中でオーナーが不在になる状況が発生する、自分たちのやりたいところベースで境界線を引こうとしてもきれいにはまらない、どこも手一杯なのでどこに載せるかを締め切りベースで決めるときれいにはまらないという問題があるのですね。
（Appendix）境界線を決める観点
@shuuk：境界線のお話を扱っている、チームトポロジーという書籍があります。有名なので知ってる方も多いと思います。
まさにチームやシステム境界をどうやって引くのかという話が載っており、いろいろな観点について解説しています。僕たちがメルペイスマート払いを開発していた当時は出版されていませんでしたが、もっと早く読んでおきたかったですね。興味のある方は、ぜひ読んでみてください。
参考資料：チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計
登壇者から一言
@shuuk：マイクロサービスはクラス設計と違って人や組織の話が必ず絡み、観点も非常に多岐にわたります。正直「正解」はないのかなと思いますし、試行錯誤しなければならないのは仕方ないと感じます。
一方で、このようなアンチパターンをあらかじめ知っておくことで、試行錯誤の回数を減らして効率的にシステムを開発できると思います。皆さんの参考になる部分があれば幸いです。
@mitu：必ずしも「これ」という正解はないと思います。ただ、マイクロサービスはエンジニア寄りの話になりがちですが、会社・組織としてあるべき姿にしていこうとする姿勢はとても重要だと感じました。
ボトムアップで声を上げていくことはもちろん、トップ側から声をかけてもらえる体制がとても充実しており、僕たちがあげた声をきちんと拾って頂けたのは大きかったです。いい方法を提示できたかわかりませんが、少しでも参考になれば嬉しいです。
@giga：僕は、メルペイスマート払いの歴史の中でいろいろな葛藤があったと知れただけでも、学びになったと思います。手探りで正解に近づいて頑張ってリリースしたことは素直にすごいと思いますし、最後までやり切ったという点は非常に尊敬します。
与信はお客さま個人向けものから法人向けのものまであり、正解のない世界だと思います。マイクロサービスの境界に正解はないという話がありましたが、それぞれ不確実の中で進めていかなければなりません。僕も強いオーナーシップとミッションを持ってやり切る意思を持って臨んでいきたいと思います。
@giga：セッションは以上です。ご清聴ありがとうございました。
