Tweet
Tweet

Slide 1

Slide 1 text

クリティカルユーザージャーニーの整理 ~対話型⾳声AI SaaS IVRyの場合~ 2024/12/11 IVRyエンジニア忘年LT⼤会2024（5min） abnoumaru @ IVRy Inc.

Slide 2

Slide 2 text

⾃⼰紹介 - 2024年10⽉ IVRy ⼊社 - 今やっている仕事 - SREのプラクティスのひとつであるSLO導⼊（4Q） - キャパシティについて考えたり - … id: abnoumaru 2 Engineer Circle / Platform Team

Slide 3

Slide 3 text

SRE？🦎

Slide 4

Slide 4 text

ユーザに届けたい価値が 適切に届いてるか？🤔 4

Slide 5

Slide 5 text

サービスの信頼性に関⼼👀 5

Slide 6

Slide 6 text

過度に⾼い信頼性はコストに跳ねるので 開発と運⽤のバランスを取りたい 100%を⽬指します！は難しいし維持しようとするためにコストがかかる サービスを守るためにリリースしません！も本末転倒 6

Slide 7

Slide 7 text

IVRyがユーザに届ける価値🌟

Slide 8

Slide 8 text

対話型⾳声AI SaaS IVRy 8 ⽉額2,980円からカスタム電話をカンタンに作成できるサービス 全ての電話業務を誰でもすぐにAIを使って効率化できます

Slide 9

Slide 9 text

業態に合わせた⾃由な応答設定 9 ダイヤルプッシュとAIの対話をハイブリッドで設定し、 受けたい電話と⾃動化したい電話を分類。電話業務を効率化できる

Slide 10

Slide 10 text

ユーザに価値が届いているか？ システム⽬線でも数値にできると嬉しい🎁 10

Slide 11

Slide 11 text

SLO📉

Slide 12

Slide 12 text

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）

Slide 13

Slide 13 text

SLOを策定することで 期待通りユーザに価値が届いてるか？ ⽬指したいサービスレベルを保てているか？ 社内で共通の物差しを持つイメージ💡 13

Slide 14

Slide 14 text

個⼈的な悩み☹

Slide 15

Slide 15 text

情報が溢れているわけではないので みんなどうやってSLOを策定しているか... その過程を⾒てみたい！！！！ 15

Slide 16

Slide 16 text

今⽇のお題󰞽

Slide 17

Slide 17 text

IVRyではSLO策定に必要な クリティカルユーザージャーニーを どう整理したか？ 17

Slide 18

Slide 18 text

どう進めたか？はこの前発表しました 18 https://speakerdeck.com/abnoumaru/yurusremian-qiang-hui-number-8-zu-zhi-de-nisregashi-maruzhong-deyi-shi-sitakoto?slide=21

Slide 19

Slide 19 text

クリティカルユーザージャーニー󰩤

Slide 20

Slide 20 text

クリティカルユーザージャーニー 20 ユーザーがウェブサイトで⽬的を達成（＝提供したい価値）するために たどる特定のユーザー操作や経路のセット ECサイトの場合 ログイン→商品検索→カートに追加→購⼊⼿続きページに移動→購⼊⼿続き https://cloud.google.com/architecture/framework/reliability/choose-slis?hl=ja

Slide 21

Slide 21 text

SLOは クリティカルユーザージャーニー（以後CUJ） に基づくのが理想 21 https://cloud.google.com/architecture/framework/reliability/choose-slis?hl=ja

Slide 22

Slide 22 text

IVRyのCUJ 22 エンドユーザ側の電話応答とクライアント側の設定画⾯で 各々CUJがある エンドユーザー側 電話応答 クライアント側の 設定画⾯ （ルール設定‧履歴確認‧各種設定...）

Slide 23

Slide 23 text

電話応答のジャーニー 23 架電→案内の再⽣→プッシュによる分岐...とステップバイステップで⾏われる 機能提供のために存在するエンドポイントは⽐較的シンプル ↓ 電話応答のエンドポイントはまとめてひとつの 電話体験というCUJとしてユーザの操作を洗い出す

Slide 24

Slide 24 text

設定画⾯のジャーニー 24 多機能でありユーザ毎にユースケースは異なる ↓ 「これがCUJ！」が難しい https://ivry.jp/

Slide 25

Slide 25 text

サービスに合う形で⼀旦定義 25 CUJに沿い⼀連に流れにすることはあくまで理想と割り切り 特定の⽬的を達成する個別機能毎に分けて エンドポイントをグルーピングする （電話履歴関連、ルール設定関連、電話帳関連...） アクセス頻度や提供したい価値⽬線でざっくりとした優先度は決まるので グループ毎段階的にSLOの数を増やして実際に眺めながら 今後の⽅針を検討していくことにした https://cloud.google.com/architecture/framework/reliability/choose-slis?hl=ja

Slide 26

Slide 26 text

出来上がったSLOのダッシュボード 26 Datadog APMとSLOを利⽤している ⾒やすくていい👍 仮置きの数字で週次確認して違反していたらなぜ？と会話が始まったの嬉しい🎉

Slide 27

Slide 27 text

感想 27 プラクティスに縛られすぎず完璧じゃなくても サービスに合う形でうまく利⽤していきたい 設定してみると気づきがあり会話が⽣まれる CUJを把握する過程で様々な⼈とコミュニケーションする必要があり これから担当するサービスについて知ることができる嬉しさある