あなたは今、ミーティングで板挟みになっています。
プロダクトマネージャー： 「この新機能を、なんとしても次のスプリントでリリースしたい。競合に差をつけるチャンスなんだ！」
インフラ担当者： 「待ってください。先週のリリース以降、システムの負荷が高止まりしています。今、新しい機能を入れるのは危険すぎます！」
両者の言い分は、どちらも正しい。そして、その間で「どうすれば…」と頭を抱えているのが、開発者であるあなたです。
これは、多くの開発チームが日常的に直面するジレンマではないでしょうか。ビジネスを成長させるための「機能開発のスピード」と、顧客の信頼を守るための「システムの安定性」。この二つは、しばしば対立するものとして語られます。
この終わりのない綱引きから抜け出し、チーム全員が同じ方向を向くための強力なツール。それが、今回お話しする SLO（サービスレベル目標）とエラーバジェットです。
なぜ「可用性 100%」はチームを不幸にするのか
まず大前提として、システムの可用性 100%は、物理的に不可能です。ハードウェアは故障しますし、ネットワークは瞬断し、そして人間は（悲しいことに）ミスを犯します。
それにもかかわらず、「絶対に障害を起こしてはならない」という無言のプレッシャーは、チームに深刻な副作用をもたらします。
- リリースの恐怖： デプロイが、全員が祈るような気持ちで見守る、年に数回の怖いイベントになる。
- イノベーションの停滞： 新しい技術の導入や、意欲的なリファクタリングなど、少しでもリスクのある挑戦が避けられるようになる。
- 責任の押し付け合い： 障害が発生した時、原因究明よりも「誰のせいか」という犯人探しが始まってしまう。
この状況を打破する第一歩は、「完璧（100%）」を目指すのをやめ、「ユーザーが満足できる、十分なレベル（Good Enough）」をチームの共通目標として定義することです。
ステップ 1：目標を定義する (SLO)
そこで登場するのが**SLO（Service Level Objective / サービスレベル目標）**です。これは、「私たちのサービスは、どの程度の信頼性をユーザーに提供すべきか」を、具体的かつ測定可能な数値で定義したものです。
難しく考える必要はありません。例えば、あなたが Web API を開発しているなら、以下のような SLO が考えられます。
SLO の例： 過去 28 日間において、
/api/usersへのリクエストのうち、99.9% が 500ms 以内 に、かつ エラーなく 成功する。
ここで重要なのは、100%ではないという点です。この例では、0.1%のリクエストは「失敗しても良い」と、チームとして合意したことになります。
この「ユーザーが許容してくれる失敗の割合」こそが、次のステップへの鍵となります。
ステップ 2：「失敗の予算」を手に入れる (エラーバジェット)
SLO を定義すると、魔法のように新しい指標が手に入ります。それが**エラーバジェット（Error Budget）**です。
計算は非常にシンプルです。
エラーバジェット = 100% - SLO
先の例（SLO 99.9%）で言えば、エラーバジェットは 100% - 99.9% = 0.1% となります。
もし、この API へのリクエストが月に 100 万回あるとしたら、エラーバジェットは 100万回 * 0.1% = 1,000回 です。
この「1,000 回」は、単なる失敗の数ではありません。これは、**チームが「リスクのある挑戦」に使うことのできる『予算』**なのです。
エラーバジェットがチームの対立を解消する仕組み
この「予算」という考え方が、開発チームの景色を一変させます。
シナリオ 1：エラーバジェットが潤沢に残っている場合
システムは SLO を上回るほど安定しています。つまり、「失敗の予算」がたくさんあります。 チームの判断： よし、この予算を使って新しい機能 A をリリースしよう！少しリスクはあるけれど、ユーザーを喜ばせる価値がある。
シナリオ 2：エラーバジェットを使い果たしそうな場合
最近小さなエラーが頻発し、システムの安定性が SLO を下回っています。「失敗の予算」がもうありません。 チームの判断： 今月の新機能リリースはすべて凍結しよう。予算が回復するまで、全員でバグ修正、パフォーマンス改善、テストの自動化といった、信頼性向上のためのタスクに集中する。
お気づきでしょうか？
これまで感情論や力関係で決まっていた「新機能をリリースするか否か」という判断が、「エラーバジェットは残っているか？」という、データに基づいた客観的な問いに置き換わったのです。
プロダクトマネージャーも、予算がなければ新機能が出せないことを理解するので、システムの安定性を自分事として捉えるようになります。開発者も、新機能を早くリリースしたければ、システムの信頼性を高めてエラーバジェットを確保しようと努力します。
エラーバジェットは、チーム全員のインセンティブを「機能開発と信頼性の両立」という同じ方向に向ける、驚くほど強力なコミュニケーションツールなのです。
あなたが明日からできる、はじめの一歩
「でも、いきなりこんな仕組みを導入するのは難しそうだ…」と感じたかもしれません。その通りです。最初から完璧を目指す必要はありません。
まずは、あなたのチームで、最も重要で、かつシンプルなユーザーシナリオを 1 つだけ選んでみてください。例えば、「ユーザーログイン」や「商品検索」などです。
そして、そのシナリオに対して、**「どのくらいの速さで、どのくらいの確率で成功すれば、ユーザーは満足してくれるだろうか？」**という問いを、チームで話し合ってみる。
その小さな会話が、あなたのチームを「可用性 100%」の幻想から解放し、健全で持続可能な開発文化へと導く、大きな一歩になるはずです。
$$
$$