「マイクロサービスになりすぎないように進めていった」　創業者CTOが語る、2度目のエンジニア組織立ち上げ時に工夫したこと

プロダクトのリリースまでに時間がかかった背景

山元亮典氏（以下、山元）：ここからは今までの挑戦を踏まえて、スマートバンクのCTOとしてどういったことにチャレンジしてきたのかというところも聞いていきたいです。（スマートバンクは）現在、創業して3年というところですね。

堀井雄太氏（以下、堀井）：そうですね。ちょうど創業して3年経ったぐらい。ただ、プロダクトをローンチできたのは2021年の年明けなので、まだ1年半ぐらいしかたっていないんですよ。なので、創業してからプロダクトをリリースするまで、仕込みの期間がかなり長かったというところはあるかもしれないです。

山元：その仕込みの期間はどういったことをやっていたのですか？

堀井：開発に時間がかかったところが大きいかなと思っていて。FinTechの事業をやると決めたのですが、FinTechの経験者がいたわけではないので。何を作ったらいいかを探りながらやっていたのもあったので、非常に時間がかかりました。

私たちのビジネスの仕組みは、「イシュア」と呼ばれているカードの発行の事業です。ライフカードさんやオリコカードさんなど、カードを発行して提供している会社と同じように、カードを発行しています。そういった建て付けで事業を作るのに、いわゆるライセンスや規約などを取得する必要があったので、そういった業務で時間がかかったというのはあります。

山元：いわゆるFinTechに挑戦する法務の部分や、システムの部分などの準備で時間がかかったというかたちなんですね。

堀井：そうですね。特に私がメインで担当していた開発領域に関しては、何をどこまで作るか次第かなと思うんですが、Visaのネットワークを通した決済基盤の仕組みだったりは、数ヶ月で開発できるものではありません。そのような仕組みをそもそもどうやって作るのかという調査から始めたので、メチャクチャ時間がかかりました。ドメイン知識がないと作れないところだったので、メチャクチャ苦労しました。

山元：聞いただけで「品質はどうするのだろう」とか気になってしまうところです。やはりすごく信頼性を求められるプロダクトだと思いますが、そのあたりの信頼性のコントロールは、初期から意識していたのですか？

堀井：そうですね。例えばVisaさんの要件には「○秒以内にレスポンスを返しなさい」というものがあります。お店でカード決済して、なかなか応答がなかったら、商品の購入はそもそもできません。「○秒以内にレスポンスを返す」ということは要件として守らないといけないです。

一番（要件として）大きかったのは、PCIDSSと言われている、カードを発行する際のブランドで、Visaさんなどが決めているセキュリティの基準があります。そもそもそれをクリアしないとカードを発行しての決済する事業はできなかったので、そこで信頼性という文脈を守ったセキュアなシステムにすることはかなり苦労したポイントです。

スマートバンク立ち上げ時の開発状況

山元：立ち上げ時は堀井さん1人で開発したのですか？

堀井：最初は私以外に開発していたメンバーが2人いて。サーバーサイドのエンジニアが私、あとの2人はインフラ領域とモバイルクライアントでiOSのアプリを書く、合計3人で始めたかたちです。

山元：その3人でドメイン知識を入れながら、いろいろな仕様書を読んでいたのですね。先ほど言っていたように、セキュリティ基準などを「守らないと！」となりながら作っていた感じでしょうか。

堀井：そうですね。最終的にリリースする時点ではもう2、3人は増えていたので最初より大きかったんですけれど。チーム自体はずっと1チームでやっていたので、全員野球に近い（雰囲気）というか。プロダクト立ち上げ時のわちゃわちゃ感じゃないですが、意思疎通をかなりこまめにやりながら作っていましたね。

ビジネスメンバー、デザイナー、PdMとも意見を交換しながら、「最初の仕様はどうしようか」などと話し合っていた感じです。

山元：確かにエンジニアサイドと事業サイドが密に連携していないと、うまく回っていかないのかなと（お話を）聞きながら思います。

堀井：特にFinTechの事業をやってみてわかったことがあります。スタートアップ単体でできることはそんなに多くなくはないのかなと思っていて、決済するにもVisaさんとライセンス契約を結んでそのシステムと連動するかたちで作らないといけないので、デベロッパーだけではぜんぜん完結しないのです。

カードを発行するという文脈も、カードを印刷する工場と、どういったかたちにするかを話してインターフェイスを決めていきます。ビジネスのメンバーとデザイナーと3人でやっていたので、ステークホルダーが多くて、なかなか難しい領域ではあります。

山元：でも、だからこそおもしろいというところなんですかね。

堀井：おもしろいと思います。私もこの領域は初チャレンジなので日々発見があります。みなさんもクレジットカードを日常的に使っていると思うのですが、カードを使った時に実際にどのような仕組みで決済されているのか、残高はどうやってコントロールされているのか、そういった部分を気にしている方はそんなにいないかと思います。自分たちがその裏側を作っているんだと思うと、けっこうおもしろいです。

山元：本当にすごいシステムだといつも使いながら思います。やはり（サービスを）落とせないですし、インフラとしても常に信頼性が高くないとなると、大変なシステムだと思いながらいつもお世話になっています。

堀井：お金を預かって、日常的に決済できることを担保しないといけません。運用する上でも制約など、ハードルがけっこう高い部類だと思っています。（ただ）それだけユーザーさんの生活に根ざしたサービスを作れていることがおもしろくもあります。いつも決済の電文に関するデータなどを見ながら、どのように処理しようか考えています（笑）。

前職のどのような経験がスマートバンク立ち上げ時に活きたか

山元：前職の立ち上げの経験について、先ほど「活きた点があった」と言っていましたが、具体的にどういった点でしょうか？

堀井：先ほど話したとおり開発するメンバーがそれほど多くなかったので、自分たちができるシステム規模がどれくらいかわかりませんでした。内製しつつ、一部ベンダーさんを組み合わせながら身の丈に合うような設計にした点が1つあるかもしれないですね。

最初に「やるぞ！」となった時、自分たちでハンドリングできる開発領域とアンコントロールな開発領域は大きく分かれていました。なので、後者のVisaさんのシステムと連動する部分などは、Visaさんとの契約が終わって仕様書がもらえないとできない、時間的な長さがありました。

（仕様書を）もらっても、その解像度を高めるのにメチャクチャ時間がかかったりしたので、ベンダーさんにも協力してもらって一緒にキャッチアップしました。「一緒にやりながら作った」というところはポイントです。

また、決済・入金・出品などいろいろな機能があるのですが、単体（の機能）を取っても1つのシステムとして稼働させられそうな粒度です。でも、早期にサービスを分断することはやめて、1つの大きなサービスで運用するかたちにしました。そのあたりは、フリマアプリで分断したモノリスになって苦労した経験から「やめよう」となりました。

山元：そうなんですね。「マイクロサービスになってしまうと難しい」と世間で言われていたりしますが、難しいバランスを取りながら進んでいったんですね。

堀井：そうですね。もう少し正確に言うと、システムは大きく2つに分かれていて、ユーザーさんの会員データなどを扱っているデータベースを中心に業務設計された残高を減らしたり、ユーザーさんのカード情報を見たり、モバイルアプリが使うAPIがあります。先ほど話したモノリスなシステムはこれにあたります。

もう1個は、Visaさんとつながってカード情報を作ったり。オーソリ電文と言われたりしますが、その電文をやり取りするシステムの大きく2系統に分かれているかたちで、前者がモノリスになっています。

スマートバンクの開発言語

山元：ちなみに、言語は何で実装されているんですか？

堀井：先ほど話したモバイルアプリのバックエンドが中心になっているモノリスは、Rubyで書かれています。Railsを使っていて、主な決済基盤やカード発行基盤と言われている後者はGoでできています。

山元：なるほど。言語が違うとエンジニアの開発のスイッチングコストみたいなところがかかってしまうと思うのですが、そこは問題なかったのですか？

堀井：実際に「Goは未経験です」というメンバーが何人かいましたが、それほど大きなボトルネックにはなっていないかなという認識です。決済基盤をGoでやりたかった理由がいくつかあったのでGoを選んだというのが大きくて。Rubyはどちらかというと社内のデベロッパーで開発できるメンバーが多かったので、そちらはそれほど問題にはなりませんでした。

山元：なるほど。ありがとうございます。

（次回に続く）