Railsへの批判
Railsの功績とその時代背景
Ruby on Railsは2004年にリリースされ、2005-2006年頃から注目を集めたWebフレームワークです。「設定より規約（Convention over Configuration）」「同じことを繰り返さない（DRY）」の思想の下、当時のJava（Struts等）やASP.NET、PHPによる煩雑な開発プロセスに革命をもたらしました。フルスタックフレームワークとして、スタートアップから中規模サービスの急成長を支え、Web開発の民主化に大きく貢献した偉大な存在です。 Railsに対するよくある批判
1. 「思考停止」を促す危険性
Railsの「規約に従う」というアプローチは、特に初心者において「なぜそうなるのか」を考えずに開発を進めてしまう傾向を生む可能性があります。
「学んだつもり」になって満足してしまう
フレームワークの仕組みを深く理解せずに使ってしまう
規約から外れたケースへの対応能力が弱くなる
2. モノリシックなアーキテクチャの限界
DHHは統合システムを重視する立場を取り続けており、小規模から中規模のアプリケーションでは依然としてモノリシック構造が合理的である場合も多い 複雑なアプリケーションでは、ActiveRecordモデルが肥大化しやすいという問題があります
ビジネスロジック、バリデーション、DBアクセスなどが一つのクラスに集中
複数のユースケースに対応するコードが混在
モデルとビューが密結合しやすい
動的型付け言語であるRubyをベースにしているため、実行時まで型エラーが見つからないというデメリットがあります。大規模な開発チームや複雑なプロジェクトでは、この点が問題となることがあります。 なぜRailsは良くないのか
これまでの特性や批判点を踏まえると、以下のような場面でRailsは最適な選択肢とは言えない可能性がある
1. 長期的な大規模開発
Railsは短期間でMVP（Minimum Viable Product）を構築するのには優れていますが、長期にわたって進化し続ける大規模システムには課題が生じることがあります モノリシックな構造がスケーリングや保守を複雑にする
異なるユースケース間でのモデルの共有が問題になる
2. パフォーマンスクリティカルなシステム
極めて高いパフォーマンスが求められるシステムでは、Go、Rust、JavaなどのコンパイルされたAOT言語の方が適している場合があります。 明確に分離されたマイクロサービスアーキテクチャを採用する場合、各サービスに対してよりシンプルな軽量フレームワークの方が適している可能性があります。
4. 過剰な機能
単純なウェブサイトや小規模なブログなど、Railsのような包括的なフレームワークが提供する機能のほとんどが不要な場合は、静的サイトジェネレーターやより単純なツールの方が適切です。
現代的な文脈での課題
1. スケーラビリティの限界
大規模・高トラフィックサービス：モノリシックな構造により、スケールアウトが困難
パフォーマンス：Node.jsやGoと比較して、メモリ消費やリクエスト処理速度で見劣り
リソース効率：同等の処理を行う際のサーバーリソース使用量が多い傾向
2. 複雑性管理の課題
抽象化レイヤーの厚さ：フレームワークが自動で行う処理が多く、内部実装が見えにくい
「魔法」的な実装：メタプログラミングや動的メソッド生成により、挙動の把握コストが高い
デバッグの困難さ：エラーの発生箇所や原因の特定が困難な場合がある
3. アーキテクチャ上の制約
マイクロサービス設計との乗離：フルスタックモノリス前提の設計で、分割や部分利用が困難
API専用設計との不整合：従来のMVCパターンが、モダンなSPA + API構成にオーバーヘッド
型安全性の欠如：動的型付けにより、大規模開発時の保守性課題が表面化しやすい
4. 技術的依存とエコシステム
フレームワーク依存：Rails固有の設計パターンに深く依存し、他技術スタックへの適応が困難
学習コストの二面性：最初は簡単だが、深く理解するには膨大なフレームワーク知識が必要
なぜこれらが問題となるのか
これらの課題は「Railsが悪い」のではなく、適用場面と成長段階の問題です。Railsの「手軽さ」や「統合性」は開発スピードの爆発的向上をもたらす一方で、長期開発や保守性・拡張性の観点で「技術的負債」になりやすい側面があります。 特定の技術スタックへの深い依存は、技術者の視野を狭める可能性もあります。Rails流の開発に慣れ過ぎると、他のアーキテクチャや設計思想への適応力が低下するリスクがあります。
建設的な結論
Ruby on Railsは適切な場面で使用すれば依然として強力なツールです。重要なのは：
シンプルなWebアプリケーション：Railsの強みを最大限活用
Railsは「道具の一つ」として捉え、その長所を活かしつつ、特定の技術に縛られない柔軟な設計思考を持つことが、現代の技術者には求められています。フレームワークの特性を理解し、プロジェクトの要件に最適な技術選択を行うことこそが重要なのです。
関連リンク
静的型付言語出身者は、Ruby on Railsの「動的にニョキニョキメソッドが生えてくる」予測不能なアンブッシュ攻撃挙動に十分に注意を払わねばならない。古事記にも書かれている。
Ruby怨Railsって、やればやるほど脳内キャッシュメモリの豊富な天才向けのの言語&フレームワークだと思い知らされるわ(ヽ´ω`)
「フレームワークと結婚するな」は実装レベルでもそうだし、思考レベルで結婚してると引き剥がすのが超大変！
モデリングの際「DBのことはいっぺん全部忘れて！」と強く言っても「いや、でもDBが……」と、フラフラと吸い寄せられるようにDBのことを考えてしまうのだ！
「フレームワークと結婚するな」とはまさにこのこと。思考レベルでフレームワークと密結合になっているのだ。この結合を分離することが、設計スキルを高める上で重要。さまざまなプログラミング言語やシステム構成に触れることは、思考のフレームワーク支配から逃れる良い機会。
ボブおじさんが、クリーンアーキテクチャでフレームワークに支配されるなって繰り返し主張してたなぁ。設計できないエンジニアが増えた云々はRailsのせいじゃないかと個人的に考えてる。