QAエンジニアによるSLO導入の振り返り

はじめに

こんにちは。Tebiki株式会社でQAエンジニア兼CREをしている中西です。2025年4月に公開した「なぜQAエンジニアがSLO導入をリードしたのか」では、Tebiki株式会社におけるQAエンジニアがプロダクト開発チーム内でSLO（Service Level Objective）の定義と運用を主導する取り組みを紹介しました。あれから半年が経ち、SLO導入を通じて多くの学びを得ました。本記事では、導入時に期待していた効果、実際に得られた成果、そして浮き彫りになった課題と今後の展望を共有します。

期待していた効果

SLO導入にあたって、私たちは主に次の2点を期待していました。

1. ビジネスチームとの共通言語をつくること

SLOやエラーバジェットの状態を共有することで、プロダクト品質に関する認識を一致させ、技術・ビジネス両面から品質を議論できる環境を目指しました。

2. SLO違反を契機に品質を見直す仕組みをつくること

違反が続く状態を「品質劣化」と捉え、機能開発よりも品質改善を優先する体制への転換を期待しました。

SLO導入に向けて

まず、動画マニュアル作成〜動画マニュアル閲覧に至るクリティカルユーザージャーニーを整理し、ユーザーにとって重要な体験ができているかを測定できるメトリクスを選出しました。多くのSLI候補が挙がりましたが、「まずは最小限の構成で始める」方針のもと、運用可能な範囲を考慮して8つのSLIを選定し、これらに対してSLOを設定しました。

さらに、エラーバジェットの定義や計測期間（ウィンドウ）、そしてエラーバジェットが枯渇した場合の対応方針など、運用ルールを具体化しました。これらの検討は、導入推進者間で何度も議論を重ねた上で、最終的なSLO定義書に落とし込みました。

運用スタート

SLO違反を検知した際に開発チームが迅速に調査・修正へ動くといった良い循環が見られました。 SLO違反をきっかけに改善行動するという点では一定の効果を得られたと感じています。

一方、設定したSLO以外の領域では、インシデントやシステムアラートが頻発していました。これを受け、「SLO違反を契機に品質を見直す仕組み」という狙いを果たすには、必要なSLIが不足しているのではないかという疑念が生まれました。

そこで新たなメトリクスを追加し始めましたが、

「どのくらいSLIを設定すれば必要十分なのか」

「SLIを増やし続けて良いのか」

というモヤモヤがSLO導入推進者内に広がっていきました。

現実と向き合う

導入推進者間で議論を重ねた結果、SLOの運用を一旦STOPするという決断を下しました。

これは、SLOの効果を検証する以前に、より根本的な課題があることが明らかになったためです。というのは、運用を通じて見えてきたのは、「SLOの目的って何だっけ？」という違和感でした。

つまり、SLOの目的が大きすぎたことで、到達地点が不明確になっていたのです。

この結論に至った背景を、次の3つの層で整理しました。

【事象】「指標」と「体感」のズレ

運用を続ける中で、設定したSLO指標と現場の体感する品質が噛み合わない状態が生まれていました。
インシデントやシステムアラートが発生しても、測定するSLIに組み込まれていなければ、SLO違反としてはカウントされません。 SLOの対象としていても、エラーバジェットが枯渇しない限り、改善アクションは行われません。

このように、SLOを満たしていても、ユーザー体験としては「品質が悪い」と感じる状態が続いていました。
つまり、監視対象が「現場が守るべきだと感じるクリティカルな体験」と連動していなかったのです。

【要因】目的の抽象化と品質基準の欠如

このズレが生じた背景には、SLOの目的が抽象的すぎたことと、品質基準が定義されていなかったことがありました。
「新機能開発と品質改善のバランスを取る判断軸にする」という目的を掲げてはいたものの、
守るべき基準がないために、何をもって“バランスが取れた”と言えるのかが不明確でした。

結果として、SLOを運用すること自体が目的化し、改善活動の方向性がぼやけていったのです。

【根本原因】守るべき「品質基準」の不在

さらに深い原因として、プロダクトとして守るべき品質基準が、組織として明確に定義されていなかったことが挙げられます。
本来であれば、ビジネス上の裏付けをもとに「どこまで品質を守るか」を定める必要がありました。

しかし、私たちはその基準をSLOそのものに求めてしまっていたのかもしれません。結果として、基準を支える土台がないままSLOを設定したため、指標や閾値の設定が感覚的になり、数値の妥当性に納得感を持てる人がいない状態に陥っていました。

学びと今後の展望

この経験を通じて、私たちは2つの大きな学びを得ました。

SLOは品質基準を可視化するための手段であり、SLOそのものが品質基準にはならないこと

SLOは「どんな品質を、どの水準で守るか」という合意を運用に落とし込む仕組みです。
しかし、守るべき“基準”がないままSLOを設定すると、測定そのものが目的化し、チームとして何を守ろうとしているのかが見えなくなってしまいます。　（今回私たちがぶち当たった壁そのものです）
目的が大きすぎると、SLOが手段として機能しにくくなること

私たちのSLO導入は「品質改善と機能開発のバランスを取る」ことを目的としていました。
しかし、この目的は抽象度が高く、SLO単体ではそのバランスを定量的に示すには範囲が広すぎました。
目的が大きいほど、どの指標をどう見ればよいのかが曖昧になり、結果としてSLOを運用すること自体が目的化してしまうリスクがあると学びました。

これらの気づきから、私たちは「SLOをどう設定するか」に立ち戻り、
まず“守るべき品質基準をどう言語化するか”から再検討を進めています。