運用マチュリティモデルの検討 ― SRE・オブザーバビリティを現場改善につなげる

o11y×SRE運用マチュリティモデルへの取り組み o11yとSREの概念を、各社の運用現場で実際に役立つ「マチュリティモデル」に落とし込む。 広大な概念(o11y / SRE) マチュリティモデル 運用現場の実態 【目的】運用現場の成熟度を可視化し、改善に活かしたい。 【課題】o11yやSREは概念が広く、現場の活動に落とし込みにくい。 【気づき】モデル化の前に、まずは自分たちで深く理解し、噛み砕くプロセスが不可欠。

机上の整理から、実践を通じた再構成へ いきなりモデルを作るのではなく、「学び・試し・発信・AI活用」のサイクルで現場に当てはめながら再構成する。 【学び】o11y/SREの探求（監視との違い、現場への還元テーマの発見） 【試し】現場での実践（実際の業務環境でトイルを削る） 【発信】外部知見の吸収（現場の泥臭い課題をSNS等で収集） 【AI活用】作業と検証の圧倒的な加速 モデルの再構成

o11yの探求：監視基盤構築を通じた状況理解 ツール構築と発信を通じて、o11yが単なる「監視」ではなく「システム状態を理解する考え方」だと学んだ。 Prometheus環境構築・可視化 Qiita発信（10投稿） o11y（状況理解の土台）の獲得 PrometheusによるPull型監視基盤の構築を実体験 メトリクス取得・可視化の流れと学びをQiitaへ継続投稿（計10稿） 監視ツール導入ではなく「状況理解の土台」であることを実感

構成イメージ・実際の画面・Qiita発信 構成イメージ 実際の画面 @KanshiKun 【Observabilityへの道シリーズ⑥】サーバは正常。でも使えない？外形監視で見えた違い AWS grafana prometheus SRE observability 0 最終更新日 2026年04月12日 投稿日 2026年03月28日 428 views はじめに 前回の記事で、アラートルールを定義しました。どの状態を障害とするのか。どのタイミングで通知するのか。これで「監視としては完成した」と言えます。 ただ、運用しているとこう感じることがあります。 サーバは正常。でも使えない。 内部のメトリクスは問題ない。アラートも出ていない。 それでも「違い」「不安定」と感じることがある。 URL: https://qiita.com/KanshiKun

SREの探求：理想論から日々の運用改善へ SREの高度な理想論をそのまま持ち込まず、まずは足元の「日々のトイル（ムダ）削減」に注目した。 Google SRE本等から基本思想（可用性、エラーバジェット等）を学習 大規模Web企業向けの「理想論」を、自社の現場向けに翻訳 SREを「現場の負荷を下げ、創造的な時間を生み出すアプローチ」として再定義 SREの理想 日々のトイル削減

現場への還元：トイル（繰り返し作業）の削減 トイル削減はSRE実践の入口として最適であり、各社の現場で共有・適用しやすいテーマである。 Before 月間97時間の非効率作業 After 自動化と共有（目標15時間へ） 他現場への横展開 日々の繰り返し作業＝「トイル」の洗い出しと定義 削減事例の分科会共有（例：Power Queryによる棚卸し 8時間→30分） メンバー各社の現場でも使える観点を適用・実施

トイル計測シート具体例 No トイル名 起業者 規模(ユーザ数、ページ数等) 月件数 時間(M) 件数×時間(分) 件数×時間(時) 1 作業用パスワード申請 A 10ユーザ 20 30 600 10.00 2 作業用チェックシート印刷 A 5ページ 40 10 400 6.67 3 作業用チェックシートPDF保存 A 5ページ 40 10 400 6.67 4 構成管理シート棚卸 A 1シート 1 480 480 8.00 5 作業用チェックシート印刷 B 17シート、十数パターン 30 75 2250 37.50 6 画像連結 B 作業負担:小、心理負担:大 4 3 12 0.20 7 Excel・テーブル活用 B 行列選択、数式一種入力など 150 0.2 30 0.50 8 検証用VM払い出し C 全体で200VM～300VM程度 12 5 60 1.00 9 検証用VM棚卸 C 全体で200VM～300VM程度 0.3 30 9 0.15 10 検証用VM作業（強制再起動など） C 全体で200VM～300VM程度 1 5 5 0.08 11 技術レビュー受付・会議調整 C 約250名の組織の提案別レビューの事後 10 10 100 1.67 12 Excelパラメータシートの確認 D 30項目の目視チェック 10 60 600 10.00 13 定型作業の作業申請(Redmine) D 作業1件に付き1チケット 10 60 600 10.00 14 監視、セキュリティエージェント導入設定 D 手順書10ページ程度 5 180 900 15.00 15 (意味のない)作業ミス後の対策検討 D 事実確認、時系列調査 なぜなぜ分析3回 対策のレビュー承認 1 300 300 5.00 16 作業前・作業後の目視確認 B 100項目程度（厳密にチェック） 2 60 120 2.00 17 マネージドサービスの設定書のマージ B 3チームで編集 20 30 600 10.00 18 就業実績・移動実績の入力 E 1か月分。2重入力の部分あり 4 25 100 1.67 19 申請書の承認 E 1申請書 20 5 100 1.67

外部知見の吸収：リアルな現場の声を収集 書籍の知識だけでなく、外部実践者のリアルな課題感や生の声を取り入れ、現場目線を磨き上げた。 書籍・公式資料（基礎知識） SRE実践者の声・発信（リアルな課題感） 現場で使える知見の抽出 SNSを通じてSRE実践者の現場での悩みや実践例を継続的に確認 自身もSRE観点の活動を発信し、理解を深化（表示回数約5万回） 書籍だけでは得にくい「泥臭い課題感」の解像度を向上

SNSの発信 今日も監視くん 676 件のポスト IT運用あるある漫画 レガシー運用からSREへ 障害対応 / 可観測性 / 自動化 プロフィールを編集 今日も監視くん @kanshi_sre IT運用/SREのあるあると改善ヒントを漫画で発信。 監視 | 障害対応 | トイル削減 | 可観測性 | 自動化 中の人：システム運用リーダー / JIMUC登壇 今日も、良い運用を。 ※漫画は生成AIで制作 1. 定例作業、終わりました！ 2. どれくらいかかってる？ 毎日30分です 3. もう慣れました！ 4. 半年で60時間か… え？ URL: https://x.com/kanshi_sre

AI活用の検証：活動を加速させる強力な補助役 AI分科会との議論を通じ、AIは万能な魔法ではなく、o11y/SRE活動を加速させる「強力な補助役」だと確認した。 要約 運用者(Human Operator) 観点整理 試作支援 AI分科会と横断で意見交換を行い、活用の可能性を議論 Claude Code等を活用し、アプリ試作や観点整理を検証 AIは運用改善における「たたき台作成」や「要約」を支援する強力な道具

見えてきたこと：現場改善の両輪と「現在地」の把握 o11yとSREは「現場改善の両輪」であり、実践には自分たちの「現在地」を知る仕組みが必要である。 o11y（見える力：状況理解） SRE（扱う力：トイル削減） AI（活動を加速する補助役） o11y：監視基盤そのものではなく「状況を理解できる状態」を作ること SRE：信頼性向上だけでなく「トイル削減・自動化」で現場を楽にすること 現場への導入要件：抽象的なモデルではなく、客観的に「現在地」が分かる仕組みが不可欠

o11y×SRE運用マチュリティモデル（全体像） 学習と実践の知見を集約し、現場の現在地と目指す方向を示す「運用マチュリティモデル」を再構成した。 [Lv1] 可視化の開始（トイルの把握） [Lv2] トイル削減の開始（チーム改善） [Lv3] データ駆動運用（SRE実践開始） [Lv4] SRE文化の定着（組織的機能） Lv4 ビジネス連動 Lv3 分散トレーシング Lv2 集約と検索 Lv1 基本監視 Lv1 反応型 Lv2 定義型 Lv3 予防型 Lv4 最適化型 SRE Practices（信頼性エンジニアリング）

マチュリティモデル（詳細マトリクス） SRE Lv1 反応型 SRE Lv2 定義型 SRE Lv3 予防型 SRE Lv4 最適型 o11y Lv4 ビジネス連動 技術指標と利用者正常が分離 サーバー単位からサービス単位へ ユーザー体験の悪化を事前検知 ★ゴール: 観測データがビジネス判断と直結 o11y Lv3 分散トレーシング 複数データ取得も原因分析は勘 内部正常と外部正常を切り分け 障害の兆候や影響範囲を早期把握 運用設計に組み込まれ再発防止へ o11y Lv2 集約と検索 ログはあるが検索・突合に時間がかかる 初動対応の候補をルールで導ける 頻出トイルを特定し改善効果を追える 集約データが継続的運用判断に使われる o11y Lv1 基本監視 事後対応。個人の判断や経験に依存 誰が見ても最低限同じ対応ができる 容量逼迫などを事前に把握している 同じ問題を繰り返さない仕組みがある

現在地を知る：「自己診断チェックシート」の作成 感覚的な評価を排し、自現場の現在地を可視化して次の改善につなげる「自己診断チェックシート」を作成した。 点数をつけるため 現在地を知り、次の改善テーマを見つけるため 本プロジェクトの最重要成果物 o11y/SRE観点ごとに項目を整理し、成熟度レベルで評価 不足している観点を明確化し、次の具体的なアクションへ接続 各社・各現場で共通の観点を使って議論することが可能に

o11y×SRE 現在地を知る診断アプリ URL :https://kanshikun.github.io/o11y-sre-maturity/o11y_sre_maturity.html 運用の現在地を楽しく診断しよう o11y(観測する力)×SRE(運用する力)の2軸・各32問。1問ずつサクサク答えるだけで、現在レベルと「次の一歩」が見えてきます。 評価対象(システム/チーム) 評価者 評価日 達成判定しきい値 例)〇〇システム運用チーム 例)松石 2026/07/15 70%(6/8問)標準 判定ルール:各レベルに8問ずつあります。✓がしきい値以上(標準では8問中6問)になると、そのレベルを達成。Lv1から順に達成できたところまでが「現在レベル」です。上位レベルだけ達成しても、下のレベルが未達成なら下のレベルで判定します(JIMUCチェックシートと同じ判定方法)。 SRE 診断 全32問 運用する力(信頼性・トイル削減・標準化) 0/32 問回答済み 診断スタート → o11y 診断 全32問 観測する力(メトリクス・ 0/32 問回答済み 診断スタート → 手順書や記録などの「現物」があるかどうかで判断しよう SRE / Toil可視化・削減 (領域 1/8) Lv1 反応型 繰り返し作業を作業予定・実績として記録している 判断に迷ったら:証拠(現物)の例を見る ✓ できている [Y]キー — まだ [N]キー ← 前の質問 あとで答える →

現場で使い、育てていく実用ツール 単なる概念の整理ではなく、現場が状態を確認し改善へ踏み出すための「実用的なツールセット」として提供する。 マチュリティモデル 自己診断チェックシート 活用ガイド/AI支援 モデル：目指すべき方向を示す「地図」 チェックシート：現在地を正確に測る「コンパス」 活用ガイド・AI支援：評価結果から具体的な改善テーマ（トイル削減等）を導き出す仕組み

今後の進め方：各社の現場での実践と洗練 今後はこのモデルとシートを各現場で試し、フィードバックをもとに各社で使いやすい形へと磨き上げていく。 1. 各社現場で試行 2. フィードバックと改善 3. 汎用的なツールへ洗練 分科会メンバーの現場でチェックシートを実際に試行 分かりにくい項目や評価しにくい項目を洗い出し 評価結果に基づく実際のトイル削減効果を測定 各社で広く活用できる最終成果物として完成させる

まとめ：カオスから習熟への第一歩 机上の空論ではなく、現在地を可視化するツールへ。 現場の運用成熟度を共に高めていきましょう。 o11yとSREは、学習と実践を通じて現場で使える形に近づいた。 「自己診断チェックシート」で現在地を可視化し、確実な一歩を踏み出す。 運用現場のトイルを削り、創造的な活動へ。共に成熟度を高めていきましょう。