可観測性を目的思考で捉え直す_-Squadが自律的に改善できるO11y基盤づくり_Railsモジュラーモノリス___DevPlatform_Squadの取り組み-

Transcript

1. 2026/02/10　Shuhei Kanamori 可観測性を目的思考で捉え直す -Squadが自律的に改善できるO11y基盤づくり Railsモジュラーモノリス × DevPlatform Squadの取り組み- @_MoneyForest
2. 自己紹介 金森 秀平(@_MoneyForest) - 所属: タイミー プラットフォームエンジ ニアリングチーム - うさぎ（7歳♂）を育ててます
3. 目次 • タイミーの組織とそのアーキ テクチャ • 目的思考のアプローチ • モジュラーモノリス × APMの 工夫
4. 1 タイミーの組織とそのアー キテクチャ
5. ２層構造の組織設計 【実組織】プロダクト本部・エンジニアリング本部 └─ 責務: メンバーのスキル・キャリア・Well-being支援 【仮想組織】Tribe / Squad（バリューストリーム） └─ 責務: 顧客価値をスピード感を持って実現 └─ 各Tribeが重要指標（KPI）に責任を持つ └─ Tribeの配下にSquadが存在 • メンバーは両方に所属（マトリクス型） • 「個人の成長」と「価値提供」の責務を分離し、異動のアジリティを確保
6. Tribe/Squad制とKPI 【仮想組織 - マッチングTribe】 └─ KPI: 稼働率（募集に対する実稼働率） └─ 申し込み、マッチング等を担当するSquadが存在 【仮想組織 - スポットワークシステムTribe】 └─ KPI: 信頼性 └─ 勤怠、決済等を担当するSquadが存在 • 各SquadにPdM/Engineer/Designer/Analystが属し、TribeはGroup PdMが統括 • ユーザージャーニー、顧客価値はSquadが強く向き合う
7. モジュラーモノリスアーキテクチャ Railsモジュラーモノリス（Packwerk活用） packs/ ├─ attendances/ # 勤怠機能 ├─ payments/ # 決済機能 ├─ offerings/ # 募集機能 └─ ... # その他多数 • ビジネスドメイン単位でパッケージを分割 • 各パッケージ ≒ Squad の責務領域
8. CODEOWNERSでチーム責務を明確化 .github/CODEOWNERS /packs/attendances/ → 勤怠機能担当Squad /packs/payments/ → 決済機能担当Squad /packs/offerings/ → 募集機能担当Squad • コードとチームが紐付く • PRレビューの自動割り当て • 「誰に聞けばいいか」が明確化
9. なぜこの前提が重要か 組織構造 × Railsアーキテクチャ → Squadごとの自律改善が重要 各SquadがKPIに責任を持つ └─ KPIに紐づくUJ/SLOがある └─ ドメイン単位でコードとチームを紐付ける └─ Squadが自律的に改善できる仕組みが必要 → この前提があるから「目的思考のO11y」が機能する
10. 2 目的思考のアプローチ
11. ✨ 理想：メトリクス、APMで問題を早 期発見・改善 • Datadogを導入した • ダッシュボードを作った • アラートを設定した よくある失敗パターン（課題の整理） ⚠ 現実：形骸化しがち • メトリクスは取っているが活用できて いない • アラートが鳴っても反応がない • ダッシュボードを作ったが見ない なぜ？ → 目的が不明確だから
12. 検索基盤（Elasticsearch）の負荷が急上昇 実際に困った事例：検索基盤の負荷急上昇 • クラスター全体の検索時間 → 遅いことは確認 • スレッドプールのキュー滞留 → 深刻度は把握 ❌ 「なんで遅いか」がわからず、改善 が進まなかった
13. 実はElastic CloudのIntegrationでは取得できるメトリクスに限界があった なぜ特定できなかったのか ✅ 取れていたもの • クラスター全体の検索時間 • 書き込み/マージの詳細時間 • スレッドプール統計 ❌ 取れていなかったもの • インデックス単位の詳細メトリクス （index.search.query.timeなど）
14. Squadが自律的に改善するには何が必要？ 「どのインデックスがなんで遅いか」がわかること -> 現状わかっていない 目的から逆算してメトリクスを取得する 再整理の結果： • Elastic Cloud Integrationだけでは不 足 • Datadog Agent経由でESを直接叩くこ とでIndex単位の詳細メトリクスが取得可 能と判明 → 目的（Squadが自律改善できる）から逆算して必要 なメトリクスを確認する → 「なんとなく連携」から「目的思考の連携」へ
15. まとめ：目的思考のポイント ❌ Before: どのメトリクスを取る か？ → ツール起点、手段が目的化 ✅ After: なぜそのメトリクスが必要なの か？ → 目的起点、改善方法から逆算 • 「何を計測するか」より「なぜ計測するか」 • 目的が不明確だと形骸化する • 具体的な改善イメージから逆算して必要なメトリクスを取得する
16. 3 モジュラーモノリス × APMの工夫
17. Squadごとの自律改善を支え る工夫
18. 🤔 DBやHTTPリクエストにかかっ た時間くらいしか見えない 🤔 時間がかかっていることはわ かっても、どう改善していいかが導 きづらい Rails APMの特性：ゼロコード計装 Railsは「ゼロコード計測」が主流 • Datadog gemを入れるだけでフ レームワークに沿った粒度でトレー ス取得開始 • 自分でスパンを切る文化はあま りない
19. ボトルネックの割合として大きいのはデータベース Rails × APMありがちなボトルネック ✅ APMにDatabase Monitoringを 紐付ける → クエリのExplainがAPMに紐づく ことで改善オポチュニティを探索し やすくなる •Active Recordの抽象度が高い → 意図せず重いクエリが発行さ れがち • N+1問題も起こりやすい → こちらはAPMのスパン数から わかり、ゼロコード計装でも気づくこ とが可能
20. CUJ × Squad × コード × APM/DBMの紐付け Squadが「自分たちのパフォーマンス」として APM + DBMを見ながら改善できるように
21. code_ownerタグによる可視化 各リクエストのトレースに「code_owner」タグを自動付与 • 自分たちがオーナーのリクエストが遅いことがわかる • DBM連携によりDBの改善オポチュニティも探索しやすく
22. 🙅やっていないこと • 各Squadの代わりにSLO/CUJを 決める • 各Squadの代わりにパフォーマン ス改善する（あくまでやる時は Squad Drivenでコラボレーションす る） O11yにおけるDevPlatform Tribe/Squadの役割 🙆やること • O11y基盤整備（code_ownerタ グ、DBM連携等の新機能活用） • 定点観測による最低限の品質担 保 • 複雑な性能問題をSquadとコラ ボレーションして解決
23. まとめ：Squadが自律改善できる状態へ 1. 目的から逆算してメトリクスを取得 → 「何を取るか」より「なぜ取るか」 → 目的が不明確だと形骸化する 2. コード × Squad × APM/DBMを紐付ける → code_ownerタグで「誰が改善すべきか」を明確に → DBM連携でRailsのありがちなボトルネック（ DB）に対処 3. プラットフォームチームは基盤整備とイネーブラーに徹する → 各Squadが自律的に改善できる状態を作る → Squadの代わりに決めたり改善を行うことはしない
24. Howの詳細は後半の 「O11yによる可視化で実現する、チー ム独立型パフォーマンス改善」 をお楽しみに！