モダンな技術を使った新しい証券会社のつくり方
ブルーモは新しい証券会社として、日本の個人投資家向けのプロダクトをつくっていますが、エンジニアリング的に構築・運用がとても大変です。今回は、開発を統括するCTOの小林が、ブルーモがどのようにモダンな技術を駆使して「証券会社」を再定義しているのかご紹介します。
新しい証券会社ブルーモでのプロダクト開発
――早速ですがプロダクトについて教えてください。
私たちは最近増えてきた日本の資産形成層向けにスマホで米国株・ETFを取引できるプロダクトを作っていて、その開発コードネームをBrooklynと名付けています。Brooklynの由来は、今作っているのが米国株投資アプリで、米国株の取引がされている最大の市場がニューヨーク証券取引所であることから、ニューヨークにゆかりのある街や建物、島や道路、食べ物などの名前を挙げていき、最後は響きと直感でBrooklynという名前にしました。
――開発体制を教えてください。
Brooklynは大きく4つのチームに分かれています。
1つ目がアプリ側のbrooklyn-appチームです。バックエンドのサーバー側は2つに分かれており、それぞれbrooklyn-webチームとbrooklyn-coreチームと呼んでいます。4つ目は主にインフラ・SRE領域を担当するbrooklyn-devopsチームです。
――4つのチームそれぞれのメンバー構成はどうなっていますか。
現状としてはそれぞれのチームに1名ないし、2名のフルタイムエンジニアがいます。brooklyn-appは1名でbrooklyn-webとbrooklyn-coreは合わせて3名、brooklyn-devopsは1名です。加えて、副業としてハーフタイムのような形で入ってくれているエンジニアが3名〜4名という感じです。
――メンバーやCTO（小林）の働き方はどのようなものになっていますか。
まず、成果が出ている限りは自由に働いてもらうというのが大きな方針で、勤務形態もフルリモートOK（出社していただいても大丈夫ですが）です。フルタイムの方はメインの担当領域を自律的に進めてもらっており、毎朝11時のスクラムミーティングで進捗とその日やることを報告し、その他の作業時間は基本的に自由です。副業の方々は、その時の開発状況に応じて入る場所は変わってきますが、基本的には開発項目が多いbrooklyn-webかbrooklyn-coreに入ってもらうことが多いです。私も同じように開発の状況に応じて4つの中の手薄なところに実装に入りつつ、全体的なタスクの洗い出しと割り振りを行っています。
――現在のテックスタックはどういったもの使っていますか。
私たちが作っているサービスはネイティブアプリでサービスを提供する予定なので、brooklyn-appに関してはFlutterを使っています。brooklyn-webではRuby/Rails、brooklyn-coreは、Go言語を採用しています。brooklyn-devopsはクラウドインフラとしてはGCPを使用し、その中でKubernetes（GKE, Google Kubernetes Engine）を中心にDev/Ops環境を構築しています。
テックスタック検討の背景
――テックスタックを今のものに決めた理由を教えていただきたいです。
まずbrooklyn-appに関しては、それこそ創業当初はiOSのネイティブだけにしようという話もありました。しかし私自身が過去のフリーランスの案件でFlutterを触ったことがあり、Flutterは思ってよりいいなという感触をその時持ったので、今回も採用しました。
――実際触ってみてわかることもあるんですね。
そうですね。FlutterやReactNativeのようなクロスプラットフォーム系の開発フレームワークはあまりパフォーマンスやユーザ体験が良くないと長年言われてきましたし、私自身も同じ印象を持っていました。なので真にユーザ体験を求める企業は、iOSとAndroid開発でそれぞれ別々のネイティブアプリ開発人材を採用してきましたが、2018〜2019年くらいからだいぶ事情が変わってきたと思います。確かにiOS/Andoroidアプリをネイティブ開発したほうがアプリの反応速度などのパフォーマンスは向上すると思いますが、例えるならネイティブ開発をした時のパフォーマンスを100とすると、Flutter開発でも今では十分に80〜90ぐらいのパフォーマンスは出ていると感じています。ですので、デメリットとしては、若干パフォーマンスが落ちる部分はありますが、その代わり大きなメリットとして、Androidユーザをカバーできます。ここで、純粋にメリットがデメリットを上回ったという理由でFlutterを選びました。
――インフラやバックエンドはどうでしょうか。
クラウドインフラですが、僕自身が長らく経験してきて、かつ前職でも、そしてフリーランスの案件や趣味のサービス開発でも長らくAWSでインフラを組むことが多くありました。前職ではクラウドインフラの一部を途中からAzureに切り替えて、その中でKubernetes（AKS）を使っていましたが、本当の意味でKubernetesの良さをフル活用できるまでには至りませんでした。
しかしKubernetesは極めれば色々なことができるし、コミュニティーやエコシステムも十分に成熟していてエンジニアとして十分にベットする価値のある技術だと確信も持てました。
一方で、Kubernetesを採用するデメリットとしてよく言われるのは、学習コストや運用コストが高いということです。しかし、僕たちがやろうとしていることは証券会社とそのシステムを作るという、どう考えても途方もなく大変なことです。証券会社とそのシステムの運用体制全般を作る大変さを100とすると、 Kubernetesを採用することによる大変さは15か、いっても20くらいかなと思いました。さらに僕たちが目指しているのは100万ユーザ＆顧客運用資産1兆円というとても大きな目標なので、いつかはKubernetesのようなガチのインフラが必要になるのは確実なので、それだったらこのくらいえいやで最初からまとめてやってしまえという思いで当初からの採用を決定しました。
――確かに、ゼロからの立ち上げほど大変なものはありませんよね。
あとはやはり、ベンダーロックインやBCPなども考慮して、クラウドインフラのポータビリティを高められるようにしておきたいとう想いもありました。ダメ押しで個人的な興味関心もあり、単純に自分自身としてもKubernetesでしっかりとしたサービスやそのインフラを作り上げてみたい、そういう想いもあってインフラはKubernetesを採用しています。Kubernetesを使うならば、AWSよりかはGCPの方が一日の長があるとよく言われているので、GCPを選びました。GCPは僕自身はそこまでの経験値はなかったのですが、使っていくうちに最近はだいぶ慣れてきましたし、AWSで培った経験値は十分に活かせていると感じてます。
――「この技術でサービスを作りたい」という想いもひとつの動機として必要ですね。
最後、1番迷ったのがバックエンドであるアプリケーションレイヤの実装言語ですね。 ここは本当に、すごく迷いました。近年バックエンドでよく採用されるプログラミング言語としては、Ruby/Rails、Python、TypeScript、Golangあたりがあるかと思っていて、僕自身はRuby/Rails、Python、TypeScriptはわりと得意で、Golangはたしなむ程度というスキル感でした。フリーランスの案件としてもWEB系はRailsでやることが多かったですし、前職ではRailsとTypeScriptでシステムの大部分を構築しました。趣味で作っているAI系のサービス（政治資金データベース）はPythonとRailsの組み合わせで作っています。得意かつ1番早く作れるものとなるとRailsになりますが、自分自身もRailsを長年やっているからこそ、その大変さもわかっていると自負しています。
Railsは開発初期のような、あまり規模が大きくならずシンプルな構成のうちは開発の生産性は非常に高く、どこに何のコードが置かれているのかもわかりやすいです。そのため、拡張やメンテナンスもしやすく、またコミュニティーも充実しているので人的・ソフトウェア的な両面から豊富なナレッジや資源が蓄積されています。さらに、管理画面や認証・認可といったようなWEBのなかでも比較的ユーザに近い位置の機能に関しても多くのライブラリが開発されています。
しかし、開発が進み要件も複雑になり、Railsアプリの規模も大きくなってくると、プロジェクトごとに独自のルールが増えたり、コードや開発方針の一貫性が保たれていなかったりという事態が起こります。また、動的言語という性質上、特に複雑なビジネスロジックの実装コードとなると読んだだけだとなかなか理解できません。「この変数hogeはいったい何クラスの型でどういう情報が入ってるんだ？」といった単純な疑問を解消するために、コードを深く読み込んだり実際に動かしながらデバッグしないと紐解けなかったりといった【ツラミ】がだんだんと大きくなってきます。
一方で、TypeScriptやGolangのような静的言語や、動的言語ではあるけれど言語仕様レベルで型のサポート（Type Hints）を組み込んだPythonなら、コードを書いた時点で型が決まっているので、複雑なビジネスロジックも動的言語よりは書きやすいと感じています。そのため、いわゆる複雑なビジネスロジック…我々で言うと、例えば、注文計算や資産管理といった複雑な部分に関しては、型の恩恵を受けられる静的言語を使うのが良いだろうと思い、最終的にはGolangを選択しました。
――Railsの良さを最大限生かしつつ、デメリットを他言語でカバーするためにバックエンドは2つの言語を採用しているんですね。
また、採用目線もあります。Rails自体は、非常に巨大なコミュニティになっていて、エンジニアもたくさんいるし、実際世の中にRailsで動いているサービスは山ほどあります。しかし、Railsエンジニアの中でも「Railsは好きだけどいつまでもRailsばかりやっていてもいいのか。他の言語も経験すべきではないか。」と思っている方もたくさんいて、実際にRailsやPHP、WEB系のPythonエンジニアからGolangに移った人も多くいます。そういう方々にも関心を持ってもらえるように、RailsとGolangという2つの言語を用意することによって、興味を持っていただくきっかけとしています。
――Golang以外にもバックエンドの言語はあると思いますが、他に採用を検討していた言語はありましたか。
その他にPythonとTypeScriptの採用も考えました。PythonもTypeScriptもとても素晴らしい言語ですし、僕自身も好きです。しかし、特にWEBのフレームワークの充実度というか完成度という意味では、なんだかんだRailsのほうが勝っていると感じています。PythonもDjangoがありますが、Railsと比べたら、 Railsの方が使いやすいと感じていますし、その他で言うといわゆるマイクロフレームワークと言われるような比較的小さいフレームワークが多いですね。なので、自分たちでその他の部分、例えばORマッパーや認証認可のプラグイン、テストのフレームワークなどを自分たちで選んで組み合わせて作っていく必要があります。1個1個のプラグインや、そのライブラリを選定するために、いろいろな技術調査をしなくてはいけなくて、考えることが多くなります。
一方、Railsにするとこういったライブラリはデフォルトで組み込まれているか、デファクトとなっているものが多くあります。僕らのようなスタートアップはスピードが命なので、Railsにすることによってこういった考える時間を大幅に節約できることが大きかったです。Rubyのコミュニティ自体がWEBだったら、基本的にはRailsにほぼほぼ一本化されていて、そこに十分なエコシステムが確立されているのでRailsは捨てられませんでした。しかし、やはりRails1本にしてしまうと、先ほどお話した様々な問題があったり、採用面でのデメリットも出てきたりします。1個1個のRailsアプリをなるべくシンプルにして複雑なビジネスロジックの部分はGolangに寄せる、そういうような構成でいけるのではないかと考え、現在のテックスタックになっています。
――検討に検討を重ねた結果、現在のテックスタックになっているのですね。デメリットもしっかりと考えた上でのテックスタックとのことですが課題感はありますか。
テックスタックそのものの選定は、今のところそんなに間違っていなかったと思っています。しかし、どうせやるなら最初から大変な方、つまり、「いつかは必要になってくるものを、最初からいれちゃえ」という考えのもと、現在のテックスタックが組まれています。Railsはどこに何を書けばいいのかがだいたい決まっているのであまり考える必要はないのですが、Golangはプロジェクトごととか人によってやり方や経験してきたものが違うため、基本的な設計の部分でも結構時間を取られました。その他、KubernetesやGCPも構成を決めるところで結構な時間がかかりました。まだまだ開発初期であるのでしょうがないですが、課題としては、やはり1個1個の課題解決に時間がかかっているところかと思います。
求む孫悟空、一緒に次世代の金融システムをつくりませんか？
――最後になりますがブルーモで活躍できるエンジニア像を教えてください。
今はまだ10人弱くらいの組織ですので、スキル面で言うと、基本的にはアプリ側ならFlutterかiOS/Androidでのネイティブ開発経験、バックエンドではRailsかGolangの経験、インフラ方面はAWS・GCP・Azureのどれかの経験は必要です。ベースとしては、実務経験をしっかり持っている人にジョインいただきたいですね。プラスで、今の規模感ですと何か1つだけしかできない、１つだけしかやりたくないという人よりかは、何か1つを中心としつつ隣接する領域をある程度カバーできる、あるいはしていきたいという意思を持っている人が向いていると思います。たとえば、Railsを軸としつつFlutterもやってみたい、Golangもやってみたい、インフラ・SREをやってみたい、そういった形で軸足を持ちつつ、周辺も触れる、触っていきたいという方が活躍できると思います。そういう人をフリーランスでも社員としてでも歓迎していますし、現在のメンバーはそういった人が揃っています。
――現在採用されている言語での実務経験は必須ですが、他にもチャレンジしていきたいという方が向いているんですね。マインド面はいかがですか。
マインド面としては、この規模のスタートアップとしては、採用している技術の幅も広く一つ一つが重たいので、複数の技術に幅広に触れてみたいという、いわゆるフルスタック思考の人が向いているかと思います。その他、金融投資というビジネス分野にある程度興味を持ってくれている方にはやりがいを持っていただける環境かと思います。あとは、何よりもモノづくり・ソフトウェアづくりが好きな人ですね。まだまだ開発初期なのでスクラッチ感満載で、モノづくりをしている感覚はダイレクトに味わえるフェーズです。好きこそものの上手なれだと思っているので、大変ながらもモノづくりを楽しめる人は向いていると思います。
つくる対象が大変になればなるほど燃える、我々は最近そういう人を「孫悟空タイプ」と呼んでいるのですが、孫悟空タイプの方が向いていると思います。
一緒に働く仲間を募集しています
バックエンドエンジニア
フロントエンドエンジニア
インフラエンジニア
モバイルアプリエンジニア
SRE（Site Reliability Engineer）
エンジニアインターン
募集概要は、採用ポジション一覧よりご確認ください！
モダンで新しい証券会社を一緒につくる仲間となってくれる方のご応募をお待ちしています！