傘を持っていくべきか答えてくれるLINE Botを作ってみて分かったこと

忙しい人のためのサマリ

「傘を持って行った方が良いか」教えてくれるLINE Botを作ったので、コミュニケーション設計として重要だった3つの考え方を書きました。「入力方法」「返答方法」「名称やキャラクター設定」を考えたら、コミュニケーションプラットフォームでBotサービスを作るときに大切にしたいことが分かりました。

カサいる？

LINEのBOT API Trialを利用して、「カサいる？」というBotを作ってみました。 f:id:uchiuchiyama:20160415173719j:plain

画像にあるとおり、LINEトークの基礎機能である「位置情報を送信」すると、傘を持っていくべきか（その地点に今雨が降っているか、1時間の間に傘が必要なくらい雨が降るのか）を教えてくれるもの*1です。

よかったら試してみてください。（LINEアプリ内のQRコードによる友達追加から上の画像を読み取ってみてください）

というBotサービス紹介だけでは申し訳ないと思うので、ここではBotサービスを作る際に考えたことを書き出してみます。

コミュニケーションを前提としたサービス

LINEに限らず、Facebook Messengerなどコミュニケーションが前提となるプラットフォームの上で動かすBotの場合、インタフェースは当然チャットになります。

今回、「カサいる？」を作ったときに、このチャットというインタフェースが意味することとして3つのことを考えました。

「カサいる？」への入力方法
「カサいる？」からの返答内容
「カサいる？」という名称やキャラクター

最初にユーザさんがこのBotを使うシーンとして「家から外出する玄関」や「家に帰るために会社から出るとき」を思い浮かべました。その上で、この3つのことを考えていきました。

「カサいる？」への入力方法

結論から言うと、テキストで「地名」や「住所」などを受け取る入力方法は適さないので、「位置情報を送る」機能を使うことにしました。

最初、チャット画面なので対話型で「いまどこにいますか？」と聞いて、「銀座」などとユーザさんに答えてもらうような方式を考えました。

しかし、これはシステムとしては思った以上に複雑で、入力されたテキストが住所として適切なのかとか、打ち間違いや表記揺れはどうするのかとか、日本全国に銀座ってたくさんあるけどどれのことを指しているのか、など対応パターンが膨大になってしまいそうでした。*2

また、ユーザ体験の観点でも、自分が今いる住所や地名が分からない（思い出さないといけない）とか、場所を特定するためにBotサービスとの会話の往復が増えたり、傘を持っていくべきか決めたいだけなのに考えないといけないことが多すぎると感じました。

結局、チャットという方式にこだわらず、LINEに標準で備わっている「位置情報を送る」機能を使って送ってもらうことにしました。ただし、ユーザさんはBotサービスに話しかけるのが普通だと思っていると思われるので、「カサいる？」Botサービスでは友達追加したとき（とブロック解除したとき）に使い方を含むメッセージを自動で送るようにしました。

「カサいる？」からの返答内容

結論は、情報の詳細度合いや時間的な正確性を多少犠牲にしてでも「ユーザさんが求めていること」だけをシンプルに回答するようにしました。

傘を持って行った方が良いのかそうでないのか
どのくらい濡れてしまいそうなのか

結局、利用シーンを考えると上記のように知りたいことは傘の要不要だけなので、（情報としては提供可能でしたが）晴れや雨などの天気概況や降雨量、時間毎にどう変化するのか、といった情報は全て削除しました。

「カサいる？」という名称やキャラクター

結論として、ユーザさんが知りたいこと（解決してほしい課題）がストレートに分かることを意識した名前にしたこと、チャットで返答してくれるのだからキャラクターを決める、ということをしました。

最初、名称は「天気Bot」とかにしていました。また、アイコンは「天気マーク（太陽に雲がかかってるやつ）」*3にしていました。

しかし、ここでも利用シーンを考えると（おそらくたくさんの）友達や公式アカウントなどが並ぶ友達一覧から探してタップすることになるのに、しかも急いでいるから早く見つけたいのに、「天気」というワードが思い浮かぶでしょうか。

きっと頭に思い浮かんでいるのは「傘要るかな？」だと思ったので、素直にそのままの名前にしました。

アイコンも対話するのに自然なのはキャラクターかな、と思いましたが自分で描くことは出来なかったので、傘をさしたカエルのキャラクターのイラストを「いらすとや」さんから使わせていただきました。

まとめ

あらためて自分が考えたことを書き出してみると「コミュニケーションのスピードを出来る限り速くしよう」と考えていたことに気付きました。

3つの考えたことに照らして説明すると、こうなります。多少都合良く書いていますが、要点は伝わるでしょうか。

「カサいる？」への入力方法
- 遅い：「地名か」→「いまここどこだ」→「銀座か」→入力→東京都中央区銀座ですか？京都府伏見区銀座ですか？→「・・・（メンドクサイ」
- 速い：＋をタップ→「位置情報」→「この位置を送信」
「カサいる？」からの返答内容
- 遅い：今は晴れていますが30分後に0.6mm/hの雨が降ります→「0.6mm/hってどのくらい降るんだ？」→「傘持って行った方が良いのか？」
- 速い：今は降ってないよ。30分後に降り出しそうだけど弱い雨だからカサは要らないよ→「傘は要らなそうだな」
「カサいる？」という名称やキャラクター
- 遅い：「傘要るかな」→「雨降るのか」→「天気を調べよう」→"天気Bot"
- 速い：「傘要るかな」→"カサいる？"

LINEやFacebook Messengerといったコミュニケーションプラットフォームは非常に多くの利用者を抱えているので、Botサービスを開発をする側にとっては利用される機会が増えチャンスです。しかし、（会話そのものを楽しむサービスでない限り）短い接触時間で済むようなデザイン・コミュニケーション設計が出来ていないBotサービスは次第に使われなくなっていくでしょう。

これらプラットフォームの通常のユーザ体験は、じっくり会話するより瞬間的な会話応答の連続なので、この基本体験から時間軸が外れるBotサービスは面倒がられていくと思うためです。

システムの応答速度はもちろん、チャットや会話によるインタフェース特性を考慮して、ユーザが満足を感じるまでの時間が短いサービス体験を提供する必要があるため、エンジニアリングだけでなくコミュニケーションデザインや情報整理の重要性が高まりそうです。

今回は「傘の要不要」を解決するBotサービスを作ったことから得た考え方を整理しました。企画する人、開発する人の参考になれば幸いです。それでは良いBot開発/Bot体験を！

（スポンサード）

*1:YOLP(地図):気象情報API - Yahoo!デベロッパーネットワークを利用しています

*2:すなわちこういうことですね。