なぜQAエンジニアがSLO導入をリードしたのか — tebiki Tech Blog
はじめに
Tebiki株式会社でQAエンジニアをしている中西です。
SLO（Service Level Objective）をご存知でしょうか？
多くの技術記事では、SRE（Site Reliability Engineering）によって設計・運用される仕組みとして紹介されています。
しかし、私たちは、SLOをプロダクト開発チーム自身で定義し、運用していくことに取り組んでいます。なぜなら、プロダクトの信頼性やユーザー体験の“守りどころ”を決めるには、日々ユーザーと向き合いながら機能開発を進めているチーム自身が、その判断の軸を持つべきだと考えたからです。
今回の記事では、QAエンジニアである私が、どのような課題感からSLOの導入を提案し、どんな視点でその必要性を捉えたのかをご紹介します。SLOの設計・運用方法そのものについては、別記事で詳しくお話しする予定です。
背景：機能追加と品質改善のバランスに悩んでいた
スピードと安定性、どちらも大切にしたかった
プロダクトの成長に伴い、新機能のリリーススピードが重視されるようになっていました。
一方で、顧客影響のあるバグの発生が増加傾向にあり、顧客やビジネスチームからはプロダクト品質に対する懸念の声も高まりつつありました。
QAエンジニアや開発エンジニアも「改善すべきことがある」という問題意識を持っていました。しかし、日々の新機能開発やインシデント対応に追われる中で、品質改善に十分なリソースや時間を割くことが難しい状況でした。
インシデントは管理されていた。が、何をいつまでに改善すべきかは合意できていなかった
インシデントの事象や発生件数、障害復旧時間を記録し、発生件数の推移を継続的にトラッキングしていました。そのため、ある時期にインシデントが増加傾向にあることは、チーム全体で把握できていました。
また、各インシデントの復旧後にはポストモーテムを実施し、再発防止策や改善施策についても都度チームで議論していました。しかし、施策が挙がっても、どれに優先的に取り組むべきかを判断することが難しいという状況がありました。
その背景には、判断するための共通の指針や基準が明確に存在していなかったという課題がありました。
品質に向き合いたい気持ちはあるのに、方向性や判断材料が足りない。
このままでは場当たり的な対応が続くだけで、本質的な改善にはつながらないという危機感が、QAエンジニアや一部のアプリケーションエンジニアの中に芽生えていました。
Tebiki QAとして、何ができるのか？
私たちのQAチームは、単にテストを担うのではなく、**品質改善のためにチームを支援・推進することを目的とした「イネイブリングQA」**として立ち上がったチームです。
この役割を果たす上で、私たちはこう考えました。
「改善に迷わず踏み出すためには、品質をチームで定義し、共通の物差しを持つ必要がある」と。
そのとき、開発チームの目に留まったのが SLO（Service Level Objective） というフレームワークでした。
なぜQAがSLO導入をリードしたのか
感覚ではなく、共通言語で品質を語りたかった
品質に関する会話は、感覚的なものになりがちです。
「インシデントが頻発しており、品質が悪化していないか心配」、「今のプロダクト品質に問題はない？」――そういった声は出るものの、”品質”が指すものは人によってバラバラです。
私たちは、QAエンジニアとして「品質の専門家」であるならば、曖昧な“印象”ではなく、明確な“定義”によって、品質が語られる必要があると考えました。そして、「定義された品質を満たしていないのであれば、改善アクションをチームから自然に生み出せる状態をつくる」必要があるとも感じていました。
共通言語がなければ、改善の必要性も方向性も定まりません。そうした問題意識が私たちのSLO導入の出発点でした。
SLOは品質を定義し、共有できるフレームワークだった
SLO（Service Level Objective）は、「どの品質をどの水準で維持するか」を定め、それをSLI（Service Level Indicator）という指標でモニタリングする仕組みです。
単なるメトリクス管理ではなく、“このユーザー体験を守る”という意思を明文化し、チームの合意のもとで運用できる点に、大きな魅力を感じました。
また、SLO／SLIという構造は、開発・QA・カスタマーサクセス・フィールドセールス間での共通言語になり得ます。
「品質が不安だ」という感覚に対して、数字と合意に基づいて、アクションできる状態をつくることが、私たちの目的でした。
顧客体験を守るSLO
SLOは、SREが導入する仕組みとして広く知られていますが、必ずしもSREにしか扱えないものではないと考えています。ただし、QAエンジニアがSLO導入を推進するにあたっては、SLOのフレームワークに関する情報収集から、SLIの定義、メトリクスの調査、可視化、違反時のアラート設計まで、プロダクトコードやモニタリング環境に深く関与する必要があり、非常に時間がかかりました。開発エンジニアにも協力いただき導入を開始することができました。（この辺りの苦労話は、次回のブログで詳しくご紹介できればと思っています。）
TebikiのQAエンジニアはテストに加えて、カスタマーサクセスやユーザーの声に日々触れながら、体験としての品質を見続けています。だからこそ、「ユーザーがどんな体験を期待しているか」「どんな状態を“許容できる品質”とするのか」といった視点を持って、SLOの検討を進めることができたのだと思います。
おわりに
私たちのようにSREが不在でも、品質を定義し、共通認識として運用する枠組みとして、SLOは大きな価値を持っています。
そして、QAエンジニアがSLO導入を推進するという選択は、ただの仕組みを導入することではなく、「”品質を語る場”そのものをつくる」ことだったと感じています。
次回のブログでは、実際にどのようにSLOを設計し、運用へつなげていったのかを具体的にご紹介する予定です。同じように品質に悩むチームの参考になれば、嬉しいです。
私たちは仲間を募集しています！
Tebiki社は、エンジニアを募集しています！
興味がある方は、ぜひカジュアルにお話ししましょう！
▼採用HP
▼募集中のエンジニア求人一覧
