はじめに ― “信頼性”という言葉の曖昧さ
誰もが知っている言葉、誰も定義できない言葉
SRE（Site Reliability Engineering）という言葉を聞いたことがある人は多いでしょう。けれど、「何をしている職種なの？」と聞かれると、うまく説明できないことも少なくありません。
「障害を減らすチーム」「自動化の専門家」「インフラの番人」――どれも一面では正しいけれど、SREという仕事のすべてではありません。SREとは、システムが“ちゃんと動く”という安心を、仕組みとして支えるエンジニアリングです。
もう少し言えば、SREは“信頼性”という曖昧な価値を、技術で形にする試みです。数字で測れる稼働率やレスポンスタイムの裏には、チームの判断やユーザーの期待があります。その関係性をどう支え続けるか――それが、SREの仕事の根っこにあります。
“信頼性”をどう捉えるか
0章の記事「なぜ“信頼性”を研究するのか」でも触れましたが、信頼性とは単に“止まらないシステム”ではありません。
チームがどのように判断し、互いに信頼を築けるかという、文化の問題でもあります。
だからこそ、SREは「技術職」であると同時に、「文化を育てる職種」でもあります。
数値化できない安心感を、仕組みとして再現する――それが、SREという実践の面白さであり、難しさでもあります。
SRE誕生の背景 ― DevOpsとの関係
Googleが直面した“運用の限界”
「SRE」という言葉は、Googleが抱えた現実的な問題から生まれました。
2000年代、Googleは世界中にサービスを拡大し続け、トラフィックは毎月のように倍増していました。けれど、運用の現場は人の手作業に頼る部分が多く、障害対応は深夜にまで及ぶ日々が続いていたのです。
どんなに優秀なエンジニアでも、24時間365日ミスなく動くことはできません。
そこでGoogleは考えました。
「人の努力ではなく、仕組みそのもので信頼性を保てないか？」と。
この問いが、SRE（Site Reliability Engineering）という新しい考え方の出発点になりました。
“運用をコードで表現する”という発想
GoogleのSREチームは、手作業の運用をスクリプト化し、自動化の仕組みを積極的に取り入れました。
障害を「突発的な事件」としてではなく、“再現できる現象”として扱うようにしたのです。
たとえば、サーバーの再起動やリソース管理をコード化し、同じ処理を何度でも再実行できるようにしました。
人の経験や勘に頼るのではなく、プログラムによって運用を説明できる状態を目指したのです。
この考え方は、後に「Infrastructure as Code（コードとしてのインフラ）」という言葉でも広まりました。
つまり、運用もまた開発の一部であり、“コードで管理する対象”になったのです。
DevOpsとSREの違い
ここでよく混同されるのが、DevOpsとSREの関係です。
どちらも「開発（Dev）」と「運用（Ops）」をつなぐ考え方ですが、立ち位置が少し異なります。
DevOpsは、開発と運用のあいだにある壁を壊し、協力しあう文化を広げるためのアプローチです。
一方のSREは、その文化を技術的に実装するための方法論です。
たとえば、DevOpsが「橋をかけよう」という思想なら、SREは「その橋を安定して支える構造を設計する」実践。
文化が先にあり、その文化を支える技術としてSREが存在している――そんな関係です。
つまり、SREはDevOpsの延長線にある“実務的な解答”でもあります。
仕組みの自動化、信頼性の指標、再現可能な改善サイクル。
それらを通じて、チームが“変化に強い安定”を手に入れることを目的にしています。
SREの3つの柱 ― 信頼性を設計するための実践
① SLO（Service Level Objective）― 目的としての信頼性
SLO（サービスレベル目標）は、システムの信頼性を測るための「合意の指標」です。
たとえば「稼働率99.9％を維持する」といった目標を、開発チームと運用チーム、そしてビジネス側が共通の言葉として共有します。
ここで大切なのは、SLOが単なる数字の目標ではないということです。
SLOとは「私たちはどんな状態を“正常”と呼ぶのか」をチームで話し合うための出発点です。
この会話を通じて、何を守り、どこまでリスクを許容できるのかという“信頼の境界線”が明確になります。
数字を決めることよりも、「なぜその数字にしたのか」を共有することが重要です。
SLOは、システムの安心を可視化するための言葉であり、チームの信頼を数値で翻訳する行為だといえます。
② エラーバジェット ― 変化と安定のバランスを測る
SLOを設定すると、次に「どれだけの失敗を許せるか」という“余白”が生まれます。
この余白を「エラーバジェット」と呼びます。
たとえば、稼働率99.9％なら、残り0.1％が“失敗してもよい範囲”です。
一見すると不思議に思えるかもしれません。
しかし、この“失敗を許す”という考え方こそ、SREの根幹にあります。
なぜなら、100％の安定は進化を止めてしまうからです。
新しい機能を出すことも、改善を進めることも、すべては少しのリスクと隣り合わせです。
もしエラーバジェットを使い切ったら、リリースを一時停止し、原因を分析します。
逆に、余裕があれば積極的に新機能をリリースする。
このサイクルによって、「変化」と「安定」が対立せずに共存できるのです。
エラーバジェットは、数字の仕組みに見えて、実はチーム間の対話を支える“翻訳者”です。
安定を守る人と、変化を進めたい人。その間にある摩擦を数字で中和する――それが、SREらしいアプローチです。
③ ポストモーテム文化 ― 失敗を“観測”に変える
どんなに優れた仕組みを作っても、障害は必ず起こります。
そのとき、SREが最も大切にするのが「ポストモーテム（事後分析）」です。
これは、障害を責めるのではなく、「何が起きたのかを観測するための儀式」です。
たとえば、「誰がミスをしたのか」ではなく、「どんな条件でミスが起きたのか」「防ぐ仕組みはなかったのか」を丁寧に言語化します。
SREにとって失敗は恥ではなく、改善のためのデータです。
記録を積み重ねることで、チームは「同じ失敗をしないための知恵」を共有できるようになります。
私が以前のチームで導入したときも、最初は誰も積極的に書こうとしませんでした。
しかし、自分が最初に障害対応の詳細を共有したところ、ほかのメンバーも次第に参加してくれるようになりました。
「失敗を共有できる空気」が生まれた瞬間、チームの雰囲気が変わったのを今でも覚えています。
ポストモーテムは、技術的な仕組みというより、チームの学び方を変える文化です。
失敗を恐れるのではなく、観測し、次に活かす。
この“観測の輪”を回し続けることこそ、SREの成熟を支える力です。
数字を越えた“信頼性”のデザイン
数値で語れること、語れないこと
SREは、信頼性を数値化し、共通の言葉にすることを得意としています。
SLOやエラーバジェットを使えば、誰もが同じ基準で議論できるようになります。
しかし、数字だけで信頼性を説明しようとすると、いつか必ず限界にぶつかります。
なぜなら、数字は「結果」を示しても、「背景」を語ることはできないからです。
障害対応の最中に誰が何を感じたか、チームの中でどんな判断が生まれたか――
そうした“見えない部分”にこそ、信頼性の本質が隠れています。
数値化は強力なツールです。けれど、数字はあくまで対話を始めるための手がかり。
数字そのものをゴールにしてしまうと、信頼性は「管理されるもの」になってしまいます。
信頼性とは、チームの対話の質である
信頼性を語るうえで欠かせないのが、チームの対話です。
「どんなときにSLOを見直すか」「リリースを止める判断は誰がするか」――
その一つひとつの会話が、チームの信頼の輪郭を形づくります。
会話が乏しいチームでは、数字だけが独り歩きし、
“なぜその数値なのか”を説明できる人がいなくなります。
逆に、活発に対話があるチームでは、数字の裏にあるストーリーが共有され、
判断の背景が見えることで、安心してリスクを取ることができます。
つまり、信頼性とはチームの会話の質に比例する指標なのです。
会話の中に、理解・尊重・期待のすり合わせがあるほど、
数字は“生きた指標”として機能します。
仕組みと人間の“共進化”
SREの究極の目的は、システムの効率化ではありません。
むしろ、仕組みと人間が互いに学び合う“共進化”の状態をつくることです。
観測・分析・改善――この3つの輪を回し続けることで、
システムは安定し、人は経験を蓄積し、チーム全体が少しずつ成長していきます。
この継続的な学習こそが、信頼性を技術ではなく文化として根づかせる力になります。
信頼性とは、安定を守るための固定的な仕組みではなく、
変化を受け入れながら学び続ける“動的な関係性”です。
SREとは、その関係を観測し、改善の輪を絶やさないエンジニアリングなのです。
文化としてのSRE ― “信頼性”は組織の関係性で育つ
データよりも先にあるもの
GoogleのSRE本には「希望的観測ではなく、データに基づく判断を」と書かれています。
けれど、現場にいると痛感します。どんなにデータを整えても、文化は数字だけでは育たないということを。
データを信じる前に、まずはそのデータを提示する人を信じられるかが問われます。
数字を共有することよりも、その数字の意味を一緒に考えられる関係性――それが、SRE文化の根っこにあります。
数字が信頼を作るのではなく、信頼が数字を使いこなす。
その順序を間違えないことが、文化をつくる最初の一歩です。
人と仕組みのあいだにある信頼
信頼は、人の手から生まれ、やがて仕組みに宿ります。
SLOを設定するのも、ポストモーテムを書くのも、最初に動かすのは人の意志です。
自動化の裏側には判断があり、その判断の背景には「この人たちの言葉なら信じられる」という関係があります。
つまり、SREは“人と仕組みのあいだ”をデザインする仕事です。
技術は冷静であるほど、そこに人の温度が必要になります。
信頼性の文化とは、その温度差を受け止め、仕組みと感情の間に橋をかける営みなのです。
信頼性エンジニアリングの出発点
もしあなたが「信頼性をどう定義すればいいのか」「チームに文化を根づかせるにはどうすればいいのか」と悩んでいるなら、
まずは自分のチームの会話を観測してみてください。
どんな判断が、どんな前提で行われているのか。
その観測こそが、信頼性エンジニアリングの出発点です。
信頼性とは、完成された状態ではなく、観測と学びを繰り返す“プロセス”です。
そしてその輪を回し続けることが、SREという文化を育てる唯一の方法なのです。