morishitaです。 前回のエントリで開発の経緯について書きましたが、 今回は「いこーよのおでかけナビ」（以降、いこナビと呼びます）の開発に際して考えたことを書きたいと思います。
前回のエントリはこちら tech.actindi.net
- 発売日: 2019/08/27
- メディア: アプリ
基本方針
いこナビは次の方針に基づいて開発を進めています。
- いこーよでは情報が多すぎて探すのが難しいと感じているビギナー向けに作ろう
- いこーよのWebやアプリとはまた違ったユーザ体験をお届けしたい。
- 最終的には施設を紹介するが、ユーザは検索したいわけではないので、対話の中で自分の好みや趣向に気づいてもらえることを目指す。
この方針は最初に決めたものではなく、シナリオを書いたり、プロトタイピングして確認しながら固めていったものです。
この方針にたどり着く過程、あるいはこの方針から開発を進めるにあたり考えたことを書きます。
Webやアプリの置き換えはやらない
VUIというこれまでとは異なるUXを提供するものを設計するのに際して、最初に考えたのはこれでした。
手元にEchoが届いてから他社のスキルをいくつか使って見ました。
そのいくつかはWebでやっているような検索をそのままVUIにしたようなスキルで、その体験は良いとは言えないものでした。
いこナビでは最終的に施設情報を提示します。そこでやっているのは本質的には検索です。
しかし、Webで提供しているような検索機能を持ち込んでもVUIでは複雑な検索条件を設定するのは困難ですし、多くの検索結果を返してもとても聞いていられません。
こういうものはVUIに向かない、Webやアプリとは違うVUIにはVUIの考え方が必要だと思いました。
ユーザの納得感
いこナビではお出かけスポットを「提案」しています。
ユーザに何も尋ねずに「提案」することもできます。
でも、いこナビでは「ジャンル」を指定してもらうようにしています。
いきなりお出かけ先を提示しても、それがユーザの好みを反映している可能性は少ないでしょう。 提案する前に何らかのユーザの意思を問うたほうが結果に納得感が得られる可能性が高まるのではないかと考えたためです。
「ジャンル」以外の候補としては「場所」「日付」などがありました。
日付を尋ねると…
日付を聞くとお出かけスポットではなくイベントが期待されるだろうと思われます。
しかし、イベントだとシーズン性が高く、ユーザの居住地域によっては安定して提案を用意できない可能性があるので採用しませんでした。
場所を尋ねると…
場所だとすでに知っているお出かけ先を調べるのに使われるのではないかと考えました。
新しいお出かけ先を発見してほしいのでスキルの方向性からずれると思いました。
また、旅行先でのお出かけ先を知りたい場合には場所を指定したいのでは？とも考えましたが、
このスキルは旅行時ではなく日常的に使ってもらいたいと思いました。これらが場所を採用しなかった理由です。
ジャンルを尋ねると…
ジャンルであれば、「動物園」と指定すれば、どのような施設が提案されるのか予想できますし、 こないだは動物園に行ったから、今度は水族館に行ってみようとユーザの主体的な選択を促しやすいと思いました。 （場所と時間を不採用にすると、後はジャンルくらいだろうという消去法的な理由も否定はしません）
結果のフィット感
納得感の一方、提案する施設のフィット感も重要です。
例えば「動物園」と指定したのだから提案の結果はまあ、そうだろうなぁと思ってもらうところまでが「納得感」で
その結果が"役立つ"、"そこへ行きたい"と思ってもらえるかどうかが結果の「フィット感」と考えています。
いこナビを通して「新たなお出かけ先の発見」をしてもらいたいと考えているので、
自宅から近い場所はもう知っている可能性が高いと考え、あえて少し離れたお出かけ先を提案するようにしています。
当初は全ジャンル同じロジックでお出かけ先を検索していました。
ところが社内でβテストをしてみると、プールなどは近場で済ませたいという指摘がありました。
なるほど、そういうジャンルもあれば、アスレチックや海水浴場などは少々遠くても行くかなというジャンルがあります。
そのためジャンルごとに距離や近場から提案するのか遠くから提案するのかを調整できるようにしました。
また、提案施設がちょっと遠すぎるとのご意見も頂いています。
自動車で片道1時間程度で行ける距離に範囲を絞って提案しているのですが、それではちょっと遠いようです。
ただ、単純に範囲を小さくすると、提案できる施設の母数が少なくなってしまう地域もあり、
利用回数に応じて範囲を広げたり、遠くのお出かけ先と近くのお出かけ先を織り交ぜて提示するなどの模索をしています。
もちろん、ユーザが結果を評価する軸は遠い近いだけではないでしょう。
フィット感に関してはユーザの利用状況を見ながら、いこーよの施設DBのデータも含め改善を続ける部分なのかなと考えています。
追記： リリース時には単純に距離で範囲を絞って検索した結果を返す方式でした。そのため結果の3件は同じくらいの距離の施設となっていました。 その後、ロジックを見直し、現在は 近く、少し離れたところ、もっと離れたところと距離の違う3件を提案するように変更しました。 こうすることで、その日の気分や、使える時間に応じてお出かけ先を選択してもらえるようになりました。
いつも同じことを言わない
日常的に使ってもらうにはいつも同じ反応では飽きられてしまいます。
スキル開始時のちょっとした挨拶や、うまくユーザの発話を聞き取れなかったときの応答は何パターンか用意していつも同じ台詞を言わないようにしています。
また、提示するお出かけ先も単純に検索すると、条件が同じならば同じ結果を出してしまうところですが過去の履歴を
持ち同じところばかり提案しないようにしています。
会話のコンテキストはあるようでなかったりする。が、ないわけではない。
例えば、いこナビでは動物園の詳細を説明しているときには次に 「寄り道スポットを教えて」 と言われることを期待しています。
でも、ユーザはそれを遮って「水族館教えて」と言うかもしれません。
人が相手ならば「ちょっとまって、動物園の話をしているんだから」と返すところかもしれません。
人間相手にいきなり話題を変える人はいます。ならば、VUI相手にも必そういう人はいます。
スキルの能力の範囲ならば応えて「では水族館のオススメは〜」と返したほうが良いと考えています。
とはいえ、なんでも受けすぎると混乱させる場合もあります。
Alexaはコンテキストを考慮して聞き取ってくれません。
例えばいこナビでは当初「◯◯の◯◯」と言われると、郵便番号を言われていると思い、
「よくわかりません。郵便番号は◯◯◯の◯◯◯◯と言うように言ってください」と返してしまっていました。
郵便番号を聞く流れはメインの会話ではないので、間違って聞き取った場合に「郵便番号は〜」と返すより、
「わかりません」とだけ回答したほうがユーザは混乱しないと思います。
そのためいこナビでは郵便番号を聞いているのかどうかはコンテキストを管理して応対するようにしています。
ユーザに愛される仕掛け
VUIがこれまでのUIと最も異なる点、それはユーザがシステムに人格を感じるというと大げさかもしれませんが これまでのUIよりも近い距離感を感じるところかと思っています1。
いこナビはユーザにとって「便利なツール」でありたいと思っていますが、
まあ、なんか参考になるかもしれないからちょっと聞いてみよう程度でも構わないと思っています。
長く使ってもらって好きになってもらいたい。
そのためには便利さよりも愛される仕掛けが必要と思っています。
使うほど親密度の高い言い回しをするとか、過去の利用を反映した受け答えをするといったよりユーザに寄り添った
応対をしていくのか、お茶目感を演出していくのか、これも模索を続ける必要があると考えています。
さいごに
この様にあれこれ悩み、考えながら世に送り出したいこナビですが、 VUIの開発ノウハウ自体まだ事例が少ないですし、私自身初めてで手探り状態のなか開発しています。
一緒に試行錯誤してくれるエンジニアを求めています。 まずは、VUIのこれからについて話してみませんか？
-
VUIサービスを提供する各社はそのサービスそのものに擬似的な人格を与えています。AlexaにAlexa自身のことを聞いてみると結構面白いです。Google Assistantはそのへんは控えめに感じます。↩
