はじめに
監視ツールは導入している。手順書もある。日々の運用も回っている。
それでも、次のような疑問に答えるのは意外と難しいものです。
- 自分たちの運用は、今どの段階にいるのか
- 何が不足しているのか
- 次にどこから改善すればよいのか
私自身、o11y（Observability）やSREを学ぶ中で、考え方を理解することと、現場で「まず何を変えるか」を決めることの間には距離があると感じていました。
そこでJIMUC（IBM ミドルウェア・ユーザー研究会）の先進IT運用管理分科会では、o11yとSREの考え方を、運用現場で改善を話し合うための「運用マチュリティモデル」に落とし込む活動を進めています。
先日、2026年のJIMUC総会で、この取り組みについて発表しました。発表資料はこちらです。
この記事では、資料だけでは伝えきれなかった「なぜこのモデルを作ったのか」と「現場でどう使うのか」を補足します。
※本モデルは、JIMUC 先進IT運用管理分科会で検討中の試作です。o11yやSREの公式な成熟度定義ではなく、現場で改善を話し合うための整理として作成しています。
※本記事は、発表内容を個人の視点で再構成したものです。
マチュリティモデルは「採点表」ではなく「地図」
マチュリティモデルというと、組織やチームを採点し、レベルの高さを競うものに見えるかもしれません。
今回目指したのは、次の3点です。
- 自分たちの運用の現在地を可視化する
- 不足している観点や認識の違いに気づく
- 次に取り組む改善をチームで決める
すべてを最高レベルにする必要はありません。システムの重要度、体制、予算、利用者への影響によって、目指す地点は変わります。
今回のモデルは評価表ではなく、現在地と目的地を話し合うための地図として使うものです。
学習だけで終わらせず、実践からモデルを組み直す
o11yやSREは対象範囲が広く、書籍や資料だけを基にモデルを作ると、現場から離れた理想論になりがちです。
そこで、今回の活動では次のサイクルを回しました。
- 学ぶ
- 実際に試す
- QiitaやXで発信する
- 外部や現場の声を取り込む
- モデルを組み直す
AIも活用しましたが、答えを決めてもらうのではなく、調査、観点整理、資料化、試作を速める補助役として使っています。
モデルを先に作り、現場へ当てはめたのではありません。学習と実践を往復しながら、現場で使える言葉へ置き換えていった点が、今回の取り組みの特徴です。
o11yは「監視できる」から「状態を理解できる」へ
o11yについては、Prometheusを使った監視基盤を実際に構築し、メトリクスの取得や可視化を試しました。
最初の実践では、自宅サーバのGPU使用率をPrometheusで可視化しました。構築して終わりにせず、その過程をQiitaへ投稿し、学んだ内容を言語化しています。
【Observabilityへの道①】PrometheusでGPU使用率の推移を可視化
実践を通じて見えてきたのは、o11yは単に監視ツールやグラフを増やすことではない、という点です。
重要なのは、収集したデータから次のことを理解し、判断できる状態にすることです。
- システムで何が起きているのか
- 利用者にどのような影響が出ているのか
- 次に何を確認し、どう判断すべきか
本モデルでは、この変化を次の4段階で整理しました。
| レベル | o11yの状態 |
|---|---|
| Lv1 基本監視 | 事象を検知し、個人の経験を頼りに対応する |
| Lv2 集約と検索 | ログなどを集約し、必要な情報を検索できる |
| Lv3 相関分析 | ログ・メトリクス・トレースを関連付け、原因や影響範囲を追える |
| Lv4 ビジネス連動 | 観測データを利用者・ビジネス上の判断につなげる |
SREは、日々のトイルを見つけるところから
SREについては、理想的なプラクティスを一度に持ち込むのではなく、現場に近い課題である「トイル」に着目しました。
なお、今回の試作はSRE全体を網羅するものではありません。SLO、インシデント管理、テストなど幅広い要素のうち、運用現場で着手しやすいトイル削減と継続的な改善を中心に整理しています。
ここでいうトイルとは、単なる定常作業ではありません。手作業、反復、自動化可能、戦術的、恒久的な価値を生みにくい、サービスの成長に比例して増える、といった性質を持つ作業です。
分科会で共有したある現場の事例では、定常作業を棚卸しした結果、トイル候補となる非効率作業が月約97時間ありました。そこで、作業時間、頻度、自動化のしやすさなどを整理し、効果が見込めるものから改善しました。
資料では、その一例として、約1,500台・30項目の構成管理棚卸しをPower Queryで効率化し、1回あたり8時間以上かかっていた作業を30分へ短縮した事例を紹介しています。
構成管理の棚卸しを「見る作業」から「差分を見るだけ」に変えた話（Power Query / 1,500台 / 8時間→30分）
大切なのは、自動化すること自体ではありません。
トイルを減らし、改善や検討に使える時間を生み出すことです。
本モデルでは、SRE側も次の4段階で整理しました。
| レベル | SREの状態 |
|---|---|
| Lv1 反応型 | 問題が起きてから対応する |
| Lv2 定義型 | 誰でも最低限同じ対応ができる |
| Lv3 予防型 | 兆候や影響を捉え、予防的に改善する |
| Lv4 最適化型 | 観測データと改善を運用設計へ組み込み、同じ問題を繰り返さない |
2つの軸を組み合わせて「現在地」を見る
ここまで、o11yの実践とトイル削減は、それぞれ個別のテーマとして取り組んできました。今回のモデルでは、その2つを運用全体の現在地を捉える軸として組み合わせました。
作成したマチュリティモデルは、o11yとSREを別々に採点して終わるものではありません。
- o11y：システムの状態を理解する力
- SRE：信頼性を守りながら、トイル削減と改善を継続する力
この2軸を4×4のマトリクスで組み合わせ、現場の状態を具体的な言葉で表しました。
例えば、次のような状態です。
- ログはあるが、検索や突合に時間がかかる
- 障害対応はできるが、個人の経験に依存している
- 可視化は進んでいるが、改善活動につながっていない
抽象的なレベル名だけでなく、現場で実際に起きている状況として表すことで、「次に何を変えるか」を考えやすくしています。
詳細な4×4マトリクスは、公開資料で紹介しています。
自己診断は、点数を付けるためではない
モデルだけでは、「自分たちはどこに当てはまるのか」が曖昧になります。
そこで、現在地を確認するための自己診断チェックシートを作成し、ブラウザで試せる診断アプリも用意しました。
診断結果はゴールではありません。点数の高低よりも、次の問いをチームで話すことに価値があります。
- なぜ、その回答を選んだのか
- 認識が分かれた項目はどこか
- 現在の困りごとと、どの項目がつながるか
- 次に何を一つ変えるか
同じ現場でも、管理者は「できている」と考え、実際に作業するメンバーは「できていない」と感じているかもしれません。その差自体が、重要な改善の手掛かりになります。
現場で試すなら、この5ステップ
最初から全項目を改善しようとすると、活動自体が新しい負担になります。まずは、次の順番が現実的です。
- メンバーがそれぞれチェックシートへ回答する
- 回答が分かれた項目を確認する
- 実際の困りごとと結びつける
- 次の改善テーマを一つ決める
- 改善前後の時間や負担を測る
例えば、「ログは集めているが、障害時に必要な情報へたどり着けない」という課題があったとします。
この場合、いきなり監視基盤全体を刷新する必要はありません。まずは、頻出障害に必要なログ、検索条件、確認手順を整理する。それも、現在地から始める立派な改善です。
重要なのは、診断結果から大きな改革案を作ることではなく、次に試す小さな改善を一つ決めることです。
今後
今回のモデルは完成版ではありません。
今後は各社・各現場で自己診断チェックシートを試し、次のサイクルで育てていく予定です。
- 各現場で試す
- 認識のずれや使いにくい項目を確認する
- フィードバックをモデルへ反映する
- 診断結果を具体的な改善アクションへつなげる
- 改善の効果を確認する
診断して終わるのではなく、実際にトイルが減ったか、運用判断がしやすくなったかまで確認できる形を目指します。
まとめ
o11yやSREを現場へ導入するには、理想像を示すだけでは足りません。
学び、試し、現場の声を取り込み、自分たちの現在地が分かる形へ組み直す。そのうえで、次の改善を一つ決める。
現在地を可視化し、次の一歩につなげる。
今回作成したマチュリティモデルは、そのための地図です。
公開資料と診断アプリが、皆さんの現場で改善を話し合うきっかけになればうれしいです。実際に試した感想や、「この観点も必要では」といったご意見があれば、ぜひお聞かせください。