モノタロウにおけるSREの現在地：モダナイゼーションの過程で変化していく組織に、SREはどう向き合ったか

Transcript

1. 2026/1/31 SRE Kaigi 2026 株式会社MonotaRO プラットフォームエンジニアリング部門 SREグループ Ryo Kawahata モダナイゼーションの過程で変化していく組織に SREはどう向き合ったか © 2025 MonotaRO Co., Ltd. モノタロウにおけるSREの現在地
2. 自己紹介 2/23 河畑　凌（カワハタ　リョウ）（ちゃんかわ） 株式会社 MonotaRO プラットフォームエンジニアリング部門 SRE グループマネージャー 2023年03月に中途入社 オブザーバビリティ向上に向けたシステム監視や運用の改善、 SREのプラクティスの推進に従事
3. 会社紹介 © 2024 MonotaRO Co., Ltd.
4. モノタロウの事業 BtoB を対象に、 自ら間接資材の在庫を持ち、 自らオンラインで売るEC企業 商品採用、物流、SCM、マーケティン グ、データサイエンス、IT など多くの業務とシステムを 自社開発、自社運用もしている フルスタック EC カンパニー
5. モノタロウの事業 ※2024年（単体）の実績
6. 複雑で多様な課題 Intro デジタルとリアルが複雑に絡み合う世界で 各フェーズにおいて進化が求められている
7. お客様の「時間価値を高める」ために、中小企業・大企業 それぞれのニーズに合わせたサービスを提供 　　　　　 大企業向け 独自の購買管理システム／システム連携 提供しているサービス 　　　　　 中小企業向け ECサイト（monotaro.com） 2-1
8. ここから本題
9. 9/23 今回お話ししたいこと SREのあり方は、環境変化に伴い常に問われるテーマです。 我々もシステムモダナイゼーションの過程で、システムと組織が大きく変わりました。 しかし、そのような変化の中でも「SREは価値のある取り組み」と考え数年にわたり 継続して実践しています。 様々な場面において、どのような仮説を立てて、どういったことを実践したか、そこか らどのような変化がもたらされたか、事例と知見を共有します。
10. エンジニアリングのチャレンジ 事業成長に貢献するため、 アーキテクチャの再構築とシステムのモダナイズに挑む 現在の課題 　　　　　 取組方針 システム・業務の長年の変化に伴う複雑性 20年間の安定した成長に伴い、組織とシステムも拡 大。そのため、新たな取り組みに対する調整コストが 増加している状況。 また、サービスが高度化し、独自の発展を遂げている ことにより、システムの複雑性が増している。 変更容易性の低下 システムが複雑になるにつれて、経営戦略や戦術への 迅速な対応が難しくなっている。 注力すべきサービスの進化に十分なリソースを割り当 てることが困難な状況。 方針：分割統治 大きな問題を小さな部分問題に分割し、それぞれを個別に解決する「分割 統治」戦略を採用。これにより、システムの複雑性を制御可能な範囲に抑 え、事業のさらなるスケールにも貢献する。 方法：ドメインモデリングと イベントドリブンアーキテクチャの導入 システムをビジネスドメインごとに分割し、各ドメイン間の連携をイベ ント駆動で行うアーキテクチャを採用。これにより、システムの変更容 易性を高め、ビジネスの変化に迅速に対応できる基盤を構築する。
11. 11/23 システムイメージ ＊システムイメージは 2024.03 時点もの
12. 12/23 モノタロウでの SRE における重要なイベント 〜2022年 ECサイトのSLOベースの運用を開始 2023年 コンテナ基盤運用を本格化、マイクロサービス化が進展 ↑前半パート ↓後半パート 2024年 プラットフォームエンジニアリング部門が設立 2025年〜 モダナイゼーションスコアの運用を開始
13. ECサイトのSRE
14. 2022年 ~ 2023年 の SRE グループの立ち位置 コアシステムエンジニアリング （CSE）部門 Mission 業務例 ビジネスの成長を 支えるITの提供 顧客体験向上の ための継続開発 大企業ビジネスの 成長加速 より良い仕事環境 の提供 価値提供の 基盤開発 • 内製基幹システムの導入、開発、運用 • 倉庫管理システム／インフラの構築、運用 • 会計システムの開発、運用 • ECサイト機能の開発、運用 • マーケティング基盤の開発、運用 • 大企業連携システムの開発、運用 • オフィスインフラの構築、保守運用 • オフィス系サービスの導入、運用 • ITサポート • セキュリティ統括 • サーバインフラの構築、運用 • データ基盤の構築、運用 • システム開発／保守基盤の構築、運用 • DevOps／Webセキュリティ ECシステムエンジニアリング （ECSE）部門 エンタープライズビジネス エンジニアリング（EBE）部門 コーポレートエンジニアリング （CE）部門 プラットフォームエンジニア リング（PE）部門 部門 SREグループ
15. 15/23 2022年 ~ 2023年 の SRE グループの立ち位置 ＊システムイメージは 2024.03 時点もの SREグループ
16. 16/23 ~2022年: SLOベースでの運用の始まり • 当時の状況 ◦ ビジネスもシステムもスケールしていく中で、サイトが不安定になるトラブ ルがたびたび発生していて、SRE への機運の高まりつつあった • 何をした ◦ Google社のSREの研修を受講 ◦ CUJの作成とそれに基づく SLI/SLO の設計 ◦ ECサイト（monotaro.com）へのSLOベースの運用開始 ◦ ポストモーテムの運用開始 ◦ オンコール体制の整備 詳細はテックブログ📗をチェック！ SRE導入: システムを安定させる4000万円の魔法の壺 https://tech-blog.monotaro.com/entry/2022/09/13/090000
17. 17/23 2023年: コンテナ基盤運用を本格化、マイクロサービス化が進展 • 当時の状況 ◦ 既存アプリのコンテナ化が本格化し、徐々にコンテナ基盤(Kubernetes）上 で稼働し始める ◦ また、既存アプリだけでなく、マイクロサービスとして切り出されたアプリ ケーションも登場し始める • 何をした ◦ 既存のSLOベースの運用を継続 ◦ SLO運用の拡大に向けた普及活動 ▪ 大企業連携システム、一部のバッチ、各種 API など
18. 18/23 当初策定された SRE の実践レベル（2022年→2023年） 18 レベル 0 (初期状態) Level 1 (見える化) Level 2 (コントロール) Level 3 (標準化・スケール) 国内EC SLO ベースの運用 オンコール 　見える化 　手順化、訓練 SLO ベースの運用 　CUJ, SLO 設計 　ダッシュボード作成 SLO ベースの運用 　アラート実装 　開発チームに展開 オンコール 　オンコールポリシー 　エラーバジェットポリシー SLO ベースの運用 　各システムの運用を切り替え ログ集約 　ログ基盤の構築 　旧ログ基盤の廃止 ログ集約 　データ保管ポリシー 　セキュリティポリシー ログ集約 　各システムがログ基盤を利用 オンコール 　各開発チームに展開 モニタリング 　現状の運用 　ツール/サービス選定 モニタリング 　設定のコード化 　CI/CD の仕組み化 モニタリング 　各開発チームが仕組みを利用 デリバリー 　Four Keys 計測 　CI, カナリアリリース デリバリー オンコール デリバリー 　CD 基盤 デリバリー 　各システムが利用 マイクロサービス マイクロサービス 　コンテナ化 マイクロサービス 　マイクロサービス基盤 ログ集約 モニタリング マイクロサービス 　各システムが利用 　アプリケーションのひな形 2022年 2023年
19. 19/23 CUJの例
20. 20/23 SLI/SLOの例
21. 21/23 SRE 拡大時に活用したもの • 共通の Terraform Module • 実測値計測用スクリプト（Google Colab） • 毎日のエラーバジェットレポート/毎月の振り返りの会議体 • インシデント対応用 Slack Bot • 各種ドキュメント類 ◦ Runbook: サイトオンコール対応 ◦ Runbook: ポストモーテム作成ガイド ◦ エラーバジェットポリシー ◦ トラブル状況ドキュメント ◦ SRE を学ぶ教材
22. 22/23 ツールの例 • ← Terraform Module Google Colab のテンプレート→
23. 23/23 エラーバジェットレポート ← Slack で通知 BigQuery でデータを保持し Looker Studio でまとめて可視化 →
24. 24/23 当時のSLOベースの運用の期待と現実① 期待 SLOが信頼性の代表指標になれば、「念のため」に設定された冗長なアラートは自然 と削減されるのではないか 現実 → ✖ • SLO導入だけでは不十分で、「このアラートは本当に必要か」を問う棚卸し活動 が別途必要だった
25. 25/23 当時のSLOベースの運用の期待と現実② 期待 ウェブベースのサービスに対するSLOだけでなく、バックエンドAPIやデータパイプラ インやバッチシステムについても SLO ベースの運用が拡大していくのではないか 現実 • バックエンドAPI ◦ ◯ マイクロサービス化と相まって SLO の利用が拡大 • データパイプラインやバッチシステム ◦ ✖ 次のページで詳細を説明
26. 26/23 データパイプラインやバッチシステムに対する SLO 運用の難しさ • SLI/SLOの設計に時間がかかる ◦ CUJ との関係性、目標値の妥当性、理解のしやすさなど • マニュアルでの計装が前提かつ、計装のハードルが高い ◦ 特にバッチはレガシーなものが多い • アプリケーションの作りや扱うデータに依存する部分も多く標準化も難しい
27. 27/23 バッチシステムに適用したSLOの例 SLIタイプ ：Data Processing: Freshness SLI仕様 ：300分以内に処理された配送状況レコードの割合 SLI実装: DeliveryStatusテーブルの updateTime（最終更新日時）と reportingTime（報告 日時）の差が300分以内のレコードの割合 配送業者のデータ提供からバッチ処理完了までの時間を計測する updateTime（データの更新日時） と reportingTime（報告日時） の差が p99 (=555分) の実績値を上回る場合は SLO計算から除外する（外れ値の除外） 長所 システムの改善活動につなげやすい 　ジョブの速度改善 　ジョブの頻度、タイミングの見直し 　配送業者に対するフィードバックの材料になる 短所 　ユーザが実際に参照したかどうかは加味されない SLO ： 1ヵ月間の配送状況において、 90%が300分以内に処理されている このSLOにより、バッチの成功失敗以外の 観点でバッチの状況を知ることができた 一方で、バッチそのものに対する 具体的な改善や目標値に対する議論につな がったかという点では改善の余地はあった SLI の妥当性の評価や再設計をすべきだ が、それを反復するには設計や実装にかか るコストが大きすぎた ※ 一部変更あり
28. 28/23 当時のSLOベースの運用の期待と現実③ 期待 「エラーバジェットが残り◦%と余裕があるので、リリース回数を増やしましょう」 といったエラーバジェットに基づく意思決定が頻繁に行われるのではないか 現実 → △ • 用語は浸透したが、意思決定への活用は限定的だった
29. 29/23 SLO ベースの運用で特に顕在化した課題 SLO は 「何を」を示してくれていたが、「なぜ」に辿り着けていない状況だった 1. とあるページのレイテンシが悪化し、このままだと数日後にはエラーバジェット が枯渇してしまう状況 2. しかしながら原因は（すぐには）特定できず、加えて、モダナイゼーション過渡 期にあり、システムは常に変化し続けていた 3. （可用性と比較すると）直ちにユーザに影響がない状況なので、優先度も上がら ず 4. その結果、SLO を緩和してしまう、静観していたらいつの間にかバジェットが復 活していた、というケースがしばしば発生 いわゆる、第一原理からデバッグできない状況 → オブザーバビリティの重要性を認識
30. プラットフォームの立場からの SRE
31. 31/23 システムの変化 ＊基幹システムの場合
32. 2024年以降の SRE グループの立ち位置の変化 コアシステムエンジニアリング （CSE）部門 Mission 業務例 ビジネスの成長を 支えるITの提供 顧客体験向上の ための継続開発 大企業ビジネスの 成長加速 より良い仕事環境 の提供 価値提供の 基盤開発 • 内製基幹システムの導入、開発、運用 • 倉庫管理システム／インフラの構築、運用 • 会計システムの開発、運用 • ECサイト機能の開発、運用 • マーケティング基盤の開発、運用 • 大企業連携システムの開発、運用 • オフィスインフラの構築、保守運用 • オフィス系サービスの導入、運用 • ITサポート • セキュリティ統括 • サーバインフラの構築、運用 • データ基盤の構築、運用 • システム開発／保守基盤の構築、運用 • DevOps／Webセキュリティ ECシステムエンジニアリング （ECSE）部門 エンタープライズビジネス エンジニアリング（EBE）部門 コーポレートエンジニアリング （CE）部門 プラットフォームエンジニア リング（PE）部門 部門 SREグループ
33. 33/23 プラットフォームエンジニアリング部門のミッション 「価値提供の流れ」をより信頼性の高いものにし、かつ、従業員の認知負荷の低減などによって、「価値提供の流れ」が より効果的に流れることを促進する。 → ざっくりとは、開発プロセスの支援やプラットフォームによって開発者に貢献すること
34. 34/23 SREグループについて メンバー 3名（2026/01末時点） ビジョン 開発チームが、以下の問いに対して自信をもって判断・行動できる状態を実現する ▪ サービスは十分に信頼できますか？ ▪ 今は機能開発ではなく、信頼性改善に注力すべきですか？ ▪ ユーザーは現状に満足しているでしょうか？ ミッション システムの信頼性の観点から、開発チームが意味のある意思決定をできる状態を支える
35. 35/23 SREグループがオブザーバビリティへ取り組む意義 オブザーバビリティは信頼性に対する判断・行動 の「質」を変える • 数字を出すだけでは信頼性は守れない • 事実を観測し、正しい判断と改善へつなげる 元々 EC サイトの SRE グループ時代に SLO ベースの運用をする上でオブザーバビリティの 重要性は認識していた ↓ プラットフォームエンジニアリングの立場から、オブザーバビリティ向上に向けて取り組む ことは、全社的に SLO ベースの運用を拡大させる観点では非常に重要と判断した
36. 36/23 SRE の取り組み方に対する課題感 「ECサイトに特化して、そのシステムに最適化したSREの導入」→ 「複数システム(EC・基幹・大企業連携)を横断的に支援する立場へ」 特定システム向けの個別対応ではなく、 どのシステムでも使える共通的な仕組み・基盤を提供する必要が出てきた 「ストリームアラインドチームの一員として、エンドユーザーやシステムの状況を身近に感じら れる環境」→「PE部門という横断組織の立場で、各システムから一歩離れた位置へ」 現場の開発者が何に困っているか、どんな支援を必要としているかを把握しづらくなった。積極 的にコミュニケーションを取り、ニーズを汲み取る仕組みが必要
37. 37/23 監視を支える基盤に対する課題感 連携されていない 各種テレメトリ 多種多様だが役割がはっきりしない 監視バックエンド メンテが追いついていない 各種エージェント パイプラインの不在によ りテレメトリのフィルタ リングやサンプリングな どのコントロールが困難 古い言語 バージョンと 点在する レガシーな計装
38. 38/23 インシデント対応における課題感 • ポストモーテムの負荷が高い ◦ インシデント対応の際の情報収集 ◦ ドキュメントの準備 ◦ 関係者との調整 • インシデント対応における成果物（チケット、ポストモーテムなど）が１箇所で 管理されていない • アクションアイテムがトラッキングされていない • インシデント対応そのものの定量的、定性的な評価がなされていない • などなど
39. 39/23 SRE グループの3つの取り組みの軸 プラットフォームの軸 監視Agentや監視バックエンドの管理・運用・改善 Enabling/Embeddedの軸 開発チームへのSREプラクティスの普及・オブザーバビリティ向上に向けた支援 プロセスの軸 インシデント対応の型化と改善、 ポストモーテムのあり方の見直し
40. 40/23 プラットフォームの軸：取り組み① 監視バックエンドと管理を主導 • ヘルプデスクチャンネルの整備 • アカウント作成&棚卸し • IaCの整備&コードのレビュー対応 • セキュリティ対応 • 新機能のキャッチアップと検証 • 稟議/コスト管理 • 各種ドキュメントの整備 ◦ Runbook、ガイドライン、勉強用コンテンツなど • 勉強会の実施/アレンジ（Datadog社のサポート） • ロードマップの作成 ログインを Okta に統一 ドキュメントは Portal に集約 Slack でツール毎に helpdesk チャンネルを作成
41. 監視バックエンド活用のロードマップ 41/23 41
42. 42/23 プラットフォームの軸：取り組み② Developer Interface への展開 • コマンド経由で共通の監視モジュールを素早く展開可能に • 共通モジュールの計装によりガイドラインに則ったテレメトリの収集可能に 例えば、devkit dashboard コマンドを実行すると Datadog のダッシュボードが自動で作成される 詳細はスライド📖をチェック！ アーキテクチャの境界を超えて https://speakerdeck.com/monotaro/beyond_limits_architecture?slide=8
43. 43/23 見えてきた成果 分散トレーシングが導入されDatadogの利活用が進んだ 詳細はスライド📖をチェック！ Datadogを活用した マイクロサービスの可観測性向上 ~モノタロウの導入効果と実践ノウハウ~ https://speakerdeck.com/monotaro/microservice-observability-datadog-20250730?slide=33
44. 44/23 Enabling/Embeddedの軸：取り組み モノタロウで重要な役割を担う基幹システムへのアプローチ • システム的な制約が大きく複雑な業務と密に関わる基幹システムに対しては前に説明 した監視バックエンドの整備やツールの提供だけでは不十分 • SRE グループから基幹システム側のグループに対してメンバーを１名アサイン • X-as-a Service ではなく、密なコラボレーションによる協業
45. 45/23 見えてきた成果 ユースケースを絞り、オブザーバビリティによる課題解決を実践 詳細はスライド📖をチェック！ 映えないObservability https://speakerdeck.com/monotaro/observability-conference-2025-monotaro-legacy-observability?slide=40
46. インシデント対応の型化とSlackアプリの展開 • インシデント対応時のメインのコミュニケーションツールである Slack 上でインシデ ント対応をサポートするSlackアプリを展開 • アプリを利用することで推奨の型に則ってインシデント対応ができるように誘導し、 加えてインシデント対応時の負荷を軽減するため支援も実施 46/23 プロセスの軸：取り組み ❏ モーダルによるインシデントの宣言 ❏ 各Slackチャンネルに応じた Runbook 等のリンクの生 成 ❏ 影響度に応じたプロセスの案内 ❏ トラブルチケットのステータスの自動更新 ❏ ポストモーテム用 doc の作成 ❏ リマインダの通知, etc.
47. 47/23 見えてきた成果 成果はまだこれから。。 AI による自動化や開発生産性の指標の収集など、 各種要望はいただいている状況です。 この Slack アプリが部門横断的に利用されることで、 このアプリ越しに SRE やオブザーバビリティに関する様々な 施策が打てると考えています。 Slack アプリ自体はコンテナ基盤上で稼働しており、 大半の機能がAI 駆動開発で機能が実装されています。 利用者のニーズに合わせて、柔軟に拡張できるように準備を整えていく予定です。
48. 48/23 副次的な効果：開発生産性への取り組みへの発展 1. 2022 年当時の SRE グループは DevOps の領域も担っており、リリースプロセス の改善の評価指標として Four Keys を計測していた 2. SRE の観点においても、数値（エラーバジェット、復旧時間など）に基づいた運 用が根付かせることを目標に、Four Keys や運用にかけた稼働実績等を継続的に 収集していた 3. その後、社内外で開発生産性の機運が高まり、プラットフォームエンジニアリン グの導入の評価指標としても開発生産性に関わる指標が利用されるようになった
49. 49/23 開発生産性の議論の過程で生まれた成果物 開発生産性に関わる指標（プルリクエスト周り） DevEx Survey の調査結果の一部 VSM の一部
50. 各組織の SRE やオブザーバビリティの状況を把握する上では、SREの観点以外も計測した モダナイゼーションの度合いを表現する指標が社内では Fit した • SRE やオブザーバビリティの関わり方もモダナイゼーションの状況に大きく依存 • 指標の乱立も回避 50/23 SRE成熟度ではなくモダナイゼーションスコアでの観測 モダナイゼーションスコアの詳細はスライド 📖をチェック！ アーキテクチャの境界を超えて https://speakerdeck.com/monotaro/beyond_limits_architecture?slide=38 SRE成熟度 モダナイゼーションスコア
51. 51/23 プラットフォームの立場から見えてきた社内の変化 • Datadog の利活用がかなり進んだ ◦ ただし、コスト管理に課題感あり • SLI の設計と実装が徐々に変化してきた ◦ アクセスログベースからトレースベースへ、RUMの利用も視野に • 各所で SRE に興味ある人たちが徐々に出てきた ◦ SLOベースの運用を改善したいです！インシデント対応のプロセスを良くし たいです！の声が！！ • 運用の面でも AI 活用が進み始めてきた ◦ 各種 MCP の利用が拡大中、定常監視やエラーのサマリなどで活躍
52. 52/23 変わらないもの 監視の高度化やAI活用が進んでも、失敗から学ぶ文化の重要性は変わらない。 一方で、良いポストモーテムを実施するのにはまだまだコストがかかるので、そこを 仕組みでサポートできる余地はまだまだある。 👑 ポストモーテムの価値
53. 53/23 まとめ SREグループはECサイト側からプラットフォーム側へ立ち位置が変化しました。 SLOベースの運用からオブザーバビリティの重要性を認識し、3つの軸で取り組みました。 • プラットフォームの軸 • Enabling/Embeddedの軸 • プロセスの軸 各種の取り組みにより、システム全体のオブザーバビリティは徐々に向上しつつあり、社 内にも変化が見られました。 そのような変化の中でも、ポストモーテムの価値が変わらないことを再認識しました。 いずれの軸の取り組みもまだまだ道半ばなので、今後も継続してやっていきます！ この軸でもっとSREを取り組んでみたい！と思われた方はこちらへ https://hrmos.co/pages/monotaro/jobs?category=1902383850569732101
54. © 2024 MonotaRO Co., Ltd.