マネーフォワードにおける SLO の取り組み ~ CUJ、SLI、SLO 策定の実際

こんにちは。この記事では、株式会社マネーフォワード Platform and Reliability部 SRE による活動を紹介します。 
弊社では、60 以上のプロダクトを展開しています。特に私が関わっているのは、マネーフォワード クラウドです。これは、経理財務・人事労務・法務・個人事業主といったバックオフィス全体をシームレスに連携し、面倒な手作業を自動化するクラウドサービスです。

今回は、CUJ (Critical User Journey) と SLI/SLO (Service Level Indicator/Service Level Objective) の取り組みを紹介します。  

はじめに共通で実施している取り組み方法を紹介し、後に個別サービス担当者による具体的な内容を紹介します。  
また、すべてのサービスを掲載するのは難しいため、マネーフォワード クラウドシリーズの特性の違うサービスを一部ご紹介します。ひとつはマネーフォワード クラウドの人事労務領域のサービス、もうひとつは会計領域のサービス、開発拠点が異なるチームのサービス、最後に社内向け基盤についてです。

X ポスト » | Facebook シェア » | はてブ »

builders.flash メールメンバー登録で、毎月の最新アップデート情報とともに、AWS を無料でお試しいただけるクレジットコードを受け取ることができます。

私たちにとって CUJ は、ユーザーがサービスを使って目的を達成するための一連の流れのことを指します。ユーザーが辿って欲しいストーリーを考えることで、いくつかの重要な CUJ を見つけます。その CUJ は、開発者や SRE の優先順位付けにも利用できるでしょう。

例えば、「自動販売機」で考えてみます。「お金を入れる→商品を選ぶ→欲しい商品のボタンを押す→商品が出る→ (（お釣りがあれば出る)）」という一連の処理は、CUJ のひとつとなるでしょう。これができなければユーザーは自動販売機に利用価値を見いだせません。仮にお金を入れても商品が出なければ困るし、もっというとお金を受け付けてくれなかったりするとその自動販売機で購入することを断念することもあります。  

ただし、自動販売機によっては CUJ の処理が異なることを忘れてはいけません。ガチャのような自動販売機では、CUJ に商品が選べることよりも「何が出るかわからないようになっている」ことのほうが重要です。このように、サービス価値によって CUJ は異なります。

CUJ を探すにあたって、SRE と関係者は「ユーザーにとってのプロダクト価値とは ?？」からスタートし、具体的な SLI を測定する方法までをワークショップ形式で検討しています。CUJ のワークショップに参加する関係者は、チームによって異なります。開発者と SRE だけのケースや、CS やデザイナーを交えて議論するチームもあります。  

このCUJについては、事前に知るためにドキュメントを書いたり説明会を開くことで、参加者の認識を揃えて検討を開始します。  

以上の流れは、おおよそ SLO を作成するまでの流れに共通します。以降は各サービスで実施していた実際の内容をご覧ください。

マネーフォワード クラウド勤怠は、様々な勤怠管理を Web 上で完結できるサービスです。打刻はもちろん、有給やシフト管理も可能です。

SLI/SLO を策定する際、導入初期から CUJ ワークショップをしたわけではありませんでした。初回はプロダクトチームとともに、サービスに最も影響があり、明確な指標を利用しました。例えば TOP ページのレイテンシであったり、重要な機能のエラーレートであったりです。

運用が軌道にのったあと、より詳細で重要な SLO を CUJ ワークショップとともに実施しました。私たちが設定した最も重要な SLO は、「打刻機能」にフォーカスしたものです。このサービスで最も重要な機能の一つである打刻を実行するには「打刻ページが開ける」「打刻ボタンが押せる」「打刻レコードが作成される」といった一連の処理が必要です。これらのレイテンシー、エラーレートを SLI とし、「打刻機能」という SLO を設定しています。よりユーザー体験に近づける分、実装コストは高いですがよりコア機能を監視できます。

プロダクトチームはコア機能がもし脅かされた場合、すぐに検知でき、即座に緊急対応が必要であると判断できます。今後はユーザ体験も含めた SLO を増やし、ユーザーの声を拾いやすいような状態にしていく予定です。

マネーフォワード クラウド会計Plus は、仕訳承認・権限管理機能で内部統制に対応した中堅企業や IPO 準備企業向けのクラウド会計ソフトです。

私が配属され SRE チームができた際、SLO は存在していませんでした。サービスの安定性を計測するために SLO の策定を開始。まずはプロダクトオーナーを巻き込みながら、CUJ の議論を進めました。マネーフォワード クラウド会計Plus にとって重要な CUJ は、現時点で「仕訳登録 - 申請 - 承認ができること」「帳票が出力できること」の 2 点です。

SLO の初期導入時、注意深く進めていた点は「目標を下回ったときにアクションが取れるようにすること」です。最初から複雑な SLO を設定するとアクションへ移行することも難しくなり、結果的に SLO が無視されることがあります。これを回避するために、一部の機能では、SLO を下回ってもすぐに改善が難しいレイテンシーは、初期の SLO からあえて省く決断をしています。

初期導入から 3 年が経つと、会計Plus では大規模なユーザーが増えました。主に大規模ユーザーでレイテンシーの運用課題が多発するようになったため、2025 年に SLO のアップデートプロジェクトを行いました。このアップデートにはプロダクトオーナーとの相談のもと、SLO にレイテンシーや、他の指標の追加を行っています。これにより、ユーザー体験を反映できるものに変更されました。

マネーフォワード クラウド会計は、中小企業や個人事業主向けのクラウド会計サービスであり、その主な目的は会計業務のデジタル化と効率化を通じて、ユーザーの経営管理や意思決定を支援することです。もともと本サービスには SLO が存在していたものの、CUJ に基づいておらず、実際の運用にも活かされていない状態でした。

そこで、我々の SRE チームは、開発者や SRE が日々の意思決定に活用できる、実運用可能なレベルの SLO を導入することを目指しました。議論の進め方としては、持続可能性や再現性を考慮し、同期的なミーティングではなく、非同期のドキュメントベースで進行しました。

CUJ の模索には、SRE 側 で こちら を基にテンプレートドキュメントを用意し、それを PdM に埋めてもらう形をとることで、CUJ の洗い出しと優先順位付けを行いました。そのうえで、各 CUJ に対して「どの API が呼ばれているか」「その API がどういう挙動であればユーザーが満足するか」といった観点で SLI の決定を開発者に依頼し、ドキュメントに整理してもらいました。

基本的にはレイテンシーとエラーレートを SLI として用いますが、サービスの特性によってはデータの鮮度や独自メトリクスを見た方が適切なケースもあるため、その点も開発者の知見を踏まえて検討しました。実装は原則として開発者に依頼しましたが、場合によっては、SRE 側で一部を実装し、その内容については開発者にレビューを依頼する形で協力体制を築きました。

現時点では初期段階の SLO が定まったところですが、今後は定期的なレビューを通じて SLI/SLO の見直しを行い、実際のサービス運営や意思決定に活用できるレベルまで成熟させていく予定です。

社内向けワークフロー基盤は、マネーフォワード クラウドシリーズ共通のワークフロー機能をマイクロフロントエンドとして提供しています。これにより、各プロダクトは個別にワークフロー機能を実装する必要がなくなり、開発効率の向上とプロダクト間での一貫性のあるユーザー体験を実現しています。

SLO 策定においては、初期構築時にプロダクトマネージャーも含んで CUJ ワークショップを実施し、ユーザーにとっての重要な価値を議論して決定しました。最終的に CUJ は基本機能である「申請者が申請できること」「承認者が承認できること」「管理者がマスターデータを管理できること」の 3 点に落ち着きました。

次に、これらの基本機能を実現するために必要な GraphQL オペレーションを特定し、それぞれのオペレーションにおけるエラーレートとレスポンスタイムを SLI として計測することにしました。  

議論の過程では、「究極的にはエンドユーザーが実際にサービスを使えているかを正確に表すには、フロントエンドの状態を監視するべきではないか ?」という意見も出ました。たしかに、ユーザー体験を正確に捉えるにはその通りなのですが、まずは実装しやすいバックエンドでのステータスから見ていくことにしました。将来的には、フロントエンドの監視も視野に入れ、よりユーザー視点に立った SLO を確立していきたいと考えています。

ご紹介した例はマネーフォワードでもごく一部の例です。多数のプロダクトを抱えている場合、サンプルとなるテンプレートやワークショップがあると様々なチームに展開しやすくなります。実際このように展開されているところを見ると、作成してよかったなと思っています。

それぞれの組織に合わせて応用可能ですので、ぜひ参考にしてみてください。