おはようございますこんにちはこんばんは。ROUTE06 取締役 CTO の重岡です。

創業 4 年目に突入した今年の 1 月に Tech blog を開設し、四半期を経て、私もようやく記事を執筆することができました。記事のネタを社内のエンジニアに相談したところ、

Q) 私も Tech blog 記事を書こうと思ってるので、どんな内容がよさそうか相談させてください 💭

A) ”マネーフォワード CTO が考えていること”を社外向けに公開しているのは良さそうだなーと思ってました 👀

という有益なアドバイスを頂きまして、真似して実践してみることにしました。

昨年 2022 年 11 月、CTO 就任時に考えていたことは ROUTE06 の取締役 CTO に就任しましたの記事にてご紹介させていただきました。

本記事では CTO 就任後、5 ヶ月を経ての振り返りと、今考えてることについてご紹介します。

Plain の現在地〜導入事例の公開と TVP の開発

今年 1 月のプレスリリースにてエンタープライズ向けビジネスプラットフォーム「Plain」の導入事例について公開させていただきました。直前の四半期は、今後導入先を増やしていくための準備として、まず技術的な基盤づくり TVP (Thinnest Viable Platform) の開発に取り組みました。TVP の開発において、各技術領域で取り組んだ内容は以下の通りです。

API や AWS を利用したクラウドインフラのマルチテナントアプリケーション対応
フロントエンド開発基盤の初期構築
データ基盤をシングルテナントアーキテクチャからマルチテナントアーキテクチャへリアーキテクチャ

Plain の構想〜クラウド EDI の機能開発とフルカスタマイズ可能なプラットフォーム開発の挑戦

現在 2023 年 4 月時点では、Plain の構想の 1 つであるクラウド EDI の開発に取り組んでいます。フルスクラッチで開発すると一年ぐらいかかる開発期間を大幅に短縮して、まずは 3 ヶ月以内に初期リリースできる状態を目標にしています。その先の理想の状態としては、1 日でリリースできる状態にしたいです。これらの目標から逆算して、短中長期的に取り組む issue をチームに考えてもらい、取り組んでもらっています。

チームトポロジーのエッセンスを取り入れたチーム体制変更

Plain の構想は、エンタープライズ領域で、フロントエンドをフルカスタマイズできる仕組みにした上で、フルスクラッチで開発すると一年ぐらいかかるプロダクトを 1 日でリリースできる状態に持っていくために、様々な issue を解決していく必要があると考えてます。

そのために、今月からチーム体制を変更しました。具体的には「チームトポロジー」と社内のソフトウェアエンジニアらの意見も参考にして、今まで 1 つのチームだった Plain チームを Plain Feature チームと Plain Platform チームの２つに分けました。これまでの体制だと、1 つのチームで機能開発とプラットフォームエンジニアリングをどちらも考慮しないといけなかったので、チーム分割をすることでフォーカスする領域を明確化しようという狙いです。

小さな Feature チームを複数組成

Plain Feature チームでは、クラウド EDI のデファクトとなる機能開発にフォーカスしていただきます。チーム人数が増えるほどチームの生産性が比例して向上しにくいという理由から、機能分類に Plain Feature チーム内に小さなチームを複数組成して、1 チームの人数が 5〜8 人のチームをたくさん作っていきたいと考えてます。そのためには、ドメイン境界を探索して決める必要があるので、最初から分けることはせず然るべきタイミングで分割していきたいと考えてます。

様々な Platform Engineering

Plain Platform チームでは、Feature チームが機能開発に集中できるような支援をしていただきます。

API Platform の観点では、モジュラモノリスでできることの技術的な検証だけして、あとは然るべきタイミングで分ける決断をしてやっていく。ROUTE06 社内でも度々 GitHub ex-CTO Jason Warner 氏のツイートを例に紹介されている通り、最初はモノリスでやる判断にしました。

Frontend Platform の観点では、フロントエンドの機能開発に Plain を導入先のプロダクト間での重複コードを極限まで減らすというお題目の元、様々な issue があります。npm package 化、ライブラリの開発、プラグインとしてのインターフェースを定義して組み込めるアプリケーションフレームワークの開発など、フロントエンドフルカスタマイズを実現するためならではのチャレンジングな issue だと思っています。

Data Platform の観点では、顧客企業がプロダクトリリース直後から事業全体におけるデータ活用ができる環境を提供に向けて、issue を取り組んでいます。事業数値が見れる BI 機能を汎用的に開発するために AWS マネージドサービスをフル活用して取り組んでます。

Design の観点では、クラウド EDI の理想のデザインを実現する以外にも、Plain が UI のフルカスタマイズを可能なプラットフォームという前提から、これを実現するために取り組むべき issue がたくさんあります。基本方針としては、我々が考え抜いたデフォルトのプロダクトが良いものという前提で使ってもらいつつ、導入先の事業特性に応じて UX に拘りたい部分はカスタマイズするというテイラーメイドを実現するために、これからチーム組成して取り組んでいきたいです。

最後に、セキュリティの観点では、今年 2 月に ISMS を取得できました。現在は SOC2 Type2 の取得にむけて準備を始めたところです。

ROUTE06 エンジニアリング組織の取り組み

技術広報〜 Tech Blog

冒頭でも触れましたが、ようやく ROUTE06 Tech Blog を開設できました。Tech Blog については執筆ノルマも期限も設定していませんが、既にいくつか記事が公開されており、今後も何本か公開予定の記事を控えています。私自身が Tech Blog ノルマみたいな運用することが嫌なので、能動的に書きたい人や得意な人に書いてもらう運用にしました。ROUTE06 エンジニア対談企画は、入社順に打診していて、ご協力いただける方のみ順番に記事にしています。

昨年に引き続き RubyKaigi 2023 へスポンサードさせていただきました。嬉しかったのは、社内のキーボード愛好家の皆さんの声で KeebKaigi 2023 へのスポンサードも決まったり、有志によるルートシックスラジオで開発チームの雑談回が実施されたりと、自然発生的に技術広報な取り組みが増えてきたことです。

エンジニアリングの幅と深さ

ROUTE06 も創業後 2 年ぐらいはフルサイクルエンジニアが活躍しやすい環境でした。現在もフルサイクルエンジニアの方が活躍していただける環境である一方で、特定の技術領域に特化したエンジニアの方にもご活躍いただける issue が用意できる状態になりました。

例えば、以下の職種はセキュリティや QA をこれまで以上に、エンジニアリングで向上させたいという思いから、つい先日募集要項を公開しました。

未公開の募集要項についても触れておくと Platform Engineer の募集要項を書く予定でして、既に公開済みの募集要項も順次最新にアップデートしていきたいです。また、Frontend Engineer は Frontend Engineer (Platform) と募集要項の細分化についても考えています。

初回、執筆してみての所感

初回ということもあり、気合い入れて ROUTE06 のエンジニアリングの取り組み全領域に触れようと思って書き始めましたが、連載を目指しているということもあり次回に取っておくことにしました。他にも、創業した 2020 年から開発しているプロダクトの技術的負債の返済や、事業成長しているプロダクトの話、10%ルールなるものがあるので、その取り組みなどについては公開できる時がきたタイミングで触れていきたいと思います。

以上、熊本からお送りしました。最後まで読んでいただき、ありがとうございました！