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

Transcript

1. Railsアプリから何を切り出す？ 機能分離の判断基準 yumu 2025.09.27 Kaigi on Rails 2025 1
2. 2 自己紹介 GMOペパボ　minne事業部　プロダクト開発チーム yumu(湯村 美吹香) 新卒3年目、エンジニア5年目、Rubyist5年目 バックエンド > インフラ >>> フロント 昨年のKoRでスポンサーLTをしました。 💎 推しのgem ： Shoryuken（ロゴ募集中） 💎 推しの漫画 ： メイドインアビス 💎 X : @myumura3
3. 3 minneとは 作家・ブランド数 95万件以上 登録作品数 1800万件以上 リリース 13年目 アプリ ダウンロード数 1500万以上
4. 4 minneのアーキテクチャ（ものすごくざっくり） minne-app minne-web-front minne-auth
5. 5 minneのアーキテクチャ（ものすごくざっくり） minne-app minne-web-front minne-auth
6. 大規模ECサイトでの現実 6 開発速度の低下 DBパフォーマンス の悪化 コードベースの 複雑化 6
7. 7 こんな迷いを抱えたことはありませんか？ この機能、切り出した 方がいいのかな？
8. 実際に分離した/分離を検討した機能の一部 88 • 動画変換機能 → Shoryuken workerサービス化 • アナリティクス機能 → Cloud Run Functions化 • リワード広告機能 → Lambda関数化 • サブスクリプション機能 → 分離見送り Ruby×AWSで作る動画変換システム Google Cloudで作るニアリアルタイムアクセス解析基盤
9. 今日お話しすること 99 実践的な判断基準
10. 今日お話しすること 10 10 1. 背景と課題 • なぜ機能分離が必要になったか 2. 5つの判断軸 • 実践的なフレームワーク 3. 実践事例 • 成功・失敗パターンの分析 4. まとめ • 考え方のポイント
11. 11 5つの判断軸
12. ５つの判断軸 12 12 1. ビジネスロジックとの関連度 2. 他インフラリソースとの依存関係 3. 機能の複雑さ 4. 運用コスト vs 開発スピード 5. ビジネス上の柔軟性が求められるか
13. ５つの判断軸 13 13 軸1： ビジネスロジックとの関連度 　 高関連（分離避ける） 　 低関連（分離候補） • コア機能（商品管理・注文・決済） • 複数テーブル・モデルとの強い関連 • 技術的処理（動画変換） • 分析系（アクセス解析） 事例：　サブスクリプション機能 ✍ ユーザーの権限制御・決済処理...との関連が強く分離見送り
14. ５つの判断軸 14 14 軸2： 他インフラリソースとの依存関係 　 強依存（分離困難） 　 弱依存（分離可能） • MySQLの直接参照が必要 • 認証基盤への依存 • S3経由でのデータ受け渡し • API経由での疎結合 • MySQL以外のDBを使用 事例：　動画変換機能 ✍ S3・SQS経由で処理完結、ビジネスロジックとも無関係で分離
15. ５つの判断軸 15 15 軸3： 機能の複雑さ 　 複雑（要検討） 　 シンプル（分離しやすい） • 複数サービス連携 • データフローが複雑 • 単一責任で外部依存少 事例：　アナリティクス機能 ✍ 行動ログの集計を行うシンプルな機能。Cloud Run Functionsとして分離
16. 事例：　リワード広告機能 ✍ 運用コストは増加したが、適切な技術スタックが選択可能に ５つの判断軸 16 16 軸4： 運用コスト vs 開発スピード 　 運用コスト重視（分離リスク高） 　 開発スピード重視（分離メリット大） • 複数デプロイパイプライン管理 • 分散したログ・監視 • 追加のインフラコスト • 独立したリリースサイクル • 技術スタック選択の自由
17. 事例：　リワード広告機能 ✍ 運用コストは増加したが、適切な技術スタックが選択可能に ５つの判断軸 17 17 軸4： 運用コスト vs 開発スピード 「コンウェイの法則」 組織構造とシステム構造のミスマッチ 　 運用コスト重視（分離リスク高） 　 開発スピード重視（分離メリット大） • 複数デプロイパイプライン管理 • 分散したログ・監視 • 追加のインフラコスト • チームの対応力不足 • 独立したリリースサイクル • 技術スタック選択の自由
18. ５つの判断軸 18 18 軸5： ビジネス上の柔軟性が求められるか 　 求められない（分離メリット小） 　 求められる（分離メリット大） • 単純な機能改善で十分 • 単一用途のみ • 切り捨て可能性が重要 • 他サービスでも活用したい 事例：　動画変換機能 ✍ 他サービスでも活用可能なシステム
19. 判断マトリックス 19 19 判断軸 　 分離推奨 　 要検討 　 分離回避 ビジネス関連度 低 中 高 インフラ依存 弱 中 強 複雑さ シンプル 中 複雑 運用コスト vs 開発スピード 開発スピード重視 バランス 運用コスト重視 ビジネス上の柔軟性 求められる 中程度 求められない ３つ以上が　 分離推奨 👉 積極的に検討 2つ以上が　 分離回避 👉 慎重に判断
20. 20 実践事例
21. 21 実践事例①　成功パターン 動画変換機能 ・ アナリティクス機能 💡 Railsアプリケーションの複雑性緩和 ・ 他サービスで活用可能 判断軸 　 分離推奨 　 要検討 　 分離回避 ビジネス関連度 低 中 高 インフラ依存 弱 中 強 複雑さ シンプル 中 複雑 運用コスト vs 開発スピード 開発スピード重視 バランス 運用コスト重視 ビジネス上の柔軟性 求められる 中程度 求められない
22. 22 実践事例②　要注意パターン リワード広告機能 💡 想定より複雑 ・ 運用コストとのトレードオフだが柔軟性重視で分離継続 判断軸 　 分離推奨 　 要検討 　 分離回避 ビジネス関連度 低 中 高 インフラ依存 弱 中 強 複雑さ シンプル 中 複雑 運用コスト vs 開発スピード 開発スピード重視 バランス 運用コスト重視 ビジネス上の柔軟性 求められる 中程度 求められない
23. 23 実践事例③　分離回避パターン サブスクリプション機能 💡 分離見送り ・ Railsアプリケーション内で最適化 判断軸 　 分離推奨 　 要検討 　 分離回避 ビジネス関連度 低 中 高 インフラ依存 弱 中 強 複雑さ シンプル 中 複雑 運用コスト vs 開発スピード 開発スピード重視 バランス 運用コスト重視 ビジネス上の柔軟性 求められる 中程度 求められない
24. 24 まとめ
25. 【再掲】５つの判断軸 25 25 1. ビジネスロジックとの関連度 2. 他インフラリソースとの依存関係 3. 機能の複雑さ 4. 運用コスト vs 開発スピード 5. ビジネス上の柔軟性が求められるか
26. 考え方のポイント 26 26 • 完璧な分離はなかなかない。トレードオフを理解して判断 • チームの状況によって各軸の重みは変わる • 分離された機能はAIが理解・活用しやすい • 失敗から学び、判断基準を磨く
27. 27 Thank You! Thank You!