証券ドメインにおけるフロントエンド開発の推しポイント５つ
こんにちは、Finatextの証券ドメインでフロントエンドエンジニアをしている塚本です。
エンジニアの採用面接などでもよく話しているのですが、私が担当している証券サービスのフロントエンド開発は、今とても面白いフェーズにあると思っています。これを面接前に簡単にでも伝えることができたら、より深い話ができそうだなと思い、この記事を書くことにしました！
Finatextの証券ドメインとは
Finatextグループには、IR等で説明している3事業とは別のレイヤーとして、証券、保険、データ、フィンテックソリューションという4つのドメインがあります。
このうち証券ドメインでは、証券ビジネスプラットフォーム「BaaS(Brokerage as a Service)」を活用し、パートナー企業との協業により革新的な証券サービスをスピーディーに世の中に届けていくことを目指しています。
2018年にサービスを開始したコミュニティ型株取引アプリ「STREAM」を皮切りに、2023年3月時点で8つの証券サービスをリリースしており、今後もBaaS上で動くサービスを増やしていく予定です。
証券ドメインのフロントエンド開発体制
Finatextグループでは、基本的にドメインごとにエンジニアがアサインされる体制をとっており、証券ドメイン全体では約20名のエンジニアが在籍しています。そのうちフロントエンド開発をメインに携わるエンジニアは2名で、各々がフェーズの異なる複数の証券サービスを掛け持ちで担当しています。
新規サービス開発時の技術選定は各々に任せられているため、使用フレームワークはVue.js、React、Nuxtと様々です。サーバーサイドも書ける人がほどんどですので、簡単なものであればサーバーサイドの実装を行ったり、Terraformの設定ファイルを書いてAWSのインフラを構築したりすることもあります。
より詳しく知りたい方は、以下の記事も参照ください。
証券ドメインのフロントエンド開発の推しポイント
私が推したいポイントを、5つにまとめてみました。
1. 大企業とスタートアップのいいとこどり！
一緒に証券サービスを開発するパートナー企業に大企業が多いため、
- 非常に堅牢なシステム構築のスキルが身につく
- 顧客基盤が大きいのでサービスの影響力も大きい
という特徴があります。
一方で、エンジニアに与えられる裁量の大きさと開発スピードはスタートアップレベルです。スタートアップの機動力を保ちながら、大きなサービスの開発に携われる環境は、かなり貴重だと思います。
2. 解決すべき課題が盛りだくさん！
第1弾サービスの「STREAM」をリリースしたのが約5年前。その時その時でベストな選択をしてきてはいるものの、スピード優先で判断したものも多く、今となっては解決すべき課題が山盛りです。共通化の検討や、リファクタ、バージョンアップなど、やりたいけれどなかなか手をつけられていないものが多分にあります。
また、現在エンジニアが行っている作業をエンジニア以外のメンバーでも行えるような仕組みづくりにも取り組んでいて、これはアプリケーションを作るのとはまた違った難しさ、楽しさがあります。
例えば、証券サービスでは法改正や規約更改などで定期的に文言修正が発生するのですが、全サービスに適用されることが多いため、修正も複数リポジトリにわたります。エンジニアとしては単純に手間がかかりますし、エンジニアに依頼する側にも「ちょっとした修正なのに申し訳ない」という心理的負荷がありました。
そこで、エンジニアでなくても簡単に画面上のテキストを更新でき、それが全サービスに反映されるような仕組みを提案しました。スピードを重視したかったので管理画面は作らず、スプレッドシート上でテキストを修正してjson出力して反映させるという簡易なもので、この仕組み自体は提案から1ヶ月くらいで作りました。
このようなオペレーション改善のアイデアも含め、気づいた点は積極的に発言して周りを巻き込み行動することで、サービスや開発環境をどんどん変えていけます。
3. 0→1フェーズのサービスが常にある！
事業成長とともに新しいパートナー企業が増えている最中なので、新規サービスの立ち上げ機会も多いです。前述の通り、証券ドメインのフロントエンジニアは複数サービスを担当するので、当社にジョインしたらほぼ確実に0→1に携われると思います。
また、ポイントの2でもお伝えした通り、システム自体が古くなってきているサービスもあるので、作り替えという意味で0から構築する機会もあります。
ちなみに、私はフロントエンドエンジニア採用のスキルテストを担当しているのですが、0からアプリケーションを作成した経験のある人は意外と少ない印象です（スキルテストでは、簡単なWebアプリケーションを0から作ってもらいます）。
これまで当社で5つの新規サービスの立ち上げを経験しましたが、0→1フェーズは、技術選定、設計、複数人での開発を考慮した環境構築などについて考え抜く力がつき、エンジニアとして急成長できる貴重な機会だったと思います。
4. BaaSの共通化の議論がアツい！
当社の「BaaS」は、複数の証券サービスの共通基盤です。基本的な機能は共通化されているものの、実際に証券サービスを作るにあたっては、どこまでを「BaaS」として開発し、どこからを証券サービスとして個別に開発するのかを要所要所で検討する必要があります。
例えば、UIのカスタマイズ範囲を、ユーザーの利便性と将来的な開発工数削減のバランスを考えながら決めていくのは、難しくもあり面白いところです。
直近ですと、以下のような共通化を行いました。
- アプリのログイン機能を共通のWeb認証画面に切り出す
- 証券口座開設の共通要件を抽出してBaaS機能化
特に証券口座開設のBaaS機能化では、「開発効率を高めるためにできるだけ共通化すべき」と考えるエンジニアと「カスタマイズの余地をできるだけ残した方がいい」と主張するBizDevメンバーとの間で議論が白熱し、なかなか痺れる体験をしました（笑）。
なお、BaaS共通化に限らず、普段からBizDevなどエンジニア以外のメンバーとの議論が活発に行われており、開発効率、ユーザーの利便性、ビジネスメリットなど複数の視点を持って考える力を養うことができます。
5. フレームワークのコア部分をいじれる
各証券サービスに求められる機能をできるだけ共通化してBaaSの汎用性を維持しつつカスタムも可能にしていくために、フレームワークのコアな部分にも手を入れます。
例えば、webpackの設定でビルドを分けてカスタムも可能にしつつ全体は共通にしたり、pnpm workspaceを使って共通実装と個別実装をうまく切り分けたりして、モダンなアプリケーションを作っています。
フレームワークの仕組みを理解して奥深くをいじるのは、楽しいですよ！
最後に
以上、私の推しポイントを紹介させていただきました。
フロントエンド開発はもちろん、証券ドメイン自体がこれからますます成長フェーズに入っていきますので、私自身とても楽しみです。この記事を通して、少しでも証券ドメインでのフロントエンド開発についてイメージいただけたら嬉しいです。
エンジニア募集中📢
証券ドメインではフロントエンドエンジニアを大募集中です！業務委託も可能ですので、まずはお気軽にご連絡ください！
