HR forecasterにおける SLO導入―SLO導入支援を受けてみた現場のリアル #PERSOL CAREER Advent Calender2025

はじめに
なぜSLOが必要だったのか
導入の前準備と「当たり前品質」の定義
SLO策定による副次的効果
SLOの策定
運用してみて
まとめ

はじめに

HR forecasterというプロダクトでエンジニアをしている諏訪と申します。
私たちのチームでは、dodaの膨大なマーケットデータを用いて採用活動を支援する

HR forecasterの開発を行っています。

パーソルキャリアではプロダクトの品質改善に向けたSLO導入の取り組みを行っています。
1日目の記事では、品質推進部の吉次さんに無料サービスにおける「仮想SLA」導入事例 —— “当たり前品質”を定義し、SLO運用を始めるまでの道のりで支援する側の視点からHR forecasterへのSLO導入事例を紹介いただきました。

また、3日目の記事では、MIRAIZの増田さんにPERSOL MIRAIZのプロダクト主導によるSLO策定についてとして同組織内のプロダクトへの導入事例を紹介いただきました。

本稿では、支援を受ける側でのプロダクトでのSLO導入の道のりと導入しての結果について紹介します。

なぜSLOが必要だったのか

HR forecasterは転職サービスdodaに蓄積された人材マーケットの知見を活用し、採用難易度の見極めや採用要件の作成をサポートするサービスです。新機能として担当者間のやり取りを一元化するための「コミュニケーション機能」を開発し現在、法人トライアルユーザーからのフィードバックをいただいている段階です。
コミュニケーション機能では、利用企業（ユーザー）がチャットを利用しリアルタイム性の高いコミュニケーションを行うプラットフォームを提供します。そのサービスの特性上、安定した品質・信頼性が要求されるため、それらの要素を適切にコントロールするべくSLO導入の要望が挙がりました。
定義の詳細は前述の記事にありますが、我々のチームでは自分たちの目標として「仮想SLA」という概念を定義し、その裏付けとしてSLOを導入する方法をとりました。

導入の前準備と「当たり前品質」の定義

具体の数値の決定を行う前に、まず、サービスとして守りたい品質は何か？を「狩野モデル」を使用してチームでの言語化を行いました。
プロダクトの開発に関わるメンバー全員(企画・デザイン・エンジニア)でプロダクトにとって「当たり前に使える状態」に必要なものを洗い出し、マッピングを行い、その上でSLOとして担保するものを決定しました。
　ここでの気付きとして、同じプロダクトに対してでも企画目線とエンジニア目線では重視する指標として見えているものが異なる、ということがありました。アプリケーション全体の応答時間はエンジニアからは目につきやすく、数値として着目しやすいです。しかし、プロダクトのコア機能を要求分析してみると、本当に応答時間が重要となるインタラクションは限られることがわかりました。またビジネス視点からは、サービス全体の営業時間の中で利用のコアタイムとなる時間の可用性がビジネス視点では重要であることなど、それぞれの視点からの重要性が出ました。それらの視点をチームとして合意形成し、プロダクトのコアとなる重要な体験のために守るべき品質を、職能を超えて合意することは非常に重要でした。

SLO策定による副次的効果

こうして、プロダクトのコア機能と、その非機能要件を整理して明文化することには副次的な効果がありました。
それは、既存の運用フローと、その運用フローによって守るべき非機能要件です。これまでのプロダクト運用では、歴史的経緯から非機能要件が明確にドキュメントとして管理されてはおらず、エンジニアやビジネスサイド各人の認識や各プロダクトの具体のドキュメントに散らばっている状態となっていました。
　そのため、それらを改めて再設計・再測定し、プロダクト全体で意識すべき非機能要件として言語化する取り組みを副次的に行うことができました。また、数値指標として障害対応などの運用業務を測定可能にするためには、既存の障害対応フローを分析する必要がありました。
プロダクトの現在地としてこれまでの障害対応での回復時間や重要度・原因などを分析し、そこからあるべき目標にむかうための障害対応フローとして改めて制度化することで測定可能な状況と、記録化されデータが残る仕組みを整えることができました。
　これらはSLOを導入する以前の話ですが、既存の運用フローを改善するための取り組みのトリガーとしても非常に有益だったと感じています。

SLOの策定

次に、具体的なSLOの策定です。
以下は実際に策定し、運用したSLO指標からの抜粋です。

運用を開始して間もない時期であったため、まずは現状を知るためのデータを取得しながら、漸進的に品質目標を修正するアプローチを行いました。
実際に運用を開始してから、想定よりもシステムが安定しており、エラーが出ていないことを週次で利用状況を確認しながら、目標値を99.0%から99.5%へ上方修正しました。
一度決めた数値が絶対ではなく、システムの品質をトラッキングしながら、現在地と目指す目標を柔軟に変更しながら、改善し続けることが重要でした。

運用してみて

上記の指標の測定には、MIRAIZの記事中での紹介と同様に、Cloud Loggingに記録されたアプリケーションログをGoogle CloudのSLOサービスを用いて測定・可視化しました。ここでも、これを機に既にプロダクトに導入されていたDatadogをより効果的に使おうという取り組みが発生するなどの副次的効果が生まれました。
　また、我々の組織ではGoogle Cloud上のインフラを管理するチームがおり、各プロダクトはその上に提供されております。GitHub上でのインフラ設定などのIaCのコードも含めて、横の組織が何に取り組んでいるかが社内のesaなどのドキュメントツールにオープンに共有されている文化があります。そのため、導入に向けた設定なども緩やかな情報交換によって事例を参考にしながら取り組むことができました。
　SLO導入後、エラーバジェットを消費する障害は発生しておらず、運用としてはこれからなのですが、SLOという定義された品質指標があることで、その後の機能追加においても、当たり前品質を維持することを職能を超えてチーム全員で意識しながら進めることができたと感じています。
また、Cloud Monitoring上にSLOダッシュボードを用意して、月次で「達成率」「消費ペース（バーンレート）」を見える化し、数字の共通言語ができたことで、優先度調整や「やらないこと」の合意がスムーズになりました。

まとめ

HR forecasterにおけるSLO導入は、単にSLOという仕組みを導入するだけの取り組みにとどまらず、サービス全体の非機能要件や品質提供価値を見直す機会となりました。
また、SLOをチェックするサイクルを回す中で、自然と運用フローにも目が向くようになり、非効率だった点の改善や未定義だった部分の言語化などを行うことができました。今回の取り組みは、あくまで1プロダクト内の1機能に閉じた限定的な取り組みでしたが、この取り組みをプロダクト全体、ひいては組織全体に展開していくことで、サービスの垣根を超えた品質改善のきっかけとしたいと考えています。