M&Aナビの技術スタックリプレイスの背景と経過
M&Aナビ第二創業のファーストメンバーとして2021年4月からCTOを務めています。吉岡と申します。
弊社は第二創業で「開発力・プロダクト力を強みにしたテックカンパニーに生まれ変わる！」という決意とともに、技術スタックの全面リプレイスを行いました。今回はその理由・狙いと効果の暫定的な検証を整理・共有しようと思い、記事を書いてみることにしました。
リプレイス前の構成
リプレイス前は以下のような最低限のシンプルな構成でした。
- Ruby on Railsのモノリシックなアプリケーション
- CI/CDはCircle CI
- AWS EC2にcapistranoでデプロイ
- DBはAurora mySQL
よくあるスタートアップのMVPって感じの構成だと思います。前CTO（現CEO）が0から構築したプロダクトでした。
プロダクトの特徴とフェーズ
M&Aナビは事業承継・中小企業M&Aのオンラインマッチングプラットフォームです。
企業や事業の売り手ユーザーが案件情報を掲載し、買い手ユーザーとコミュニケーションし、契約成立までをオンラインで完結することを目指しています。
2021年4月時点では、すでに3年程度運営しており、完全にオンラインで完結しきるまでの機能は実装しきれていないが一定のユーザーがすでにいる状態でした。
リプレイスの目的
当初の主な狙いはフロントエンドの洗練でした。最初の開発開始から3年ほど経過していて機能的には固まってきたので、UI/UXを洗練させていくためにモダンなフロントエンドのフレームワーク導入してフロントエンドとバックエンド分離しよう、というのがスタートだったと思います。CSSがグローバルでメンテナンスしづらいという現実的なつらみもありました。
せっかくリプレイスするならってことで、その他の技術スタックも一緒に見直してみることにしました。
技術選定過程
フロントエンド (React/Next.js)
まずは主たる課題であったフロントエンドの技術選定から始めました。
2021年現在、安心して採用できる現実的な選択肢はほぼReactかVueの2択と考えました。公開された売却案件ページに対してSEOでの流入も狙いたいので、SSG/SSRは必要だろうということでNext.jsかNuxt.jsか、という観点も入ってきます。
両者のPros&Consは散々議論されているので細かく立ち入りませんが、決め手はTypescriptとの相性でした。
当時はまだVue3が正式リリースされて半年ほどで、NuxtはVue3に対応していませんでした。Vue3でTypescript対応が改善されはしたもののReactと比べるとTypescriptによって得られる恩恵はだいぶ差がある印象だった上にNuxtではまだVue3が使えないとなると、タイミング的にもVue/Nuxtの採用は微妙だなと考えReact/Nextに決定しました。
バックエンド (Typescript/Express.js)
当初はRailsをAPIモードで使うつもりでいたのですが、「ControllerもViewも再利用できないのだからRailsに縛られずに技術選定してもいいのでは？」と考え、ゼロベースで技術選定し直しました。
とはいえ、こちらはさほど悩まずTypescriptとExpressの採用を決めました。
Typescriptを経験して静的型付け言語のありがたみを実感していたので、Web開発でポピュラーな静的型付け言語に絞ると自分が経験あって安心して採用できるのがTS/Expressしかなかったからです。
フロントとバックの言語を統一することは開発者のコンテクストスイッチを減らせるだけでなく人材採用・育成の点でもメリットを享受できるのでは、という狙いもありました。弊社のような初期のスタートアップではフロント専任・バックエンド専任の開発者というのは機能しづらく、全員フルスタックにならざるをえません。そうすると採用でも育成でもTSのスキルは必須となり、バックエンドを別の言語にするとその言語のスキルが採用条件や育成コストにのっかることになります。常に人材難になるスタートアップではこのメリットも無視できないと思い、Railsからの移行を決意しました。
日本でもバックエンドにTS採用するプロジェクトが増えたらいいのにな、と思っています。
インフラ (AWS Fargate)
各機能を順次移行していくので、当面は既存のRailsのアプリと移行後のアプリが共存する形になります。これまでのシンプルな構成では対応できないのでここも見直しを図りました。
開発環境では旧Railsアプリ・フロント・APIと3つのDockerコンテナで構成されるので、本番環境もコンテナで運用したくECSの採用を決めました。またインフラ管理の工数を少しでも削減したく、Fargateタイプで構築しました。
またこの機会にterraformを導入しインフラもコード管理するようになりました。
リプレイスの効果について
ここからは箇条書きで、現時点での良かった点と反省点を書いてみます。
開発効率
良かった点
- フロントとAPIが分離され、関心の分離が明確になった
- APIをTDDで作れるようになった
- UIをコンポーネント管理できるようになり、変更の影響範囲が明確になった
- 型の導入によりリファクタ時の修正対象がコマンド一発でわかるようになった
反省点
- Next/ExpressはRailsみたいに規約が明確にないのでディレクトリの切り方とかメンバーによってブレが出た
- 最初に規約決めて明文化しとくべき
品質
良かった点
- 動作の軽快さはユーザー様からも高評価をいただけている
- APIに起因する不具合は少ない＝テストと型の恩恵
反省点
- フロントの型定義が甘くて不具合につながることがあった
- 型定義はさぼらないで丁寧に考える。これもチーム内である程度ルール化が必要そう
人材確保
良かった点
- フロントの開発に強みを持っている人が魅力を感じて参画してくれた
- フロントの比重が重いので助かる
- フロントしか経験なかった人でも短期間でAPI開発に参加できるようになった
反省点
- 国内で外部の開発会社に依頼を出そうとすると、Railsと比較したら選択肢が少ない
- オフショアに切り替えてワークし始めている
最後に
まだ全機能のリプレイスが完了しているわけではないので若干中途半端な振り返りになってしまっていますが、上記のような過程でリプレイスをすすめつつ新機能開発をごりごり行っています。
やりたいことがありすぎて困っているので常に人材難で新メンバー募集中です。
面白そうな環境だなと思っていただけたらぜひお話させてください！
Discussion