20-B-7 02/20 15:20 ～ 15:50
RubyとGoでゼロから作る証券システムー 高信頼性が求められるシステムのコードの外側にある設計と運用のリアル
「証券システムをゼロから作る」と聞くと、ものすごく特殊な世界に思えるかもしれません。しかし実際にやってみると、多くの学びはあらゆるWebプロダクトに応用できるものでした。本セッションでは、Ruby on RailsとGoを使ったオンライン証券システム立ち上げの経験を題材に、コードの外側にある視点も含めて高信頼システム開発のリアルをお話しします。
まず前半では、なぜRuby on RailsとGoという二言語構成にしたのか、その背景とシステム全体のざっくりした構成を紹介します。顧客情報や画面まわり、管理画面など変化に追従したい部分はRailsで、約定処理や残高管理などお金を直接動かすコア領域はGoで、といった具合に境界を引きました。『技術的に書きやすいから』ではなく、『どこでミスしたら致命傷になるか？』という観点で責務と言語を分けていったプロセスを共有します。
以降は、この高信頼システムを支える三つの柱として話を進めます。1つ目はアーキテクチャと境界設計、2つ目はお金が本当に合っているかを検証する仕組み、3つ目は二言語構成がもたらしたチーム文化とインシデント対応です。
第1の柱：アーキテクチャと境界設計
Rails側とGo側で『ミスしたら致命傷になるポイント』が違うという話を掘り下げます。Rails側は主に顧客のデータ管理を担っており、たとえば個人情報の扱いを間違えれば、情報流出や誤った顧客紐付けといった形で信頼を大きく損ないます。一方、Go側は約定や残高管理といったお金そのものを扱う領域を担当しており、取引内容を間違えたり、保有資産や残高を誤って計上したりすると、直接的な金銭被害につながります。同じ【致命傷】でも質が異なるため、それぞれのリスクに合わせて設計やレビューの濃度を変えたり、冪等性・リトライ戦略の置き方を変えたりしてきました。こうした『どのレイヤーで何が壊れると一番つらいか』をモジュールごとに整理し、境界設計に反映していった具体例を紹介します。
第2の柱：お金を守るための検証・ダブルチェック
金銭管理を確実に行うために、どのようなチェックを行っているかをご紹介します。
ブルーモ証券側のシステム・米国側の証券会社のシステム・外部の証券管理システムという三つのシステム間で、各種の値が合っているかを継続的に検証するプロセスを整えています。たとえば、取引単位・銘柄単位・残高単位で照合を行い、どこか一か所でも差分が出た場合には、インシデントプロセスを発動させ調査にあたるようにしています。
第3の柱：二言語構成がもたらしたチーム文化とインシデント対応
技術選定が組織に与えた影響にフォーカスします。RailsとGoでコンポーネントを分けつつも、「Railsチーム」「Goチーム」と縦割りにするのではなく、顧客の関心領域でチームを分けてオーナーシップを持つ体制にしたお話をします。
また、実際のインシデント対応の場面では、ビジネス、オペレーション、エンジニアがどう連携したのかを具体的に紹介します。障害の検知から影響範囲の特定、顧客・社内への説明、恒久対応までを一連のプロセスとして整理し、ふりかえりを通じてプロダクト仕様や運用手順にフィードバックすることで、トラブルが起きるたびに組織として強くなるサイクルを回してきました。ここでも、『誰のせいか』を追及するのではなく、『どうすれば再発を防げるか』をチームで考える文化づくりに触れます。
金融に限らず、 「お金や信頼を扱うサービスで、どこまでなら自分たちで作れるのか？」に悩む方に、高信頼システムに向き合うときの具体的な視点と、コードの外側まで含めた開発と運用のイメージを持ち帰っていただければと思います。
