Feedback Loop

アクセシビリティと似ているものとしてユーザビリティがある。ユーザビリティが使いやすさを意味するのに対し、アクセシビリティはそもそもアクセス可能かどうかを表す。音声で操作できたり拡大して文字を読めたりするのがアクセシビリティ、サービスの使い勝手が良くて目的を達せられるのがユーザビリティ。バリアフリーという単語が昔はよく使われたが、それは特定の障害を取り除く意味合いがあった。いまでは障害は濃淡あれど人それぞれあるもので、すべての人にとって使えるものを提供しようというのでアクセシビリティと呼ばれる。包括するという意味でインクルーシブデザインなどと呼ばれることもある。

障害とはなにか？個人が持つものではなく、環境との間に生まれるものだと理解している。視覚障害の方でも勝手をよく知る自分の家なら楽に移動できる。外に出ると気をつけないといけないことが多い。これは外の建物やサービスで配慮が不足しているから。人と環境の間に障害があり、それはひとつずつ取り除いていける。ここでいう障害はグラデーションがある。例えば車椅子の人にとって使いやすいよう作られた駅構内は、スーツケースを引いている人にも助けになる。一時的に足を怪我し、松葉杖をついているときも助かる。人によって能力はさまざまで、階段を何段か登るととても疲れてしまう人もいるかもしれない。アクセシビリティを高めることは全体にとってポジティブになる。Webサイトのすべてをキーボードで操作できるようにするのは、視覚障害者にとって大事なことだが同時にキーボードを使いこなして効率化したい人にもよろこばれる。

ただし、「障害者のためのデザインは結局、非障害者にとっても有用だ」と安易に考えすぎるのも注意が必要。非障害者にとって役立たないものの優先度が下がるわけでは決してない（むしろ感覚的にはあがるべき）。ニュースの手話通訳や点字ブロックは障害者のニーズにのみに応える。韓国では美観上よろしくないという理由で点字ブロックの色が目立ちにくいグレーになっているらしい。全員にとって、を強調しすぎるあまり本来の問題を解決できなくなるのは本末転倒だと頭に入れておきたい。ちなみこのあたりの話は「サイボーグになる」という本に教えてもらった。障害をもつSF作家と俳優の二人が書いた本だが、社会の障害と人間の感情、テクノロジーとの関連について書かれていてとても面白かった。

考慮されていない施設に後からエレベーターやスロープをつけていくのは費用や工数の面で時間がかかる。最初から考慮して設計していれば元々の建てる工数とほぼ変わらずに作ることができる。これはWebの世界でも似ている。データベースを設計するとき、サービスが成長して後に必要になる機能を見通しながら、将来に破綻をきたさないように設計する。後からまったく想定外の仕様を実装するとなると大幅に時間がかかる。それを避けるために最初にいろいろ考慮してつくるわけだが、Webアクセシビリティもそれに近いかもしれない。作ったものを後からWebアクセシビリティ対応するのではなく、最初から考慮して設計・実装していく。スタート地点から設計に組み込まれていれば拡張もしやすいし、使いやすいようにチューニングしていくのも簡単。設計の時点で気づければ、いまの時代解決のための手段や技術はたくさん存在する。まずは気付けるように、いろいろな環境や障害を知っていくことからなのかなと思っています。

3年前にアプリエンジニアからWebサービスのプロダクトマネージャーに職を変えて以来、アクセシビリティについて考える機会がとても増えた。まだまだ全容は理解できていないが、勉強した範囲で書いてみたい。

アクセシビリティと書いたが正確にはWebアクセシビリティで、WebサイトやWebサービスをすべての人が使えるようにすることを目的とする。例えばレイアウトや文字サイズ、色のコントラストに配慮して設計すると、色覚異常の方や高齢者の方でも使える。見出しがあって本文がある、ボタンをアイコンだけで表現せず意味のあるタイトルを添えると、音声での操作ができたり文字読み上げが滑らかにできたりして視覚障害を持つ方でも利用できるようになる。そのサービスを利用するいろいろな人の環境を考え、配慮のある設計をしようというのがアクセシビリティ。

Webはアクセシビリティを担保しやすい媒体である。例えば新聞は印刷した時点で文字サイズが確定する。拡大鏡などを使ってある程度まで文字を大きく見ることはできるが限界がある。音声で読み上げることもできない。情報の出し手がフォーマットまで決めているといえる。それに比べてWebは受け取り側がフォーマットを選択できる。拡大して文字で読みたい人もいれば、音声でコンテンツを聞く人もいる。AI技術の進化によりコンテンツを動画に変換して見たり、自分の理解レベルに合わせてコンテンツを改変する未来も近い（小学4年生がわかる言葉遣いで書き直してもらうとか）。発信者はコンテンツを提供し、受け取り手がフォーマットを選べる。これはサービス利用者の間口を広げる。

Webは元々高いアクセシビリティを持っているが、近年のWebサイトやWebサービスは複雑化しており、考慮して設計や実装を進めないと使いづらいものになってしまう。例えばマウスをコンテンツに乗せるとボタンが出てくるインタフェースをつくると、マウスを持ちづらい人にとって使えなくなってしまう。キーボードだけでも操作できるとか、音声でも操作できるように設計するのが望ましい。こういう気をつけるべきポイントは多々あり、ウェブアクセシビリティガイドラインとしてまとめられている。JIS規格が参照されることが多いが、各社が独自にガイドラインを公開していたりする。デジタル庁も「ウェブアクセシビリティ導入ガイドブック」を出しており、初めての人でも理解しやすいようにまとめてくれている。どのような環境でも使えるように、まずはどんな環境があり、考慮されていないWebサイトはその環境でどう使いにくいのかを理解する必要がある。

Webサイトの構造やパフォーマンスをチェックできるツールはあるが、アクセシビリティを完全にチェックするものは今時点でない。画像に代替テキストが設定されていないなど一部の項目は確認できるが、構造が読みやすくなっているかなどは人間的で、機械的にすべてをチェックできない。個人的にはこのあたりが整ってくるとアクセシビリティの浸透が進む気がしている。先述のパフォーマンス計測ツールをみんなが使っているのも、それがGoogleが提供していて基準を満たすとSEO的に有利という要素があったからだと思う。スコアの高いサイトにするとGoogleが検索結果の上の方に表示してくれて、より多くの人に届けることができる。何もなくとも全員がアクセシビリティを常に意識できるともちろん良いが、全員の意識を急に引き上げるのは難しいのでまずは仕組みかなと思っている。Appleは最近画面のどこに何があるかをAIが理解できるようになる旨の論文を出していた。AIは意味合いを理解できるので、AI活用が急激に進む今の時代ではよいチェック機構が生まれてもいいような気がしている。

Webサービスをつくるとき、それが「人に言いたくなるものか」を考えるのが大事。自分の課題をドンピシャで解決してくれるとか、使い心地が抜群に良いとか、これまで見たことない機能が提供されているとか。人に話すきっかけは多々あるが、話したくなるものを作れるかはひとつの基準になる。

ある人に刺さるものが作れたとき、それはクチコミで広がる。人は自分と似たコミュニティに属している。趣味であったり仕事であったり属性は様々だが、そこには同じような悩みを抱えた人がいる。自分の悩みを解決してくれるものを見つけたとき、周りにいる人にも紹介する。そしてその人がさらに知人に紹介する。こうしてサービスが知られていく。

サービスを広める方法として、広告を打つなどのお金を使う方法もある。1人を獲得するだけではコストに見合わないので、そこから紹介の連鎖が生まれるかどうかが重要。人に言いたくなる体験があったり、SNSなどにシェアしやすくなっていたり、そういう工夫を入れた上で広告を打つ。クチコミは無料の拡散手段でもあるが、有料の手段を増幅する性質も併せ持っている。

クチコミをすべて計測するのは難しい。Xでポストされるとか目に見えるのは一部で、LINEで紹介されたりランチの時に話されたり多くはクローズドな空間で行われる。登録時にアンケートで「どのようにこのサービスを知りましたか？」と聞けば教えてもらえる場合もあるかもしれない。お金があれば紹介キャンペーン的なことをして、紹介コードを入れてもらうと500円分キャッシュバックするような仕組みを作ることもできる。誰が誰を紹介したのか、1人が平均何人を連れてきてくれるのかの数値を測定できる（バイラル係数と呼ばれる）。

クチコミを生むためにはある程度領域を絞った方がいい。全員向けのサービスと謳うより、特定のコミュニティの課題を解決するサービスの方が良い。何にでも使えますよ、というサービスは天下を取る可能性はあるがそもそも広まりにくい。そういう意味ではNotionはすごいと思っており、使い方が多様なのに人々の心を掴んでいる。クチコミが生まれるほど良い体験を提供できているか、クチコミがコミュニティに広がるほどその課題は汎用的なものか。Webサービスを作るとき、実装に入る前にこのあたりに思いを馳せるとコンセプトの良し悪しを確認できる。自分が欲しいものなら作ったら良いとは思うが、もしかしたら少しのチューニングで多くの人にも喜んでもらえるかもしれない。何かを作り始める前には一度立ち止まって考えてみたい。

先週末の話。カフェで個人開発をしていて、どうにも解決できない問題があった。この実装で正しく動くはずなのに動かない。ネットで調べても情報はなく、自分と同じ問題に直面している人は他にいないように見える。実装を楽にするためにとあるライブラリを使っていたが、それが良くないのかもしれない。2時間くらい奮闘していたが夕方から予定があって調査を切り上げる必要があり、最後に調べた内容をまとめてそのライブラリのコミュニティに聞いてみる（GitHubのIssueを立てる）ことにした。

発生している問題や期待値、自分が試した内容などをまとめていく。このケースは動くのにこのケースでは挙動がおかしい。そんなことをまとめていると検証しきれてないパターンがあったことに気づく。情報は全部揃っていた方が良いので、漏れていた部分を検証する。すると不可解な挙動になっていて、そこを深掘りすると問題の原因に行き着いた。原因がわかってしまえばすぐ直せる。10分くらいで修正して良い気分でカフェを出る。そして、こういうことってよくあるなと思い返していた。

前の職場でエンジニアとして働いていたとき、行き詰まって同僚に相談することがよくあった。相談するときはソースコードや実際の画面を見てもらいながら、起きている問題について整理して話す。すると不思議なことに、相談しはじめた途端に怪しい箇所が判明し、問題が解決する。これは問題に直面して狭くなった視野を俯瞰して整理するタイミングが必要ということだと思う。問題をツリー構造で理解し、すべてのパターンを試す。このパターンではうまくいくが、このパターンではうまく動かない。その違いを深ぼっていく。問題に直面して1時間くらい経っていると、こういう冷静な脳が働かなくなる。一度画面から離れて、人に話したり状況をテキストにまとめたりするのは視野を取り戻す効果がある。

今回カフェで当たった問題は、自分があまり詳しくない技術の周辺で発生した。勉強中の身なので自信がない。そうなるとエラーの内容でググって一発で誰かの答えを探そうとしてしまう。熟達した分野なら早い段階で落ち着いて問題整理に時間をつかい、一つずつ可能性を潰していったと思う。詰まったら立ち止まって状況を整理すること、自信がなくてもいつも通りのプロセスをふむこと。これらは意識しておきたいポイント。

価値と評価は似ているようで違う。価値は自分で感じる主観的なもの。例えばこの日記はなくても世の中の人にとって全く問題ないが、自分的には続けることに意味を感じているので続けている。一方で、評価は他人が下すもの。絵画や音楽、Webサービスなどあらゆるものが評価の対象となるが、その時々の世間の状況や環境に影響されながら誰かが評価する。そのため死後に作品が評価されることもある。価値と評価、この二つは分けて考えておきたい。

前職でHack Dayというイベントがあった。エンジニアの祭典なるもので、24時間でひとつのWebサービスを作る。この間は通常の業務はストップして、好きなチームで参加し、好きな技術を使い、好きなものを作る。私はよく友人に声をかけて一緒に出ていたが、この時間がとても楽しかった。自分たちが作ってみたいと思うものを作り、そのために必要な技術を調べて勉強する。仲の良い友人と長時間、サービスの仕様や技術、なんでもない話をしながらものづくりする。土日12時間ずつ、という普段の仕事とは違うタイムスパンなのもゲーム感があって面白く、24時間で作り切れるように仕様やスコープを調整していく（のちに平日8時間×3日に変わった）。全員がものづくりが大好きで集まっている人で、会場には活気がある。その空間も好きだった。

Hack Dayは最後に作った作品を発表する時間がある。1チーム5分で順番に発表していく。参加チームも多いので次々とアイデアや作ったものが発表されていく。自分が知らない技術、思いつけないアイデアがたくさんあり、聞いていて勉強になる。自分たちの番をドキドキしながら待つ。チームメンバーの誰かが代表で発表するが、私も何度か発表した。作ったものの魅力を最大限伝えたくて、共感できる課題を最初に提示したり、キャッチーなフレーズを並べたり、開発同様自分の持てるものを注ぎ込んだ。

さて、モヤりポイントはここからで、Hack Dayでは発表の後、いくつかのサービスが表彰される。審査員が話し合って授与される最優秀賞、新しい技術を使いこなしたチームに授与されるHappy Hacking賞、それから技術提供などに協力してくれた各社による協賛賞、社長賞などがある。この時間は自分にとってとても嫌な時間で、入賞したものは良くて、入賞しないものは良くないと判別さているように感じた。あれだけ良い時間を過ごして、ものづくりに熱中して、作ったものを誇る気持ちもあって、それなのに誰か知らない人にそれを価値なしと判断される。当時は今よりもっと人から評価してもらいたい気持ちがあったので、これは辛い体験になった。結局6, 7回参加して一度も受賞はしなかったが、賞欲しさにマイナーな技術を使って無理やり狙いに行ったりもした。それでも選ばれない。賞もなく、本当に作りたかったものを作ってもない。もう意味不明な状態である。自分の浅さにショックを受けたりもした。

ものづくりに熱中している24時間、これには価値がある。自分が心から楽しめて没頭できる時間。またこういう時間を過ごしたいと思う。発表の後の表彰、これは評価である。他人が作品をみて、その人の基準で評価をつける。評価はその人の主観で、絶対に正しいわけじゃない。普通に間違える。しかも審査員のことをよく知っているわけでもない。そんな人たちの評価に左右される必要は本来ない。

例えばそこで表彰されなかったとして、そのWebサービスを世に出してめっちゃ人気のサービスになるというのは普通にありえると思う。Hack Dayという性質上新しい技術をうまく使ったチームが評価されていたが、別に世の中のユーザーは新しい技術に触れたいわけじゃない。自分たちの生活が便利になったり、困っている問題が解決したり、そういうものを求めている。すでに枯れた技術でも組み合わせれば便利になり、同じ機能でも見た目をかわいくするだけ刺さる相手が出てきたりする。審査はあくまでHack Dayの、あの会場のモノサシで測られただけだったと今なら理解できるが、当時は自分のつくったものが価値なしと判定されているような気分になっていた。価値と評価を混同するとこういう不幸が起きる。

基本的には価値、自分が納得できることをやれば良い。人からの評価は水物で、それをコントロールしようとすると疲れる。ただし、給料をもらったりお金を稼いだり、食っていくためには評価が必要になる。周りからの評価が高い方が有利な場面もある。そこは割り切ってチューニングし、表現や届ける相手を工夫するなどして生活できるくらいには評価を得ておく。それが出来たらあとは自分の信じるものに投資する。お金にならないかもしれないが、それをやっているだけですでに楽しいと思えるようなもの。熱は誰かに伝播するので、一生懸命やっていればどこかには繋がる。お金か出会いかはわからないが、思わぬところに行ったりもする。行き先不明な部分も大きいし、他人に理解できないけど自分には大切なものもたくさんあるので、ここは他者の評価はあまり取り入れなくて良い。評価に振り回されず、自分が価値があると思えることに素直に取り組みたい。