株式会社FOLIOの次世代証券システムをひもとく

これはFOLIO Advent Calendar 2017の25日目の記事です。昨日は弊社CTOである椎野(tshiino48)による「IOTA ~ポストスマートフォン時代のフィンテック~」でした。

qiita.com

本日はFOLIO Advent Calendar最終日、締めの記事を「株式会社FOLIOの次世代証券システムをひもとく」と題して、Head of Engineeringの伊藤(@itohiro73)が務めさせていただきます。

株式会社FOLIOでは、フォリオという、個別銘柄ではなくテーマを選んで投資するオンライン証券サービスを提供しています。

https://folio-sec.com/ *図表やデータ等はあくまでもサンプルであり、将来の運用成果等を示唆あるいは保証するものではありません。また、サービスの詳細はこちら

本エントリーでは株式会社FOLIOを支える次世代証券システムについて、機能面とエンジニアリングの両方の視点から解き明かしていきたいと思います。

PORT + FOLIO

株式会社FOLIOには大きく分けて「FOLIO」というオンライン証券サービスと、「PORT」という証券業務システムの二つのプロダクトが存在します。

f:id:itohiro73:20171220174006p:plain

FOLIOとは

ここで解説する「FOLIO」はフォリオのサービスを構成するシステム群全体を表すプロダクト名です。まさにユーザーが直接接するプロダクトのことですね。株式会社FOLIOと同じ綴りですが、ここでいうFOLIOはプロダクトそのものの名称なのです。ちなみに、FOLIOの中にも厳密にはFOLIO-WebとFOLIO-Mobileが存在しており、FOLIO-MobileではiOS(Swift + Redux)とAndroid(Kotlin + Flux)での実装が現在開発進行中です。

今回はすでにβ版としてリリースされているFOLIO-Webに軸足をおいて説明します。 f:id:itohiro73:20171220233210p:plain FOLIOのフロントエンドはBFF(backend for frontend) on Node + React/Redux というモダンなアーキテクチャーで構成されており、BFFの裏側はScalaのマイクロサービスで構成されたバックエンドシステムとThriftによる通信でコミュニケーションを行なっています。ユーザーの口座情報やポートフォリオなどのマイクロサービスが提供する情報をBFFが集約し、サーバーサイドレンダリングした上でユーザーに表示しています。

実際の取引には受発注処理のためのマイクロサービスの実装があり、株式会社FOLIOとお客様の相対取引を執行する店頭市場の実装、そして株式会社FOLIOが外部の証券ブローカーへFIXプロトコルを通じて取引を発注・約定するためロジックが実装されています。

現時点で20を超えるマイクロサービスが存在しており、Consulによるサービスディスカバリ、Fluentd/Kibanaによるサービスログ集約・可視化やSlackへのアラート通知、Zipkinによるサービス間トレース、Prometheus/Grafanaによるインフラ監視・ダッシュボードの整備等々、サービスの成長に従って増加していくマイクロサービスやそれを支えるインフラを管理していくにあたって重要なミドルウェア群も整備されています。

証券会社としてはかなりモダンでチャレンジングなアーキテクチャーを採用しており、エンジニアリングの側面からも非常に面白いシステム構成になっています。

FOLIOのチャレンジ

証券会社のサービスとはいえ、FOLIOの構成は一般的なWebサービスのマイクロサービスアーキテクチャーとも言えますし、ぱっと見普通のWebサービスのような開発が行われているのだろうと想像されがちです。しかし、証券の取引やお客様の資産を扱うという面において非常に繊細かつ高度な品質が要求され、通常のWebサービスと比べても機能面・技術面の両方において非常にチャレンジングな側面を持っています。

機能と技術両方において難しい一つの典型的な例をあげると、たとえばコーポレートアクションという機能。

コーポレートアクションとは、「企業の活動」という意味ですがその中でも特に有価証券の価値に影響を与える企業の意思決定のことをさし、具体的には株式分割、株式併合、株式移転・交換・合併などが含まれます。

このコーポレートアクション、機能的にはそもそも扱わなければいけない状態数が非常に多いために、UXデザイン、フロントエンドやバックエンドの要件定義と実装、テストを行うだけでも膨大なリソースと相当なエンジニアリング力が試されます。

技術的には、情報の更新タイミングを合わせるための難しさがあります。たとえば株式分割という事象では、お客様の資産において「保有株数」と「株価」というふたつの情報が違うタイミングでシステム上の変更が行われます。お客様が最終的に興味がある「保有資産評価額」はこのふたつの情報をもとに計算されます(「保有資産評価額」= 「保有株数」x「株価」)。このふたつの情報更新のタイミングの違いによりデータベース上でシステム反映時間とビジネス的な有効時間情報の両方を同時に表現する必要があり、これは技術的に非常に扱いが難しいものになります。

この問題の解決のために弊社ではreladomo-scalaというOSSを開発し、活用しています。本OSSScala関西Summit 2017で公開され、当該セッション資料にもコーポレートアクションの例が記載されているため、興味がある方はのぞいてみてください。

www.slideshare.net

PORTとは

PORTは、顧客が日々直接接するWebサービスのプロダクトであるFOLIOとは違い、証券会社の内部業務を支えるミドル・バックオフィスシステムの総称で、株式会社FOLIO独自のプロダクト名です。実は、証券会社が業務を行う上では証券取引の性質上行わなければいけない業務や、さまざまな法律や規制に基づいて規定された必要業務が存在しており、それらを支えるPORTは株式会社FOLIOの心臓部とも言えるシステムなのです。

PORTという名前には、FOLIOというサービスプロダクトを毎日無事に出港させるための港(Port)でもあり、PORT+FOLIOが両方合わさって初めてPortfolioという概念が完成される大事なシステム、という想いが込められています。

では、PORTとは一体どういう機能を持つものなのでしょうか。すべてを事細かに紹介することはできませんが、おおよそ下記のような業務機能をサポートします(未実装の機能も含まれます)。

顧客口座管理

口座開設のための本人確認や、必要情報の整備、カスタマーサポートに必要な顧客情報等を管理します。

取引管理

約定や決済の情報管理やそれらの処理が正しく行われているかどうかの突合処理、コーポレートアクション情報の管理などが含まれます。

入出金管

銀行とお客様のフォリオ口座の間の入出金処理や履歴を管理し、金額情報に誤りがないことを担保する重要な機能をサポートします。

報告書作成

お客様への取引報告書や法定帳票の作成をサポートします。

財務処理

自己資本規制比率を算出し、証券会社としての財務の健全性を保つための業務をサポートします。

リスクコントロール

自己勘定取引におけるポジションリスクの管理や、ヘッジのための機能を提供します。

コンプライアンス業務

コンプライアンスに関わる売買審査や社内コミュニケーション管理、監査情報の管理等をサポートします。

投資委員会業務

フォリオで提供するテーマの銘柄選定や入稿をするための業務をサポートします。

上記のように、PORTでサポートする機能は多岐にわたり、会社の業務を支える重要な要件や、法律や規定によって定められた複雑な要件を満たす必要があります。たとえば「本人確認」といったひとつの業務要件においても、顧客ユーザー、社内ユーザー、社外システム等のそれぞれのアクションによって異なる状態遷移を管理する必要があり、非常に複雑でかつ高品質を求められる業務システムになっています。

PORTのアーキテクチャとBPMN/ワークフローエンジンの活用

PORTに関しては、フロントエンドがRuby on Railsによって作られている以外はFOLIOとほとんど同じ構成で、バックエンドのマイクロサービスアーキテクチャFOLIOと同様Scalaによるマイクロサービスが配置されており、Thriftによる通信でサービス間コミュニケーションをしています。サービス監視やインフラ構成もFOLIOと同様の構成です。

f:id:itohiro73:20171220233250p:plain

実はPORTの機能の多くはいわゆる業務システムであり、さまざまな状態遷移をもつワークフローに基づくものが多いです。このような性質をもつ業務の要件定義を行う際に、BPMN(Business Process Modeling Notation)と呼ばれるモデリング記法が非常に役立ちます。

www.bpmn.org

BPMN自体は業務フローのモデル化のための記法にすぎませんが、BPMNと組み合わせてワークフローエンジンを活用することで、モデル化したフローをの大部分をコード生成し、実装コストを大幅に下げることが可能だと考えています。

FOLIOでは現在オープンソースのBPMNワークフローエンジンであるCamundaに着目しており、この技術でPORT開発と業務フローの改善ができないかの検証に着手しようとしています。

camunda.org

PORT+FOLIOの誕生秘話

このように、PORT+FOLIOは次世代証券会社を支えるシステム構成であり、それぞれが非常にモダンかつエキサイティングな技術によって支えられています。

しかし、PORTというプロダクト概念はまだ産まれてから半年強しかたっておらず、フロント以外のバックエンド構成はFOLIOと密に結合してしまっています。これは、FOLIOというベンチャー企業が誕生してから約一年半、これらの概念が認識される余裕もないまま一気にシステムが成長してきてしまったことに起因しています。

実は半年ちょっとくらい前まではPORTという名前も概念も存在せず、その機能の一部であり社内ユーザーが触れるRuby on Railsのフロントエンドの機能群が単に「管理画面」と呼ばれている状況で、その重要性やプロダクトとしての地位、エンジニアが機能開発にとりくむモチベーションさえもが非常に低い状況でした。これは由々しき問題です。

上記で述べたように、証券業務の機能は株式会社FOLIOの心臓部ともいえる非常に大事なシステムであり、重要な概念として認識される必要がありました。今年の春に証券会社出身のエンジニアが何名かジョインした後にこれらの概念が整理され分類されることで、顧客に提供するWebサービス証券業務システムふたつの概念としてまずは認識されるべきだという提案が共有されました。

この概念整理に伴って証券業務システムにも愛着の持てるエキサイティングなプロダクト名が必要だろうということで社内で名前募集をした際にPORTという名前が提案されました。その提案がなされた際の、まさにその瞬間の社内Slackのキャプチャ。PORT爆誕の瞬間です。

f:id:itohiro73:20171220190618p:plain

われわれは会社全体としてビジネス陣、クリエーター陣(デザイナ+エンジニア)含めて、証券業務システムをサービスプロダクトであるFOLIOと同じくらい重要視しつつ育て上げていくというマインドを育んでいく必要があり、PORTという命名はその第一歩だったのです。

そして、最初に載せたこちらのイメージこそが、PORT + FOLIOの目指していく姿を共有するためのプロダクトビジョンでもあるのです。

f:id:itohiro73:20171220174006p:plain

PORT+FOLIOの未来

FOLIOとPORTというふたつのプロダクトの概念を説明しましたが、上でも述べたように、実はフタを開けてみるとこれらのシステムは互いに密に結合してしまっています。PORTは概念として誕生し、育まれてきましたが、まだ完全に独立したライフサイクルをもつシステム群としては存在できていません。

特にバックエンドに関してはポートフォリオ管理サービスや受発注処理サービス等、FOLIOを構成するマイクロサービス群の一部から直接のAPI提供も受けており、決済やポジション管理に必要なバッチ処理FOLIO側のバックエンドサービスに直接接続するなど密な構成になってしまっているのです。

本来であればこれら二つのプロダクトは、全く違う対象ユーザー、システム要件、ライフサイクルの性質を持っており、それらをふまえた適切なアーキテクチャやPORT<=>FOLIO間のメッセージングの設計、また、それぞれのプロダクトに対応したエンジニアチームの編成もつくっていきたいところです。

理想としては、FOLIOは最高のUXと高品質なサービスを提供するためにアジャイルなリリースサイクルをまわしつつグロースハック施策をうつ、PORTは必要な業務要件を適切に吸い上げながら堅牢なシステム構成と高い品質を保った開発リリースをまわしつつコスト削減をめざす、といった形で全く違う開発ライフサイクルを持つべきであり、そのためにもアーキテクチャ分離がなされている必要があります。

しかし、現在のPORT+FOLIOアーキテクチャーでは適切なサービスモジュール分離と完全な開発リリースサークルの分離はまだ完全に達成されておらず、互いに密な設計、テスト、リリース計画を行う必要がある構成になってしまっています。

もちろんPORT用途のAPIサービスが一部分離されていたり、PORTフロントエンドのリリースサイクルの分離が推進されていたりと、改善してきている部分は多くあります!が、本来あるべき姿に到達するまでまだまだやるべきことは山積みです。

そして、PORTに関しては現在外部システムとの連携や外注システムの利用に頼っている部分があったり、まだ完全にシステム化されておらずマニュアル作業にたよっている機能も多く存在します。株式会社FOLIOの長期的な成長とコスト構造改善を推進していくためにも、これらのPORT機能を内製化していくことは非常に重要なアクションと言えるでしょう。

つまり何が言いたいのか...?

この記事を読んでいただいたことで、株式会社FOLIOの次世代証券システムのエンジニアリングに興味を持ったあなた、FOLIOの最高のUXづくりとアジャイル開発プロセスを推進したいモダンな技術に興味があるエンジニアのあなた、PORTの堅牢な証券業務システムづくりに興味がある重厚感を持ったエンジニアのあなた、PORT+FOLIOアーキテクチャ分離とリリースサイクル改善に興味をもった改善マインドを持ったエンジニアであるあなたと、われわれはぜひ一緒にこれらの施策を推進していきたいと考えております!

興味を持った方は、ぜひ下記の募集要項からご自身の興味のある職種にご応募ください。

www.wantedly.com

本日は「株式会社FOLIOの次世代証券システムをひもとく」と題しまして、弊社の2大プロダクトであるFOLIOとPORTについて解説しました。これを持ちましてFOLIO Advent Calendar 2017の最終エントリーとなります。本エントリーでFOLIOに興味を持った方はアドベントカレンダーの他の記事ものぞいてみてください。多種多様な記事があって面白いですよ!

それではみなさん、メリークリスマス!素敵な年末をお過ごしください。