厳しい制約条件の下で、既存パッケージに頼らないUI/UXを追求
証券会社を創業して金融サービスを立ち上げるには、金融商品取引法や個人情報保護法、犯罪収益移転防止法など、数多くの法律や業界団体のルールに従わなければならない。従来、金融機関のシステム開発において外注中心の多重下請け構造が一般的だったのは、既存ベンダーのパッケージを導入すれば、規制の多くの部分に対応できるという背景があったからだ。
しかし小林氏は「既存のパッケージを入れるだけで多くのルールに対応できますが、我々のような小さい会社だと、なかなかそういうこともすぐにはできません」と述べる。
せっかくゼロから作り上げるのであれば、使いやすいUXで本格的な長期投資ができるという価値をユーザーに届けたい。ブルーモ証券が目指したのは、本格的な長期投資をスマホで手軽に体験できるネイティブアプリの構築だ。米国株やETFに対象を絞ることでドメインを限定しつつ、将来のスケールを見据えると、システムが1つの巨大なモノリスになって身動きが取れなくなることは回避したかった。そのため、立ち上がりのスピードと、内製開発においてメンバーがモチベーションを維持して開発を続けられるモダンな技術選定が必要不可欠だった。
「3つの複雑性」をマッピングして導き出した技術選定
このような背景のもと、スマホアプリのUI/UXを損なわないよう、フロントエンドにはクロスプラットフォームで一貫した開発ができ、投資アプリとして十分なパフォーマンスを発揮できるFlutterを採用。またインフラには、将来的なマルチクラウドへのポータビリティ確保や、自動復旧・オートスケールの仕組みを整えるため、Kubernetesを導入した。
技術選定でもっとも迷ったのは、ビジネスロジックを構築するバックエンドの言語選定だった。ここで小林氏らは、ソフトウェア開発においてビジネスロジックレイヤーの採用技術を決めるための考え方である「本質的複雑性」と「偶有的複雑性」という観点を、「本質的複雑性」「機能面における偶有的複雑性」「技術面における偶有的複雑性」の3つに分解して検討。「本質的複雑性」とは取引ロジックや税制対応など、対象となるドメインそのものの難しさ、「機能面における偶有的複雑性」は本人確認や通知など、対象としたドメインに付随する機能面の複雑さや難しさ、「技術面における偶有的複雑性」は言語の制約や環境構築といった採用した技術に起因する難しさだ。
小林氏は「これらの複雑さをいかにして解決できるかという点が、事業の勝敗を左右します」と語り、この3軸で主要言語をマッピングした図を提示。各言語のメリットとデメリットのトレードオフを客観的に評価し、アーキテクチャの選定へとつなげていったことを説明した。
こうした分析の結果、Ruby on Railsはミドルウェアを選定する必要がなく、強力なエコシステムと豊富なライブラリ（Gem）によって、認証や本人確認の実装に伴う「機能面における偶有的複雑性」を迅速に解消できるという強みが、改めて浮き彫りになった。しかし一方で、動的型付けの特性から、一定の規模感があるチームでドメインロジックを記述していくと「技術面における偶有的複雑性」を誘発しやすいという懸念があった。
それとは対照的に、Goは言語としての表現力が制限されており属人性が低いことから、長期にわたり保守しやすく、チームの規模が拡大しても問題が起こりにくい。つまり「本質的複雑性」を安定して維持することができる。ただし、シンプルな言語であるがゆえに愚直に大量のコードを書く必要があり、「機能面における偶有的複雑性」の面では不利となる。
