The Rails Way とは？ -原則とその向こうへ-

331 Views

November 12, 25

#仕事 #プログラミング言語 #エンジニアリング #ruby #ruby on rails

スライド概要

「The Rails Way とは何か？」
この問いに答えられるだろうか?

是ならば、Ruby on Rails に対して情熱があり熟達もしているはず。
否であれば、恐れずにその哲学にどっぷり飛び込んでみよう。

今こそ原則とその向こうへ!

profile-image
スライド一覧

某教育系サービスの内製開発にソフトウェアエンジニアとして携わっています。 使用技術スタックは、バックエンドは Ruby on Rails、フロントエンドは React.js + TypeScript です。 プライベートでは Python も少し書きます。 学部生時代は英語学を専攻していたので、言語に強い興味を持っています。 LT 会のプレゼンテーションなどで使用したスライドを掲載しています。 宜しければご自由にご覧下さい。

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

（ダウンロード不可）

関連スライド

slide-thumbnail

ソフトウェアエンジニアの社内技術ドキュメンテーションへの向き合い方 -一般論編-
仕事 エンジニアリング ドキュメンテーション ソフトウェアエンジニアの社内ドキュメンテーションへの向き合い方
user-img 石田 隼人 25K
slide-thumbnail

ソフトウェアエンジニアの社内技術ドキュメンテーションへの向き合い方 -実践編-
仕事 エンジニアリング ドキュメンテーション ソフトウェアエンジニアの社内ドキュメンテーションへの向き合い方
user-img 石田 隼人 19.2K
slide-thumbnail

比較言語学のススメ -Ruby vs. Python に学ぶ言語のアイデンティティ-
仕事 言語学 自然言語 プログラミング言語 エンジニアリング ruby python
user-img 石田 隼人 8.1K
slide-thumbnail

Road to Ruby for A Linguistics Nerd
仕事 言語学 自然言語 プログラミング言語 エンジニアリング ruby rubykaigi rubykaigi 2025
user-img 石田 隼人 6.9K
slide-thumbnail

チームビルディングと雑談会 -「心理的安全性」とは？-
仕事 スクラム開発 チームビルディング 心理的安全性 雑談 チームビルディングと雑談会 -「心理的安全性」とは？-
user-img 石田 隼人 5.5K
slide-thumbnail

AI 時代の高級言語の意義 -人間の思考・表現の観点から-
仕事 言語学 プログラミング言語 エンジニアリング ruby ai ポリコレ おすすめ本
user-img 石田 隼人 5.3K
各ページのテキスト
1.

The Rails Way とは？ -原則とその向こうへ作成者: 石田 隼人 英語版はこちら 最終更新日: 2025年11月14日 1

2.

自己紹介 • 各種アカウント • • • • • GitHub: @hayat01sh1da X: @hayat01sh1da LinkedIn: @hayat01sh1da Speaker Deck: @hayat01sh1da Docswell: @hayat01sh1da • 職業: ソフトウェアエンジニア • 趣味 • • • • • 言語学 カラオケ 音楽鑑賞 映画鑑賞 猫飼育 2

3.

免許 / 資格 • 英語 • TOEIC® Listening & Reading 915点: 2019年12月 取得 • エンジニアリング • • • • 情報セキュリティマネジメント: 2017年11月 取得 応用情報技術者: 2017年06月 取得 基本情報技術者: 2016年11月 取得 IT パスポート: 2016年04月 取得 • その他 • 珠算2級: 2002年06月 取得 • 暗算3級: 2001年02月 取得 3

4.

スキルスタック • 自然言語 • 日本語: 母語 • 英語: ビジネスレベル • 開発 • バックエンド: Ruby(Ruby on Rails), Python • フロントエンド: TypeScript + React.js, TypeScript +Vue.js • データベース: MySQL, PostgreSQL, MongoDB • アーキテクチャー: モノリス, モジューラーモノリス • ホスティング: AWS ESK • バージョン管理: Git, GitHub • CI/CD: GitHub Actions, ArgoCD • 監視: Datadog, Sentry 4

5.

職歴 期間 業種 職種 業務内容 2021年08月Present EdTech SaaS ソフトウェア エンジニア • バックエンド開発 • フロントエンド開発 • CI/CD 運用・保守 • 週次リリースマネージャー • トラブル対応 • ドキュメンテーション • 技術負債解消 • 技術ブログ記事執筆 • LT 登壇 2020年02月2020年12月 チャットボット系 SaaS バックエンド エンジニア • バックエンド開発 • ドキュメンテーション • 技術負債解消 • 代替 API 検証 5

6.

職歴 期間 業種 職種 業務内容 2018年06月 2020年01月 受託開発 ソフトウェア エンジニア • バックエンド開発 • フロントエンド開発 • トラブル対応 • QA • 技術ブログ記事執筆 2016年04月 2018年01月 SES システムエンジ ニア • 全社アカウント管理者 • Windows Server 運用・保守 • セキュリティ管理者助手 • 翻訳・通訳 6

7.

国際交流活動 • 大学時代 • • • • 英語学ゼミ(マスメディア英語) 国際交流サークル兼部(2年次) 内閣府主催国際交流プログラム(2013年 - 2016年) 日本語学の授業の S 単位取得(最終年次) • 海外生活 • オーストラリアでのワーキングホリデー(2014年04月 - 2015年03月) • • • 2ヶ月間のシドニーの語学学校通学 6ヶ月間の Hamilton Island Resort での就労 1ヶ月間の NSW 州の St Ives High School での日本語教師アシスタントボランティア活動 • その他活動 • • • • • 英語での日々の日記(2014年04月 - 現在) Sunrise Toastmasters Club 参加(2017年02月 - 2018年03月) Vital Japan 参加(2018年01月 - 2019年07月、2022年10月 - 2023年02月) 英語自己学習 Ruby 関連カンファレンス参加 7

8.

Agenda 1. 何故興味を持ったか？ 2. "The Rails Way" の哲学 -MVC vs. 多層構造型3. 主要な責務 -MVC vs. 多層構造型4. 拡張型 The Rails Way の主要構成要素(多層構造型) 5. 長所・短所 6. 漸進的な多層構造の取入れ戦略 7. アンケート回答 8. まとめ 9. 参考文献 8

9.

1. 何故興味を持ったか？ 9

10.

1. 何故興味を持ったか？ Rails アプリケーションのカオスなエコシステム整備のつらみを経験 • 入れ子になったドメイン名前空間: システム種別とアカウント種別 • ※ 次スライド にて図解 • ロジックや実装場所の一貫性のなさ • 冗長な多層構造 • → CQRS, Forms, Validators, Decorators, Serializers など • バックエンド・フロントエンド間の適切に管理されていないルーティング • モジューラモノリスではない「相乗りモノリス」 → 「The Rails Way とは何か」が全く分からん!! 10

11.

1. 何故興味を持ったか？ モジューラモノリス vs. 相乗りモノリス vs. 11

12.

1. 何故興味を持ったか？ とある Rubyist の方が Kaigi on Rails 2025 にて投稿した内容、それが… "rails wayとは何なのか?" 12

13.

1. 何故興味を持ったか？ 13

14.

1. 何故興味を持ったか？ 同意する理由 • 公式な "The Rails Way" の定義がない • → 十人十色の解釈 • MVC エコシステム・CoC 哲学のいずれか、もしくは両方を指している？ • → 曖昧模糊で話が噛み合わない • 「おまかせ」とも違う? • → 作者の DHH すら "The Rails Way" という表現を使っていない → もはや "The Rails Way" という合言葉では Rails アプリケーションのアーキ テクチャについて合意を取れない 14

15.

1. 何故興味を持ったか？ Now is not the time to cry Now's the time to find out why "The Rails Way" Live Forever - Oasis 15

16.

2. "The Rails Way" の哲学 -MVC vs. 多層構造型- 16

17.

2. "The Rails Way" の哲学 -MVC vs. 多層構造型従来の MVC アーキテクチャー • 設定より規約 • 機能を出来る限り推論出来る仕組み • オブジェクト名やプロジェクトの構造に基づく • セットアップよりも製品開発に集中出来るように • 数(単数形/複数形)や格変化(e.g. I-my-me)などの文法上の屈折 • e.g. User モデルはデータベースの users テーブルに相当 • 3層構造: MVC • Models (ActiveRecord) • Views (ERB HTML テンプレート) • Controllers (データフロー制御) 17

18.

2. "The Rails Way" の哲学 -MVC vs. 多層構造型拡張/多層構造型 アーキテクチャー • 構造的な抽象化: 役割の分離 • ロジックのカプセルか • 詳細な実装よりも外側の振舞いに着目 • → オブジェクト指向 • 1対1 の単一かつ明確な責務の割当て • 薄いコントローラーとモデル • 5つ (かそれ以上の) 役割に特化した層: • • • • • プレゼンテーション層 ビジネス/ドメイン層 アプリケーション/サービス層 データ/永続層 インフラ 18

19.

2. "The Rails Way" の哲学 -MVC vs. 多層構造型- vs. 19

20.

3. 主要な責務 -MVC vs. 多層構造型- 20

21.

3. 主要な責務 -MVC vs. 多層構造型責務 MVC 多層構造型 プレゼン テーション • app/controllers/*_controller.rb: インスタンス変数 • app/helper/*_helper.rb: カスタムヘルパー • ActiveModel::Serializers::JSON#as_json • app/serializers/*_serializer.rb • app/view/components/ • app/view/presenters/ フォーム 操作 • app/controllers/*_controller.rb: Strong parameters • app/model/*.rb: バリデーション app/forms/*_form.rb (コンテキスト準拠) ビジネス ロジック Scattered Everywhere • app/controllers/*_controller.rb(concerns を含む) • app/model/*.rb(concerns を含む) • app/views/*.html.erb( アンチパターン)他 • app/model/*.rb • app/services/*_service.rb 認証 • app/controllers/*_controller.rb: Callbacks • app/model/*.rb: Attributes app/policies/*_policy.rb (single source of truth) データ接続 Executed Everywhere • app/controllers/*_controller.rb(concerns を含む) • app/model/*.rb(concerns を含む) • app/views/*.html.erb( アンチパターン)他 • app/commands/*_command.rb • app/repositories/*_repository.rb • app/queries/*_query.rb 21

22.

4. 拡張型 The Rails Way の主要構成要素(多層構造型) 22

23.
24.

4. 拡張型 The Rails Way の主要構成要素(多層構造型) 4-2. アプリケーション/サービス層 • Service Objects: 単一のビジネス関連の操作 • Form Objects: 複数モデルの操作、コンテキストのバリデーション • Filter Objects: ユーザー入力 24

25.
26.
27.

5. 長所・短所 27

28.

5. 長所・短所 従来の MVC アーキテクチャー • • • • 高速な開発: 組込みコマンドやジェネレーターの利便性 設定より規約: 余計な設定ファイル要らずの高い生産性への注力 Gem の豊かなエコシステム: 中核業務 に最大限注力 豊富な資源: サポート熱心な大きなコミュニティからの助力、ドキュメ ント、チュートリアルやその他情報源へのアクセスの良さ • 組込みのセキュリティ関連機能: XSS, CSRF, and SQL injection のような ウェブの脆弱性対応 • 最善策の提供: コードの保守性と信頼性の担保 • プログラマの喜び: 「好きこそものの上手なれ」 28

29.

5. 長所・短所 従来の MVC アーキテクチャー • 初学者にとっての険しい学習曲線: 「魔法」のメカニズムを知る必要が ある • 大規模開発における柔軟性: 拡張型 "The Rails Way" の最適解を見つける のが難しい • 大規模開発におけるパフォーマンス: 優れた並列処理やレスポンスの遅 延の少なさでは最適な選択ではない • デプロイ作業の複雑さ: アセットプリコンパイルやデータベースマイグ レーション、非同期ジョブなど DevOps の知見を必要とするコンポーネン トの管理 • 実行中の処理の実態: 難解なメカニズムによるデバッグやカスタマイズ 体験の悪化 29

30.

5. 長所・短所 拡張/多層構造型 アーキテクチャー • • • • • • • • • • 保守性: 分かりやすい分割単位、コードの特定のし易さ テスト容易性: 分離された層、フレームワークの疎結合 拡張性: 線形成長、独立層 柔軟性: 実装の入替え、コンテキストに即した振舞い 明晰さ: コードがビジネスロジックの仕様書 初手の複雑さ: 数多のファイル、前倒しの設計、険しい学習曲線 遅い立上り: scaffold のサポートなし、単純機能のオーバーヘッド チームの共通認識: 全員の例外なき設計パターンへの合意が必要 デバッグ: スタックとレースの肥大化、経路の複雑化 移行コスト: 既存アプリの継続的なリファクタリング労力 30

31.

6. 漸進的な多層構造の取入れ戦略 31

32.

6. 漸進的な多層構造の取入れ戦略 適切なケース - ROI(投資対効果)が十分 • 実用最小限の製品開発(MVP)の段階を超えた場合 • 3人以上の開発者がいるチームが複数ある場合 • ビジネス/ドメインが複雑な場合 • 長期保守が必要な場合 • 複数の API クライアントを持つサービスの場合 • パフォーマンスのボトルネック MVC アーキテクチャにある場合 32

33.

6. 漸進的な多層構造の取入れ戦略 不適切なケース - ROI(投資対効果)が乏しい • 単純な CRUD アクションだけで完結する場合 • プロトタイプ/実用最小限の製品開発(MVP) の段階である場合 • 1-2人で構成されたチームしかない場合 • 短期のプロジェクトの場合 33

34.

6. 漸進的な多層構造の取入れ戦略 最善策 1. MVC より始めよ: 新規プロジェクトは従来のアーキテクチャーで！ 2. ペインの閾値に刮目せよ: • 200行以上の複数モデル • 複雑なワークフローを処理する複数のコントローラー • 遅くて保守が利かないテスト(必要な挙動の検証が抜け漏れてしまう場合も含む) 3. 漸進的に抽出せよ: 必要な分だけ特定領域に絞ってリファクタリングを！ 4. 規約に準拠せよ: Rails のイディオムを適切に管理(例. ActiveRecord) 5. 美味しいとこ取りせよ: シンプルな箇所は従来の MVC、複雑な個所は多層 構造の上手な適用を！ 34

35.

7. アンケート回答 35

36.

7. アンケート回答 36

37.

7. アンケート回答 37

38.

7. アンケート回答 38

39.

7. アンケート回答 39

40.

7. アンケート回答 40

41.

7. アンケート回答 41

42.

7. アンケート回答 アプリケーションレベルでの Rails っぽい CoC の独自実装の提供 (method_missing の多用を含む) 42

43.

7. アンケート回答 43

44.

7. アンケート回答 Q. あなたが思う "The Rails Way" の条件を自由に記述して下さい - 海外 出身 Rubyists の回答 • 「サービス」の名の下何でも詰め込むんだり dry-rb を多用するのは悪手で、 ActiveRecord とビジネスロジックは密結合し得ることを受け入れる • Rails が持つ最適解に従いコミュニティの好みに合わせること。個人的に は The Rails Way から派生したくなる場面はあるが成長過程にあるチーム ではそれを避けて最適解に従う • Rails はレゴのようなもので、持っているブロックで自分なりの宇宙船を 作れば良い • 抽象化ゆえに Rails に関する意思決定は最適でない場合がある 44

45.

7. アンケート回答 Q. あなたが思う "The Rails Way" の条件を自由に記述して下さい - 日本 人 Rubyists の回答(一部抜粋・加工) • イレギュラーなものはイレギュラーであると皆が自覚できていればそれは まだ The Rails Way を保持できているとしてもよいのかなとも思う • Rails new と scaffold で作られるファイルとディレクトリ構造以外は全て "The Rails Way" ではないとすると、個人的には考えやすい • Rails の用意した CoC に従い RESTful なリソース設計を原則としてビジネス ロジックを Model 層に集約すること • スタートアップの最初期は価値を届けられないと終わる => 製品の価値提 供の最大化に実用的なエコシステムが正義 45

46.

8. まとめ 46

47.

8. まとめ • 従来の MVC: アイデアから実装までのスピードが MVP に最適 • → 狭義の "The Rails Way" • 多層構造化: 規模拡大時の境界の明確化と保守・テスト容易性の担保 • → 広義の "The Rails Way" • • • • • 漸進的な移行: シンプルに始め複雑化した時に初めて多層化を導入 長期保守: 現実に感じるペインを手掛かりにリファクタリング 狭義の "The Rails Way": 大半が CoC + MVC の図式に合意 広義の"The Rails Way": 大半が Service Objects にペインを感じていた "The Rails Way" から外れる時: 海外出身 Rubyists にとってはデフォルトの エコシステムを入れ替えた時で、日本人 Rubyists にとってのそれが CRUD 以外のアクションが生えた時であることと好対照 47

48.

8. まとめ 長い話をまとめると… "Think Less, Create More!" こそ The Rails Way! 48

49.

9. 参考文献 49

50.

9. 参考文献 • Vladimir Dementyev、Layered Design for Ruby on Rails Application 、バーミン ガム、 2023年 • 石田隼人、Layered Design for Ruby on Rails Application - Full Summary 、東京、 2025年 • 石田隼人、Layered Design for Ruby on Rails Application - Concise Summary 、 東京、 2025年 • "The Rails Way" Survey - EN • "The Rails Way" Survey - JP • Statistics of "The Rails Way" Survey • TechRacho、「 Ruby: Dry-rb gemシリーズのラインナップと概要 」、東京、 2017年 50

51.

EOD 51