あなたの興味は信頼性？それとも生産性？ SREとしてのキャリアに悩むみなさまに伝えたい選択肢

SRE Kaigi 2025で発表した資料です

1. あなたの興味は信頼性？ それとも生産性？ SREとしてのキャリアに悩む みなさまに伝えたい選択肢
2. Kazuto Kusama @jacopen Product Evangelist @PagerDuty Japan Organizer @Platform Engineering Meetup Founder @Cloud Native Innovators Association Organizer @SRE Kaigi
3. Platform Engineering推進の団体をやっています 一般社団法人 クラウドネイティブイノベーターズ協会 Platform Engineering Meetup
4. 質問 SREで居続けるの 難しくないですか？
5. SREが登場してから22年 GoogleでSREが提唱されたのが2003年(!) オライリーからSite Reliability Engineeringが出版 されたのが2016年。 日本語版は2017年の8月 これ以降、日本でも採用する事例が増えてきた
6. どうしてSREが必要とされたんだろう そのほうがかっこいいから システムの複雑化 安定性に対する要求 クラウド化(による自動化の余地) ベストプラクティスの導入
7. どうしてSREが必要とされたんだろう そのほうがかっこいいから システムの複雑化 →といいつつ、本当にマイクロサービスやってる組織がどのくらいあるのか 安定性に対する要求 →誰に聞いたってそりゃ障害が少なくて安定しているほうがいいって言う クラウド化(による自動化の余地) →ベンダーの後押しもあり自動化に注目があつまった ベストプラクティスの導入 →流行り物に乗った方がいろんな知見を効率よく得られてコスパ・タイパがいい
8. そして生まれるなんちゃってSRE • インフラ運用チームが名前を変えただけ • 開発者数名で始めたスタートアップが 「クラウドと自動化できる便利な人が欲しい」という理由でSREを設置 • 人材募集する際に、人を集めやすいカテゴリにした方がいいからSREを設置 • 大手企業が「新しい取り組みやってます」アピールのため
9. そして生まれるなんちゃってSRE • インフラ運用チームが名前を変えただけ • 開発者数名で始めたスタートアップが 「クラウドと自動化できる便利な人が欲しい」という理由でSREを設置 • 人材募集する際に、人を集めやすいカテゴリにした方がいいからSREを設置 • 大手企業が「新しい取り組みやってます」アピールのため ビジネスの合理性を考えると、必ずしも問題とも言えない でもこういうSREのイベントに来ると、「このままで良いんだろうか･･･」と悩む
10. 今日話したいと思っていること みなさんの悩みをスパっと解決できるものではないです 自分がありたいエンジニア像を描く際の材料を提供する
11. そもそも信頼性って何だっけ？
12. そもそも信頼性って何だっけ？ • SLO • SLI • MTTR • MTBF • …
13. 信頼性を上げる最も効率のいい方法
14. なにもしないこと
15. 何かするから障害がおきる “障害のほとんどはデプロイによって引き起こされる。 したがって、デプロイが増えると障害も増え、結果と してインシデント管理、軽減策、ポストモーテムが必 要となる” エレガントパズル　エンジニアのマネジメントという難問にあなたはどう立ち向かうの か より引用 言い方を変えると、デプロイをしなければ障害は減る
16. だからデプロイ減らしましょ ･･･とはならない (よね？) 今の世の中勝ち残るには、素早く開発して素早く市場に投入するという取り組み が必須。だからこそ、アジャイル開発やDevOpsが必要とされる でもそれだとインシデントが増えるので、SREが必要となる アジャイルもやってないしDevOpsも形だけ。リリース頻度変わってないのに SREとか言い始めると、「なんちゃってSRE」の可能性がとても高い。 おそらくあなたに求められるのは、信頼性向上ではなく クラウドが出来る便利屋さん 注: こうは書いてますけど、「便利屋さん上等！オレがなんとかしてやる」と いう意気込みでいるのは全然アリだとおもいます。ここで言いたいのは、前段 のアジャイルやDevOpsがろくに回ってないのに、形だけSREやっても意味が 無いので、もっと先にやるべきことがあるよね、ということです
17. Four Keys • デプロイの頻度 ◦ 変更を本番環境にデプロイ、あるいはエンドユーザーにリリースした頻度 • 変更のリードタイム ◦ 変更のコミットから、本番環境で正常に実行されるまでの時間 • 変更失敗率 ◦ デプロイによって本番環境で障害が発生する割合 • デプロイ失敗時の復元までの時間 ◦ 本番環境での障害から復元までにかかる時間 Four Keysがよく取り上げられますが、大きく分けると上下 2つに分けられます。上だけ高める、下だけ高めるのは難し くない。全部高めるのが大事だし、チャレンジングな点
18. SREの探求 より引用
19. SREの探求 より引用 Site Reliability Engineer として求められる領域
20. SREの探求 より引用 Site Reliability Engineer として求められる領域 実態
21. SREの探求 より引用 Site Reliability Engineer として求められる領域 実態 ここばっかり やっている人もいる 開発側もなんとかしないといけない、となって、 結局右から左のSREではなく左から右の取り組み まで全部やってるっていう
22. そんな中で出てきたもの Platform Engineering
23. Platform Engineeringとは 開発者体験と生産性を向上させるために セルフサービスで利用できるツールチェーンとワークフローを 設計・構築する分野 定義で言うとこういうのがあります
24. あーあれでしょ 共通基盤作ろうってやつでしょ 大きな会社なら必要あるかもだけど ウチはまだそういう感じじゃないかなー って思う人いるかもしれないので、ちょっと違った表 現をしてみます
25. 真のDevOps 開発者が、アプリをエンドツーエンドでデプロイし、実行する ただし、多くの組織にとって現実的ではない Kubernetes Buildkit Helm Dockerfile Grafana Prometheus GitHub Actions React Next.js Security Node.js Terraform ArgoCD APM Compliance 認知負荷が 高すぎる これをやり切れ る人材は少ない
26. https://www.infoq.com/articles/platform-engineering-primer/ より引用 認知負荷の増大が問題に クラウドの浸透、クラウドネイティブ技術の登場、マイクロサービス化の流れ、 エンジニアの責任範囲の拡大により認知負荷が大変なことに
27. くっそめんどくさい！ 自分もコード書くことありますが、コード書く頭の時 にデプロイのこと考えるのちょう面倒くさい
28. くっそめんどくさい！
29. 認知負荷の増大による生産性の低下が 無視出来なくなりつつある この「くっそめんどくさい」が世界中で起きているの が今
30. じゃあ、どうすればいいのか
31. くっそめんどくさい対策 • 自分で無理に頑張るより、その道のプロにお願いしたい • 全部任せたいけど、難しい場合はせめて相談に乗って欲しい。 適切な情報提供をお願いしたい
32. くっそめんどくさい対策 • 自分で無理に頑張るより、その道のプロにお願いしたい • 全部任せたいけど、難しい場合はせめて相談に乗って欲しい。 適切な情報提供をお願いしたい その道のプロ = Platform Team その道のプロを体系だって作っていく取り組み = Platform Engineering 開発者側からみたPlatform Engineeringの理解は、この程度でいいと思います
33. くっそめんどくさい対策 • 自分で無理に頑張るより、その道のプロにお願いしたい • 全部任せたいけど、難しい場合はせめて相談に乗って欲しい。 適切な情報提供をお願いしたい どうお願いするのか。その任せ方、関わり方 教えを請う？ 手伝って貰う？ それとも･･･
34. Team Topologies 価値のあるソフトウェアを素早く届けられるよ うにするための組織設計。 4タイプのチーム定義と、3つのインタラクショ ンモードが定義されている。
35. 4つのチームタイプ Stream-aligned team ビジネスのストリームに沿って配置するチー ム。ビジネスの中心 Complicated Subsystem team 複雑なサブシステムやコンポーネントを扱う チーム。その分野のスペシャリストが集まる Enabling team 他のチームが新しい技術やスキルを身につける 支援をするチーム ★Platform team インフラやツール、共通サービスなどのプラッ トフォームを提供するチーム
36. 3つのインタラクションモード ファシリテーション 一方のチームが他のチームの障害を取り除くた めに支援をしたり、支援されたりする。同時に 複数のチームと連携することもある コラボレーション 2つのチームが密接に協力して作業する。同時に コラボレーションできるのは1チームまで ★X-as-a-Service 他のチームが提供するものをサービスとして利 用する関係性。責任分界点が明確。疎結合。
37. その道のプロ(= Platform Team)との関わり方 開発チーム その道のプロ 開発チーム その道のプロ Collaboration Facilitating その道のプロが開発チームに勉強会を 開いたり、Slackで情報提供 その道のプロが開発チームにジョインし Manifest書くのを担う 開発チーム その道のプロ XaaS その道のプロが用意したプラットフォームの レールの上で開発
38. その道のプロとの関わり方 開発チーム その道のプロ 開発チーム その道のプロ Collaboration Facilitating その道のプロが開発チームに勉強会を 開いたり、Slackで情報提供 その道のプロが開発チームにジョインし Manifest書くのを担う 開発チーム その道のプロ XaaS その道のプロが用意したプラットフォームの レールの上で開発 最終的にはここを目指す この過程も大事
39. Platform Teamが担うこと • 開発者の認知負荷軽減を一番の目的として取り組む • 開発の助けになるような情報を整理する • あらゆる技術に精通することは難しく、ガバナンスを効かせていく必要もあ るので、Platform Teamは技術の『標準』を定めていく • スムーズに取り組めるようオンボーディングの仕組みをととのえる • 必要に応じて勉強会やワークショップの開催を行う • 開発者からの質問や問い合わせに対して対応する • 開発者がセルフサービスで利用できる、自動化されたプラットフォーム を作っていく
40. 自分のやってることって こっちなのでは？ 🤔 っていう話をすると、いまSREをやっている人も、実 態としてはこっちなんでは？という人もいるかも
41. SREの探求 より引用 SRE Platform Engineering
42. ここで言いたいこと 「SREじゃなくてPlatform Engineeringやれ」とか、 「それはSREって名乗るべきじゃない」とか そういう主張をしたいわけでは全くないです 既に確立されたSREチームがPE的なことをやることもあるだろうし、限られた人 数なので一人で両方を担うみたいなケースも全然あると思います 定義は定義で理解しつつも、実態はうまく調整すれば良いです 僕はそのために商標取ったりしないので安心してください 自分の定義を主張するために商標取るなんて人もいるらしい ですけど、それって不毛なので、定義は定義、実態は実態で うまいこと考えていけばいいんじゃないでしょうか
43. ただ 自分のモチベーションが右から左なのか、左から右なのかは、考えておいたほう がいいです。 そうすることで、適した情報源に当たりやすくなります。 SREの探求 より引用 右から左 SRE 左から右 Platform Engineering
44. deeeetさんとの対談 プラットフォーム開発に関わる人は 「ドラクエでしっかりとスクルトと バイキルトで強化してからボスに望 むのが好きな人」 なんじゃないかという仮説 「プロダクティビティを改善するこ とは、つまり皆を強くすることであ り、みんなで強くなることによっ て、より早くプロダクトを出せるよ うになっていく」 チーム全員の生産性を上げる！ メルカリ deeeetさんに聞く、Platform Engineeringの醍醐味 https://codezine.jp/article/detail/20283
45. こういう人 MMORPGだとバッファータイプ Minecraftでひたすら装置作り
46. 共通するところ • ソフトウェア開発に対する知識、スキル • 自動化・効率化に対するモチベーション • 他チームと連携しながら組織を前進させる • 継続的な改善と学習文化 SRE • 信頼性・可用性への強いコミット • 分析・監視・運用設計の能力 • 障害対応から得た実践的知識 • データドリブンな意思決定 Platform Engineering • プラットフォームの設計・開発における技術力 • ユーザー視点のプロダクト開発マインド • 組織全体、複数サービスを見渡す抽象化・標準 化への意識 繰り返しになりますけど、SREというタイトルでPlatform Engineeringやっていても良いと思います。共通する項目も多 いので。でも、自分がどっちに対してやりがいを感じるかは、 心の中で整理しておくと良いです。
47. 最後に、流行りのアレ
48. AI x (SRE | Platform Engineering) 好む好まざるとに関わらず、AIを活用したSRE / Platform Engineeringの実践は 不可避。 一昨年〜昨年にかけてのRAGを使ったアプローチは上手くいかないケースが多 かった ただ昨年末から盛り上がっているAIエージェントのアプローチは、かなり親和性が 高いように思う(特にPlatform Engineering) 具体的な事例が出てくるのはこれからだが、暖かくなってくる時期から一気に情報 が出てくると思われる
49. AI Driven Development ここ数ヶ月のソフトウェア開発におけるAI Agent の発展がすさまじい 全ての開発が直ちに置き換わるとは思わないが、 全ての開発が「影響を受ける」というのは過言で はない なので、これが開発のメインストリームとなった ときに、SREに求められるのは何か、Platform Engineerに求められるのは何かを早いうちから考 えておくべき まずは自分で触ってみて Cursor composer agent Devin Cline bolt.new いまこの時点では、一定の規模を超えるものを作らせるに は力不足なAIドリブン開発ですが、徐々にやれる規模は広 がるでしょうし、一部のタスクをAIにやらせるというのは 今でも可能。 まずはしゅっと触って感覚を掴むのがお勧め
50. The augmented LLM MCP(Model Context Protocol)や Computer Use, browser-useのように、 LLMと外部がやり取り出来る標準のイン ターフェースが生まれ始めた まずは自社で身近な何かを連携させて仕組み を作ってみるのがおすすめ AnthropicのBuilding effective agentsとい う記事がとてもよく出来ているので、これを 参考にちいさなエージェントを考えてみるの がよさそう https://www.anthropic.com/research/building-eff ective-agents https://www.anthropic.com/research/building-effective-agents より引用
51. まとめ • SREの主目的は「信頼性」 • 認知負荷の削減、開発生産性の向上のための「Platform Engineering」 • SREとPlatform Engineerを明確に分ける必要はないが、自分がどっちを志向 しているのかは理解しておいた方が良い • AIは不可避
52. Platform Engineering Meetup特別回やります！ 2/19に発売 発売に先立って、2/13に発売記念イベントを兼ねた Meetupを開催します! 一週間も早く入手出来る、書籍の先行販売 著者 Mauricio Salatinoさん登壇 & サイン会 翻訳者 nwiizoさん登壇 & サイン会