本記事は LayerX Tech Advent Calender 2022の12/23日分の記事です。
自己紹介
LayerX、Fintech事業部でエンジニアリングマネージャーをしています。たこちゅー ( @takochuu )です。 前職含めてtoC開発の経験が豊富で、過去5年ほどEMをしていました。 経歴はこちら
現在は、三井物産デジタル・アセットマネジメントに出向して、10ヶ月ほど個人向け投資サービスであるALTERNA(オルタナ)の新規開発に関わっています。
MDMについて
三井物産デジタル・アセットマネジメント(以下、MDM)については以下の記事郡が詳しいので、ご覧になってみてください。
そんなMDMを一言で表すと、「スタートアップ・エンジニアカルチャーに三井物産・金融取引業者のエッセンスを足し、金融サービスを作っている会社」です。
社長の上野さんは三井物産で数々の会社経営を実践されてきた方ですが、「能力ある人が裁量を持って自由に活躍できる会社」というのを常日頃仰っており、実際フラットな組織・コミュニケーションで仕事ができています。
設立経緯や思いについては以下をご覧ください。
オープンイノベーションは“地道”の積み重ねだ。LayerXと三井物産から学ぶ、JV立ち上げの秘訣【連載 イノベーション・メカニズム】| FastGrow
本記事ではそんなMDMが新規プロダクトとして取り組んでいるALTERNA(オルタナ)で行ってきた取り組みをご紹介します。
ALTERNAとは
上場株式に比べて価格変動しにくい、既に安定稼働している不動産やインフラなどに対して投資を行うことができるプラットフォームサービスです。
STO（セキュリティー・トークン・オファリング）という仕組みを利用し、デジタル証券をやり取りし、投資を行うことができます。
事業の不確実性に対しての技術選定基準
我々Fintech事業部のメンバーは「金商業者」であるMDMで勤務しているため「金融商品取引法」で定められている内容を適切に守ると共に、各関連団体が定める基準を満たしたプロダクトを開発する必要があります。
詳しい内容についてはチームメンバーのetaroさんの記事をご覧ください。
ですが、プロダクト開発チームメンバーは金商業者のエンジニアリング部門出身ではないため、当初から要件を全て明確にすることは難しく、都度不明瞭・不確実な事業要件を明確にしつつ開発する必要があり、都度の変更に耐えるアジリティ・開発効率の高いシステムを構築する必要がありました。
また、当初の計画では実装着手から8ヶ月ほどで全てのシステムを用意し、ローンチする予定だったのでなおさら管理コストを払いたくないという理由で、社会的にも知見が十分に溜まっており、調査したら問題が早期に解決できるであろう技術スタックで開発することにしました。
バックエンド: Go
フロントエンド: TypeScript / React / Next.js
チーム構成
PdM: 2名 / デザイナー: 1名 / エンジニア: 6名のチームで開発しており、ほぼ全員のエンジニアがフロントエンド・バックエンド・インフラを触ることができるというフルスタックなチームになっており、XXさんはフロントエンドといった役割を固定せずに開発を行っています。
そのような体制を取ることで、機能単位の実装において他の人に実装をパスする必要がなく、コミュニケーションコストの削減になっています。
リポジトリ構成
以前開発していた法人投資家向けのプロダクトではフロントエンド・ユーザー向けバックエンド(以下fs)・管理画面バックエンド(以下bs)のリポジトリが分割されていました。
それによりブランチのswitchからはじまり、開発効率が落ちていると感じていました。また、同じGoでの開発のはずなのに似たようなコードをを別のリポジトリに再実装する手間がありました。
今回はスピードを出して開発することを目的にフロントエンド・バックエンドを一つのリポジトリ内に配置しており、各々 /go /typescriptが各々のルートディレクトリになります。
.
├── go
│ ├── bs
│ ├── common
│ ├── fs
│ ├── model
│ └── repository
├── infra
├── sql
│ └── migrations
└── typescript
├── bs
└── fs
結果的にtypescript側ではfs(ユーザー向け画面)とbs(管理画面)で言語内での再利用性が必要なかったのですが、特にGoにおいてはmodel repository等のfsからもbsからも呼ばれるコードの再利用性を上げることができています。
その他にも、以下のようなメリットを享受することができ、比較的悩まずに開発を進めることができています。
- 似たようなコードの再実装を避けることができ、言語内でコードの再利用性が高い
- セットアップの効率化
- フロントエンド、バックエンド通した開発時の快適性の向上
- Pull Requestが分割されないためレビューで一貫して確認が可能
管理画面の複雑さ
プロダクト開発をする上で、必ずと言っていいほどつきまとうのが「管理画面開発(以下bs開発)」です。
bs開発はfs開発と比較すると、一度運用が開始されると追加機能がない限りはユーザー向け画面の開発が優先され、あまりメンテされない傾向が以前勤めていた会社ではありました。
その他にも、メンテされないことによって言語・ライブラリのバージョンアップに追従できず、セキュリティホールを抱えてしまったり、多くのエンジニアの悩みの種ではないかと思います。
投資サービスという特性上、一般的なプロダクト運用で必要な機能だけではなく「広告審査」といった申請・承認などのフローが必要であるなど、考慮しなければいけない点はプロダクト運用以外にも存在します。
これらの中で、特に「案件掲載対応」は案件の見せ方が決まらないと画面設計も決まらないという特性を持っており、非常にbs側のUIの構築が難しい領域です。更に要件が変更され、修正をする場合はAPIもUIも直さなければならないというのが非常に辛かった思い出がありました。
実際に法人投資家向けのプロダクトではこれらの画面を全て自前で実装していたのですが、決算期が来ると担当のPdMが泣きながら入稿作業をするといった有様で、同じ轍は絶対に踏まないようにしたかった部分です。
そこでチームとしては「見せ方が不定である内容について正規化したデータとして持たない」「入稿作業・更新作業をとにかく楽にする」というコンセプトでどうにかして実装レスで管理画面を構築する方法を探していました。
そこで見つけたのがBaseMachinaというサービスです。 about.basemachina.com
少しこちらのサービスの紹介をさせて頂きますと、先のリンクのLPにもある通り「管理画面を数分で」作れるサービスなのですが、何が我々のチームの要件と合致したかというと、以下ポイントになります。
- データソースとして、DBだけではなくAPI endpointへの接続ができる(REST/GraphQL/gRPC対応)
- 申請・承認フローが実装されており管理権限を分割することができる
- 操作ログが残り、誰が何の操作をしたのかバックトラックすることができる
これらのポイントからBaseMachinaを採用し、APIだけ用意することでプロダクト運用に必要なUI実装と、CS担当者が使用するユーザー管理系のUI実装を全て捨て去ることができました。(最高！)
無駄なものを作らない
LayerXには「爆速開発」という文化があります。 それは以下のスライドに詳しいのですが、その文化はFintech事業部でも励行されており、特に「使われないものを作らない」ということには意識してこだわってきています。
Fintech事業部における「使われないものを作らない」というのはつまり「原典をしっかり理解する」ということです。
その具体としての行動は、明確な基準が存在しないガイドラインを読み解き理解した上で仕様を担当部署含めて主体的にプロダクトチームが整理するといった行動にあらわれており「不安だから作っておこう」ではなく「不安ならば調べて対処しよう」という行動様式で仕事をしています。
例えばFISC(金融情報システムセンター)が刊行している「金融機関等コンピュータシステムの安全対策基準・解説書」を読み、実装を行うことや、個人情報保護法の遵守などがそれに当たります。
一見地味に見えますが、システムを運用するだけではなく記録の保管義務などが存在している我々のプロダクトとしてはマストな行動だと考えています。
上記の行動をPdMだけが実施しているわけではなくBe Animalにプロダクトチーム全体で実施できているところがチームの強みです。
おわりに
我々が現在鋭意開発中のデジタル証券で資産運用ができる個人向けサービス「ALTERNA（オルタナ）」は近日リリース予定です。
現在、リリースに先駆けて 事前登録受付中 なので是非以下のLinkまたはQRコードからご登録をお願いします！
共に働く仲間を募集中！
AM・証券会社の金融システムを創意工夫をしながら作っていく のに興味がある方を募集中ですので、少しでも興味を持っていただけた方がいましたら、是非以下からご連絡下さい！
