「良くも悪くもすごく割り切っているフレームワーク」　“ルールに従えば使いやすい”Railsのいいところ、つらいところ

Railsのいいところ

清野隼史氏（以下、清野）：では、次のテーマに移ります。テーマ2までで、今のWebアプリケーション開発がどうなっているか整理できたと思います。それをまた踏まえた上で、次は「Railsってこういうところがいい」「こういうところがいまいち」という点を語り、最後にRailsに自分たちはどう向き合っていけばいいのか、どう使っていけばいいのかについて話します。

まずテーマ3「Railsあるある」では、Railsのいいところとつらいところをざっくばらんにうかがいます。まずはいいところから。Railsの「やはりここいいよね」というところはありますか？

櫻庭洋之氏（以下、櫻庭）：賛否両論ありますが、ActiveRecordがメチャメチャ強力でシュッと書けるという強みのほか、ActiveSupportもすごく親切なメソッドがメチャクチャ用意されているので、データ操作が簡単に直感的に書けるのは、開発体験としてはメチャクチャいいと感じます。

清野：僕もまさにその部分（がいいところ）だと感じていて。Railsがここまで成長できたというか、これだけ使われるようになったのはActiveSupportの書きっぷりのよさによる。本当に書き心地がいい。オブジェクトを触っているだけのような感覚でDBアクセスできてしまうのが繁栄した理由だと考えているので、本当にそこはいいところだと僕も思います。赤沼さんはいかがですか？

赤沼寛明氏（以下、赤沼）：今の点はすごく思います。久しぶりにRubyの素のスクリプトを書こうとすると「これRailsにしかないんだっけ？」と思うことがある。それ以外には、これも善し悪しだと思いますが、暗黙的な処理というか、記述をしなくても勝手に、よしなにやってくれるところが強力で、サービス立ち上げのスピードはすごく早いと思います。

設定より規約という点で、レールに乗っかっているとメッチャ早いというか、勝手にやってくれるので、そのスピード感はすごいと思いますね。

清野：まさにRailsのコンセプト、ルールに従って書いているだけであればすごく書きやすいというか、設定をする必要もない点は魅力的ですよね。チャットに「良くも悪くもなんでもよしなに処理してくれる」と来ています。まさにRailsのよさであり、困ることでもある。

櫻庭：でも、初学者がつまずく悪いポイントでもあるのかもしれませんね。「ここはどう動いているんだろう」という。

清野：確かに。逆に初学者の成長を妨げてしまっているかもしれませんね。なんでもよしなにやってくれちゃうせいで、深掘りしづらいというか。

赤沼：コードだけ見てもわかりませんからね。

清野：わかりませんね。

赤沼：知らないとわかりませんからね。

清野：いいところについて、ほかに「なんだかんだ楽、ってなります」ときています。Railsのいいところは、立ち上げるところなど、ルールに従って書いているとスピーディにどんどん作っていけることですよね。

Railsのつらいところ

続いて、つらいところにいきます。すでにいくつか来ているので紹介します。1つ目は「config配下に設定がメチャクチャあってつらい」。これは、Railsの枠からだんだん離れたり、いろいろなツールをどんどん入れていくと発生するんですよね。

櫻庭：そうですよね。gemもスタイルはさまざまですが、魔術的なタイプのgemだと中身もよくわからないし、configの書き方もよくわからなかったりするのかもしれません。

清野：READMEに書いてあるものをそのまま貼るとなぜか動くけどまったく理解できない謎の現象がありますよね。そのほかに「読むのがつらすぎる時ありませんか？」という質問も来ています。

櫻庭：これはトリッキーなコードを書いてしまった時ですか？

清野：そうですね。特にクラスの継承やモジュール、Model Concernを使っている時はしんどいですよね。

櫻庭：わかります。

赤沼：このあたりは、静的な型付け言語ならIDEでよしなにしてくれるけど、Railsだとそうはいかないから自分で理解して追っていかないといけない。それがつらいところなのかな。

清野：まさに。型があれば、逆にそれがメリットになることもあると思いますが。

赤沼：そうですね。

櫻庭：Rubyは、「YARD」などのドキュメントで書けるっちゃ書けるけど、オブジェクトの中に何が入っているのかはコードを読むだけでは判断できないこともあるので、そのあたりはつらいですね。

清野：しかもYARDも途中からだとYARDもやりづらいというか、「これ全部書くの？」みたいになっちゃいますよね。

赤沼：確かに。途中からやり方を変えようとすると、だいぶつらいですよね。

清野：どんどん来ます。「カッコよく書きすぎてほかの人が読めないコード、ありがち」。いわゆるメタプロでしょうか。誰でもDSL（Domain-Specific Language）っぽい書き方ができてしまうというのはありますよね。

櫻庭：みんな一度はハマる道のような気がします。「Rubyでなんでも作れるじゃん」って思って、オレオレ構文作りを始めるという。

清野：感動してメタプロにハマって、カッコ使わなくなって読めなくなるみたいなことありますよね。

赤沼：元のクラスになんでも追加できちゃうから、どこで何をやられているかわからなくなることもありそうですよね。

清野：ありますね。続いて「良くも悪くもよしなにやってくれない言語を書く時に、逆にそこがわかんなくなる」。Railsがなんでもやってくれすぎちゃうからという。

櫻庭：これはあるかもしれません。いわゆる「Webってどう動いているの？」という点、つまり、きちんと基礎を押さえていないと、先ほど言ったように暗黙の部分に想像が働かなくて、デバッグ自体できないということがあるかもしれません。

Railsでドメイン駆動設計をする際の向き合いかた

清野：ありますよね。続いて、ちょうど僕も質問したいと思っていたんですが、「Railでドメイン駆動設計をやるとつらくないですか？」。Railsのつらみとして、アーキテクチャがMVC（Model-View-Controller）から離脱しようとすると難しいというか、しんどくなることが多いと思っています。それに関してどう向き合えばいいとかありますか？

櫻庭：僕は、Railsでは無理にDDD（Domain-Driven Design）でやる必要はない。あまりメリットがないと思っている。DDDではなく、例えばServiceクラスやFormオブジェクトなど、いわゆるRailsが標準で用意していない概念を入れることはあると思いますが。設計能力とそれを運用し続けるチームのスキルが揃っていないと破綻しやすいので、ファットモデル上等というか、むしろ太らせて素直に作っていったほうがいいとずっと思っていました。

清野：なるほど。赤沼さんはいかがですか？　社内で設計やアーキテクチャを変えている事例はありますか？

赤沼：今話に出たServiceクラスは弊社も使っているので、そのあたりは各プロダクトのチームに任せています。こっちのプロダクトではServiceクラスをこういう使い方しているけど、こっちのプロダクトではこう使っていて、こっちのプロダクトではそもそもServiceクラスを使っていなかったりする。正直、あまり整理できていませんね。

また、DDDに限らず、「どこまでやるべきか」とか、「Railsでそれをやるのが正しいのか」とか、手法にこだわりたいのなら、それに向いたフレームワーク（言語）を使ったほうがいいのではないかという気がします。

清野：そもそもRailsならそういうことを考えないというか、変えるのが筋としてよくない。逆に、弱みというか柔軟性があまりないという言い方も、仮に言うとしたらできるのでしょうか。

赤沼：Railsは良くも悪くもすごく割り切っているフレームワークというか、もともとのクラス、オーソドックスなものならきちんとレイヤーを分けるところをギュッとしちゃっていると思う。それを活かしてやっていくのならすごくいいと思いますが、無理矢理違う構造に当てはめようとすると結局レールから外れないといけないので、そうするとつらみばかりになりそうな気がしますね。

リッチなUIなどに対するRailsの相性

清野：もう1つ、僕から聞きたいと思っていた質問があります。先ほど「最近は環境の変化で、フロントがリッチになってきているとかインフラが複雑になってきている」という話がありましたが、リッチなUIなどに対するRailsの相性はどうですか？

櫻庭：悪いと思います（笑）。パーシャルがよく使われているところは、悪さがプンプン出ているなと。パーシャルはもともとコンポーネント指向で作られているものではないので、お門違いかもしれませんが。フロント周りで細かくコンポーネントを作りたいとか、デザインシステムと連携してやっていきたいという時に、とにかくパーシャルが使いにくい。それが逸脱しているというか、つらいと思うところです。

清野：それは僕もすごく思います。パーシャル、コンポーネントっぽいインターフェースを提供してくれるようで、挙動は実はどちらかというとマクロっぽいというか、渡したものをそのまま展開されるところがあると思います。

櫻庭：スコープもグローバルで完全に開いちゃっているし、「これはどうすればいいんだ？」という。

清野：それは、Railsを書いている方みんなのあるあるなのではないかと思います。赤沼さんはいかがですか？　ユニファの事例だと、Railsとフロントエンドはどうなんでしょう？

赤沼：先ほど話したように、弊社も最初はRailsの中だけで十分やっていたんですが、やはりそれもつらくなってきて、リニューアルしたプロダクトからVue.jsを組み合わせてやっています。弊社が提供するフロントエンドはすごくシンプルなので、Railsで十分やっていけていると思いますが、フロントにすごくこだわるようなプロダクトならRailsである必要はないのかなという気がします。

向き不向きという点では、フロントエンドリッチなものに向いているわけではないと思う。私自身がフロントエンド弱者だからでもありますが、「Sprockets」や「Webpacker」周りは黒魔術という印象があって、なんでそこがそう動くのかわかりづらいのではないかな。

清野：最近のRailsのトレンドでいうとがんばっている印象はありますが、それでもまだまだというか、全ページReactで書くレベルまでは行っていない感じですよね。

赤沼：フロント（エンド）なら本当に向いているものを選んだほうがいいのではないかな。

清野：「Vueにロジックゴリゴリ書いてあるとつらい」というコメントもきています。Vueもそうですね。Railsは境界が規約くらいでしかないから、どこにでも書けちゃいますけど。

赤沼：こうなるとつらいですよね。

Railsの設計で参考にしているプロダクト

清野：「Railsの設計をする時に参考にするプロダクトってありますか？」という質問がきています。「『GitLab』や『Redmine』を見たりしますが、規模が大きすぎて参考にするには難しい」。なるほど。

櫻庭：最近は見ていませんが、少し前はよく「マストドン」を見ていました。そんなに大きすぎず、中規模くらい。Serviceクラスはがっつり使っていましたが、参考にはなったかなと。ほかにはShopifyがよくブログで出しているものを参考にしますが、Shopifyはデカすぎて逆に参考にならないと思った。

清野：ちなみにRailsの設計の時は、各アプリケーションにどのくらい差分があるものなんですか？　Railsのコンセプト自体はシンプルで、規約にのっとっているとは思いますが。

櫻庭：“俺が考えた最強のRailsアーキテクチャ”は、人の数だけある気がします。Qiitaの記事でいろいろな主張が並べられていることでもわかると思う。もし会社組織として取り組む場合には、目線合わせはすごく重要だと。

清野：ちなみに先ほどの話でいうと、ユニファもRailsの構成はシンプルでServiceクラスがある感じですよね。

赤沼：基本的にはそうで、すごく違うということはありませんが、各プロダクトのメンバーの好みが出る部分はある。例えばDBもRDB（Relational Database）、AWSなので、普通にやればRDS（Amazon Relational Database Service）やAuroraを使いますが、ものによってDynamoDBを使っていたりすると、クエリの投げ方が変わってくる。Railsの中でもジョブ、バッチ処理をどう構成するのかという点では、けっこうやり方が違ったりします。大枠のアーキテクチャとしては同じですが、世代というか、作られた時期によって個別の処理の仕方が違うことはありますね。

清野：確かに。gemも無限にあるし、何をミドルウェアとして使っていくかもいろいろあるので、そういうところに変化が生まれるということですね。

赤沼：きちんと考えてgemを取り入れないと（いけない）。適当なgemを取り込むと、後々メンテされなくなったりしてつらいことがあるので。

櫻庭：あるあるですね。

（次回につづく）