前回は、気持ちいいUIを構築する方法を開発者の視点から捉え、「⁠開発者が“⁠面倒くさくて⁠”やらなかったことが、利用者の“⁠面倒くささ⁠”の蓄積につながるのではないか⁠」⁠、そしてユーザーの面倒くささを解消してあげる方法の1つとして「ユーザーが何もしなくて良い状態を作る」ことがよいのではないか、という意見を提示しました。今回はその考察をさらに発展させ、技術者がついついやってしまいがちな「やりすぎ」について考えてみたいと思います。

チュニジアで痛感したGoogleマップの出来の良さ

筆者は8月末にチュニジアに行って来ました。チュニジアはアフリカ大陸の地中海沿岸に位置しており、アフリカの中では比較的発展を遂げている国です。フランス人などのリゾート地としても有名です。今回は家族を連れて、チュニジア人の元同僚を訪ねての旅だったのですが、筆者は基本リモートで仕事をしているため、仕事を完全にストップさせず、毎日家族が寝ている早朝（チュニジアは8時間の時差があるため、早朝は日本だと昼すぎになります）に仕事をしていました。

出発前に、その元同僚は「チュニジアはネット速いから大丈夫だよ」と言っており、たしかに想像していたよりは全然速かったのですが、やはり日本と比べれば（当然ですが）遅いもの。しかも、ホテルのネット環境は、たくさんの人が使う午後から夜にかけては輻輳が激しかったですし、外に出れば公衆WiFiはさほど存在していませんでした。さらに、持参していたSIMロックフリーのスマートフォンの調子が途中で悪くなってしまい、日本のSIMロック付きのiPhoneで何かを調べたり、情報を保存したりすることが増えたため、本連載でも触れたようにネットワークの遅い地域や、まったくつながらないタイミングが生まれることを考慮したサービス、アプリかどうかを非常に敏感に感じ取れる状況でした。

さて、旅先で非常に便利なサービスといえば、Googleマップですよね。Googleマップさえあれば、自分がどこにいるかも、どこに向かっているかも、ホテルまでどうやって帰ればいいのかも、タクシーがわざと遠回りしていないかも、電車やバスで降りる駅をすぎてしまっていないかも、把握することができます。この便利さは本当にありがたくて、最近では「Googleマップがスマートフォンで見られなかった時って、どうやって道を調べていたんだっけ？」とふと思ってしまうほどです。

そして、Googleマップは比較的キャッシュがしっかりしており、一度アクセスしておくと、しばらくの間はネットワークに接続していなくても問題なく地図が表示されるため、ホテルなどWiFi環境のあるところであらかじめ行きそうなところを表示しておくと、あとは外に出ても意外と問題なく使うことができます。これはさすがというか、ニーズをきちんと汲み取った結果と言えます。

ただし1点だけ、あまりキャッシュが古くなると、ネットワーク接続していなくても突然キャッシュが切れてしまい、何も表示されなくなるという問題があります。できればネットワーク接続がない場合はキャッシュアウトしないようにしてほしいところです。筆者は、この訪問で1回だけ、バスに乗っている時に突然キャッシュが切れて、ちょっと冷や汗をかきました。

なぜ、宿泊するホテルや飛行機の時間が自動的にマップ上に表示されるのか？

そんな便利なGoogleマップですが、見ている時に、あることに気づきました。それは、自分が宿泊する予定のホテルや搭乗予定の飛行機の時間がマップ上に表示されているのです。

最初は、Googleカレンダーの情報を表示しているのかと思いました。しかし、そうした予定をカレンダーに記録した記憶もなかったので、「⁠なぜ、Googleがそんな情報を知っているのか……」と、最初はかなりビックリしました。

少し考えてみると、一番怪しいのはGmailだと気づきました。今回はホテルはExpediaやAgoda、飛行機は航空会社のWebサイトで直接購入しており、Gmailに確認などの各種メールが届いています。その中の情報を読んでいる可能性が高いと思い、調べてみると、（⁠筆者が知らなかっただけですが）GoogleマップにはGmailとの連携機能があり、2014年7月にiOS版でもその機能が追加されていたのです。

みなさんはこの機能、どう思われるでしょうか？

わかってしまえば「なるほど」と思う機能ですし、泊まるホテルの位置や出発する空港の場所もひと目でわかるので、非常に便利な気もします。しかし、いきなり表示されると、かなり面食らうのではないでしょうか。しかも、とりたてて説明もありません。人によっては「勝手にメールの内容を読んでいるのか！」と怒るかもしれませんよね。デフォルトでオンにするには、ちょっとまだ時代が追いついてきていない機能である気がします。

「何もしなくていい」と「余計なお世話」の境目は人によって違う

開発者として、「⁠ユーザーが何もしなくていい状態を作る」ことを第一に考えた時、こうした自動連携は「ユーザーにとって便利な機能⁠」⁠」として提供したくなってしまいます。せっかく予約情報も自分たちが提供するサービス（この場合はGmail）に記録されているのだから、そしてそれを自動識別できるのだから、マップに自動で表示してあげればどんなに便利だろうかと。それはたしかに事実で、実際に色々わかってしまえば便利だと考えることもできます。しかも、そういった機能は、往々にして技術的にもおもしろいチャレンジだったりするので、ついつい夢中になって作ってしまいがちです。

しかし、闇雲に「便利さ」や「ユーザーが何もしなくていい状態」を追いかけてしまうと、「⁠気持ちのいい」状態を通り越して、「⁠薄気味悪い」「⁠余計なお世話」の世界に突入してしまうかもしれないことを、このGoogleマップの例は示しています。

しかも、その「薄気味悪さ」や「余計なお世話」の感覚の閾値は人によってさまざまであり、自分が特に気持ち悪くなかったからといって、それがほかの人も同じかどうかはわかりません。たとえば、国民総背番号制の導入も、「⁠気持ち悪い」と考える人も、「⁠便利になっていい」と考える人もいます。同様に、サービスがさまざまなことを勝手にやってくれるようになった時、どの段階で「気持ち悪い」と考えるかは人それぞれです。したがって、自分の感覚だけに頼らず、ほかのユーザーの意見なども参考にしながら、慎重に進める必要があります。

「因果関係がはっきりしていること」「自分の提供した情報が、想定のとおりに使われているか」が重要

「何が気持ち悪いのか」は人それぞれとはいえ、「⁠ユーザーがどんなことに対して“⁠気持ち悪い⁠”と感じるのか」を考えると、「⁠因果関係がはっきりしていること」や「自分の提供した情報が、想定のとおりに使われているか」が重要である気がしてきます。

前回紹介したMovesと、今回のGoogleマップの例を比較して考えてみましょう。Movesでは、「⁠GPSによって、移動した場所が自動的にマッピングされる」のは基本機能で理解して使っているはずですから、気持ち悪くありません。そして、移動した場所の名前は、そのあたりにあるお店やスポットの情報を自動でとっていることが比較的わかりやすく、しかも最初はものすごくまちがえるので、自分で「教えこむ」必要があります。そして、その情報が次回自動で表示されても、それは自分が教えた情報ですから、気持ち悪さは感じません。「⁠おっ、ちゃんと前教えたことを覚えているな。偉いじゃないか」と思いはするものの、「⁠勝手に使いやがって！」という気はしません。自分が与えた情報が想定どおりに使われているからです。

一方で、Googleマップの場合は、GmailとGoogleマップは同じGoogleが提供しているとはいえ異なるサービスですし、そもそもホテルや飛行機の予約メールは自分の予約確認のために使うもので、マップ上に表示されるなんて普通は知らなければ想像できません。ですから、最初は因果関係がわからないことで「どうやって知ったのだろう……」と気持ち悪さを感じ、Gmailから情報を取得していることがわかったあとは想定外の使われ方をしたことにぎょっとするわけです。その気持ち悪さは、単に勝手に使われたことだけではなく、「⁠ほかにも情報をとって、悪用しているのではないか」と、自分がコントロールしたい情報がコントロールできない状態に置かれてしまう怖さも含んでいるでしょう。

ことGoogleについて言えば、Googleはさまざまなサービスを提供しており、インターネットを使っている人はかなりの情報をGoogleに握られていると言っても過言ではない状態ですから、「⁠いまさらそんなことを言っても……」という感はあります。しかし、この感覚をほかのサービスに当てはめて考えると、「⁠自分の情報が自分の想定外に使われている」という感覚を抱かせないことは非常に重要だと思います。その機能が本当にものすごく便利で、「⁠ここまで便利になるなら、しかたがない」と思ってくれるユーザーもいるかもしれませんが、もしそうでないなら、ユーザーが離れてしまう原因となってしまうでしょう。

筆者が関わっているあるUGC系のサービスでは、Facebook連携を利用していました。そのサービス自体にも友達をフォローする機能がありましたが、ユーザーが情報を投稿した際に、フォローしていない人であっても、Facebookの友達であればPush通知でそれを知らせる機能を実装した時がありました。これは、「⁠Facebookの友達であればきっと知り合いのはずだから、知り合いのアクティビティを知ることができればきっとうれしいはず、アクティブ率が上がるはず」という仮説があったからです。

しかし、蓋を開けてみると、アクティブ率ががぐんと下がりました。これは結局、「⁠フォローしていないはずの知り合いに“⁠勝手に⁠”通知が届くのは気持ち悪い」とユーザーが思ったからでした。これも、情報が勝手に使われる気持ち悪さに対してユーザーがネガティブな反応を示した良い例と言えるでしょう。

国が変われば「気持ち悪さ」の感覚にますます差が出る

「気持ち悪さ」の感覚は人によってさまざまであると書きましたが、日本の中でも、リテラシーや思想、その他いろいろな要因で、その感覚には大きな差がでてきます。さらに世界に目を向けると、その違いはもっと大きくなるように思います。たとえば、Facebookログインの機能は、現在では日本でもかなり当たり前に見られるようになってきましたが、まだ「Facebookのアカウントを別のサービスに知られてしまうのは気持ち悪い」と感じる人は多いのではないでしょうか。筆者も、最近はだいぶ麻痺してきましたが、かつてはそうでした。しかし、東南アジア、たとえばインドネシア人の友人に聞くと、Facebookでログインすることにはまったく抵抗がなかったりします。

また、これは筆者がかつて検索エンジンの仕事をしていた時の話でユーザーインターフェイスの話ではありませんが、クローラーが巡回しているあるサイトの管理者の方から「うちのサイトは1日100アクセスくらいしかないのに、あなたのところのクローラーが1日1000アクセスくらいしてきて、非常に気持ちが悪い」と言われました。これはもちろん、その検索エンジンの信頼度の問題も非常に大きく絡んでいると思われますが、それを差しおいても、「⁠1日100アクセスのサイトにロボットが1000アクセスすることが気持ち悪い」という感覚は理解できる気がします。しかし、そのクローラーを管理していた中国人のエンジニアと話をすると、

• 「このサイトのサーバが1日1000アクセスで落ちるわけではなさそうだし、なぜなんの悪影響も与えないのに嫌がるのか、まったく理解できない」

という答えが帰ってきました。

「じゃあ、自分が管理してるサイトに、どこの馬の骨かもわからないロボットがたくさんアクセスしてきたら不愉快ではないのか？」と聞いたところ、「⁠サーバがそれで重くなったりしない限りは気にならない」という答えでした。「⁠感覚の違いをお互いに理解するのは難しいかもしれない」と痛感した覚えがあります。

その時には、「⁠お互い理解できなくても、相手を信じよう」という信頼関係がそのエンジニアとの間で成り立っていたので、前向きに対応することができました。しかし、この体験から「自分自身の感覚のみに頼っていると、大きな失敗をしてしまう危険性が常に付きまとう」という示唆が得られました。

開発者にとって、いろいろな情報から有意なデータを抽出したり、新しい手法を編み出してユーザーにより便利な環境を生み出すのは、とてもやりがいがあることです。しかし、そのためについついやりすぎてしまう可能性を、常に気にしておいたほうがよさそうです。「⁠便利さ」と「薄気味悪さ」は非常に密接に関わっていることだと肝に銘じて、ユーザーインタビューやA/Bテストなどを含め、多くの人の感覚を実際に調べつつ、慎重に検討しましょう。

次回は、引き続き気持ちのいいUIについて、「⁠機能追加」という切り口から考えてみます。