Powered by

「GMO掛け払い」新規プロジェクト立ち上げからローンチまでの軌跡【DevelopersNight #24】

article-040_top.jpg

2021年6月15日に開催しました 「Developers Night #24 キャッシュレス決済サービス 開発者が語るサービスの裏側」のSession3「「GMO掛け払い」新規プロジェクト立ち上げからローンチまでの軌跡」をお届けします。

動画はこちららかご覧いただけます:https://youtu.be/LGkufGI5RO0

GMOペイメントゲートウェイ 後払いGr 担当課長 河合
システムインテグレーター7年勤務後、GMOペイメントゲートウェイに入社し10年。

GMOペイメントゲートウェイ 後払いGr 宮山
新卒でシステム受託開発の会社に入社し、5年間常駐勤務。その後、広告系の事業会社にて新規プロダクトを2つローンチ。現在はGMOペイメントゲートウェイ掛け払いチームの開発担当。

article-040_thumb01.jpg

河合 では、サービスの紹介をしたいと思います。まず掛け払いという言葉ですけれども、一般的に買い物をするときにはあまり出てこない言葉なので、掛け払いの説明をしたいと思います。掛け払いというのは、先に商品やサービスを提供して後で支払ってもらうという支払い方法です。企業間においては一般的な支払い方になります。
私の前職がシステムインテグレーターで大体が客先常駐という形をとっておりますので、お客様先に行って、タイムカードを押して終わった時間分だけで、最後お金の精算という形になり、後でお金をもらうという形が企業間では割と多い支払い方になります。

article-040_thumb02.jpg

我々はBtoC領域で、コンシューマー向けの後払いというサービスを既に提供しております。今回はBtoBに挑戦していくということになりました。ここの業界はもうすでに他社さんがシェアを持っている業界になりまして、我々は新規参入し、プロジェクトをスタートさせていきました。

article-040_thumb03.jpg

河合 私所属をGMOペイメントゲートウェイと言いましたが、掛け払いのサービス自体はGMO-PGのグループ会社のGMOペイメントサービスが扱っているサービスになります。

図の右上側の購入企業様、こちらが、左のほうの加盟店様のサイトで買い物をする。買い物をしたときに掛け払いを利用すると、加盟店様の方からGMOペイメントサービスの掛け払いのほうに与信判断が1回飛んできます。リアルタイムでだいたい返っていきまして、そこで我々の中の与信で「良いよ」とか「悪いよ」という結果が返ってきまして、その結果をもって加盟店様は購入者様のほうにサービスなり商品なりを提供していただくような形です。
3番の「商品・サービス提供」するのと同時にGMOペイメントサービスの方にも「提供しましたよ」というトリガーをひいていただく。すると4番の「請求書発送」と5「代金支払」の回収というのはGMOペイメントサービスが購入企業様とやりとりをして、最後6の「お支払い」で加盟店様にGMOペイメントサービスからお支払いするということになっております。
メリットとしましては、加盟店様としては請求書の発行や入金の確認、督促の業務など、そういった業務から解放されるというところになっております。

article-040_thumb04.jpg

河合 続きまして概要のほうですが、最初に立ち上げる時のコンセプトですが、我々、後払いをやっているので、その思想は限りなく踏襲したいと思いスタートしました。また、サービス提供を最優先するために、まずミニマムでスタート。期間としても1年で全部作りきってサービスにしていくこととしました。

ハード的な処理コストを抑えるために、今回はAmazon WEB Services、「AWS」というクラウドを使って環境構築していく。また、システム構築も「GMO後払い」の思想を持っているため、使えるソースも限りなく多いということで、動いているものは全部使い切ろうという姿勢ではじまりました。

article-040_thumb05.jpg

河合 「GMO後払い」との違いとしては、スキームはBtoBとBtoCで違いますが、利用できる金額が後払いですと5万5,000円となっているのですが、掛け払いのほうですと30万円くらいからオプションをつけていただくことで、1,000万円ぐらいまで与信ができるという形になっております。
インフラとしては、AWSでやっております。言語はJavaで、フレームワークは今回Spring bootで作りました。

article-040_thumb06.jpg

河合 実際に作ったものがこれだけになるのですが、全部で8サブシステムありました。
APIは10本、バッチは50本。加盟店管理の画面数でいうと50画面。
購入者管理の方も40画面、業務管理の方は60画面。
また、与信もあるのですが、リアルタイムで返す与信のところのエンジンも新しく作りました。そこの画面は10画面。API は5本程度、バッチも併せるとなかなかな量になりました。
ミニマムスタートといいながらも、8年間動いているGMO後払いのシステムを踏襲という前提もあるのでミニマムでもかなり多かったなというのが印象です。

article-040_thumb07.jpg

宮山 先ほど河合からもありましたように、GMO後払いからの乗せ換えについて、AWSは利用しているのですが、利用技術的には一般的なJavaのプロジェクトで使われるような技術を主に使っております。
開発スタイルは、今回1年でローンチしたいということで、とにかく納期が短いため、開発を前倒しで終わらせて、早期からモジュールをどんどん結合させて結合試験で課題を洗い出すというスタイルでやりました。
バッチにつきましては、「GMO後払い」のソースコードを基本的にはビジネスロジックレベルで移植しました。こちらはフレームワークにのらないビジネスロジックがかなり多く占めておりましたので、そのような形をとっております。
WEBアプリですが、こちらはSpring bootのフレームワークをゼロベースで構築しております。8年前のソースと比べますと現在開発手法でSpring Framework から提供している機能を利用することで、シンプルで安全に作ることができるという判断から、ゼロベースで構築しました。
また今回4拠点間のリモートプロジェクトだったので、コミュニケーションの方法は苦労しました。結合試験フェーズ以降はTeamsの通話をずっとあけておいて、何かあったらすぐに相談できるというような環境を用意して、開発メンバーが開発をしやすいような工夫をしておりました。

article-040_thumb08.jpg

宮山 続きまして「ソースコードの標準化」といたしまして、今回掛け払いのチームでは各々が好みのIDEを使えるようなプロジェクトとしておりました。開発のピーク時に急速に増員がされまして、増員された開発メンバーもすぐに立ち上がれ、ストレスなく開発できるようにこのような形をとっておりました。
IDEごとに自動整形などが異なってしまうと思うのですが、そちらを防止するためにSpotlessというフォーマッタを導入しております。Javaのソースコードにつきましては、AOSPのスタイルを導入しております。こちらはSpotless、プラグイン定義がありまして、別途コンフィグレーションを定義することが必要ないので利用しております。

article-040_thumb09.jpg

宮山 開発のチーム構成ですが、先ほど申しましたようにピーク時は結構人数が多くて、17名で開発しておりました。チームは4チームあり、掛け払いのバッチ、APIチーム、掛け払いの業務管理チーム、掛け払いのそれ以外のWEBアプリのチーム、与信チームがありました。私自身はその他のWEBアプリチームに最初はいたのですが、移植の際に結構冗長なコードがあったため、それぞれのアプリからよばれる共通処理を作る部分を担当もしたりしておりました。現在はパートナー(社員)6名で開発及び運用を行っておりまして、かなり人数が減ってしまったのですが、運用に関しては本社メンバーの河合、宮山を中心に残っております。
追加の開発の案件にサブチームは特になくて、案件単位で人を充てて開発をしています。またスライドの下にありますインフラチームの2名ですが、こちらは開発の初期段階からAWS周りのサポートをしていただいていて、現在もAWS周りの運用等をしていただいている2名となります。

article-040_thumb10.jpg

宮山 主なAWSで利用しているサービスをご紹介させていただきます。
環境構築につきましては、CloudFormationで環境をコード定義しています。開発環境についてもAWSで用意しており、そのまま検証環境を本番環境にのせることを意識してコード定義しております。それによってCloudFormationによって容易なスクラップ&ビルドを実現しております。
また、CloudFormationで50本以上あるバッチの起動パターンなどを定義ファイルにしていることで、起動のスケジュールの修正や、新たな環境をゼロベースで構築するというような、作業が非常に短時間で行えるため重宝しておりました。
またWEBアプリ、バッチもですが、こちらはECSを使っており、起動タイプはFargateで作りました。基本的には1アプリ1コンテナというのがセオリーだと思うのですが、今回ミニマムスタートだったため1コンテナに複数WEBアプリを載せて起動するというような方法をとりました。
バッチに関してもコンテナで動かしていて、タスクのスケジューリングをCloudFormationで定義して、定時実行するような形になっております。
リランに関しましては、 AWSのStep Functionsから任意のタイミングで実行することができるような仕組みを作っております。

article-040_thumb11.jpg

宮山 先ほど1コンテナに複数のアプリを載せるというお話をしましたが、通常のコンテナ起動シェルはこんな形で「Java-jar」とやり、Javaファイルのパスというような書き方をすると思います。

article-040_thumb12.jpg

今回につきましては、起動シェルをこういった形で定義しております。それぞれのコマンドの中に「&」を付けることでバックグラウンド起動させておいて、複数アプリを同時に起動しています。またバックグラウンド起動したアプリは起動直後に落ちてしまうので、最後のtailコマンドで適当なところを監視するようにしてアプリが落ちないようにしています。

article-040_thumb13.jpg

メリットとデメリットですが、メリットは単純にランニングコストが安いです。こちらはコンテナを立ち上げる数が少ないので、非常に安く済んで、今回のコンセプトになるミニマムスタートに向いているかなと思います。またリリース時に1つのECSを更新してあげればいいので、リリースも短時間で行うことができました。
デメリットとしましては1つのアプリが高負荷状態になってしまうと、他の低負荷状態のアプリもつられてスケールアウトしてしまうので、少し無駄が出るかなといった問題があります。

article-040_thumb14.jpg

宮山 またロギングに関しましてはAWSのCloudWatchを利用しているのですが、複数アプリ分のログがすべて同じ箇所に吐き出されてしまうというような問題がありました。ただこちらの問題に関してはログのフィルタリングを利用することで、現状解決しております。
ログの出力時にアプリ名のプレフィックス、例えば「app1」のプレフィックスを打ち込んでおくことで、「filter @message likeそのアプリ名」というような形で検索してあげることで、比較的簡単にログのデータをかけることができます。本番環境では最近はかなり頻繁にログを見るのですが、このような運用で問題なく行うことができています。

article-040_thumb15.jpg

宮山 AWS及びJavaの開発につきましては以上となります。ここからはプロジェクトを振り返って感想を述べさせていただこうと思います。

私、冒頭にも申し上げましたように、コロナ禍で入社し、最初のプロジェクトがリモートプロジェクトでした。はじめは結構不安があったのですが、コミュニケーションの壁は思ったよりはなかったです。というのも、結合試験フェーズ以降ですが、Teamsの通話を開けておくことでそこにいるかのようなプロジェクトでした。仕事の話だけではなく、雑談もすることで、そのプロジェクトメンバーの人となりを深く知ることができて、この人はこれに詳しいからこれを相談しようみたいなことも、最近は結構できています。

河合 私、AWSの概念だけは知っていたのですが、AWSを本格的に使うというのは初めてでした。割と古い人間ですのでCDを入れて、OSインストールして、というあの面倒くさい作業というんでしょうか、インフラの構築というのも最初から携わってアプリ作っていて「ああ、OSのここをこうしておかないといけなかった!」となり、もう1回CDを入れて、、、みたいな作業を延々と繰り返していました。そういう人間からすると、AWSでのスクラップ&ビルドというのはものすごく楽だったのですね。
また、だいたいAWSは、「こういう機能なかったっけな、あったらいいのにな」というのが探し方によっては結構あるのですね。そういう意味でも今回使ってみてすごくよかったなと思いましたので、また次回何か新しい案件があったらAWSでやりたいなと思いました。

最後になりますが、われこそはという方は手を挙げていただきたいなと思っています。
以上になります。ご清聴ありがとうございました。

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