もう⼀度考えるSRE #1 「SREチームの作り⽅と育て⽅」 組織にどうSREを根付かせるか？ 〜IVRyの場合〜 2025/07/31 @abnoumaru, IVRy inc. 

⾃⼰紹介 id: abnoumaru SRE Unit, Platform & Infrastructure Group Engineering Manager, SRE - 経歴 - ⼤学 - アルバイト/⼀社⽬ - ⼆社⽬ - IVRy .................. - 2024/10 ⼊社 → 2025/01 Team Lead → 2026/01 EM - 趣味 - setlog 2 

3 

プロダクト IVRとAIであらゆる電話対応を効率化 「アイブリー」 4 

5 

この発表で⽬指すこと - IVRyのSREの起源から今をお伝え（まだ1年7ヶ⽉） - SREを組織に根付かせるために良かったことを共有して 全員参加の座談会が盛り上がるきっかけになれたら嬉しい 6 

メンバー構成 IVRyのSRE、Unit 4名＋Principal Engineer 2名が兼務 Platform Systems SRE Unit 7 

SREというワードを使うまで サービス成⻑や開発速度を ⾒据えてインフラ移管計画 （EC2→ECS、Terraform） 正式リリース 2020/11 2021/05 コロナのワクチン接種予約 初めてのスパイク 2021/08 10⽉に現EM 11⽉に現Tech Lead が⼊社 2023/04 2024/11 インフラに軸を置く 正社員が⼊社 （インフラリリースで CEOの⽴ち会いが不要に） 8 

SREを意識的に使いはじめたタイミング - 2025年1⽉から明⽰的にSREという枠が出来た - メンバーが揃ってからSREというワードを使い始めた👍 肩書のフリップにならなかった* * David N. Blank-Edelman 著、山口 能迪 訳『SREをはじめよう ―個人と組織による信頼性獲得への第一歩』オライリー・ジャパン、 2024年。 9 

⾜元を整える 特に初期は⾜元の整備の効果が⼤きかった、仕組み化でよはくが⽣まれた👍 - Terraformの改善（Atlantis導⼊、State分割、静的解析、コンテキストの整備...） →⼈数も増えて安全かつスピードを出せる状態に - 依頼の仕組み化（Slack Workflow→Linear→オンコールベースで⾃動アサイン） →オンコールの⽇以外は依頼問い合わせを忘れて集中できる状態を作る - インシデントレスポンスのbotを作って型化（チャンネル作成、要約...） →組織やサービスが⼤きくなることによるバラつき解消、属⼈化も防ぐ 10 

プロダクトへの越境 プラクティスの実践や開発基盤の改善がうまくいかないことに気付く - - 電話/AI領域のドメインは難しさ、開発サイクルを体験することでニーズが⾒えてくる スピードを上げるために⾶び込む SREのチームが出来て半年が経った頃の話 開発への留学やEmbedded SREに振った👍 - 越境してよりプロダクトの近くそして内側からプロダクトや開発環境を知る 会社のValueにも通じる 11 

開発への留学 オンコールからも⼀度外れてプロダクトチームに所属して開発を⾏う👍 - 開発の中でいまあるリリースエンジニアリングやサービスの課題を体験する - 機能開発する中でリリースの改善をする動きが複数⽣まれた＋継続してEmbedded SRE Team SRE Product Team SRE PdM Designer Engineer 12 

13 

Embedded SRE プロダクトチームでSREのプラクティスを実践する👍 - 事業計画やプロダクトの特徴をより理解して信頼性と向かい合う - プロダクトの理解が進み課題をより深く理解＋Embedded先で⾃発的な取り組みが⽣まれる SRE Team SRE Product Team SRE PdM Designer Engineer 14 

15 

得られたこと 開発への留学 →機能開発とSREの橋渡しに - 開発基盤で便利と思ってもらえる改善を具体的にできた インフラ/アプリにまたがる⾮機能な仕組みづくりを推進 （今ではSREでやりたい改善をしながら開発） Embedded SRE →信頼性について頼られる存在に - Production Meeting 事業計画に基づくキャパシティプランニング SLI/SLOを決めるコミュニケーション 外部サービス連携のフォールバック‧メトリクス等の要否をレビュー（Claude Skills） Embeddedしていたチームの採⽤要件にSREケイパビリティを組み込む 16 

現在の働き⽅ 引き続きビジネスや現場の課題を肌で感じることを⼤事にしている。SREはEmbeddedしながら 機能開発やSREの改善を⾏う。まだ⼩さな組織なのでサイロを遅らせる狙いもある。隣で働く Platform Engineerのメンバーはマルチプロダクトや事業に必要な基盤を先回りで開発。 Management Dialogue Console SaaS Control Plane New Business Development Environment Infrastructure ※あくまでメインで⾒てるなというイメージ ※ は明確にSREの活動に関わるメンバー 17 

根付かせるために⼤事なこと すでに根付いている例 - インシデントから学ぶ⽂化はもともとニーズが強い 障害情報をAIが整理する仕組みは使われていて障害情報やポストモーテムが蓄積 気づき - 根付くにはニーズと便利さの両⽅が必要 ⼤事なこと - まず信頼性に関するニーズを探す 幸い、プロダクトやユーザへの気持ちが強いメンバーが多い（ミッションも関係ありそう） 場合によっては、会社の⽂化に合うやり⽅で必要性を⽰していく（IVRyは越境、など） 18 

いまは中央集権のSREをリスタート 事業的なニーズとSREとして進めたいことが重なる部分を選定 ⽬指したい状態 - 信頼性に関する取り組みが⽂化や仕組みで⾃然と⾏われる組織 Embeddedで⽣まれたいい⽂化を持続させる（Embeddedが外れても続くだろうか？） 取り組んでいること - Embeddedで得たことを横展開する仕組みや体制の整備‧提案 AI前提の開発を安全に加速させるための計測や基盤 サービス拡⼤に向けたインシデント時のコミュニケーション⽅法の⾒直し 19 

まとめ 以下のような順序で活動してきた - ⾜元を整えてよゆうを⽣み出した 越境して組織に必要なSREを実践 得られた知⾒を広めるために、いま中央集権に再び⼒を⼊れている 根付かせるために⼤事なこと - ニーズと便利さ、両⽅を作る 信頼性のニーズを探す 会社の⽂化に合うやり⽅で必要性を⽰す 地道に着実にSREを根付かせようとしている 20 

We are Hiring! 21