Upgrade to Pro — share decks privately, control downloads, hide ads and more …

グローバル基準のSREは、運用現場でどう機能したか:成熟度アセスメントの実践 / SRE NE...

グローバル基準のSREは、運用現場でどう機能したか:成熟度アセスメントの実践 / SRE NEXT 2026

2026年7月10日〜11日開催のSRE NEXT 2026で登壇した際の発表資料です。

グローバル標準に基づき任命されたSREが直面する構造的な課題と、成熟度アセスメントを通じてそれをどう可視化し、変化につなげたかをお話ししました。

※本資料は登壇時点(2026年7月)の内容です。その後の状況変化を反映していない場合があります。
※本資料の内容に関するお問い合わせは [email protected] までご連絡ください。

所属:キンドリルジャパン株式会社

Avatar for sorawatanabe

sorawatanabe

August 03, 2026

Other Decks in Technology

Transcript

  1. CH 0 · INTRO 自己紹介 職歴 2018–2022 2022–2023 2023–2025 2025–

    プロダクト開発・ サービス信頼性の 基盤刷新・保守運用 仕組み化 開発組織の イネーブリング 運用品質の可視化と 目標設計 ← 現在 Java · JavaScript · AWS Platform Engineering · Observability SRE Community主幹 Terraform · OTel · SLI/SLO · CI/CD 渡辺 宇 Sora Watanabe Lead SRE キンドリルジャパン(株) 開発側と運用側の両方を経験。一貫して「信頼性を組織に埋め込む」 本資料は2026年7月10日時点の内容です 2
  2. CH 0 · INTRO 社内SREコミュニティ活動 社内で運営している学び合いの事例を紹介します。 01 02 SRE勉強会 若手向け育成プログラム

    テーマを変えながら、原則と実務の知見を共有する場。 少人数・半年程度で、考えるところから小さな改 善まで順番に取り組む。 SREの原則を学ぶ 実際にあった障害を責めずに振り返る Kubernetesの実践スキルを身につける 社外事例・自由テーマで知見を共有 提案〜運用改善の知見を職種横断で整理 資格取得に向け、進捗を共有し学習を継続 SREの本質を自分の言葉で考える SRE本を読み、現場での使い方を議論 経験者から適用イメージを聞く 小さくできる改善を実践 学びを事例化し、キャリアの方向性を整理 本資料は2026年7月10日時点の内容です 3
  3. “Kyn ” は “kin ” に由来し ます。 お客様、そして従 業員同士の強い絆を表し “dryl

    ”は “tendril ” から 派生した造語で、新たな 成長とつながりを連想さ ています。 せます。 従業員は、私たちのビジ 力を合わせることで、 私たちは成長していきま ネスの中心です。 す。 4
  4. CH 0 · INTRO Kyndryl(キンドリル)とは 02 WHAT WE DO 01

    ORIGIN IBM ミッションクリティカルなエンタープライズ・テク ノロジー・サービスのリーディングプロバイダーを 担う。 数千にのぼる企業のお客様にアドバイザリー、インプ リメンテーション、マネージドサービスを提供してい ます。 03 SCALE グローバル 60カ国以上で展開 → 「顧客のシステムを預かる」関係を築く姿勢が特徴 本資料は2026年7月10日時点の内容です 5
  5. CH 0 · INTRO Kyndryl が支援する技術領域 アプリケーションサービス 重要なビジネスアプリケーションのモダナイズ、移行、保護、管理を網羅。 クラウド ITの複雑さを解消し、ハイブリッド、マルチクラウド環境の管理を効率化。

    メインフレーム 古くなったコンポーネントのモダナイズ、プライベートクラウドとハイブリッドクラ ウドのインフラに対応。 データ&AI 複雑なデータ管理やAI活用の課題解決を支援します。 デジタルワークプレース オンライン、オフラインを問わず作業できる、強固なセキュリティを備えたデジタル ワークプレースを構築します。 ネットワーク&エッジ 5G対応のエッジとSDNにより、ハイブリッドマルチクラウド環境を構築することで、 イノベーションの推進力が得られます。 セキュリティ&レジリエンシー 統合されたサイバーレジリエンスのアプローチにより、サイバー攻撃の予測、防御、 対応、復旧を実現します。 Kyndryl「ITインフラサービス」https://www.kyndryl.com/jp/ja/services(2026/7/10参照) 本資料は2026年7月10日時点の内容です 6
  6. CH 1 · 背景 Kyndryl には、SRE という Role が存在している ※本資料における「グローバル」

    グローバル(Kyndryl Inc.)は人材育成・技術戦略において共通の方針・知見・アセットを連携し、 キンドリルジャパンは、お客様への貢献を最大限に考えながら、グローバルの方針をもとに施策を検討する。 定義がある 枠がある 人もいる グローバルで「SRE」という Role が定義されている。 期待される活動範囲は広い。 • 計測 • 設計 • 実装 • 運用改善 • 組織推進 • etc デリバリー組織のリーダーポジ ションとして、構造上配置され る。 本人の準備状況に関わらず、ア サインされうる。 ― 土台はある。 本資料は2026年7月10日時点の内容です 8
  7. CH 1 · 背景 構造紹介:私たちの立場 ― 顧客のシステムを預かる ① エンタープライズ顧客のミッションクリティカルなシステムを 24/365

    で担う 停止が許されないシステムの安定稼働が最優先。改善より維持が優先されやすい構造。 ② 業務の中心は監視・インシデント対応・変更管理・キャパシティ計画 アーキテクチャを自らコードで変えるのではなく、「運用する」が本体。 ③ 複数の独立したデリバリー組織が、それぞれ別の顧客を持つ チーム間でノウハウが共有されにくく、横展開に構造的なハードルがある。 構造が制約(※後で紹介)をうむ。 本資料は2026年7月10日時点の内容です 10
  8. CH 1 · 背景 構造紹介:SRE の出発点が違う ― Dev起点 と Ops起点

    観点 プロダクト SRE(Google 型) 私たちの組織 出発点 開発(Dev)→ 運用への拡張 (「SWEが運用チームを設計」) 運用(Ops)からはじまる SRE の定番書(Google『Site Reliability Engineering』)が想定する「自社プロダクトを開 発・運用する」前提とは異なる。 本資料は2026年7月10日時点の内容です 11
  9. CH 1 · 背景 構造紹介:SRE の出発点が違う ― Dev起点 と Ops起点

    どちらが優れているという話ではない。出発点が違うだけ。 「できていない」のではなく、ピンと来づらい。 自分たちの実践が「SRE として見えていない」だけの可能性。 本資料は2026年7月10日時点の内容です 12
  10. CH 1 · 背景 現場の声 ― 別々の組織から、同じ声 “ SRE 任命されたけど、普段の運用業務と

    何が違うのか説明できない “ 隣の部署にも SRE がいるらしいが、 何をやっているか知らない “ 監視改善やってるけど、 これを SRE と呼んでいいのか分からない “ 改善すべき箇所は見えてるけど、 手を入れられる範囲が分からない → 能力の問題ならバラつくはず。全員同じ声 = 構造が原因。 本資料は2026年7月10日時点の内容です 13
  11. CH 1 · 背景 現場の声 ― 別々の組織から、同じ声 プロダクト開発の文脈で書かれた定義を、 運用起点の現場へそのまま当てはめると齟齬が出る。 →

    「SRE をやっているのか分からない」という声は、構造のズレから来ている。 本資料は2026年7月10日時点の内容です 14
  12. CH 2 · 構造による制約 — 01/04 自律性の制約 制約 ① 4つの制約が積み重なる

    変更したくても、裁量がない ① 自律性の制約 ② リスクテイクの制約 ③ 改善速度の制約 ④ 判断基盤の制約 前提:責任分界・厳格な変更管理プロセス 変更したくても裁量がない SCENE 原因は特定できている。しかし修正対 象が責任分界をまたぐため、承認なし には着手できない。 ※ 構造を伝えるためのイメージ例です 本資料は2026年7月10日時点の内容です 16
  13. CH 2 · 構造による制約 — 02/04 リスクテイクの制約 制約 ② 4つの制約が積み重なる

    「変えない」が合理的になる ① 自律性の制約 背景:どの現場にも「止めない」期待はある。 24/365 運用では特に強く、エラーバジェットをそのまま当 てはめにくい。 ② リスクテイクの制約 ③ 改善速度の制約 ④ 判断基盤の制約 「変えない」が合理的になる SCENE 監視エージェントを最新化したい。で も本番への変更は稟議が必要。 「今動いているものは変更を控える」 が組織として合理的な判断になる。 ※ 構造を伝えるためのイメージ例です 本資料は2026年7月10日時点の内容です 17
  14. CH 2 · 構造による制約 — 03/04 改善速度の制約 制約 ③ 4つの制約が積み重なる

    承認が連なる ① 自律性の制約 ② リスクテイクの制約 ③ 改善速度の制約 ④ 判断基盤の制約 背景:マルチベンダー環境では、変更1件に複数の関係者 の確認が必要。 自チーム 確認 → 自社承認 → 顧客確認 → 隣接ベンダー影響 確認 SCENE アラートルールの追加。技術的には1日。 でも全ステップを通すと数ヶ月。 完了する前に、次のインシデントが来る。 承認が直列に並ぶ ※ 構造を伝えるためのイメージ例です 本資料は2026年7月10日時点の内容です 18
  15. CH 2 · 構造による制約 — 04/04 判断基盤の制約 制約 ④ 4つの制約が積み重なる

    正しい判断をするための情報が手元にない ① 自律性の制約 ② リスクテイクの制約 ③ 改善速度の制約 ④ 判断基盤の制約 背景:設計意図・利用者情報・ビジネスコンテキストが責 任分界の向こう側にある。 SCENE インシデントの重大度を判定したい。 でも「このシステムを誰が何人どの業 務で使っているか」全体像が見えない。 「影響度:不明」のまま対応方針を決 める。 情報が手元にない ※ 構造を伝えるためのイメージ例です 本資料は2026年7月10日時点の内容です 19
  16. CH 2 · 構造による制約 4つ重なると、実践が見えなくなる ゴールへ 届きづらい 経路が狭まる ※本来はリスク低減の比喩。ここでは制約が重なる状態として転用。 1

    つずつなら対応できる。 → 4 つ重なると「動けていない」という感覚が出る。それが SRE 実践ができない感 の正体。 本資料は2026年7月10日時点の内容です 20
  17. CH 3 · アセスメントの実施 アセスメントの位置づけ 道具 姿勢 対象 グローバル基準に基づく 「できていない点の指摘(採点)」ではなく

    SRE 成熟度アセスメント 「できていることを見える化(実践の発掘)」 複数のデリバリー組織を横断 (一組織内で閉じない) → 「見えない」実践を、「見える」に変える。 本資料は2026年7月10日時点の内容です 24
  18. CH 3 · アセスメントの実施 アセスメントの構造 ― 成熟度評価 Capability Maturity Model(CMM)の「段階で成熟度を捉える」考え方を用いている。

    → 能力・プロセスを段階評価し、現在地と次の改善テーマを見つける 5 段階の成熟度: 属人性を減らし、再現性・標準化・計測・改善へ進む 1 初期 属人・場当たり 2 管理 手順がある 3 定義 標準化・共有 4 定量管理 数値で把握 5 最適化 改善が続く 成熟度 本資料は2026年7月10日時点の内容です 25
  19. CH 3 · REFERENCE (参考) Tenets of SRE ― Google

    SRE 本の 8 つの信条 Tenets とは? Google SRE 本の Tenets of SRE(SRE の信条)は、SRE チームがどう働くかを支えるパターン・行動・関心領域の中核を言 語化したもの。 1 5 Ensuring a Durable Focus on Engineering 運用業務(トイル)は 50% 以下に。残りは改善・自動化へ。 Change Management 障害の多くは変更起因。段階的展開と安全な切り戻し。 2 Pursuing Maximum Change Velocity Without Violating a Service’s SLO SLO を満たす範囲で変更速度を最大化する。 Demand Forecasting and Capacity Planning 需要を予測し、十分なキャパシティを確保する。 3 7 Monitoring 人がログを見張らない。アラート・チケット・ログを設計す る。 8 Emergency Response MTTR を縮める。手順書と訓練で復旧を速く。 4 6 Provisioning 変更管理×キャパシティ。必要な時に素早く、無駄なく。 Efficiency & Performance 資源を効率的に。負荷・利用率・性能を管理しコストを抑え る。 ※ 出典:sre.google『Site Reliability Engineering』Introduction / Tenets of SRE。 本資料は2026年7月10日時点の内容です 26
  20. CH 3 · アセスメントの実施 アセスメントの構造 ― 11項目 × 5段階 アセスメントは、グローバルで定義された

    Kyndryl における Tenets of SRE を評価軸にしている。 ★ 評価軸は、Kyndryl の文脈に合わせて具体化・重点化したもの。 皆さんの組織にも、文脈に合った評価軸があるはず。 11 項目あり、和訳して適用した。 結果はレーダーチャートで可視化 使い道 11 項目 × 5 段階の成熟度 • • • 現在地を把握する 強み・伸びしろを見つける 時系列で変化を追う ※ イメージ図。実スコア・テネット詳細は非公開 本資料は2026年7月10日時点の内容です 27
  21. CH 3 · アセスメント結果の読み解き — 01/03 レーダーチャートの典型パターン:偏り型 架空チャート例 Pattern 01|偏り型

    項目ごとの成熟度差が明確 項目A 5 4 項目F 3 読み取り 項目B 一部の項目が高く、別の項目が低い状態。高い項目は得意項目 として他デリバリー組織への横展開候補にし、低い項目は別途 その項目に合った打ち手を選ぶ。 2 1 0 次のアクション例 項目E 01 得意項目の型化:高い項目の実践・判断基準を言語化す 項目C る。 02 他組織への横展開:類似するデリバリー組織に展開し、 再現性を確認する。 03 低位項目の個別改善:低い項目は別途、項目に合った打 ち手を選ぶ。 項目D ※ 架空のスコア例。実スコア・評価項目詳細は非公開。 本資料は2026年7月10日時点の内容です 28
  22. CH 3 · アセスメント結果の読み解き — 02/03 レーダーチャートの典型パターン:全体低位型 架空チャート例 Pattern 02|全体低位型

    まずSRE標準・共通基準が必要 項目A 5 4 項目F 3 読み取り 項目B 全体的にスコアが低く、改善テーマが多く見える状態。全部を同 時に進めるより、最低限の基準と優先順位を決めることが先決。 2 1 0 次のアクション例 項目E 01 SRE標準の適用:既存標準があれば、最小セットから導 項目C 入する。 02 標準づくり:低位型が多ければ、共通基準とRunbookを 整備する。 → Platform Engineering 03 改善テーマ選定:リスク・頻度・影響で1〜2個に絞る。 項目D ※ 架空のスコア例。実スコア・評価項目詳細は非公開。 本資料は2026年7月10日時点の内容です 29
  23. CH 3 · アセスメント結果の読み解き — 03/03 レーダーチャートの典型パターン:均衡型 架空チャート例 Pattern 03|均衡型

    安定している一方、次の打ち手が見えにくい 項目A 5 4 項目F 3 読み取り 項目B 全体が中程度で大きな凹凸が少ない状態。現状維持で止まらな いよう、事業インパクトの大きい項目から次の一段を選ぶ。 2 1 0 次のアクション例 項目E 01 重点選定:障害影響に直結する項目を一つ選ぶ。 項目C 02 目標設定:次回測定までに「1段階上げる」テーマを明確 にする。 03 再測定:四半期ごとに変化を追い、効果が出た実践を標 準化する。 項目D ※ 架空のスコア例。実スコア・評価項目詳細は非公開。 本資料は2026年7月10日時点の内容です 30
  24. CH 3 · アセスメントの実施 実施の設計 ― 自己評価から循環へ ① 自チームを自己評価 各チームの

    SRE が実施 ② → ③ チーム内で共有・考察 ズレや気づきが出やすい → ④ 組織横断で共有 比較が刺激になり、見落と しに気づける → コミュニティで循環 学びが組織を越えて広がる 設計のコツ ① 設計のコツ ② 設計のコツ ③ 外から採点せず、自分で気づく設計 厳密さより「まずやってみる」 競争ではなく「時系列」を見る 気づきは外から与えられるより、自分で 発見するほうが定着する。 条件をそろえすぎると動けない(Ch2 の承認速度と同じ構造にはまりやすい)。 他チームとの優劣を競っても意味はない。 見るべきは、自分たちの成熟度が時間と ともにどう変わるか 。繰り返し評価す ることが重要。 本資料は2026年7月10日時点の内容です 31
  25. CH 3 · SUMMARY 制約の中でも、実践は存在した。 名前のなかった実践に 名前がついた 個人に閉じていた実践が 共有可能になった 組織横断で

    実践の地図ができた → 見えるようになった。見えることで何が変わったか。 本資料は2026年7月10日時点の内容です 32
  26. CH 4 · 可視化と変化 アセスメント後アンケートの実施結果 アンケート項目 4.0/5 満足度 73%が4以上 結果からわかること

    今回のアセスメントにどの 程度満足しましたか? ① アセスメントは肯定的に受け止められた 5段階評価で実施後の受け 止めを確認。 ② 実施方法は理解しやすい 回答方法が分からない状態ではなく、結果を次 の議論に使える前提が整っている。 100% 実施方法の理解 難しい・不明0% 進め方・回答方法を理解 できましたか? 7%「とても」/93% 「ある程度」。 本資料は2026年7月10日時点の内容です 34
  27. CH 4 · 変化 — 01/03 変化① 気づきと自信 SURVEY SIGNAL

    53% 設問:アセスメント結果は現状を反映していますか? 結果:はい53%/どちらとも言えない47%/いいえ0% BEFORE AFTER 「自分が SRE をやっているのか分からない」 「SRE の肩書きに実感がない」 変化 → 「自分は既に SRE として価値を出してい た」 半数の「はい」は、評価軸が現場の実践に届いたサイン。 「いいえ0%」は、納得形成を進める土台があることを示す。 本資料は2026年7月10日時点の内容です 35
  28. CH 4 · 変化 — 02/03 変化② 学び合いから改善へ SURVEY SIGNAL

    自由記述 設問:今後必要だと思う共有・支援は何ですか? 結果:「ベストプラクティスの共有」「スコープに合わせた情報共有」 BEFORE 他チームの実践が見えない。 改善は個人・チーム内に閉じている。 AFTER 変化 → 互いの実践を共有し、 自チーム向けに解釈できる状態に。 共有ニーズは、学び合いを改善活動へつなげる入口になる。 本資料は2026年7月10日時点の内容です 36
  29. CH 4 · 変化 — 03/03 変化③ 改善意向 ― 次の活動に進む準備

    SURVEY SIGNAL 80% 設問:アセスメントを踏まえて、今後、改善に取り組みたいですか? 結果:20%「すぐに」/60%「タイミングを見て」/20%「わからない」 BEFORE 改善したい意思はあるが、 タイミング・優先順位が揃っていない。 AFTER 変化 → 優先テーマと着手条件を決め、 次の活動へ進める状態に。 改善意向はある。次は「いつ・何から始めるか」を決める段階。 本資料は2026年7月10日時点の内容です 37
  30. CH 4 · SUMMARY アセスメントは 「発掘と循環」の道具として機能した。 1 発掘する 2 現場にある実践を見つける

    意味づける 価値として言語化する 見つけた実践が 次の活動を生む 4 広げる 3 次の改善へつなげる 学び合う 他チームの知見にする 本資料は2026年7月10日時点の内容です 38
  31. CH 5 · 今後の余地 アセスメント設計の議論 01 観察 53% 改善意向は高い一方、 現状反映は53%。

    47%は判断を保留。いいえは0。 02 解釈 47%は否定とは言い切れず、 「当てはまる部分/ 当てはまらない部分」があるこ との 混在評価かもしれない 03 原因仮説 グローバル定義の Kyndryl Tenets of SRE は、 日本の現場に即している部分と、 担当範囲・成熟段階に まだ合わない部分がある可能性 アセスメント改善の検討案 案01 評価項目を段階別に変える 案02 共通コア+追加モジュール 担当範囲に応じて3パターン化 インフラ中心/ハイブリッド/フルスタック(←現在) 中核Tenetsは共通で残し 段階別項目を追加オプションでつける方式 案03 項目は変えず、スコアリングを変える 現在対象/隣接領域/将来対象としてタグ付けし、 それぞれスコアの重みづけを変える 案04 2軸で優先度を読む SREとしての重要度 × 現場のコントロール可能 性で整理し、次の着手順を決める参考とする 本資料は2026年7月10日時点の内容です 40
  32. CH 6 · まとめ 明日からできること こういう人に こういう人に こういう人に 「うちは SRE

    できてない」 と感じている現場 SRE を組織に広げたい 推進者 改善が自チームの中で 閉じているリーダー 自分たちの「当たり前」 に名前をつけてみる 既存の信条を手がかりに、 現場の実践を棚卸しする 隣のチームの実践を知る 場を 1 つ作る 嬉しさ 嬉しさ 嬉しさ 否定から始めなくていい。 既にやっていることが SRE だと分かる。 現状を肯定した上で「次の一 歩」を示せる。 仕組みより先に「知る」から 入れる。 循環の入り口になる。 本資料は2026年7月10日時点の内容です 43