Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
見えないユーザの声はログに埋もれている! ~ログから具体的なユーザの体験を数値化した事例紹介~
Search
NAVITIME JAPAN
PRO
June 24, 2024
Technology
6
3.2k
見えないユーザの声はログに埋もれている! ~ログから具体的なユーザの体験を数値化した事例紹介~
2024/06/21-22に開催された「スクラムフェス大阪」で発表した資料です
https://www.scrumosaka.org/
NAVITIME JAPAN
PRO
June 24, 2024
Tweet
Share
More Decks by NAVITIME JAPAN
See All by NAVITIME JAPAN
つよつよリーダーが 抜けたらどうする? 〜ナビタイムのAgile⽀援組織の変遷〜
navitimejapan
PRO
23
16k
実践ジオフェンス 効率的に開発するために
navitimejapan
PRO
3
860
安全で使いやすいCarPlayアプリの 魅せ方:HIGと実例から学ぶ
navitimejapan
PRO
1
250
ユーザーのためなら 『デザイン』 以外にも手を伸ばせる
navitimejapan
PRO
2
1.7k
フツーのIT女子が、 Engineering Managerになるまで
navitimejapan
PRO
3
380
不確実性に打ち勝つOKR戦略/How to manage uncertainty with OKR strategy
navitimejapan
PRO
4
3.7k
アジャイルを小さいままで 組織に広める 二周目 / Agile Transformation in NAVITIME JAPAN iteration 2
navitimejapan
PRO
4
1.4k
変更障害率0%よりも「継続的な学習と実験」を価値とする 〜障害を「起こってはならないもの」としていた組織がDirtの実施に至るまで〜 / DevOps Transformation in NAVITIME JAPAN
navitimejapan
PRO
8
5.7k
こうしてふりかえりは終わってしまった / A Demise of a retrospective
navitimejapan
PRO
47
31k
Other Decks in Technology
See All in Technology
因果AIへの招待
sshimizu2006
0
960
大企業でもできる!ボトムアップで拡大させるプラットフォームの作り方
findy_eventslides
1
750
乗りこなせAI駆動開発の波
eltociear
1
1.1k
RAG/Agent開発のアップデートまとめ
taka0709
0
170
ブロックテーマとこれからの WordPress サイト制作 / Toyama WordPress Meetup Vol.81
torounit
0
570
[CMU-DB-2025FALL] Apache Fluss - A Streaming Storage for Real-Time Lakehouse
jark
0
120
Reinforcement Fine-tuning 基礎〜実践まで
ch6noota
0
180
Power of Kiro : あなたの㌔はパワステ搭載ですか?
r3_yamauchi
PRO
0
110
MapKitとオープンデータで実現する地図情報の拡張と可視化
zozotech
PRO
1
140
Debugging Edge AI on Zephyr and Lessons Learned
iotengineer22
0
180
EM歴1年10ヶ月のぼくがぶち当たった苦悩とこれからへ向けて
maaaato
0
270
Karate+Database RiderによるAPI自動テスト導入工数をCline+GitLab MCPを使って2割削減を目指す! / 20251206 Kazuki Takahashi
shift_evolve
PRO
1
720
Featured
See All Featured
Designing for humans not robots
tammielis
254
26k
Building Flexible Design Systems
yeseniaperezcruz
330
39k
Documentation Writing (for coders)
carmenintech
76
5.2k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.4k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
1.1k
Building Applications with DynamoDB
mza
96
6.8k
The Art of Programming - Codeland 2020
erikaheidi
56
14k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
141
34k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
37
2.6k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
16k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
32
2.7k
Transcript
見えないユーザの声は ログに埋もれている! ~ログから具体的なユーザの体験を数値化した事例紹介~ 株式会社ナビタイムジャパン 小南果穂
「よいユーザ体験」は どうやって測る? #1
イテレーティブな開発にはフィードバックが必要 Plan Plan Plan FB FB FB UX UX UX
Develop Develop Develop
ユーザ体験のフィードバックになるもの 定量データ 定性データ
定量データのメリット 離脱率 CV率 • 客観的 • 変遷を継続して観測できる • 説得力があり伝わりやすい 定量データ
定性データのメリット • 数値で表せない具体的な体験を知 ることができる • 感情の動きをつかめる ユーザ テスト インタ ビュー
定性データ
ユーザ体験のフィードバックになるもの 定性データ ユーザ テスト インタ ビュー 本当はすべてのリリースで 両方のフィードバックを得たい が、ユーザテスト・インタビューは 実施難易度が高い
ログを分析することで定性データの代替手段にする
自己紹介 株式会社ナビタイムジャパン 小南 果穂 Kaho Kominami 2019年新卒として入社。 研究開発部門で機械学習を用いた渋滞予測機能である 「AI渋滞予報」などの開発を行うほか、 エンジニアと兼務のスクラムマスターとしてチームの
改善にも取り組んでいる。
実際の 研究開発部門の事例 #2
研究開発部門の抱える課題 NAVITIME バス NAVITIME ドライブ サポーター トラック カーナビ ・・・・ 各サービスのユーザー
研究開発(R&D)部門 各サービスの共通基盤
研究開発部門の抱える課題 各サービスのユーザ ユーザからの距離が遠く、声が届きにくい 研究開発(R&D)部門 各サービスの共通基盤
研究開発部門の抱える課題 研究開発(R&D)部門 各サービスの共通基盤 各サービスのユーザ 研究開発(R&D)部門 所属チームの専門性が高い 渋滞予測 経路探索 時刻表データ 道路
ネットワーク 該当する数が少なく 指標にしづらい
事例をご紹介するチーム:交通情報チーム 車移動に関わるすべての人へ正確な道路交通情報の提供を目指す 渋滞予測
欲しいフィードバックへの道のりは遠い 「渋滞予測は正確に感じられたか?」 「走っている時に困ることはなかったか?」 を数値にしたい・・・・ 渋滞予測精度改善のため数多くの施策をリリース・運用している 精度やUXが悪化していないか日々監視が必要 ユーザボイスは数が少なく不向き ユーザテスト・インタビューを全案件で実施も難しい どうやって?
ユーザの体験そのもの! そこでナビタイムジャパンの強みに注目 日本全国の走行ログ 1日あたり約1,000万km = 地球250周分 (2022年1月時点) ※走行ログはユーザから許可を得て取得し 匿名化しているデータです https://api-sdk.navitime.co.jp/api/
column/use_of_probedata/
ログから抽出する UX評価指標の進化 #3
2018年-2020年 チーム発足、UX指標の数値化を試みる 経路探索チームから交通情報チームが独立 1時間程度走行時、所要時間誤差◦◦分以上のユーザを◦◦%削減 チームの目標
2018年-2020年 チーム発足、UX指標の数値化を試みる 再現 GPSログ ユーザが通った道を再現 出発した時間に渋滞予測した と仮定してシミュレート
2018年-2020年 チーム発足、UX指標の数値化を試みる 再現 8:00出発 9:30 到着予測 10:00到着 2時間の経路で 30分の誤差が発生
2018年-2020年 チーム発足、UX指標の数値化を試みる 本当にこの指標は ユーザの体験を反映させている? 1時間程度走行時、所要時間誤差◦◦分以上のユーザを◦◦%削減 チームの目標
2021年 OKRが導入される 顧客満足度を高める高い交通情報品質 • 「予測より早く到着できた」時より 「渋滞を外して遅れた」時の方がユーザ体験が悪い • 全体最適を重視する指標なので、一部のユーザに効果がある施策への モチベーションが低くなる •
「渋滞を抜けるまでに数時間かかる」ような ユーザ体験が著しく下がる場合に着目したい 昨年度までのふりかえり Objective
「ユーザ体験が著しく悪化するケース」に着目した指標 重点課題区間の合計所要時間誤差を◦◦%以上削減 順調に行けると予測 →実際は渋滞していた が一番不満度が高い = 「重点課題区間」 順調 渋滞 順調
渋滞 予測 実際 KeyResult
さらに進化する評価指標(2022年) 日本一の所要時間精度を実現する • 昨年度までで評価指標の数字自体はかなり良いことがわかっている → ではなぜ「日本一」と自信をもって言い切れないのか → 今までの指標では見つかっていない弱点がどこかにあるはず • 他社比較する計測を行いながらOKRを更新し、弱点であった一般道へのアプ ローチを開始した(詳しくはこちら『不確実性に打ち勝つOKR戦略』) KeyResult
Objective 所要時間精度改善施策◦◦件リリース 一般道の重点課題区間50%削減(下半期追加)
さらに進化する評価指標(2023年) 2022年までは期初に決めた評価期間を対象に評価指標の計測を行っていた 今年は4月の 第二週にしよう 季節性のある イベントがある時は? 台風や大雪の影響は?
日次で改善人数を計測するシステムを構築 誤差が著しく大きいユーザ数 何もリリースしなかった 場合の人数 サービスに出ている 予測での改善人数 リリースによって どの期間に・どの程度 改善があったのか 見ることができる
評価指標もアジャイル的に改善している 2022 2023 2024 ふりかえり ふりかえり ふりかえり
しかし・・・・ まだ評価指標がユーザボイスや社内指摘に あっていないと感じる・・・・ 数字には現れない課題感が依然あった
気を付けなければ いけなかったこと #4
なぜか?はデザイン思考からも説明できる 共感 問題 定義 アイデア 創出 プロト タイプ テスト ユーザ体験についての仮説
評価指標決定 施策の実施 このフェーズをずっと試行錯誤しているが・・・・
「共感」と「問題定義」の違い 共感 問題 定義 サンプリングして深く知る 範囲を広げて分析する
いままでのユーザ体験についての仮説の立て方 共感 問題 定義 多くのユーザを対象に「問題定義」をする 一般化からはじめてしまっている
いままでのユーザ体験についての仮説の立て方 共感 問題 定義 「共感」に戻る 必要があった
2024年度の取り組み ユーザボイスを 深掘りして調査 調査箇所が 評価対象に入るように 実際に投稿された内容や 検索条件・通った道路も 見比べながら どこが原因かを特定
まとめ ユーザテスト・インタビューなどの代替手段として ログからユーザ体験を再現して評価指標にするという手法を提案 仮説を立てる際は実際のユーザボイス等数が少なくても得られる 生のユーザの情報を参照することで仮説の精度を高められる 評価指標には仮説を多く含むため、定期的なふりかえりが必要