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

SRE NEXT 2025 (.https://sre-next.dev/2025/ )での発表資料です。

Transcript

1. SREチームの越境と対話 〜どのようにしてイオンスマートテクノロジーは 横軸運⽤チームの廃⽌に⾄ったか〜 イオンスマートテクノロジー株式会社 DevSecOps Div/Director 齋藤光 2025年7⽉11⽇ SRE NEXT 2025
2. 自己紹介
3. ⾃⼰紹介 齋藤 光( @hikkie13 ) イオンスマートテクノロジー株式会社(2022/5⼊社） DevSecOps Div ディレクター ⼊社以来、SREを組織にインストールすることに従事 趣味：ヨガ(RYT200) SRE NEXT 2023に登壇しました
4. 会社紹介
5. イオングループ紹介 - 関連数字 h"ps://www.aeon.info/company/ - "INFOGRAPHICS 数字で見るイオングループ"
6. 会社紹介
7. iAEONアプリについて 膨⼤なIDと購買データを集約したアプリ「iAEON」 iAEONはイオングループが提供する決済機能やポイントプログラムを1つにまとめたアプリです。 イオングループ内の多数の事業会社がもつ顧客IDを⼀つのアプリに統合しています。
8. iAEONアプリについて 膨⼤なIDと購買データを集約したアプリ「iAEON」 iAEONはイオングループが提供する決済機能やポイントプログラムを1つにまとめたアプリです。 イオングループ内の多数の事業会社がもつ顧客IDを⼀つのアプリに統合しています。
9. AEON PayとWAONを統合しました https://www.aeonpay-world.jp/world-cp/
10. Agenda • なぜ越境？ • 越境と対話の際に参考にしていること • ケース • 更なる越境
11. なぜ越境？〜当時の状況を添えて〜
12. 設⽴当初の組織図（雑） ビジネス部⾨ 開発チーム群 （ベンダ含む） インフラ 運⽤チーム
13. 設⽴当初の組織図（雑） ビジネス部⾨ 開発チーム群 （ベンダ含む） インフラ 運⽤チーム • そびえ⽴つ壁、壁、壁 • 依頼、許可、承認による仕事
14. イオンスマートテクノロジーでの組織取り組み 2022年に以下の動きが開始 • SREチームの組成（インフラチームからの変更） • 内製開発組織の⽴ち上げ。アジャイル開発への挑戦！ https://engineer-recruiting.aeon.info/aeon-tech-hub/interview_saitohikaru https://engineer-recruiting.aeon.info/aeon-tech-hub/interview_ounagasatoshi
15. アジャイル開発とSRE、⽬指すものは全てビジネス‧事業的成果 アジャイルの⽂脈で⾔えば‧‧‧ • Don’t just do agile. Be agile. • 開発をアジャイルにするのではなく、経営をアジャイルにする SREの⽂脈で⾔えば‧‧‧ • Class SRE implements DevOps • 運⽤と開発の壁の破壊 • ⽣産性を⾼めるための⾃動化 • プロダクトの信頼性
16. 皆、⽬的は1つなのだ Biz Dev Ops ビジネス的価値 顧客への価値 • 関⼼ごとの共通化＝ビジネス的価値、顧客への価値 • そのためには相互理解、素早い仮説検証ができる環境づくりが必要 → 部⾨を越えた越境のアプローチが有効なケースが多い（個⼈的⾒解）
17. 越境と対話の際に参考にしていること
18. 無⼈島に3冊持って⾏くとしたら… https://www.oreilly.co.jp/books/9784814400645/ https://amzn.asia/d/3MbvUeJ https://amzn.asia/d/2T50Kdt
19. 組織を変える5つの対話 5つの対話のステップ 信頼を築く対話 不安を乗り越える対話 Whyを作り上げる対話 コミットメントを⾏う対話 説明責任を果たす対話 いきなりWhyから始めない https://www.oreilly.co.jp/books/9784814400645/
20. 「変化を嫌う⼈」を動かす 惰性 慣れているものに 留まろうとする欲求 労⼒ 変化に必要な労⼒‧コスト （価値より労⼒を懸念） 感情 変化に対する否定的な感情 （アイディアそのものへの反応） ⼼理的反発 変化させられることへの反発 （アイディア推進者/⽅法への反発） 例 ‧今のオンコール体制で⼗分 ‧今のリリース⼿順で⼗分 ‧やったことないから⼤変だ ‧仕事が増えるから⼤変だ ‧俺の仕事を奪うのか ‧⾃分の無能さが露呈するのでは ‧やり⽅を押し付けてくるな https://amzn.asia/d/3MbvUeJ
21. 「変化を嫌う⼈」を動かす 惰性 慣れているものに 留まろうとする欲求 労⼒ 変化に必要な労⼒‧コスト （価値より労⼒を懸念） 感情 変化に対する否定的な感情 （アイディアそのものへの反応） ⼼理的反発 変化させられることへの反発 （アイディア推進者/⽅法への反発） 主な対処 ‧段階的な変化 ‧単純接触効果を狙う - 何度も伝える。時には話す⼈を変える ‧やらない労⼒の⽅が⾼いことを⽰す ‧不要なプロセスがあるなら⾒直す ‧労⼒の⾒せ⽅を変える ‧「なぜ？」に⽬を向けて観察し理解を深める ‧早い段階からプロセスに巻き込む ‧Yesを引き出す質問づくり https://amzn.asia/d/3MbvUeJ
22. 他者と働く 準備 相⼿と⾃分のナラティヴ (=解釈の枠組み,正しさ)の溝に気づく 観察 相⼿の⾔動や状況を 観察し、溝の箇所や 相⼿のナラティヴを探る 解釈 溝を⾶び越えて、 橋が架けられそうな場所や 架け⽅を探る 介⼊ ⾏動することで、 橋(=関係性)を築く Biz Dev Ops ビジネス的価値 顧客への価値 https://amzn.asia/d/2T50Kdt
23. 更に対話を深めるために… • 対話と会話の違いを理解する o 会話: 広く⼈と⼈が⾔葉で交流すること o 対話: それを通じて何かが新たに浮かび上がってくるようなやり取り o 相⼿を他者と認識し、他者の頭を使う o 「早く⾏くなら⼀⼈で⾏け、遠くに⾏くならみんなで⾏け」（アフリカの諺） • 基礎⼒としての、メタ認知/評価判断の保留/傾聴/学習と変容/リフレクション • 対話を深める要素としての、問いのデザイン/課題設定と優先度/意志/決断
24. ケース： (1) Embeddedアプローチ (2) だっしゅぼーどを眺める会 (3) SLI/SLO策定のためのワークショップ (4) 障害対応の⺠主化、ポストモーテム⽂化の醸成 (5) 横軸運⽤チームの廃⽌ (6) Platform Engineering
25. ケース： (1) Embeddedアプローチ (2) だっしゅぼーどを眺める会 (3) SLI/SLO策定のためのワークショップ (4) 障害対応の⺠主化、ポストモーテム⽂化の醸成 (5) 横軸運⽤チームの廃⽌ (6) Platform Engineering
26. SREチームにまつわるトポロジー（⽴ち上げ当時） Stream-Aligned Team Platform Team Enabling Team SREチーム 2つの側⾯を持ち合わせる Enabling • Stream-Aligned(SA)チームへSREのインストール • 整備したツール/基盤の伝承と伴⾛ • 定点観測会など定期的にSAチームとcommunication Platform • インフラ基盤⾃体の改善(Azure) • セルフサービスの提供（徐々に拡⼤中） • ツール/基盤の整備 Team Topologies
27. こうなる 情報共有&連携 SREチーム プロダクトA プロダクトB プロダクトD プロダクトC Platform ツール など 課題や要望を⼀般化 Enabling Enabling Enabling Enabling
28. SREチームにまつわるトポロジー • チーム内のcontext switchの多さ • 改善が進まない / 改善のスピードが期待値より低い領域が発⽣ o SAチームのリソース不⾜ o SAチームのcapability不⾜ o 優先度の考え⽅のすれ違い o 相談/依頼のタイミングではHow/WhatになっておりWhyを掘り起こすところからスタート → ⼀部プロダクトへのEmbeddedアプローチの導⼊へ 以下のつらみや悩みが発⽣
29. Embeddedへの挑戦で意識してやっていること • SAチームが出席するようなプロダクトに関する定例、会議は出席 o SAチームと情報をsync o 案件状況、チームの状態、課題の優先度を把握。⽬線を揃える。 • ⼀緒に課題を解くことで信頼の構築 o Team Topologiesでのコラボレーションが濃い状態に近いと捉えている • ゴールの状態を忘れない。 o あくまで最終⽬標はSAチーム内でSREの実践が完結すること o SAチーム内でSRE担当に任せっぱなしの状況は作らない。
30. ケース： (1) Embeddedアプローチ (2) だっしゅぼーどを眺める会 (3) SLI/SLO策定のためのワークショップ (4) 障害対応の⺠主化、ポストモーテム⽂化の醸成 (5) 横軸運⽤チームの廃⽌ (6) Platform Engineering
31. 弊社とオブザーバビリティ • イオンスマートテクノロジーではNew Relicを活⽤ • オブザーバビリティツールは運⽤チームのためのものではない。開発チームが使いこなす ことが⼤事。 • 開発チームの使いこなし促進‧意識づけのために、定点観測会を実施。堅苦しくないよう に ”だっしゅぼーどを眺める会” と銘打って開催。 • オブザーバビリティのモブ作業として確⽴
32. 定点観測会の副次的効果 • 課題作成‧課題の棚卸し • 直近タスクやトピックなどの共有 • アイスブレイク/雑談 • ザイオンス効果（単純接触効果）で協業がし易くなる！
33. ケース： (1) Embeddedアプローチ (2) だっしゅぼーどを眺める会 (3) SLI/SLO策定のためのワークショップ (4) 障害対応の⺠主化、ポストモーテム⽂化の醸成 (5) 横軸運⽤チームの廃⽌ (6) Platform Engineering
34. SLI/SLO策定ワークショップ • 現在、SLI/SLOの策定と運⽤を推進している。 • エンジニア部⾨のみで決めるのではなく、 ビジネス部⾨との合意が必須 • 合意に向けた対話には正しい知識が必要 エンジニア部⾨‧ビジネス部⾨両者を集めて SLI/SLO策定ワークショップを開催 https://www.oreilly.co.jp/books/9784814400348/
35. ワークショップ後のフィードバックからの抜粋 • ビジネス部⾨の⽅とワークを⼀緒に⾏なって、SLIの考え⽅がそれぞれだと感じたので、 SLIの共通認識をこれから持っていくことが重要だと感じた。 • ワークショップで話したような議論を通常時でもビジネス側と⾏いたい • SLIとSLOの定義をビジネスと合意して継続的にみていきたい • ビジネスサイドからもSLI SLOを指標として提案したい
36. 現在 • ⼀部プロダクトでSLOの仮運⽤を開始 • 並⾏してワークショップを随時実施中。そこからのSLO策定会議が開発チーム主導で開催 される流れができている
37. ケース： (1) Embeddedアプローチ (2) だっしゅぼーどを眺める会 (3) SLI/SLO策定のためのワークショップ (4) 障害対応の⺠主化、ポストモーテム⽂化の醸成 (5) 横軸運⽤チームの廃⽌ (6) Platform Engineering
38. 障害対応とポストモーテムの課題 • 鳴り響く、でも対応は不要なアラート • ⼀次受けとなる専任の運⽤チームへの⾼負荷 o 中⾝のわからないアラートを受け取り、都度開発チームへ問い合わせを⾏っていた o ⾃分が受けないので、開発チームもアラートを整理するモチベーションが上がらない • 伸び代のあるポストモーテム⽂化 o 障害報告書は得意だが、障害を学びに消化する部分に伸び代がある。 o そもそもやったことがないから何をどうしたらいいか分からない
39. 障害対応とポストモーテムの課題 • PagerDutyの導⼊で、開発チーム⾃⾝へアラートを送るように。 o 「このアラートは本当に必要なのか？」を考える⼒学が発⽣する • ポストモーテムの⽂化をSREが広めていく o テンプレートの準備 o 慣れていないチームに対して最初の数回はSREメンバがファシリを実施 o PagerDutyのAIによるポストモーテム機能も多⼤なる貢献
40. 振り返ると‧‧‧ • 既に実施していた “だっしゅぼーどを眺める会” により、意⾒の交換への抵抗が少ない • ポストモーテムにおいてもその流れがうまく働き、アクションアイテムなど活発な意⾒がでて いる実感がある。 • また、アラートが多発している状態では⼤きい抵抗があったと思う。 o ここでも “だっしゅぼーどを眺める会” が貢献 これって信頼を築く対話、不安を乗り越える対話では‧‧‧？ https://www.oreilly.co.jp/books/9784814400645/
41. ケース： (1) Embeddedアプローチ (2) だっしゅぼーどを眺める会 (3) SLI/SLO策定のためのワークショップ (4) 障害対応の⺠主化、ポストモーテム⽂化の醸成 (5) 横軸運⽤チームの廃⽌ (6) Platform Engineering
42. 横軸運⽤チームの廃⽌ 設⽴当初からプロダクト横断の横軸運⽤チームがあった • アラートの⼀次受け • リリース作業 • ゲートキーパーとして活躍 内製化や開発チームのオーナーシップが⾼まっていく中で以下の課題が顕在化 • 権威化 • フローを低下させる要因に
43. 横軸運⽤チームの廃⽌ 結果的に、業務の⾒直しと組織設計の⾒直し両⾯の流れでこの横軸運⽤チームを廃⽌に⾄る ※業務運⽤は別チームへ移管。システム運⽤は開発チームへ。 実現した要因としては… • これまでの通り、開発チームのオーナシップの醸成が既にある程度進められていた • 不安を払拭するための対話と技術的なフォローアップ o 廃⽌の懸念を事前にヒアリングしフォロー o 例: リリース作業は⼀時的な権限付与と監査の仕組みを準備
44. 振り返ると‧‧‧ • いきなり「横軸運⽤チームを廃⽌しましょう」では実現できなかった。 • (1)-(4)までのステップがあってこその実現 o ⼩さく刻む o 対話と協働を通した越境 o 上記を通じて信頼を築き、不安を取り除く SREをやりましょう。 それがモダンでナウな今時のトレンドですよ。 「You build it, you run it」ですよ。 (渾⾝のﾄﾞﾔ顔) ⼈間が電話を取り継ぐとかw PagerDutyをご存知ない？ 権威的な承認が良くないってのは何 年も前からDevOpsの本に書いてあ るんですよ。（無限の蘊蓄) https://www.oreilly.co.jp/books/9784814400645/ うまくいかないマン
45. ケース： (1) Embeddedアプローチ (2) だっしゅぼーどを眺める会 (3) SLI/SLO策定のためのワークショップ (4) 障害対応の⺠主化、ポストモーテム⽂化の醸成 (5) 横軸運⽤チームの廃⽌ (6) Platform Engineering
46. Platform Engineering • SREチームにはサブチームとしてPlatformチームがあり、開発者のためのプラットフォーム 改善を進めている。 • SREとして築いた信頼関係が実はPlatform Engineeringの推進にも活かされている 初期フェーズはチームビルディングとトイルの特定の為に 濃いcollaboraConが必要 Microsoft Learn: Platform Engineering Team Topologiesより引⽤
47. 更なる越境へ
48. 更なる越境 ワイ 開発チーム プロダクト イオンスマートテクノロジー（経営層） イオングループ全体 SREチーム DX 基幹 今⽇話した内容はこの辺
49. 更なる越境 • 経営直下としての⾃分と、経営への越境 • POSなどの基幹システムの運⽤を担っていたイオンアイビス社との統合 o 基幹領域をSREのプラクティスでどう改善していくか？ • 弊グループは⼤きい • 究極的には越境という認識を無くしたい
50. まとめ
51. まとめ • 越境と対話に関連する弊社のケースを⼀部ご紹介 • 越境は⼀⼈のメンバから始まる。そしてチームへ浸透し やがては組織⽂化変⾰のキーとなる。 • 越境には対話と協働が必要 • 相⼿を観察し、ケイパビリティ/リソース/状況/フェーズに合わせて対応 • ⼩さく始め、⼩さく刻み、⻑く続ける • 60万⼈超の従業員,数千万⼈のお客様へ貢献できる可能性がある変⾰は楽しいかもしれないぞ
52. あなたもイオンピープルにならないか？ 特にSREで！
53. 参考資料：ケースごとのポイントまとめ (1) Embeddedアプローチ (2) だっしゅぼーどを眺める会 (3) SLI/SLO策定のためのワークショップ (4) 障害対応の⺠主化、ポストモーテム⽂化の醸成 (5) 横軸運⽤チームの廃⽌ (6)Platform Engineering ‧信頼を築く対話 ‧「観察」 ‧「介⼊」 ‧信頼を築く対話 ‧「惰性」の克服 ‧Whyを作り上げる対話 ‧「⼼理的反発」の軽減 ‧不安を乗り越える対話 ‧「労⼒」の軽減 ‧信頼を築く対話 ‧不安を乗り越える対話 ‧「惰性」の克服 ‧「⼼理的反発」の軽減 ‧信頼を築く対話 ‧ 「労⼒」の軽減 ‧「観察」 ‧「介⼊」
54. 参考資料：関連する過去の登壇 • PagerDuty×ポストモーテムで築く障害対応⽂化 • SRE改善サイクルはチームを超えて - ダッシュボードを眺める会の取り組み • AEON’s blueprint for technological maturity and market competitiveness • SREチーム⽴ち上げ3年⽬、Embeddedやってみた実践と気づき • エンタープライズ企業でのSRE⽴ち上げ挑戦の際に意識した事と気付き、 現在地とこれから
55. 以下、告知
56. 弊社からもう⼀⼈登壇します！( 7/11 16:20 - 16:40)
57. 告知
58. 告知 https://aeon.connpass.com/event/357743/