正確で追跡可能な指標でCUJインシデント優先度を決めよう　モバイルアプリの信頼性を担保するために

モバイルアプリのサービスレベルを考える

中尾俊介氏：次は、ここまで話したDevOpsのエッセンスとSREのプラクティスを用いて、モニタリングとオブザーバビリティを実現するサービスレベルについて、どうモバイルアプリに当てはめられるかを一緒に考えていこうと思います。

（スライドを示して）サービスレベルはそもそも何なのかですが、そのサービスがエンドユーザーに対して期待されるサービスを正しく提供できているかという度合いや、測定値を示すものかなと思っています。それに関係するものとして次の3つがSREの中で定義されています。

SLIですね、Service Level Indicators。これはサービスレベルを示す具体的な定量指標を指します。SLOは、サービスが達成すべきサービスレベルの目標値を指します。SLAは、補足として説明をすると、サービスレベルに関してユーザーとの間で取り交わす契約になります。これらはそれぞれ先ほどお話ししたSREのプラクティスで、エラーバジェットによる許容と苦労と信頼性の計測を実現するための道具みたいなものですね。

今の話を聞いて、なんとなくCrash Free Rateと近いかなと思った方もいらっしゃるかなと思います。実際にSLI/SLOとしてCrash Free Rateを見ている現場も多いんじゃないかなと思っています。確かにモバイルアプリ開発におけるCrash Free Rateは、SLIとして有効な指標です。クラッシュはアプリにおいては最悪な体験になるので、そこを見るのは間違っていないかなと思っています。

SREの中でのSLI/SLOの定義をどう決めればいいのかを確認した上で、モバイルアプリにおけるSLI/SLOはどう決めるのがベストなのか。Crash Free Rateはそれに沿っているのかみたいなところを、これから見ていきます。

SLI/SLOはどう決めればいいのか

（スライドを示して）SLI/SLOをどう決めたらいいのかは、結論から言うと、原点のSREブックに書いてあって、プロダクトです。「サービスのコレクションに基づいてSLOを開発して、ユーザーがそのプロダクトを行うもっとも重要なインタラクションに焦点を合わせて定義すること」と書いてあります。

そこの一文に書いてある、よくある間違いとして、フロントエンド、バックエンドで個別のサービスでSLOを定めることとあります。

ここのユーザーがこのプロダクトと行うもっとも重要なインタラクションは、SREの中でクリティカル・ユーザージャーニーという名前が付けられています。これは、そのサービスの顧客満足度に直結する、サービスにおける重要なユーザージャーニーのことです。

ここは具体例で説明したほうがわかりやすいと思うので、例を出してみます。コード決済アプリを具体例としてクリティカル・ユーザージャーニーの例を提示してみようと思います。

コード決済アプリはそのビジネスモデルにおいても、ユーザー体験においても、その価値はスマホでQRコードを見せるだけで決済ができるというところかなと思っています。

事業にとっては、この決済によって発生する手数料がマネタイズポイントになるかと思います。そしてその市場における決済手段のうち、自社QRコード決済アプリのシェアを獲得することによって売上を拡大するところが目的になるかなと思います。

一方、ユーザーにとっては現金払いやクレカ払いなど、他の決済手段に感じている不満をQRコード決済で解決して、日々の消費行動をより良くすることが目的にあるかなと思っています。

そのための、両者にとってもっとも重要な価値である、QRコードを見せるだけで決済ができるという機能はクリティカル・ユーザージャーニーになり得るかなと思っています。その具体的なユーザージャーニーは、ここに示しているような、正常系みたいなものを付けていますが、そこに書いてあるような流れかなと思っています。

SLI/SLOでは、これが本番環境でちゃんと担保できているのかを、ちゃんとモニタリングして見れる必要があるよねというのが語られています。

（スライドを示して）この正常系の一方で、正常なユーザージャーニーを崩すパターンもあります。それはどういうケースなのかを確認してみましょう。ここに挙げているのは一例ですが、例えばQRコードをスキャンしたあとの決済リクエストで失敗するとか、あるいはその前のQRコードの表示とか、読み取る時点で失敗するとかがあります。これは自分がそのユーザー目線に立ってみても、遭遇したくない嫌な体験だと思います。

SLI/SLOではここを見ようねという話ですね。プロダクトが正常にクリティカル・ユーザージャーニーを提供できているか。仮に提供できていない場合は、その影響規模はどの程度かを定量的に計測することで、プロダクトの運用状況を判断できるようにします。ここに示したようなクリティカル・ユーザージャーニーの達成を阻害する状況は、ユーザーがサービスに対してもっとも信頼を失うリスクが高いものになります。

このような事態が発生した時は、SLI/SLOを用いることで、開発側は他のことよりも優先して取り組まなければならないという判断ができるかなと思います。

クラッシュはCUJを阻害する要因のひとつにすぎない

というところで、今話した、SLI/SLOではクリティカル・ユーザージャーニーが担保されているかどうかを測定すると考えた時に、先ほどの話にもありましたが、Crash Free Rateはどうなのかを考えてみます。

これはいろいろと意見があると思いますが、私自身の意見としてはCrash Free Rateだけでは不十分かなと考えています。なぜかというと、クリティカル・ユーザージャーニーを阻害する要因は何もクラッシュだけではないからですね。エラーが発生するとか、読み込みが終わらないとか、クラッシュはしないものの、機能が正常に動作していないとか、他にもいろいろと阻害される要因は考えられるかなと思います。

とはいえクラッシュは、やはりアプリにおいて最悪な体験であることは変わりないので、最低限クラッシュを見るのは間違っていないかなと思っています。ここは優先度を付けた上で、クラッシュ以外も加味したほうがいいかもというのをお伝えしたいです。

まとめると、クリティカル・ユーザージャーニーを正常に達成しているユーザーと、そうでないユーザーを測定してモニタリングツールを通して、日々サービスレベルの異常をモニタリングしていくことが重要です。

「DMMポイントクラブ」ではどうしているか

長々と話をしてしまったのですが、最後は私が担当しているDMMポイントクラブではどうしているのかを、簡単に事例紹介をして終わろうかなと思います。

DMMポイントクラブでは、工数的な都合もあるのでそこまで特別なことはできていないのですが、Crash Free Rateを見る以外では、「Firebase Performance」を通してクラッシュ以外でクリティカル・ユーザージャーニーが達成できなかったユーザーを追跡しています。

Firebase Performanceでユーザーインタラクションから発生するプレゼンテーションの処理が、ちゃんと成功したか失敗したかをトレースして、そのトレースデータをBigQueryにエクスポートして、そのBigQueryからスプレッドシートにインポートしてビジュアライズする構成になっています。

そして見ているSLIのうち、SLOを設定していないものもあるのですが、SLOを設定しているものはCrash Free RateとError Alert Free Rateの2つを運用しています。Error Alert Free Rateに関しては完全に造語で、たぶんうちでしか扱っていない指標だと思います。

Error Alert Free Rateは、ユーザーがアプリを操作する中でエラーアラートが表示された割合を示しています。完全にCrash Free Rateのクラッシュをエラーアラートに置き換えたみたいなものですね。このError Alert Free Rateを急降下するとどうなるかというと、それだけ、その日その機能を使ったユーザーの多くがエラーに遭遇した。すなわち、ユーザーのユーザージャーニーを阻害したという証明になるかなと思います。

この2つに優先度を付けて日々、DMMポイントクラブのiOS開発ではモニタリングをしています。それぞれ検知した問題はクリティカル・ユーザージャーニーに直結するかどうかと、サービスレベルの下がり幅で今すぐ解決すべき問題かどうかを判断する運用を取っています。

というところで、最後にまとめに入っていきます。（スライドを示して）この発表で伝えたかったことは、次の3つです。1つ目は、DevOpsの具体的なプラクティスがSREです。SLI/SLOを用いた失敗の許容によって、開発速度とオペレーションを両立しましょうというところです。2番目は、SLI/SLOではクリティカル・ユーザージャーニーを追跡可能な正確な指標を測って、問題・インシデントのトリアージをしましょうというところです。

3番目は、クリティカル・ユーザージャーニーを阻害する要因は何もクラッシュだけではないので、ユーザーがアプリに対しても行うもっとも重要なインタラクションを考えて、SLI/SLOを設計しましょうというところですね。

この3つが、このセッションで伝えたかったことになります。ここまでお付き合いいただき、ありがとうございました。発表は以上となります。ご清聴ありがとうございました。