「URL」を指して「リンク」という言葉が使われる例が増えている気がする

たとえばGoogle Docsでは、見出しの部分を右クリックすると「見出しリンクをコピー」というメニュー項目が出現する。

たとえば、Amazonの商品ページでは、共有ボタン¹のメニュー内に「リンクをコピー」がある。下に貼ったスクリーンショットでは幅が足りず「リンクをコ...」と表示されてしまっているが、実際には「リンクをコピー」と書かれている。

たとえばInstagramでは、「投稿のオプション」（投稿右上にあるミートボールボタン）内に、「リンクをコピー」がある。

macOSのターミナルは、URLらしき文字列が表示されているところで右クリック²すると「クイックルックリンク」「リンクを開く」というメニューが出現する。「クイックルックリンク」は、小さなポップアップ内にWebページを表示し、ブラウザを使わずに確認する機能だ。

こんなふうに、https:// や http:// ではじまる「URL」を指して「リンク」と呼んでいる事例は数多くある。日本語のUIばかりを紹介したが、英語のUIでも「link(s)」がよく使われていて、おそらく上に紹介したものも英語設定にすればそうなるだろう。スマートフォンアプリでもよく見る表現だ。

「リンク」を作るための文字列が「URL」

なぜ、「URL」ではなく「リンク」という表現が使われるのだろうか。その理由のひとつに、URLがそのまま表示されないことが多いから、というのがあるのではないだろうか。

最近の多くのWebサービスやアプリでは、URLが貼り付けられると、だいたいそのページに関する情報がURLよりも強調されて表示される。URLらしきものが含まれているとき、サービスやアプリはそのURLをリクエストし、OGPを中心に情報を取得する。OGPには画像（og:image）を含めることができ、URLを含む投稿やメッセージではこの画像がすっかり主役になる。それ以外にもページのタイトルや説明文なども同時に表示されたりする。

Twitter (X) では、URLはよく一部が省略された表示になる³どころか、URLに後続するコンテンツが無い場合は、URLの文字列が全く表示されていない状態にすらなる。

つまり投稿の操作としてURLを貼っていても、実際に投稿されるものは「URL」という言葉では言い表せない。画像やタイトルが表示され、元のURLは原型を留めないこともある。となれば「URLを送信した」というより「リンクを送信した」と言ったほうが適切だろう。

https:// や http:// ではじまるURLは、ユーザーにとって「Webページの場所を示す文字列」⁴というより、「リンクを作るための文字列」という使われ方をすることが多いものになっているのではないだろうか。特に「リンクをコピー」みたいなメニューでユーザーがやろうとしていることは、SNSへの投稿だったり、メッセージの送信であったり、ブログでの紹介であったりするはずだ。それらはどれも「リンクを作る」行為で、そしてWYSIWYGな入力欄だったら、貼り付けた途端に「リンク」となり、すこし待つとタイトルや画像が表示されたりもする。

はてなブログのMarkdownモードはWYSIWYGでないけれども、URLを貼りつけようとすると「リンクを挿入」ダイアログが表示され、「埋め込み」「タイトル」「URL」が選べるようになっている。やっぱり、「リンクを作るための文字列」なのだろう。

「URL」は意識されなくなっていく

「URL」が無くなったわけではない。いまこの記事を書くために使っているはてなブログ執筆画面でも、右側に表示されているメニューに「カスタムURL」の入力欄がある。Webサービスの企業で働いていることもあってか、仕事のなかで「URL」という言葉が通じていない状況は思いあたらない。

とはいえこれらはWebを「つくる」側の世界の話で、もしかしたら、近い未来、「URL」は「技術屋さんの用語」になっていくような流れがあるように思う。

縦向きに持ったときのスマートフォンのブラウザのアドレスバーは狭く、長いURLの全体を表示することはできない。iOSのSafariはアドレスバーをタップしないかぎり、ホスト部分だけの表示になる。PC向けのChromeも https:// のようなスキーマ部分をクリックするまで表示しなくなって久しい。

URLの表示を削られつつもアドレスバーがブラウザの一丁目一番地とも言える場所に残りつづけているのは、Googleのような検索エンジンへの入口も兼ねているからというのも理由の一つだろう。Chromeが登場した頃のFirefoxやInternet Explorerは、アドレスバーとは独立した検索欄を装備していた。そこから数年で各ブラウザはアドレスバーに検索機能を統合して、アドレスバーはWebの「入口」となった。

しかし、いわゆる「AI搭載ブラウザ」によってその状況は変化していくかもしれない。いまは（Chromium由来の）Chromeによく似たUIを採用しているケースが多いようだが、AI中心のWebブラウジングに最適化していくうちに、アドレスバーの位置付けは変わっていくのではないだろうか。

Webの仕組みとしてURLは間違いなく残るだろう。しかし、それは「つくる」側が意識しているものだ。一般のユーザーからはどんどん見えにくいもの、見えないものになっていくのかもしれない。

スマートフォンのUIでは「共有」メニューがWebに限らず配置され、いま見ているものを他のアプリに送ったり、クリップボードにコピーすることができる。JavaScriptから「共有」メニューを呼び出すこともできる。「リンクをコピー」ボタンを備えたWebサービスも増えた。もはや、URLを触らずともWebページを、いや「リンク」を共有する便利な手段は充分にある。

テレビや印刷物などからWebページを案内するときも、QRコードを使用するやり方はすっかり定着した⁵。URLを自分自身の手で打ち込む機会はほとんど無くなった。短くて覚えやすいURLだと嬉しいという実感はだいぶ薄まってしまった。

Twitter (X) に新しく登録するときにランダムなスクリーンネーム（URLや @ によるメンションで使われる文字列）が割り振られるが、そのスクリーンネームのまま使い続ける人がそれなりの数いることは、そういった流れがすでに存在していることを示しているものだと思う。

---

1. role="button" がついている中身が空の <a> 要素で、背景画像として「共有」によく使われる長方形から上向き矢印が出ているアイコンが設定されている。アクセシブルネームがない状態になっており、見た目から「共有」と呼んでいる。↩
2. MacBookのトラックパッドやMagic Trackpadでは、デフォルト設定では2本指でのクリックで操作する。macOSのトラックパッドの設定の用語を使えば「副ボタンのクリック」と呼ぶべきだろう。↩
3. リンク先（<a> 要素の href 属性）が投稿されたURLではなく t.co のものになる点は、表示されるものではないためここでは関係ない。↩
4. URL Standard では Locator と言わなくなったとか、RFCやIETFは有効なものとして存在しているのでやっぱりLocatorでもあるとか、そういう話は今はしていない。↩
5. スマートフォンではなくPCに対してURLを渡すには面倒が発生するが、受け取った側がブラウザの同期機能などを使えばよいだろう↩

コードレビューの性質をUIデザインに輸入したい

あくまでこれは私の視点からのものであることを断わっておく。一般化して語ろうとすると筆が進まなくなってしまう。

もともとソフトウェアエンジニアからUIデザイナーになった。それ以前からエンジニア以外の仕事をする人と関わり、その仕事を観察していくうちに、「コードレビュー」がいかに独特の世界であったかということを度々思い知らされてきた。これまで当たり前にやってきた、あるいは周囲が当たり前にやっていた「レビュー」という行為は、自分のまわりのソフトウェアエンジニアという職種の独特の特性と文化によって支えられていた。

コードがすべての世界

ソフトウェアは閉じた世界で、森羅万象がコードでできている。設計書などの中間生成物もあるが、ソフトウェアエンジニアでありプログラマーである人は、それらが最終的にコードに落とし込まれる前提をもっている。コードはプログラミング言語、つまり曖昧さの排除された人工言語で記述され、書かれている通りにしか動かない。

すべてのコードが誰かにレビューされていれば、世界のすべてが誰かにレビューされていることになる。その世界の端にはAPIやUIといったインターフェースがあり、全てのものはそれらを通ってくる。インターフェースさえ押さえられていれば、世界のすべてがレビューされている状態を保つことができる。実際にはプロジェクトの立ち上げでは誰かがエイヤッと大量のコードを書いていたりして、すべてのコードがレビューされていると言えない場所があったりもする。しかし、ある時点から先の変更のレビューをしっかりやっていくことで、すべてがレビューされている状態に近付いていくことができる。

これが、UIデザインに対するレビューではなかなかそうはいかない。常に想定外のユーザーの想定外の状況、そこから発せられる想定外の要求があることに怯えなければならない。むしろ「UIデザイン」という行為をソフトウェアエンジニアリングから切り出し、ソフトウェアは与えられた要求のみを満たせば良いとしていることで、ソフトウェアエンジニアのためのコードだけの世界を作れているのかもしれない¹。

UIデザインを支えるのは、二次元の図面であったり自然言語のドキュメントであったりする。そこには曖昧さがどうしても発生する。曖昧さを取り除いていく技術もたくさんあるが、それは関わる人に依存する。コンパイラなりインタプリタなりがエラーを吐いてくれたり、テストコードを動かして検証できたりするわけではない。ユーザビリティテストをはじめとしてUIデザインにもテストなり検証なりというものはあるにはあるが、目的も性質もかかるコストも異なっている。

お互いをレビューできる

コードは想定通りに動くか、計算量が適切かなどの視点で質を客観的に評価しやすい。コードレビューは熟練者だけでなく、チーム内の多くのメンバーが参加することができる。もちろん初心者プログラマーがレビューを任されることには不安がつきまとうし、変更前のコードを書いたりレビューしたりしていたりなどでこの人のほうが安心できるということもある。だが、コードレビューに関する話題では、だいたいソフトウェアエンジニアのチーム全体でお互いにレビューすることが理想とされているのではないかと思う。

今でも自分がコードを書くこともあれば、コードレビューすることもある。コードを書けばレビュイーになるし、チームから信頼されていればレビュワーになることができる。レビュワーとなれる人が多いことのメリットは、少数のレビュワーにレビューの仕事が集中しないことだ。レビュワー役が誰かに集中してしまうと、その人はレビューばかりやることになり、自分でコードを書いてレビュイーとなることができなくなる。レビュイーとしては自分でコードを書いて動かしている人にレビュワーとなってもらうほうが安心できる。やはりなるべく多くの人がレビュワーとなれるほうがいい。上手い仕組みだ。

UIデザインではこれが上手くいくだろうか。想定外と曖昧さをなるべく排除し、より良いUIとなっているかをレビューするにはそれなりの知識と技術が必要となる。曖昧さが含まれるかもしれない資料を読み解き、想定に漏れがないかを再検討し、そして様々な要素が複雑に絡まりあったユーザビリティの多寡について判定する。もし問題がありそうなら、その問題を曖昧さが小さくなるよう言語化して伝える。どうしても、そう簡単にできるようになるものではないように思えてしまう。

レビュワーとなれるデザイナーはどうしても限られる。自分自身がいまUIデザインをレビューする立場にあるが、あらためてこれを書いていて不安になる。

レビューを通して学ぶ

コードレビューがレビュワーにとってもレビュイーにとっても学びのあるものであるというのもよく指摘される。レビュイーはレビューコメントを通して、レビュワーは他のメンバーの書いたコードを読むことを通して学びが得られる。これもお互いにレビューできるがゆえの利点だろう。レビュワーから指摘されたことを自分が書くコードに反映し、自身がレビュワーとなるときにはレビュイーに伝える。レビュイーとして読んだコードに感心して自分の書くコードに反映したり、レビュイーに伝えたりもする。

自分自身もコードレビューによって鍛えられてきたと思っている。あのときのあのPull Requestがなければ、きっとこのコードは書けなかっただろうと思い返せるものはたくさんある。繰り返しレビュイーとなりレビュワーとなってきたことの蓄積が血肉になっている。

これに近いことはUIデザイナーとなって以降にも起きていたのではないかと思う。エンジニアからデザイナーとなったこともあって、その初期からデザイナーとエンジニアの間の橋渡し役や双方からの相談役を求められたりすることも多く、そのなかでたくさんのことを説明してきた。なぜこのUIは良いのか、なぜこのUIでは良くないのか、ひたすら言語化に努めてきた。いわば、レビューという枠組みのない中で、レビュワーとなってきた。思い返せばそのおかげで、UIデザイナーとしてのスキルを獲得できてきた面は多いのではないかと思う。

そういった学びの得られるものでもあり、そしてレビュワー役が誰か（というより、自分）に集中するのを防ぐためでもあり、コードレビューと同じようなものを、UIデザイナーのチームに持ち込めないかと考えている。どうすればいいのかはまだわからない。UIデザインにまつわるだけでなく、レビュワーをするだけの自信がないというのもあるだろう。いきなり今後は相互レビューにしますよ、なのであなたはレビュワーもやってね、と言えるものではない。たまたま自分は、あのときそうせざるを得なかっただけだ。

ただ、言葉にすることを繰り返すことで前に進めてきた過去を省みると、まずはこうして書いてみることがもしかしたらスタート地点なのかもしれない。だからこうして書いてみている。

---

1. ソフトウェアエンジニアもユーザーに対峙し、要求定義に関わっている。運用により想定外のことを求められることもある。エンジニアも想定外の要求に晒されている。しかし、今はそういう話はしていない。↩

またブログを書こうと思った

ちゃんとした文章を残す場所を作ろうかと、ここ1年くらいずっと悩んでいました。

ブログというものを以前に書いていたのは10年以上前で、長いあいだ新しい記事を書くことがないまま放置してしまっています。いつの間にか、「自己満足でブログを書く」という行動をしなくなっていました。他のSNSもあるし、仕事も忙しいし、それでいいやと思っていました。

技術者としての言葉を自由に書きたい

数年前までは「会社」という文脈のなかでプログラミングやソフトウェア技術を語ることが多く、社内情報ツールにはいろいろ文章を書いていたはずですが、あまり表に出したものがありませんでした。

風向きが変わったのは「Webアプリケーションアクセシビリティ」を出版した頃でした。

Webアプリケーションアクセシビリティ──今日から始める現場からの改善 WEB+DB PRESS plus

自分に専門分野と言えるものができたおかげで、広く発信しなければと思う機会がしばしば発生しました。そこで使ったのは、noteやQiitaやZennといったプラットフォームでした。これらのプラットフォームには、それぞれ独特の雰囲気があるので、内容や届けたい相手によって使うプラットフォームを選んでいました。

note.com

zenn.dev

qiita.com

この書きたいことにあわせてプラットフォームを選ぶ戦略は、それなりに効果的だったと自負しています。しかし、「どのプラットフォームに馴染むかわからないものがいつまでも書けない」ということでもありました。書きたいことはいろいろあったのに、どこにどんな雰囲気で書くべきか悩んだ挙句、どこにも書かないうちに気持ちが冷めてしまうということがしばしばありました。

SNSに疲れた

ブログを書かなくなった要因として、なんでもSNS、というよりTwitter (X) に書くようになったことが大きかったと思います。2010年代のTwitterは楽しかったです。Twitterの上で写真も動画も長い文章（スレッド）も書けて、読めて、リアクションできて、その通知が来て、承認欲求をしっかりと満たしてくれました。

それが、いまのX (Twitter) はなんだかなぁ……という感じるようになってしまいました。これにはいろいろな要因があるだろうし、ここでは触れません。XとなったTwitterから去って別のSNSに移住した人たちも多く、なんでも書いて満足できる場所ではなくなってしまいました。

そういうこともあって、すこし腰を据えて、またブログを書こうかなぁという気持ちになってきました。

自分を発信できていないということ

SNSなどで私のことを見たことがある人は、私を「アクセシビリティに詳しいフロントエンドエンジニア」くらいに思っていそうな気がします。ところが私の会社での職種は「UIデザイナー」です。私のUIデザイナーとしての姿、理想としているあり方みたいなものをあまり発信できていなかったと思っています。

UIデザイナーといっても、BtoBサービスのデザインをしているので、世間一般の「デザイナー」像からはかけ離れているかもしれません。絵は描かないのはもちろん、華やかなものを作るわけでもありません。しかし仕事にラベルを付けるなら「デザイナー」としか呼びようがないのです。そして、この仕事をするにはソフトウェアエンジニアリングの知識や視点が必要だとも思っています。自分のような人が人材市場に適度に増えて、社会的に認知されて、採用が楽になったり自分の給料が増えたりしてほしい気持ちもあります。そういうことを考えているわけですが、どこかに書いたりして来なかったのです。

とはいえ「デザイナーよ、コードを書け！」みたいな説教くさい話には誰からも耳を貸してもらえないでしょう。それよりももっと、自分の視点や考えや行動を書き残していったほうが効果がありそうです。

私は人付き合いが苦手で、自分からは人脈をうまく広げられません。これまではSNSを軸にすることでなんとか社会と繋がってきました。そのSNSだけでは心許ない以上、別のことを始めたほうが良いだろうという思いがあります。

やっぱりはてなブログ

「ブログを作りたいなぁ」と考えていると、次には「どうせならモダンなフロントエンドのライブラリを使って、全部自分で作って……」という気持ちが生まれてしまっていました。そしてデプロイ先や記事の管理の仕方などを妄想しているうちにいろいろな課題が見えてきて、面倒くさくなってやめてしまうというのを繰り返していました。

目的は文章を書いて公開することでした。なんでそのためにコードを書こうとしてしまうのでしょうか。

ということで、再びはてなブログに戻ってきました。広告を自分で管理したいし、ちゃんと続けていきたいのではてなブログPROを2年分払いました。

ブログ名を付けるところで「ああ、そういう世界だったよな」とハッとさせられました。「まず自分の投稿先に名前を付ける必要がある」というのは、ブログならではなんじゃないでしょうか。5分くらい考えて「層の狭間で」という名前をつけました。「層」はいろいろな「層」を指していますが、これはそのうちの記事のネタのために取っておきます。

何記事か書いて飽きてしまうかもしれません。それどころかこの記事で止まってしまうかもしれません。できれば長続きさせていきたいと思っています。もし応援していただけるのなら、次の記事からでも、何らかの形で応援のメッセージや、書いてほしいことのアイデアなどがいただけるとありがたいです。