SREチームの越境と対話〜どのようにしてイオンスマートテクノロジーは横軸運用チームの廃止に至ったか〜/the-Cross-border-and-dialogue-of-SRE

by AEON

Slide 1

Slide 1 text

SREチームの越境と対話〜どのようにしてイオンスマートテクノロジーは横軸運⽤チームの廃⽌に⾄ったか〜イオンスマートテクノロジー株式会社 DevSecOps Div/Director 齋藤光 2025年7⽉11⽇ SRE NEXT 2025

Slide 2

Slide 2 text

自己紹介

Slide 3

Slide 3 text

⾃⼰紹介齋藤光( @hikkie13 ) イオンスマートテクノロジー株式会社(2022/5⼊社） DevSecOps Div ディレクター⼊社以来、SREを組織にインストールすることに従事趣味：ヨガ(RYT200) SRE NEXT 2023に登壇しました

Slide 4

Slide 4 text

会社紹介

Slide 5

Slide 5 text

イオングループ紹介 - 関連数字 h"ps://www.aeon.info/company/ - "INFOGRAPHICS 数字で見るイオングループ"

Slide 6

Slide 6 text

会社紹介

Slide 7

Slide 7 text

iAEONアプリについて膨⼤なIDと購買データを集約したアプリ「iAEON」 iAEONはイオングループが提供する決済機能やポイントプログラムを1つにまとめたアプリです。イオングループ内の多数の事業会社がもつ顧客IDを⼀つのアプリに統合しています。

Slide 8

Slide 8 text

Slide 9

Slide 9 text

AEON PayとWAONを統合しました https://www.aeonpay-world.jp/world-cp/

Slide 10

Slide 10 text

Agenda • なぜ越境？ • 越境と対話の際に参考にしていること • ケース • 更なる越境

Slide 11

Slide 11 text

なぜ越境？〜当時の状況を添えて〜

Slide 12

Slide 12 text

設⽴当初の組織図（雑）ビジネス部⾨開発チーム群（ベンダ含む）インフラ運⽤チーム

Slide 13

Slide 13 text

設⽴当初の組織図（雑）ビジネス部⾨開発チーム群（ベンダ含む）インフラ運⽤チーム • そびえ⽴つ壁、壁、壁 • 依頼、許可、承認による仕事

Slide 14

Slide 14 text

イオンスマートテクノロジーでの組織取り組み 2022年に以下の動きが開始 • SREチームの組成（インフラチームからの変更） • 内製開発組織の⽴ち上げ。アジャイル開発への挑戦！ https://engineer-recruiting.aeon.info/aeon-tech-hub/interview_saitohikaru https://engineer-recruiting.aeon.info/aeon-tech-hub/interview_ounagasatoshi

Slide 15

Slide 15 text

アジャイル開発とSRE、⽬指すものは全てビジネス‧事業的成果アジャイルの⽂脈で⾔えば‧‧‧ • Don’t just do agile. Be agile. • 開発をアジャイルにするのではなく、経営をアジャイルにする SREの⽂脈で⾔えば‧‧‧ • Class SRE implements DevOps • 運⽤と開発の壁の破壊 • ⽣産性を⾼めるための⾃動化 • プロダクトの信頼性

Slide 16

Slide 16 text

皆、⽬的は1つなのだ Biz Dev Ops ビジネス的価値顧客への価値 • 関⼼ごとの共通化＝ビジネス的価値、顧客への価値 • そのためには相互理解、素早い仮説検証ができる環境づくりが必要 → 部⾨を越えた越境のアプローチが有効なケースが多い（個⼈的⾒解）

Slide 17

Slide 17 text

越境と対話の際に参考にしていること

Slide 18

Slide 18 text

無⼈島に3冊持って⾏くとしたら… https://www.oreilly.co.jp/books/9784814400645/ https://amzn.asia/d/3MbvUeJ https://amzn.asia/d/2T50Kdt

Slide 19

Slide 19 text

組織を変える5つの対話 5つの対話のステップ信頼を築く対話不安を乗り越える対話 Whyを作り上げる対話コミットメントを⾏う対話説明責任を果たす対話いきなりWhyから始めない https://www.oreilly.co.jp/books/9784814400645/

Slide 20

Slide 20 text

「変化を嫌う⼈」を動かす惰性慣れているものに留まろうとする欲求労⼒変化に必要な労⼒‧コスト（価値より労⼒を懸念）感情変化に対する否定的な感情（アイディアそのものへの反応）⼼理的反発変化させられることへの反発（アイディア推進者/⽅法への反発）例 ‧今のオンコール体制で⼗分 ‧今のリリース⼿順で⼗分 ‧やったことないから⼤変だ ‧仕事が増えるから⼤変だ ‧俺の仕事を奪うのか ‧⾃分の無能さが露呈するのでは ‧やり⽅を押し付けてくるな https://amzn.asia/d/3MbvUeJ

Slide 21

Slide 21 text

「変化を嫌う⼈」を動かす惰性慣れているものに留まろうとする欲求労⼒変化に必要な労⼒‧コスト（価値より労⼒を懸念）感情変化に対する否定的な感情（アイディアそのものへの反応）⼼理的反発変化させられることへの反発（アイディア推進者/⽅法への反発）主な対処 ‧段階的な変化 ‧単純接触効果を狙う - 何度も伝える。時には話す⼈を変える ‧やらない労⼒の⽅が⾼いことを⽰す ‧不要なプロセスがあるなら⾒直す ‧労⼒の⾒せ⽅を変える ‧「なぜ？」に⽬を向けて観察し理解を深める ‧早い段階からプロセスに巻き込む ‧Yesを引き出す質問づくり https://amzn.asia/d/3MbvUeJ

Slide 22

Slide 22 text

他者と働く準備相⼿と⾃分のナラティヴ (=解釈の枠組み,正しさ)の溝に気づく観察相⼿の⾔動や状況を観察し、溝の箇所や相⼿のナラティヴを探る解釈溝を⾶び越えて、橋が架けられそうな場所や架け⽅を探る介⼊⾏動することで、橋(=関係性)を築く Biz Dev Ops ビジネス的価値顧客への価値 https://amzn.asia/d/2T50Kdt

Slide 23

Slide 23 text

更に対話を深めるために… • 対話と会話の違いを理解する o 会話: 広く⼈と⼈が⾔葉で交流すること o 対話: それを通じて何かが新たに浮かび上がってくるようなやり取り o 相⼿を他者と認識し、他者の頭を使う o 「早く⾏くなら⼀⼈で⾏け、遠くに⾏くならみんなで⾏け」（アフリカの諺） • 基礎⼒としての、メタ認知/評価判断の保留/傾聴/学習と変容/リフレクション • 対話を深める要素としての、問いのデザイン/課題設定と優先度/意志/決断

Slide 24

Slide 24 text

ケース： (1) Embeddedアプローチ (2) だっしゅぼーどを眺める会 (3) SLI/SLO策定のためのワークショップ (4) 障害対応の⺠主化、ポストモーテム⽂化の醸成 (5) 横軸運⽤チームの廃⽌ (6) Platform Engineering

Slide 25

Slide 25 text

Slide 26

Slide 26 text

SREチームにまつわるトポロジー（⽴ち上げ当時） Stream-Aligned Team Platform Team Enabling Team SREチーム 2つの側⾯を持ち合わせる Enabling • Stream-Aligned(SA)チームへSREのインストール • 整備したツール/基盤の伝承と伴⾛ • 定点観測会など定期的にSAチームとcommunication Platform • インフラ基盤⾃体の改善(Azure) • セルフサービスの提供（徐々に拡⼤中） • ツール/基盤の整備 Team Topologies

Slide 27

Slide 27 text

こうなる情報共有&連携 SREチームプロダクトA プロダクトB プロダクトD プロダクトC Platform ツールなど課題や要望を⼀般化 Enabling Enabling Enabling Enabling

Slide 28

Slide 28 text

SREチームにまつわるトポロジー • チーム内のcontext switchの多さ • 改善が進まない / 改善のスピードが期待値より低い領域が発⽣ o SAチームのリソース不⾜ o SAチームのcapability不⾜ o 優先度の考え⽅のすれ違い o 相談/依頼のタイミングではHow/WhatになっておりWhyを掘り起こすところからスタート → ⼀部プロダクトへのEmbeddedアプローチの導⼊へ以下のつらみや悩みが発⽣

Slide 29

Slide 29 text

Embeddedへの挑戦で意識してやっていること • SAチームが出席するようなプロダクトに関する定例、会議は出席 o SAチームと情報をsync o 案件状況、チームの状態、課題の優先度を把握。⽬線を揃える。 • ⼀緒に課題を解くことで信頼の構築 o Team Topologiesでのコラボレーションが濃い状態に近いと捉えている • ゴールの状態を忘れない。 o あくまで最終⽬標はSAチーム内でSREの実践が完結すること o SAチーム内でSRE担当に任せっぱなしの状況は作らない。

Slide 30

Slide 30 text

Slide 31

Slide 31 text

弊社とオブザーバビリティ • イオンスマートテクノロジーではNew Relicを活⽤ • オブザーバビリティツールは運⽤チームのためのものではない。開発チームが使いこなすことが⼤事。 • 開発チームの使いこなし促進‧意識づけのために、定点観測会を実施。堅苦しくないように ”だっしゅぼーどを眺める会” と銘打って開催。 • オブザーバビリティのモブ作業として確⽴

Slide 32

Slide 32 text

定点観測会の副次的効果 • 課題作成‧課題の棚卸し • 直近タスクやトピックなどの共有 • アイスブレイク/雑談 • ザイオンス効果（単純接触効果）で協業がし易くなる！

Slide 33

Slide 33 text

Slide 34

Slide 34 text

SLI/SLO策定ワークショップ • 現在、SLI/SLOの策定と運⽤を推進している。 • エンジニア部⾨のみで決めるのではなく、ビジネス部⾨との合意が必須 • 合意に向けた対話には正しい知識が必要エンジニア部⾨‧ビジネス部⾨両者を集めて SLI/SLO策定ワークショップを開催 https://www.oreilly.co.jp/books/9784814400348/

Slide 35

Slide 35 text

ワークショップ後のフィードバックからの抜粋 • ビジネス部⾨の⽅とワークを⼀緒に⾏なって、SLIの考え⽅がそれぞれだと感じたので、 SLIの共通認識をこれから持っていくことが重要だと感じた。 • ワークショップで話したような議論を通常時でもビジネス側と⾏いたい • SLIとSLOの定義をビジネスと合意して継続的にみていきたい • ビジネスサイドからもSLI SLOを指標として提案したい

Slide 36

Slide 36 text

現在 • ⼀部プロダクトでSLOの仮運⽤を開始 • 並⾏してワークショップを随時実施中。そこからのSLO策定会議が開発チーム主導で開催される流れができている

Slide 37

Slide 37 text

Slide 38

Slide 38 text

障害対応とポストモーテムの課題 • 鳴り響く、でも対応は不要なアラート • ⼀次受けとなる専任の運⽤チームへの⾼負荷 o 中⾝のわからないアラートを受け取り、都度開発チームへ問い合わせを⾏っていた o ⾃分が受けないので、開発チームもアラートを整理するモチベーションが上がらない • 伸び代のあるポストモーテム⽂化 o 障害報告書は得意だが、障害を学びに消化する部分に伸び代がある。 o そもそもやったことがないから何をどうしたらいいか分からない

Slide 39

Slide 39 text

障害対応とポストモーテムの課題 • PagerDutyの導⼊で、開発チーム⾃⾝へアラートを送るように。 o 「このアラートは本当に必要なのか？」を考える⼒学が発⽣する • ポストモーテムの⽂化をSREが広めていく o テンプレートの準備 o 慣れていないチームに対して最初の数回はSREメンバがファシリを実施 o PagerDutyのAIによるポストモーテム機能も多⼤なる貢献

Slide 40

Slide 40 text

振り返ると‧‧‧ • 既に実施していた “だっしゅぼーどを眺める会” により、意⾒の交換への抵抗が少ない • ポストモーテムにおいてもその流れがうまく働き、アクションアイテムなど活発な意⾒がでている実感がある。 • また、アラートが多発している状態では⼤きい抵抗があったと思う。 o ここでも “だっしゅぼーどを眺める会” が貢献これって信頼を築く対話、不安を乗り越える対話では‧‧‧？ https://www.oreilly.co.jp/books/9784814400645/

Slide 41

Slide 41 text

Slide 42

Slide 42 text

横軸運⽤チームの廃⽌設⽴当初からプロダクト横断の横軸運⽤チームがあった • アラートの⼀次受け • リリース作業 • ゲートキーパーとして活躍内製化や開発チームのオーナーシップが⾼まっていく中で以下の課題が顕在化 • 権威化 • フローを低下させる要因に

Slide 43

Slide 43 text

横軸運⽤チームの廃⽌結果的に、業務の⾒直しと組織設計の⾒直し両⾯の流れでこの横軸運⽤チームを廃⽌に⾄る ※業務運⽤は別チームへ移管。システム運⽤は開発チームへ。実現した要因としては… • これまでの通り、開発チームのオーナシップの醸成が既にある程度進められていた • 不安を払拭するための対話と技術的なフォローアップ o 廃⽌の懸念を事前にヒアリングしフォロー o 例: リリース作業は⼀時的な権限付与と監査の仕組みを準備

Slide 44

Slide 44 text

振り返ると‧‧‧ • いきなり「横軸運⽤チームを廃⽌しましょう」では実現できなかった。 • (1)-(4)までのステップがあってこその実現 o ⼩さく刻む o 対話と協働を通した越境 o 上記を通じて信頼を築き、不安を取り除く SREをやりましょう。それがモダンでナウな今時のトレンドですよ。「You build it, you run it」ですよ。 (渾⾝のﾄﾞﾔ顔) ⼈間が電話を取り継ぐとかw PagerDutyをご存知ない？権威的な承認が良くないってのは何年も前からDevOpsの本に書いてあるんですよ。（無限の蘊蓄) https://www.oreilly.co.jp/books/9784814400645/ うまくいかないマン

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Platform Engineering • SREチームにはサブチームとしてPlatformチームがあり、開発者のためのプラットフォーム改善を進めている。 • SREとして築いた信頼関係が実はPlatform Engineeringの推進にも活かされている初期フェーズはチームビルディングとトイルの特定の為に濃いcollaboraConが必要 Microsoft Learn: Platform Engineering Team Topologiesより引⽤

Slide 47

Slide 47 text

更なる越境へ

Slide 48

Slide 48 text

更なる越境ワイ開発チームプロダクトイオンスマートテクノロジー（経営層）イオングループ全体 SREチーム DX 基幹今⽇話した内容はこの辺

Slide 49

Slide 49 text

更なる越境 • 経営直下としての⾃分と、経営への越境 • POSなどの基幹システムの運⽤を担っていたイオンアイビス社との統合 o 基幹領域をSREのプラクティスでどう改善していくか？ • 弊グループは⼤きい • 究極的には越境という認識を無くしたい

Slide 50

Slide 50 text

まとめ

Slide 51

Slide 51 text

まとめ • 越境と対話に関連する弊社のケースを⼀部ご紹介 • 越境は⼀⼈のメンバから始まる。そしてチームへ浸透しやがては組織⽂化変⾰のキーとなる。 • 越境には対話と協働が必要 • 相⼿を観察し、ケイパビリティ/リソース/状況/フェーズに合わせて対応 • ⼩さく始め、⼩さく刻み、⻑く続ける • 60万⼈超の従業員,数千万⼈のお客様へ貢献できる可能性がある変⾰は楽しいかもしれないぞ

Slide 52

Slide 52 text

あなたもイオンピープルにならないか？特にSREで！

Slide 53

Slide 53 text

参考資料：ケースごとのポイントまとめ (1) Embeddedアプローチ (2) だっしゅぼーどを眺める会 (3) SLI/SLO策定のためのワークショップ (4) 障害対応の⺠主化、ポストモーテム⽂化の醸成 (5) 横軸運⽤チームの廃⽌ (6)Platform Engineering ‧信頼を築く対話 ‧「観察」 ‧「介⼊」 ‧信頼を築く対話 ‧「惰性」の克服 ‧Whyを作り上げる対話 ‧「⼼理的反発」の軽減 ‧不安を乗り越える対話 ‧「労⼒」の軽減 ‧信頼を築く対話 ‧不安を乗り越える対話 ‧「惰性」の克服 ‧「⼼理的反発」の軽減 ‧信頼を築く対話 ‧ 「労⼒」の軽減 ‧「観察」 ‧「介⼊」

Slide 54

Slide 54 text

参考資料：関連する過去の登壇 • PagerDuty×ポストモーテムで築く障害対応⽂化 • SRE改善サイクルはチームを超えて - ダッシュボードを眺める会の取り組み • AEON’s blueprint for technological maturity and market competitiveness • SREチーム⽴ち上げ3年⽬、Embeddedやってみた実践と気づき • エンタープライズ企業でのSRE⽴ち上げ挑戦の際に意識した事と気付き、現在地とこれから