SLOを経営者が決める。安定性にいくら使うかを業務から考える

SLOを経営判断に使うとき、経営者が単独で技術的な測定方法を決めるのではありません。事業責任者、開発、運用を含む関係者で、止まった際にどの業務がどこまで待てるかを整理し、合意します。安定性に人と時間を投じれば、機能開発など別の仕事が後ろへ動きます。だから、停止時間の長さ、業務への影響、代替手段、復旧期限を並べ、限られた投資をどちらへ振るかを選びます。

利用者の申込みを受け付ける処理と、その内容を翌日にまとめる集計処理を比べてみます。受付が止まるとその場で業務が止まり、安全な代替手段もなく、利用者に復旧を待ってもらえません。翌日集計は失敗しても再実行でき、合意した期限までに結果がそろいます。この条件なら、僕は受付側の信頼性対策を先に検討します。両方に一律の可用性目標を課すより、守る業務に応じて目標と投資を分ける判断です。

では、受付はいつも優先でしょうか。代替手段で申込みを受理できるようになれば、停止の影響は軽くなります。翌日集計の遅れが後続業務を止め、再実行しても期限に間に合わないなら、集計側の優先度が上がります。自社で実行するには、現在の優先順位に加え、優先順位が逆転する条件まで先に合意しておく必要があります。

SLOは事業が負えるリスクを決めるもの

SLOは、サービスが利用者に提供すべき信頼性の目標水準です。目標を高くするほど、対策へ振り向ける人と時間も増えます。2026年9月29日に確認したGoogle Site Reliability Engineeringの公式資料は、SLOを、信頼性作業の機会費用を踏まえてエンジニアリング作業の優先順位を判断する道具として説明しています（Implementing SLOs）。

信頼性の目標は、事業が負えるリスクと明示的に整合させます。機能開発や技術的負債への対応も含めた機会費用を考える必要があると、同日に確認した公式資料は述べています（Embracing Risk）。安定性への追加投資を承認する会議では、その投資によって遅らせる仕事も同時に示さなければなりません。

経営者や事業責任者が承認する中心は、小数点の付いた目標値より、その目標が守る業務です。「停止を減らしたい」では投資の上限を決められません。「受付停止中は申込みを受理できず、代替手段もない」「集計は遅れても期限内に再実行できる」と業務の言葉に置き換えると、優先順位を選べます。技術の説明を経営が選べる形へ整える役割は、経営と技術をつなぐ人がいないと、会議は決まらないでも扱っています。

受付と翌日集計を、別々の業務台帳で比べる

同じサービスの中でも、仕事の性質によって観測すべき指標は変わります。Implementing SLOsは、利用者が応答を待つリクエスト駆動型では可用性や遅延を、レコードを処理して出力するパイプライン型では鮮度、正確性、カバレッジをSLIの候補に挙げています。SLIとは、利用者から見た信頼性を観測する指標です。

僕なら、受付と翌日集計を一枚に混ぜず、業務ごとに台帳を作ります。この台帳はSLIやSLO値を決める前の業務要件整理であり、SLOそのものでも、原典所定の帳票や義務でもありません。二つの台帳へ同じ順番で、次の項目を記します。

• 業務の完了条件：受付は申込みをその場で受理できたか。翌日集計は、合意した期限までに必要な処理を終えたか。
• 停止時の業務影響：利用者や後続業務の何が止まり、復旧まで待てるか。
• 代替手段：別の方法で業務を続けられるか。その方法を安全に運用できるか。
• 復旧期限：いつまでに戻れば業務上は許容できるか。再実行で期限に間に合うか。
• 許容できない条件：どの失敗の形になったら、ほかの開発より信頼性作業を優先するか。

この五項目が埋まれば、「どちらのシステムが大切か」という抽象論を避け、業務が完了したかどうかで比較できます。受付画面が表示されても申込みを保存できなければ、受付業務は未完了です。翌日集計が一度失敗しても、再実行で期限までに必要な結果がそろえば、受付の全面停止とは業務影響が異なります。

投資順を決め、逆転条件も記録する

受付の台帳に「停止するとその場で業務が止まる」「安全な代替手段がない」「利用者に復旧を待ってもらえない」が並び、翌日集計の台帳に「失敗後に再実行できる」「合意した期限内に復旧できる」と記されたとします。この組み合わせなら、受付側の信頼性対策を先に検討します。翌日集計は稼働・停止だけで評価せず、結果の鮮度、正確性、カバレッジと復旧条件で管理します。

経営者にとっての利点は、目標値の高さを競う議論から離れ、「何を守る投資か」「そのために何を遅らせるか」を同じ場で確認できることです。

なお、迷いは残ります。障害の件数が同じなら、影響も同じと見てよいのでしょうか。Embracing Riskは、同じ絶対エラー数であっても、継続的な一部失敗と一時的な全面停止では、事業への影響が大きく異なり得ると説明しています。台帳には失敗の量に加え、許容できない失敗の形も記す必要があります。

投資順は、条件が変われば見直します。受付に確実な代替手段が整い、停止中も業務を継続できる状態になれば、受付を先にする根拠は弱まります。翌日集計の遅れで後続業務が止まり、再実行でも期限に間に合わないと分かれば、集計を後に回す根拠が失われます。台帳に「受付を優先」とだけ書くのでは足りません。「代替手段が機能するまで」「集計を期限内に再実行できる間」と、結論が変わる境界を添えます。判断理由と責任の残し方は、CTO代行を入れると、組織の意思決定はどう変わるのかにもつながる論点です。

許容範囲を超えた後の行動まで承認する

SLOから外れた際の行動が未定だと、観測結果を投資判断に使えません。Implementing SLOsは、利用者に十分な水準か、通常時に守れるか、エラーバジェットを優先順位付けに使うかを関係者で合意し、予算を使い切ったときの行動と担当を方針に定める必要があるとしています。エラーバジェットは、SLOで許容した不調の量です。割合で表すSLOなら、100%からSLOを引いた値になります。

僕なら二つの業務台帳の末尾に、次の三点を追加します。

• 延期する変更：許容範囲を超えたとき、どの変更を止めるか。
• 優先する信頼性作業：受付または集計のどの状態を先に戻すか。
• 判断者：延期と再開を誰が決めるか。

三点を事前に合意すれば、障害が起きてから担当者同士で優先順位を争う事態を避けやすくなります。この記録方法も、公式資料の一般原則を会議へ持ち込むために僕が提案する実務案です。受付が許容範囲を超えたら、受付へ影響する変更を延期し、必要な信頼性作業を優先します。翌日集計では、鮮度、正確性、カバレッジ、復旧条件のうち、外れた項目に応じて行動を選びます。繁忙期に変更を止める範囲と、未反映変更を戻す順番まで決める場合は、事業カレンダーからリリースフリーズを判断する方法で、通常変更・修正・緊急変更の区分と解除条件へつなげてください。

技術の細部は技術チームが設計し、経営は停止時に事業が負える影響と、安定性投資によって後回しになる仕事を承認します。代替がなく、利用者がその場で復旧を待てない間は受付を先にします。再実行や期限内復旧ができなくなり、後続業務が止まるなら翌日集計の優先度を上げます。その境界、許容範囲を超えた後の行動、判断者を一組で決めることで、SLOは経営判断として機能します。