IVRyエンジニア忘年LT大会2024 クリティカルユーザージャーニーの整理

Transcript

1. クリティカルユーザージャーニーの整理 ~対話型⾳声AI SaaS IVRyの場合~ 2024/12/11 IVRyエンジニア忘年LT⼤会2024（5min） abnoumaru @ IVRy Inc.
2. ⾃⼰紹介 - 2024年10⽉ IVRy ⼊社 - 今やっている仕事 - SREのプラクティスのひとつであるSLO導⼊（4Q） - キャパシティについて考えたり - … id: abnoumaru 2 Engineer Circle / Platform Team
3. SRE？🦎
4. ユーザに届けたい価値が 適切に届いてるか？🤔 4
5. サービスの信頼性に関⼼👀 5
6. 過度に⾼い信頼性はコストに跳ねるので 開発と運⽤のバランスを取りたい 100%を⽬指します！は難しいし維持しようとするためにコストがかかる サービスを守るためにリリースしません！も本末転倒 6
7. IVRyがユーザに届ける価値🌟
8. 対話型⾳声AI SaaS IVRy 8 ⽉額2,980円からカスタム電話をカンタンに作成できるサービス 全ての電話業務を誰でもすぐにAIを使って効率化できます
9. 業態に合わせた⾃由な応答設定 9 ダイヤルプッシュとAIの対話をハイブリッドで設定し、 受けたい電話と⾃動化したい電話を分類。電話業務を効率化できる
10. ユーザに価値が届いているか？ システム⽬線でも数値にできると嬉しい🎁 10
11. SLO📉
12. SLI/SLO 12 SLI(Service Level Indicator) サービスレベル指標 ◦ 何をもとにシステムの良し悪しを判断するかの指標となるもの ◦ SLO を定義する時に利⽤する ◦ ex. ユーザのリクエストに対して正常に応答（ 5xx以外のアクセス）した割合を SLIとする SLO (Service Level Objective) サービスレベル⽬標 ◦ サービスレベルに対する内的な⽬標値 ◦ ex. 前述のSLIが99.9%満たされていることSLOとする Site Reliability Engineering: How Google Runs Production Systems. （2016） O'Reilly Media. （Niall Richard Murphy 他 玉川 竜司 訳 SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム （2017）オライリージャパン） 3.4.1 エラーバジェットの形成、 4.1 サービスレベルに関する用語 ・Google - Site Reliability Engineering https://sre.google/sre-book/part-II-principles/ （参照 2022/11/14）
13. SLOを策定することで 期待通りユーザに価値が届いてるか？ ⽬指したいサービスレベルを保てているか？ 社内で共通の物差しを持つイメージ💡 13
14. 個⼈的な悩み☹
15. 情報が溢れているわけではないので みんなどうやってSLOを策定しているか... その過程を⾒てみたい！！！！ 15
16. 今⽇のお題󰞽
17. IVRyではSLO策定に必要な クリティカルユーザージャーニーを どう整理したか？ 17
18. どう進めたか？はこの前発表しました 18 https://speakerdeck.com/abnoumaru/yurusremian-qiang-hui-number-8-zu-zhi-de-nisregashi-maruzhong-deyi-shi-sitakoto?slide=21
19. クリティカルユーザージャーニー󰩤
20. クリティカルユーザージャーニー 20 ユーザーがウェブサイトで⽬的を達成（＝提供したい価値）するために たどる特定のユーザー操作や経路のセット ECサイトの場合 ログイン→商品検索→カートに追加→購⼊⼿続きページに移動→購⼊⼿続き https://cloud.google.com/architecture/framework/reliability/choose-slis?hl=ja
21. SLOは クリティカルユーザージャーニー（以後CUJ） に基づくのが理想 21 https://cloud.google.com/architecture/framework/reliability/choose-slis?hl=ja
22. IVRyのCUJ 22 エンドユーザ側の電話応答とクライアント側の設定画⾯で 各々CUJがある エンドユーザー側 電話応答 クライアント側の 設定画⾯ （ルール設定‧履歴確認‧各種設定...）
23. 電話応答のジャーニー 23 架電→案内の再⽣→プッシュによる分岐...とステップバイステップで⾏われる 機能提供のために存在するエンドポイントは⽐較的シンプル ↓ 電話応答のエンドポイントはまとめてひとつの 電話体験というCUJとしてユーザの操作を洗い出す
24. 設定画⾯のジャーニー 24 多機能でありユーザ毎にユースケースは異なる ↓ 「これがCUJ！」が難しい https://ivry.jp/
25. サービスに合う形で⼀旦定義 25 CUJに沿い⼀連に流れにすることはあくまで理想と割り切り 特定の⽬的を達成する個別機能毎に分けて エンドポイントをグルーピングする （電話履歴関連、ルール設定関連、電話帳関連...） アクセス頻度や提供したい価値⽬線でざっくりとした優先度は決まるので グループ毎段階的にSLOの数を増やして実際に眺めながら 今後の⽅針を検討していくことにした https://cloud.google.com/architecture/framework/reliability/choose-slis?hl=ja
26. 出来上がったSLOのダッシュボード 26 Datadog APMとSLOを利⽤している ⾒やすくていい👍 仮置きの数字で週次確認して違反していたらなぜ？と会話が始まったの嬉しい🎉
27. 感想 27 プラクティスに縛られすぎず完璧じゃなくても サービスに合う形でうまく利⽤していきたい 設定してみると気づきがあり会話が⽣まれる CUJを把握する過程で様々な⼈とコミュニケーションする必要があり これから担当するサービスについて知ることができる嬉しさある