もくじ
インターネットはユーザーに最適化されている
自分がいまいる場所によってTwitterのトレンドも最適化されるし、ブラウザの利用履歴や場所、PC/スマホかでGoogleの検索結果も変わる。Googleで得られる情報は集合知であるけれど、その検索結果がすべてではないので、その集合知から最適なものを取り出すスキルが必要となる。ネットは自分以上の情報は持たない。動かない人の所にライブな情報はやってこないということだ。
GoogleとSNSは同じネットだけれど、使い方が違う。Googleは調べることで情報を得られ、SNSは人と繋がる。SNSは書く人の想いが入るためファクトな情報やノイズも混ざりやすい。GoogleとSNSどちらが良い悪いではなく、人のどの部分をつなげて、何を増幅させるべきかという使い方の問題だ。「再現可能な情報」はコンテンツとしてアーカイブされて、Googleで取り出すことができる。「その時の単体での事象」の場合はSNSでその瞬間に消費されて、時間が流れればタイムラインのどこかに溶けてなくなっていく。
更新されないWebサイト
このWebサイトのBlog記事は、投稿日と更新日がそれぞれ自動表示されるようにしている。最初に書かれてから放置されている古い情報なのか、それとも最近更新された新しい情報なのかを判断する指標になるからだ。
WordPress｜記事の投稿日と更新日を追加する方法
たとえば企業のWebサイトが、クライアントとプロダクションという関係の中で制作されて、その後は放置される。もしくは、更新費を抑えるためにクライアント側で更新作業を行うことも多い。ほとんどの場合がデザインやレイアウトが崩れていったり、システムのアップデートやバックアップなどの保守が行われていなかったり。無駄なものにお金を支払って、必要なものにお金を出せていないのが現状だ。
なかなか更新されないWebサイトというのは、情報が古いから早く更新した方がいいよというだけではなく、問題はそれらの情報がリアルタイムに更新される仕組みがないこと。
いくつか具体例を挙げたい。
Case1｜お店の営業時間
Withコロナにおいて、実店舗の営業時間がイレギュラーすぎて予測ができない。臨時休業や時間短縮、その他の変則的な営業スケジュール自体が問題なのではなく、その情報をリアルタイムに更新できていないことが問題。
飲食店でも、公式サイトの情報が更新されていることはまれで、食べログやGoogleマップにも反映されていない。一方で、日々の更新が必要になりそうな情報は公式サイトに載せず、Googleマップから直接チャットで予約やお問い合わせができるお店もある。タイミングが悪くなければスタッフさんからの返信もレスポンスがよく、数分でやりとりが終わる。
手動で更新を行う場合は、お店によってリテラシーが表面化してしまうけれど、サービスのプラットフォーム側で吸収してしまおうという動きもある。Yahoo! MAPは、各店舗の公式サイトに基づいて営業時間を自動更新できるように対策をした。
飲食店や小売店など、全国約4600チェーン、約80万店舗の公式サイト情報にもとづく店舗情報の自動更新に対応したと発表した。これにより、新型コロナウイルス感染症の影響で変則的な営業を行っている店舗の情報が確認しやすくなる。
Case2｜公共交通機関の運行状況
バス停で待っていたが、時間になってもバスが到着せず、問い合わせたら高速バスが運休していることを知った。バス停に記載はなく、バス会社のWebサイトのトップページのお知らせ欄に運休情報がまとめて記載されていた。そもそもWebサイトの動線というのは、トップページ→各ページではなく、トップページが入口でもないので、時刻表のページに運休情報が必要だ。
紙的なもしくはPDF的な思考があらゆる場所で残っている。あらゆる企業の担当者がデザイン思考をできる訳でもないので、現場の数人だけで極めて重要な部分の見せ方が決められてしまう。その結果、今日もどこかにバスの来ないバス停がある。
Case3｜アクセス情報の情報鮮度
目的の場所に行くために公式サイトのアクセス情報を見るが、その情報が古い。たとえば店舗のアクセス情報のページに、渋谷駅A3出口から徒歩3分と記載がある。しかし実際に行ってみるとA3出口が工事中で、その場合はA1出口から徒歩5分だ。さらに、大規模な工事が終わった渋谷駅は、出入口番号そのものが変わった。
更新されていないアクセス情報は生き続けているけれど、誰もわざわざ連絡しないので、ただ潜在不満として残ることになる。
多くのWebサイトで共通して表示させるようなコンテンツ、アクセス情報などは共通のライブラリを使った方がいい。常に更新されて正確であり、情報の鮮度が下がらない。
Case4｜Webサービスの運営
Webサービスでは、すべての接点が顧客体験なので、Webサイトにデザインの崩れがあればユーザーに敏感に読み取られる。そのサービス自体のクオリティの判断にも直結する。サービスの顔であるWebサイトが崩れたまま放置、つまり玄関が不潔であることは、不潔な玄関が気にならない人をサービスに呼び込んでいるというフィルタリングにもつながる。
必要な情報を「伝える」のと「伝わる」のは大きく違う。たとえばAmazonから届いたPrivacyPolicy変更のメールをどれだけの人が読んでいるだろうか。「そこに記載してあるから」「メールで送っているから」では、伝えたいことが伝わってはいない。Webサイトは見られていないし、メールも読まれていない。必要な時に必要な情報を的確な動線で伝わるようにすることが大事。その伝え方として「規約に記載されていますよね？」なんて接客をリアルではしないはずだ。Webサービスもリアルと同じで、Webだから許されるということは何もない。
やりたいことを実現するために、本来はシステム側で解決するべき問題が、システムで吸収されずに規約の方が変更されてしまうことがある。データの書き換えは簡単にできるが、人の記憶は書き換えられない。Webサービスでのよくない体験は、潜在不満としていつまでも記憶の中に残る。しばらく後に思い出される時に、一緒にその良くない記憶も引っ張り出される。
Case5｜SNSとWebサービスでユーザーが作り上げるコンテンツ
SNSやWebサービスで、サービス提供側は場所を提供し、ユーザーがコンテンツを作り上げていく仕組みも十分成り立っている。SNSは情報鮮度が高い強みがある一方で、情報の正確性に問題がある。ユーザーはコンテンツを作り上げることではなく、コンテンツを消費することに夢中だ。
同じ情報元を取り扱っても、解釈やニュアンスに違いがあるし、言葉のゆらぎもある。Avocadoはアボカド、TeaBagはティーバッグ、Bandageはバンデージ、公式サイトでの日本語のゆらぎは、校閲の観点からも避けたい。人がテキストを手打ちしないこと、1単語であっても必ずコピペするなど、少しの手間で全体的な仕事量を減らすことにつながる。
Case6｜基幹システムとサブシステムの連携の悪さ
Windows95かと思うようなUIの時代遅れなシステムに対して、年間100万円以上の金額を支払っている会社もいまだにある。宿泊業のOTA（Online Travel Agent）、倉庫業のWMS（Warehouse Management System）など、基幹システムとサブシステムとの連携の悪さによって、システムが人の仕事を増やす。これは早期に解決しておかないと、サービスが拡大した時には大きな負債となる。
日々システムの管理画面を開いて必要な情報を手入力し、お粗末なシステムに仕事をさせられているのだ。目的と手段が崩壊している。そのシステムを使う必要があるか、より良い代案はないのか、1年前はなかったが今は代案はないのか、独自開発ではなく汎用性のあるシステムを導入する検討はされているか。1度システムが稼働してしまうとなかなか変更もしづらくなってくる。
セマンティックなWebサイトのバイオニック化
Webサイト制作では、セマンティックな作り方をするべきだ。正しいタグを使ったり、文章のまとまりを示したり、その情報が意味するものやつながりなどをWebサイトのクローラーに教えるため、しいては、現代の情報を正しくアーカイブして継承していくことでもある。
目まぐるしく進化し続けるWebサイトでは当然ではあるけれど、セマンティックなWebサイトであることは、次の瞬間にはセマンティックではなくなるということ。そもそもセマンティックWebはAIの仕事であり、WebをWebたらしめるhtml構造そのものが人間の進化の後追いになっているのが問題。Webの技術はAIが高めていけばいいし、人間がやる必要はない。
Webサイトのバイオニック化（＝人が制作するWebサイトの最終形）を見つめながら、プレート型のデバイスなどに投影するためのGUI（Graphical User Interface）、音声コントロールのためのVUI（Voice User Interface）、それ以外のxUIを模索したい。
リアルへの帰還
目に見えないVUIやxUIで取り出されるコンテンツを扱う時代での、アイデンティティってなんだろう。捨てられるものを捨て切った先に、本当に必要なリアルが見えてくるのだと思う。
