免責
会社のテックブログに書くと社の代表者としてコメントしているように見えるので、個人ブログに考えをつらつらと書いていく。答えがあるとは限らない。
背景や課題感はやはり社に基づいているため、考えの方向性はそれらに依存している。 ただし、公開できる範囲にしか言及できないためこの記事ですべては賄えないであろうことをご了承いただきたい。
なお、このブログはAIではなく私自身が書いています。
[序文] プロダクトの数が増えると、SREはそれぞれのプロダクトへ平等にリソースを割くのはむずかしい
かつてEmbedded SREとしてSREチームを立ち上げた経緯があるが、対象のプロダクトの数は増え、連携サービスも増え、さらに中長期的な計画も入ってくると、すべての会議に出ることは難しい。結果的に、どうしてもEmbedded SREとして信頼性に関わることが困難になった。
プロダクトチームは、彼ら自身で意思決定をする方が圧倒的にスピードが出る。小規模なチーム構成ならEmbedded SREもしくは他のソフトウェアエンジニアと同じロールで参加した方が好ましいのは、そのような理由のはずだ。 マーガレット・ハミルトンの逸話にあるように、またSRE NEXTの参加資格がそうであるように、サービスの信頼性を制御する上で自認がSREである必要はない。
SREの仕事とは？ - スタディサプリ Product Team Blog
マーガレット・ハミルトン：「アポロ計画」を支えた女性プログラマーの肖像 | WIRED.jp
ではタイトルの、中規模*1以上になるとどんな体制になるか？
- プロダクトの数が増え*2、少人数のSREがすべてのチームにEmbeddedするのは非現実的
- 信頼性の制御は、SREという職種でなくても実施できる
- SREチームは、プロダクトチームが自律的に信頼性の制御をできるような状態をつくれるような体制を目指した方がよいのでは？
と、ごく自然に「プロダクトチームはSREがいなくとも信頼性を制御できる状態にある」ことが最も合理的に思えてくる。
次第にEnabling SREという形式に移り変わり、いわゆる支援型に切り替わった。つまり、プロダクトチームにSREをインストールするような体制である。詳しくは次のリンク先。
そしてこのような体制を目指しても、様々な課題は発生する。
SREは自身のチームの継続性を考慮した負荷軽減とプロダクトチームの自律性を両立するための戦略が必要ではないか
プロダクトチームに対して、「自身で信頼性の制御を可能にしていく体制を整備していく役割を担うSRE」をここではEnabling SREと呼ぶことにしよう*3。
このEnabling SRE体制は、基本的に構成が少人数である。 通常は開発者のほうが多いのが現実であり、それがプロダクトごとに在籍していると考えると正直比率もわからない。
プロダクトチームからの相談や権限都合によるタスクはもちろんのこと、Enabling SREが実施しなければならないロードマップ（中長期的な施策、直近できる信頼性のための活動）も存在している。 優先順位こそあれ、一斉に依頼が来るとリソース限界を感じるものだ。
"Product-Focused Reliability for SRE" について知る
この課題を解決するべく、Googleが公開しているこの内容が、迷える私たちの指針となると思った。
日本語で要約してくれている記事もある。
こちらでも要約すると、Product-Focused Reliability for SREを次のようなことを言っている。
- SREチームが限られたリソースの中で、ビジネスやユーザーにとって最も重要なことに焦点を当て、優先順位を付けて活動するためのもの
- プロダクトとエンドユーザーのニーズに焦点を当てたサポートモデルへと転換する
- これまでのSREの業務（管理対象）は、サービスを中心に考えられている
- 可用性、レイテンシ、パフォーマンス、変更管理、モニタリング、インシデント対応、キャパシティプランニングなど
- インフラや、そのサービスそのものを焦点になっている
- これまでの方法だと、ユーザニーズやビジネス目標を部分的解決しかできていない
- サービスの信頼性測定は、プロダクト全体のエンドユーザー体験とギャップがどうしても発生する
- サービスはどんどん成長するので、エンジニアリング組織の成長を容易に上回る。結果、サービスが放置されたりチームが過負荷に陥る
- SREは、機能とユーザーアウトカムの集合体を担当するように変更
- ビジネスとユーザーアウトカムに合わせて優先順位を調整。サービススタックのあらゆるレイヤーにおいて、より広範かつ影響力のある取り組みに取り組む
- 「ユーザーとビジネスにとって最も重要なこと」に焦点を当てるために、「プロダクトサポートモデル」という新しいアプローチを採用した
- このモデルでは、SREチームはサービスの稼働率だけでなく、製品全体の重要な機能の信頼性に対して責任を負う
つまり、サービスのメトリクスだけを追いかけていると、ユーザは無関心である部分に時間を使っていたり、反対に不満を見落とす可能性があるということだ。
SREの「プロダクト」中心と「サービス」中心の違いについて考える
先の記事では、「SREの業務はサービス中心に考えられている」ため「ユーザニーズやビジネス目標を部分的解決しかできていない」という課題に言及されていた。
文言の中で「サービス」「プロダクト」とで言い回しに差があることに気づく。
私はプロダクトSREとして、プロダクトについて考えてきたと思ってきた。プロダクト固有の問題解決を担当してきたからだ。
しかし、GoogleのProduct-Focused Reliability for SREの定義においては、そうではないようだ。私は最初、この違いがよくわからなかったが、考えていくうちになるほどなと思った。
| 項目 | サービス中心 SRE | プロダクト中心 SRE |
|---|---|---|
| イメージ | これまで私たちが培ってきたSRE実践の考え方 | システムより先に、ビジネスサイドが関係してくる考え方 |
| 焦点 | 個々のシステム、インフラ、サービスの安定稼働 | プロダクト全体の重要な機能、ユーザー体験、ビジネス目標 |
| メトリクス | 可用性、レイテンシ、パフォーマンス、エラー率など（技術的指標） | ユーザーが期待する機能の成功率、ユーザー満足度、プロダクトのKPI（ビジネス指標） |
| SLO設定 | サービス単位（例: API応答時間99.9%） | ユーザー目標の文脈（例: メール検索の成功率99%） |
| プラクティス | 変更管理、モニタリング、インシデント対応、キャパシティプランニング | ステークホルダーとの協議、プロダクトモデリング、SLOによる優先順位付け |
| 評価軸 | システムの安定性、パフォーマンス、開発速度 | ユーザーの満足度、プロダクトが持つKPIの達成度、ビジネス成果 |
| ポイント | 開発速度と信頼性のバランス、エラーバジェット活用、継続的改善 | エンドユーザーの理解、SLOはプロダクトの機能ステップベース、ビジネス成果との組み合わせ |
| 具体例 | 「AddressLookupサービスはどれくらい信頼性が高く、高速であるべきか？」 | 「ユーザーがメールアドレスを検索する際に、どれくらいの数のエラーを許容できるか、そしてどれくらいの速さでメールアドレスが返されるべきか？」 |
プロダクト中心で考えた時、私たちの議論の起点はシステム（サービス）ではなく、プロダクトそのものになるはず。よって、次のような図で表現してみる。
graph TD
subgraph Product-Centric Approach
PdM[PdM] --> A
Designer[Designer] --> A
Dev[Development] --> A
CS[CS] --> A
A[Product Requirements] --> B(Business Goals)
end
subgraph Reliability Control
B --> C[Define Metrics]
C --> D[SLO Setting]
C --> E[Error Budget Management]
D --> F[Monitoring]
E --> G[Change Management]
F --> H[Improvement Activities]
G --> H
H --> C
H -- Feedback --> E
end
サービス中心の考え方をすべて破棄するという意味ではないと思うし、これまでの方法が間違っていたとも思わない。
我々が持つ有限のリソースをどこに振り分けるか。
ユーザへ適切に価値を届けるために、大きくなってきた組織が取る体制が、「プロダクト」中心ではなのかもしれない。
方針
さてここまでの序文を踏まえつつ、次のことを考えてみた。
- SREがより重要な信頼性に集中するための体制をつくる
- 優先度順位付け可能な状況をつくる
- 優先度をつけるための基準をつくる
- SLOをその根拠として利用できること
- SLOが判断材料として存在できるだけの、高い精度で維持できること
- 関係者と合意が形成されていること
- 優先度をつけるための基準をつくる
- 優先度順位付け可能な状況をつくる
- 「プロダクト」中心の考え方に変え、SREの存在価値がより高い状態をつくる
- システムのことだけに責任を持っている状態をやめ、プロダクトそのものについてSREも理解できていること
- プロダクトチームはこの考えを理解できており、SREもプロダクトチームの事情を理解できている状態をつくる
なんだか書いていて目標設定みたいになってきたが、目指したい状態としてはこのようなものだ。
SLOについて考える
SLOはもはやバズワードな立ち位置になってきているので、あまりこのワードを連呼すると余計な混乱を招きそうで怖い。私自身も考えすぎてわからなくなる時がある。
我、SREといふ概念、もうナニモワカラナイ
— oʎЯꓕɅ (@3s_hv) 2025年5月23日
通称SLO本（以下リンクの本）には、SLOについて次のように記載がある。
- 1.2.2 サービスレベル目標→つまりSLOとは、障害を起こしても許容される頻度の目標値であり、あるいは正常に動作していなくてもユーザーが重大な混乱に陥らないと保証する目標値です。 p9
- （中略）SLOが目標であることを再度確認しましょう。それらは、契約上の合意ではありません。それらはあくまで目標値なので、自由に変更したり更新したりできます。
- 1.4.1 SLOは単なるデータである→SLOは、あなたを導く指針になりますが、あなたに何かを要求することはありません。 p15
- 1.4.2 SLOはプロセスでありプロジェクトではない→SLOを、四半期のロードマップOKRを掲げ、期末には「解決済み」のチェックを入れられるようなものだと捉えるのは、よく持たれる誤解です。 p15
- 13.38 SLOが十分に適切になった時を判断する→SLOはプロジェクトではありません。したがって、「十分に適切である」状態には達しません。とはいえ、最終的にSLOは、サービスがユーザーを満足させるだけの十分な信頼性を確立する地点まで導いてくれます。p309
このように書かれているくらいには、SLOの扱いは難しい。
サービスはどんどん変化し、システムに求められる要求も規模によって変わってくる。 その前提があったとき、「SLOを設定した後に一度も変更していない」「ずっと99.99%を達成中。信頼性ヨシ！」という状況に、全く疑問を抱かずにいられるだろうか。
先に言及したProduct-Focused Reliability for SREの記事内では、実装コストが高くより正確なSLOとそうでないSLOを設定することで、SLOの中に優先度を設定する話がある。
しかし、「その優先度付け自体が難しい」と言われている通り、「どういう基準で優先するか」を決められるレベルのSLOが存在している必要がある。
SLOを開発と運用のバランス取りとしての意思決定に使うために、ポリシーに合意していきたい（する）
SLOに問題がないとき、つまりエラーバジェットに予算があるときは、どんどんリリースをしていきたい。
一方で、エラーバジェットが枯渇したのであれば、各チームは信頼性の回復に務めるべきだろう。
一件シンプルな話のはずだが、これが中々できないのが現実である。
中規模以上の組織で、SLOを意思決定に使えるようにしたいとき、どうすればいいのだろうか。
「リリース止めて〜」という鶴の一声で、数え切れないほどの関係者を巻き込めるのは、SLOではなくSLAが危険なときくらいかもしれない。
……おや、なぜSLAなら大手を振って周りを巻き込めると思ったのだろうか？
ユーザとの契約だからだ。明確な取り決めがそこにある。
となると、やはり「取り決め」が重要なのだ。妥協のないエラーバジェットポリシーが、内部組織の約束ごとになれる。
開発とSREで合意するだけでなく、もっと広範囲のポリシー。
そのポリシーをつくるとき、0-100みたいな内容にはしないほうがいいだろう。
例えば、
- エラーバジェット消費ポリシー
- エラーバジェット超過ポリシー
のように段階を踏んだもの（これはSLO本にも記述がある）。
これを真面目に運用するしかないのかもしれない。真面目にと書いたのは、決めただけで使わないだとか、やっぱルール厳しすぎて例外ばっかりになっちゃったからやってないとか、そういうことをしないように務めるということだ。
決めただけで使わなくなってしまった理由を掘り下げたり、ルールが厳しいなら段階的に設定するなどして、エラーバジェットポリシーを諦めてはいけない。
中規模以上の組織になるとステークホルダーが非常に多い。文書がなければ多くの人を巻き込むのが難しいのが現実。そして文書化すれば当然、例外に対する定義や多くの条件分岐も記載しなければならなくなる。これが嫌で、下手に明文化したくないと思うときもある（柔軟性に欠ける）。
だが諦めてはいけない、柔軟性とポリシーを同時に維持できる解決方法を探していくしかない。
Product-Focused Reliabilityの観点から、SLOの責任者を開発とSREとで分担したい
複数のSLOを設定し、そのSLOの中で優先順位を設定する。
そのうち、最も重要で影響力のあるSLOをSREが責任を持つ。一方でこれまで管理してきたサービス系のSLOをプロダクトチームが責任を持つ。
これにより、次のようなメリットが互いに発生する。
プロダクトチーム
- 本番変更時のコミュニケーションコストの削減（SREへの依頼オーバーヘッド）
- これまでSREが担当していた範囲について知ることで、新たな成長機会を持てる
- SLO Review
- Monitirong
- Infrastructure
- リリース作業、メンテナンス作業
SRE
- 複数のプロダクトチームからの依頼ごとが減り、チームが持てる時間が増える
- アプリケーション側にも関われることで、新たな成長機会を持てる（Enabling SREはどうしてもドキュメント執筆といった支援系のタスクが増えがち）
- システムそのものだけでなく、ドメイン知識やプロダクトが目指すものといったビジネスサイドへの意識を持てる
つまり、責任範囲を「アプリケーション」「インフラ」のような分け方をするのではなく「この機能（SLO）はプロダクトチーム」「この機能（SLO）はSRE 」という具合に分けることで、互いの成長機会や相互理解の機会を奪わずに同じ目的を目指せるのではないかと思っている。
Q. プロダクトチームが最も重要で影響力のあるSLOに責任を持ったほうが良いのでは？逆じゃないの？
最終的には、そのようになることが良いと思う。プロダクトに最も近い組織が信頼性を担保することが一番の理想形だと思う。
しかしながら、それが現実として難しいためSREというロールと組織があると思っている。もしそれが実現したときは、SREチームは解散したい。
先述した通り、SREもプロダクト中心に考えて活動するならば、最も重要なSLOはSREが担った方が良いと考えている。
あるサービスにとって最大重要機能について最後の砦になるイメージ。これならSREが担当することへの違和感はない。
SREが最も重要なSLOに責任を持つという状態をひっくり返し、プロダクトチームが最も重要なSLOに責任を持つようになるには、いくつか条件があるだろう。
- "本番環境"に対して最も知識があるのは
プロダクトチーム >= SREという式が成り立つ - 自律的にサービス運用や信頼性制御が可能となっている
- わかりやすいいくつかの例
- SLOが定期的に改善されている
- エラーバジェットが運用されている
- Postmortemが執筆されている
- キャパシティプランニングのようなインフラ計画に関連するタスクも委譲されている
- リリース作業、メンテナンス作業を完全に委譲されている
- わかりやすいいくつかの例
SREが最も重要な信頼性に対してコミットするという点では、（個人的に）プロダクトチームではなくSREが責任を持つことに違和感はない。
ユーザの声を最も聞いているチームと定期的に意見を交換したい
SLOに優先度をつけるとなれば、より精度高める必要が出てくる。現実とSLOのズレを感じているなら、これをなるべく減らしたい。
- プロダクトチームがプロダクトのことを一番よく知っている
- SREが本番環境のことを一番よく知っている
では、ユーザのことを最も知っているのは誰か。
私の組織においては、カスタマーサクセスとカスタマーサポートである（あるいはセールスも組織によっては）。私たちが見えていない声を無数に持っているはずだ。
彼らから聞いた内容とSLOにズレはないか。そこから見落としているメトリクスはなかったか。
プロダクトチームやSREはどうしても目の前にシステムがあるせいで、先の「サービス」中心の思考になりやすい。意識してなければ避けられない気がしている。
「プロダクト」中心に切り替えるためにも、定期的にユーザの声を取り入れる。そうすることで、サービスに起きるすべてのことが自分ごとになれた時、ようやく私たちが見えている世界が変わるかもしれない。
ビジネスチームの情報をどう取り入れるのか
正直答えがあるわけではないので、ここは期待して読まなくてよい。
のだが、今ところビジネスKPIをそのままSLOにすることは難しいとは思っている。仮にChurn rateが指標にあったとしても、それをそのままSLOにはできないということである。
Churn rate をもしベースにするなら、Churnになった原因を元に検討すべきだ。
また、ビジネスチームから意見を聞くことで意外な回答が返ってくることがあった。まだヒアリングしていないのであれば、ぜひ一度その機会を設けよう。
もし、ビジネスチームの肌感で「システム不具合起因で解約はあまりないんですよ」なんて返ってきたら、あなたはどうするだろう？
「もしかしてSLOこんなに高くなくてよくない？もっと機能開発にチャレンジしてよくない？」と思うかもしれない。そしてその意思決定がビジネスに良い影響を与えるなら、SREとしてあるべき姿になるはずだ。
Enabling体制について考える
SLOの方針を示したところで、どうしても避けられない問題がある。
仮にSLOを分担するとしても「これまでSREが持っていた作業をいきなり委譲することは現実的ではない」ということだ。
SREなしでの運用に懸念はあるかというサーベイをすると、各所のツール利用方法や本番環境に対する不安は多く見られる。
仮に自分がその立場だとして、ひとつの専門部隊ができるような内容をいきなり渡されたら恐怖でしかない。明日からよろしくねとは行かない。壊しても自分で責任を取れない。
ということは私たちは同時に、次のことが求められる。
- プロダクトチームにこの考え方を理解してもらう
- 知識やスキルのアップデートをしてもらう
してもらってばかりで正直本当に申し訳なくなる。彼らの負担が増えるようなことは本望ではないため、どのように伝えるかというのも頭を悩ませる。それはここでは触れないでおくが、やはり何かを大きく変えるためにはじっくり相手の状況を見ながら進めるしかないだろう。
また、SLOを分担するので、完全自立型を目指すという方向性からもやや外れてくる（Enablingチームであれば分担せずにプロダクトチームに委譲する方針を取るはずだ）。
Enabling体制といいつつ、現実は完全自立型を目指しながら、ハイブリットな体制になる。
知識やスキルのアップデート
この課題は、工夫は必要だと思う一方で、生成AI技術の進歩で以前よりもなんとかなりそうな肌感がある。
運用に必要なソースとなる情報をとにかく集めて、適切な回答を生成できればSREがいなくとも一次回答や相談は可能だ。
あるいはハンズオンや定期的な勉強会など、いにしえから伝わるスタイルも試してみる価値がある。今やきっかけさえあれば、学ぶハードルは下がっていると思う。
方針のまとめ
今一度、最初の方針を見てみる。それぞれどのアプローチであるかマッピングしてみた。
- SREがより重要な信頼性に集中するための体制をつくる
- 優先度順位付け可能な状況をつくる
- 優先度をつけるための基準をつくる → SLOを開発と運用のバランス取りとしての意思決定, SLOの責任者を開発とSREとで分担
- SLOをその根拠として利用できること
- SLOが判断材料として存在できるだけの、高い精度で維持できること
- 関係者と合意が形成されていること
- 優先度をつけるための基準をつくる → SLOを開発と運用のバランス取りとしての意思決定, SLOの責任者を開発とSREとで分担
- 優先度順位付け可能な状況をつくる
- 「プロダクト」中心の考え方に変え、SREの存在価値がより高い状態をつくる → SLOの責任者を開発とSREとで分担, ユーザの声を最も聞いているチームと定期的に意見を交換
- システムのことだけに責任を持っている状態をやめ、プロダクトそのものについてSREも理解できていること
- プロダクトチームはこの考えを理解できており、SREもプロダクトチームの事情を理解できている状態をつくる → Enabling体制について考える
さて、ここまでの長文を読んでくれる人はいたのだろうか。
どうあれ、この個人的なまとめが実現できるように精進していきたい。
以下はまとめる上で色々考えてきたものをメモとして置いておく。
Appendix
ここまでの内容をつらつらとまとめるまでに出てきた疑問や自問自答した内容を、付録として残しておく。
「なんでこれ不採用なんだっけ」というときに読み返したい。
開発側のKPIとすり合わせることでSLOは進化するか？
SLOがSREとDevにとって重要な指標（意思決定のソース）として取り扱えるようになれば、SREとDevはもっと良いプロダクトを提供できると信じている。 しかし、現実は合意形成のスコープもあり極めて難易度が高い。
いわゆる「不具合報告の数」というKPIをSLOに対応させられるか？
一つの例として「ユーザからの不具合報告の数」という指標は、ビジネスインパクトを考えると少ないに越したことはない。ではSLOとして表現するべきなんだろうか？
不具合報告の数を計算し、その数が減っていればユーザの満足度として扱う？ということになるが、次のことを踏まえるとそれは難しいなと思っている。
- ユーザが不満をすべて報告しているはずがない（無自覚に感じている不満も含む）
- 報告された内容が重要度と関連しているとは限らない（クライアントサイドの問題が起票されるなど）
しかし、SLOの検討する上では重要かもしれない。ユーザが起票してくれた内容を分類し、CUJで特定された処理の一部があればSLOを見直すきっかけにできるかもしれない。
どのステップ（処理）に関するものなのかを特定すれば、E2EなSLOを作成するときに役に立つだろう。 問題が起きやすい箇所のSLIを持つことで、SREとDevは目で見える形で捉えられるようになる。
ということは、不具合報告を元にしたSLOが作成されてもおかしくはない。むしろDevは、SREよりも強い動機を持ってそれらのSLOを管理できるかもしれない。
本当に重要なSLOを死守するために、SREが能動的にサービスに関わる時間を確保したい
軽微な変更依頼をSREが受け取り続ける場合、そこに時間を取られすぎてしまう。 サービスのために時間を使っていたら、サービスのために使う時間が減っているという矛盾が発生することがある。
プロダクトチームに運用をある程度委譲する方針は、回り回ってサービスやプロダクトチームへ還元されるようにしたい。
（Four keysとSLOは別の角度で信頼性を見ている）
変更失敗率やリリースのリードタイムのような指標は、ユーザからみた品質や満足度といったものを直接的に表現しているわけではない。ただ、信頼性に関連しないわけではなく単に別の角度の指標というだけだろう。 変更による失敗があれば、ユーザには迷惑がかかる。何らかの理由でリリースに失敗し、ユーザになにか影響がでたときにSLOがびくともしなければ、もやもやする。
開発者（Dev）とSRE（Ops）の役割がチーム内でわかれている→DevOps分断なのか？
同チーム内で開発と運用という役割がわかれていることはよくあると思う。両方ができるエンジニアがいたとしても、時間は有限だ。
その場合、「DevとOpsがわかれている」というのだろうか。
個人の意見は「同じ組織系統にいるならわかれていない」と考えている。同じチーム内にいれば、Opsメンバーは問題を共有できるしより迅速に解決に着手できる。ひとつの組織として共通の目標を持って取り組んでいる。
しかしこれが「Dev」組織と「Ops」組織のように上長が異なったりすると話が変わってくる（と感じる）。ここをうまく制御できれば、仮に組織が異なっても問題はなさそうである。
これは単なる距離感なのかもしれない。
SREがEnablingに特化すると、Devを支援するだけ（自分たちはコードを書かない傾向）になるのか？
DevがSLOを意識している状態は理想的だろう。開発者がサービスの状態を理解している状態が、信頼性を最も制御しやすいと想像できる。EmbeddedしているSREでもない限りサービスとの距離感があり、難しくなる。 そうすると、SREの体制が「Devを支援する」形に変化し始める。「距離の近いDevこそが、SLOのオーナーであることが合理的」だから、SREはSLOから手を離したくなる。全部をDevにやってもらいたいと思い始める。
ところが、この体制になるとSREは何をする人たちになるのか。Devの支援とは何を指すのか。
ぱっと思いつく限り
- Devが利用できるナレッジポータルの充実
- 信頼性向上のためのEnabling活動
- そのような仕事を継続するための基盤開発
中大規模組織のSREはこのようになっていくのだろうか。いや、組織のあり方によって異なるので断定はできない。組織の数だけ形がある。今思いついたことも、私が日々仕事している文脈と課題感を多く含んでいる。
これは私が自問自答した内容。
- Devにすべてを任せるという体制はあまりにもDevの負荷が高い気がしている（機能開発, ドメイン知識, QA活動、それに加えてSRE活動も増えるという認知負荷）。嫌な言い回しをすると、丸投げに聞こえる懸念
- プロダクトSREとして全くワクワクしない、つまらないものになる可能性がある。「（簡単に言うと）ドキュメントを整備します」が主なGoalになっている自分の目標設定を見たくないと思っている
- どれだけ忙しくても、SREがサービスの信頼性から手を離すのは避けるべきだと思った。私たちはパフォーマンスや安定運用に対する知見が多いと信じている
ではどのようにするか、「SLOにグラデーションをつけて両チームが特定のSLOに関わる部分に責任を持つ」ことでバランスを取る。 つまり、SREもアプリケーションを修正するし、Devもインフラを修正する。 これなら両者の成長機会を奪わない。SREもサービスへの距離感、最も重要な信頼性制御責任、現場感も離さない。
ナラティブを忘れない
かつて見たかっこいいエンジニアってやつは「バッキバキにパフォーマンスチューニングできて、アプリケーションもインフラもなんでも知ってる。なのに泥臭いことからも逃げない。でも自認がSREではない」人だった。 今でもそれは変わっていない。技術者のあり方は様々だが、そのような人たちを「SRE」と呼ぶようになっただけだ。
「組織が大きくなるとワクワクすることが減るんだよな」と思う時がある。個人的にそう思っていたのを覆してくれたのは今の社であるが、うっかりしているとつまらなくなる。 気がつくと、合理性から「生産性を最大化するならSREはDevを支援したほうが良いかも」という体制を思いつく。思いついてしまう。日々、合理的に判断するように訓練されている弊害だ。
でもそれだけじゃあだめかもしれない。ナラティブ（物語）は必要ではないか。「自分はこういうエンジニアにあこがれていたから、これからもそうなれるようでありたい」という思いを現実に負けて消してはいけない時があるのかもしれない。 人は論理だけでは動けない。ワクワクするには、もっと前に進みたいと思うには、自身のナラティブを忘れてはいけない。
*1:規模に関してここでは、「厚生労働省の従業員1000人以上は大企業」という基準で話す 主な用語の定義｜厚生労働省
*2:自社ではプロダクト数は2024年11月時点で62
*3:SREチームがいない組織において非機能面を担当するチーム。のような定義もある。組織によって名前は様々ある
