この記事では、アプリケーションエンジニアやPdMを経験したのち、SREとして「プロダクトとビジネスのあいだ」を橋渡ししているエンジニアに、「信頼性の優先度をどう決めるのか」「SLOやインシデントをどうビジネスとつなげているのか」を聞きました。
- 年代30代後半
- 現職プロダクト横断 SRE／リライアビリティリード複数プロダクトを横断し、SLO設計・エラーバジェット運用・インシデントレビューをリード。開発・PdM・ビジネスサイドの間に立ち、信頼性に関する「共通言語づくり」を担っている。
- キャリアアプリ開発 → PdM → SRE新卒でWebアプリケーションエンジニアとしてキャリアをスタート。機能開発とチームリーディングを経験した後、プロダクトマネージャーとして企画・優先順位付け・KPI設計を担当。その中で信頼性課題と向き合ったことをきっかけに、SREとしてプロダクト横断の信頼性戦略に関わるようになる。
- プライベート街歩きとボードゲームが好き休みの日は知らない街を歩きながら、喫茶店や本屋を巡るのが楽しみ。友人と集まってボードゲームを遊ぶのも好きで、「みんなが気持ちよく遊べるルールづくり」にこだわるタイプ。
キャリアの交差点 ― 開発者から「橋渡し役」のSREへ
仕様とコードのあいだで、ずっと立ち続けてきた
最初は普通のWebアプリケーションエンジニアでした。バックエンド中心に機能開発をしていて、「どう作るか」に頭のほとんどを使っていた時期ですね。ただ、チームリーダーを任されるようになると、「なぜ今これを作るのか」「本当にユーザーに届いているのか」が気になり始めました。
その流れで、プロダクトマネージャーとして企画や優先順位付けに関わるようになったのですが、そこで強く感じたのが、「プロダクトとしてどこまで攻めたいか」と「システムとしてどこまで守れるか」が、いつも少しずつズレているということでした。機能要望と技術的制約の板挟みになりながら、そのズレを埋める役割を自然と担うようになっていった感覚があります。
インシデントをきっかけに見えた、「誰の仕事でもない領域」
SREに近い動きを意識し始めたのは、大きめのインシデントを経験したことがきっかけでした。サービス全体に影響が出る障害が発生したとき、開発チームは原因調査に集中し、ビジネス側はユーザーへの説明や影響範囲の把握に追われていました。
そのとき、「技術的な原因は分かりつつあるけれど、『なぜこのリスクを許容したのか』『どこまでをOKと見なしていたのか』を説明できる人がいない」という状況に直面したんです。インシデントの最後に残ったのは、コードの問題というより、「どういう前提で運転していたのか」という合意の欠如でした。
そこから、「信頼性に関する前提や優先順位を、最初から一緒に設計し直したい」と思うようになり、SREとしてプロダクト横断の役割に踏み出しました。
プロダクトとSREの境界で担う、“合意づくり”の仕事
信頼性の優先度を、一緒にテーブルに乗せる
一言でいうと、「信頼性の優先度を、プロダクトの議題に乗せ続ける役割」です。新機能の検討や四半期ごとのロードマップを作る場に、SREとして必ず入り、「どの体験をどこまで守るのか」「どのリスクは受け入れるのか」を一緒に決めていきます。
単に「もっとSLOを厳しくしましょう」と言うのではなく、「このSLOを守るには、開発側にどんな投資が必要か」「代わりに何を後ろに回すのか」までセットで議論することを大事にしています。プロダクト側から見れば「SREは制限をかける人」になりがちなので、「一緒に優先順位を決めてくれる人」として認識してもらうことが、第一歩かなと。
SLOは“数字”ではなく、“合意の器”だと思っている
よく「SLO設計が仕事ですか？」と聞かれるのですが、個人的には「SLOは結果としてのアウトプットであって、本質は合意形成プロセスにある」と思っています。数字自体は後からいくらでもチューニングできますが、そこに至るまでの会話の質は、そう簡単には変えられません。
なので、ワークショップ形式で「どのユーザーストーリーが一番壊れてほしくないか」を出し合ってもらったり、過去のインシデントログを見ながら「これはどこまで我慢できたか」を振り返ったりしながら、チームごとの“痛点マップ”を可視化していきます。そのプロセスを通じて、「このサービスにとっての信頼性とは何か」が、少しずつ言葉になっていく感覚があります。
現場で見えてきた“ズレ” ― チームごとの「信頼性のイメージ」
同じ数字を見ていても、見ている景色が違う
まず多いのは、「同じSLOの数字を見ているのに、頭の中で再生しているシーンが全然違う」というケースです。例えば、同じ99.5%の可用性でも、インフラエンジニアは「落ちるのは年にこれくらい」と考え、CSのメンバーは「月にこれくらいの問い合わせが来る」と考え、経営サイドは「これだけの売上インパクトがある」と捉えます。
数字だけで議論すると、「もっと上げたい」「これで十分だ」という感情だけがぶつかりがちです。なのでミーティングでは、「この数字の裏側で、実際にユーザーはどんな体験をしているか」を、ロールごとに口に出してもらうようにしています。そうすると、「自分たちはこんな前提で話していたのか」と気づきが生まれ、議論のトーンが少し柔らかくなるんですよね。
対立を消すのではなく、“言葉の足場”を揃える
信頼性の話は、どうしてもビジネスと開発の「価値観のぶつかり合い」になりやすい領域です。ただ、自分が意識しているのは、対立そのものを消すことではなく、「同じ足場に立てる言葉を用意する」ことです。
例えば、「この機能は止まってもいいけれど、この機能は止まってはいけない」という話をする時に、なんとなくの感覚で決めるのではなく、「これは売上に直結する」「これは社内オペレーションに影響する」といった分類を先に作っておく。カテゴリごとに「どこまで止まってもいいか」のラインを決めておくと、議論はずっと建設的になります。
SREとしては、その“言葉の足場”を用意することが、技術的なチューニングと同じくらい大事な仕事だと感じています。
インシデントとポストモーテム ― 「誰のせいか」ではなく「何が起きたか」を残す
最初の5分で、「責任の矢印」を止める
大きめのインシデントが起きたときにまずやるのは、「誰が悪いか」という矢印を、できるだけ早い段階で止めることです。人間なので、「あのときレビューしていれば」「あの設定を変えなければ」という発言はどうしても出てきます。
そのタイミングで、「いったん個人名は忘れて、事実だけをタイムライン形式で並べませんか」と提案するようにしています。「いつ、誰が、何をしたか」を責めるためではなく、「どのような前提と情報で、その判断をしたのか」を理解するために辿る、というメッセージを明確に出すイメージです。
再発防止策より、「前提のアップデート」を残す
ポストモーテムを書くときも、いわゆる「再発防止策」を箇条書きにするだけでは終わらせないようにしています。それだと、「新しいチェックリストが増えたね」で終わってしまいがちなので。
むしろ重視しているのは、「このインシデントの前と後で、私たちの前提はどう変わったか」を一文で残すことです。例えば、「この規模のトラフィックは想定外としていたが、今後は日常的に起こりうると見なす」とか、「この種の障害はアプリ側だけでなく、運用ルールの問題としても扱う」とか。
そうした前提のアップデートが積み重なっていくと、「この組織はちゃんと学習しているな」と実感が持てるようになりますし、後から入ってくるメンバーにとっても大きな手がかりになります。
これからのSREと、自分が描きたいキャリア
“正解を出す役”から、“問いを投げる役”へ
これからのSREは、「こうすべきだ」という正解を提示する役割から、「どこに問いを置くか」をデザインする役割にシフトしていく気がしています。クラウドもAIも進化し続ける中で、「これが唯一の正解です」と言い切れる設計は、どんどん減っていくと思うので。
その代わりに、「どこまでなら壊れてもいいか」「どこからが許容できないのか」「そのラインを誰が決めるのか」といった問いを、チームと一緒に引き受けていく人が必要になります。自分はその問いを投げ続けられるSREでありたいなと思っています。
「このチームと仕事するの、安心だよね」と言われる存在に
個人としてのキャリアでいうと、「このチームと一緒にやると、ちゃんと守られている感じがするよね」と言ってもらえる状態を増やしたいです。技術的にすごいとか、難しいことができるとかではなく、「一緒に走っていて安心する」と思ってもらえる存在でありたい。
プロダクトの成長フェーズやビジネス上の制約によって、「今は攻めた方がいい」「ここは守った方がいい」という判断は変わります。その中で、「どの選択をしても、ちゃんと振り返れるようにしておきましょう」と言い続けることが、自分の役割かなと感じています。
信頼性は一度作ったら終わり、というものではなく、チームとの関係性の中で更新され続けるものです。SREという仕事を通じて、その更新プロセスにずっと携わっていけたらいいなと思っています。
インタビューを終えて
同じSLOの数字を見ていても、ロールによって見ている景色が違うこと。それでも対立を消そうとするのではなく、「言葉の足場」を揃えることで議論を前に進めていくこと。インシデントのあとに「誰のせいか」ではなく、「どんな前提でこの判断をしたのか」を残そうとする姿勢も、まさにMeet the SREで伝えたい“文化としての信頼性”そのものだと感じました。
SREをめざしている人にとっても、すでに現場で信頼性と向き合っている人にとっても、「問いをどこに置くか」という視点は大きなヒントになるはずです。今回のインタビューが、あなたの現場での対話を少しだけ前に進めるきっかけになればうれしいです。
