「GMO-PG プロセシングプラットフォーム」導入の舞台裏【GMO Developers Day 2022】

自己紹介

このお時間ではGMOペイメントゲートウェイが展開しているサービスの一つでもあります、GMO-PG プロセシングプラットフォームのお話をさせていただければと思います。

まず初めに自己紹介をさせていただきます。わたしはソウトメトオルと申します。よろしくお願いいたします。2019年1月に中途にてGMOペイメントゲートウェイに入社いたしました。
前職ではSIerとして決済システムに関わっておりましたので、日本最大規模の決済代行システム会社であるGMOペイメントゲートウェイに縁を感じ、入社させていただきました。
入社後はアクワイアリングプロセシングの開発・保守運用をやらせていただきまして、そこからもうすぐ4年となりますが、同じシステムの面倒をみております。
得意な領域を記載させていただきましたが、新卒からずっと決済のシステムに関わっているのもあり、基本的に決済システムは高パフォーマンスのため、そのバックエンドAPIの開発ばかりやっていたという過去背景からバックエンドAPI開発と記載させていただいています。

本日のお話すること

メインテーマ

本日のメインテーマに関してお話します。
近年とてもカード決済は身近になったと思います。ECサイトではクレジットカード決済は当たり前にありますし、コンビニやスーパーは都内ではどのお店でもクレジットカード決済が行えるようになっています。
それに伴いカード会社も年々増えてきています。
実際カードを作る際にどの会社でカードを作ろうか皆様も悩むと思います。ただカード会社様増えているからといっても、そのシステム基盤を支えている会社は意外にも多くはありません。
当社GMOペイメントゲートウェイですが、プロセシングプラットフォームと言うサービスでカード会社のシステム基盤を支えている会社の一つでもあります。そんなプロセシングプラットフォームを導入する際の裏側で何が発生して、どのように解決していったか可能な限り体験談を交えてお話させていただければと思っています。

アジェンダ

アジェンダです。
先ほどからプロセシングという言葉を使っておりますが、そもそもプロセシングとは何か？という前提の話をさせていただき、当社のGMO-PGプロセシングプラットフォーム導入の流れをお話します。
先ほどの自己紹介でアクワイアリングプロセシングシステムを担当していますとお話しましたが、私が担当しているアクワイアリングシステムでの導入の話がメインとなります。
次に導入時の課題とその解決方法を、具体例を挙げてお話させていただきまして、最後にまとめとします。

プロセシングとは？

カード会社とは

まずはカード会社について説明させていただきます。
こちらがカード会社の全体図となります。
左から加盟店（お店）です。そこからはじまりアクワイアラ、国際ブランド、イシュア、皆様一般ユーザーが会員になります。
カード会社は真ん中の青い部分のアクワイアラとイシュアの業務を行っています。
イシュアは会員獲得だったりカード発行をする業務になるので、皆様になじみが深くぱっとカード会社というと頭に浮かぶのはだいたいイシュアのことになります。
対してアクワイアラは加盟店を獲得し、審査をする業務になります。
加盟店というのはお店のことです。平たくいうとカード決済ができるお店を管理監督する役割を持つのがアクワイアラです。各アクワイアラと各イシュアを結んでいる国際ブランドがいますが、これが皆様の良く知るVisaやMastercardと言ったグローバル企業になります。
このような構成でカード会社が成り立っています。

プロセシングとは

肝心のプロセシングとは何かと言うところですが、アクワイアリングやイシュイングがカード決済事業を遂行するために、「各種必要な機能群を提供運用すること」になります。
ここの定義は各社微妙に異なるため当社定義です。本日はこれを前提に進めていきます。

アクワイアリングシステム提供サービス

その中でも私たちはカード会社のシステムを提供させていただいております。
アクワイアリングシステムで具体例を説明させていただきます。
アクワイアリングシステムで提供しているサービスは大きく４つあります。

１点目がオーソリ機能です。
詳細は割愛しますが、カードの与信枠を抑える業務をオーソリといいます。カードが利用できるかできないかを審査する業務となります。カードの審査情報を持つのはイシュアなのでアクワイアラは審査できない、というところでアクワイアラとしてはイシュアに審査してもらう情報を流す、そんなような仕組みです。

２点目は売上機能となります。
オーソリはあくまで枠の確保のため、枠を確定させるためにバッチ処理にてファイルを使った確定処理を行っています。

3点目がバックオフィス機能となります。
加盟店の管理を行っているため、それに必要な管理機能の提供であったり、国際ブランドとの精算業務、または加盟店との精算業務といった機能もご用意しています。

4点目は加盟店向けWEB画面です。
加盟店が取引や精算を確認するためのWEB画面の提供も行っております。

GMO-PG プロセシングPF

アクワイアリングサービスの具体例をご説明したので、当社のGMO-PGプロセシングプラットフォーム全体の話もさせてください。
金融機関や金融サービス事業者がカード事業を始めるに辺り、先ほどの国際ブランドとのNWの構築やアプリケーションの作成が必要になり、システムを一から構築するのでは時間もお金もかかり過ぎてしまいます。
しかし、当社のプラットフォームをご利用いただくことで、簡単に柔軟で効率的に決済インフラが構築でき、事業の展開に時間やお金を集中していただくことが可能となります。
右下の図にもありますが、当社のプラットフォームは様々なサービスを提供していて、私がシステムを担当しているアクワイアリングはもちろん、クレジットカード、デビッドカード、プリペイドカードといったカード券種ごとのサービスもあります。
また、既に基幹システムを持つ事業者に対してはゲートウェイやFEPといったサービスにより、基幹システムへの影響を最小限にしたシステムを構築することが可能となっています。

プロセシングPF導入の流れ

PJ計画

次に、GMO-PGプロセシングプラットフォームの導入の流れに関してお話します。
導入プロジェクト計画は図の通り、全体で半年から1年ほどかけて行います。キックオフから始まり、FIT&GAP、要件定義を行い、設計、開発、テストの上でリリースとなります。
システム開発においては凄く一般的な流れですね。プラットフォームではありますが、カード会社それぞれにやりたいことや考え方というのは異なりますので、そこのギャップを吸収するための開発期間が必ず発生します。これにだいたい3ヶ月～6ヶ月かけて行います。
そして開発が完了した後は対外向けのテストを行い、カード会社がカード事業を進めておくにおいて問題ないか確認していきます。これにだいたい3ヶ月～6ヶ月ぐらい期間が掛かります。
この工程ですが、注目いただきたいのはオレンジ色の「ブランド加盟店接続テスト」というところでこれがカード事業特有になるかなとは思いますので、少しだけ詳細を説明します。

ブランド接続テスト

ブランド接続テストとは何なのか？という点ですが、国際ブランド、VisaやMastercardと接続するには認定試験が必要になります。
下の図にもありますが、アクワイアラは各国に存在していて、イシュアも各国に存在しています。オレンジ色が私が担当しているアクワイアリングシステムだとして、イシュアは日本、イギリス、インド、その他諸々の会社と接続があります。国際ブランドと接続可能となることは世界中のカード会社と接続可能状態となるので、身元不明のよくわからないカード会社を勝手に接続するとこはできないため、認定テストを実施し、国際ブランドが規定したシステム規約に沿ったシステムが組めているかをテストします。

加盟店接続テスト

加盟店接続テストに関して説明します。先ほどのブランド接続テストとほぼ同じ話になります。
加盟店とアクワイアラの接続の間にもNW事業者がいます。これはグローバルではなく国内のNW事業者です。そのNW事業者とアクワイアラが接続することで日本全国の加盟店と接続が可能となります。加盟店をアクワイアラが探し、その加盟店と協力して、問題なくカード決済が出来るかのテストを行います。

導入時の課題と解決方法

導入時の課題

これまでプロセシングについて説明させていただきましたが、ここから本題になります。
私はあるお客様の導入の初めからリリースまで携わらせていただいたので、そこで発生した実際の課題と解決方法を2つご紹介します。

1点目は出揃わない要件、伸びるFIT&GAPというものです。
こちらは開発プロセスを見直すことで対応した話です。
2点目は"前例"との闘いです。
こちらは課題の本質はどこか？というところを見極め対応しました。

出揃わない要件、伸びるFIT&GAP

一つ目の出揃わない要件、伸びるFIT&GAPとなります。
システム開発を行っているとよく発生するかと思いますが、弊社GMO-PGプロセシングプラットフォームでの実際の解決事例をご説明させていただきます。

アクワイアリング導入の流れとして、FIT＆GAP、設計、開発と続くと先ほど説明いたしましたが、約半年かけて開発を行うスケジュールを当初立てていたプロジェクトでした。プロジェクト開始から1ヶ月以上が経過したところ、気が付けば半分も進んでおらず、3ヶ月はかかるなーという見込みとなっていました。
理由は様々でしたが、カード会社業務は幅が広いため、システム内容を細かく説明するには時間がかかりますし、その中で発生したGAPをどうシステムに落とし込んで解決するかといった非常に前向きな議題に花をさかせていました。
ですが、右下にもある通り、スケジュールの延期と言うのも中々厳しい状況でした。皆さんこの辺りはご経験があるかと思います。
FIT&GAPお客様とで非常にシステムよりの話が出来ていたので、何とか間に合うように動けないかと私は考えに考えました。

ウォーターフォール型開発からスパイラル型開発へ

考えた結果、開発手法に目を付け解決の糸口を見つけようとしました。従来プロセシングサービスはウォーターフォール型で開発を行っていましたので、要件定義の遅れはスケジュールの遅れに直結するものでした。
ウォーターフォール型と言うのは、要件定義、設計、開発、テストを滝のように各工程を上から順番に行っていく開発手法となります。かといってアジャイルのように細かいリリースを行えるわけでもなかったので、開発手法を調べていると、スパイラル型開発の手法があることを知りました。
スパイラル型開発とは要件定義、設計、開発、テストをぐるぐる繰り返して行う開発手法となり、アジャイルと非常に似ているものの、部品毎の開発がまとまり、より品質が高い状態でリリースする手法になります。

先ほども申しあげましたがシステムに落とし込むところはお客様と会話ができていたので決まった要件から部分的に開発をして品質を高めながら、最後に集合させてリリースできるのではないかというところを若干、見切り発車的にスパイラル型開発に挑みました。

出揃わない要件、伸びるFIT＆GAP

そして実際にはこのように進めていきました。
結局FIT＆GAPは3ヶ月どころか半年ほどかかりました。要件がある程度出揃ったタイミングで機能別に落とし込み開発計画を練っていく、という形でどんどん進み、半年ほどで開発は完了しました。
図では少し分かりやすいように記載していますが、実際はサイクルがもっと多段階あったと記憶しています。

得られたことと難しかったことを簡単にご紹介します。
得られたことは先ほどの通り、上流工程に引っ張られないでスケジュール遅延なく開発が完了しました。
最大かつ唯一のメリットです。

難しかったこととしては3点です。
まずはスケジュール管理です。先ほど図でも少し載せていましたが、テストをしているうちに次の設計に入っていますので、開発が次から次へと押し寄せてきまして、一つのサイクルが遅れた際に、後続工程への影響が出てしまうので、スケジュール管理を厳密にしなければならず、課題が出たら即解消に向けたアクションを取る必要がありました。

2つ目はコスト管理です。
スパイラル開発はコストがかさむということは事前に調べて分かっていました。それはサイクル単位で工程を繰り返すので、サイクルが増えれば増えるほど二重で同じテスト等が発生するからです。
私は可能な限り二重テストを減らすため、リグレッションテストを実施するタイミングを整理したり、なるべくコストが膨らまず必要な分だけ行えるように緻密な調節をしました。

最後にブランチ管理です。
急にシステム的な話になりますが、開発が並行して走る場合もあるので、サイクル単位での開発内容を誤ると競合が発生します。そのため開発機能を徹底管理する必要がありました。管理というところを適切に行うためには、システムへの深い理解が必要でしたので、ここも非常に苦労しました。

"前例"、"慣習"との闘い

前例との戦いです。
カード決済は他の決済手段に比べると非常に歴史が長いです。最初にも申しましたが、ある程度普及しているので別のアクワイアラとすでに接続している加盟店が違うアクワイアラに切り替わるパターンもあります。これをカード切り替えと言います。この際に前例が発生します。

今回起こったのは、加盟店管理方法の前例です。加盟店を管理するということは様々なことを考慮する必要があります。システムでわかりやすく言うとユーザー管理の仕組みがそれに近しいかと思います。加盟店管理はカード会社ごとに異なります。

真ん中のビルをある店舗だとします。店舗全体を加盟店として管理するカード会社もいれば一階、二階のフロア単位に管理するカード会社もいます。また、入居テナント単位で管理するカード会社もいます。
大きな単位で加盟店を管理することで一元的に管理できるので管理業務が少なくて済むメリットはあるのですが細かい管理ができないデメリットがあります。
小さい単位で加盟店を管理することで細かいこところまで管理が行き届くメリットはあるのですが逆に管理が煩雑になるデメリットがあります。加盟店の管理はこうやってメリットデメリットのバランスを取り合ってやります。
今回はオレンジ色に囲っていますが、店舗単位での加盟店管理を行うことで決定しました。

ただ、蓋を開けてみると前のカード会社との違いがあることがだいぶ後半になってわかりました。前のカード会社は親加盟店とそれに紐づく子加盟店を管理できる階層構造になっていました。親加盟店に店舗を設定して子加盟店にはテナントを紐づける形です。
対して我々GMO-PGプロセシングプラットフォームは階層構造で管理ができずシンプルに店舗単位での管理しかできません。階層構造での管理は良し悪しがあって、ここではあまり触れませんがとにかくギャップを埋める必要がありました。大切なのはなんでこんな階層構造で管理をしているのか、こういう管理をすべきなのかという点です。
ここを深堀して現在のシステムに当てはめることはできないのか、というところを考えました。

深堀した結果、やりたいことは業種単位の管理だとわかりました。
例えば飲食店と高級洋服店ではカード決済の利用方法が全く異なるかと思います。わかりやすく言えば金額単位が全然違うので、だいたいのイメージで大丈夫です。我々はフロアごとに管理する方法をとりました。大きな店舗ならよくあると思うのですが、1Fは飲食、2Fは洋服店、そんな形です。
フロア単位で管理することによって前のカード会社と同等の管理が可能となるというところでした。このようにまったく前のカード会社と同じシステムではないので、どうしてもカード会社切り替えで変更点が出てしまうのですが、本質的にやりたいことを把握してそれを解決することも我々プラットフォーム提供者として行っています。

まとめ

最後にまとめをさせていただきます。
私がGMO-PGプロセシングプラットフォームを導入する際に心がけている２つのことがありますので、それを最後にまとめとしてご紹介させていただきます。

一つ目は「課題は必ず発生する。その時にどう動くかが大事」です。
GMO-PGプロセシングプラットフォームはカード事業を作るというところのため、非常に規模が大きいプロジェクトとなり、課題は必ずといってよいほど発生します。その時にどう動けばいいのか、と言うところを常に考えながらプロジェクトを推進しています。多少のことはなんとかなります。

二つ目は我々にできることは何だろうか、と考えることです。
課題の一つ目で話をしたケースだと、「要件定義で遅れたのでスケジュールを延期します」、と言うことはすごく簡単です。ただ、スケジュールはお客様の事業計画の上で成り立っているので、そこの遅延はお客様に多大な影響が出ます。そのため簡単に結論を出すのではなくてスケジュール内に収めるために我々にできることは何か、という最善策をまず考え、それに対して積極的に取り組みます。また、それをよしとする風土も弊社には存在しているので意見は通りやすい環境にあるかなと思っています。

以上でGMO-PGプロセシングプラットフォーム導入の舞台裏の話を終了とさせていただきます。今回は上流工程で発生した事象をまとめたのですが、下流工程でもいろいろ発生しましたのでその話はいつかどこかでさせていただければと思います。

ありがとうございました。

決済業界のリーディングカンパニーであるGMOペイメントゲートウェイでは金融機関様のBaaS支援のため、「GMO-PGプロセシングプラットフォーム」の提供を行っております。

※本コンテンツ内容の著作権は、GMOペイメントゲートウェイ株式会社に属します。