- ごあいさつ
- SLO導入の背景と必要性
- コンセプト設計：「仮想SLA」＝「当たり前品質」の担保
- 導入ワークショップ：Biz/Tech/Creativeで合意をつくる3ステップ
- SLO導入支援後の状況と今後の展望
- 本取り組みの広がり（アドベントカレンダー連載）
ごあいさつ
こんにちは。品質推進部の吉次です。 今年のDeveloper＆Designer Advent Calendar 2025の1日目を担当いたします。
私はいくつかの組織に所属していますが、その中でも品質推進部ではエンジニアリング組織全体の品質・生産性向上や、プロセス改善の支援を行っています。
今回は品質推進部の活動の一環として、HR forecasterのコミュニケーション機能（現在は試験的導入中）のチームに対して行った、「仮想SLA（Service Level Agreement; サービスレベル合意）」および「SLO（Service Level Objective; サービスレベル目標）」の導入支援の事例について紹介します。
SLO導入の背景と必要性
HR forecasterは転職サービスdodaに蓄積された求人票などのデータを活用し、採用難易度の見極めや採用要件の作成をサポートするサービスです。 新機能として担当者間のやり取りを一元化するための「コミュニケーション機能」を開発し、一部ユーザーに対して試験導入をおこなっています。
コミュニケーション機能では安定した品質・信頼性が要求されるため、それらの要素を適切にコントロールするべくSLO導入の要望が挙がりました。
導入にあたっては、大きく以下2つの課題がありました。
1. 無料サービスにおけるSLAの取り扱い
HR forecasterは無料サービスであるため、ユーザーと金銭的な補償（返金など）を伴う厳密なSLA（Service Level Agreement）を結ぶことは想定していませんでした。
2. 保証の合意はなくとも信頼性を可視化したい
SLAを結ばないとはいえ、「一定水準の品質が担保されていること」を実績として示せる状態にすることで、安心して利用してもらいたいというニーズがありました。
これらの課題に対するアプローチとして、ユーザーとの契約としての厳密なSLAではなく、自分たちの目標として「仮想SLA」という概念を定義し、その裏付けとしてSLOを導入する方法をとりました。
コンセプト設計：「仮想SLA」＝「当たり前品質」の担保
あるサービスにおいて、「サービスレベル」というワードそのものが意味するところやその妥当性について、対外的に説明したりユーザーに理解してもらうのは案外難しいものです。
一方で、一定水準の品質が担保されていることを実績として示すためには、少なくともサービス提供者側が明確に言語化できている必要があります。
まずはチーム全員の目線を合わせるため、「狩野モデル」を用いて、サービスレベルを「当たり前品質」という言葉で定義し直して議論しました。
| 品質の種類 | 充足度と満足度の関係 |
|---|---|
| 当たり前品質 | あって当たり前、ないと不満 |
| 一元的品質 | あれば満足、なければ不満 |
| 魅力的品質 | あれば満足、なくても不満ではない |
私たちは今回のSLO導入の目的を、ユーザーに対して「当たり前品質が担保されていることを示すもの」と位置づけました。 これを踏まえ、チーム内での用語を以下のように整理しました。
- 仮想SLA = 当たり前品質が担保されている状態そのもの
- SLI = 当たり前品質を測定するための指標（ものさし）
- SLO = 当たり前品質として満たされるべき目標値（合格ライン）
また、当たり前品質を担保することの意味について、認識合わせを行いました。
導入ワークショップ：Biz/Tech/Creativeで合意をつくる3ステップ
コンセプトが決まったところで、実際にSLOを策定するためのワークショップを実施しました。エンジニアだけでなく、PMやデザイナーも含めたBiz/Tech/Creative（BTC）のメンバー全員で共通認識を醸成していくことが重要なポイントになります。
STEP1：当たり前品質の言語化
言語化の実践と整理のためのブレインストーミング
最初から「可用性99.9%」といった数字の話はしません。まずはユーザー目線に立ち、「どのような状態であれば、当たり前にサービスを使えていると言えるか」を言語化・整理するためにブレインストーミングを行いました。
具体的な流れは以下のとおりです。
- サービスにとっての当たり前品質が具体的にどんなものかを付箋に書き出す
- 付箋をグルーピングする
- 各グループの特性をラベリングする（応答時間、ユーザビリティ、セキュリティなど）
- 各特性のうち特に大事にしたいものを投票する（何から着手するかという優先度を考えるときに利用）
- 各グループの特性をモニタリングしたり担保する手段をラベリングする（SLO、テストなど）
当たり前品質の言語化の際の注意点
最初のステップである「サービスにとっての当たり前品質が具体的にどんなものかを付箋に書き出す」際には、システム目線ではなくユーザー目線で挙げるよう意識してもらいました。
- ❌ システム目線：メモリ使用率が〇〇%まで上昇したらスケールすること
- ⭕️ ユーザー目線：〇〇機能を使ったときに△△の状態にならないこと
サービスレベルを考えることは、ユーザーにとっての価値を考えることに等しいといっても過言ではありません。したがって、この段階ではシステム内部の細かいメトリクスのことは考えないようにします。
STEP2：SLI選定とSLO定義
当たり前品質が言語化できたら、システムで計測可能な指標（SLI）と目標値（SLO）に落とし込んでいきます。
当たり前品質の特性とモニタリング・担保方法の整理
ブレインストーミングとグルーピングの結果を整理したものがこの表になります。
| 特性 | モニタリング・担保方法 |
|---|---|
| 応答時間 | SLO |
| 可用性 | SLO |
| 収益性 | KPI |
| ユーザビリティ・透明性 | ユーザビリティテスト・ユーザーインタビュー・ヒューリスティック評価 |
| サポート | サポートチケット分析（応答時間・解決時間） |
| 完全性 | テスト（データ整合性） |
| 安定性 | テスト（UT・ST・UAT） |
| コンプラ・セキュリティ | 監査・テスト（脆弱性診断など） |
当たり前品質の中にもSLOでカバーするものとそうでないもの（例えばテストによってカバーされるもの）があることがわかります。 この段階で、どの特性の担保を優先的に取り組むかを決めると良いと思います。
今回のワークでは当たり前品質の中でも「応答時間」と「可用性」がSLOでのモニタリング・担保に適していることが特定できたので、この2つに関する指標をSLIとして扱うこととし、目標値を定義しました。
CUJに対するSLIのマッピング
CUJ（Critical User Journey; クリティカルユーザージャーニー）とは、ユーザーがサービスを利用する際の特に重要で頻繁に行われる一連の体験です。
ユーザーが行うすべてのアクションや、ユーザーがたどるすべてのパスに対してSLOを定めるのは現実的ではありません。
そこで必要になるのがCUJです。詳細は割愛しますが、自分たちのサービスのCUJにおける、ユーザーにとってのゴールを特定し、その重要なユーザー体験に対して指標（SLI）をマッピングして、目標（SLO）を設定するのが王道の流れです。
HR forecasterコミュニケーション機能においては以下のようなマッピングを行いました（一部抜粋）。
| ゴール | 価値 | 可用性 | 応答速度 | 備考 |
|---|---|---|---|---|
| 企業チャンネル一覧を確認する | ◯ | |||
| 求人タグを作成する | ストック | ◯ | ||
| メッセージを送信する | フロー | ◎ | 誤送信予防として送信確定までに10s待つ仕様なので送信の応答速度を測る価値はそれほど大きくない | |
| メッセージの送信をキャンセルする | フロー | ◯ | ||
| メッセージを確認する（受信） | フロー | ◎ | ◎ | 直近のもの |
CUJとSLIのマッピングを行う際には以下のようなポイントに注意して進めました。
各ゴールの価値を明らかにする
- フロー: 「今」コミュニケーションが取れることの価値
- ストック: 情報が蓄積されていることによる「未来」に得られる価値
各ゴールのSLIとして可用性・応答速度をモニタリングすることにどの程度の価値があるかを明らかにする
- SLIの選定根拠を残しておく
SLOの定義
次に、選んだゴール・SLIに対しての目標値を定めます。 決定までの過程は割愛しますが、例としてメッセージ送受信の可用性に関しては以下のよう定めました。
| カテゴリ（SLIの種類） | SLI | SLO |
|---|---|---|
| 可用性 | HTTPリクエストが成功した比率 ・良いリクエスト = ステータスコード2xx ・悪いリクエスト = ステータスコード5xx |
試験導入版 99.5% 製品版 99.9% |
STEP3：エラーバジェットポリシーの策定
SLOを実際に運用するフェーズになった際に最も大切なのが「目標を達成できなさそうな状況になった時にどうするか」の合意です。ここで「エラーバジェット（失敗の許容量）」の概念を導入しました。
こちらはエラーバジェットが実際の動きの一例です。
エラーバジェットが枯渇することは、当たり前品質が損なわれている状態を意味します。そういった状況でチームがどう行動するかを「エラーバジェットポリシー」として明文化しました。
エラーバジェットポリシーの構成要素と関係者間での合意
こちらも決定までの詳細は割愛しますが、エラーバジェットの構成要素と関係者間で合意形成する意義について簡単に紹介します。
まずは、「エラーバジェット消費ポリシー」です。
簡単に言うと、ある時点での「残りの残高」で判断する消費量ベースのポリシーと、「このままの消費速度のままだといつ枯渇するか」という観点で判断をする速度ベースのポリシーがあります。
両方採用することもありますが、このあたりは運用のしやすさや開発スタイルなどを考慮して選択すると良いと思います。
次に、「エラーバジェット超過ポリシー」です。
エラーバジェット消費ポリシーが「バジェット減少中」に適用されるのに対し、エラーバジェット超過ポリシーは、実際にバジェットが枯渇してしまった場合に適用されるものになります。
有料サービスで特定の期間においてSLAに違反してしまった場合などは、ユーザーへの保証なども発生してきます。例としては次のようなことを定めます。
最後に、関係者間での合意についてです。いくら立派なポリシーを定めても、関係者間での合意が得られてなければ実際のアクションを起こすことはできません。
エラーバジェットポリシーに対する所有・同意の関係性の例としてはこのようなものになります。
どんな状況でどう動くかを「なんとなく」ではなく、ポリシーとしてドキュメント化し、関係者全員で合意しておくことが、迷いのない運用・迅速なアクションに繋がる第一歩だと考えています。
SLO導入支援後の状況と今後の展望
HR forecasterコミュニケーション機能チームの状況と今後
HR forecasterコミュニケーション機能では、ここまで紹介したようなワークを通して、SLOの運用に必要な情報をまとめて「SLO定義ドキュメント」を作成し、現在はトライアル運用を行っています。
SLO定義ドキュメントはSLOを継続的に運用していくために必要不可欠なものですので、別の機会に詳しく説明したいと思っています。
もちろん、一度決めたSLOは恒久的なものではありません。サービスに追加される機能・成熟度やユーザー増加・利用の状況に合わせて、定期的に見直すサイクルも設計に組み込んでいます。
トライアル運用でチームにSLOを馴染ませた先には、CUJをより広範囲にカバーするためにSLI/SLOを追加したり、より正確なメトリクスが得られるような計装の改善を行ったりすることを見込んでいます。
品質推進部としての今後
今後は全社的に社内事例を増やして、各チームが自律的にSLOを運用することで、価値の高いサービスを安定して提供し続けられるチームを最大限増やすことを目標に掲げています。 その目標に向かってできること・やるべきことを一つ一つこなしていく、というのが品質推進部の目下のミッションです。
本取り組みの広がり（アドベントカレンダー連載）
本記事では、支援側である品質推進部の視点から「導入の型」についてお話ししました。 しかし、実際に運用するのは現場のチームです。「現場ではどう感じたのか？」「他チームへはどう広がったのか？」といったリアルなストーリーについては、今回のアドベントカレンダーの別記事にて詳しく紹介されています。ぜひ併せてご覧ください。
PERSOL MIRAIZのプロダクト主導によるSLO策定について（2025/12/3公開予定）
- 今回の導入プログラムも参考にしつつ、エンジニアが主体となって自律的にSLO導入を推進したPERSOL MIRAIZチームの事例です。HR forecasterとは異なる状況とアプローチが興味深い内容です。
SLO導入支援を受けてみた現場のリアル（2025/12/16公開予定）
- 導入支援対象となったHR forecasterチームの視点から、ワークショップでの気づきや、自分たちのサービスに合わせてどう運用を工夫しているかが綴られています。現場でのリアルが垣間見える内容です。
吉次 洋毅 Hiroki Yoshitsugu
プロダクト&マーケティング事業本部クライアントプロダクト本部テクノロジー統括部 兼 ITガバナンス本部ITアーキテクチャ統括部品質推進部品質推進グループ シニアエンジニア
2014年に高専専攻科を修了後、飲食店検索サービスを提供するWeb企業に入社。バックエンドの領域の開発やプロジェクトマネジメントに従事。2016年にインテリジェンス（現パーソルキャリア）に入社。doda AIジョブサーチ、Salariesなどの開発を経て、現在はdoda法人向けプロダクトの開発や組織横断の品質課題解決・文化醸成に取り組んでいる。
※2025年12月現在の情報です。
