
はじめに
直近はお仕事で、とある卸問屋さん?でWebサイト開発を支援してるんですが、Webサイトそのものの開発を行っているわけではなく、社内横断のデザインチームの人間としてUIのライブラリの開発と提供・メンテナンスを行っています。色々あってなかなか進まない (ウンザリ) ですが、このたびやっとフォントを確定して実装できました。
私も共通基盤側に立ってライブラリ配布をするのも、デザイナーチームで働くのも、四半世紀のあいだITで飯食ってきて初めての経験なんですが、今回のフォントについては特に発見が多かったので、後日同じことをやるときに抜け漏れが無いよう備忘録的に残しておきたいと思います。
なお、フォント自体の選定は専任のデザイナーさんが行いました。オレはそれをライブラリに実装したり、ルール決めたり、npmで配布できるようにしたり、ビジネスオーナーたちが漏らした不安を解消していく (貴重なデザイナーリソースを無駄な作業で消費しない) ことが主な役割です。
UIライブラリにおけるフォントとは
早い話が「1サイトの中でフォントは統一できるようにしましょう」ってことですね。
TOPページではゴシック、次のページでは明朝体、こっちではポップなやつ、あっちではシックなやつ、とかサイトでフォントが統一がされてないと鬱陶しいですし、ブランドイメージが揃わないですよね。そういうことが無いよう、「このUIライブラリを使うサイトは全部このフォント使ってね」って強制的に単一のフォントしか使えなくなるようにします。
実際にフロントエンドを開発するエンジニアの方がいちいち「あれ、フォント何を指定するんだっけ?」悩まなくても済むようにする、という役割もありますね。
書体名と配信ファイルを特定する
今回オレが開発するUIライブラリは、とあるOSSのフォントを採用しました。このフォントの選定理由は
- フリーライセンス (無償) か
- サイトイメージと合致するか
- 一般的か (いちいちインストールしないと使えないようなフォントではないか)
- etc...
みたいなものがありました。前述のように選定自体は専任のデザイナーさんが行っています。
このOSSフォント、配布サイトが本家サイトとGoogle Fontというフォント配布のプラットフォームみたいなサービスの2箇所で配布しているんですが、同じフォントなのに若干ですが内容が異なるんですよね。その辺も調べて差分を明らかにし、どちらから採用するか (今回の場合は本家サイトを選択、理由は後述) を決めました。
使用できる文字を確認する
日本語として表示する文字には「環境依存文字」というのがあります。フォントそれぞれが必ずしもフォローしていなくてもOKっていう特殊な文字です。Windowsだと表示できるけどmacだと文字化けする、とか、ああいうやつですね。具体的には「①」「Ⅳ」「≒」のような特殊な記号や「髙」(はしごだか、と呼ばれる「高」の旧字体)や「彅」(草なぎ剛さんの「なぎ」の漢字)らがそれに該当します。最近では「☺」みたいな絵文字も環境依存文字に含まれていたりしますね。商習慣上どうしてもこれらの環境依存文字が使われるケースでは、どの程度そのフォントがカバーしているかを調査する必要があります。
(※この文章はWindows11 / Google Chromeで記述していますが、それ以外の環境で括弧の中の環境依存文字がどのように表示されるかは確認していません)
低速時読込をどうするか
基本的にUIライブラリの中にフォントを直接取り込んで再配布するのではなく、UIライブラリにはフォント取得先の指定だけ書いておいて、そこから本家サイトだったりGoogle Fontだったりに取りに行ってもらう実装を今回は選択しました。フォント側が刷新したときにUIライブラリでいちいち取り込み直しを行うのを避けたかったんですよね。
それゆえ、フォントのロードには時間がかかります。ネットワークが何らかの理由で遅くなっているときは、本来指定のフォントがすぐサイトに反映できないケースが存在します。
そのような場合に備え、どの環境にもたいてい入ってるだろ?みたいなフォントをバックアップとして指定しておき、いざ本命のフォントが読み込めません!って時には大体のフォントを表示してもらいます。この代替フォントもあらかじめデザイナーさんに決めておいてもらいました。
pxやptではなくサイズ用の文字列でサイズ指定させる
フォントのサイズを「12px」とか「36pt」とか「60rem」みたいな数値で指示できるようにしておくと、デザイナーの指示通りのサイズではなく、フロントエンドエンジニアの誤った数値指定が入ってしまうことがあります。
それを防ぐために「xs」とか「m」とか「xl」とかいったフォントサイズを指定するためのクラス名にあらかじめフォントサイズを指定しておき、そのクラス名でしかフォントサイズを指定できないようにしました。間違った指定をするとデフォルトサイズで表示されるので、実際に画面描画したときに結構違和感が出るので気付ける、という想定です。
デザイナーの意匠を徹底させるための予防策ですね。
Storybookで事前確認できる
今回のUIライブラリはStorybookを用意して、実際サイトに組み込む前にどのような表示や動きになるのかを確認できるようにしています。背景色も実際のサイト用に定義されたカラーが複数あり、それらをbackground-colorにして確認できるようにしました。この辺はフォントに限らず全てのUI部品が同じように確認できるようにしています。
今回はAtmic Designを採用しているので、ある程度大きな画面部品の場合には構成要素を確認する意味でもStorybookを活用してほしいと思っています。(まだそこまで大きな画面部品が登録できてない)
ライセンス表記が確認できる
OSSのフォントと言えどライセンス表記は必須です。
今回の場合はUIライブラリを管理するGitHub上で、READMEとLisence専用ページを設けてフォントのライセンスを記載した他、配布物の中にも、メインとなるCSSの先頭にライセンス表記を行いました。
今回はフォントだけでなく、OSSのアイコンについても同様にライセンス表記を行っています。
理想を言えば実際UIライブラリを活用するサイト側でも、TOPから1ステップで移動できるページにライセンスページを設けるべきですが、それについてはUIライブラリを託す開発チームにゆだねています。
OSSの採用・実装に同意してもらう
ここまで色々長々と書いてきましたが、そのいくつかはビジネスサイドの「これちゃんとしてなくて大丈夫?」「無償配布とか、急に有償に切り替わったりしないの?」みたいな不安の声を払しょくするために対応してきた内容もいくつかあります。
ライセンス表記は、著作権法的に全く問題ない状態とはどういうものなのかが断定できるまで調べました。
環境依存文字も、一般的に使用される環境依存文字を全てリストアップし、それらをこのフォントがどの程度カバーしているのかを調べました。
無償配布が優勝に切り替わらないか、も、これまでの事例を全て調べ上げました。これはフォントだけではなく、アイコン素材も、OSSも、ほぼすべてを調査対象としました。結果、
- 無償公開していたOSSが有償に切り替わったケースはほぼ存在しない
- 同じブランドから有償公開のOSSが公開される場合、無償のそれを有償化するのではなく、新たに有償用のOSSを立てて公開することが殆ど
というところまで徹底的に調べ上げました。
また、仮に今回採用したOSSフォントが有償化したり、突然非公開になってしまったとしても、即座に別のフォントに切り替えられる実装を採用しています。
こういう質より量みたいな絨毯爆撃的調査が行えるようになったのは、AIエージェントの多大なる恩恵ですね。
おわりに
このような様々な努力の甲斐あって、やっとこさUIライブラリに採用するフォントを確定し、無事実装できるようになった、というわけです。たかがフォント1つ選ぶだけですが、やることはなかなかあって大変ですね。
UIライブラリの開発担当者になってフォントを実装しなくちゃならない、なんてシチュエーション、そうそうないと思いますが、もし遭遇したら参考にしてみてください。






















