SRE NEXT 2026 2026.07.11 (Sat) 14:50–15:20 #srenext_c グローバル基準のSREは、運用現場でどう機能したか 成熟度アセスメントの実践 渡辺 宇 Sora Watanabe Lead SRE / キンドリルジャパン株式会社 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 

CH 0 · INTRO 社内SREコミュニティ活動 社内で運営している学び合いの事例を紹介します。 01 02 SRE勉強会 若手向け育成プログラム テーマを変えながら、原則と実務の知見を共有する場。 少人数・半年程度で、考えるところから小さな改 善まで順番に取り組む。 SREの原則を学ぶ 実際にあった障害を責めずに振り返る Kubernetesの実践スキルを身につける 社外事例・自由テーマで知見を共有 提案〜運用改善の知見を職種横断で整理 資格取得に向け、進捗を共有し学習を継続 SREの本質を自分の言葉で考える SRE本を読み、現場での使い方を議論 経験者から適用イメージを聞く 小さくできる改善を実践 学びを事例化し、キャリアの方向性を整理 本資料は2026年7月10日時点の内容です 3 

“Kyn ” は “kin ” に由来し ます。 お客様、そして従 業員同士の強い絆を表し “dryl ”は “tendril ” から 派生した造語で、新たな 成長とつながりを連想さ ています。 せます。 従業員は、私たちのビジ 力を合わせることで、 私たちは成長していきま ネスの中心です。 す。 4 

CH 0 · INTRO Kyndryl（キンドリル）とは 02 WHAT WE DO 01 ORIGIN IBM ミッションクリティカルなエンタープライズ・テク ノロジー・サービスのリーディングプロバイダーを 担う。 数千にのぼる企業のお客様にアドバイザリー、インプ リメンテーション、マネージドサービスを提供してい ます。 03 SCALE グローバル 60カ国以上で展開 → 「顧客のシステムを預かる」関係を築く姿勢が特徴 本資料は2026年7月10日時点の内容です 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 

CHAPTER 01 背景 役割も枠も人も、すでにある。 なのに「動けない」という声が聞こえてきた。 7 

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

役割も枠も人も、ある。 でも、動けない。 何故か？ 本資料は2026年7月10日時点の内容です 9 

CH 1 · 背景 構造紹介：私たちの立場 ― 顧客のシステムを預かる ① エンタープライズ顧客のミッションクリティカルなシステムを 24/365 で担う 停止が許されないシステムの安定稼働が最優先。改善より維持が優先されやすい構造。 ② 業務の中心は監視・インシデント対応・変更管理・キャパシティ計画 アーキテクチャを自らコードで変えるのではなく、「運用する」が本体。 ③ 複数の独立したデリバリー組織が、それぞれ別の顧客を持つ チーム間でノウハウが共有されにくく、横展開に構造的なハードルがある。 構造が制約（※後で紹介）をうむ。 本資料は2026年7月10日時点の内容です 10 

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

CH 1 · 背景 構造紹介：SRE の出発点が違う ― Dev起点 と Ops起点 どちらが優れているという話ではない。出発点が違うだけ。 「できていない」のではなく、ピンと来づらい。 自分たちの実践が「SRE として見えていない」だけの可能性。 本資料は2026年7月10日時点の内容です 12 

CH 1 · 背景 現場の声 ― 別々の組織から、同じ声 “ SRE 任命されたけど、普段の運用業務と 何が違うのか説明できない “ 隣の部署にも SRE がいるらしいが、 何をやっているか知らない “ 監視改善やってるけど、 これを SRE と呼んでいいのか分からない “ 改善すべき箇所は見えてるけど、 手を入れられる範囲が分からない → 能力の問題ならバラつくはず。全員同じ声 ＝ 構造が原因。 本資料は2026年7月10日時点の内容です 13 

CH 1 · 背景 現場の声 ― 別々の組織から、同じ声 プロダクト開発の文脈で書かれた定義を、 運用起点の現場へそのまま当てはめると齟齬が出る。 → 「SRE をやっているのか分からない」という声は、構造のズレから来ている。 本資料は2026年7月10日時点の内容です 14 

CHAPTER 02 構造による制約 「顧客のシステムを預かる」立場には、 4つの構造的制約が重なる。 15 

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

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

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

CH 2 · 構造による制約 — 04/04 判断基盤の制約 制約 ④ 4つの制約が積み重なる 正しい判断をするための情報が手元にない ① 自律性の制約 ② リスクテイクの制約 ③ 改善速度の制約 ④ 判断基盤の制約 背景：設計意図・利用者情報・ビジネスコンテキストが責 任分界の向こう側にある。 SCENE インシデントの重大度を判定したい。 でも「このシステムを誰が何人どの業 務で使っているか」全体像が見えない。 「影響度：不明」のまま対応方針を決 める。 情報が手元にない ※ 構造を伝えるためのイメージ例です 本資料は2026年7月10日時点の内容です 19 

CH 2 · 構造による制約 4つ重なると、実践が見えなくなる ゴールへ 届きづらい 経路が狭まる ※本来はリスク低減の比喩。ここでは制約が重なる状態として転用。 1 つずつなら対応できる。 → 4 つ重なると「動けていない」という感覚が出る。それが SRE 実践ができない感 の正体。 本資料は2026年7月10日時点の内容です 20 

CH 2 · SUMMARY 制約は、程度の差はあれ、どの組織にも存在する。 顧客のシステムを預かる構造では、連鎖が強く効く。 本資料は2026年7月10日時点の内容です 21 

CH 2 · SUMMARY 制約を取り除く、ではなく 制約下において行われている 実践を可視化する → SRE 成熟度アセスメントを実施する 本資料は2026年7月10日時点の内容です 22 

CHAPTER 03 アセスメントの実施 「見えない」としたものを、 どう「見える」に変えたか。 23 

CH 3 · アセスメントの実施 アセスメントの位置づけ 道具 姿勢 対象 グローバル基準に基づく 「できていない点の指摘(採点)」ではなく SRE 成熟度アセスメント 「できていることを見える化(実践の発掘)」 複数のデリバリー組織を横断 （一組織内で閉じない） → 「見えない」実践を、「見える」に変える。 本資料は2026年7月10日時点の内容です 24 

CH 3 · アセスメントの実施 アセスメントの構造 ― 成熟度評価 Capability Maturity Model（CMM）の「段階で成熟度を捉える」考え方を用いている。 → 能力・プロセスを段階評価し、現在地と次の改善テーマを見つける 5 段階の成熟度： 属人性を減らし、再現性・標準化・計測・改善へ進む 1 初期 属人・場当たり 2 管理 手順がある 3 定義 標準化・共有 4 定量管理 数値で把握 5 最適化 改善が続く 成熟度 本資料は2026年7月10日時点の内容です 25 

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 

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

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 

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 

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 

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

CH 3 · SUMMARY 制約の中でも、実践は存在した。 名前のなかった実践に 名前がついた 個人に閉じていた実践が 共有可能になった 組織横断で 実践の地図ができた → 見えるようになった。見えることで何が変わったか。 本資料は2026年7月10日時点の内容です 32 

CHAPTER 04 可視化された実践と 生じた変化 見つけた結果、何が変わったか。 33 

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

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

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

CH 4 · 変化 — 03/03 変化③ 改善意向 ― 次の活動に進む準備 SURVEY SIGNAL 80% 設問：アセスメントを踏まえて、今後、改善に取り組みたいですか？ 結果：20%「すぐに」／60%「タイミングを見て」／20%「わからない」 BEFORE 改善したい意思はあるが、 タイミング・優先順位が揃っていない。 AFTER 変化 → 優先テーマと着手条件を決め、 次の活動へ進める状態に。 改善意向はある。次は「いつ・何から始めるか」を決める段階。 本資料は2026年7月10日時点の内容です 37 

CH 4 · SUMMARY アセスメントは 「発掘と循環」の道具として機能した。 1 発掘する 2 現場にある実践を見つける 意味づける 価値として言語化する 見つけた実践が 次の活動を生む 4 広げる 3 次の改善へつなげる 学び合う 他チームの知見にする 本資料は2026年7月10日時点の内容です 38 

CHAPTER 05 今後の余地 事実と示唆を分けた上で、 ここから先の可能性を。 39 

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

CHAPTER 06 まとめ 持ち帰れるメッセージと、 明日からのアクション。 41 

MESSAGE SRE は「導入する」前に「見つける」ことができる。 見つけることからも、変化は始まる。 Tenets of SRE に照らして現場の実践を読み解くプロセス自体に価値がある。 本資料は2026年7月10日時点の内容です 42 

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

WE'RE HIRING 一緒に、やりませんか？ Kyndryl での SRE 活動に興味があれば、ぜひ声をかけてください！ 本資料は2026年7月10日時点の内容です 44 

本資料の内容に関するお問い合わせは、 [email protected] までご連絡ください。 Thank you 2026.07.11 (Sat)