セッションの4つのテーマ
清野隼史氏（以下、清野）：本日はトークセッションとして、先ほどLTをしてもらった櫻庭さんや赤沼さんと一緒に話したいと思います。清野が進めます。よろしくお願いします。
櫻庭洋之氏（以下、櫻庭）：よろしくお願いします。
赤沼寛明氏（以下、赤沼）：よろしくお願いします。
清野：今回のトークセッションのテーマとして、スライドに書いてある4つを用意しています。最初にこういうテーマにした意図というか背景を説明したいと思います。目的について。Railsは2004年リリースで今はRails7です。Rails1から7まできているので、Webアプリケーションの開発を取り巻く環境は2004年からの18年間ですごく変わってきていると思います。最近、たまに「Railsはオワコンだよね」という声を聞くようになりました。
ただ、実際それを議論しているというか、本当に今オワコンになっているのか。Railsが生み出している今の価値や「こういうところがよくなったらいい」という部分に、あらためてこのトークセッションのタイミングで向き合っていきたいと思い、これらのテーマを用意しました。
新しくサービスを作るタイミングでRailsを採用するのはアリか？
さっそく本題に入ります。視聴者のみなさんに質問しますが、今仕事でRailsを使っている方はどれくらいいますか？
赤沼：どれぐらいいるんですかね？
清野：意外と使っていないんですかね。どんどん増えてきました。やはり仕事で使っている方もいると思うので、今回はこれから新しく検討することについても話します。そもそもRailsを使っている方のほか、すでに使っていて「ここからどう向き合っていこう」という方にもお伝えしようと思います。
テーマ1は「今Railsを採用するのはアリ？ナシ？」です。（Railsを使っている方の人数が）53（人）まで行っているみたいですね。ありがとうございます。
新しくサービスを作るタイミングでRailsを採用するのはぶっちゃけアリなのかナシなのか、どういう時ならアリなのかナシなのかについてもうかがいます。はじめに櫻庭さん。
櫻庭：正論ですが、「要件とチームによる」という回答になります。毎年「Rails is dead」と言われるくらい死んでいるので。それくらい使われているという証拠でもありますが、個人的にはオワコンだとは思っていないし、順当に進化しているので採用するのはアリだと。
清野：赤沼さんはどうですか？
赤沼：私も同じような意見です。RubyもあわせてRailsは毎年死んでいるというか、毎年オワコンと言われていますが、私はアリだなと思っています。でも、それはもちろん要件とチーム構成による。例えば、今の私のチームは基本的にRailsばかりで作っているので、同じチームでやるとしたらRailsが妥当だと思います。
プロダクトの内容的には、普通のという言い方はアレかもしれませんが、普通のWebアプリならRailsでいいと思う。パフォーマンスやリッチなフロントエンドを要求される場合はRailsは向かない可能性もあるので、その場合は別のものを選ぶのもアリだという感触です。
Rails採用をすすめられないパターン
清野：機能がシンプルであればRailsの強みを活かせるというか、それだからこそRailsを使うメリットがあるということでしょうか。ちなみに、逆におすすめできないパターン、「こういう方にはお勧めできない」「こういうタイミングでは採用するのは控えたほうがいい」という例があるのか、櫻庭さんにうかがいます。
櫻庭：1つ明確なのは、リッチなエディタ、CMS機能の場合はたぶんReactで作りたくなる。それならサーバーサイド含めてNextでやるほうがシンプルだと思う。ほかにmonorepoというか、モノリシックでメチャクチャ巨大で、モデルもメチャクチャたくさんあって、複数のドメインが交じっているようなものをRailsで作ると開発速度が落ちる。ただRailsじゃなくても落ちる気はします。
規模が大きくなったらRailsは捨てたほうがいいのか？
清野：今リッチでモノリシックな大きなアプリケーションという話が出ましたが、これもあるあるで、最初にRailsを採用した時はサービスも会社も小さかった。その結果、グロースしたことでアプリケーション自体も大きくなっていったと思います。そこをどう見極めるか、どう判断していくか、どう考えていけばいいのか。
ユニファはすごく（たくさんの）Railsアプリケーションを作っていると思うので、例えばRailsは一度捨てたほうがいいのか、大きくなっていくタイミングでも、向き合い方によって採用はアリなのかをうかがいたいです。
赤沼：私は絶対に捨てなきゃいけないとは思っていません。ユニファも1つのプロダクトからスタートして、「ルクミー」の中ではありますが、次のプロダクトでまったく違う機能を提供したいと思った時に、今までのプロダクトと同じRailsに載せるほうがいいか、別に作るほうがいいのかを内部で議論したんです。
同じところに載せるほうが、今までのユーザーアカウントなどもそのまま使えるので、機能だけ実装すればいいのではないかという意見もありました。ただやっぱりそこが大きくなると後々メンテ（メンテナンス）がつらいので。
最初のプロダクトの構成がもともとあまりよくなかったので、本当にイケてないんですが、最初のプロダクトにもメンテするとつらい部分がある。そこにこれ以上、しかもわりと機能が違うものを載せるとなると後々つらくなると思った。
どれだけ早くプロダクトを提供できるかが1つの勝負でもあったので、それなら別のチームで作ってしまったほうが早く提供できるのではないかと。 マイクロサービスを意識していたわけではありませんが、その時は自然と内部の議論で分けたほうがいいという結論に至った。やはり機能が違うものは無理に載せない、合わせないように分けたほうがいいと思っています。
一方で、迷うのはmonorepoがいい流れもあること。弊社はあまりmonorepoでやっていないので、monorepoでやった時との比較ができていませんが、monorepoでやっている方はそのほうがいいところがあるのだと思うので、賛否両論あると思いつつも、弊社の選択はそう（先ほどお話ししたとおり）でした。
アカウントデータの一部を独立して持ってバッと作って先にリリースする選択肢や、後からアカウントを統合するケースもあった。その時々で悩んで選択してきた感じです。
清野：Railsというかアプリケーションが大きくなっていく時に、1つのRailsを肥大化させていくのか、シンプルに保ちつつ複数のアプリケーションをどんどん作っていくのかという選択肢があるということですか。
赤沼：そうですね。
Railsの代わりとして採用するとしたら何を選ぶか？
清野：質問も取り上げていきます。1つ目の質問は「もしRailsを採用しないとなった場合は、ほかに何を採用すればいいでしょうか？」。
櫻庭：僕はやはりフロントを軸に選ぶので、フレームワークでいうとNextなどかなと思います。
清野：例えばフロントエンドでReactやVueを使う前提で、バックエンドでもそれに合うフレームワークを選んでいくというスタンスですね。
櫻庭：そうですね。Ruby3でRBSが入って、次に型情報も出てきます。クオリティ次第ですがTypeScriptの型の利便性は強いので、その点で言語ベースで選んだりもすると思います。
清野：ちなみに、ユニファの社内でほかのフレームワークを選定する場面があるとすれば、どんな選択肢がありますか？
赤沼：弊社もTypeScriptなどをもっと活用してもいいのではないかと思います。一方、サーバーサイドのエンジニアの興味という点で考えると、過去にGo言語を使いたいという声もあった。一部でたまにLambdaをGoで書いてみたこともあるので、静的な型付けの言語を使ってみたいという意味も含めて、Goも1つの選択肢になるのかもしれません。
清野：そういう意味では、ナシを選択するのはRailsにはない強みを持っているものを選ぶということですか。型がしっかりあるものや、フロントと整合性をしっかり持って作れるものを判断時には持ってくるということでしょうか？
櫻庭：そうですね。似たようなものにリプレイスしてもあまりうまみがない（笑）。
清野：そうですね（笑）。
Railsのリプレイスや削除の判断軸は？
清野：次の質問です。「もし今後RailsをリプレイスしたりRailsを捨てたりする判断をすることがあれば、何を判断軸として選択するのか」。今はまだやっていないかもしれませんが、可能性としての判断軸はいかがでしょうか？
櫻庭：1つは、開発速度を担保したくなった時かと思います。プロダクトが成長していくと、機能追加を含めてガンガンやっていくのに伴ってアプリケーションが肥大化したり、コードの質が下がってしまったりする。
機能開発なのにそれが負債になってすごく工数かかるような状況になると、プロダクトの成長がすごく鈍化してしまう。その時に投資としてリファクタリングするのか、思い切ってドメインレベルで分割してマイクロサービス的に、あるいは今流行のモジュラモノリス的に分割していくのかを判断することになると思います。
清野：今の話だと、リプレイスすると判断しても一気に全部を変えるわけではなく、一部分ずつ変えていくという選択肢ですか。
櫻庭：そうですね。なだらかにというか、少しずつグラデーションで切り替えていくのが現実的だと思います。
清野：そういう意味では、もしかするとユニファの構成というか、小さなアプリケーションがたくさんある構成は、ある意味Railsを捨てるという選択になったとしても可用性が高いというか、乗り換えやすいのでしょうか。
赤沼：Railsを捨てるかどうかはその時の技術選定ではありますが、確かに特定のプロダクトに対してリプレイスなりRailsではないもので作る選択肢はあると思います。Railsを捨てたわけではありませんが、過去に1つのプロダクトをリニューアルしたことは実際にあります。
まさに櫻庭さんが言ったように、これ以上はメンテが厳しい、簡単な開発のはずなのにすごく工数がかかる状況になってしまいました。VOYAGE GROUPさんが出した本に“ドアノブを捻ると風呂の底が抜ける”というおもしろい表現があったと思いますが、「ここをいじったらどこに影響が出るのかがわからなくなってきた」という状況になったことがある。
そうなると、多少サービス開発を止めてでもリプレイスしないといつ止まるかわからないので、そのタイミングでもうリプレイスをガラッとリプレイスをガラッと一つのプロダクトでやったというのはありましたね。
（次回につづく）
