SREじゃなかった僕らがenablingを通じて「SRE実践者」になるまでのリアル / SRE Kaigi 2026

2026年1月31日開催「SRE Kaigi 2026」の登壇資料です。
登壇者：イオンスマートテクノロジー株式会社 久保 翔馬／川田 雅彦

Transcript

1. SREじゃなかった僕らがenablingを通じて 「SRE実践者」になるまでのリアル イオンスマートテクノロジー株式会社 久保 翔馬 川田 雅彦 2026年1月31日 SRE Kaigi 2026
2. 会社紹介
3. 3 iAEONアプリについて 膨大なIDと購買データを集約したアプリ「iAEON」 iAEONはイオングループが提供する決済機能やポイントプログラムを1つにまとめたアプリです。 イオングループ内の多数の事業会社がもつ顧客IDを一つのアプリに統合しています。
4. 4 iAEONアプリについて 膨大なIDと購買データを集約したアプリ「iAEON」 iAEONはイオングループが提供する決済機能やポイントプログラムを1つにまとめたアプリです。 イオングループ内の多数の事業会社がもつ顧客IDを一つのアプリに統合しています。
5. AEONの歴史上 初のエンジニアイベントスポンサー です！
6. イオンスマートテクノロジーのSRE 6 イオンスマートテクノロジーのSRE https://speakerdeck.com/aeonpeople/sre-is-not-a-cost- center-real-world-stories-that-prove-true-value https://speakerdeck.com/aeonpeople/the-cross- border-and-dialogue-of-sre SRE NEXT 2025より
7. イオンスマートテクノロジーのSRE 7 Enabling（時々Embedded)でやってきた
8. 実際のところ、どうなのでしょうか？
9. 今回は 他部署からSREチームにJoinしたメンバー & Enableされたメンバー の視点でお話しします
10. インフラエンジニアから SREチームに入って感じたこと
11. 自己紹介 自己紹介 イオンスマートテクノロジー株式会社 DevSecOps Div SREチーム 川田 雅彦 2021/4 新卒で生命保険会社に入社（インフラエンジニア） 2023/10 イオンアイビスに転職 2024/12 イオンスマートテクノロジーとイオンアイビスが合併 2025/4 SREチームにジョイン 3歳児の娘と拡張中 / バンドやってました！ 11 内製 外注中心
12. アジェンダ - インフラからSREへ - 異動後の印象・ギャップ - 変わったこと - おわりに 12 本日のアジェンダ
13. インフラからSREへ 13 クラウドに憧れて転職 - 2021年 新卒でインフラエンジニアとなる - 2023年 パブリッククラウド技術に憧れ、転職を決意 - 念願が叶い、Azureの案件に関わるようになるが・・・ 稟議や作業委託のスケジュール調整が業務 の大半を占める
14. インフラからSREへ 14 SREチームへ異動 - 組織改編をきっかけに、”突然”SREチームへの異動を伝えられる - 「SRE」を初めて聞き、異動まで不安な日々を送る 「SREってなんか怖そう」 「すごい人たちの集まり」 自分の知識、技術で やっていけるのか
15. アジェンダ - インフラからSREへ - 異動後の印象・ギャップ - 変わったこと - おわりに 15 本日のアジェンダ
16. 異動後の印象・ギャップ 16 初朝会に参加 - わいわいと活気のあるチームの雰囲気 「明るい」「称える文化」「チームで考える」 1 on 1などによる積極的な交流 - 技術面で不安だらけ 聞いたことのない単語が飛び交う 触ったことのない様々なツール →「戦力にならない」「ついていけない」のではと、技術面で不安が残る 異動直後に1 on 1を申し込んでくれたことが、今でも印象に残ってい ます。 雑談も交えて話し、「わからないことない？」と気にかけてくれた ことで、不安だった気持ちが救われたのを覚えています。
17. 異動後の印象・ギャップ 17 どんなふうに業務を広げていったか Step 1：オンボーディング資料を活用し、全体像を理解する • チームで整備されたオンボーディング資料（Confluence)があることで 何から始めればいいかが明確で、スムーズにスタートを切ることができ た • プロダクトリストやインフラ概要図など、資料が一通りまとまって整理 されていることで、キャッチアップしやすいと感じた • チームチャットでの相談では、複数のメンバーが積極的に応じてくれる 文化があり、一人に偏ることなく、幅広くチームとコミュニケーション を取ることができた
18. 異動後の印象・ギャップ 18 実際のオンボーディング資料
19. 異動後の印象・ギャップ 19 どんなふうに業務を広げていったか STEP 2：タスク着手 • モブワークを通じて、実際に手を動かしながら学ぶ機会を多く得ること ができた • PRに対する細やかで丁寧なレビューを通じて、設計の意図や実装の背景 まで深く学ぶことができた 朝会などを通じて、チームの明るさや、リスペクトを大切にする雰囲気を感じたことで、自 然と相談しやすい空気があり、集まって話しながら作業する文化がありました。 実際にわからないことを相談すると、「この後一緒に進めましょうか」と声をかけてもらえ る場面が多く、非常に貴重な時間になり感謝しています。
20. 異動後の印象・ギャップ 20 どんなふうに業務を広げていったか Step 3：スキルマップを活用した計画と振り返り • スキルマップを基に目標を刻み、チケット化 スキルマップをベースに、取り組む内容をJIRAチケットとして“刻む“。 目標・進捗が解像度高く可視化されることで、日々の成長を実感することができました。 実際に刻んだチケットの一部
21. アジェンダ - インフラからSREへ - 異動後の印象・ギャップ - 変わったこと - おわりに 21 本日のアジェンダ
22. 変わったこと 22 自分の意見を持ち、発信する Before • 言われたことをこなす意識が強く、疑問を持っても発信できなかった After • ADRを利用した意思決定を進める中で、自分自身がどうしたいのかを明確にすることが 求められ、意見を持つことや根拠を整理・伝えることの重要性に気づく • PRで意図を言語化する習慣がつき、モブワークやレビューを通じて、意図を言葉にして 発信する大切さを学んだ。「なぜこう書いたか」を共有することで、レビューの質も深 まる 一般的に ADR（Architecture Decision Record）はシステム設計に関する意思決定を記録するものですが、 ちのチームでは「Any Decision Record」として、設計に限らずあらゆる(Any)意思決定を記録する場として しています。
23. 変わったこと 23 自発的に課題を探す Before • 与えられたタスクに取り組むことが中心で、自ら課題を見つけ解決する意識が薄かった After • 依頼ベースではなく、各自が課題を見つけて行動するSREチームの文化に触れ、少しず つタスクを自ら作り、業務やシステムを改善していく意識をもつ • プロダクトチームとの接点を増やし、日々の会話の中から課題を拾い上げることで、 SREとしてプロダクトにも主体的に関わる
24. 変わったこと 24 不安だった技術面の進歩 Before • 技術に対して自信がなかった • 技術的課題について考え、自分から意見を発信することができなかった After モブワークなどの集まって話しながら作業する文化と、些細なことも称えあう文化によって、 技術的な課題について、解決策を自分なりに考えチームに提案できるように
25. 変わったこと 25 実際のPRでの会話
26. 変わったこと 26 ここまでを振り返って 自分のような人間でも、少しずつSREを実践できるようになったと感じた 「意見を持つ」「言語化する」「自ら課題を見つけて行動する」 こうした変化をもたらしたのは、次のような環境と支援が大きかったと感 じています。 • 接しやすい雰囲気づくりや 1 on 1 などの対話しやすい関係性 • ペアプロや丁寧なレビューなど、自然に関わる機会を生む行動 • 明確で刻んだタスクと、目標のJIRAチケット化による取り組みやすさ
27. - インフラからSREへ - 異動後の印象、ギャップ - 変わったこと - おわりに 27 本日のアジェンダ
28. おわりに 28 前半のまとめ SREチームにJoinして • モブワークやADRなど、SREチームが実践している工夫した進め方に触 れる中で、考え方や意図を理解することができて、自分でも仮説や意見 を持って関われるようになっていきました。 • 小さな行動や気づきにも称える文化・雰囲気が、「まずはやってみる」 「対話してみる」気持ちを後押ししてくれたことも大きな支えでした。 SREを実践していくうえで大切だと思ったことは、今後Enablingをしてい く中でも、意識すべきポイントになるのではないか
29. おわりに 29 やっていき宣言 これまでに得た経験や気づきを活かし、今後は 「SREチームにEnablingされた自分」 から、 「プロダクトチームにSREをEnablingする自分」 へと、 役割と視座を広げていきたい
30. 「全員初見」のワイガヤMTGが生んだEnabling モバイルアプリエンジニア、 気がついたらSREプラクティスを 実践していたという話
31. 自己紹介 イオンスマートテクノロジー株式会社 フロントエンド開発Div. フロントエンド開発チーム（Stream-Aligned Team） 久保 翔馬 (KUBO Shoma) X : @bory_kb • 普段の業務: iAEONアプリの開発 (モバイルアプリ開発) • 普段良く使う言語 : TypeScript • コミュニティ • InnerSource Commons Foundation Member 31
32. 32 https://amzn.asia/d/8PK01tc 私とSREチームの関係図 Enabling Team Stream-Aligned Team (SAチーム) フロントエンド開発チーム Platform Team SRE チーム 今日のお話はココ！
33. Stream-Aligned Team の私が どのようにして SRE から Enabling されたのか 「Stream-Aligned Team の目線」でお話します 33
34. 「だっしゅぼーどを眺める会」 とは • 週一の定例MTG・通称 : 眺める会 • 参加者は私の所属するフロントエンド開発チームとSREチーム • New Relic のダッシュボードや Azure 上にあるリソースの状況を確認 • 「直近で増え始めたエラーはないか」 • 「Azure 計画メンテナンスで影響のあるものはないか」 • 「想定外のコスト増減がないか」 • 報告会ではなく眺める会 • 事前準備不要で実際の状況は当日その場で初めて確認をする • 全員初見 34
35. だっしゅぼーどを眺める会の変遷を追う • フェーズ1: SRE先導期 • フェーズ2:月イチ特別回の発展期 • フェーズ3: SAチーム主導期 眺める会に軸を置いて 私、および、私のチームどう変わっていったのか 35
36. と、その前に 36
37. フェーズ0:入社前の私 フェーズ0:入社前の私 • SaaS を開発するWebアプリケーションエンジニア • アプリの規模は小さく、また、ユーザーもそんなに多くなかったため、 日次でダッシュボードをつくってパフォーマンスを見たり…などはなし • （当時も Azure 使っていたので） 月イチで Azure コストチェックと計画メンテナンス予定の確認 日々パフォーマンスをチェックする経験がないまま イオンスマートテクノロジーへと入社…！ 37
38. 改めて
39. フェーズ1: SRE先導期 フェーズ1: SRE先導期 -> フェーズ2:月イチ特別回の発展期 -> フェーズ3: SAチーム主導期 • SRE（特定の一人）が毎週司会進行を担当 • SAチームは進行を聞きながら問題がなさそうか一緒にチェック • 私「毎週プロダクトの正常性をSREといっしょに見れて安心！＆楽しい！」 課題 • SREに任せてしまう場合が多い（MTGの進行も、事象の確認も） • SREとSAチームだけでは起こった事象に対して原因究明はできるが、 予測ができない（ことが多い） 39
40. フェーズ2: 月イチ特別回の発展期 フェーズ1: SRE先導期 -> フェーズ2:月イチ特別回の発展期 -> フェーズ3: SAチーム主導期 • 月末の会を特別回とした • いつものメンバーに加えてビジネス部門のメンバーと バックエンドサービスチームも参加してもらうことに • 次月に開催予定のキャンペーン情報やクーポン配布予定を共有してもらう • これにより負荷が高い日を予測しやすくなり、 先回りの対策が取りやすくなった • 複数部門が一つのプロダクトの安定稼働のために密に連携するように 課題 • SREに任せてしまう場合が多い（変わらずの課題） 40
41. フェーズ3: SAチーム主導期（現在） フェーズ1: SRE先導期 -> フェーズ2:月イチ特別回の発展期 -> フェーズ3: SAチーム主導期 • 上司からの提案：「これからはSAチームで司会進行してみよう」 • SAチームのメンバーが持ち回りで進行を担当するよう変更 • 事前準備不要＆全員初見というスタイルは変わらない • 一方で自ら進行する必要性が出てきたのでSAチームに主体性が芽生えた • 持ち回りになったことで、特定の誰か一人の記憶を頼れなくなった • しかし、だからこそ「ちゃんと聞こう」という意識が芽生える • SREは会議チャットでコメントくれたり、相づちしてくれたりして、 なんかあったときすぐに聞けるんだという雰囲気を作りづつけてくれている 41
42. ここまでのプロセスはEnablingでは？ • 眺める会の司会進行がほぼ苦労なく、気づいたら SAチーム へ移っていた • SAチームが自ら司会進行することの価値に気付き、 主体的に実行するようになった = SREによる「Enabling」 • なぜEnablingがうまくいったのか • 眺める会の設計 • 事前準備が不要なため、気軽に参加ができる • 司会もプレッシャーがない、 「わからない」と言いやすい • SREの人柄 • 気軽に話しかけやすく、非常に相談しやすい • なにかあったとき自分事として一緒に考えてくれる • ぶっちゃけSREの人たちと仲良くなりたいと思っていた（！！） 42
43. まとめ & SREの皆様へのメッセージ 何かのプロセスを Enabling するのであれば… • とっつきやすさ • 「とりあえずやってみよう」が生まれやすい仕組みをつくる • 私のケースでは : 事前準備不要・全員初見というお気軽なMTG設計 • 相談しやすさ • 何かあったらすぐに助けてもらえるから大丈夫、という安心感を与える • 私のケースでは : 「チャットでの盛り上げや相づち」による「ワイガヤ」感 ＆毎週MTGする中でわかったSREの相談しやすい人柄 43
44. 最後に 「セッション全体のまとめ」 です
45. SREじゃなかった僕らが「SRE実践者」になれたのは まとめのまとめ SREによる丁寧なEnablingプロセスがあったから！ • 対話しやすい関係性の構築 o 1on1 、称え合う文化、話しかけやすい雰囲気 • 実践的な学習機会の提供 o ペアプロ、モブワーク、丁寧なレビュー • とっつきやすい仕組みづくり o 全員初見、事前準備不要、刻んだタスク 続きはB1Fホワイエ・イオンブースで。 「うちの組織だと…」「具体的にはどうやって…？」などお話しましょう！ お待ちしてます。 45
46. 46 46