「商品口座プロジェクト」開発者インタビュー前編〜将来を予測しながら作り上げる〜

みなさんこんにちは、FOLIO採用担当です！

今回は約一年かけてゴールに辿り着いたあるプロジェクトについてお話したいと思います。

※本インタビューは2021年1月に行ったものとなります。

このプロジェクトには多くの方が関わっていたのですが、今回は代表してFOLIO証券基盤部の高山さんと松林さんにお話をうかがいたいと思います。今日はよろしくおねがいします！

高山さん、松林さん（以下、高山、松林）：
こちらこそよろしくおねがいします。

商品口座プロジェクトとは？

司会：
今回のインタビューでお二人にお聞きしたいのは、2020年の夏に終了した「商品口座プロジェクト」のお話を中心に、FOLIOへ入社した経緯やお二人の経歴なども聞かせていただければと思っております。まずはじめに商品口座プロジェクトのことから聞きたいのですが、これはどのぐらいの期間で動いていたのですか？

高山：
スタートしたのが2019年の10月で、終わったのが2020年の7月14日なので、スタートアップとしては長い9ヶ月にわたるプロジェクトです。

司会：
9ヶ月とは、確かにスタートアップにしては長期にわたるプロジェクトですね。色々大変だった点も多いと聞いています。ですがその前に、そもそも「商品口座とは何か？」について教えてください。

高山：
FOLIOのプロダクトには、最新の金融工学に基づいた資産運用サービスであるロボアドバイザー（通称ロボアド）の一種である「おまかせ投資」と、LINEスマート投資上で運用ができるロボアドバイザーの「ワンコイン投資」というサービスがあります。これに加えて2020年1月から「ROBO PRO」というロボアドバイザーも提供しておりますが、それらロボアドを運用する基盤の部分を、社内で代名詞的に「商品口座」と呼んでいたんです。

司会：
なるほど、その商品口座プロジェクトが大変だったんですね。どういう点が大変だったのでしょうか？

松林：
ロボアドの資産管理システムはやることが多くて、資産の管理や注文状態も管理しないといけないんです。また、運用方式の調整が必要だったり、ロボアドは運用を自動でしてくれるわけですから、今の資産と理想のポートフォリオの差分をみて、最適ポートフォリオ※になるように、ちゃんと売買するようにしなくてはいけないなど、色々と検討事項があったんです。

「おまかせ投資」をリリースしたのは2018年の10月なのですが、ロボアドの資産管理システムは当時、外部に委託して開発していただいたんです。 社内リソースが足りなかったのが主な理由だったんですが、上記のような課題の分析が十分でない状態でアウトソーシングしたので、結果としてはかなり手間のかかるシステムができあがってしまったんです。

システムを作るのって、色々なことが自動化されるのがメリットですよね。でもその導入したシステムは、一部の作業を手動でやらないといけなかったんです。そういった部分の自動化対応や将来のスケールアウト、また自分たちのノウハウを貯めながらメンテナンスや運用の負担を減らすということも考え、当時と比べると体制も充実してきたので外注していたシステムから内製するシステムに置き換える、というプロジェクトが立ち上がったんです。これが商品口座プロジェクトです。
（※最適ポートフォリオ……最適と考えられる資産配分のこと）

司会：
なるほど、技術的に一番大変だった点があったら教えてください。

未来を見据えて開発することの大変さ

松林：
技術的な部分とはちょっと違うんですが、本来ならばリプレースに力を入れるよりサービスを洗練させる方に工数を割いたほうがビジネス的にはよいはずなので、スピーディには作りたかったんです。かといって、同じようなシステムだとリプレースする意味がないのでどこまでリッチに作るか、そのあたりの落とし所をどうつけていくかの判断は難しかったですね。

司会：
たしかに、商品口座プロジェクトは、サービスの裏側の話なので、ユーザーからは直接見えない部分ですよね。もし9ヶ月あったら、ユーザーが直接タッチできるような新しい機能とかサービス改善など、色々なことができると思うのですが、そこの工数を減らしてでもボトムである基盤の部分をもう一度作り直そうと考えたのは、そこになにか哲学や考えがあったのでしょうか？

高山：
そこがまさに大事なところなんです。きちんとシステムのことを理解していないと、その後のサービスの拡張性に大きな影響が生じてしまうんです。具体的な話だと、先程お話したサービスで「ワンコイン投資」と「おまかせ投資」は、以前のシステム上だと一人のお客様が両方のサービスを同時に使えないというウィークポイントがありました。

というのも以前のシステムは、一人のお客様は一つのサービスしか使わないであろうという前提で作られていたんですね。そういう前提で開発されたので、前提から覆さないといけない状況だったんです。

大切なことは、将来こういうことをやろう、というイメージがあって、そこから逆算して今何をやらなくてはいけないのか？ということを考えてシステムを作ることなんです。そうすれば拡張性を持って色々とできるようになるはずなんです。その部分を考えずに単に改善や改良を繰り返すだけでは難しくて、そもそもの前提を今持っている知見や技術でどうやって作り直そうか？ということを考えて基礎から直していかないと、改善したくてもできないという状況でした。

松林：
きちんとシステムのことを理解しておくのは本当に大切なのですが、それと同時にビジネスや事業領域自体の理解も大切なんですよね。というのも、最初に「おまかせ投資」を作った時には、まさか一つの会社でロボアドを複数展開するなんて思ってもいなかったんです。ですからシステムのことを考えつつ、今後事業がどのように展開していくのかも考えて、システムを運用しながら学んだことのエッセンスを入れて取り組んだり、業界の新しいノウハウなども入れて整備していったんです。

安定した運用のため、技術的にどう工夫するか？

司会：
商品口座の開発において、大変だったことや苦労した部分があったら教えてください。

高山：
大変だったことは、将来どのようなサービスを組み入れる可能性があるか、ということを考えながら設計していったので、未来を予測しながら作り上げる必要があったことですね。また比較的大きなシステムですから、設計も複雑で大変でした。

新しく作った商品口座と、そこで使われている発注の自動化という仕組みは基本的にバッチの繋がりで作るのですが、そのバッチ自体が90を超える数で、しかもそれぞれのバッチが独立した責務をもっていて、きちんとそれぞれが閉じた世界で作られないといけないんです。最近のアーキテクチャで言うとモジュラモノリス※1のイメージに近いですね。

やるべきことや作るべきものがとても多いことによって、それぞれのつながりを意識しつつ全体をきれいに整えていくことが大変でした。しかも9ヶ月間ずっと開発をやっていたわけではなくて、実は設計も2019年10月から2020年4月まで続けていて、設計書を書きながら全体として整合性が取れているかを確認しつつ、横で開発を進めていました。設計の部分がきちんとしていないと、開発した時に手戻ってしまったり失敗してしまうので、事前に「これだったら問題なくいけるだろう」とある程度目星をつけてから開発に着手するという繰り返しを、約半年やり続けたのが大変でした。
（※１モジュラモノリス……複数の機能や責務を持ったアプリケーションのうち、機能や責務をある程度適切に分割し、それぞれの依存関係を疎に保ったものを指す。）

司会：
設計の部分はチームでやったのでしょうか？それとも高山さんお一人で？

高山：
今回は私がメインで設計をやらせていただきました。というのも、元々以前に請負で作ってもらったシステム自体の知見を持っているのが、私と他数名のエンジニアしかいなかったからです。

また設計にはFOLIOのサービスをこれからどうしたいのか？どういうサービスへと進化させていきたいのか？という点も考慮にいれないといけませんから、そういう世界観とどう繋げていくかを考える必要がありました。これらをエンジニアのみんなに投げると現場が確実に混乱しますよね。ですから私の方で一度考えて内容を噛み砕き、方向性をある程度作ってからみんなで議論するという流れを作りました。

松林：
高山さんが担当していた設計もかなり大変だったと思うのですが、みんなで全体像を把握して開発を進めるのも結構大変でした。全体像を理解せず部分的に自分が実装する部分だけ理解していると、他の箇所と結合した時に全然思っていたのと違っていたりとか手戻りが多くなってしまうんですよ。

あとは「このバッチは○○さんが実装したので、○○さんでないと障害対応できません」みたいな状況になると、安定した運用ができないんです。ですからメンバーみんなで全体像をみながら、設計を全員で俯瞰しながら理解していって、個別の実装を進めていくというループを作るのが結構大変でした。