スペースマーケットの Rails to NestJS 移行の現在地。そしてこれから。
私たちスペースマーケットが4年前から進めている 「Ruby on Rails から NestJS への移行プロジェクト」。
一時期、その進捗は残念ながら進んでいるとは言えない状態でした。
過去の登壇や採用資料でも「NestJS へ技術スタックを移行中です」と発信してきておりました。
その裏側では、日に日に重くなる技術的負債と、進まない移行への静かな焦りが渦巻いていたのです。
この4年間、私たちの開発現場で一体何があったのか。
そして、一度は止まった歯車が、なぜ今、再び力強く回り始めたのか。
「で、結局スペースマーケットの技術基盤って、今どうなってるの?」
そんな疑問をお持ちの方が(きっと、少しは)いるはず⋯
今回はこのプロジェクトの「これまで」と「これから」を、赤裸々にお伝えできればと思います。
🛣️ これまでの振り返り
わたしが入社する前の話も含まれるため、社内のドキュメントを漁ったり、当時のメンバーから聞いた話をもとに、この4年間を振り返ってみました。
黎明期: なぜ Rails から NestJS を目指したのか
スペースマーケットのサービスが産声をあげたのは2014年。当時は Ruby on Rails で開発されていました。
Rails の持つ開発スピードの速さは、スタートアップの成長を力強く牽引してくれますし、現在でも多くの企業が Rails を採用しています。
しかし、サービスが成長しコードが積み重なるにつれて、いわゆる 「Fat Controller / Fat Model」 といった問題が顕在化し始めます。
機能追加のたびに影響範囲の調査に時間がかかったり、知らず知らずのうちにコードの密結合が進んで改修が困難になったり…。
「このままでは、サービス成長のスピードを維持できない」という危機感が、チームの中に生まれ始めていたようです。
そして時は2021年初頭。
この状況を打破すべく、NestJS への移行プロジェクトが発足します。
- TypeScript の静的型付けによる安全性
- DI (Dependency Injection) による疎結合な設計
- エコシステムの豊富さ
NestJS というフレームワークが持つこれらの要素は、当時のサービスが抱えていた課題に対する明確な処方箋となりうるものでした。
まずは NestJS の学習とともに、ディレクトリ構造や Passport などの認証機能、TypeORM による DB 操作、GraphQL、DataLoader、CQRSパターンなどの技術検証を行い、2021年6月ごろから本格的な開発が始まっていきました。
当時の資料にはこのような記載があります。
CleanArchやオニオンアーキテクチャーなどの概念を取り入れ、Expressのみで構成する方法もとれるが、独自の構成になりやすい。
Nest.js Wayに従うことで独自の実装を避け、尚且つNest.jsのフレームワークのもつテストがしやすく、スケーラブルで疎結合で保守が容易なアプリケーションを作成できる。
重要な点は 「保守しやすく、スケールするアプリケーションを作る」 という強い意志を持って NestJS が選ばれたことだと考えられます。
弊社の Rails API はバージョンが異なる2つの API 群と、予約関連の API が存在していました。
このプロジェクトの最初のゴールとして、まずは前者の 2 つの API 群を NestJS でリプレイスし、廃止することを目指したのです。
停滞期: 理想と現実のギャップ
しかし、現実はそう甘いものでありませんでした。
ここで新しく NestJS に移行された API の本数を四半期ごとに見てみましょう。
(* スペースマーケットは1月1日からQ1が始まります)
(* PR調査に時間がかかるので Devin 君に出してもらいました)
予約ドメインのAPIおよびバッチを除いたAPI(200本以上)のうち、これまでに移行(新規での開発を含む)されたものは 26本 あり、2024年までの移行率は約13%です。
この図を見て分かる通り、残念ながら2022の夏ごろから停滞している状況でした。
他に優先すべき施策があること、そして何よりも 有志での移行作業 であることが要因として挙げられます。
日々のプロダクト開発や機能改善が優先される中で、移行作業のためのまとまった時間を確保することは非常に困難でした。
熱意ある方々が頑張ってくれてはいたものの、一度手を止めてしまうとそこから復活させることも難しいというモチベーション維持の観点もあったのだと思います。
結果として、Rails と NestJS という2つのシステムが併存し、運用コストが増えてしまったという、なんとも悩ましい状況に陥ってしまったのです。
転換期: 会社としての「やりきる」という覚悟
2つのシステムが併存し、移行が進まない状況は、開発効率の低下だけでなく、エンジニアのモチベーションにも影響を与えます。
この状況を打破するため、2024年の夏、ついに会社として大きな意思決定を下しました。
「移行プロジェクトに、会社として本気で向き合う」
これにより、しっかりと時間を使ってやりきるためのチームが新しく生まれました。
Marketplace X(通称: MXチーム)と名付けたこのチームは、 アプリケーションの移行だけでなくインフラ面での構築から見直しています。
ただAPIを移し替えることではなく、技術基盤を再定義し、これからのスペースマーケットを支えるシステムを作っていくことがミッションです。
チームの発足や背景については、現場.ts vol.2 でもお話しましたのでぜひ資料もご覧ください。
チームのドキュメントには、わたしたちが目指す世界をこのような風に書いています。
変更容易性を確保し、エンジニアの開発体験を向上することで価値・検証したいことを届けるスピードを増す。
ゲストが増え、ホストが増え、トランザクションが増え、売上が増え、給料が増える
みんなハッピー!
🧭 新チームはなにをやっており、どこへ向かうのか
新しく生まれたチームが、具体的に何をやっているのか。
こちらも簡単にご紹介します。
足場を固める:基盤の再定義
-
インフラ/AWS ネットワークの見直し
-
アプリケーションアーキテクチャの見直し
- src 配下にフラットに配置されていた約80のモジュールを、Clean Architecture に則って再構成
- 移行済み API のリファクタリング
-
TypeORM から Prisma への移行
-
NestJS のバージョンアップ
-
インフラ/AWSネットワークの見直し
- 別プロダクトと相乗りしていた構成を分離
-
アプリケーションアーキテクチャの見直し
- src 配下にフラットに存在していた約80のモジュール。これらを Clean Architecture に則って再構成し、見通しが良く、責務が明確な構造へ。
- 過去に移行されたAPIのリファクタリングも並行して実施。
-
TypeORM から Prisma への移行: より堅牢な型安全性を求め、ORM を Prisma へ変更。
-
Node, NestJS, 各種ライブラリのバージョンアップ
- 実行環境を最新に保ち、セキュリティとパフォーマンスを向上。
こうした地道な改善を、チーム発足の2024年9月から2025年5月にかけて進めてきました。
再び移行の最前線へ
盤石な足場を固めた上でついにAPIの移行を再開しました。
改めて残存APIを洗い出し、インパクトの大きいところから優先度を割り振り進めるようにしました。
その結果、2025年7月19日現在で 22本 (調査の結果、使われておらず不要としたものも含みます)について対応を完了しています。
これで移行率は 約20% に達しました。歯車が再び力強く回り始めています。
当面のマイルストーンとしては、2026上半期中までに冒頭で述べた2つのバージョンの API を移行し終えることを目指しています。
道のりは長いですが、「変更しやすいシステム」を作り、「エンジニアの開発体験を向上」させることで、スペースマーケットの成長に貢献していきたいと考えています。
次のステップ: チームから組織へ
次の目標は、チーム外のエンジニアも開発できるような仕組みを整え、スペースマーケットのエンジニア全員で移行を加速させていく ことです。
これまでチーム内で培ってきた技術や知見を共有し、より多くのエンジニアに参加してもらい、みんなで作り上げていく。
「チームの関心事」から「エンジニア全体の関心事」へと広げていくことが、スペースマーケットの技術基盤をより強固なものにしていくと信じています。
最初は右も左も分からない状態で参画したメンバーも、今では自分の意見を持ち、チームに貢献できるようになっていますし、欠かせない存在へと成長しています。
✨ さいごに: この仕事楽しい?
こういった技術的負債の解消は、いわば「守りの開発」です。
あるときのチーム振り返り(レトロスペクティブ)でメンバーからこんな質問をいただきました。
「自分はやっていて面白いんですが、8zcaさんも楽しめてますか?」
プロダクトを前に進めたい、新しい機能を作ってユーザーに使ってもらいたいと考えるエンジニアも内外問わず多くいることでしょう。
負債解消の取り組みばかりでは、どうしてもモチベーションを感じにくいと思われる方ももしかしたらいらっしゃるかもしれません。
しかし、わたしたちの仕事により、まわりのエンジニアが成長し、より楽しくより良い開発体験を得られるようになれば、プロダクトもより良いものになっていきます。
その結果、ユーザーにとってもより良い体験を提供できるようになり、会社にも貢献できる。
巡り巡ってわたしたち自身に返ってくる、未来への投資そのものです。
だからこそ、「めちゃくちゃ楽しいよ」 と答えることができます。
良いプロダクトは良いコードから。
そういった弾み車を作っているのです。
スペースマーケットのこの挑戦に、少しでも興味を持ってくれた方がいればぜひ一度カジュアルにお話ししましょう。
最後まで読んでいただき、ありがとうございました。

スペースを簡単に貸し借りできるサービス「スペースマーケット」のエンジニアによる公式ブログです。 弊社採用技術スタックはこちら -> whatweuse.dev/company/spacemarket
Discussion