泥臭く始める一人目SREの生存戦略、戦略的属人化による運用肥大化からの脱却

SRE NEXT 2026登壇資料

Transcript

1. 泥臭く始める一人目SREの生存戦略 戦略的属人化による運用肥大化からの脱却 株式会社Hubble 三橋 2026/7/11 SRE NEXT 2026 Gold Sponsor Session
2. 「SRE学んだ人あるある」
3. スタートアップに行けば早い段階から SREを実践していけるのでは！？
4. 三橋 奎太 (@k_honeybees) 2025年9月入社 SREとしては3社目 最近はAIを活用した運用 効率化に注力している
6. SREチームの成り立ちの一例
7. 価値提供が最優先される最初期 ストリームアラインドチーム
8. インフラ詳しいメンバーが横断的に見始める ストリームアラインドチーム ストリームアラインドチーム インフラ詳しいマン
9. SRE(??) そして、SREチームという名の「何でも屋」が生まれる ストリームアラインドチーム ストリームアラインドチーム 依頼 依頼
10. これでいい？？
11. この時期の組織を取り巻く状況 アクセス増 複雑性増 障害が発生しやすい状況 & チャーンインパクト大 利用者数増
12. 真に必要なのはSRE!!
13. 組織がどれだけ大きくなっても揺るがない信頼 性を築いていく必要がある
14. 実際はどうだったか
15. 入社当時のチームの状況 EM CTO 業務委託メンバー まさに「何でも屋」という状況 幸いにも依頼タスクに忙殺されるという 状況ではなかった ただし放置すれば、何でも屋のままSRE 本来の活動にたどり着けない... SREチーム
16. どうやって改善していったか
17. 1. 組織の合意を得る
18. 方向性と責務の言語化 中長期でやることを宣言し目線合わせ - Mission/Visionの策定 - 責務領域の言語化 - Reliability, O11y, Cost Optimization, Security & Governance, Agility やらないことの線引ではなく、何に対して責任を持って旗を振って いくつもりかを宣言した
19. スケールを軸にしたSRE成熟度の定義 実行主体がどこまで広がっているかで定義 フェーズ定義は「 SREの探求 22章 成功の文化としての SRE」より Lv.1 個人レベルで実践 火消しフェーズ Lv.2 SREチームで実践 門番フェーズ Lv.3 組織で実践 パートナー/触媒フェーズ
20. SRE成熟度の定義 責務 テーマ Lv.1 Lv.2 Lv.3 Reliability SLI/SLO インシデント対応 O11y アラート 計装 CostOptimization FinOps テーマごとに評価を行い現在地を確認 ※ イメージ
21. ロードマップへの落とし込み 成熟度評価結果および事業状況から優先テーマを決定
22. 運用方針の策定 業務をチームとしてどのようにこなしていくかを明文化 例：タスクを3種に分類し稼働割合目標を設定することで柔軟性をもたせた  Roadmap ロードマップに関するタスク 半期ごとにチームでディスカッ ションして起票する 一人最低一テーマを持つ  Ops 定常運用/改善など 自由に起票して良いタスク 何をやるかはメンバー裁量に委 ねる  Request 他チームからの依頼対応 ローテーションによるアサインを 行う
23. 自律的に動くための枠組みを手に入れた
24. 2. 信頼を獲得する
25. ⌛ ロードマップの課題 ロードマップタスクも重要であるが、成果が 出るまでに時間がかかる... 🤝 SRE活動の前提条件 真のSRE活動を行っていくには、他部署か らの信頼を得ておく必要がある 💡 「球拾い」で最短で信頼を得る 伝家の宝刀「球拾い」
26. STEP 01 🔔 通知設定 得意領域のキーワード をSlackで通知設定 （datadog, aws, o11y, sreなど） STEP 02 ⚡ 高速打ち返し 誰かが困っているスレッ ドをいち早く検知して高 速で打ち返す OUTCOME 💡 信頼獲得 「この領域のことはこの 人に聞けばいい」という 印象を最短で作れた 球は高速に打ち返す
27. 💊 依存性 - そもそも誰もやりたがらないのでやるだけで感謝され、信頼も得や すい上に自己肯定感も高まる (もっと拾いたくなる) 💀 副作用 - 何でも屋化と属人化を加速させ、最終的には燃え尽き症候群に陥 る可能性も 「球拾い」はドラッグ
28. 3. 運用の仕組み化
29. 泥臭く現場に入り課題を掴んだ インシデント対応 ほぼ100％参加した 【理由】 既存フローが回っているのか わからず理解も浅かった 【結果】 会話の散在や対応手順の浸 透不足などの把握 脆弱性対応 率先して実施した 【理由】 定めた運用ルールが本当に回 るのか不明だった 【結果】 偽陽性の多さによる現場負担 の大きさを露呈 セキュリティチェックシー ト対応 自ら手を上げ参画した 【理由】 既存の回答フローのどこに負 担があるのか掴めていなかっ た 【結果】 Bizとの連携のリアルや既存フ ローのボトルネックを発見
30. 完璧を目指さずに仕組み化していく
31. 01. 導入と最適化 インシデント管理ツー ル(Waroom)の導入と フローの最適化を行っ た 02. 改善ループ フローのリポジトリ管理 とAIのつなぎ込みによ るフロー自体の改善 ループを作成した 03. AI調査対応 さらなる効率化のた め、調査対応をAIにや らせるようにした 04. 自己改善分 析 原因特定に時間がか かった場合はAIに分析 させて自己改善させる ようにした インシデント対応の仕組み化
32. 01. チケット自動起票 各種ツールの検出結果をチ ケット管理ツールに自動起票 できるようにした 02. AI自動トリアージ AIに重複チェック、偽陽性 チェックをさせ、適切なメンバー にアサインさせるようにした 03. フィードバック 偽陽性と判断された場合はコ メントを残してもらい、それを AI に学習させて偽陽性判定の精 度を上げていく 脆弱性対応の仕組み化
33. 01. ファクト集の管理 回答材料となるファクト集を作 りリポジトリ管理できるようにし た セキュリティチェックシート対応の仕組み化 02. 一次回答の自動化 AIにファクト集を参照させ、開 発サイドで一次回答を生成で きるようにした 03. 継続的な改善 レビュー結果をAIに受け取ら せ、ファクトやプロンプトの改善 に繋げられるようにした
34. 戦略的属人化 = 「手放すために、あえて一度集める」 振り返ってみると戦略的に動いていた 01. あえて集める（属人化） 宣言した責務領域に、まず自分が泥臭く 入って属人的に抱えた。 ※ 良い仕組みは現場を知らないと作れない。だか ら「手放すための現場理解」として、あえて一度引 き受けた 02. 仕組みで手放す（脱属人化） 抱えて分かった勘所を、可能なものから仕 組みに変えて手放す。 ※ 順番が逆（現場を知らずに仕組み化）だと、的を 外す
35. 結果どうなった？
36. 運用肥大化に飲まれる前に手を打てた
37. CORE MISSION 次の課題：チームレジリエンスを強化する 見えてきた新たな課題 これから取り組むこと 01 コミュニケーションの場の 再設計 → 知識・作業の冗長化 02 ビジネスメトリクスに紐づく チーム KPIの策定 → 方向・判断の冗長化 03 AIを活用したチーム健全 性の分析 → 異常の早期検知
38. 完璧な計画はなかった。ただ、無計画でもなかった。 属人化の怖さを知りながら、できるものから仕組みに変えた。 それが、生存戦略になった。