3日でプロトタイプを作ったからこそ見えた、改札UXの課題
3つのプロダクトの概要を押さえたところで、野口氏はディスカッションの軸となる3つのテーマを提示した。「現場に出る」「事業に返す（還元する）」「体験をつなぐ」というテーマに沿って、各プロダクトのリアルな開発体験が語られた。
まず、Q SKIPのバックエンド領域を担当する中川武憲氏は、同プロダクトならではの制約から話し始めた。
Q SKIPには、外部ベンダーが担当する改札システムの開発と、URBAN HACKSが担当するアジャイルなアプリ開発が並走するという特有の制約がある。PASMOやSuicaなどの既存サービスも通す改札機に自社サービスを追加するため、すでにある機能へ影響を及ぼさない「守りの役割」は外部ベンダーが担い、ユーザー体験における「攻めの改善」をURBAN HACKSが担当するという役割分担だ。
この役割分担が真価を発揮したのが、複数名でQ SKIPを利用するケースについて検証した際のエピソードだ。代表者1人がスマートフォンで家族や友人の分のチケットも購入し、一緒に改札を通る機能を実装するにあたり、東急電鉄が持つ自動改札機などの駅務機器が設置された試験場で、本番に近いステージング環境を使った検証を行った。
すると、「改札機自体は動くものの、ユーザーの画面にリアルタイムで利用状況が反映されないため、誰のチケットを使ったかがわかりづらい」という課題が、現地検証で初めて明らかになった。当初は改札機の動作確認だけを行う前提でスケジュールを設定していたものの、中川氏らのチームがアプリのUXの確認のためプロトタイプを3日で作り、スケジュール外の検証が実現したことで問題を明らかにすることができた。URBAN HACKSのアジャイルの体制がなければ、本番の駅に設置した後に初めて気づくという事態になっていた可能性がある。中川氏は「我々がUXの確認のため、現場に入ったからこそ問題に気づけました」と振り返る。
さらにQ SKIPチームでは年間100回を超えるリリースを重ねながら、エンジニア自身が覆面で駅などの施設に足を運び、ユーザー視点での気づきをプロダクトへ直接返していく実践を続けている。「実際に自分たちで使って得たフィードバックを、スピード感を持ってプロダクトに反映しています」と中川氏は語る。
リリースはゴールではない！ 検索データとAIが回す改善サイクル
Shibuya TOQ Passのバックエンド領域を担当する星野翔氏は、リリース後のデータ活用について語った。
Shibuya TOQ Passのチームでは、ユーザーが実際にアプリ内でどのようなワードで検索しているかのデータを観察し、その結果、飲食のジャンルにおいて「蕎麦」のニーズが高いことが見えてきた。星野氏はこの結果をチームに伝え、結果として掲載店舗のラインナップ強化につながった。星野氏は「開発中に『蕎麦の需要が高い』という発想はなかなか出てきません。データを見たからこそチームとしてこうした気づきを得ることができました」と振り返る。
データ分析にはAIも活用し始めている。ウィークリーアクティブユーザー（WAU）の改善のため、Googleの「Data Studio」（旧：Looker Studio）で可視化したアナリティクスデータにデータマスキングしたユーザーアンケートを加えてAIに読み込ませ、仮説を生成させている。もちろん、AIが正しいとは限らない。例えば「ブックマーク機能の利用率を高めればリテンション率が上がる」という仮説が生成されたこともあったが、実際には「よく優待を使う人がブックマークも使っている」という相関であり、因果の向きが逆だった。星野氏は「最終的な判断は人間が行います。AIにすべてのコンテキストを渡すことは現実的に不可能ですから」と語り、AIとエンジニアの協働のあり方を示した。
