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

by AEON

Slide 1

Slide 1 text

SREじゃなかった僕らがenablingを通じて「SRE実践者」になるまでのリアルイオンスマートテクノロジー株式会社久保翔馬川田雅彦 2026年1月31日 SRE Kaigi 2026

Slide 2

Slide 2 text

会社紹介

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

AEONの歴史上初のエンジニアイベントスポンサーです！

Slide 6

Slide 6 text

イオンスマートテクノロジーの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より

Slide 7

Slide 7 text

イオンスマートテクノロジーのSRE 7 Enabling（時々Embedded)でやってきた

Slide 8

Slide 8 text

実際のところ、どうなのでしょうか？

Slide 9

Slide 9 text

今回は他部署からSREチームにJoinしたメンバー & Enableされたメンバーの視点でお話しします

Slide 10

Slide 10 text

インフラエンジニアから SREチームに入って感じたこと

Slide 11

Slide 11 text

自己紹介自己紹介イオンスマートテクノロジー株式会社 DevSecOps Div SREチーム川田雅彦 2021/4 新卒で生命保険会社に入社（インフラエンジニア） 2023/10 イオンアイビスに転職 2024/12 イオンスマートテクノロジーとイオンアイビスが合併 2025/4 SREチームにジョイン 3歳児の娘と拡張中 / バンドやってました！ 11 内製外注中心

Slide 12

Slide 12 text

アジェンダ - インフラからSREへ - 異動後の印象・ギャップ - 変わったこと - おわりに 12 本日のアジェンダ

Slide 13

Slide 13 text

インフラからSREへ 13 クラウドに憧れて転職 - 2021年新卒でインフラエンジニアとなる - 2023年パブリッククラウド技術に憧れ、転職を決意 - 念願が叶い、Azureの案件に関わるようになるが・・・稟議や作業委託のスケジュール調整が業務の大半を占める

Slide 14

Slide 14 text

インフラからSREへ 14 SREチームへ異動 - 組織改編をきっかけに、”突然”SREチームへの異動を伝えられる - 「SRE」を初めて聞き、異動まで不安な日々を送る「SREってなんか怖そう」「すごい人たちの集まり」自分の知識、技術でやっていけるのか

Slide 15

Slide 15 text

アジェンダ - インフラからSREへ - 異動後の印象・ギャップ - 変わったこと - おわりに 15 本日のアジェンダ

Slide 16

Slide 16 text

異動後の印象・ギャップ 16 初朝会に参加 - わいわいと活気のあるチームの雰囲気「明るい」「称える文化」「チームで考える」 1 on 1などによる積極的な交流 - 技術面で不安だらけ聞いたことのない単語が飛び交う触ったことのない様々なツール →「戦力にならない」「ついていけない」のではと、技術面で不安が残る異動直後に1 on 1を申し込んでくれたことが、今でも印象に残っています。雑談も交えて話し、「わからないことない？」と気にかけてくれたことで、不安だった気持ちが救われたのを覚えています。

Slide 17

Slide 17 text

異動後の印象・ギャップ 17 どんなふうに業務を広げていったか Step 1：オンボーディング資料を活用し、全体像を理解する • チームで整備されたオンボーディング資料（Confluence)があることで何から始めればいいかが明確で、スムーズにスタートを切ることができた • プロダクトリストやインフラ概要図など、資料が一通りまとまって整理されていることで、キャッチアップしやすいと感じた • チームチャットでの相談では、複数のメンバーが積極的に応じてくれる文化があり、一人に偏ることなく、幅広くチームとコミュニケーションを取ることができた

Slide 18

Slide 18 text

異動後の印象・ギャップ 18 実際のオンボーディング資料

Slide 19

Slide 19 text

異動後の印象・ギャップ 19 どんなふうに業務を広げていったか STEP 2：タスク着手 • モブワークを通じて、実際に手を動かしながら学ぶ機会を多く得ることができた • PRに対する細やかで丁寧なレビューを通じて、設計の意図や実装の背景まで深く学ぶことができた朝会などを通じて、チームの明るさや、リスペクトを大切にする雰囲気を感じたことで、自然と相談しやすい空気があり、集まって話しながら作業する文化がありました。実際にわからないことを相談すると、「この後一緒に進めましょうか」と声をかけてもらえる場面が多く、非常に貴重な時間になり感謝しています。

Slide 20

Slide 20 text

異動後の印象・ギャップ 20 どんなふうに業務を広げていったか Step 3：スキルマップを活用した計画と振り返り • スキルマップを基に目標を刻み、チケット化スキルマップをベースに、取り組む内容をJIRAチケットとして“刻む“。目標・進捗が解像度高く可視化されることで、日々の成長を実感することができました。実際に刻んだチケットの一部

Slide 21

Slide 21 text

アジェンダ - インフラからSREへ - 異動後の印象・ギャップ - 変わったこと - おわりに 21 本日のアジェンダ

Slide 22

Slide 22 text

変わったこと 22 自分の意見を持ち、発信する Before • 言われたことをこなす意識が強く、疑問を持っても発信できなかった After • ADRを利用した意思決定を進める中で、自分自身がどうしたいのかを明確にすることが求められ、意見を持つことや根拠を整理・伝えることの重要性に気づく • PRで意図を言語化する習慣がつき、モブワークやレビューを通じて、意図を言葉にして発信する大切さを学んだ。「なぜこう書いたか」を共有することで、レビューの質も深まる一般的に ADR（Architecture Decision Record）はシステム設計に関する意思決定を記録するものですが、ちのチームでは「Any Decision Record」として、設計に限らずあらゆる(Any)意思決定を記録する場としてしています。

Slide 23

Slide 23 text

変わったこと 23 自発的に課題を探す Before • 与えられたタスクに取り組むことが中心で、自ら課題を見つけ解決する意識が薄かった After • 依頼ベースではなく、各自が課題を見つけて行動するSREチームの文化に触れ、少しずつタスクを自ら作り、業務やシステムを改善していく意識をもつ • プロダクトチームとの接点を増やし、日々の会話の中から課題を拾い上げることで、 SREとしてプロダクトにも主体的に関わる

Slide 24

Slide 24 text

変わったこと 24 不安だった技術面の進歩 Before • 技術に対して自信がなかった • 技術的課題について考え、自分から意見を発信することができなかった After モブワークなどの集まって話しながら作業する文化と、些細なことも称えあう文化によって、技術的な課題について、解決策を自分なりに考えチームに提案できるように

Slide 25

Slide 25 text

変わったこと 25 実際のPRでの会話

Slide 26

Slide 26 text

変わったこと 26 ここまでを振り返って自分のような人間でも、少しずつSREを実践できるようになったと感じた「意見を持つ」「言語化する」「自ら課題を見つけて行動する」こうした変化をもたらしたのは、次のような環境と支援が大きかったと感じています。 • 接しやすい雰囲気づくりや 1 on 1 などの対話しやすい関係性 • ペアプロや丁寧なレビューなど、自然に関わる機会を生む行動 • 明確で刻んだタスクと、目標のJIRAチケット化による取り組みやすさ

Slide 27

Slide 27 text

- インフラからSREへ - 異動後の印象、ギャップ - 変わったこと - おわりに 27 本日のアジェンダ

Slide 28

Slide 28 text

おわりに 28 前半のまとめ SREチームにJoinして • モブワークやADRなど、SREチームが実践している工夫した進め方に触れる中で、考え方や意図を理解することができて、自分でも仮説や意見を持って関われるようになっていきました。 • 小さな行動や気づきにも称える文化・雰囲気が、「まずはやってみる」「対話してみる」気持ちを後押ししてくれたことも大きな支えでした。 SREを実践していくうえで大切だと思ったことは、今後Enablingをしていく中でも、意識すべきポイントになるのではないか

Slide 29

Slide 29 text

おわりに 29 やっていき宣言これまでに得た経験や気づきを活かし、今後は「SREチームにEnablingされた自分」から、「プロダクトチームにSREをEnablingする自分」へと、役割と視座を広げていきたい

Slide 30

Slide 30 text

「全員初見」のワイガヤMTGが生んだEnabling モバイルアプリエンジニア、気がついたらSREプラクティスを実践していたという話

Slide 31

Slide 31 text

自己紹介イオンスマートテクノロジー株式会社フロントエンド開発Div. フロントエンド開発チーム（Stream-Aligned Team）久保翔馬 (KUBO Shoma) X : @bory_kb • 普段の業務: iAEONアプリの開発 (モバイルアプリ開発) • 普段良く使う言語 : TypeScript • コミュニティ • InnerSource Commons Foundation Member 31

Slide 32

Slide 32 text

32 https://amzn.asia/d/8PK01tc 私とSREチームの関係図 Enabling Team Stream-Aligned Team (SAチーム) フロントエンド開発チーム Platform Team SRE チーム今日のお話はココ！

Slide 33

Slide 33 text

Stream-Aligned Team の私がどのようにして SRE から Enabling されたのか「Stream-Aligned Team の目線」でお話します 33

Slide 34

Slide 34 text

「だっしゅぼーどを眺める会」とは • 週一の定例MTG・通称 : 眺める会 • 参加者は私の所属するフロントエンド開発チームとSREチーム • New Relic のダッシュボードや Azure 上にあるリソースの状況を確認 • 「直近で増え始めたエラーはないか」 • 「Azure 計画メンテナンスで影響のあるものはないか」 • 「想定外のコスト増減がないか」 • 報告会ではなく眺める会 • 事前準備不要で実際の状況は当日その場で初めて確認をする • 全員初見 34

Slide 35

Slide 35 text

だっしゅぼーどを眺める会の変遷を追う • フェーズ1: SRE先導期 • フェーズ2:月イチ特別回の発展期 • フェーズ3: SAチーム主導期眺める会に軸を置いて私、および、私のチームどう変わっていったのか 35

Slide 36

Slide 36 text

と、その前に 36

Slide 37

Slide 37 text

フェーズ0:入社前の私フェーズ0:入社前の私 • SaaS を開発するWebアプリケーションエンジニア • アプリの規模は小さく、また、ユーザーもそんなに多くなかったため、日次でダッシュボードをつくってパフォーマンスを見たり…などはなし • （当時も Azure 使っていたので）月イチで Azure コストチェックと計画メンテナンス予定の確認日々パフォーマンスをチェックする経験がないままイオンスマートテクノロジーへと入社…！ 37

Slide 38

Slide 38 text

改めて

Slide 39

Slide 39 text

フェーズ1: SRE先導期フェーズ1: SRE先導期 -> フェーズ2:月イチ特別回の発展期 -> フェーズ3: SAチーム主導期 • SRE（特定の一人）が毎週司会進行を担当 • SAチームは進行を聞きながら問題がなさそうか一緒にチェック • 私「毎週プロダクトの正常性をSREといっしょに見れて安心！＆楽しい！」課題 • SREに任せてしまう場合が多い（MTGの進行も、事象の確認も） • SREとSAチームだけでは起こった事象に対して原因究明はできるが、予測ができない（ことが多い） 39

Slide 40

Slide 40 text

フェーズ2: 月イチ特別回の発展期フェーズ1: SRE先導期 -> フェーズ2:月イチ特別回の発展期 -> フェーズ3: SAチーム主導期 • 月末の会を特別回とした • いつものメンバーに加えてビジネス部門のメンバーとバックエンドサービスチームも参加してもらうことに • 次月に開催予定のキャンペーン情報やクーポン配布予定を共有してもらう • これにより負荷が高い日を予測しやすくなり、先回りの対策が取りやすくなった • 複数部門が一つのプロダクトの安定稼働のために密に連携するように課題 • SREに任せてしまう場合が多い（変わらずの課題） 40

Slide 41

Slide 41 text

フェーズ3: SAチーム主導期（現在）フェーズ1: SRE先導期 -> フェーズ2:月イチ特別回の発展期 -> フェーズ3: SAチーム主導期 • 上司からの提案：「これからはSAチームで司会進行してみよう」 • SAチームのメンバーが持ち回りで進行を担当するよう変更 • 事前準備不要＆全員初見というスタイルは変わらない • 一方で自ら進行する必要性が出てきたのでSAチームに主体性が芽生えた • 持ち回りになったことで、特定の誰か一人の記憶を頼れなくなった • しかし、だからこそ「ちゃんと聞こう」という意識が芽生える • SREは会議チャットでコメントくれたり、相づちしてくれたりして、なんかあったときすぐに聞けるんだという雰囲気を作りづつけてくれている 41

Slide 42

Slide 42 text

ここまでのプロセスはEnablingでは？ • 眺める会の司会進行がほぼ苦労なく、気づいたら SAチームへ移っていた • SAチームが自ら司会進行することの価値に気付き、主体的に実行するようになった = SREによる「Enabling」 • なぜEnablingがうまくいったのか • 眺める会の設計 • 事前準備が不要なため、気軽に参加ができる • 司会もプレッシャーがない、「わからない」と言いやすい • SREの人柄 • 気軽に話しかけやすく、非常に相談しやすい • なにかあったとき自分事として一緒に考えてくれる • ぶっちゃけSREの人たちと仲良くなりたいと思っていた（！！） 42

Slide 43

Slide 43 text

まとめ & SREの皆様へのメッセージ何かのプロセスを Enabling するのであれば… • とっつきやすさ • 「とりあえずやってみよう」が生まれやすい仕組みをつくる • 私のケースでは : 事前準備不要・全員初見というお気軽なMTG設計 • 相談しやすさ • 何かあったらすぐに助けてもらえるから大丈夫、という安心感を与える • 私のケースでは : 「チャットでの盛り上げや相づち」による「ワイガヤ」感＆毎週MTGする中でわかったSREの相談しやすい人柄 43

Slide 44

Slide 44 text

最後に「セッション全体のまとめ」です

Slide 45

Slide 45 text

SREじゃなかった僕らが「SRE実践者」になれたのはまとめのまとめ SREによる丁寧なEnablingプロセスがあったから！ • 対話しやすい関係性の構築 o 1on1 、称え合う文化、話しかけやすい雰囲気 • 実践的な学習機会の提供 o ペアプロ、モブワーク、丁寧なレビュー • とっつきやすい仕組みづくり o 全員初見、事前準備不要、刻んだタスク続きはB1Fホワイエ・イオンブースで。「うちの組織だと…」「具体的にはどうやって…？」などお話しましょう！お待ちしてます。 45

Slide 46

Slide 46 text

46 46