Railsアプリから何を切り出す？機能分離の判断基準　Kaigi on Rails 2025

by yumu

Slide 1

Slide 1 text

Railsアプリから何を切り出す？機能分離の判断基準 yumu 2025.09.27 Kaigi on Rails 2025 1

Slide 2

Slide 2 text

2 自己紹介 GMOペパボ　minne事業部　プロダクト開発チーム yumu(湯村美吹香) 新卒3年目、エンジニア5年目、Rubyist5年目バックエンド > インフラ >>> フロント昨年のKoRでスポンサーLTをしました。 💎 推しのgem ： Shoryuken（ロゴ募集中） 💎 推しの漫画：メイドインアビス 💎 X : @myumura3

Slide 3

Slide 3 text

3 minneとは作家・ブランド数 95万件以上登録作品数 1800万件以上リリース 13年目アプリダウンロード数 1500万以上

Slide 4

Slide 4 text

4 minneのアーキテクチャ（ものすごくざっくり） minne-app minne-web-front minne-auth

Slide 5

Slide 5 text

5 minneのアーキテクチャ（ものすごくざっくり） minne-app minne-web-front minne-auth

Slide 6

Slide 6 text

大規模ECサイトでの現実 6 開発速度の低下 DBパフォーマンスの悪化コードベースの複雑化 6

Slide 7

Slide 7 text

7 こんな迷いを抱えたことはありませんか？この機能、切り出した方がいいのかな？

Slide 8

Slide 8 text

実際に分離した/分離を検討した機能の一部 88 ● 動画変換機能 → Shoryuken workerサービス化 ● アナリティクス機能 → Cloud Run Functions化 ● リワード広告機能 → Lambda関数化 ● サブスクリプション機能 → 分離見送り Ruby×AWSで作る動画変換システム Google Cloudで作るニアリアルタイムアクセス解析基盤

Slide 9

Slide 9 text

今日お話しすること 99 実践的な判断基準

Slide 10

Slide 10 text

今日お話しすること 10 10 1. 背景と課題 • なぜ機能分離が必要になったか 2. 5つの判断軸 • 実践的なフレームワーク 3. 実践事例 • 成功・失敗パターンの分析 4. まとめ • 考え方のポイント

Slide 11

Slide 11 text

11 5つの判断軸

Slide 12

Slide 12 text

５つの判断軸 12 12 1. ビジネスロジックとの関連度 2. 他インフラリソースとの依存関係 3. 機能の複雑さ 4. 運用コスト vs 開発スピード 5. ビジネス上の柔軟性が求められるか

Slide 13

Slide 13 text

５つの判断軸 13 13 軸1：ビジネスロジックとの関連度　高関連（分離避ける）　低関連（分離候補） ● コア機能（商品管理・注文・決済） ● 複数テーブル・モデルとの強い関連 ● 技術的処理（動画変換） ● 分析系（アクセス解析）事例：　サブスクリプション機能 ✍ ユーザーの権限制御・決済処理...との関連が強く分離見送り

Slide 14

Slide 14 text

５つの判断軸 14 14 軸2：他インフラリソースとの依存関係　強依存（分離困難）　弱依存（分離可能） ● MySQLの直接参照が必要 ● 認証基盤への依存 ● S3経由でのデータ受け渡し ● API経由での疎結合 ● MySQL以外のDBを使用事例：　動画変換機能 ✍ S3・SQS経由で処理完結、ビジネスロジックとも無関係で分離

Slide 15

Slide 15 text

５つの判断軸 15 15 軸3：機能の複雑さ　複雑（要検討）　シンプル（分離しやすい） ● 複数サービス連携 ● データフローが複雑 ● 単一責任で外部依存少事例：　アナリティクス機能 ✍ 行動ログの集計を行うシンプルな機能。Cloud Run Functionsとして分離

Slide 16

Slide 16 text

事例：　リワード広告機能 ✍ 運用コストは増加したが、適切な技術スタックが選択可能に５つの判断軸 16 16 軸4：運用工数 vs 開発スピード　運用コスト重視（分離リスク高）　開発スピード重視（分離メリット大） ● 複数デプロイパイプライン管理 ● 分散したログ・監視 ● 独立したリリースサイクル ● 技術スタック選択の自由

Slide 17

Slide 17 text

事例：　リワード広告機能 ✍ 運用コストは増加したが、適切な技術スタックが選択可能に５つの判断軸 17 17 軸4：運用コスト vs 開発スピード　運用コスト重視（分離リスク高）　開発スピード重視（分離メリット大） ● 複数デプロイパイプライン管理 ● 分散したログ・監視 ● チーム対応力不足 ● 独立したリリースサイクル ● 技術スタック選択の自由「コンウェイの法則」組織構造とシステム構造のミスマッチ

Slide 18

Slide 18 text

５つの判断軸 18 18 軸5：ビジネス上の柔軟性が求められるか　求められない（分離メリット小）　求められる（分離メリット大） ● 単純な機能改善で十分 ● 単一用途のみ ● 切り捨て可能性が重要 ● 他サービスでも活用したい事例：　動画変換機能 ✍ 他サービスでも活用可能なシステム

Slide 19

Slide 19 text

判断マトリックス 19 19 判断軸　分離推奨　要検討　分離避けるビジネス関連度低中高インフラ依存弱中強複雑さシンプル中複雑運用コスト vs 開発スピード開発スピード重視バランス運用コスト重視ビジネス上の柔軟性求められる中程度求められない３つ以上が　分離推奨 👉 積極的に検討 2つ以上が　分離避ける 👉 慎重に判断

Slide 20

Slide 20 text

20 実践事例

Slide 21

Slide 21 text

21 実践事例①　成功パターン動画変換機能・アナリティクス機能 💡 Railsアプリケーションの複雑性緩和・他サービスで活用可能判断軸　分離推奨　要検討　分離避けるビジネス関連度低中高インフラ依存弱中強複雑さシンプル中複雑運用コスト vs 開発スピード開発スピード重視バランス運用コスト重視ビジネス上の柔軟性求められる中程度求められない

Slide 22

Slide 22 text

22 実践事例②　要注意パターンリワード広告機能 💡 想定より複雑・運用コストとのトレードオフだが柔軟性重視で分離継続判断軸　分離推奨　要検討　分離避けるビジネス関連度低中高インフラ依存弱中強複雑さシンプル中複雑運用コスト vs 開発スピード開発スピード重視バランス運用コスト重視ビジネス上の柔軟性求められる中程度求められない

Slide 23

Slide 23 text

23 実践事例③　分離回避パターンサブスクリプション機能 💡 分離見送り・ Railsアプリケーション内で最適化判断軸　分離推奨　要検討　分離避けるビジネス関連度低中高インフラ依存弱中強複雑さシンプル中複雑運用コスト vs 開発スピード開発スピード重視バランス運用コスト重視ビジネス上の柔軟性求められる中程度求められない

Slide 24

Slide 24 text

24 まとめ

Slide 25

Slide 25 text

【再掲】５つの判断軸 25 25 1. ビジネスロジックとの関連度 2. 他インフラリソースとの依存関係 3. 機能の複雑さ 4. 運用コスト vs 開発スピード 5. ビジネス上の柔軟性が求められるか

Slide 26

Slide 26 text

考え方のポイント 26 26 ● 完璧な分離はなかなかない。トレードオフを理解して判断 ● チームの状況によって各軸の重みは変わる ● 分離された機能はAIが理解・活用しやすい ● 失敗から学び、判断基準を磨く

Slide 27

Slide 27 text

27 Thank You! Thank You!