ロールが細分化された組織でSREと協働するインフラエンジニアは何をするか？ / SRE Lounge #18

2025年8月5日に開催された「SRE Lounge #18」の登壇資料です。
https://sre-lounge.connpass.com/event/362882/

▼関連資料
ロールが細分化された組織でSREは何をするか？ - Speaker Deck, https://speakerdeck.com/tgidgd/rorugaxi-fen-hua-saretazu-zhi-desrehahe-wosuruka

---
KINTOテクノロジーズのSNS

▼KINTO Tech Blog | キントテックブログ
https://blog.kinto-technologies.com/

▼KINTOテクノロジーズ【公式】
https://x.com/KintoTech_Dev

Transcript

1. ロールが細分化された組織で SREと協働するインフラエンジニアは 何をするか？ KINTOテクノロジーズ株式会社 プラットフォーム開発部 古代 吉
2. 古代 吉 / KOSHIRO Hajime a.k.a. こっしー プラットフォーム開発部 シニアクラウドエンジニア 自己紹介 2 :X: @kodai1_jp
3. トヨタ自動車株式会社 トヨタファイナンシャルサービス株式会社（TFS） 海外販売金融 現地事業会社 世界40以上の国と地域で サービスを展開 KINTOテクノロジーズ 株式会社 株式会社KINTO トヨタファイナンス 株式会社 販売金融・クレジット カードなど KINTOテクノロジーズ株式会社について（グループ組織） 3
4. KINTOテクノロジーズが関わっているプロダクト 4
5. SRE NEXT 2025 に参加した人 5
6. KINTOテクノロジーズの長内の 発表を聞いた人 6
7. SREという組織に所属してない人 SREという役割ではない人 7
8. ロールが細分化された組織で SREと協働するインフラエンジニアは 何をするか？ 8
9. インフラエンジニアは サービスの信頼性を維持向上するために 何をしているか 9
10. SRE NEXT 2025 でのKTC長内からの発表内容 大きなプラットフォーム組織の中の少人数のSREsとしての悩みと経験、取り組みを共有した 引用: ロールが細分化された組織でSREは何をするか？ - Speaker Deck, https://speakerdeck.com/tgidgd/rorugaxi-fen-hua-saretazu-zhi-desrehahe-wosuruka 10
11. 多くの開発チームと一つのプラットフォーム組織 Platform Team Application Team Account Network Computing Managed Service Platform Product Security Service A Service Z 80 SID 4-10 Envs x すべてのプロダクトのインフラを１つの組織で一括管理しているため、バックアップなど非機能に ついての責任範囲も広い。 11
12. セキュリティ組織 プラットフォーム開発部 開発組織を支援する充実したチーム体制 計30名以上 (/約400名) の体制でプラットフォーム領域を一括でサポート QA Cloud Infrastructure SRE, DBRE Managed Service Provider(MSP) Platform Engineering Security Operation SCoE A プロダクトシリーズ B プロダクトシリーズ C プロダクト X プロダクト サービス サービス サービス サービス サービス サービス サービス 12
13. Service Reliability Hierarchy で見る各チームの業務内容 UX 開発 キャパシティ・スケール テスト／リリース インシデントレスポンス インシデント後のレビュー 監視／オブザーバビリティ 引用 図14-1：Dickersonの信頼性の階層構造を若干修正したもの, 14.1 Dickersonの信頼性の階層構造, SREをはじめよう ー個人と組織による信頼性獲得への第一歩 p.198 SRE Cloud Infra Platform Engineer ー ー ー △ ー ー △ ◯ △ ◯ △ ◯ ◯ ◯ △ ◯ ◎ △ ◯ ◯ ◎ Dickersonの信頼性の階層構造の下層を中心にプラクティスを SREing と意識せず実行している 13
14. 14 大きなプラットフォーム組織はユーザーとの距離が遠い 一般ユーザー 業務システム ユーザー 開発チーム プラットフォーム組織 カスタマーサポート プロダクトオーナー 1 ホップ 2ホップ 3ホップ ユーザーからの距離が遠いほど、信頼性や価値提供との向き合い方が難しくなる
15. 15 大きなプラットフォーム組織はユーザーとの距離が遠い 一般ユーザー 業務システム ユーザー 開発チーム プラットフォーム組織 カスタマーサポート プロダクトオーナー 1 ホップ 2ホップ 3ホップ ユーザーからの距離が遠いほど、信頼性や価値提供との向き合い方が難しくなる 顧客の声が届きづらい 直接価値を提供できない
16. 16 大きなプラットフォーム組織はユーザーとの距離が遠い 一般ユーザー 業務システム ユーザー 開発チーム プラットフォーム組織 カスタマーサポート プロダクトオーナー 1 ホップ 2ホップ 3ホップ ユーザーからの距離が遠いほど、信頼性や価値提供との向き合い方が難しくなる 顧客の声が届きづらい 直接価値を提供できない 内部顧客への価値提供
17. 17 大きなプラットフォーム組織はユーザーとの距離が遠い 一般ユーザー 業務システム ユーザー 開発チーム プラットフォーム組織 カスタマーサポート プロダクトオーナー 1 ホップ 2ホップ 3ホップ ユーザーからの距離が遠いほど、信頼性や価値提供との向き合い方が難しくなる 顧客の声が届きづらい 直接価値を提供できない 内部顧客への価値提供 「SREのプラクティスは実践してるようだが、 ユーザーへの価値提供には繋がっているのか…？🫠 」 （信頼性の維持向上）
18. KTCでは開発チームのEnablingがSREsの最初の役割 18 引用: ロールが細分化された組織でSREは何をするか？ - Speaker Deck, https://speakerdeck.com/tgidgd/rorugaxi-fen-hua-saretazu-zhi-desrehahe-wosuruka プラットフォームとプロダクトの溝を埋めつつ、更にその先のサービスレベル設計へ
19. インフラエンジニアは サービスの信頼性を維持向上することに 貢献できているのか？ 19
20. SRE、DevOps、アジャイル戦略の関係性 20 引用 図1-2: SRE、DevOps、アジャイル戦略のLimoncelliモデル。『SREの探求』（2018年、O’Reilly）の原文を改変。, 1.3.3 パート3：注目の方向がすべて, SREをはじめよう ー個人と組織による信頼性獲得への第一歩 p.198 SREは本番環境の運用からSDLCパイプラインを遡る視点で改善を行う
21. SRE、DevOps、アジャイル戦略の関係性 21 引用 図1-2: SRE、DevOps、アジャイル戦略のLimoncelliモデル。『SREの探求』（2018年、O’Reilly）の原文を改変。, 1.3.3 パート3：注目の方向がすべて, SREをはじめよう ー個人と組織による信頼性獲得への第一歩 p.198 SREは本番環境の運用からSDLCパイプラインを遡る視点で改善を行う 関心事の方向性の違いは分かるが、 ソフトウェア以外の部分が分かりづらい
22. ST, 個別テス ト テスト計画・準備 移行計画・準備 System Life Cycle から見たアジャイル、DevOps、SRE 22 構想 企画 要件 定義 アーキ テクチ ャ設計 ソフトウェア 設計 インフラ 設計 実装 UT 構築 IT1-2 IT3 運用設計 運用準備 リ リ ー ス 業務運用 ソフトウェア 保守 基盤運用 機能拡張 プロジェクト管理 統制・標準化 アジャイル SRE DevOps システム運用保守 運用管理
23. ST, 個別テス ト テスト計画・準備 移行計画・準備 System Life Cycle から見たアジャイル、DevOps、SRE 23 構想 企画 要件 定義 アーキ テクチ ャ設計 ソフトウェア 設計 インフラ 設計 実装 UT 構築 IT1-2 IT3 運用設計 運用準備 リ リ ー ス 業務運用 ソフトウェア 保守 基盤運用 機能拡張 プロジェクト管理 統制・標準化 アジャイル SRE DevOps システム運用保守 運用管理
24. SREが「実際には何をするのか」 24 1. インシデント／障害モード 2. インシデント後の学習モード 3. ビルダー／プロジェクト／学習モード 4. アーキテクチャモード 5. 管理モード 6. 計画モード 7. コラボレーションモード 8. 回復とセルフケアモード 「SREの一日のモード」を見ると、インフラエンジニアにも馴染みのあるモードがある 参考 8章 SREのある一日, SREをはじめよう ー個人と組織による信頼性獲得への第一歩
25. ST, 個別テス ト テスト計画・準備 移行計画・準備 System Life Cycle から見たアジャイル、DevOps、SRE 25 構想 企画 要件 定義 アーキ テクチ ャ設計 ソフトウェア 設計 インフラ 設計 実装 UT 構築 IT1-2 IT3 運用設計 運用準備 リ リ ー ス 業務運用 ソフトウェア 保守 基盤運用 機能拡張 プロジェクト管理 統制・標準化 アジャイル SRE DevOps システム運用保守 運用管理
26. ST, 個別テス ト テスト計画・準備 移行計画・準備 System Life Cycle から見たアジャイル、DevOps、SRE 26 構想 企画 要件 定義 アーキ テクチ ャ設計 ソフトウェア 設計 インフラ 設計 実装 UT 構築 IT1-2 IT3 運用設計 運用準備 リ リ ー ス 業務運用 ソフトウェア 保守 基盤運用 機能拡張 プロジェクト管理 統制・標準化 アジャイル SRE DevOps システム運用保守 運用管理 インシデント／障害モード
27. ST, 個別テス ト テスト計画・準備 移行計画・準備 System Life Cycle から見たアジャイル、DevOps、SRE 27 構想 企画 要件 定義 アーキ テクチ ャ設計 ソフトウェア 設計 インフラ 設計 実装 UT 構築 IT1-2 IT3 運用設計 運用準備 リ リ ー ス 業務運用 ソフトウェア 保守 基盤運用 機能拡張 プロジェクト管理 統制・標準化 アジャイル SRE DevOps システム運用保守 運用管理 インシデント後の学習モード
28. ST, 個別テス ト テスト計画・準備 移行計画・準備 System Life Cycle から見たアジャイル、DevOps、SRE 28 構想 企画 要件 定義 アーキ テクチ ャ設計 ソフトウェア 設計 インフラ 設計 実装 UT 構築 IT1-2 IT3 運用設計 運用準備 リ リ ー ス 業務運用 ソフトウェア 保守 基盤運用 機能拡張 プロジェクト管理 統制・標準化 アジャイル SRE DevOps システム運用保守 運用管理 ビルダーモード
29. ST, 個別テス ト テスト計画・準備 移行計画・準備 System Life Cycle から見たアジャイル、DevOps、SRE 29 構想 企画 要件 定義 アーキ テクチ ャ設計 ソフトウェア 設計 インフラ 設計 実装 UT 構築 IT1-2 IT3 運用設計 運用準備 リ リ ー ス 業務運用 ソフトウェア 保守 基盤運用 機能拡張 プロジェクト管理 統制・標準化 アジャイル SRE DevOps システム運用保守 運用管理 アーキテクチャモード
30. インフラエンジニアも 信頼性への取り組みを実践できている 30
31. KINTOテクノロジーズでの実践例 31
32. ST, 個別テス ト テスト計画・準備 移行計画・準備 System Life Cycle から見たアジャイル、DevOps、SRE 32 構想 企画 要件 定義 アーキ テクチ ャ設計 ソフトウェア 設計 インフラ 設計 実装 UT 構築 IT1-2 IT3 運用設計 運用準備 リ リ ー ス 業務運用 ソフトウェア 保守 基盤運用 機能拡張 プロジェクト管理 統制・標準化 アジャイル SRE DevOps システム運用保守 運用管理 アーキテクチャモード 基盤運用 インシデント／障害モード 運用管理 インシデント後の学習モード インフラ 設計 構築 ビルダーモード
33. 業界標準やグループ会社の定める厳しい基準 33 プラットフォームで実現すべき多くの基準やルールが存在する 分類 内容 主な要素 一般的なもの （業界共通の基準） 業界全体で広く共有されて いる品質基準や技術的標準 非機能要求グレード ・性能、可用性、保守性、セキュリティ 品質標準 信頼性、拡張性、保守性、移植性など 会社レベルのもの （組織方針・統制） 自社で定めた開発・品質に 関する方針や統制ルール 会社の方針 ・品質重視、顧客満足、継続的改善 ルール・ガイドライン ・セキュリティポリシー、情報管理、標準化方針 チームレベルのもの チーム内で共有する開発の 進め方や技術運用 インフラ運用標準 ・監視設定、ログ収集、アクセス権管理 ・環境構築手順、構成管理（IaC） プロジェクトごとのもの （個別ルール） プロジェクト固有のルール や制約事項 プロジェクト固有のインフラ設定 ・環境構成（開発・本番） ・クラウド設定（VPC、セキュリティグループ） ・バックアップ・DR設計、コスト管理、ネットワーク構成
34. どんなシステム構成をしているでしょう？ - 1 34 コーポレートサイト 一般ユーザー 業務ユーザー 開発者 運用担当者
35. どんなシステム構成をしているでしょう？ - 2 35 登録済みユーザー向けWebシステム 一般ユーザー 業務ユーザー 開発者 運用担当者
36. どんなシステム構成をしているでしょう？ - 3 36 社外向け業務支援システム 一般ユーザー 業務ユーザー 開発者 運用担当者
37. どんなシステム構成をしているでしょう？ - 4 37 基幹業務管理システム 一般ユーザー 業務ユーザー 開発者 運用担当者
38. サービスの共通項を発見し 組織の基準を満たすサービスを 速く簡単に構築する 38
39. 「早期エンゲージメントモデル」 「プロダクションサービスのためのフレームワーク」 39 32章 進化するSREのエンゲージメントモデル, SRE サイトリライアビリティエンジニア リング ―Googleの信頼性を支えるエンジニアリングチーム より
40. ヒアリングシートでシステム要求を漏れなく確認 40 IaC code Parameter Pack module IaC code Parameter IaC code Parameter 開発者 開発者 開発者 ヒアリング シート ヒアリング シート ヒアリング シート 実装 実装 実装 システム設計の早い段階でIaCコードと対応するヒアリングシートを使ったアーキテクチャの設計
41. フレームワーク化したIaC と Product as a Platform 41 IaC code Parameter Pack module IaC code Parameter IaC code Parameter Network Account Product as a Platform Service Service Service Service Service Service Provisioning 組織の基準を満たすシステムを素早く構築し、プラットフォームサービスも利用可能にする 参考: [Japanese] Terraformを抽象化し環境構築の工数を削減する取り組みについて – YouTube, https://youtu.be/4h_0B0QYo2g
42. インフラエンジニアは 組織基準と複数プロダクトを横断する視点から システムの信頼性の維持向上にアプローチする 42
43. We are hiring! KINTOテクノロジーズでは、一緒に 働く仲間を募集しています！ ＫＩＮＴＯテクノロジーズ株式会社 クラウドエンジニア の求人一覧, https://hrmos.co/pages/kinto-technologies/jobs?category=2037393016523087872
44. Thanks ;)