バイセル Tech Blog

バイセル Tech Blogは株式会社BuySell Technologiesのエンジニア達が知見・発見を共有する技術ブログです。

バイセル Tech Blog

手動送金地獄をシステム化して作業時間を50%削減した話

手動送金地獄をシステム化して作業時間を50%削減した話

はじめに

こちらはバイセルテクノロジーズ Advent Calendar 2022の21日目の記事です。 前日の記事は今井さんの「HasuraやAPI Gatewayを活用してマルチテナントなマイクロサービスを効率よく開発する」でした。

こんにちは。テクノロジー戦略本部 開発1部の杉田です。
突然ですが皆さん、インターネットバンキングってすごく便利でありがたいけど、もし1日に何件も手作業で振込を行うとしたら、さすがに煩わしいなぁって思いませんか?
バイセルはその名の通りモノを買ったり(Buy)売ったり(Sell)している会社なので、どこかにお金を振り込む機会も非常に多いのです。そこで、この「送金」という行為をより簡単にしよう!という目的で開発されたのが、私が担当した自動送金システム「Money Transfer(マネートランスファー)」です。
できたてほやほやで先日遂にリリースされましたので、今回はそのご紹介をさせていただきます!

開発経緯・背景

自動送金システムを開発するに至ったきっかけは、今年の夏に弊社が株式会社フォーナインを買収したことにありました。
もともとフォーナイン社は買取店舗「Reuse Shop WAKABA」を数多く運営しているのですが、買取スキームのひとつとして以下のような場合があります。

買取スキーム

  1. お客様が買取店舗に売りたいモノをお持ち込み
  2. (売買契約成立ならば)店舗がお品物と引き換えにお客様へ代金をお支払い
  3. 店舗が買い取った品物をフォーナイン本社に送付
  4. フォーナイン本社が店舗に買取代金を支払い

この時、店舗としては#4のお金を翌日の#2の代金に充てたいので、できるだけ早く送金してほしいという要望があります。ところがフォーナイン本社にとっては全国の店舗から同様の依頼があり、1日に数十件の送金対応が必要で、これを手作業で1件ずつ、しかもスピーディーに行うのは限界がきていました。
手作業での送金は、シンプルに書いても以下のような手順が必要になります。

  1. 店舗から送金依頼が届く
  2. 内容確認
  3. インターネットバンキングにログイン
  4. 金額&振込先を入力(ミスのないよう慎重に)
  5. ワンタイムパスワードを入力
  6. 振込完了

インターネットバンキングがなかった時代と比べたら既にだいぶ楽になっていますが、それでももっと簡単にできるはず!そこで...

  1. 店舗から送金依頼が届く
  2. 内容確認&承認
  3. 振込完了

テクノロジーの力を使ってこんな世界を実現しよう!ということになったのです。

送金サービスの選定

このプロジェクトが始動してまずはじめに行ったことは、送金サービスの選定です。
いくつか比較検討をしたのですが、主に以下の点に着目していました。

  • API経由で振込ができること
  • 手数料
  • 振込上限額

API経由で振込ができること

これは言わずもがな、MUSTです。
なんらかの人間の操作をトリガーに、新しく開発するシステムから外部送金サービスにリクエストを飛ばして自動振込させるようなイメージでしたので、API連携が大前提でした。

手数料

こういった送金サービスは、一般的に1件あたりの振込に対して手数料がかかります。
振込金額によって手数料が変動するパターンだったり、振込金額問わず一律だったり、サービスによって料金形態は様々でしたが、振込件数が多ければそれだけ費用もかさみます。安ければ良いというものでもないですが、抑えられるなら抑えたいという気持ちでした。

振込上限額

お買取させていただくお品物はお客様によって様々ですので、1回あたりの振込金額が比較的大きくなることもあります。「限度額オーバーなのでこの案件は自動送金できません」となっては困るので、振込上限額がいくらなのかも重要なポイントでした。

そして辿り着いたGMOあおぞらネット銀行

上記3つのポイントを踏まえて総合的に検討した結果、弊社ではGMOあおぞらネット銀行のAPIサービスを利用することに決めました。
大きな決め手となったのは、やはり銀行ということもあり振込上限額がなかった点です。たしかに銀行で振込をする時って、自分にお金さえあれば基本的にいくらでも振り込めますよね。

システム構成

以下の理由からサーバーレス構成でCloud Functionsを採用しました。

  • 要件的に複雑なUIを作る必要がない
  • リリースまでも時間的余裕がそこまでないため、手軽にさくっと作りたい

全体としては下図のような造りになっており、黄色の3つのCloud Functionsをまとめて「Money Transfer」と呼称しています。

Money Transferシステム構成

振込依頼CF

Cloud Pub/Subで特定トピックへのメッセージ配信をトリガーに起動するCloud Functionです。
外部のサービスから振込金額と振込先情報(口座番号など)を送ることで起動し、振込依頼情報をDBに保存しつつGMOあおぞらネット銀行API(以下、あおぞらAPI)へ振込依頼リクエストを送ります。その後、その結果をリクエスト元の外部サービスへ返します。ここで返す「結果」というのはあくまで「振込依頼が正常に受け付けられたか」であり、「振込処理が成功したか」ではないことに注意してください。実際に振込処理が成功したかを確認するのは、後述のCloud Functionの責務になります。

今回の場合、買取店舗WAKABAからフォーナイン本社への送金依頼はfreee会計を使用して行われていましたので、上図の「サービスA」にあたる部分として更に別の小規模システムを作りました。このシステムがfreee会計上での「送金依頼の承認」をwebhookにより検知して、Money Transferの振込依頼CFへリクエストを送るという仕組みです。
これにより、前述の

  1. 店舗から送金依頼が届く
  2. 内容確認&承認
  3. 振込完了

が実現できるようになったのです!

振込状況確認対象取得CFと振込状況照会CF

振込自体は非同期で行われるため、先に行った振込依頼が無事成功したかどうかの結果は別途あおぞらAPIへ取得しにいく必要があります。そのため、振込状況確認対象取得CFがCloud Schedulerによって5分に一度起動し、その時にまだ振込結果が分かっていない振込依頼を一括取得して1件ずつ振込状況照会CFに流します。振込状況照会CFは受け取った振込依頼の振込状況を確認すべくあおぞらAPIを叩き、その結果をDBにも保存しながらリクエスト元の外部サービスへ送る、ということをしています。

工夫したポイント

マイクロサービス化した

冒頭にも書いたように、もともとバイセルとそのグループ企業はどこかにお金を振り込む機会が多い会社であるため、今回の発端以外にも自動送金のニーズというのは潜在的に存在していました。そのため、先の図を見ていただいても分かるかと思いますが、Money Transferはグループ内の様々なシステムから利用できるようマイクロサービスとして設計してあります。
特定の内容でリクエストを送ってくれさえすれば簡単に送金を実現できるので、便利な存在を開発できたんじゃないかなと思っています。

webhookで振込結果を通知できるようにした

もしもMoney Transferの中に定期的な振込結果確認の仕組みがなかったらどうでしょうか。振込結果の取得という意味では、各利用元サービスが任意のタイミングで振込状況照会CFへリクエストを送れば、自分から振込結果を取得することは可能です。とは言え、そういった似たような処理が社内の様々なシステムの中に生まれるのはなんともイケてない世界です。そこで、そういった処理はMoney Transfer内で完結させ、利用元サービスはただ結果が送られてくるのを待つだけ...という美しい世界にしました。
外部サービスが新しくMoney Transferを利用する時には、Money Transfer内にwebhookの通知先エンドポイントを登録する形になります。

エラー通知の責務を分けた

例えばなんらかの理由で振込が失敗していた場合は、エラー通知を行いたいものです。フロー的に一番最初に振込が失敗していることに気付くのは振込状況照会CFになるため、そこからエラー通知を飛ばすことも可能です。ただ、それではサービスAからの振込依頼が失敗していた場合でも、サービスBからの振込依頼が失敗していた場合でも、Money Transferからエラー通知が送られることになってしまいます。せっかくマイクロサービス化されているのに、それってなんだか少し違和感がありますよね。そこで、そもそもどんなエラーを誰が検知したいのかを整理してみました。

エラーの種類

こうして見えてきた状況を踏まえ、Money Transferの一部である振込状況照会CFは振込結果の内容へ関与しない設計にしました。仮に振込が失敗していた場合でも、とにかく利用元サービスにその結果を送るのです。そうすることで、利用元サービス側で任意の方法(Slackやメール等)で任意の事業部メンバーにエラー通知を送れる設計にしました。利用元サービスが変われば事業部の担当者=エラー通知を検知したいユーザーも変わるので、非常に合理的な結論になりました。

効果

Money Transferを利用した送金フローの運用が始まったことによって、1件あたりの送金にかかる作業時間を大幅に短縮させることができました。

  • 1日あたりの総作業時間が 10時間 → 5時間 に短縮
  • 月間にすると 5時間×20日間=100時間 の削減

ひと月あたり丸々12日(1日8時間労働を想定)は他の仕事へ充てられるようになったことになります。

定性的な面でも、以下などを実現することができました。

  • 煩わしい手作業の廃止
    • 送金ミスのリスク軽減
    • 送金依頼の一元管理化
  • 作業者の精神的負担の軽減

ユーザーからも「本当に楽になりました、ありがとうございます」と何度も感謝の言葉をいただくことができ、開発者としても嬉しい限りです。
バイセルではこのように社内システムやtoBシステムの開発を主に行っていますが、今回のようにユーザーからのフィードバックをダイレクトに受け取ることができる点も大きな魅力かなと思います。

小話

このプロジェクトが立ち上がった初期の頃、サービス名の検討をしました。

ネーミング指針

ここから始まり、いくつか候補は出て、

ネーミング候補

ナニかを想起させる懸念もありつつも、

ナニかを想起

結局今のMoney Transfer、略してマネトラに落ち着いたのでしたw

終わりに

前述のように、マネトラの誕生によって業務効率を大きく改善できました。まだリリースされたばかりのシステムですが、今後様々なサービスから利用されるようになるのが楽しみです。社内でも「マネトラ」という言葉がどんどん浸透していってほしいなと思います。

最後に、バイセルではエンジニアを募集しています。ここには書けないマネトラの秘密をお話することもできますので(笑)少しでも弊社に興味を持ってくださった方は是非ご応募ください!お待ちしております。

herp.careers

明日のバイセルテクノロジーズ Advent Calendar 2022は高谷さんの「全社員がSQLを書けるようBQの権限やデータソースを整理して運用している話(後編)」です。そちらも是非読んでみてください!