Solidusを元にECサイトを作って3年半後にSolidusを外した話

レンティオのカミヤです。当社ではカメラや家電製品をレンタルできるECサイトRentioを運営しています。

Rentio[レンティオ] - 家電・カメラをレンタルでお試し サブスク型の月額制利用も どんな製品も買わずに試せる！

Rentioは創業直後はカラーミーショップを使ってサイトを運営していました。その後、2016年からRuby on RailsによるWebアプリに切り替えたのですが、ゼロからの開発ではなくSolidusというECサイト構築のフレームワークを元にサイトを構築していました。

Solidus: Rails Ecommerce Platform

そしておよそ3年半が経過した去年、Solidusを外すこととなりました。その経緯と理由、Solidusと歩んだ3年半について残してみたいと思います。今後RailsでECサイトを構築される方にとって少しでも参考になれば幸いです🙏

Solidusとは

SolidusはRuby on Rails製のECサイト構築のためのオープンソースフレームワークです。元々はSpreeというフレームワークから派生したプロジェクトでした。2017年にSpreeの運営元が買収され、Spreeの開発が終了すると宣言されたあと、有志で立ち上げられたプロジェクトがSolidusでした。結局Spreeの開発はその後も積極的に継続されており、今でもSolidusと異なる方向性のプロジェクトとして存続しています。

RailsアプリにSolidusをインストールしていくつかのコマンドを実行するだけでシンプルなECサイトが立ち上がるのがSolidusのいいところです。

ちなみにSolidusやSpreeについては過去にQiitaにも記事を投稿しています。技術的な情報についてはそちらをどうぞ（ちょっと古いですが）

SolidusでECサイトを作る際の方法と考え方 - Qiita

Spreeの後継ECシステム、Solidusのインストールメモ - Qiita

Solidusを採用した経緯

当時はエンジニア1名体制であったこと、そしてまだレンティオの開発プロジェクトがどこまで大きくなるのか不透明でした。そのため開発工数を潤沢に投下することができませんでした。

さらにはECサイトを運営する知見は持っていたものの、ECサイトをRailsで開発&構築するのが初めてだったためゼロから作るのは厳しいだろうという判断のもと、Solidusを採用しました。

Solidusを使ってサイトを構築するということ

最初にも書いたとおり、Solidusをインストールしていくつかのコマンドを実行するだけでシンプルなECサイトが立ち上がるのが一番の良いところです。

ECサイトと一言で言っても必要な機能は多岐に渡ります。Solidusを採用することでざっと次のような機能の開発を省略することができました。

・注文や商品周辺のモデリング
・チェックアウトフロー
・アカウント登録/ログイン等の機能
・社内向け管理画面

ですがSolidusの標準機能だけでは足りないものもあります。

一つは決済周りです。Stripeのような国際標準の決済サービスは予めプラグインが用意されておりそれらをインストールするだけで使えますが、PAY.JPのような国内の決済サービスや決済手数料が発生する決済方法（例えば代金引換など）は自分たちで実装する必要があります。

また実装方針をとっても、Solidusのモデルや機能を元に使うのか、あるいは自分たちで機能を追加して使うのかSolidusのコードを読んで判断する必要があります。こうして書くと前者のほうが良さそうに思えますが、Solidusのコードは大規模かつ海外の商習慣を元に作られているため読み解くのが難しい場合が多いです。

またサイトのデザインも基本的には自分たちでデザイン&マークアップする必要がありますし、社内向けの管理画面も必要な機能を自分たちで追加する必要があります。例えばヤマト運輸のB2や佐川急便の飛伝はCSVで配送情報を連携するのが一般的ですが、もちろんSolidusにそれらの機能は搭載されていません。

Solidusを使って良かったこと

注文や商品周りのモデリングがそのまま使えたので、ゼロからECサイトを構築するよりもスピーディーにECサイトを作り上げることができました。

特に、ECサイトの機能の中でも設計や実装が難しいであろうチェックアウトフローがそのまま使えたのはとてもメリットが大きかったように思います。ECサイトでは個人情報を預かる必要があるため、経験の浅い開発者がゼロから作るよりも既存の仕組みに乗っかれるほうが圧倒的に安心感や安全性があります。

社内向け管理画面についてもゼロから作ろうとするとCSSだレイアウトだで多くの時間がかかると思いますが、その点ひとつ取っても多くの時間を節約できました。

Solidusを外した理由

Solidusを使うことはそれ自体が一定の技術的負債を抱えることになります。その負債の重さとSolidusを使い続けることによるメリットとのバランスが逆転したというのが理由です。

Solidusを使って開発する場合、一般的なRailsのような形でコーディングができず、Solidus特有のお作法に従う必要があります。その学習コストも無視できないものでした。少人数で開発していたうちは良かったのですが、今後の開発プロジェクトがより大規模になるのであれば、その状態のまま進むのは厳しいという判断となりました。また依存するRubygemやnpmパッケージといったライブラリ群が稀に古いバージョンで固定されてたりするのもキツいポイントでした。

元々Solidusは、ヨーロッパなど他国への配送時に発生する関税や国際配送を想定して作られているため地域関連や税金のモデルがとても重厚に作られており、日本国内限定のECサイトを運営するにはオーバースペックです。

実際のところSolidusはかなり巨大なフレームワークで、インストールするだけで即100個くらいのテーブルが作られます。ですが、実際に使っていたのはそのうちの2、3割くらいです。特に配送周りや税金周りの扱いが日本のECの商習慣と異なる点もスムーズな理解に苦労する要因でした。

Solidusを外すためにやったこと

そのような背景もあってSolidusを外したわけですが、Solidus内のコードを参考にしながら不要なクラス以外をリファクタリングしながら移管するといった手順を取りました。Solidusは内部的にsolidus_core、solidus_frontendといった複数のRubygemに分割されていますので、これらを順番に対処していった形となります。

ゼロから移行先のアプリを作ってデータだけ載せ替えるという方法もありましたが、すでにRentioは大きなアプリケーションになっていたためより慎重に進められるこの方式を選択した次第です。

振り返り

当時エンジニアが1人だったことやRentioがどこまで伸びるか不透明だった点を考えるとSolidusを採用したことは序盤のスピードアップに繋がったと思います。が、後期の開発効率を犠牲にしていた可能性はありそうです。

もし、もう一度同じことをやるとなった場合、Solidusを採用するかどうかは悩ましいポイントですね...一度入れたSolidusを外すのはかなり重いタスクでした。もしかしたらSolidusの一部のみ（注文や商品といった主要なモデルと機能のみ）を利用して、それを中心にサイト構築する形といった選択肢も検討するかもしれません。

追記

その後も当社のECサイトはおかげさまで成長を続けていますが、Solidusの実装がよくできているなと感じることがしばしばあります。基本的なモデリングもそうですし、脱Solidusしたころは用途がわからなかった機能も規模が拡大した今だからこそ必要性を理解できることがあります。RailsでEC構築を行ううえでSolidusを採用する/しないに関わらずSolidusの実装については非常に参考になる点が多そうです。

Thank you Solidus!

-----

Rentioではエンジニア募集中です🙋🏻‍♂️

レンティオ株式会社の会社情報 - Wantedly