労務管理からタレントマネジメントへ、急成長するSmartHRの現在地

── はじめに、SmartHR様の事業の現在地についてお聞かせください。

SmartHRは、生まれた当初は「労務管理」のプロダクトでしたが、従業員情報が集まる正確なデータベースという強みを活かし、現在は人事評価などの「タレントマネジメント」領域へも機能を広げています。

注力している顧客層としては、大企業になります。一般的なSaaSは中小企業への導入から始まることが多いですが、SmartHRは大企業でも使われるものを目指しています。今後は特に、給与や情報システム領域、そしてAIによる業務効率化といった人的資本経営に資する分野に力を入れていきたいと考えています。

── 佐藤様の役割と、所属されているSREユニットについて教えてください。

私はSREユニットでユニット長を務めています。SREユニット自体は2024年1月に立ち上がった組織で、現在は4名のメンバーで、社内に30個ほどあるプロダクトチームを横断的に支援しています。

「属人的な判断」からの脱却、大規模障害が変えた意識

── SREチームが立ち上がる以前、現場ではサービスの信頼性に対してどのような課題感を持たれていたのでしょうか。

最大の課題は、信頼性に対する判断が「属人的」になっていたことです。例えばレイテンシー（反応速度）が悪化したり、お客様からの問い合わせがあったりした場合でも、それに対応するかどうかは、その時の担当者の判断に委ねられていました。

組織として対処するかどうかを決める仕組みや、定量的な判断軸がなく、どうしても「お客様が本当に困っていそうか」といった個人の感覚で判断してしまっていた部分がありました。

── そこでSLOの導入が進んだのですね。

最初は私を中心にSLOに詳しいメンバーたちで、SRE立ち上げ当初（2024年初頭）から「SLOを入れてみないか」と提案し、仮運用を始めていました。しかし、当時はSLO違反を検知しても「何もできない」状態が続いてしまいました。

チーム全体として「とにかく機能を提供したい」という思いが強く、信頼性の問題に対して「そろそろヤバそうだ」とアラートが出ても、うまく開発プロセスの中に改善アクションを組み込めなかったのです。

── その後、本格的な運用へ舵を切ったきっかけは何だったのでしょうか。

大きな転機となったのは、2024年に経験した、システムの障害です。複数の障害が連続して発生し、サービスが安定しない時期に、多くのお客様にご迷惑をおかけしてしまいました。これについては、社内的にも非常に重く受け止めました。

あの障害を受け、ポストモーテム（事後検証）を行う中で、「技術的な課題に気づいていたにも関わらず、対応しきれずに保持し続けてしまった」ことが根本的な原因ではないかという議論になりました。

そこで、仮運用だったSLOを正式に導入し、今までの状況を改善しようという決定に至りました。以前は問い合わせが来るまで動けなかった状態から、SLOを基準に自分たちで予兆に気づき、対応できる体制へと本格的に舵を切ったのです。

信頼性向上のための基盤としてNew Relic活用と従量課金移行がもたらしたもの

── 信頼性向上のための基盤として、既存のNew Relicをそのまま活用することに決めた理由は何だったのでしょうか。

まず機能面で言えば、SLOの策定に必要なデータがすでにNew Relic上に蓄積されていたことが大きいです。New Relicは特定のトランザクションとアラートを紐づけて監視設定ができるため、我々がやりたかった「ユーザー体験に基づいたSLO計測」に非常に適していました。

また、本格運用に踏み切れた要因の一つは、ツール自体の機能もさることながら、「料金体系の変更」にありました。

── 新しい料金体系に変わったことで、使いやすくなった部分はありますか?

これは本当に劇的な変化でした。以前のユーザーベース課金だと社内で見られるユーザーを限定しており、情報の格差が起きていました。そこがSLOを意思決定に使う際のボトルネックになっていたのです。

CCU（処理したアクション量）ベースの課金に移行したことで、利用者は約30名程度から100名近くにまで増えました。これまでは「誰かに頼んで見てもらうツール」だったのが、「みんなが見る当たり前のインフラ」に変わりました。

開発者全員が同じダッシュボードを見て、自分たちのサービスの健康状態をリアルタイムに把握できるようになりました。これは、SLOを文化として根付かせる上で、非常に大きな一歩だったと感じています。

「SLO星取り表」と「伴走」で文化を作る

── 開発チームへ運用を広げていくにあたって、進めるのが難しかった課題はありましたか?

一番大きかったのは、そもそも理解してもらうのが難しかったことです。「SLOを作ります」と言うと、今まで機能開発にフル投資していた現場からは「開発に制約ができるのではないか」という懸念を持たれることもありました。

最終的には、「SLOはあくまで意思決定のためのツールです」と説明しました。信頼性が切迫していれば対応するし、余裕があるなら機能開発を進めていい。その判断を行うためのツールで、目標値は状況によって緩めたり厳しくしたりしてもよい、と伝えることで理解を得ていきました。

── 理解が進んだあとでも文化として根付かせるには工夫が必要かと思います。実践されたところをお伺いできますか。

そうですね、運用してもらうにはギャップがあります。そこで、「SLO運用ガイド」という手順書や、運用の定着度合いを可視化する「SLO星取り表」を作りました。加えて、SREメンバーが各チームに入り込み、週1回の振り返り会に伴走することで、定着を図っています。

＜実際に運用で使われている「SLO星取り表」のSTEP1＞


＜実際に運用で使われている「SLO星取り表」のSTEP2＞

Terraform活用で設定のハードルを下げる

── その他に、現場のエンジニアが使いやすくするための工夫はありましたか？

技術的な工夫として、SLOの設定をTerraformで管理できるようにしました。New Relicは画面上で設定することもできますが、数十あるチームが手動で設定していくのは非常に大変ですし、手順書を作るのも面倒です。

そこで、Terraformのコードをコピペして、一部を書き換えるだけで設定が作れるような仕組みを用意しました。これにより、導入のハードルを大きく下げることができたのが良かった点だと思っています。

経営層の理解を得た「信頼性への投資」の重要性

── ビジネスサイドや経営層の反応はいかがでしょうか。

非常にポジティブな反応をいただいています。SREチーム主導で取り組みを進めていく中で、我々のいる本部全体としても「SLO、いいじゃないか。やっていこう」という空気になり、トップから「全チームでこのSLOを入れていきましょう」と言っていただいた。

これがすごく良かった点だと思います。トップダウンで「全チームでやろう」と後押ししてもらえたことで、現場も動きやすくなりました。



── 経営層に対して、ツールのコストやROIについてはどのようにお話しされていますか？

ROIの説明は難しい部分ですが、やはり24年の障害がきっかけとして大きかったです。あの障害はお客様に多大なご迷惑をおかけしましたし、会社としても損失がありました。

「そういった事態を防ぐためにやるんだ」という説明で、理解を得られています。中長期的には、ユーザーの信頼を獲得し、サービスを継続利用していただく、あるいはアップセルに繋げていく上でも、信頼性の担保は重要だと考えています。

「攻めのSRE」に向けたNew Relicへの期待

── 今後の展望や、New Relicへの期待についてお聞かせください。

SLOの運用は軌道に乗り始めましたが、まだ道半ばです。30個あるチームのうち、運用が定着しているのは半分程度ですので、これを全チームに広げていくのが直近の目標です。

その先に見据えているのは、New Relicの機能をさらに活用した「運用の効率化」です。現在は基本的なHTTPレスポンスの監視が中心ですが、New Relicを活用してバックグラウンドジョブやスマホアプリのレスポンスなど、監視領域を広げていきたいと考えています。

制作協力：New Relic株式会社