今年もHTML5 Conference 2017の展示ブースでは、私ことDJ KATOの特別ラジオをお届けしていました。今回はビジネス・アーキテクツ太田良典さんとサイバーエージェント原一成さんをゲストに迎え、「UIデザインとアクセシビリティ」テーマに語っていただきました。その再現レポートをお届けします。ぜひ、カンファレンスレポートの番外編としてお楽しみください！

まずは、どんな講演内容だったのか教えてください

「ビジネス・アーキテクツの太田です。普段はWebアクセシビリティ関連の活動を主に行っています。『多様なユーザーニーズに応えるフロントエンドデザインパターン』というタイトルで講演させていただきました。よろしくお願いいたします」

「サイバーエージェントの原です。アメブロのフロントエンド開発を中心に行っています。『“モダン” ウェブアプリケーション ～アメブロ5ヶ年計画～』という講演タイトルで、アメブロの “モダン化” 実例に沿った考え方や技術採用事例、今後の展望などをお話しました」

「お二人とも先ほど同じ時間に講演されてきたんですよね。どちらかのお話を聞いた人は、どちらかが聞けなかったと思うので、どのような話をされたか教えていただけますか」

「私は、11月4日発売の『インクルーシブHTML+CSS & JavaScript 多様なユーザーニーズに応えるフロントエンドデザインパターン』という書籍で紹介されている、アクセシビリティに配慮した実装手法について、例を挙げて紹介しました」

「どのような実例でご説明されたのでしょうか？」

「先ほどのセッションではサイトでの操作など、使いやすくするためにはどうするかという話をしました。例えば、商品のリストを値段の高い順や安い順に並べたり、最新順に並び替えるなどの機能も、基本的な要素を使ってマークアップしましょうという話ですね。絞り込みの機能を選択するのは高い順・低い順・古い順・新しい順が多いのですが、それは4個の中から1つを選ぶ機能なので、ラジオボタンで実装すればいいとか。

よくある問題は見た目がきれいになるからと、ラジオボタンじゃなくて<span>とか<div>で実装して、JavaScriptでクリックイベントをつけて操作できるようにするとか。それは、ラジオボタンで実装することによってキーボード操作であっても使いやすくすることができます。でもソフトキーボードでちゃんと使えるのか、スクリーンリーダーでアクセスしたときにちゃんと読まれるのかなど、いろんな問題があるわけです。なので、基本的にはちゃんと機能に合った要素を使って、見た目は後からがんばりましょうという話ですね」

「先に知っておけば、そういう落とし穴には落ちないということですね」

「HTMLをやってる人なら誰でも知ってるはずなんですけど、なぜか<div>とか<span>を使ってしまうんですよね。知っていることと実践できているかというのは別なんです」

「そうなってしまうのは、楽だからなんでしょうか」

「というか、『見た目から入ってしまう』からそうなるんですよね。見た目から入ると『枠で囲まれているから<div>かな』という考え方になりがち。後から結構スクリプトでできちゃうので、それなりに動くものができるんですよね。ただ、それがどんな環境でも使えるかというと、結構使えないことがあるのが問題です」

「そういったことをいろいろご紹介されていたんですね。チェックボックス以外のトピックも聞いてみたいです」

「リストや見出しをちゃんと使うことですね。あとJavaScriptやXHRを使ったパフォーマンス改善やアクセシビリティの話を中心にしていました。

アクセシビリティは『JavaScriptをできるだけ使うな』という議論になることが結構多いんです。でも、今普及してるUIはJavaScriptで動かしていることが多いのに、そんなこと言われても困るんですよね。今回ご紹介してる本ではこうすればできるという技法を紹介しています」

「ありがたいですよね。僕もJavaScriptを使いまくりなんですけど、実際のサービスを作る上ではやっぱり使わざるを得ない。さらに、ネイティブアプリとの差をなくしていったり、使いやすさを向上させるには必要な技法です。ピンク本と呼ばれる「デザイニング Web アクセシビリティ」という本があるんですが、毎週チームで読み会をしています」

「そのピンク本、ありがたいことに私の著書なんです(笑)」

「うちの会社にもあります。みんなは読んでいる本なんですけど、僕はどっちかっていうとエンジニアというよりディレクター寄りということもあって、まだ読んでいませんでした。すみません…」

「ディレクターさんにもすごくいい本ですよ」

「というか、ディレクターさんにもぜひ読んでいただきたいと思って書いた本です(笑)」

「なるほど！読みます！」

「実装だけじゃなくて、その上流から踏まえていきましょう、ということも結構書いているので、ぜひ読んでください」

「さっきのサイト制作の話に戻るんですけど、見た目から入っちゃうことが結構多くて。特にビジネスで評価する人って、この見た目がかっこいいとかから入っていきがちなんですよね」

「見た目と動きだけでしか評価できない人が多いという問題もありますね。見た目と動きがちゃんとしてればOKになってしまうことも多いんですよ」

「例えばディレクターがアクセシビリティを知らなくて、スクリーンリーダーなどの存在を知らなかったら、それだけで話が通じなくなりますよね」

「そうですね。それを解消するためにも、ぜひ！」

「まずこれを読むことで、関係者全員のしなくてもいい紛争が減ると」

モダンなウェブとアクセシビリティは両立できますか？

「原さんはモダンなウェブというテーマで講演されていましたが、アクセシビリティと両立するのは難しくないんですか？」

「難しくはないんですけど、ワークフローの中に組み込むのが結構大変ですね。プロジェクトは企画から始まって、デザインを作って…というように、見た目が前提なフローが多いので、どうしてもコードがわかる人はフロントエンドエンジニアくらいになるんですよ。評価できる人も」

「自然と優先度が下がっちゃう、というかんじですね」

「そうなんです。先程も言ったように『コードを知らない』って方もいるので、ピンク本は『JavaScript使うな』とは書いていないので、その辺もありがたいです」

「そういうことですか！」

「昔ながらのアクセシビリティをやってる人だと、『JavaScriptは使うな！』と言っちゃう人もいるんですよね。現場ではそう言われても困るので、なんとかしたいって思ってたんです。今回の本はそういう内容がたくさん書かれているので、いいなと思っているんですよね」

「極端ですけど例えば『危険だから家から出るな』みたいな話になっているんですかね」

「そうそう。何かあった時に『これとこれとこれを準備して』とか『こういうことに気をつけて』というのを示してくれるかんじなんです」

ところで、普段はどんなお仕事しているんですか？

「話は変わるんですけど、太田さんは普段どんなお仕事されてるんでしょうか？」

「ビジネス・アーキテクツという会社で、Webの仕事をしています。主に大きな会社のWebサイトを受託で作ることが多いです」

「企業の公式Webサイトですね」

「そうなんです。グローバル展開している日本の大手企業が多いのですが、そうした企業はアクセシビリティのガイドラインを持っていて、各国に配布したりしてるんですよね。各国にもそれぞれサテライトサイトがあって、全部統一させようと取り組んでいます。そういうアクセシビリティのデザインガイドラインの配布や取り組みに対して、お手伝いをしています。ひと言で言うと、Web制作ですけど」

「ひと言だとそうなんですけど、大変そうというか、慎重にやってかないと…。なんか、あまり軽いノリで作れないサイトってかんじですね」

「重すぎるノリっていうのも問題で、これやるなって言いすぎてもガイドライン無視されるだけなので、やっぱり現場で使えるようにしていかないと。実際に使えるものを作って、かつ運用できるようにしていくということがすごく大事なんですね」

「そうすると、基本のWebだけではなく、モダンな開発手法も知らないといけないですね」

「最近だとモバイル用のページをレスポンシブで作るのが当たり前になっていると思うのですが、そういうところも考えないといけないことがありますね」

「スマートフォンのモバイル用のページのことや、PC用ページではどうかとか、デスクトップのリーダーではどうかというのも書いてあって便利です」

「原さんは、どんなお仕事をされているのですか？」

「私は完全に開発者で、2004年からずっとアメーバブログを作っています」

「長いですね！」

「2015年にリニューアルをしていますが、サービスの歴史も長いですね。主にフロントエンドを担当しています」

「歴史が長いと今までに積み上げてきたものも多いと思います。社内で設計が大きく変わったりすると、かなり大変だと思いますが」

「その辺はエンジニアと協力しながらやっていますね。iOSならiOSの、AndroidならAndroidのエコシステムっていうか開発環境と作り方の基本があるんですけど、その上で他の人と会話しながら、モダン、モダンって言いながら開発してます。閉じこもった自分たちだけのライブラリばかりでは、存続が危うくなると思うので」

「お二人ともなんというか共通するところがあるっていうか、戦っているポイントが結構似ているかんじがします」

「かなり」

「そうですね」

お二人の情報収集や勉強方法を聞かせてください

「お二人はどのように情報収集や勉強されているんですか？」

「今まさに勉強しているつもりです」

「そうそう。かなり勉強してます(笑)」

「気がついたら置いていかれてた…っていうのは一番避けたいのですが、そのためにどんなことをしたらいいのでしょうか。ニュースサイトを見るとか？」

「それもありますが、周りの人と会話をすることも大事なんじゃないかと。最先端の技術者たちとコミュニケーションをとったり、彼らがTwitterなどで何をシェアしているのかを見ることで、どういうものが流行っているかを知ったりすることが多いですね」

「僕も一番簡単な情報収集はTwitterですね。フォローしておいて、その人がリツイートしているものを見るだけでも参考になります。あと、海外の情報も重要なので、英語が読めるだけでも大分可能性は広がります。ちょっと時間差はあるかもしれませんが、日本語に訳してくれる人をフォローするという手もありますね」

「Twitterはすごい情報数があふれているので、普段あまり使ってないんですけど…。どうやって情報の絞り込みをするんですか？」

「もちろん、全部を読むわけではないですよ」

「技術系のカンファレンスで気になったものをフォローしているので、そこからとか」

「良質なツイートをしている人が発信している情報を集めて、どんどんその濃度を上げていくみたいなかんじなんですね」

「あとは情報を発信している人のところに実際に行ってみるとか。そういう会社に入っちゃうというのもありますね」

「なるほど！」

「簡単に希望したところに行けるかはわからないですけど」

「そういう意味では、サイバーエージェントさんは大変いい環境ですよね」

「うちは情報が自然に入ってくる環境なので、勉強する必要がないっていうか。極論ですけどね(笑)」

「自然にっていうのがすごいですよね。周りの人との雑談がなんかマークアップの話になるとか？」

「ちょっと気持ち悪いかもしれないですね、普通の人からすると(笑)。技術に興味がある人が集まっている場所というか」

「でも、マークアップの話で盛り上がれるってすごく楽しいですよね。いや、『それ変態だ』って言われそうですけど(笑)」

アクセシブルなサイト設計・制作について教えてください

「簡単なアプリケーションだったら自分で作ったりもするんですけど、実際に開発始めてみると<div>とか<section>とか、途中で<h3>や<h4>がだんだん適当になってくんです。100行超えてくると『あれ？もともとどんなかんじに作りたかったんだっけ』というかんじになって、全体のことがあやふやになってくるんですけど、どうすればいいんでしょうか」

「それはいい質問だと思いますね！早い段階から見た目を気にして、その段階で増やそうと考えちゃってるんですよね」

「はい。で、書きながら実行してるんですよ」

「それは自然ではあるんですよね。悪いことではないんですが、基本的にオススメなのは、まずCSSを一切適用しない状態でHTMLだけで作ってしまうこと。結構しっかりした構造が作れると思います」

「完全に素のやつですよね」

「さらに言うと、見出しから作っていくとか。それがマークダウンなんですが、逆に難しいかな」

「以前僕が経験したものだと、先にデザインが決まり、デザインカンプが上がってきて、スライスしてCSSをあてる。で、インタラクションとかをJavaScriptでやるという順番でした。ちゃんと考えたつもりなのに、だんだん破綻していくんですよね。いきなりフロートからやるとか、順番がおかしいとは思ってたんですけど(笑)」

「もしかすると、デザイナーさんもあまり整理できてないのかもしれないですね。うちではコンポーネント思考で、デザインから作っています。Webコンテンツをコンポーネントっていう単位で分割するんですよ。例えば見出しなら見出し、本文なら本文、リストならリストみたいなパーツに分割してデザインしてくんです。

それを組み合わせてWebページを作るというシステマティックなやり方をしています。ページごとにデザインするのではなく、パーツごとにデザインしたものを組み合わせてページを作るという考え方をデザインの段階からやっているんです」

「最初はみんな紙ベースというか、ペライチみたいなデザインで始めることが多いんですよね。紙って自由度が高いけど、文字や画像などのコンテンツをバラバラにすることはできなかったり、うまく区切れなかったりとか、Webとは考え方ややり方が違いますよね」

「逆にWebのやり方がわかっているデザイナーさんだと、『これは<h1>で』とか言ってくれたりするんですよ」

「あとは自分たちで共通部分を見つけてコンポーネント化していくとか」

サイトの構造やレイアウトデザイン、昔と今ではどう変わってますか？

「以前、コーディングは全然やらない人で完全にデザインだけやっている外部の人が、『こんな感じでよろしく』って送ってきたデザインが最悪だったことがあります。一方で、フロントエンジニア兼デザイナーをやっている人とやった時はすごくて、まずデザインの前にきちんと要件をはっきりさせてくれました。自分がちゃんと考えきれてなかったサイトの構造やボタンの位置にツッコミを入れてくれたりとか。みんながそれできるかっていうと厳しいですけど」

「今日登壇してる方たちもみんな通っている道ですね(笑)。めちゃくちゃのところからスタートして、だんだん良くなっていくという」

「それはあると思いますね。我々なんかの世代だとHTML3.2の時代からやっている人もいるので。以前はテーブルレイアウトというのがあって…」

「あー知ってます！昔やってましたよ、それ。一番最初にWebサイト作ったときに全部テーブルやりましたね」

「構造も何もあったもんじゃない(笑)」

「完全に見た目だけですよね。最近入社してきた若手なんかはテーブルレイアウト知らない世代でしたけど」

「ある意味うらやましいですね(笑)」

「昔はありだったんでしょうか」

「あるかなしかっていうと、なしだったんですけど。仕方がなかったっていうか」

「あれはフロートがなかったからとかそういうことだったんでしょうか」

「フロートがいつからあったかというのは難しい議論なんですけど、昔はブラウザのCSS周りの実装がボロボロだった時があって、IEでフロートすると横マージンが2倍になるとかありましたね」

「まぁ環境が整ってなかったというかんじですよね。だから一概にさっきの話も悪いとは言えないというか」

「Web標準が流行り出して、ブラウザの実装が統一されてきたのも、もう10年前くらいですね」

「モバイルが出てきてWebkitベースで確認できるようになって…」

「それ以前はもうぐっちゃぐちゃですよね」

「昔はできたデザインとマークアップした結果を重ねて、透過して1ピクセルもずれちゃいけないみたいな」

「ピクセルパーフェクトってやつですね！」

「聞いたことあります」

「昔は『全部のブラウザで同じ見た目にならないといけない』って時代があったんですよ。でも今はそういう時代じゃないですね、『デバイスによってちょっと違いますよね』ってのが当たり前になっているので」

「今はデバイスの種類がたくさんあるので、ピクセルよりも文字サイズはremとか、高さも%じゃなくてvwとか使うんでしょうか」

「状況によりますよね、使うべきときは使います。ちなみにそういう単位をどういうときにどれを使うのかという議論も、『インクルーシブHTML+CSS & JavaScript 多様なユーザーニーズに応えるフロントエンドデザインパターン』に書いてありますので、もしご興味があればぜひ！」

「ぜひ、勉強します！」

「CSSが一番難しいですよね」

「同じことを実現する方法が結構いくつもあって、でもやり方によって結果がかなり違ってくるとか」

「僕CSS書いたら1万行くらいいってしまったことがあって…。さすがにディレクターの人に『俺でも3分の1にはできるぞ、書き方おかしい！っていうか、全部に対してCSS書いてるじゃん』って言われたことがあるんです。その辺のベストプラクティスもあるんでしょうか」

「今はセレクターの値の設定やファイルの指定とか、いろいろな方法が考えられてます」

「CSSについても書いてありますか？」

「そこまで深くはないかもしれないですけど、それなりにCSSについての議論は書いてあります。楽しい本ですよ」

「ありがとうございます！個人的にはすっきりしてきました。なんかもやもやしてたことに明確に答えが返ってきて、なんだか気持ちいいです」

「そうですよね。他の人ととりとめない話をすることがすごく勉強になるみたいなこと、結構あると思うんですよ」

「いろんなカンファレンスありますが、純粋に技術の話できるというのは面白かったなあと思います」

UIを考える時に一番気をつけるべきことは何ですか？

「そろそろまとめというか『オチ』に入っていきたいので、最後に質問をさせていただきます。UIを考える時に一番気をつけないといけないことって何でしょうか」

「ユーザーのことを考えるというのが一番重要だと思います。これでユーザーが実際に使えるのか、どんなユーザーがいてどんな環境でどう使うのかを意識することが大事なことなんじゃないでしょうか」

「僕もユーザーですね。いろんなユーザーがいるということを、いかに自分の中で学ぶかということだと思います。一番いいのは、いろんなサービス使ってみたりして、自分がいろんなユーザーになれることですね。例えば、日本だと回線は速いけど海外だと遅いとか、性能の低いデバイスしか売ってないとか。こんな良い端末でこんないい回線使っている人は世界中にはそんなにいないですよと。そういったことを想像して、自分がユーザーとして変化できることも必要だと思っています」

「そのとおりですね！今日はとても勉強になりました。本当にありがとうございました！」

「ありがとうございました！」

そこで今回はPC/スマホ向けにクリエイティブ業務を行っているデザイナーや、サイト・アプリ・イベントなどのプロジェクトでVRを使ってみたいと考えているディレクター向けに、マインドスケープアーキテクト・ひらやまともよ氏が「TECH PLAY CONFERENCE 2017」で語った、気軽に使えるVRの表現方法を紹介したい。

▲マインドスケープアーキテクト クリエイティブディレクター/デザイナー　ひらやま ともよ氏
グラフィックデザイナーとしてキャリアをスタートし、トヨタメディアサービス、DeNA、トランスコスモスなどの企業でデジタルコンテンツ企画、デザイン・ディレクションなど、前職のInstaVRではエバンジェリストと活躍。様々なOSでのアプリ開発、IoT、AR、VRを活用したビジネス構築、企画提案やUI設計を行っている。また、Techコミュニティのイベント運営にも参画し、VRクリエーターを増やすべく関連イベント運営やセッション登壇、講師活動も行う。

簡単にVR画像編集ができる全天周イメージ投影法

インターネットは文字の表示から始まり、写真・画像や動画、ついにVR(仮想現実)という360度の表現ができるようになった。ひらやま氏はこの表現のキャンバスが平面から360度になったことを、クリエイターとして使わないのはもったいないと考えた。

それは直視するだけの動画と比べ、まるでその場にいるかのような没入感のあるVRなら、よりコンテンツの世界観を実感してもらえるからだ。VRを使ったクリエイティブというと高機能なマシンや専門知識、コストが必要だと思われがちだが、Photoshopなどを活用したデザイナーならではのさまざまな“見せ方”があるという。

VR空間のしくみは大きく分けて、全天周イメージ投影(プリレンダリング)と、3DCG(リアルタイムレンダリング)の二つがある。3次元のイメージを常に高速でレンダリングしている3DCGは、主にゲーム制作などで使われることが多い。いろいろな表現ができるが、CGやゲームエンジンなどの専門知識やハイスペックなデバイスも必要となる。

一方、全天周イメージ投影はすでにプリレンダリングされたCGや撮影済みの画像や映像を使って仮想空間を作るので、基本的な画像や映像編集の知識・経験があれば3DCGに比べて学習コストは低い。あらかじめレンダリングされているので、リアルタイムで演算を行う必要がない分、メモリの消費が抑えられてWeb上での表示も速いというメリットもある。そこで、今回は全天周イメージ投影に絞って紹介していく。

全天周投影法では、エクイレクタングラー方式を使う。世界地図の投影法でも使われているもので、この投影方式を理解すれば簡単にVRコンテンツを作ることが可能だ。エクイレクタングラーの特性として画像中心の横線（地平線）に接する付近は正しく描画されるが、地平線から離れるにつれて、画像が歪んでしまう。

実際にTHETAで撮影された以下の画像を見てみよう。中心部分は綺麗に描画されるが、上下は歪んでいる。その歪みも柄だと目立つが、無地はわかりにくい。

例えば、地平線から離れた空や海・地面などは作りやすくなる。形のハッキリしているものを配置する場合、歪みにくい中央部に置く必要があるが、VR空間で見るとオブジェクトは思ったより大きく表示される。

上の方に配置すると頭が疲れやすく、下の方はうつむく動作を人はあまりしないので気づかれないことが多い。従って効果的に配置するためにも、小さめに画像中心を基本とした水平に配置することが望ましい。

以下のようなエクイレクタングラーの特性を理解すると、デザイン表現の幅が広がる。

• 画像の中心の横線は地平線となる
• メインのオブジェクトは画面中心に作成する
• ファーストビューで画面に切り取られるエリアを意識する
• 画像の上部と下部にオブジェクトを配置しない
• 配置オブジェクトは思ったより小さくて良い

エクイレクタングラーの特性を活かした全天周画像編集

画像の編集はPhotoshopで行うが、エクイレクタングラー形式の全天周画像・映像の360度視聴の検証を行うためのツールを活用する。PCであればGoPro VR PLAYER、スマートフォンであればジャイロでSingle/Dual表示も見れるTHETAアプリが便利だ。

実際に作ってみた画像がこちらだ。球体に壁画が立体的にレイアウトされているが、これは画像編集のみで作成しており、一切CGは使っていないという。

これらはPhotoshopで画像を作ることができる。まず、画像の中心に横線を引く。この中心がファーストビューになるので、最初に表示された時に目の前に見せたいものを作っていく。

右端と左端が円筒になるので、シークエンスするように写真をコピーなどして画像を合成していく。

上下は画像が歪んでしまうため、グラデーションで無地にする。

メインのオブジェクトを中心線の位置に置く。360度画像でも人間の目に最初に映る範囲は限られているので、ファーストビューを意識したほうが良く、画像や文字は小さくても問題ないとのこと。

ちなみに、画像内の地平線の位置をを上げたり下げたりすると、中心の自視点に対して周りの風景が上下し、見え方が変わる。地平線を下げると自分が高いところにいるようになり、上げると自分が落とし穴のような穴の中に落ちたようにも見える。

実際にVRを制作する場合は、酔いを起こさせないようにすることが大事。そのためには広範囲にコンテンツを置くのを避け、頭の動きが最低限になるようにレイアウトしたい。

特に上下の頭の振りは左右に振る場合より負荷がかかり酔いやすい。エリアをめいっぱい使わないで360度の意味はあるの？と考えがちだが、全体の世界観や没入感、空気感を表現することに360度見渡せるVRは有効なツールで意味はある。

その空間の中でユーザーが快適にコンテンツを楽しむためには見せたいオブジェクトのレイアウトする位置に留意する必要があると考える。実際、多くの人はコンテンツ内の真後ろを見ることはあまりせず、ファーストビューから離れるほど滞在時間は少なくなっている。

しかし、見る人がいることを考えて重要なものではないが、何か遊び心をあるものを置いておくと宝物を見つけたような気持ちになり、面白いかもしれない。それもVRならではの楽しみ方である。

特に画面の上下にオブジェクトをレイアウトすることを避けたいその他の理由として、全天周の球体へマッピングした時に歪んでしまうので避ける必要がある。

ただし、どうしても上下に置きたいものがある際は、Photoshopで歪みを気にせず全天周画像が作成できる「Flexify 2」というプラグインがあるので活用しよう。

▲「Flexify 2」キュービック方式からエクイレクタングラー方式に変換して出力し、上下を見せることができる。

VRの画面表示には全画面で見せるSingle Viewとヘッドマウントディスプレイ（以下、HMD）用のDual Viewがある。VRのコンテンツを作る際は、両方選べるように留意して作ったほうが良い。それぞれの特徴は以下の通りだ。

VRコンテンツの展開方法

SNSでのVRコンテンツの展開方法として代表的、かつお手軽なのは、YouTubeとFacebookだ。どちらもアップロードするだけで世界中のユーザーに簡単にリーチできる。YouTubeは動画のみのアップロードとなるが、ジャイロやSingle View/Dual Viewの表示も可能。Facebookは360度画像・動画ともにアップロード可能だが、ジャイロとSingle Viewでの視聴となる。インタラクションはつけられない。

WebはGoogleの無料フレームワーク「Google VR View」、mozillaが提供する無料フレームワーク「A-Frame」があり、どちらも数行のHTMLを書くだけでVRページができる。HTMLにあまり詳しくない人でもソースコードをコピペして埋め込むだけで簡単にVRコンテンツが作れる。回転させる動作やゲーム性を加えることも可能だ。

ソースコード例（A-Frame）

ソースコード例（Google VR View）

VRのオーサリングツールは無料から使える日本製のInstaVR、Krpanaが提供するPanotourがある。インターフェイスから操作でき、コードを見なくていいので直感的に作ることができる。

ゲームエンジンで代表的なのはUnity、Unreal Engine。無料のアセットやサンプルコードもあるので、ノンプログラマでも挑戦しやすい。

VRコンテンツの基本をまとめると、以下のようになる。

• 傾きのあるコンテンツは酔うのでNG
• 顔の縦運動より横運動をさせる
• 360度いっぱいにものを置かない
• ファーストビューを決める
• 配置オブジェクトは思ったより小さくて良い
• 全天周投影法では解像度を可能な限り上げることで没入感が増す

これらは、「酔わない、疲れない、極力頭を動かさない」ことにつながる。

Adobe Stockのような画像素材サイトで「エクイレクタングラー」と探すと素材が出てくるので、これらを上手く活用しながらVRコンテンツにチャレンジしてみよう。

「行取り」あるいは「バーティカルリズム」とは、要素の配置に一定のリズムを取り入れることで、デザイン上の安定感や、可読性の向上などの効果が見込るデザイン手法です。通常は、本文の行の高さをリズムの単位として、要素間の余白を調整します。ノートの罫線や、原稿用紙をイメージするとわかりやすいと思います。

上の例のように、CSSでline-heightやmarginを適切に設定すれば実現可能ですが、メンテナンスが煩雑になる、レスポンシブにするのが難しい、見出しが複数行になるとうまくいかない、などの課題が残ります。

現在W3Cでは、この問題を改善するために、line-height-stepという新しいプロパティを議論しています。まだ異論や技術的課題が残っていますが、Chrome、Edge、Safariは賛同しており、Chromeでは試験運用機能として実装もされています。この記事では、このプロパティを使って、バーティカルリズムを実装する方法について解説します。

二つのスタイル：強いリズムと弱いリズム

まずは、どこにどのように適用するかを考えます。「バーティカルリズム」にもメリットとデメリットがあります。メリットとデメリットを理解して、適切に適用する方法を考えてみましょう。

一つ目のメリットは、行や要素が一定の間隔を持つことで、デザイン上の安定感が生まれることです。規則的に並んでいるデザインは、洗練、安定、安心、といった印象を与えます。

二つ目のメリットは、脳が一定のリズムをパターン認識することで、可読性を上げることです。目線が次の行頭に移動する時は、可読性が一番妨げられる時でもあります。脳が次の行頭位置を予測することで、目線の移動を助け、より早く、より楽に読めることで、内容の理解力も高まるとされています。

残念ながら、デメリットもあります。一つ目は、スペースを消費することです。余白を広げて調整するため、適用しない場合と比べて、より広いスペースが必要になります。モバイルでは画面の大きさが限られているため、本文の行の高さの半分をリズムの単位にするなどの工夫もあるようです。

デメリットの二つ目は、余白が一定でなくなることです。これはちょっとわかりにくいので、例を挙げて説明します。

画像や表、引用文、コード、コラムなど、大き目のブロックが入った場合を考えてみます。「バーティカルリズム」を適用するなら、これらのブロックの高さを本文行の高さの整数倍に揃えることになります。雑誌などデザイン重視の印刷物では、通常は画像や表の大きさを調整して揃えますが、Webでは画像のサイズを変えたくないため、余白で調整することになります。この結果、画像が複数ある時に、画像と本文の間の余白が一定にならない、という副作用が生まれます。

二つの画像の間に、一行の本文がある場合がわかりやすいかと思います。

一定のリズムを作るデザインを心がけているのに、この余白が一定で無いのは残念です。また、大きなブロックをまたいだ場合、上に挙げたメリットは小さくなってしまいます。脳が画像をまたいでパターン認識するのは困難ですし、目線が画像の次の行頭を見つけるのは簡単です。

この点から、大きな画像や表に対しては、画像をリサイズできない場合には「バーティカルリズム」を適用せず、余白を一定にする手法が一般的に使われる、と「日本語組版処理の要件」および、JIS X 4051「日本語文書の行組版方法」では定めています。

W3Cでの議論を見ると、この点が、英語圏由来の「バーティカルリズム」と、日本語本来の「行取り」では大きく違うようで、英語圏由来の「バーティカルリズム」は、余白の調整は断念し、常に適用する場合が多いようです。対して「日本語組版処理の要件」では、行取りの処理例は、見出しの説明の中でのみ出てきます。日本語は、文字の高さが一定のため、画像と本文の余白を、英語の場合よりも気にするのかもしれません。

本記事では、適用する場合と、空白を揃える場合の両方のパターンを使って、本文と見出しにのみ適用してみます。

CSSコーディング

提案中の line-height-step プロパティを設定すると、行の高さが設定値の倍数になるように切り上げられます。これを使って、CSSを書いてみましょう。便宜上、見出しは <h2> と <h3>、本文は <p>、画像やコラムは <div> タグを使っているとします。

line-height-step プロパティはまだChromeの試験運用機能でしか使えないので、まずは @supports で囲みます。ブラウザで表示を確認する場合には、Chromeのアドレスバーに「chrome://flags」と入力し、表示された画面で「Experimental Web Platform features」を有効にしてください。

article {
  font-size: 16px;
}

@supports (line-height-step: 1px) {
  article {
    --grid: 24px;
    line-height-step: var(--grid);
  }
}

日本語の行間は、フォントサイズの1.5倍から1.8倍くらいが読みやすいとされていますので、ここでは font-size を1.5倍にした 24px を基本のリズムとします。この値は他でも使うので、CSS Custom Properties で定義して、line-height-step プロパティを設定します。

基本のリズムを設定したら、本文の設定をします。

article > p {
    line-height: 1.2;
    margin: 0;
  }
  article > p + p {
    margin: var(--grid) 0 0 0;
  }

line-height-step を使う時には、margin をリズムの整数倍に揃える必要があります。個人的には日本語の段落間の空きはない方が好みなのですが、Webでは空ける場合も多いため、ここでは段落間を一行空きに設定しています。後で出てきますが、margin collapsingが使えない場合があるため、隣接セレクターを使っています。

また、line-height-step が行間を一定に揃えてくれるため、誤って余分な空白が入らないように line-height を小さめに設定しています。通常は問題ありませんが、複数のフォントが使われた時などには、CSSの仕組み上、行間が広がってしまう場合があるためです。

次に、画像や表は適用外とします。margin は見た目を確認しながら適当に設定してください。

article > div, article > table {
    line-height-step: 0;
    margin: .2em 1em;
  }

最後に、見出しを「行取り」で揃えてみましょう。

article > h2, article > h3 {
    display: inline-block;
    width: 100%;
    line-height-step: 0;
    line-height: 1.2;
    margin: var(--grid) 0 0 0;
  }

ちょっとおまじないが出てきました。実は、line-height-step は行の高さを揃えるだけで、ブロックを揃えることができません。ブロックを揃えるための仕様も議論には上がっているのですが、行の議論でもう二年近く経っているので、ブロックの議論や実装は残念ながらまだ先です。このため、現段階でブロックを揃えるには、ブロックを inline-block にして行の中に収め、その行を揃える、という手法を取ります。width は、この inline-block を含む行を幅いっぱいにするためです。

これで <h2> や <h3> の高さは常に 24px の倍数になるように上下に余白が入ります。

モバイルなどの狭い画面では、見出しが複数行になる機会もあるので、このブロックの中では line-height-step をオフにし、小さめの line-height を設定します。見出しは、短めで、フォントも大きいので、通常は行間を詰めた方が見やすくなります。

最後に、見出しの上部の空きを、下部の空きより大きくするため、margin-top のみを一行分に設定します。これも好みですが、実際の空きは、「行取り」の調整のためにこれよりも大きくなるため、確認しつつ適切な値を探してみてください。上下の margin の合計値は 24px の倍数になるようにする必要があります。また、inline-block にしたため、隣接したブロックとの間でmargin collapsingが働きません。<p> で隣接セレクターを使ったのはこのためです。

これで完成です。試験運用機能を有効にしたChromeで確認できるはずです。サンプルはこちらにあります。確認が終わったら、試験運用機能は無効に戻しておいてください。

最後に

多くの方が、試されて最初に感じるのは「あんまり変わらないね」ということではないかと思います。ほぼすべての日本語ワープロにこの機能が入っていますが、気がついている人は多くはないのではないでしょうか。「行取り」「バーティカルリズム」のみならず、多くのタイポグラフィの改善は、一つ一つは非常に小さな変化ですが、積み重ねることで確実に読みやすくなります。ぜひ、お試しください。

Flashに造詣の深い池田泰延さん、沖良矢さん、轟啓介さんをゲストにお迎えし、Flashという技術の歴史、またFlashの役割を受け継ぐ新たな技術とは何なのか、とことん語り合っていただきました。

※「懐かしさ」には個人差があるので、「Flashはまだ懐かしむ段階じゃない」というツッコミもあるかもしれません。そこはどうかご笑覧ください！

今回のゲスト紹介

白石：今回ファシリテーターを務める、HTML5 Experts.jp編集長の白石俊平です。まずは皆さんのFlashとの関わりについて、自己紹介をお願いします。

池田：僕はFlash歴15年で、Flashに関する本も10冊書いています。沖さんと一緒に雑誌「Web Designing」の連載をしたり、Flashのオープンコミュニティでも活動していました。今日はなぜFlash Playerがこんなに追い込まれてしまったのか、その不満についてもぶちまけつつ、Flashが果たしてきた役割について語りたいです。

▲株式会社 ICS代表池田 泰延さん
フロントエンドのテクノロジーを紹介するサイト「ICS MEDIA」の編集長。個人実験サイト「ClockMaker Labs」やセミナー・書籍執筆などの活動を通して積極的にインタラクションデザインの情報共有に取り組んでいる。筑波大学 非常勤講師も務める。Flashに関する著書は10冊。「Papervison3D入門」「ActionScript3.0ライブラリ入門」「ProgressionによるFlashコンテンツ開発ガイドブック」「Stage3Dプログラミング」など。

沖：Flashはバージョン4.0から始めて、いまだに使っています。過去には、Adobe公式FlashユーザーグループF-siteの代表も務めていて、思い入れもいろいろあるんですが、ユーザーとして使っていた時間が長かったので、今日はユーザー視点で語りたいと思っています。

▲世路庵 インタラクションデザイナー　沖 良矢さん
1981年愛媛県生まれ。フリーランスとしてWebを中心としたテクニカルディレクション、フロントエンド開発、スマートフォンアプリ制作など様々なプロジェクトに参加する。雑誌『Web Designing』では、2009～2015年の6年間、FlashのTIPS連載を担当した。クリエイティブコミュニティDIST主宰、Adobe公式FlashユーザーグループF-site代表。

轟：僕も最初に触ったのは4.0からですね。ActionScriptが出たあたりで、アドビに入社したので、ユーザー年数としては短いかもしれません。今日は会場に猛者がたくさんいるのでインタラクティブに語っていきたいです。

▲アドビ システムズ 株式会社　Creative Cloud マーケティングマネージャー　轟 啓介さん
1999年、早稲田大学理工学部を卒業後、大手印刷会社に勤務。主にEC分野で J2EE開発に携わるが、Adobe Flexとの衝撃的な出会いを機にリッチクライアントの世界へ。2008年4月、アドビ システムズ入社。アドビのWebツール全般のマーケティングを担当。オブジェクト指向が好きで、クラス設計やプログラミングをしている時はシアワセを感じるが、現在はプライベートプロジェクト用にやっている。デザインも好きで、デザインが適当な全てのものを憎んでいる。

白石：僕はFlashは軽く触ったことがあるくらいなので、皆さんの話を聞きながら、学ぶという立場で聞いていきたいと思います。

なぜFlashは流行ったか

白石：まずは、なぜFlashは流行ったのかについてお話を聞かせてください。

池田：Flashが盛り上がり始めたのは2000年前後ですね。

沖：個人的な認識ですが、Flashの盛り上がりには3回ピークがあったと思います。第一次ブームはまだモデムでアクセスしていた98～99年くらい。中村勇吾さんの「yugop.com」を代表とする軽量でダイナミックなアニメ―ションが話題になりました。Flash 4や5の時代ですね。

第二次ブームはFlash Player 6でビデオが再生できるようになった頃。Windows Media PlayerやReal Playerなどの重いプラグインを使わなくても再生できる便利さから、ビデオ再生プラットフォームとしていろんなデバイスに普及するきっかけになりました。

白石：その後、YouTubeやニコニコ動画が出てきたんでしたっけ。

沖：そうですね。当時はマシンパワーも非力だったし、軽量なFlash VideoがWebサイトにおける動画コンテンツの救世主になったかんじです。

轟：あと２ちゃんなどの独特の文化とFlashのシュールなコンテンツがすごくマッチしてた。そんな文化的な背景もFlashが盛り上がった理由の一つなんじゃないかと。

池田：この「まだ生きてる歴史的Flashページまとめ」は僕がまとめたものなんですが、togetterで昔のFlashページを懐かしむというものです。主に２ちゃんのFlash板に投稿されたものがまとまっています。吉野家ゴノレゴなんかはすごく人気がありましたね。

沖：第三次ブームはいわゆるフルFlashサイト。ビデオの表現力のあとにフィルターが入ったり、ActionScript 3.0で高度なスクリプティングができるようになって、Flashだけでリッチかつ情報量を備えたサイトを作れるようになった。表現力が広がったことで、広告関連や企業のコーポレートサイトなどもフルFlashサイトで作られるようになっていきました。

白石：その頃は僕でさえ、コーポレートサイトをFlashで作ってましたからねえ。

池田：当時はインタラクティブなものはだいたいFlashで作ってましたよね。今から考えると、SEO対策やアクセシビリティ的には最悪でした(笑)。

クリエイティブとFlash

白石：では、具体的にどんなクリエイティブがFlashの盛り上がりに影響を与えていったのか、お聞かせください。

池田：やっぱり広告なのかなと。特に、企業のスペシャルサイトでよく使われていました。例えば、モリサワの「FONTPARK 2.0（MORISAWA）」。ユーザーもフォントのパーツを自由に動かして、投稿できるというものです。

沖：Flashはこうしたユーザー・ジェネレイテッド・コンテンツという文化を流行らせた一因にもなっていますよね。

池田：こうしたコンテンツを見ているとわかるんですが、文字の細かいシズル感や効果音などの表現が凝縮されてるんですよね。クリエイターとして単純に憧れてました。

沖：THE ECO ZOO（ECODA!DOBUTSUEN）は3Dで作られていて、当時としてはかなり画期的なサイトでした。普通こうした3Dコンテンツを作るにはPapervision3Dなどを使うことが多いんですが、作者の城戸雅行（ROXIK）さんがすごいのは、フレームワークや仕組みの部分から全部自分で作ってしまうこと。おそらく、他のフレームワークで同じようなコンテンツを作ろうとしても、重くて動かせないと思います。

池田：当時はリアルタイムで3Dをたくさん動かすには性能的に難しかったので、プレレンダリングでボケた葉が舞う画像を先に作っておいて、そのぼかしたキャッシュを表示させるなど、相当研究されてましたね。

轟：Flashのコミュニティでは、そういった企業秘密になりそうな技術的なこともオープンに公開していたから、みんなで面白いものを作ろうぜという雰囲気になっていったんですよね。

沖：同じソフトを使っている人が集まって定期的に勉強会を開くのは、Flashのコミュニティが初めてだったんじゃないでしょうか。

池田：オープンソースの考え方が入ってきて、Flashのコミュニティが盛んになってきたのは、日本で言うとSpark projectが大きかったですね。当時高校生だった新藤愛大さんが、未踏ユースで採択されたことをきっかけに、著名クリエイターたちも参加するようになり、それまでバラバラに出ていたライブラリやフレームワークなどを集約して共有するようになった。ProgressionやFLARToolKitなんかも、このSpark projectで公開されました。

沖：まだGitHubがなかった時代に、今と同じことをやってたというのはすごいですよね。

池田：FLARToolKitは海外からの反響も大きかったですね。

白石：テレビのアニメや映画広告でもFlashが使われていたんですよね。

沖：そうですね。テレビや映画でもアニメーションツールとして使われるようになって、最近では湯浅政明監督の「夜は短し歩けよ乙女」、過去には「鷹の爪団」や「おしりかじり虫」なんかもそうですね。テレビのCG合成やPlayStationのゲームのUIなんかにも使われていました。

轟：ガラケーはFlash Liteを使ってましたね。

池田：Flashは極限まで軽量に作れるので、いろいろ工夫すれば30Kくらいまでファイルサイズを小さくできたんですよ。

沖：Flash Liteのノウハウは独特で職人技でしたよね。

池田：今では考えられないですけど、SWFファイルをサーバー側で書き換えるとか、マニアックなこともやってました。

白石：皆さんはFlashでどんなものを作っていたんですか？

沖：もう10年近く前になりますが、「地球と気象」という、気象に関する教育コンテンツの制作を担当しました。Flashはアニメーションでさまざまな事象を簡単に表現できるので、教育系の仕事には重宝していました。

池田：僕は、個人で作った作品やデモを「Clockmaker Labs」に載せています。流体表現や物理計算などを研究しながら作ってました。

沖：この時代は、小さい作品をたくさん作って自分のサイトで公開するという文化がありましたよね。今だとCodePenやQiitaで書くという人が多いんですけど。当時は素材を描くところから演出してプログラミングするところまで、全部一人で作れてしまうので、作家性が発揮しやすかったように思います。こうしたコンテンツが再生できなくなっていくのはさみしいですね。

Flashの拡がり、そして現在に至るまで

白石：続いては、ActionScript 3.0、コミュニティ、Flex、Adobe AIR、そしてiPhoneによって、Flashがどう拡がり、現在に至ってしまったのかを語っていただきたいと思います。

轟：僕はまさにAdobe Flashの頃から、ユーザーとして付き合い始めました。それまでJavaでサーバーサイドの開発をしてたんですが、業務アプリケーションとして使いたかったんですがちょっと不安定だったんです。ActionScript 3やオブジェクト指向が使えるようになって、開発環境もEclipseが使えるようになって、すごく面白くなってきた。Flexのコミュニティもかなり盛り上がってましたね。

ブラウザの互換性もあり、チーム開発もできそうということで、企業の業務系アプリケーションとしても導入のしやすさがあった。僕はその頃、サーバーサイドからフロントエンドに移ったんですが、とにかく楽しかったのを覚えています。

池田：Flash Playerのブラウザ互換性はとにかく高かったですね。MacでもWindowsでも同じように動いていた。Playerのバージョン検知も古いバージョンだと促してくれてましたね。

轟：アップデートすると、数カ月でユーザーの80％くらいはアップデートしてました。

池田：Flex Frameworkというのは、MXMLという言語で画面を生成するライブラリで、今で言うとReact.jsやAngular.jsに近い。保守性が高いため業務系アプリケーション、Rich Internet Application（RIA）なんかでよく使われていました。

轟：さっきの話にも出ていた昔のシズル感というか、ふわっとしたかんじの表現が業務アプリケーションにも入ってきた瞬間でした。ようやく業務系アプリにも作業を効率化させて、気持ちよく使おうという流れになってきた。

白石：ECMAScipt4が政治的な何かで消えたという話も聞きましたが。

池田：ActionScriptはECMASciptから派生してできたもの。ActionScript 3が出て、次はECMAScipt 4が出るというところで、いろいろあってストップしたんですよね。で、まったく別の枝からECMAScipt 5が出たんです。

白石：じゃあ、iPhoneやジョブズに関する想いはどうですか？

池田：iPhoneが最初に販売されたときはまだ性能が低かったので、Flash Playerが載らないのは仕方ないと思ってました。でも、iPadにFlash Playerが搭載されなかったのは大きかったですね。Adobe Flashのエバンジェリスト、Lee Brimelowは「Go screw yourself Apple」というブログを書いて批判していました。

轟：彼は腕にひらがなで「ふらっしゅ」ってタトゥーを入れるくらいFlashを愛していたんですよ。

池田：FlashのアプリをiPhoneアプリとして生成するサードパーティ製のツールも出たのですが、数カ月でそれもApple側が審査を通さなくなってしまった。AIRでActionScriptを変換して出せるパッケージャーも出たんですが、「Thoughts on Flash」という有名なタートルおじさんのセリフとともにすべて消えてしまいました。

轟：当時、FlashがなかなかiPhoneに載らないので、Adobe MAXという大きなイベントでAdobeのCTOがどうしたらiPhoneにFlashが載るかというのをブラックジョークなパロディ寸劇でやったんですよ。あれも刺激したんじゃないかなあ。

白石：FlashはそんなにAppleのビジネスを阻害したんでしょうか？

沖：Flash Playerはウェブブラウザ上で動いていたので、App Storeを経由しなくてもアプリを提供できてしまいます。当時、App Storeの仕組みを普及させようとしていたAppleとしては、良く思わなかったはずです。

白石：「ジョブズからの手紙」をエンガジェットさんが要約してくれていますね。

沖：バッテリーなんかは、Flashと同じものをHTML5 Canvasで作って載せたらよけい重くて動かなくなると思いますけどね。

白石：ということで、Androidでは動いていたけど徐々に動かなくなり、デスクトップのアプリケーションとなり、モバイルの隆盛とともに衰退していったということでしょうか。

池田：作る人がいなくなっていったというのも大きいですね。モバイルが中心になってきたにも関わらず、モバイルでは動かすことができず、新たな技術も生まれず、新規の作品を作る人がどんどんいなくなってしまった。

白石：Flexなんかはわりと早めの段階でApacheに寄贈していましたね。2011年の頃ですね。

池田：Adobeの決断は早かったですね。

轟：Flexに惚れて入社したので、辞めようかと思うくらいショックでした。

沖：業務アプリケーションにユーザービリティとかエンターテインメント性という概念が生まれたのは、Flash以降ですよね。

轟：Flashのコンソーシアムも立ち上がってました。企業の中にノウハウがないから、コンシューマ向けのコンテンツを作っている人たちから吸収しようといろんな化学反応が起きてましたね。

沖：Flashの勉強会は、全然違う分野の人たちが話せたのがすごくよかったですね。

今後のwebを占う

白石：池田さん、Flashの現状と今後はどうなっていくでしょう？

池田：2020年でFlash Playerのサポートは終了するんですが、Adobe AIRでiPhoneやAndroidアプリのデプロイが可能なので、Flashテクノロジーとしては継続していくと思います。サードパーティ製アプリ禁止が緩和されて、Adobe AIRは個人で開発するのには最適なプラットフォームなのですが、新たにFlashを学ぼうという人はほぼいないので、Flashがこれから盛り返していくことは、現実的に難しいんじゃないでしょうか。

白石：Flashで培われたシズル感を表現するツールのようなものが減っているような気がします。HTML5やモバイル、 WebGLといった技術の中で、今後のwebはどうなっていくでしょう。

沖：現時点のWebで何かを表現するには、HTML,CSS,JavaScriptが基本になるので、そこはしっかり抑えておきたいですね。表現力という意味ではWebGLに注目が集まっていますが、Flashのように誰でもすぐ使える技術かというと疑問は残ります。どうしても高度なプログラミングがベースとなるので、学習し始めてから成果が出るまでの時間がかかりすぎる面はあります。

池田：UnityからWebGLに書き出す機能もあるし、Unityの学習曲線もそろってきているので、コンテンツが増えないのかというのはトータルで見ていく必要があると思っています。WebGLでFlashコンテンツと同じようなものを作るとすごい容量になるので、WebGLでユーザーにストレスなく遊んでもらうにはキャッシュをうまく使うためにService Workerを覚えたほうがいいとか、周辺技術もいくつかおさえておかないといけない。ハードもスマートフォンやパソコンもあるからトータルにおさえなくてはいけない技術がたくさんある。学ぶものの多さが普及の妨げになっているんじゃないでしょうか。

轟：Adobe Edgeでいろんなアニメーションの方向性を細分化して模索してみたんですが、DOMアニメーションがきついので、結局CSSアニメーションとCanvasしか残さなかった。昔はFlash Playerのことだけ考えていればよかったのに、ブラウザやハードもたくさん増えたので、今のクリエイターは本当に大変だと思います。アドビも作り手がワクワクしながら簡単にできるツールを提供できるように頑張りますので、期待してください！

白石：では最後にひと言ずついただけますか。

池田：Flashがなぜ衰退したのかは、Flashの好き嫌いはともかく、理解しておいたほうがいいと思っています。政治的な理由やプロパガンダによって自分が使っていた技術が突然なくなってしまうこともあり得ます。Flashを教訓として、例えばHTMLが使えなくなったとしても今まで覚えた技術やノウハウを次の異なる技術でも活かしていきたいです。

沖：Flashは衰退してWeb標準のほうに傾いているけど、最近のブラウザでもFlash Player 6とか7くらいの表現はできるようになってきました。HTMLやJavaScriptだけを見るよりも、Flash時代のライブラリを振り返って学んでおくと幅が広がるし、過去の資産が生きることは結構ある。Webコンテンツやアプリ、モバイルゲームを作る人もFlash時代の本やコンテンツなんかで学んでほしいと思います。

轟：アドビの中の人として、Flashのマーケットをどうしようか悩んだんですね。でも、Flashツールじゃなくて手段であると考えた。その先のお客さんが楽しく、仕事がしやすくなるように、Flashの育てた文化やコミュニティをひっくるめて、マーケットに貢献したほうがいいなと。Flashのコミュニティのおかげで生まれたものもあるし、面白い仕事を作っている人は今も活躍している。若い人たちにもこういう面白い世界があったんだと伝えていきたいですね。

イベントの様子は「Creative Cloud 道場」もしくはYouTubeで公開されているので、興味がある方はぜひこちらからご覧ください！

こんにちは、編集長の白石です。

この記事は、9月24日に開催されたHTML5 Conference 2017に登壇したエキスパートに、お話されたセッションのトピックを中心に語っていただこうとういものです。セッションの内容をより深く理解する手助けになるだけでなく、本記事単体でも面白く読んでいただけることを目指しています。

今回お話を伺ったのは、freeeの伊原力也さんと、ビジネス・アーキテクツの太田良典さんです。

お二人のセッション「多様なユーザーニーズに応えるフロントエンドデザインパターン〜書籍「インクルーシブ HTML + CSS & JavaScript」より」に関するスライド資料は、こちらで公開されています。

「インクルーシブ」に込められた意味とは？

白石: 今回は取材をお受けいただきありがとうございました！簡単に自己紹介をお願いします。

太田: ビジネス・アーキテクツに所属している太田です。大規模企業サイトの構築、ガイドライン策定などを行ってきました。

Webアクセシビリティ関連に昔から取り組んでいまして、「Webアクセシビリティ基盤委員会」の翻訳作業部会主査を担当しています。

▲株式会社ビジネス・アーキテクツ 太田良典さん　　※写真提供：html5j [HTML5 Conference 2017事務局

伊原: freee株式会社の伊原です。Webサイトやアプリケーションの情報設計を行っています。私もWebアクセシビリティ基盤委員会に所属しており、「理解と普及作業部会」にて活動しています。

他には、HCD-Netという人間中心設計を推進する団体でも活動しており、UXデザインの普及に務めています。

▲freee株式会社 伊原力也さん　※写真提供：html5j [HTML5 Conference 2017事務局

白石: 本日は、HTML5 Conferenceでお話された内容を主にお聞きしたいのですが、このセッションは、今度出版される書籍を元にしてらっしゃるんですよね。

伊原: はい、11月4日に出版される「インクルーシブ HTML + CSS & JavaScript」という書籍の内容をベースにしています。

私たちは2年ほど前にデザイニングWebアクセシビリティという書籍を、その半年ほど前にはコーディングWebアクセシビリティという書籍を上梓しました。

今回のセッションの元になった書籍は、いわばそうした流れを組んだ最新のものだといっていいと思います。特にコーディングWebアクセシビリティとは、著者も同じヘイドン・ピカリング氏ですし、続編といって差し支えないかと思います。

白石: では、今回もWebアクセシビリティに関する書籍なんですね。

太田: そうです。「コーディングWebアクセシビリティ」では特に、WAI-ARIAの使い方について詳しく論じられていました。WAI-ARIAの基本的な知識はあっても、「なぜそう書くのか」「いつどう使うのか」を知らない方に向けて、具体的な例を挙げつつ語った本です。

白石: では、今回の書籍は「インクルーシブ HTML + CSS & JavaScript」となっているわけですが、これはどういう内容の本なのでしょうか？

伊原: 原著のタイトルは「Inclusive Design Patterns」と言うのですが、サブタイトルは「Coding Accessibility Into Web Design」（Webデザインの中にアクセシビリティをコーディングする）となっていて、こちらの方がわかりやすい(笑)。

ぶっちゃけて言えば、アクセシビリティに配慮したコーディング例を具体的に挙げていっているという本です。

原著者がなんで「インクルーシブ」という単語を用いたかというと、「アクセシビリティ」というと、「アクセシビリティガイドラインを満たしていくこと」とか、「特定の障害を持つ人に向けた配慮」というニュアンスが強く根付いてしまっているからだと言っています。

また、「アクセシビリティ」という言葉自体には、デザインや設計という意味は含まれていない。アクセシビリティとは単に「アクセスできる可能性の度合い」のことですから。

一方でインクルーシブというのは「包括的」とか「全てを包む」といったニュアンスを含む英単語で、「できるだけ受け入れる」とか「できるだけ含める」という意味合いがあります。原著者が「インクルーシブ」という単語を用いたのは、「できるだけ多くの人に使ってもらえる」「できるだけ多くの状況で使える」ものをデザインしていこう、という意図なんです。

太田: ただ、日本語版では元のタイトルにある「デザインパターン」という言葉は使いませんでした。Web制作の世界では、「デザインパターン」と言う単語からはWebデザインを想起してしまいがちなので…。

アクセシビリティにおいては、そういう（UI）デザインのニュアンスだけが強いわけではありませんからね。

白石: 「デザインパターン」という単語は、エンジニアの方であれば逆に馴染みはあるかもしれませんね。

しかし、「コーディングWebアクセシビリティ」や「デザイニングWebアクセシビリティ」という書籍がありながら、今回新しい書籍を出版されたのはどういう背景があるのでしょうか？

太田: ここ10年くらいで、JavaScriptを用いた動的なUIがすごく普及しました。Ajaxがその立役者で、JavaScriptを利用して非同期にUIを書き換えるような作り方が一般的になってきました。

おかげで、WebサイトのUXは全般的に向上しましたが、一方で、アクセシビリティ的には新たな課題を抱えることにもなったわけです。元々、HTMLはアクセシブルに設計されているのに、JSがそれを損なってしまうケースが散見されるようになったのです。

例えばフォーム送信などは良い例です。昔ながらのフォームで、「送信」ボタンを押したら次のページ…という流れであれば、アクセシビリティに問題はあまりありません。ただこれを、JavaScriptを用いてAjaxでデータ送信するようにした途端、アクセシビリティが低下してしまうことが多い。

伊原: そもそも、JSで「アプリ」を作ろうとすると、アクセシビリティへの配慮がされにくくなりがちです。ほとんどdivやspanでマークアップして、見た目上動けばOK…という場合が少なくありません。

それを、セマンティックなHTML要素とWAI-ARIAを活用して、アクセシブルでUXにも優れたWebアプリを作ろうというのが、この「インクルーシブ HTML + CSS & JavaScript」で述べていることです。

実践！アクセシブルな商品リストを作ってみる

白石: では、アクセシブルなマークアップの具体的なパターンを幾つかお話いただきたいと思います。

ただ、セッションの内容全体についてはスライド資料をご覧になってもらえればいいと思うので、ここでは、私が個人的に疑問に思ったことなどを遠慮なくツッコませていただきつつ、ポイントとなる部分をおさらいしていっていただけると嬉しいです。

伊原: わかりました。では一つ目の例として、商品リストを見ていきます。

このサイトは画像アセットを購入できるサービスという想定ですが、UIデザインについては、Amazonの検索結果のようなものを想像して頂ければいいと思います。

リストの項目それぞれは商品名やレビュー結果、そして「すぐに購入」ボタンなどがあります。

これが複数縦に並んでいるリストをイメージしてください。

白石: こういう一覧の実装方法っていろいろですよね。個人的には、単にdivを並べるときもあれば、表っぽければtableを使うときもあります。

伊原: まず、リストそのものはリスト要素（ulやol）を使ってマークアップした方がいいかなと思います。

ここでリスト要素をお薦めするのは、要素の意味合いがわかりやすいのと、スクリーンリーダーがリストを読み上げるのに特別な機能を持つからですね。

太田: 例えばスクリーンリーダーは、リストの項目数を先に読み上げたり、前後のリスト項目にジャンプしたりできるんです。項目数って結構大事で、項目数が多い場合と少ない場合では、ユーザーの行動も変わってきますからね。

白石: なるほど。

伊原: また商品名ですが、見出し要素を使用するのが最適です。スクリーンリーダーは見出しに直接飛んだり、直前の見出しを読みあげたりすることもできる。 リストと見出しを組み合わせることで、一覧の見出しを飛ばし読みしていくようなことが可能になるんです。

まとめると、以下のようなマークアップがおすすめですね。

<li>
  <h3>
  ガソリンスタンドにたたずむ裸の男 <a href="/artist/kenny-mulbarton">by <cite>ケニー・マルバートン</cite></a>
  </h3>
</li>

白石: liの中に見出し要素を置くと、リスト項目が全て個別のセクションということになりますが、それは問題ないんでしょうか。HTML5からは、見出し要素は暗黙的にセクションを構成するようになりましたよね。

太田: はい、確かにセクショニングアルゴリズムの観点から、liの中にh3を入れることを望ましくないと考える人もいるかもしれません。ここは意見が分かれるところでしょうね。 ただ、アクセシビリティの観点からは支援技術で実際に使えるかどうかが重要で、その意味では十分に実用的だと言えると思います。

「今すぐ購入」ボタンはボタンにする？それともリンクにする？

伊原: 次は、「今すぐ購入」ボタンをどうマークアップするかを検討してみましょうか。

白石: うーん、これはbutton一択じゃないですか？

伊原: それもアリです。buttonを使うケースとしては、JavaScriptと組み合わせて、購入処理をその場で行えるようにするような場合ですね。

でもこの例のサイトは一般的なプリント写真購入サイトをイメージしているものなので、「今すぐ購入」ボタンを押したら、写真の購入確認画面に飛ぶことになります。

白石: そうなると、写真の購入確認画面へのリンクとして実装したほうが良さそうですね。

伊原: はい、そのほうがJavaScriptがなくても動きますし、要素の意味合いも明確になります。ここではa要素を使いましょう。

以下のようなマークアップがまずは望ましいですね。

<a href="/product/naked-man-in-garage" class="button">今すぐ購入</a>

白石: このマークアップだと、class="button"となっていますし、CSSで見た目をボタンっぽくするイメージですね。例えばWAI-ARIAを使って、このリンクのロールをボタンにするというのはいかがでしょうか？

<!-- role要素でbuttonを指定 -->
<a href="/product/naked-man-in-garage" role="button">今すぐ購入</a>

伊原: あ、それはやめてください。これでは、元のHTML要素が持つセマンティクスが変わってしまい、この要素はリンクではなくボタンであるという意味合いになってしまいます。

白石: なるほど、ここでは見た目だけボタンにしておいて、セマンティクスは変えないのが望ましいと。

太田: そうなんです。WAI-ARIAって覚えると濫用されがちな技術でもありますが、基本的には「WAI-ARIAは使わない」のが正しい。

W3Cの「Using WAI-ARIA」という文書の先頭に書いてあるのは、「（HTMLでまかなえる場合は）WAI-ARIAは使うな」なんですよ(笑)。

例えばボタンや見出しがあったとしたら、素直に<button>や<h1>を使えば良い。WAI-ARIAを使う必要は必ずしもないんです。基本的にはHTML5の語彙を用いて、足りないところをWAI-ARIAで補う、という形が望ましい。

リンクテキストにも配慮しよう！

伊原: あともう一つ考えてみたいのは、リンクテキストです。このままだと全てのリンクが「今すぐ購入」になってしまいますが、それってアクセシビリティに優れていると言えるでしょうか？

白石: うーん…見出しに商品名はあるので、全くアクセシブルじゃないとは思いませんが。リンクテキストも読み上げられるんですよね？全部が「今すぐ購入」じゃ不親切かも？

伊原: そうです。「何を購入できるか」が、リンクテキストから分かると、よりアクセシブルですよね。

なので、非表示のテキストでリンクテキストをより詳細化すれば、UIデザインも損なわれません。

<a href="/product/naked-man-in-garage" class="call-to-action">
  <span class="visually-hidden">ガソリンスタンドにたたずむ裸の男を</span>今すぐ購入
</a>

白石: なるほど、不可視のテキストも利用してより説明的にするとは…！アクセシビリティへの配慮を真面目に考えてないと、まず出てこない発想ですね。

伊原:ちなみに他にもやり方はいくつかありますが、この本ではSEOにおける内部対策的な意味合いも込めて、このやり方が推奨されています。

検索結果ページ（SERP）にも配慮する

伊原: 最後に、検索エンジンの結果ページで商品（Search Engine Result Pages）がどう見えるか、についても配慮した方がいいでしょう。

白石: 検索結果ページですか？なんでですか？

伊原: 支援技術ユーザーの中には、目的のページに辿り着くために、検索エンジンのインターフェースを利用する人も多くいるんです。Google検索って、site:を前につけるとサイト内検索を行えるじゃないですか。

白石: ああなるほど。言われてみれば、ぼくもAmazonの中検索するのに、Google検索をよく使います(笑)。

伊原: 例えばマイクロデータとschema.orgを使えば、検索結果の表示をより充実させることが可能です。以下に、商品のレビュー結果を表すマークアップの例を示します。

<span itemprop="aggregateRating" itemscope itemtype="http://schema.org/AggregateRating">
<span itemprop="ratingValue">4</span>つ星、
レビュー数<span itemprop="reviewCount">13</span>
</span>

白石: そうか、今までぼく、「マイクロデータ使っとけば検索結果ページで目立てるかな」くらいしか考えたことなかったんですが、アクセシビリティの点から考えても重要なんですね。あんまりちゃんと意識したことなかったです。

見た目ではなく機能でマークアップせよ！

伊原: では次の例に移らせてください。表示結果を絞り込んだり並び順を変えたりするUIを実装してみたいと思います。

白石: うーん、こういうの実装するんだったら、ぼくだったらどうするかなあ。ナビゲーションメニューみたいなものと捉えて、リストとa要素とかでやるかもしれません。

伊原: それも悪くないのですが、このメニューって、どれかが選択中の場合は他のメニューを選択できませんよね。それってどうします？

白石: …JavaScriptのお世話にならざるを得ないかもしれません。

伊原: そう、でも、標準のHTMLには、そういう「排他的」な選択を行うためのフォーム要素があります。

白石: …ラジオボタン、ですか？

伊原: そのとおりです！

このデザインだけからだと、見た目はラジオボタンとは似ても似つきませんが、ここではラジオボタンを使うことにします。マークアップの段階では、見た目ではなく機能に沿ってマークアップするのが重要ですから。

ラジオボタンのスタイリング…やりにくい！どうする？

白石: でも、ラジオボタンは「◎」みたいな余計なUIがくっついてきちゃいますよね？しかもあれがブラウザごとに異なる上、どのブラウザのデザインもあんまりカッコよくない(笑)。

伊原: そうなんです。ラジオボタンってスタイリングしにくいので評判が良くないですよね(笑)。だから、結局他の要素を使っちゃう…なんてことも起きちゃうんですが、そこは工夫次第です。

ここではlabel要素をうまく使って、目標とするデザインを実現しましょう。label要素は、それ自身をクリックすることで、対象となるラジオボタンやチェックボックスの状態を変更できますよね。

白石: ああ、なるほど！labelはクリッカブルな状態で表示しておいて、ラジオボタン本体は隠しちゃえばいいんだ。

伊原: そうです。labelさえあればラジオボタンのクリックは可能ですので、実際のラジオボタンは隠しちゃってもいいんですよね。ラジオボタンのフォーカス状態やチェック状態はCSSの擬似クラスで指定できますので、CSSだけで表示の切り替えが可能です。

例えばこんな感じになります。

<input type="radio" name="sort-method" id="most-recent" checked />
<label for="most-recent">新着順</label>

<input type="radio" name="sort-method" id="most-popular" checked />
<label for="most-popular">人気順</label>
...(略)...

[type="radio"] + label {
  cursor: pointer;
  /* その他、基本のスタイル */
}
[type="radio"]:focus + label {
  /* フォーカス時のスタイル */
}
[type="radio"]:checked + label {
  /* 選択時のスタイル */
}
/* ラジオボタンを見えなくする */
.sorter [type="radio"] {
  position: absolute !important;
  width: 1px !important;
  height: 1px !important;
  padding:0 !important;
  border:0 !important;
  overflow: hidden !important;
  clip: rect(1px, 1px, 1px, 1px);
}

白石: なるほど、これならHTMLのセマンティクスもわかりやすいし、JavaScriptもいらない。素晴らしい。

伊原: ちなみに、このCSSの!important連打は「とにかく扱いづらいラジオボタンを消し去ってやりたい」という原著者のジョークなので、真似しないでください(笑)。

無限スクロールはやっぱり×？「もっと読む」はどう実装するか

伊原: 最後に、検索結果が複数ページに渡る場合、どういう風なUXが望ましいかを考えてみたいと思います。昔よく使われていたのはページングですが、今は無限スクロールを採用するサイトも多いですね。

白石: はい、ぼくも自社で運営しているTechFeedというアプリで無限スクロールを採用しています。

伊原: ただ、アクセシビリティ的には無限スクロールは使わないほうが無難です。

白石: えっ！いろんなサイトが採用しているし、使いやすいとも思うんですが…

伊原: 理由はいくつかあります。

まず、スクロールという操作が読み込みを誘発することが、ユーザーにとって望ましいことなのかどうか。ユーザーは次のページ読み込みを望んでいないかもしれないですよね。

あと、スクロールバーを使っているユーザーは、新たなページが読み込まれた瞬間スクロールバーが勝手に上下するので、混乱します。

最後に、ページのフッターにたどり着けないことがあります。フッターに要素を置いているにもかかわらず、無限スクロールがあるものだから、フッターに触りたくとも触れない…という事態が起こりうるのです。

白石: ふむ、理由はわかります。では、代わりにどうデザインすべきだと思いますか？

伊原: ページ読み込みをユーザーが制御できればいいので、「もっと読む」ボタンを明示的に設置するというのは一つの解決策ですね。

白石: でも、いちいちそのボタンを押さなくちゃならないというのも結構面倒な気がします…。あと、サービス事業者側としては、無限スクロールでどんどん下に読んでいってもらうことで、ユーザーの滞留時間を伸ばしたいという気持ちもあると思うんですよね。

伊原: この本では、ユーザーが「もっと読む」ボタンをよくクリックするようなら、その時に改めて「続きを自動的に読み込むか」を尋ねるようにするというやり方が紹介されています。その質問に「YES」と答えるのなら、そのユーザーにとっては、先ほど挙げられていた無限スクロールのデメリットが気にならないという証拠でもあると。

白石: なるほど。確かにそのほうがユーザー本位でもありますね。

太田: あとこういう動的にリストを追加する場合、アクセシビリティの観点から一点注意点があります。

読み込みが完了したら、新しく読み込んだデータの先頭にフォーカスを移すことです。そうしないと、スクリーンリーダーのユーザーが、次にどこに行けばいいかわからなくなってしまいますから。

そのために、新たに読み込んだデータの先頭にtabindex="-1"を指定しつつ、JavaScriptでフォーカスを与えます。

...
<li>
  <!-- tabindexを指定して、タイトルをフォーカス可能にする -->
  <h3 tabindex="-1">
    ガソリンスタンドにたたずむ裸の男<a href="/artist/kenny-mulbarton">by <cite>ケニー・マルバートン</cite></a>
  </h3>
  ...
</li>
<li><!-- 新たに表示された商品の2番目 --></li>
...

白石: おお、こういう配慮は全く考えていませんでした。勉強になります。ちなみに、tabindexにマイナス値を指定することなんてできるんですね…知りませんでした。

太田: tabindexにマイナスを指定すると、ユーザーはそこにフォーカスを当てられないのですが、スクリプトでなら当てられるようになります。

「アクセシビリティは0点か100点っていう話じゃない」

白石: 本日は、いろんな例についてマークアップを考えられて面白かったです。

ただ最後に質問があります。

最近のWebアプリはどんどん動的になっていて、「UIのほとんどをJavaScriptで構築する」という場合も少なくありません。Single Page Applicationなんかはその最たるものだと思います。

こうしたサイトでも、アクセシビリティを担保することは可能なんでしょうか？相当の工数をかけないと難しいんじゃないかという気がしているのですが。

伊原: 確かに、SPAのアクセシビリティは面白いテーマです。ただ、SPAだからアクセシビリティの担保が難しいということはないと思います。

というのも、Google DocsやGoogle SlidesはWAI-ARIAにかなり対応していて、コンテンツの読み上げに対応しているんですよ。

白石: え、そうなんですか！それらのアプリ、SPAの代表格みたいなもんだと思ってました…。「SPAはスクリーンリーダーになじまないんじゃないか」なんて思ってましたが、それは単なる思い込みですね。

伊原: どんなサイトでもまずは一回、スクリーンリーダーで読み上げを行ってみることをお勧めします。SPAであっても、意外なほどスクリーンリーダーが綺麗に読み上げてくれることもありますので。

太田: 私はいつも言っているのですが、アクセシビリティって0点か100点かだけではないんです。全くアクセスできないサイトもなければ、全世界のすべての人がパーフェクトにアクセスできるサイトもありません。全てのサイトがその中間のどこかに位置していて、少しでもよくしていこうという考え方が大事だと思います。

伊原: 「アクセシブルかどうか」はちょっとした改善で大きく変わったりもするものです。

例えば先日、とあるサイトをスクリーンリーダーで読み上げてみたのですが、ほとんど問題なく使える。ただ一点、そのページで一番重要なラベルだけ読み上げてもらえないんです。こういう点を改善するだけで、アクセシビリティはぐっと向上する。

なので、まずはアクセシビリティ上の問題を特定し、問題の重要度を判断して、重要なところから対応していく…という現実的なアプローチが、アクセシビリティを向上させていく上では大事だと思っています。

白石: 本日は、いろんなお話を聞かせていただき、ありがとうございました。

こんにちは、編集長の白石です。

この記事は、9月24日に開催されたHTML5 Conference 2017に登壇したエキスパートに、お話されたセッションのトピックを中心に語っていただこうとういものです。セッションの内容をより深く理解する手助けになるだけでなく、本記事単体でも面白く読んでいただけることを目指しています。

今回お話を伺ったのは、東京理科大学4年の石井翔さんです。

石井さんのセッション「WebGLの今とこれから ~今のWeb開発で使うからこそ知っておきたい周辺技術~」に関するスライド資料は、こちらで公開されています。

スライド資料 （注: 重いのとモバイルから見えないのはご容赦ください by 石井翔さん）

WebGLの現状

白石: 本日は取材をお受けいただいてありがとうございます！簡単に自己紹介をお願いします。

石井: 東京理科大学4年生の石井 翔です。昨年、私が進めているGrimoire.js（注: モバイルからだと多少レイアウトが崩れます by 石井翔さん）というプロジェクトが未踏IT人材発掘・育成事業に採択され、スーパークリエータに認定されました。

白石: Grimoire.jsはWebGLのライブラリですね。Grimoire.jsについてもあとでお聞かせ願いたいのですが、まずはWebGLの概要や現状についてお話いただけますか？

石井: WebGLは、一言で言えばWeb上で3Dコンテンツを扱うための技術です。2010年に仕様が策定されており、既に多くのブラウザで実装されている技術です。ブラウザ上でどの技術が使えるかを測定するCan I Useでの結果を見ても、92%以上のブラウザがサポートしていて、広く使える状態にあると言っていいでしょう。

ただこれは、WebGL 1.0の話です。WebGL 2.0はまだまだですね。ChromeとFirefoxだけが対応しているという状態で、特にiOSで使えないのが厳しいです。「ブラウザを限定すれば使える」という状態です。

白石: WebGL 1.0と2.0って何が違うんですか？…ぼく、3Dプログラミングが全然わかってないので、理解できるか自信がないのですが(笑)

石井: 浮動小数点テクスチャなどがWebGL 2.0の主な機能ですが、3Dプログラミングの知識がない人に向けて話すのはちょっと難しいですね(笑) とりあえず、ライブラリ作者なら知っておくべきですが、ライブラリのユーザーはそれほど気にする必要はないかと思います。 ライブラリ作者も、WebGL 2.0が使えない環境では1.0にフォールバックするように実装していることが多いでしょうし。

（筆者注: WebGL 2.0の強化点についてはQiitaで良い記事を見つけました。ぼくにはちんぷんかんぷんですが…）

白石: なるほど、あまり気にしなくていいと(笑) 安心しました。

石井: 3Dをご存じない方にとって大事なのは、そもそもWebGLとはGPUを扱うための技術だということをしっかり理解しておくことです。

CPUは、CPUは複雑な処理を逐次的に処理することを得意としています。CPUの場合はコアの数が4とか8とかに限られていることが普通です。

一方GPUの場合は、「異なるデータに対して同じ処理を施す」のを並列で実行するのに特化しています。なのでGPUは、コアの数が1,000を超えることも普通です。 こうした特徴を持つGPUだからこそ、大量の頂点を移動する処理など、3Dプログラミングに必要とされる「単純な処理の並列実行」に向いているんです。

白石: こうした特徴は、最近だと機械学習の分野とかにも活かされているんですよね。単純なベクトル計算とかが多いから。

石井: そうです。で、WebGLってそもそもOpenGL（※）と同じなので、CGの取り扱いに関しては共通している部分がほとんどです。ただ、置かれている環境は、OpenGLネイティブのゲームやアプリとは随分違う。

一番違う点は、WebGLは必要とされるリソースが全部Web上にあって、ダウンロードが必要という点です。モデルデータの読み込みに時間がかかるんですよね。

だから今まではゲームなど、「読み込みに時間がかかりそうだ」とユーザーも了解しているコンテンツが多かったんです。でも、本来使うデータをしっかり選べば短いロード時間で使えるものも多いんですよ。シェーダーアートとか。

※OpenGL（オープンジーエル、Open Graphics Library）は、クロノス・グループ (英: Khronos Group) が策定している、グラフィックスハードウェア向けの2次元/3次元コンピュータグラフィックスAPIである（Wikipediaより引用）

白石: 確かに、WebGLでできたゲームとか、読み込みに数分待たされるものもありましたね。

石井: はい。モデルデータが大きいと、それだけダウンロードやデータ読み込みに時間がかかってしまう。なので、そうしたWebGLの問題を解決すべく、CGの世界にも進化が起きようとしているんです。

ランタイム向け3Dデータフォーマット「glTF」

白石: 具体的にはどのような進化ですか？

石井: 一つはglTF (GL Transmission Format) と言って、汎用的な3Dアセットフォーマットです。ツールに依存しない軽量フォーマットとして、Khronosが普及を進めています。

glTF

白石: ツールに依存しない、というのはどういう意味ですか？

石井: 以前WebGL上でモデルファイルを扱う際には、MayaやBlenderといったツールのファイルをそのまま読み込んで利用することが一般的でした。これは言わば、「Photoshopのpsdファイルはあるけど、jpgやpngなどの汎用的な画像フォーマットがない」という状況です。

白石: そんな状況だったんですね…知りませんでした。ゲームやアプリとしてひとまとめにパッケージングしてしまうから、汎用フォーマットが必要とされなかったんでしょうか。

石井: 概ねそういうところです。そういう状況を変えようと、COLLADAという汎用フォーマットがKhronosによって提案され、一定程度普及はしています。

ただ、COLLADAファイルはCG編集ツール間でデータをやり取りするためのフォーマットとして設計されているため、WebGLアプリケーションが読み込んで利用するには、編集用のパラメーターなど不要な部分も多いんです。また、XML形式だというのも、ファイルサイズや解析速度の点で不利になります。

glTFは、COLLADAファイルから編集用のパラメータを取り除いて、JSON形式にしたものと言ってほぼ差し支えありません。

白石: なるほど。ただ、そういうフォーマットって、普及させるのがなかなか大変な気もしますが、どうなんでしょう？

石井: glTFは既に様々なライブラリにもサポートされていますし、普及は中々順調と言えると思います（参考: glTFのライブラリサポート状況）。

glTFの面白いところは、大手ベンダーの採用意欲が高いというところです。MicrosoftやAutodeskという大手ベンダーが乗っかってきているんですよ。 Khronos自身WebGLの仕様策定元なので、この分野で発言力が強いこともあります。また、最近ではApple WatchのページでglTFが使われてたりもします。

白石: Apple Watchの公式サイトでもですか！それはかなりの人がアクセスしたでしょうね。確かに、これ単なる画像じゃない。スクロールと共に水滴が別々の動きをしてる…！（重いけど）

Apple Watch Series 3のサイト

石井: glTFは「オーディオにおけるMP3, ビデオにおけるH.264、画像におけるJPEG」といったように、「3DといえばglTF」となることを目指しているとのことで、普及にかけるKhronosの意気込みも並々ならぬものがあります。

頂点データ専用の圧縮形式「draco」

石井: もう一つ注目の技術としては、Googleがオープンソースで開発しているdracoという圧縮形式です。頂点データを効率よく圧縮する技術で、元々の頂点データのサイズに比べて4倍から16倍の圧縮率を誇ります。

白石: 先ほどのglTFにしか使えないんですか？

石井: いえ、汎用的なポリゴンデータ形式（.ply）に対応しているので、元のファイルフォーマットは選びません。

白石: ブラウザによる対応も必要なんですか？

石井: いえ、ブラウザがネイティブ対応するというものでもないんです。dracoによって圧縮されたポリゴンデータは、JavaScriptでデコードすることができます。

白石: なるほど、アプリケーションが自前で圧縮データを展開するんですね。でもそれだと、デコード処理にかかる時間がちょっと心配です。

石井: WebAssemblyでできたデコーダーもあるし、Web Workersで展開すればUI処理を阻害することもないので、そこはあまり問題ないと思いますよ。使うブラウザを選ぶということもありませんし、Three.jsのようなライブラリに任せてしまえば、アプリケーションはデコードについて意識する必要もありません。

白石: ほかには、Webだと画像のサイズを結構気にしたりしますが、CGの世界ではどうなんでしょう？

石井: CGだと、テクスチャ画像のサイズを削減するという話になりますね。ただ、単に画像のファイルサイズを小さくするだけでは片手落ちなんです。 いくら元画像のファイルサイズを小さくしても、GPUに乗るときにはフルサイズにデコードされてしまうので、メモリ使用量などにすごく影響するんですね。

なので、GPUが直接扱えるテクスチャ圧縮形式というものがありまして、それらを利用すると、GPU上でも圧縮した状態で画像を扱うことができます。DirectXだとS3TCという形式、iOSだとPowerVR Texture Compression (PVRTC) というように、ベンダーごとに異なってくるんですが。

白石: ベンダーごとに異なるんだと、取り扱いが面倒ですね。

石井: はい、なのでこういうフォーマット変換はWebpackなどで自動化されるべきだと思います。このように、今まではエンジンが自動的に行なってきたことも、WebGLの場合はプログラマーが自分で意識しなくてはなりません。

白石: まとめると、3DをWeb上で行うためにはいろいろな課題があって、それが徐々に解決されつつあるということですね。汎用モデルフォーマットが普及しつつあり、頂点データの圧縮ツールも登場した。そして、テクスチャ圧縮も自動化されるだろうと。

石井: そうです。そもそもWebは、多様なデバイスがネットワークで繋がれていることが前提です。そういうユビキタスな環境で、3Dが自由に表現できる世界に向けて、今まさに具体的で重要な進化が起こっているということです。

WebGLの未来

白石: こうした動きを踏まえて、WebGLの未来はどうなると思いますか？

石井: 今のコンピューターの世界は、やはり2Dを前提としているのは間違いありません。3Dが利用されるシーンは、ゲームなど、コンピューティングのごく一部に限られていました。マテリアルデザインなども、3Dの要素をうまく取り入れてはいますが、前提は2Dです。

ただ、今、GoogleやApple、Microsoftなどの強力なベンダーたちが、こぞってARやMRに力を入れています。このまま進めば、映画館や不動産屋さんとか、あらゆるお店の軒先にARのオブジェクトが浮いている…という世界は普通に来るんじゃないかと思っているんです。3Dがより身近になる世界です。

ただ、そういうのを見るために、わざわざアプリをインストールするのは面倒ですよね。近い将来、そういう面倒くささが、AR/MRの普及を妨げる大きな一因になってくるんじゃないかと思うんです。

しかしWebGLがそういう状況を打開できるんじゃないか、と期待しています。WebGLはWebブラウザさえあれば動きます。PCでもスマホでも動く。アプリのインストールが必要ないし、しかも安全なサンドボックス上で動きます。

白石: 確かに！もしかすると、ビーコン技術との組み合わせとか（※）で、アプリのインストールを必要とせず、気軽にバンバンARコンテンツを見るような時代が来るかもしれませんね。

※Webとビーコン技術との組み合わせとして、Eddystoneという仕組みがGoogleから考案されている

石井: 実際、GoogleがWebARという仕様を作ったりもしていますし、ARには各社力を入れているので、Webでも早晩ARが使えるようになるだろうと思います。

白石: でも実際、要素技術が揃っているだけでは世の中変わらない…という現実もあるかと思います。WebGLも、実際には随分前から使えるようになっていたわけですし。こういう「要素技術が揃っているだけでは越えられない壁」は、どうやったら超えられると思いますか？

石井: 難しい問題ですが、一つは3Dコンテンツの制作コストが高いというのも、普及を妨げる要因にはなるのかなと思います。ただそれは、「人が作る」ことを前提とするからコストが高くつくんだと思うんですよね。

そういう点では、2Dに関しては既にPaintsChainer（AI技術を使い、線画を自動で着色するサービス）やMakeGirlsMoe（AIで自動的に萌えキャラを作成するサービス）のようなサービスが出てきています。同様に、自動で3Dコンテンツを生成するようなサービスも近いうちに登場して、コンテンツの制作コストが劇的に下がるんじゃないでしょうか。

白石: AIサービスでコンテンツの制作コストが激減するというのは面白い発想ですね〜

石井: Adobe Senseiも最近話題になっていますし、デザインの一部をAIに任せるというトレンドが来つつあるのは確実かなと思いますね。

Grimoire.jsは、WebGLをWebエンジニアにとっての「筆」にする

白石: では最後に、開発を進めていらっしゃるGrimoire.jsについても、簡単にご紹介頂けますでしょうか？Three.jsなどのライブラリとは何が違うんでしょう？

石井: Grimoire.jsはWeb開発の中でWebGLを扱うためのフレームワークです。Three.jsやBabylon.jsは、発想がCG中心なんですよね。画面全体をCGで構築するようなコンテンツにはいいのですが、Webコンテンツと混在させて、相互がやり取りするようなプログラムを作るには適していないんです。CGとWebには大きな隔たりがある。それに決められた構造を両者に与えて橋をかける必要があった。

この隔たりは、プログラミングスタイルにも大きく表れてきます。

CGの場合は、フレームごとにグラフィックを変更させていく、いわばフレーム指向です。
一方でWebの場合は、イベントに応じて処理を行うのが普通ですよね。いわばイベント指向です。
こうした隔たりがあるせいで、CG側とWeb側が、お互いにどうデータを受け渡しすればいいか、正解がないというのが今の状況です。

Grimoire.jsは、CG側とWeb側の、2つのAPIを提供することで、両者がシームレスに同居するようなアプリケーションを簡単に作ることができるように設計されています。

白石: 具体的にはどのようなコードになるんでしょう？

石井: Grimoire.jsは、GOMLという専用のマークアップ言語でCGを記述することができます。そして、GOMLの要素を変更することで、簡単にCGを変更できるんです。例えば、立方体にテクスチャを貼り付けて、自動的に回転するようなCGは以下のようなマークアップで簡単に実現できます。

<goml>
  <scene>
    <camera></camera>
    <mesh texture="logo.png" geometry="cube">
      <mesh.components>
        <Rotate speed="1,1,1" />
      </mesh.components>
    </mesh>
  </scene>
</goml>

そして例えば、マウスが重なった時だけこの立方体が2倍の大きさになる…という処理は、以下のようなJavaScriptで実現できます。

gr(function() {
  var mesh = gr('#simple .canvas')('mesh')
  mesh.on('mouseenter', function () {
    mesh.setAttribute('scale', '2.0')
  })
  mesh.on('mouseleave', function () {
    mesh.setAttribute('scale', '1.0')
  })
})

白石: おお、簡単ですね！これならWebエンジニアでも簡単に扱えそうです。

石井: はい、そうなんです。イベントを受けてパラメーターを書き換えるという流れは、今のWebアプリケーションフレームワークなどの潮流を見れば古い感じを受けるかもしれませんが、結局のところこれだけあればいくらでもラップすることができます。そのようなモダンなWeb開発の環境でもシームレスに環境を選ばず導入できるんです。Grimoire.jsの目標は「WebGLを、Webエンジニアにとっての『筆』にする」ことなんです。

一方で、CG側にはUnityに近いようなインターフェースのAPIが提供されています。TypeScriptで記述できるビルド環境が提供されているので、Webに疎いCGサイドでもすぐにWebエンジニアの使う筆を作ることができます。再利用可能で、最終的なパラメーター調整などをWeb側が簡単に行えるわけです。実際、そのためにChrome拡張でWebGLの空間をそのまま操作できるインスペクタも提供しています。

Grimoire.js Inspector

WebエンジニアにとってCGをより身近にすること、そしてCGがより一般的な世界にすることを目指しています。

白石: とても期待しています！本日はWebGLの基本的な事柄からGrimoire.jsまで、いろいろ教えていただいてありがとうございました。

石井: 1.0リリースを年内に行いたいと思っています。興味がある方がいたら公式サイトから開発チームのSlackなどに入ると新しい様々な情報が拾えるかと思います。またいくつかの例も載っているのでご覧いただけると幸いです。

こんにちは、編集長の白石です。

この記事は、9月24日に開催されるHTML5 Conference 2017に登壇するエキスパートに、予定しているセッションのトピックを中心に、いろいろ伺ったものです。セッションの内容をより深く理解する手助けになるだけでなく、本記事単体でも面白く読んでいただけることを目指しています。

今回お話を伺ったのは、ソフトバンク・テクノロジーの関口浩之さんです。

関口さんのセッションは「Webフォント最新事情2017～導入事例も一挙紹介～」（ルームE 11:20-12:00）です。（現在HTML5 Conferenceは定員オーバーの状態ですが、無料イベントということもあってキャンセルも多めに出るらしいので、あきらめずにキャンセル待ちすることをお勧めします！）

「フォントおじさん」誕生まで

白石: こんにちは。関口さんとは、いつかゆっくりお話してみたいと思っていたので、インタビューできて大変嬉しいです。

関口: こちらこそ。

白石: 関口さんは、FONTPLUSというサービスに携わられているんですよね。ソフトバンクでYahoo! JAPANの立ち上げなどに関わっていた関口さんが、そもそもどういう経緯でフォントの世界に入られたのですか？

関口: FONTPLUS以前は、仕事上でフォントにそれほど深く関わってきたわけじゃないんです。ただ、子供の時からアナログレコードのジャケットとかが大好きで。これとか、中学生のときにはじめて買ったEPレコードなんですが、ロゴが素敵だったので、トレーシングペーパーでロゴをトレースしたりしてました。カッコよくないですか？

白石: ほんとだ、カッコいい！手書きのレタリングがなんとも言えない味を出していますね。

関口: 他にも、ホーロー看板って知ってますか？

白石: え、知らないです。なんですかそれ？

関口: 昔よく見かけた看板で、大好きなんです。見てくださいこれ。レトロという意味でのカッコよさ以上に、デザインとしてカッコいい。

白石: たしかに、言われてみるとすごくカッコいい気がしてきました…。

関口: こういうのが子供の頃から大好きだったので、元々フォントにハマる素養はあったんでしょうね。Webフォントの仕様が登場して盛り上がってきた2010年頃も、知り合いとよくフォントの話をしていたものです。

ただ、日本語のWebフォントはやはり難しいだろうなあ…というのが当時の雰囲気でした。なにせ何万文字もありますからね。フォントファイルのサイズだけでも、数MBになってしまう。

白石: はい、ぼくもWebフォントは文字数の少ない言語圏じゃないと無理だろうな、なんて思っていました。

関口: でも、そこからがうちら（ソフトバンクグループ）っぽいところです。「日本語Webフォント、やるか！」って話の流れになって、そのまま勢いでやることになったんです。飲み屋で。

白石: 飲み屋で(笑)。

関口: やるとなったらうちらは早いし、とことんです。「フォントメーカーを横断したWebフォントサービスを作りたい」という構想を練り、日本のフォントメーカーの皆さんにご協力をお願いしまくって、なんとかでき上がったのがFONTPLUSです。

今ではFONTPLUSは、1,000書体近くを扱えるWebフォントサービスになりました。

白石: 1,000書体近く、ってすごいですね…！

ちなみにぼくはエンジニアなので知らないのですが、デザイナーさんって、それだけの数のフォントをだいたい覚えているものなんでしょうか？

関口: DTPデザイナーさんやグラフィックデザイナーさんはかなり記憶してらっしゃると思います。でないと仕事になりませんから。Webデザイナーさんは、まだそのレベルまで仕事で必要とされてる段階には至ってない方も少なくないと思います。ただ、Webでよく見かけるフォントに関しては、かなり詳しくご存知ですよね。

白石: すごいなー！ぼくもスライドとか作る時、できればフォントにこだわりたいと思うのですが、元となる知識が少なすぎて、めちゃくちゃ時間かけた挙句に選べないんですよね。そのうち「こんなに時間かけてられない」って諦めて、一般的なフォントに落ち着いちゃう。

関口: そうですよね。適切なフォントを素早く選ぶ知識やセンスは、今後どんどん重要になっていくスキルだと思っています。人間って、何かを前にした瞬間に、実は0.1秒くらいで好きか嫌いかを決めちゃってるじゃないですか。

その一瞬の判断に、フォントが及ぼしている影響ってすごく大きいと思うんです。例えば、「吾輩は猫である」をいろんなフォントで表示してみると、こんなに印象が違うんですよ。

関口: …とまあ、こんな感じで、今はフォント自体のことをお話することが多くなってきまして。 以前は「Webフォントおじさん」と呼ばれていたのが、最近では「フォントおじさん」と呼ばれるようになってきました(笑)

白石: いやー、ぴったりなあだ名ですね。こうしてお話ししててもフォント愛ビンビン感じますもんね(笑)

Webフォントの導入例

白石: HTML5 Conferenceのセッションでは「Webフォント最前線」というお話をされるとのことですね。

関口: はい、Webフォントを活用されている企業さんの事例や、縦書きCSSの事例、Webフォント界隈の最新事情などをお話しようと思っています。

白石: Webフォントを活用している企業さんの例ということですが、例えばどんなサイトが挙げられますか？

関口: そうですね、例えば鬼怒川金谷ホテルさんのサイトは、全面的にWebフォントを使ってらっしゃいます。 文字を表示するのにほとんど画像を使用していないので、テキストとして選択可能です。

白石: ほんとだ。普段見かけないような書体もあって「画像かな？」と思うようなところも、だいたいテキストですね。

関口: おかげで、拡大しても綺麗に表示されますしね。ここで使われているWebフォントは、上品さと伝統と感じさせる「筑紫明朝」という明朝体です。面白いのが、住所とか電話番号とかが選択可能なことを宿泊客の方に褒められたことがあるそうです。 「住所を選んでコピーできるのがありがたかった」って(笑)。

白石: そんなところ、褒められることってあるんですね(笑)。

関口: ほんとに(笑) 。ほかに挙げられる事例としては、小田原市のHPとかでしょうか。このサイトでは、「ハミング」というフォントを活用しています。明朝体ほど装飾性は高くなく、まじめな印象を与えつつも、少し遊び心と柔らかさのあるフォントになってます。

白石: 確かに。絶妙なかわいらしさですね。

関口: このサイトは、徹底的にWebフォントとアクセシビリティにこだわった結果、サイトのほとんど全てがやはりテキストで構成されています。おかげで、Google翻訳でサイトのほぼ全体を多言語化できているんですよ。

白石: ほんとだ、エスペラント語なんてのもある。エスペラント語に翻訳できてしまった…！

関口: 機械翻訳に頼っているので、完璧ではありませんが、かなりコストを抑えて多言語対応できています。観光の入り口になるサイトとしてはかなりのアドバンテージになりますよね。

それだけじゃなく、自治体のサイトとしてのアクセシビリティも担保できていますし、Webフォントを使用したおかげでサイト自体も美しい、素晴らしい例だと思います。

Webフォントは遅い？ちらつく？

白石: では、「Webフォントおじさん 兼 フォントおじさん」として、Webフォントの技術的な側面について今語るとすると、何がポイントになりますか？

関口: Webフォント自体は、技術としてはそれほど理解が難しいものではないので、ポイントとなる部分は絞られるかと思います。

まず、遅さやちらつき。Webフォントと聞くとやはりこうした印象を抱く人が沢山います。ただ、そこは現在だいぶ改善されつつある。

あとは文字詰めの問題ですね。Webフォントを使う大きな理由は、やはりテキストを美しく見せたいというところでしょう。そうなるとやはり文字詰めにもこだわりたいですよね。

白石: では一つ目の遅さ、ちらつきのお話からお聞きしていいですか？先程の小田原市のサイトを見ても、Webフォントの遅さやちらつきをほとんど感じませんでした。

関口: そうですよね。でも今は、FONTPLUSを初めとした配信側の努力もあって、Webフォントの表示はかなり高速化されているんです。

白石: 具体的にはどういうテクニックで高速化しているんでしょうか？

関口: まずはフォントのサブセット化をサービスとしてサポートしています。

白石: サブセット化というと、限られた文字のフォントのみ使うということですよね。サイトで使用されている文字のぶんだけダウンロードするということですか？

関口: はい。サイトで実際に使用している文字だけをJavaScriptで抽出し、そのグリフだけが入ったサブセットデータをダウンロードするんです。

白石: なるほど！DOMの読み込みが完了してから、JavaScriptでWebフォントの適用範囲内にある文字を抜き出すというわけですね。

関口: そのとおりです。例えば、ぼくのブログページを例にとって説明しますが、Webフォントを適用しているbody要素に2,600文字あったとします。サブセットを取得する際、JavaScriptでユニークグリフ化（文字の名寄せ）を行った結果、このケースでは約400グリフになります。そして、CSSで記述されたfont-familyのサブセットデータを閲覧者のブラウザに適した形式で配信しているわけです。（筆者注: インタビュー中に見せていただいた例だとゴシック体400グリフで60kb以下でした）

白石: なるほど、そうやってデータ量を削減するんですね。

関口: FONTPLUSはサービス開始時の6年前から、サブセット配信は行っていました。この6年間、高速に表示できるよう、サーバー側の構成や処理も相当チューニングを繰り返し、改善してきたのです。

白石: ちらつきを抑えるのはどのように行っているんですか？

関口: FONTPLUSの場合は、Webフォントのダウンロードが完了するまで、JavaScriptでテキストを非表示にすることで対応しています。非表示にする範囲は、Webフォントの適用範囲に限ることも、サイト全体を非表示にすることもできます。

Webフォントがダウンロードされるまで、ブラウザがテキストをレンダリングする方法は、ブラウザによってまちまちなのですが、その差異を吸収しています。

白石: ちらつきを抑えるのにも、JavaScriptを駆使しているわけですね。

関口: と言っても、FONTPLUSをお使いのユーザーは、JavaScriptコードを書く必要はありません。 FONTPLUSのscriptタグで指定するURLに、delayっていうパラメーターを付けるだけです。
（参考）。

<script type=”text/javascript” src=”http://webfont.fontplus.jp/accessor/script/fontplus.js?xxxxx&aa=1&delay=1” charset=”utf-8”></script>

関口: このように、URLパラメーターで高度な処理をON/OFFできるのは、文字詰めの件でも同様の設計を行っています。

文字詰めって…なに？

白石: ポイントの二つ目、文字詰めですね。そもそもフォントの文字詰めって、よくわかっていないのですがどういうことなんでしょう？

関口: 特に、中黒（・）やかぎ括弧や丸括弧等の約物を含む文字列、および、拗音や促音といった小さい文字（ゃゅょっ）等を含む文字列を普通に表示すると、文字と文字の隙間が空いて見えてしまうんです。そうした隙間を詰めて表示するのが文字詰め。カーニングとも呼ばれます。

白石: お恥ずかしながら、全然知りませんでした。

関口: FONTPLUSでは、カーニングを有効にするため独自の対応を行っています。先ほどと同様に、script要素のURLにパラメータでpm=1と付けることで、プロポーショナルメトリクス情報を使って文字詰め配信をすることができます。プロポーショナルメトリクスというのは、文字間の最適な余白幅の情報のことで、フォントデータに組み込まれています（注: プロポーショナルメトリクス情報が入っていないフォントデータもあります）。

白石: なるほど、でも、ページ全体で一括で文字詰めされちゃうと困る場合もあるんじゃないですか？

関口: その通りです。ちょうどそういう、「h1要素は文字詰めしたいけど、body要素は文字詰めしたくない」というようなご要望にお応えする機能も最近リリースしたんですよ。「ピンポイント文字詰め配信」と言って、font-family に{pm}セレクタを付けると、特定の要素のみを文字詰め配信できます。

白石: そんな機能もあるんですね！Webフォントサービスは、フォントの配信が主な機能だと思っていたので、思ったより機能が多くてびっくりです。

関口: そうですね、ブラウザ側で「CSS Font Module Level 3」の実装が進められているのと並行して、ちらつき対策や文字詰め対応などは、独自の対応も行っているという状態です。

他にも、ブラウザやOSごとに異なる細かい挙動を吸収したり、実装時に調整しやすいよう、リセットすることもできます。例えば、WindowsとmacOSのブラウザでは行の高さの解釈が異なるケースがあるのでそれを調整できたり、字の間の余白を削除して、文字間隔を letter-spacing で完全にコントロールできるようにする機能もあります。

こうした豊富な機能を使って頂けるかどうかは、デザイナーやマークアップエンジニアの皆様にお任せするしかありませんが、技術の選択肢がたくさんあることは重要だと思ってます。機能改善や新機能追加は今後も積極的に行っていきたいと考えていますので、ご要望やツッコミは常に大歓迎です。

最後に書体選びについて

白石: そろそろお時間ですね。「Webフォントおじさん」でもあり、「フォントおじさん」でもある関口さんに、最後の質問をお願いしたいのですが。先程も申し上げたように、フォントには個人的にこだわりたいと思いつつ、知識と検討する時間がなくて諦めてしまうんです。

ぼくを含め、そういう悩みを抱えている方々に向けて、何かアドバイスはありますか？

関口: そうですね、まず前提として、1,000種類近くあるフォントを把握するだけでも至難の業です。であれば、まずは人気のフォントをいくつか覚えるところから始めてはいかがでしょうか。 ちょっと今はデータが古い（2016年10月度）のですが、FONTPLUSではフォントの利用状況をランキングで発表してますので、上から20くらい眺めて特徴を把握するだけでもいいと思います。

白石: え、データが古いって…もしかしてこのランキング、関口さんが手で更新してたんですか？

関口: そうですよ(笑) 自動化したいとは思っているんですが、中々手が回らなくて。最近忙しいので、つい更新が滞っちゃいました。

白石: なんというフォント愛…。頭が下がります。でも、フォントという「美しいもの」のために働けるって幸せですよね。今日の関口さんを見ていてそう思いました。本日は、フォントの素人にもわかりやすいお話、どうもありがとうございました！

そんな時代に、Web開発はどう変わるのか？まずはCSS設計というところに着目して聞いてみたいと思い、先日「Web Components時代のCSS設計」という座談会を開催し、エキスパートの方々にお話を伺ってみました。

ゲストのエキスパート紹介

高津戸 壮さん

株式会社ピクセルグリッド フロントエンドエンジニア

Web制作会社、フリーランスを経て、株式会社ピクセルグリッドに入社。スケーラビリティを考慮したHTMLテンプレート設計・実装、JavaScriptを使った込み入ったUIの設計・実装を得意分野とする。著書に『改訂版 Webデザイナーのための jQuery入門』がある。CSS Nite 2011ベストセッションにおいて、全170セッションの中から、ベスト10セッションに、CSS Nite 2013ベストセッションでは、全278セッション中、ベスト20セッションに選出。

小原 司さん

株式会社ピクセルグリッド UIデザイナー

デザイン事務所で広告デザインの基礎を学び、2000年に独立。2007年頃からWebデザインにも取り組み、クロスプラットフォームアプリのデザイン、画面設計、実装に携わる。現在はその媒体の特長を活かしたグラフィックデザインに励む。マンセル色相環とムーン＆スペンサー配色理論を採用した配色アプリ『HUE360』の開発を行っている。著書に『改訂版 Webデザイナーのための jQuery入門』、『ノンデザイナーズ・デザインブック[第4版]』。

榊原 昌彦さん

一般社団法人リレーションデザイン研究所 代表理事

大学院卒業後、一般社団法人リレーションデザイン研究所立ち上げ。その後、まちづくりの産業化を目指す一般社団法人エリア・イノベーション・アライアンスにも参画し、全国の様々なまちづくりの現場に携わる。事業の構造的転換を図り、Webを導入。事業で用いるWebアプリやシステムの開発を行っている。関西フロントエンドユーザーズグループを中心に活動し、CodeIgniter、Ionic2、Onsen UI 2についてもSlackやTwitterを通じて関わる。

CSS設計の遍歴を探る…3年前、どうしてましたか？

白石: 今回の座談会は「Web Components時代のCSS設計」と題し、Web Componentsが一般的に普及した未来の話を主眼として、そこに至るまでの流れも重視したいと思っています。

過去のCSS設計から現在の皆さんのベストプラクティスの話をもとに、未来に向けた話も聞いていきます。 まずは3年前くらいから振り返っていきたいのですが、当時のCSS設計はどんなふうにしていましたか？

榊原: ちょっと調べてみたのですが、3年前というとiOS7がフラットデザインを採用した年なんですよね。

白石: おお！そう聞くとずい分昔な気がしますね。

榊原: そう、そしてCSSまわりの話でいうと、Bootstrapがフラットデザインを採用しました。UIデザインの潮流が大きく変わった年でもあります。

白石: なるほど。そういう状況下で、榊原さんはどのようにデザインを行っていましたか？ UIのビジュアルデザインも、設計という意味でのCSS設計も含めてお聞かせください。

榊原:その頃は、デザイナーがPhotoshopなどで作ったデザインカンプを元に、「ピクセルパーフェクト」で書き起こしていました。 最近は、レスポンシブなWebサイトもわりと当たり前になったおかげで、ピクセルパーフェクトってあまり聞かなくなりましたよね。

白石: なるほど。高津戸さんはいかがですか？

高津戸: 実は私と小原は3年前も今も、やっている案件自体は変わらないので、やり方自体もそれほど変わっていないんです。どういうふうにCSS設計を行っているかというと、デザインを様々な単位に分割してCSSのクラスにまとめ、そうしたパーツを組み合わせたり再利用したりしながらサイトを構築していく。レゴブロックを組み立てるような要領です。

やはり話題に上がります、OOCSS

白石: それは、OOCSS (オブジェクト指向CSS)の考え方と関係しているのでしょうか？

高津戸: そうですね…。OOCSSについて話すと長くなるので、詳細は割愛します(笑)。OOCSSはヤフーのエンジニアだったニコール・サリバンが提唱した手法で、サイトを構成するパーツを、レゴのような小さい単位のモジュールの集まりで考えるというものです。その中で、オブジェクト指向プログラミングの考え方を応用して、似通ったモジュールをクラスの継承のような実装で実現するというものです。

白石: なるほど。以前から誰かに聞きたかったのですが、例えば「テキストを右寄せにする」ための「align-right」というクラス、もっというと「8pxのマージン」をつけるための「margin-8」みたいなクラスを作って組み合わせる、というのもOOCSSと言えるんでしょうか？ 正直、あまり好みではないのですが…。

高津戸: それがOOCSSかどうか、でいえば「そうだ」と言えるとは思います。ただ、OOCSSがCSSを構造的に扱おうという考え方が広く広まっていなかった時は、そういうUIパーツをモジュール化して効率的に設計しようとした点が重要なところでした。

その頃はそれを実現する手段として、複数のクラスを一つの要素に指定し、スタイルを当てるという方法を採用していたんです。なので、そういう複数クラスを利用することがOOCSSなのかと聞かれたら、否定することはできないですけれども、複数クラスの利用＝OOCSSというわけででもないですね。

榊原: Bootstrapは、OOCSSの一つのかたちだとは思います。ただ、BootstrapなどのCSSフレームワークを使いはじめたばかりの頃に思ったのは、フレームワークの流儀に合わせるためにdivを追加していくのはどうなのかな、と。 本来不要なはずのdivじゃないですか。結果、HTMLの見通しが悪くなったりするので、こういう不満を解決するのも（後で論じる）Web Componentsの役割なのかなと思います。

白石: 小原さんは、UIデザイナーの立場でいうと、3年前はどのようなかたちでデザインやワークフローを行っていましたか？ 例えばPhotoshopでカンプを作ったりするのでしょうか？

小原: いえ、ぼくはそもそもPhotoshopは使っているわけではなくて、Illustratorを使ってます。Illustratorはキャンバスを広大に使えるので、状態違いを横に置いたり、引出線でメモを入れたりしていますね。Illustratorでデザインしたあと、そこにエンジニアにお願いすることもいろいろと書き込んだりします。

高津戸: 小原のデザインは「エンジニアフレンドリー」と言いますか(笑)、指示が細かくて適切なんです。パディングの幅とかまで書いてあることもありますし、時にはCSSのコードが書かれたJSFiddleのURLが貼られていることもあります(笑)。

小原: アニメーションなどは、実際に自分で試してみないとデザインできませんから。試してみた結果を参考として伝えるわけですが、そのまま（そのコードを）使ってくれという意味ではありません。同じような結果になる、より良いコードに書き換えてもらう前提ではあります。

デザインのコンポーネント化、そして共通化

白石: 先ほど高津戸さんが言っていた「レゴブロックを組み立てるような」構築の仕方についてお聞きしたいのですが、そういう共通化や部品化、いわば「コンポーネント化」はUIデザインの段階から考えているものなのでしょうか？

小原: いえ、UIデザインの段階では考えていませんね。その段階では全体で見ることが重要だと思っているので、パーツ単体でデザインするわけではありません。

白石: なるほどー。UIデザインの段階で共通化が可能だと判明することも多々あるんじゃないかな、と思ってお聞きしたんですよね。ボタンのパディングだとかもそうでしょうし、色なども。

高津戸: ああ、色はかなり重要ですね。色をSassの変数とかにして、共通化できるんじゃないか…というのは私たちも何度も検討しています。ただ、今はそうしていないですね。

白石: プリプロセッサはSassを使ってらっしゃるんですね？LessやStylusなどもありますが。

高津戸: はい、Sass一色ですね。

榊原: Compassとかも懐かしいですよね。

高津戸: ああ、懐かしいですね。昔、ブラウザごとのベンダープレフィックスを付けていくのにCompassの関数を利用したりしていましたが、今はPostCSSにautoprefixerというプラグインがあって、それが自動的にベンダープレフィックスを付与してくれるので、めっきり使わなくなりました。CompassってRuby Sassを前提にしていましたが、今はぼくらはより高速なnode-sassを使っています。

榊原: そうですね、そもそもCompass自体もうメンテナンスされていませんしね。

白石: で、先ほどの話に戻りますが、色をSassの変数などで管理しようとしたけどまだやっていない、と。

小原: そうですね、やっていないです。様々な場面で同じ印象を与えようとすると、色って一元的なものじゃなくなるんです。例えば同じ色のボタンでも、背景が暗い場合と明るい場合では、明るさが大きく違って見えてしまう場合があります。

そういうふうに、状況に応じて色合いの微調整を行うことを考えると、Sassの変数で一元管理するというやり方はうまく管理し続けられたことがありません。

高津戸: エンジニア的な考え方でいくと色は常に同じに思えてしまうし、一元管理が望ましいとも思えるのですが、現実と照らし合わせると難しいところもあって、今はそうしていないということです。 ただ、Sassのlighten()やdarken()などの関数を使えば、ベースカラーを派生させた色合いの微調整が可能なので、それを活用して色を一元管理できるかも…とは考えています。

白石: 最近、Sass Color Generatorという便利なものがあるのを発見して、重宝してます。

高津戸: 色については、調整のための関数がCSSの標準でも提案されていますね（著者注: CSS Color Module Level4）。

白石: おお、そうなんですね。変数とかも、CSS Variablesなどの標準でサポートされつつありますし、CSS標準にも引き続き注目ですね。

では、過去の話はこれくらいにして、現在皆さんが行っているCSSデザインという話に移行しましょうか。

CSSフレームワーク使う？インブラウザデザインする？

白石: 皆さんは、現在はどのようなワークフローでUIデザインからCSS設計まで行っていますか？ 榊原さんいかがでしょう。

榊原: ぼくは手書きでワイヤー書いちゃったら、あとは直接ブラウザ上で確認してしまいますね。 そういう流れなので、CSSフレームワークは必須です。ざっとコードを組んでしまって、ブラウザ上で確認と修正を繰り返して調整していく感じです。

SketchとかAdobe XDとか、Webやアプリに特化したプロトタイピングツールも試して便利だとは思いましたが、まだ本格的に使ってはいません。

白石: なるほど。榊原さんはインブラウザデザインが主だと。ちなみにCSSフレームワークは何を使うことが多いんでしょうか？

榊原: ぼくはFoundationを使うことが多いですね。

白石: ピクセルグリッドのお二人は、3年前とほぼ変わらない、ということでしたね。

小原: そうですね。今のところSketchは使っていません。

インブラウザデザインは、最終的な成果物を確認しながらできるというのはとても良いのですが、デザインをより良くするという視点で考えると、確認と改善をするためにコードを書かないといけないので、その分時間がかかってしまうと感じています。

ある程度出来上がってからの調整を行うにはいい方法だと思いますが、UIデザインの初期段階だとやはりツールを使ったほうがデザインを素早く行えるかなと。使い分けが大事だと思います。

高津戸: ぼくらは受託のお仕事が中心だから、というのもあると思います。お客様からの要望を聞いて、UIデザインを提案して…っていうフローが重要なので、可能な限り素早くUIデザインを改善できる形に落ち着くんだと思います。

あと、お客様からのニーズに細かく対応していくとなると、CSSフレームワークとかは邪魔になってしまうことが多い。

小原: そうですね。CSSフレームワークはあるレベルまでは便利なのですが、そこを超えて「カスタマイズ」の域に達してしまうと、途端に作業が大変なものになってしまいます。

白石: それはわかる。ぼくらが作っているTechFeedというサービスでも、現在IonicというUIフレームワークを使っているのですが、「ionic-hack.scss」っていうファイルに闇のようなコードを詰め込んでいます(笑)。

榊原: 私もBootstrap使ってた時、「bootstrap-override.scss」ってファイルを作ってましたよ(笑)。

白石: フレームワークを使うか使わないか、って話、些細なことのように思われがちですが、結構大事な話ですよね。

高津戸: ぼくらも、社内だったりプロジェクト単位だったりでフレームワークのようなものを持ってはいるんです。先程申し上げたように、レゴブロックを組み合わせて作る要領で構築を行えるように、ですね。

一般的なCSSフレームワークを使うとなると、まずいらないコードが大量についてきて、そういうコードを捨てるところから始めたくなってしまいます。 不要なコードがたくさんある、というのはプロジェクト全体の見通しの点でも、コードのメンテナンスの上でもよくないですしね。

白石: なるほど、プロジェクト内で再利用できる部分などについては、きちんとフレームワーク化、もっというとコンポーネント化しているという話ですね。 では、いよいよ最後のお題として、今日の主題である「Web Components時代のCSS設計」について話しましょうか。

Web Componentsって…なに？

白石: ではまず、コンポーネント指向とWeb Componentsについて、榊原さんに簡単に説明をお願いしたいと思います。

榊原: はい、ではこちらのスライド（Webコンポーネント時代のCSSデザイン）をご覧ください。

これはHTML5 ExpertsのWebサイトなのですが、よくみると同じようなデザインパーツが使いまわされていますよね。そういったデザインパーツを共通規格化するのがコンポーネント指向です。使い回し、というとちょっと表現悪いので、「再利用性を高める」といったりしています。

例えば、そういう思想を理論化したものとしてAtomic Designがあります。

デザインのパーツを原子、分子、生体、テンプレート、ページという粒度で構成していく。 コンポーネントの再利用については、こういったアイデアが提案されて、試行錯誤されてきました。

（榊原補足：厳密には、Atomic Designは粒度毎のコミュニケーションとワークフローデザイン論ですので、「コンポーネント指向の理論」という見方は一側面となります）

しかし、実際にコンポーネントの再利用を実践するにあたっては、これまではフレームワークや、CSSのクラス名などをやりくりして乗り切っていたわけです。

こうした問題を抜本的に解決すべく、標準技術として提案されているのがWeb Componentsです。 Web Componentsは、端的にいうと自作のタグを作れる技術です。

Web Componentsは、Custom Elements、Templates、HTML Imports、Shadow DOMと言った要素技術から成り立っています。

ブラウザによっても、要素技術によっても対応状況には差がありますが、着実に実装は進んでいますし、Polyfillを使うとほとんどの環境下で利用することができます。近い将来、あらゆる環境でWeb Componentsが利用できるようになるのは間違いないでしょう。

Web Components時代のCSS設計

白石: 榊原さん、簡潔なご説明、ありがとうございました。さて、こうして近い将来Web Componentsの普及が見込めるという状況において、CSS設計などにどう影響するかをお聞きしたいのですが…そもそもWeb Componentsってどう使われるんでしょうね。

榊原: いきなり世界がすべてWeb Componentsになることはないと思うんです。例えば昔はやった「ブログパーツ」みたいなもの、以前はiframeで作られていましたが、そういうものがWeb Componentsという形で流通して使われるようになるとか、そういうところから使われ始めるんじゃないかと。

白石: 広く再利用可能なパーツが、Web Componentsによって流通しやすくなるんじゃないかということですね。

榊原: そうですね、例えばWEBCOMPONENTS.ORGというサイトでは、そういうコンポーネントが共有されていますので、これをサイト制作やアプリ開発に一部利用していくとか、そういうあたりから使われていくんじゃないかと。

白石: では、Web ComponentsはCSS設計にどう影響を与えるでしょう？

高津戸: Web Componentsになったからいきなり変わるということでもなくて、すでに変化は始まっているとは思うんですよね。

例えばBEMやSMACSSなどは、クラスの命名規則やカテゴライズによって、スタイルの再利用性や独立性を高めています。こういう手法を採用してWebアプリを構築している場合、すでにそれはコンポーネント指向的なCSS設計を始めていると言ってもいいんじゃないかな、と思います。

白石: HTML5Experts.jpに寄稿してくださったEnduring CSSなどもそうでしょうか？

高津戸: そうですね。Enduring CSSは、NamespaceやModuleという考え方を取り入れており、Namespaceごとにアセットを分離するよう設計していくのが特徴です。

そうすることで、例えばあるページが不要になった場合、Namespaceに対応するディレクトリごとバッサリと削除してしまえる。そのように分離して管理するということがECSSの目指す設計です。

白石: なるほど。ほかには、コンポーネント指向に関連して、どのようなアプローチが取られていると思いますか？

高津戸: 私自身はまだあまり触っていないのですが、やはり、Reactなどのコンポーネント指向のJSフレームワークの存在を抜きにしては語れないと考えています。

例えば、CSS in JSやCSS Modulesは、CSSのルールを全体に当てるのではなく、コンポーネント内だけに当てるのが第一であるという思想を実装に落としこんだ一つの形であると言っていいかなと。

現時点でも、こういった技術を取り入れることで、コンポーネントを意識した設計が行えるだろうとは思います。これらを例えばReactと合わせて使うことで、CSSが従来抱えていた問題を解決し、コンポーネント指向な開発と相性のいいCSS設計を進められるんじゃないかな、と期待しています。

白石: Angularなんかも、フレームワークの機能として、コンポーネントごとにCSSを分離してくれますよね。私も使っていますが、BEMみたいに命名規約に頼らずにスタイルをカプセル化できるので、クラス名が短いままでも他の部分との衝突を考えなくてすむので気楽です。

榊原: はい、Angularを普通に使うと、CSSがコンポーネントごとにカプセル化されますね。Shadow DOMと似たような分離の仕組みをフレームワークで実現していますね（筆者注: AngularはShadow DOMを直接扱うことも可能）。

白石: 榊原さんは、Ionic2 (AngularをベースとしたUIフレームワーク。解説記事はこちら)やOnsen UI2（ReactやAngularなど様々なフレームワークと合わせて使えるUIフレームワーク。解説記事はこちら）などの、コンポーネント指向のUIフレームワークも活用されてらっしゃいますよね。

榊原: はい、そうですね。Ionicなどで素早くUIを構築してしまって、あとはブラウザ上でデザインしていく…というフローで最近はデザインと開発を行っています。

白石: BootstrapやFoundationなどのCSSフレームワークをベースに素早くUIを作って、あとはブラウザ上でいじる…というのと同様の手法でアプリケーションのデザインを行っているわけですね。

となると結局また、「CSSフレームワークを使うか否か」という先ほどの話と同様に「汎用的なコンポーネントライブラリを使うか否か」という話も出てきそうです。

とはいえ、「外部のコンポーネントを全く使わない」という選択肢もないと思うんですよね。例えばピクセルグリッドさんでも、jQuery UIのDatepicker（日付選択ダイアログ）なんかは使ってたんじゃないかと思うんですが、結局そのデザインカスタマイズなどはどうしてらっしゃったんでしょう？

小原: 実はDatepickerについても、ぼくら自作していたので…(笑)。

白石: ええっ！それはすごい。

小原: もちろん、外部のUIパーツとか、全く使わないわけじゃないですよ。お客様のニーズを満たせるもの、自分たちが求めるクオリティを満たすものがあるかどうかまずは探してみて、なければ自分たちで作るって感じですね。

…

編集後記

というかんじで、イベントは盛況のうちに終了いたしました。その後の懇親会にもかなりの人数の方々が参加され、Webエンジニア同士の交流も大いに盛り上がりました。HTML5Experts.jpは、今後もこうしたイベントを開催していきますので、ご期待ください。

最後に、イベントの様子を書き起こしつつぼくが感じた、今回の結論めいたものを最後に記したいと思います。

そもそもなぜWebにコンポーネント化が求められているのかというと、その理由の一つに「再利用性」があります。そしてその再利用性は、「プロジェクトを横断した、汎用的な再利用性」と「プロジェクト内における再利用性」の2種類が考えられます。

Web Componentsが普及することのメリットの一つは、汎用的な再利用性を持つコンポーネントの流通が活発になることでしょう。

WEBCOMPONENTS.ORGに見られるコンポーネントのリポジトリはこれからも増えてくることでしょうし、コンポーネントを有料で販売するというビジネスも早晩現れることでしょう。

そうしたコンポーネントを組み合わせて素早くアプリケーションを開発する、というアプローチは、今後より一般的になると思われます。

ただし、そうした外部ライブラリやフレームワークを使用する際に厄介なのが、カスタマイズが面倒という問題です。特に、Shadow DOMはCSSを強くカプセル化しますので、カスタマイズがより困難になる印象もあるかもしれません。

しかし、Web Components (Shadow DOM)にはコンポーネント内部をスタイリングする様々な手段があります。それらを使って「汎用的で、スタイリングも容易なコンポーネント」を開発する手法は、今後ベストプラクティスが模索されていくことと思います。

一方で受託開発のように、先にデザインを綿密に擦り合わせた後に開発に入るようなワークフローの場合、外部のコンポーネントをカスタマイズするコストや、コンポーネント内部の構造を把握するためのコスト（そして多くの場合、完全に把握し切ることはないでしょう）が大きく、外部ライブラリを利用するメリットを上回ってしまうことも考えられます。

その場合は外部ライブラリやフレームワークを使用せず、できるだけプロジェクト内や社内で完結するよう、開発用のアセットを積み上げていく方が優れたアプローチでしょう。その場合でも、Web Componentsの「モジュラリティ」や「カプセル化」、「拡張性」といったメリットは非常に大きいのではないでしょうか。

そして今回の主題である「Web Components」は、まだまだこれからの技術なのは間違いありませんが、一方現場ではとっくにコンポーネント化は必要とされ、実践もされています。

それをより良くWeb標準でサポートするための技術がWeb Componentsであり、多くの人に待ち望まれている重要な技術であることが再確認できたかな、と思いました。

しかし、2009年の「モバイルファースト」と、今の「モバイルファースト」は大きく中身が成長しました。モバイルフレームワークであるIonic 2も先日リリースされましたので、ここで改めて「モバイルファースト」とは何かを考え、モバイルの設計を見直していきます。

レスポンシブとモバイルファースト

モバイルファーストは、「モバイル環境に最適化した開発手法」と説明することができます。

モバイル（多くはiPhoneを指しました）は解像度が低く、操作方法もPC文化と異なり、かつ通信速度も遅いという制約があります。イベントひとつとっても、onclickでは待機時間があるから、jQueryのtapイベントを使う、というようにPCとモバイル開発の乖離をどのようにするかの課題があります。

モバイルファーストがいわれはじめた2009年当時は「PC版を作ったあと、MediaQueriesを使ってモバイルでも表示させる」というワークフローが主流でしたが、これではPCとモバイル開発の乖離にアプローチするのが難しかったため、「先にモバイル版をつくる」ワークフローを取り入れる現場が多く生まれました。PCよりもモバイルを優先させるので、「モバイルファースト」だったわけです。

その頃は、モバイルファーストとレスポンシブデザインの区別がつかない議論を度々聞きましたが、もうここらへんの誤解は整理された感があります。

Googleが提示する「次のモバイルファースト」

モバイルからのアクセスが主流になる中で、Googleは「次のモバイルファースト」として、2つの選択肢を提示しました。AMP（Accelerated Mobile Pages）と、PWA（Progressive Web Apps）です。

簡単に概要をいうと、AMPは超高速でWebサイトを表示することができます。HTMLやJavaScriptは高速化を妨げるものは使えなくなっており、またCSSはインラインのみでの表示でありと、ひたすらページ表示速度をあげるための仕様です。 PWAは「Webのアプリ化」を標榜したもので、インストール型のアプリと同様にWebを使うことができます。代表的な内容でいえば、Webをアプリとしてインストールしたり、オフラインでも表示することができたり、プッシュ通知を受け取ることができるようになります。

Googleはこの2つの仕様により、

• 普通のWebサイトなら、超高速化するためにAMP
• いろいろな機能を実装するなら、PWAでWebをアプリ化

という2つの「次のモバイルファースト」を提示しました。これは、今の「レスポンシブにしてモバイルで表示できればOK」から大きな変化であり、これからのモバイル体験を大きく変えるものになるのではないでしょうか。

UIデザインのモバイルファースト

PWAの標榜する「Webのアプリ化」は、UIデザインにおいても「次のモバイルファースト」を生み出す可能性が高いです。 皆さんご存知の通り、PCと（現在の）モバイル、そしてモバイルアプリはUI文化が異なります。PCとモバイルのWeb表示はレスポンシブデザインによって多くの共通化されたモジュールが使われていますので似通っておりますが（便宜上、これらを「現行WebUI」といいます）、モバイルアプリUIは別物に近いといっていいでしょう。

例えば、「現行WebUI」では、HeaderのロゴはクリックしてHOMEに戻るという文化があります。ほとんどがこのUIを採用しています。しかしながらモバイルアプリはHeader部にロゴは入れませんし、入れていてもクリックさせない場合が多いです。 また、「現行WebUI」ではクリックできる場所は明確にするしきたりがあります。例えばカードデザインでも下に「詳しくみる」と注釈をつけてクリックを促したりします。しかしながら、モバイルアプリUIでは「カードはとりあえずクリックしてみるよね」という風潮があります。

モバイルファーストで考えた時、Webがアプリ化する前提でのUIの再設計も必要になってくるでしょう。その時に、各デバイスが発表しているデザインガイドラインはとても有用です。

• iOS Human Interface Guidelines（日本語版）
• マテリアル デザイン
• Windows 10 アプリ UX デザイン ガイド（Modern UI）

AMPのように表示速度に最適化したWebはまた異なるUI文化が生まれてくるのでしょうが、「Webのアプリ化」を標榜するPWAはモバイルWebのUIもアプリサイドに寄せていくことになりそうです。 　

デバイスの作法に寄り添うために

WebのUIもアプリサイドに寄っていくことを考えた時、一番大きなハードルになるのは前挙した「各デバイス毎のデザインガイドライン」をどのように吸収するかです。モバイルでは、デバイスの文化に寄り添うUI設計が最もユーザの学習コストが低く、適切なUI,UXを提供することができます。iPhoneはフラットデザイン、Androidはマテリアルデザイン、WindowsPhoneはModern UIを提供するために1リソースで複数デザインパターンを用意して保守し続けることはハードルが高く現実的ではありません。

そのハードルに対して、適切にソリューションを提供してるモバイルフレームワークのひとつに、Ionic 2があります。

Ionic 2は、2017年1月にリリースされた、Angular 2を使って構築するモバイルフレームワークです。現在、（著者が確認する範囲では）唯一のPWA対応を標榜したモバイルフレームワークとなっております。

Ionic 2のWebComponents

よくモバイル開発で使われるComponents（CardやFabitなど）を、フラットデザイン、マテリアルデザイン、Modern UIのパターンを用意し、フレームワークが判断して自動的にデザインをデバイスに合わせます。

Ionic 2は、デフォルトで用意しているUIパターンは、複雑になりがちなHTMLを「Web Components」という技術によってカスタムタグを用意して、コーダーの負担を減らす工夫をしています。例えば<button ion-button>Login</button>というボタンがあると、これをフレームワークが自動的に展開して、ユーザには

<button block="" ion-button="" class="button button-md button-default button-default-md button-block button-block-md">
    <span class="button-inner">Login</span>
    <div class="button-effect" style="transform: translate3d(392px, -91px, 0px) scale(1); height: 240px; width: 240px; opacity: 0; transition: transform 552ms, opacity 386ms 166ms;">
    </div>
</button>

と表示されます。手元のソースコードはシンプルですので、可読性が高く、またデバイス毎の表示に困ることはありません。2017年3月現在、28のコンポーネントがデフォルトで用意されています（コンポーネント一覧は公式リファレンスをご覧下さい）

また、フレームワークが直下に<ion-app>というタグを生成してくれており、そこにデバイスを示すclass（iPhoneだとios、Androidはmd、WindowsPhoneはwp）をつけてくれます。なので、もしも自分自身でカスタムデザインを用意したい場合、それを親にしてCSS設計することが可能です。

Ionic 2のオフライン表示

GoogleのPWAのガイドラインの中で「Progressive Web App Checklist」を提供しています。Webをアプリ化するために、これだけはクリアしてねというチェックリストです。

その中で「オフラインでも表示される」というものがあります。普通のWebサイトでは、キャッシュを持っていてもオフライン環境で更新すると「オフラインです」とエラーがでます。しかしながら、Service Workerという技術を使うと、オフライン環境では自動的にキャッシュを返すことができます。

オフライン対応を有効するのはとても簡単で、src/index.htmlの17-24行目のコメントアウトを外すだけです。

<script>
    if ('serviceWorker' in navigator) {
      navigator.serviceWorker.register('service-worker.js')
        .then(() => console.log('service worker installed'))
        .catch(err => console.log('Error', err));
    }
  </script>

このことによって、Service Workerが対応している場合はservice-worker.jsを読み込み、オフライン対応が行われます。回線が安定してるPCとは異なり、トンネルの中であったり山中であったりでも安定してコンテンツを提供するためには必須の機能です。
Ionic 2では、sw-toolbox.jsを利用しておりますので、詳細に興味がある方は「sw-toolbox」をご覧下さい。拡張すれば、いろいろなオフライン時の挙動を制御できます。

Ionic 2のmanifest.json

PWAでは、Webをアプリストアのアプリ同様にHOME画面にアイコン付きで登録することができます。manifest.jsonは、その時のアイコンであったりとか、起動した時のヘッダー部の配色であったりを定めることができます。 初期では以下の通りです。

{
  "name": "Ionic",
  "short_name": "Ionic",
  "start_url": "index.html",
  "display": "standalone",
  "icons": [{
    "src": "assets/imgs/logo.png",
    "sizes": "512x512",
    "type": "image/png"
  }],
  "background_color": "#4e8ef7",
  "theme_color": "#4e8ef7"
}

これを設定すると、Androidで表示された場合に自動的に「ホーム画面に追加」というバナーがでてきて、ユーザに対してWebをアプリとして扱うことを提案することができます。

他のProgressive Web App Checklist

他のProgressive Web App Checklistは以下の通りです。Webをアプリとして扱うことを考える時に、ぜひご配慮下さい。

• SSLで提供されている
• モバイルに表示が最適化されている（レスポンシブデザイン）
• 10秒以内に最初のページが表示される
• Chrome、Edge、Firefox、Safariで動作する
• 各ページはURLを持っている

おわりに

GoogleがAMPとPWAというふたつの選択肢を提示しました。これは、既存のモバイルから設計するデザインワーク中心の「モバイルファースト」から、モバイル体験中心をWebを中心として再設計する新たな「モバイルファースト」を生み出す可能性を秘めています。Webの設計、デザイン、技術の大きな見直しの転換点となるのではないでしょうか。 そこで、ぜひともいちはやく「PWAのサポート」を発表したIonic 2を試していただき、この流れとWebのこれからを体験していただければと思います。

Ionic 2 の日本語コミュニティあります

今では随分改善されましたが、Ionic 2はリリース前（特にβ版時代）はとても日本語情報が少なかったので、知見を共有するためにslackのオープンチャンネルを開設しました。分かる方がいれば有志が回答する形ですのでレスポンス速度はあまり高くありませんが、ご活用いただけましたら幸いです。

Ionic 2 slackチーム

社内のエンジニア向けツールをSaaS事業化

白石：まずは、皆さんの自己紹介からお願いします。

松木：はてなはIDで呼び合う文化なんです。僕は本名の松木を中国語読みにしたSongmu（ソンムー）と呼ばれています。3年前にはてなに入社して、Mackerelのディレクターと東京オフィスのチーフエンジニアを任せてもらってます。

元々はPerlのエンジニアですが、最近はGo言語を書くことが多くなってきました。共著で『みんなのGo言語』という本を書いてたりします。

　▲株式会社はてな チーフエンジニア 兼 Mackerelディレクター 松木雅幸（Songmu）さん

濱田：itchynyです。2015年4月に新卒として入社しました。「Mackerel」のアプリケーションエンジニアとして開発していて、リードエンジニア代行も務めています。

村田：村田（はてなID:murata_s）です。2013年4月に新卒として入社しました。「Mackerel」を担当して3年になります。最近はMackerelのデザインチームをまとめています。

▲株式会社はてな アプリケーションエンジニア 濱田健（itchyny）さん、アートディレクター 村田智（murata_s）さん

白石：今日ははてなさんのサーバー監視サービス「Mackerel」について、いろいろ聞かせてください。

松木：はてなはこれまではてなブログやはてなブックマークなど、カスタマー向けの事業が中心だったんですが、最近はそのバッググランドを活かした他社との協業も増えてきました。

例えば、KADOKAWAさんと共同開発した小説投稿サイト「カクヨム」、ソニーさんとの共同事業である「家電会議」、任天堂さんに開発協力した「Miiverse」などが最近のはてなの流れです。「Mackerel」もその流れの一つで、他社との協業サービスではないですが、カスタマ―向け(toC）で培った技術やノウハウを企業向け（toB）に活かしたサービスです。

はてなは今年16年目の会社ですが、かねてより、社内クラウド基盤を構築・運用し、1000台を越える仮想サーバーをスケールさせ、管理しながらサービスを提供してきました。そのための仕組みも社内で内製してきました。それがMackerelの前身となるツールです。

最近ではAWSやGCPなど、パブリッククラウド上で仮想サーバーを増減させるのが当たり前の世の中になってきたこともあり、前述の内製のサーバー管理ツールのノウハウを活かし、「Mackerel」というSaaSを新規開発し、B向けの新規事業として打ち出したんです。

「Mackerel」には、これまでのサーバー監視・管理ツールと考えを変える必要があると思って作っている部分があります。一つはクラウドの思想に沿った設計であること。昔と違って、今はサービスの状況に合わせてクラウドでのサーバーを増やしたり減らしたりすることは普通になってきました。

でも、サーバーを建てたらすぐ監視を開始しなくてはいけないし、サーバーから外したら監視も外さなければいけない。そういった運用コストを解消したいということ。

もう一つは、UI/UXの差別化。既存のサーバー管理・監視ツールはエンジニアだけが使うものが多く、それもあって、デザイナーがツールの開発に関わることは少なく、見た目や使いやすさが考慮されることはあまりありませんでした。しかし、「Mackerel」は使い勝手や見た目を考えて、いろんな人に使いやすいように工夫をしています。開発には専属のデザイナーが3人携わっています。

白石：グラフがメールで送られてくるといった点もそういったこだわりからなんでしょうか。

松木：はい、メールに限らず全般的にグラフの見せ方にはこだわっています。ブラウザの画面上でグラフを並べて見られるようにしている部分も直感的に見やすいように作っています。

白石：はてなさんは1000台を超えるサーバーを運営していたとのことですが、今はどうなんですか？自前のオンプレが主なのか、クラウドも併用しているのか。

松木：今は併用しています。「Mackerel」自体は自社のデータセンターのサーバーを使っています。新規サービスについてはAWSを使うことが増えていますね。

白石：オンプレのほうが規模が大きくなると、サーバーコストは安くなると思いますが、クラウドを併用する理由は何でしょう？

松木：安定していて、ゆるやかな成長が見込めるサービスは、見積もりやすいのでオンプレにメリットがあるのですが、新規サービスにはやはり素早く作る必要があるので、クラウドのほうが便利ですね。オンプレは改善を重ねる必要があったり、急激なサービス増強といったときに調達が大変なので。

コア部分はScala、サブシステムはGoで開発

白石：プログラミング言語は何を使っていますか？

濱田：サーバーのアプリケーションはScala、ユーザーがサーバーにインストールする監視エージェントであるmackerel-agentはGoで開発しています。外形監視とデーターベースインテグレーションのクローラーなどもGoで書いています。

松木：コアな部分はScalaで、サブシステムはGoで書くといったかんじです。

白石：それぞれ言語を変えてる理由はあるんですか？

松木：Mackerelは複雑なソフトウェアなので、コアの部分は抽象度の高い表現ができる言語を採用するのがいいだろうと。いろんな言語を検討したのですが、静的型付けができ、表現力が高いScalaを採用しました。

ただサブシステムやマイクロサービス的に作る場合など、局所的に少ない台数でパフォーマンスを出したいようなコンポーネントを開発する場合には、Goのほうがマッチしています。

濱田：mackerel-agentはWindowsを含めてどんな環境でも動かないといけないし、実行速度の面でもGo言語は優れていると思っています。サブシステムは本体のアプリケーションに比べると機能が少なく、コード構成が把握しやすくてデプロイも簡単なGo言語は適していると思います。

白石：シングルバイナリになるからとか？

濱田：そうですね。

白石：Scalaってやっぱり重いとかメモリ食うなどのトラブルが起きたりしますか？

松木：現実問題としてはありますね。コンパイル時間の問題もあります。本番ではサーバーを何台か立ててローリングでデプロイする形になるので、ミニマムで構成するにしてもそれなりにコストがかかる。ただ、パフォーマンス自体は悪くありません。開発時間はかかるけど、その分バグが起きにくいので、B向けにはマッチしていると思います。

グラフで直感的に状況がわかるUIデザイン

白石：デザインの話も聞かせていただきますね。UI/UXでこだわっているところ、思い入れがある点などについて聞かせてください。

村田：Mackerelは日常的に使う道具なので、ストレスなく直感的にグラフの傾向がつかめるようにデザインしています。複数のグラフが並んだときにも機能を落とさず使い勝手を保てるように、細かな部分にこだわっています。

このようなツールでは、何かをするためのボタンが多くなりがちですが、それは往々にして最初の学習コストを増やすことにつながります。使い始めたばかりの人でも理解しやすく、必要な時に必要な行動がおこせるような、良い意味で簡素なUIの提供を心掛けています。

最近ではitchynyさんと共同でアラートの絞り込み機能も作りました。

白石：グラフは何で作ってるんですか？

濱田：これはD3.jsで作ってます。グラフにマウスオーバーしたらこのようにメトリックの値が表示されます。

白石：へえ、すごい！これ、モバイルでも見れたりします？

村田：モバイル用のUIも用意しているので、お手元のモバイル端末で見ることができます。出先でアラートを確認したいということありますよね。そんなときに便利です。Mackerelの画面はレスポンシブ設計になっているので、タブレットサイズの端末でもご覧になれます。

白石：レスポンシブなデザインってどんなかんじで作っているんですか？

村田：開発内容にもよりますが、直接HTMLとCSSを触りながらデザインしていくことが多いです。画面上での表示内容は、単に表示サイズもそうですし、様々な利用状況や設定によっても大きく影響を受けます。

想定されるシステムの状態を思い描き、チームメンバーとコミュニケーションしながら進めていきます。GitHubのIssue上でのやり取りに加え、細かなところは口頭で直接会話をしたり、他の拠点にいるメンバーとはハングアウトを活用して議論したりもします。

松木：開発体制のことをもう少し詳しく説明します。東京はビジネスメンバー中心で、プロダクトオーナーやセールス、セールスエンジニアという体制で、開発エンジニアは一人です。京都に他の開発メンバーがいます。

Mackerelのリードエンジニアで開発の最初にコードの1行目を書いたエンジニアが愛知にいるんですが、今は育休中です。なので現在は、itchynyさんがリードエンジニア代行を務めています。

リードがリモートなのでオンラインでコミュニケーションするというスキルが発達しているんですよね。開発ログはちゃんと文章で残すし、気軽にビデオで会話しながらコミュニケーションをとるように意識しているし。

濱田：朝会はスタンダップミーティングの形式なので、10分かからないですね。リモートのコミュニケーションにはZoomというツールを使っています。

松木：Zoomは2年前から使っていて、いろいろ試してみたのですが、これが安定しているんですよ。最近はハングアウトも導入しています。定期的なミーティングとかはハングアウトを使ってやってます。

白石：Mackerelチームは、全員で何人いるんですか？

松木：今はビジネス系含めて16人います。そのうち開発は11人です。

白石：16人いて10分かからないというのは相当テキパキしてると思うんですが、どんな話をされてるんでしょう。

松木：各人がはてなのグループウェアに日報を書いているので、その共有を朝会でやっています。最近はそれも減らしていて、各自が話したいことをGitHubでIssuesを上げて、司会がランダムに読み上げていくだけなので、すぐ終わっちゃう。

村田：デザイナーの分科会もチームの朝会後にやってますね。

毎週必ず新機能をリリースしている

白石：開発ツールや開発の進め方について教えてください。

松木：開発ツールはGitHubとZenHubでカンバン、日々のコミュニケーションツールはSlackを使っています。

開発体制としては、スクラムぽい開発をしていて、2週間に1回開発会議をしています。だいたい5～6時間くらい、メンバーがそろって会議している。誰が何を担当するかなどを決めて、次の2週間はなるべく打ち合わせせずに、集中して開発してもらう。で、一番最後の日は振り返りをします。アジャイルの世界だと「出荷」っていうと思うんですけど、それをめでたいって祝うかんじです。

デプロイは週に2回火曜と木曜に行なっています。こだわっているのは毎週新機能を出すということ。正式リリースから、お盆や正月などを除くと毎週何かしらのリリースを出していることは、評価いただいています。

白石：毎週新機能出していることをどうお客さまにお伝えしているんですか？

松木：告知ブログを毎週日本語と英語で書いています。毎週メールでユーザー全員に告知メールも出しています。楽しみにしてくれるユーザーも多くて、Twitterを眺めていると、告知を見てコメントをしてくれている。祝日の関係で木曜に告知送ると、「今日金曜かと思ってあせった」と書かれていたり(笑)。

白石：巨大な機能を出すときはどうしているんですか。メインの開発ラインと別にしているとか？

松木：厳密なスクラムだと、大きいタスクでも小さな単位に区切ってスプリント内に収まるタスクにしてから始めることが多いようですが、それでは見積もりのオーバーヘッドも出てくる。大きめのタスクに関しては担当を決めて張り付いてもらうことが多いですね。

プロダクションに出していく前は、絶対にプルリクエストを送って誰か他のメンバーのレビュー受けてからマージするようにしています。そこで、一人の人に任せきりになって属人化することを避けてバランスをとっているかんじです。

白石：プルリクエストが巨大になるということはないですか？

濱田：それはそうならないように努めています。まずはテーブルスキーマの変更をレビューに出して本番に反映し、モデル層やAPIなどのレイヤー毎にプルリクエストを出し、順番にレビューしてもらい、リリースしていきます。プルリクエストのサイズを意識して、開発メンバーが誰でも見れるようにしています。

松木：基本的には、この人が見ないとプロダクションに出せないというやり方はしていません。全員がちゃんと全部レビューできるように務めている。リードエンジニアが育休とっていても、代行が問題なくできるのもそういうのがきちんとできているからなんです。

最近結構ほかのチームから新たにメンバーが異動して来たのですが、そのメンバーはMackerelのことを知らないので、逆に積極的にレビューしてくれたりします。全員がレビューするというのははてなのこだわりです。

グローバル展開に向け、初期段階からドキュメントを英語化

白石：フレームワークは何を使ってますか？

濱田：WebアプリケーションフレームワークにはPlay Frameworkを用いています。Lightbend社 (旧Typesafe社) の製品で、継続して開発されており、信頼性も高いと思います。フロントエンドでは、AngularJSを使っています。デザイナーさんにもAngularJSのテンプレートを触ってもらっていますね。

白石：デザイナーさんもプログラミングスキルをお持ちなんですね。すごいなあ。

濱田：データベースはPostgreSQLを使っています。はてなでPostgreSQLを使っているのはMackerelだけですね。採用理由には、外部キー制約を張ったりチェック制約を設定することでデータを固く守れる点や、JSON型があることでメタデータのようなデータも保持しやすいところにあると思います。

白石：Scalaを書くのに使っているのは？

濱田：エディタはVimを使っています。3人ともVimを使っていますね、たまたまですけど(笑)。

松木：あとはEmacs3人、IntelliJが2人ですね。

白石：ということは自由なエディタを使っていいんですね。

濱田：そうですね。私はIDEは使ってないんですが、使っているメンバーもいます。

白石：最後に、これからチャレンジしていきたいことを聞かせてください。

村田：今後もUIは継続的にブラッシュアップしていきたいですね。ユーザーさんの声を聞いて使いやすくしていきたいと思います。

松木：ユーザー数がどんどん増えているので今の10倍になっても負荷に耐えられる環境を作っていきたいです。課題としては、マイクロサービスで各種コンポーネントを起動してテスト環境や開発環境を作るのが大変なので解決したい。あとは、せっかくドキュメントを初期段階から全て英語化しているので海外でも使ってもらえるサービスにしていきたいですね。

白石：Mackerelは僕も使っているので、すごく興味深く聞けました。これからの新機能拡充も期待しています。今日はいろいろ面白い話をありがとうございました。