数珠つなぎで本を読む
8月頃から読書熱が高まっており、そのまま途切れることなく読書の秋に突入した。読みたい本を絶やさず手元に確保するために、定期的に本を買っている。
本を買う一番のきっかけは友人の紹介で、直接聞いたりブログを読んだりPodcastを聴いて、紹介されている本を買う。個人書店を応援したいのでメモしておいて本屋で買いたいが、急ぎの場合はAmazonでポチることもある。本を読んでいるとそのなかで別の本が引用されていたりする。そこで気になったものもメモして買う。こんな感じで数珠繋ぎで本を読んでいく。
本を紹介する本というのもある。「千年の読書」は生きづらさ・食・幸福などの章に区切られ、テーマごとに様々な本が紹介される。単純な列挙というよりは語りながらいろんな本を紹介していくような文体なので次々と読みたくなる。こういう本を起点に新しい本と出会うのも良い。「経営読書記録 表」はビジネス本版の紹介本だ。著者の楠木さんは錚々たるビジネス本の帯コメントを書いたり翻訳したりしている。その楠木さんが読んだ本のなかから特に印象深いものを紹介する。選書というと小説やエッセイなどが多い印象があるが、この本で紹介されるのはゴリゴリのビジネス本、しかもどれも上質なもので素晴らしい。ビジネス本は多く出版されているが、すぐに使えるテクニック!みたいなものではなく長く自分の中に残る本を読みたいと思っている。玉石混合のビジネス本のなかで、確かな目で選書してもらえるのはありがたい。
自分のために誰かが本を選んでくれるというのに憧れて、本屋の選書サービスを利用したこともある。毎月自分に合うと思われる3冊程度の本が定期的に送られてくる。まるで違うジャンルの本を読めたりして面白いかなと思ったが、あまり読みたいと思える本が届かず3ヵ月ほどで解約してしまった。これはもっと自分の興味関心を理解してくれている人にやってもらうと面白くなりそう。昔テレビで老夫婦が経営するローカルの本屋さんが取り上げられていて、そこで子供向けに絵本の選書をするというのがあった。年齢にあわせていま読んでおいてほしい絵本を選び、その感想を聞いてまた次の本をおすすめする。その選書がとても人気という話だったが、これの大人版が欲しい。たとえば今は政治とか国会とかの仕組みを学びたいが、なかなかエントリーで何を読めば良いかわからない。そういう相談相手がいるだけでも読書のとっつきやすさはかなり変わる。
気になったものはとりあえず買うことにしてるので、いわゆる積読状態になる。積読にはなってて全然良いと思う。ふとした時にあるジャンルの本を読みたくなる。そのタイミングはまちまちなので、そういう気持ちになったときにすぐ手を伸ばせるよう手元にいろいろ準備しておく。突然興味がなくなって、その分野はもうお腹いっぱいになることもある。そのときはもう読まずに置いておくか、スペースがなければ友人にあげるなりすれば良い。ちょっと読んで自分に合わないなと思ったらそこで読むのをやめたりもする。一冊一冊絶対に読まないといけないと思うと息苦しくなるので気楽に読み替えるようにしている。人には読書体力的なものがあるらしく、自分の読書体力はそこまで高くはないので超難しい本は選ばないようにしている。ページ数もあるが翻訳本とかドキュメンタリーとかは体力が必要。エッセイや技術本とかはスラスラ読める。一番読みやすいのは芸人のエッセイ本で、ハライチの岩井さんやかまいたち山内さん、ぼる塾日記などは読書に戻ってくるきっかけになった。こういう本は他人にも薦めやすい。
読書体力でいうと、一日に読みたくなる文字数は決まっている、みたいな話を昔どこかで聞いたことがある。仕事でたくさんメッセージをやり取りしたり、何かのドキュメントを読み込んだりした日はあまり本に手が伸びない。考えたり体を動かしたりした日は読みたくなる。そういえばXから距離を置くためにアプリを消したりおすすめフィードを非表示にしたりしてから本を読むことが増えた気がする。単純に時間が増えたためだと思っていたが、触れる文字数が減ったというのも影響しているかもしれない。適当に流れてくる情報で文字カウントを消費するのではなく、自分が読みたいものを読むようにしたい。
アクセシビリティに関するNのこと(後編)
アクセシビリティと似ているものとしてユーザビリティがある。ユーザビリティが使いやすさを意味するのに対し、アクセシビリティはそもそもアクセス可能かどうかを表す。音声で操作できたり拡大して文字を読めたりするのがアクセシビリティ、サービスの使い勝手が良くて目的を達せられるのがユーザビリティ。バリアフリーという単語が昔はよく使われたが、それは特定の障害を取り除く意味合いがあった。いまでは障害は濃淡あれど人それぞれあるもので、すべての人にとって使えるものを提供しようというのでアクセシビリティと呼ばれる。包括するという意味でインクルーシブデザインなどと呼ばれることもある。
障害とはなにか?個人が持つものではなく、環境との間に生まれるものだと理解している。視覚障害の方でも勝手をよく知る自分の家なら楽に移動できる。外に出ると気をつけないといけないことが多い。これは外の建物やサービスで配慮が不足しているから。人と環境の間に障害があり、それはひとつずつ取り除いていける。ここでいう障害はグラデーションがある。例えば車椅子の人にとって使いやすいよう作られた駅構内は、スーツケースを引いている人にも助けになる。一時的に足を怪我し、松葉杖をついているときも助かる。人によって能力はさまざまで、階段を何段か登るととても疲れてしまう人もいるかもしれない。アクセシビリティを高めることは全体にとってポジティブになる。Webサイトのすべてをキーボードで操作できるようにするのは、視覚障害者にとって大事なことだが同時にキーボードを使いこなして効率化したい人にもよろこばれる。
ただし、「障害者のためのデザインは結局、非障害者にとっても有用だ」と安易に考えすぎるのも注意が必要。非障害者にとって役立たないものの優先度が下がるわけでは決してない(むしろ感覚的にはあがるべき)。ニュースの手話通訳や点字ブロックは障害者のニーズにのみに応える。韓国では美観上よろしくないという理由で点字ブロックの色が目立ちにくいグレーになっているらしい。全員にとって、を強調しすぎるあまり本来の問題を解決できなくなるのは本末転倒だと頭に入れておきたい。ちなみこのあたりの話は「サイボーグになる」という本に教えてもらった。障害をもつSF作家と俳優の二人が書いた本だが、社会の障害と人間の感情、テクノロジーとの関連について書かれていてとても面白かった。
考慮されていない施設に後からエレベーターやスロープをつけていくのは費用や工数の面で時間がかかる。最初から考慮して設計していれば元々の建てる工数とほぼ変わらずに作ることができる。これはWebの世界でも似ている。データベースを設計するとき、サービスが成長して後に必要になる機能を見通しながら、将来に破綻をきたさないように設計する。後からまったく想定外の仕様を実装するとなると大幅に時間がかかる。それを避けるために最初にいろいろ考慮してつくるわけだが、Webアクセシビリティもそれに近いかもしれない。作ったものを後からWebアクセシビリティ対応するのではなく、最初から考慮して設計・実装していく。スタート地点から設計に組み込まれていれば拡張もしやすいし、使いやすいようにチューニングしていくのも簡単。設計の時点で気づければ、いまの時代解決のための手段や技術はたくさん存在する。まずは気付けるように、いろいろな環境や障害を知っていくことからなのかなと思っています。
アクセシビリティに関するNのこと(前編)
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時間くらい経っていると、こういう冷静な脳が働かなくなる。一度画面から離れて、人に話したり状況をテキストにまとめたりするのは視野を取り戻す効果がある。
今回カフェで当たった問題は、自分があまり詳しくない技術の周辺で発生した。勉強中の身なので自信がない。そうなるとエラーの内容でググって一発で誰かの答えを探そうとしてしまう。熟達した分野なら早い段階で落ち着いて問題整理に時間をつかい、一つずつ可能性を潰していったと思う。詰まったら立ち止まって状況を整理すること、自信がなくてもいつも通りのプロセスをふむこと。これらは意識しておきたいポイント。