こんにちは、システム開発一部長の上川です。
昨年まではシステム開発部の中で次世代システムを考えるというミッションを与えられた、GX推進グループのグループ長をやっていましたが、1月にシステム部門の組織改編がありまして、システム開発部が3つの部門に分かれました。
その中の一つで、主に現行基幹システムの開発や保守を行う、システム開発一部の部長をやらせていただいております。
さて、ではこの組織改編でGX推進グループはどうなったかというと、、、
はい、相変わらず上川がグループ長としてやらせていただいておりますです。
ここまで読んで、次世代システムの検討が不調に終わって、解散してしまったかと焦った方もいるかもしれないですが（いないですね（笑））兼務という形でちゃんと継続しています！ヨカッタ！
と、 前置きはここまでとして、先日本部長の安原よりこんな記事が出ましたね。
blog.tech-monex.com
この記事中で書かれているPoCを行っていたのが、GX推進グループのこの1年の活動です。
ちなみにスタート地点の昨年4月の段階では、上川はこんな記事を書きました。
アンサーソングが書けるように完走したい！なんて言っていましたが、なんとか一定の結果を出して、次のステップに進むことができたのでよかったです。
もう、基幹システム全体の一括刷新なんてことはできないよ
マネックスは2017年に証券基幹システムを自社内製システムに刷新しました。
この時は、従来使っていた基幹システムと同等の機能やサービスを全て構築してから、年末年始に一気に新システムへ移行するという荒業をやってのけたのですが、当然ですが気が遠くなるような時間とコストをかけています。
あれからもう4年が経ち、技術刷新や変化のスピードが急速に上がっている世の中で、もう一度同じことをやっていたら、世の変化に全くついていけませんよね。
スタイルチェンジします
ということで、今回次世代システムをどのように考えたかを説明してみようと思いますが、安原の記事にあったスタイルチェンジをタイトルだけちょっと引用しちゃいましょう。
システムの作り方のスタイル・チェンジ
全体をまるっと作ってから使うようなことはできないので、 一部を切り出して少しずつ刷新していくようなやり方にするため、次世代システムのベースになる考え方は、「マイクロサービス化」です。
インフラのスタイル・チェンジ
マイクロサービスの基盤は、コンテナであり、CI/CDであり、スケーラブルであり、といったようなものになりますので、必然としてプラットフォームはクラウドになります。
エンジニアのスタイル・チェンジ
現行基幹システムは典型的なモノリスの塊ですので、新しいアーキテクチャや基盤、サービスなどを柔軟な考え方で使いこなしていけるエンジニアが必要です。
ビジネスのスタイル・チェンジ
組織のスタイル・チェンジ
このあたりは、省略！
（タイトルは Gartner 亦賀氏 2020年セミナー資料より引用されています。詳細は上述の安原の記事内にて。）
次世代システムPoCは、このような考え方のもとで行いました。
最大の敵は、余力
証券基幹システムのマイクロサービス化を考えるときに、どういう切り口でドメイン分割をするかとか、そういう一般的な悩みに直面する以前に、まず「余力」をどのように料理するかが、必ず大きな壁として立ちはだかるだろうということが見えていました。
余力って何よ
余力余力って言っているけど、一体それは何者ぞ、とみなさん思いますよね。
余力＝パワー＝開発リソース？、が足りるかどうかなんて、そんなの当たり前じゃないか、と。
マネックスの証券システムで言う余力とは、「買付可能額」のことを指します。
つまり、あなたは今いくらまで金融商品（株や投資信託、債券など）を買うことができるのか、という金額です。英語だと Buying Power と言ったりもします。
余力は超有名人
この余力さん、想像してみるとわかると思いますが、証券システムのあらゆるところに顔を出す有名人なんです。
ある人が100万円入金して10万円の株を買ったら、次に買う商品が株であっても、投資信託や債券など他の商品であっても、90万円分しか買えないようにしないといけません。
もちろん、証券口座の外に出金できる金額も90万円までです。
このように、あらゆる商品を買ったり売ったりするとき、そして入出金が行われる時など、あちこちで余力が関係してきます。
単純に入金された金額から、使った金額を引くだけではなく、株の信用取引のことを知っている方であれば、保証金の約3.3倍まで買付が可能だったり、代用有価証券と言って、保有している株の価値を一定の割合で評価して信用取引の保証金として買付可能額に加算したりするような計算もあったりするのをご存じの方もいらっしゃるでしょう。
余力をどのようにドメイン分割するべきか
このような有名人である余力は、モノリスシステムの中であれば大きな問題にはなりませんが、マイクロサービス化を考える時には、余力をどういうドメインとして考えるかが非常に大きなテーマとなります。
PoCでは、余力を独立させました
昨年4月にGX推進グループが組織されて、ひと通り各金融商品の機能や業務を洗い出してきたあとに、それを一枚一枚カード化して、リフレッシュスペースにあるテーブルを大量に連結して、そこに大きな模造紙を展開して何時間も独占し、模造紙の上でカードをあっちこっち移動させながら、ああだこうだドメイン分割の構想をグループ内で検討するという、リフレッシュスペースで休憩したい人達には迷惑極まりない行為を何日も繰り返した結果、余力を一つのドメインとして独立させてみることにしました。
作ってみなきゃわからん
結局、マイクロサービスにおけるドメイン分割は、「関心ごとの単位」で分割するのがセオリーであり、これに失敗してしまうと切り離したはずのサービス間に依存関係が残ってしまって、せっかくのマイクロサービスが全然活きなくなってしまいますが、その関心ごとの単位というものに、一つの正解があるわけではなく、作って動かしてみて不都合があったら考え直す、というプロセスが絶対に必要です。
もちろん、最初から適当に考えていたらそのやり直しの回数がいたづらに増えてしまいますので、どれだけ真剣に考えて答えを出せるかが正解への近道になるわけですが、我々はまず、余力を独立させてみたということですね。
思ったよりシンプルに作ることができた、、、気がする
このPoCを始める前には、余力が大変だろうなという漠然とした不安感があったのですが、現行の証券基幹システムの余力機能には、余力とは直接関係ないような機能をたくさん持ってしまっていることがなんとなく見えていましたので、まずはそこの分析から入りました。
例えば、余力機能の中で実施してしまっている株専用の処理は、株ドメインの中で実施するようにする、といった感じで、余力と直接関係ないものをできる限り削ぎ落としていって再構成してみるといった感じです。
すると、他のドメインとのAPI連携をしっかりと考えておけば、そこまで複雑なドメインにはならないことがわかりました。
もちろん、PoCでは完全な機能を作り切ったわけではないので、今後細部をどんどん詰めていったら大きな問題にぶち当たる可能性がないわけではないです。
もう、作り始めます！
余力の検討にメドが見えてきたところで、株と投資信託を基本機能に絞った形で売買ができて、上のような考え方で作った余力サービスを実装したデモシステムを作成して、これらをしっかり機能させることができました。
PoCを完璧にやるのが最終目的ではありませんので、ここまでで一定の結果を得ることができましたので、この4月からはいよいよ本番サービスとして利用することを目的とした次世代システムの構築を開始します。
栄えあるマイクロサービス化第一号に選ばれたサービスは、、、うまく出来上がらなかったら恥ずかしいので、秘密にしておきます（笑）
ちゃんとリリース出来たら、ブログで報告しますね。
構築を開始します、なんて簡単に書いてしまいましたが、これから考えて決めていかないといけないことは山のようにあります。
と、いうことで、途中でつまずいて頓挫するようなことがなく、順調に次世代システムの構築が進められるように、頑張っていきたいと思います！
