メルカリで重要な役割を果たしているWebView

白石：お二人は、メルカリでどんなお仕事をされているんですか？

小嶋：私は2015年10月に入社して、アプリケーション内のWebViewページの開発を担当してきました。具体的には大規模なトラフィックがある取引画面や、配送サービス「メルカリ便」に新たな運送会社を追加したり、「大型らくらくメルカリ便」の配送機能を拡大したり、集荷サービスなどの開発も行いました。

白石：ビジネス的に重要な部分を作っていらしたんですね。

小嶋：技術としてはいわゆるHTML5、CSS3、JavaScriptを使ったフロントエンドで、WebView内からお客様の取引状況に合わせて、Web画面を出す部分を担当してきました。最近はメルカリのJP Web版（日本向けWebサイト）の開発を進めています。機能開発というよりは流入施策ですね。

▲株式会社メルカリ エンジニアリングマネージャー 小嶋 仁司氏
メルカリ エンジニアリングマネージャー / Frontend。大手Webメディアで働いた後、Flash の表現力に感嘆しフリーランスで Flash Developerとして働く。その後、Flashの衰退とともにHTML/JS/CSSにスイッチし、ゲームの受託開発などを行う。2015年にメルカリに入社。Web/WebView開発に従事。今はPWAに興味津々。

坂本：エンジニアの坂本です。Engineering Operations Teamというチームで、エンジニア全体の組織作りや制度、採用にコミットしています。現在3名（取材当時）いますが、全員エンジニアです。私は特に中途エンジニアの採用や技術広報、そして技術ブランディングを担当しています。もともとサーバーサイドエンジニアで、2014年に入社して去年の12月まではプロダクトに関わっていました。

▲株式会社メルカリ Engineering Operations Team　ソフトウェアエンジニア 坂本結衣さん
大学卒業後、流通業で営業職や店舗運営を経験し、Web制作会社に転職。PHPを用いたシステムの実装から、要件定義や設計、またDevOpsによる環境構築、Jenkinsサーバー構築等の開発基盤の構築・管理等を担当。2014年にメルカリに入社。Engineer Operation Teamという、エンジニア組織作り・採用・制度・技術ブランディングを行う部署のメンバーとして活躍中。

白石：メルカリはWebViewをかなり使っているんですか？

小嶋：最近はReactNativeを使ったりしているので、WebView自体は減っている傾向にあります。ただし、ReactNativeもJavaScriptで書くのでフロントエンドの領域だと思っています。WebViewとして特にコアな機能は取引画面ですね。

白石：なるほど。ということは、重要な画面はこれまでWebViewで作ってきたんですね。

小嶋：そうですね。当時からするとホットデプロイできる強みや、Webの技術でデプロイして、クイックに画面が切り替えられるという理由でWebViewが選定されたんだと思います。

白石：それはサーバーサイドに画面を更新すれば反映されるということですか？

小嶋：はい。更新性という意味合いでは大分速くなってきたんですけど、ネイティブはどうしてもiOSで申請があったり、ネイティブのアップデートがあるので…。例えば取引画面で使用している外部の配送サービスが急に一時期使えなくなったときに、ネイティブで何ができるかというとメンテナンスと出すしかなく、お客様はアップデートを待つしかありません。それであれば、Web上だけでクイックに開発できる方が良いという選択だったと思います。例えば、招待ページはWebViewで作られていましたね。

WebViewの全体量としては減っていますが、Web文脈でいうと注目度はかなり高まっています。例えばPWAとか。技術選定の根底にあるのは、お客様の体験だと思っているので、その時その時の状況に適した技術選定ができていればいいと思っています。WebViewをなくしていこうとか、PWA（Progressive Web Apps）だけにしていこうとかではなく、その都度リーチできるものを選べばいいかなと。

白石：パフォーマンスの速さとユーザー体験を重視しているわけですね。

小嶋：会社全体としてもテックカンパニーという点を重視しているので、いち早く最新技術を取り入れるという目的もあると思います。

開発速度を優先すべく、コードベースをリージョンで分割

白石：小嶋さんご自身は、ReactNativeの開発をしているんですか？

小嶋：僕自身は以前はUSプロダクトもやっていましたが、現在はJPプロダクトの担当なので、ReactNativeのプロダクト導入経験はないです。

白石：ちなみに、USプロダクトということは、JPプロダクトとは別にアプリを作っているんですか？

小嶋：はい。コードベースの話をすると、去年の秋くらいに現地での開発速度を優先するという目的で、JPとUSとUKのAPI含め、リージョンを分割したんですね。というのも、日本で開発した機能で、一部USで表示がどうしてもおかしくなってしまうこともありました。そういうことを懸念して、現地のことは現地でオーナーシップを持って開発・運営することにして、分割した経緯があります。

白石：Googleは全世界で一つのコードベースだと言ってますが、御社は分割したほうがいいと判断されているというのは、興味深いですね。

小嶋：ステークホルダーが同じリージョンにないということは、タイムゾーン分だけコストがかかります。例えばUSである機能をさくっと1日で開発してリリースしたいときも、JPに影響がないかを見るためにはQAなど複雑なリレーションが発生します。なので、現地でやっていることは現地のルールを優先しています。

坂本：メルカリは会社のミッションとしても、「世界的なマーケットプレイスを創る」ことを目標としています。最終的に世界中でメルカリを使ってもらいたい。ですが、まずは世界を獲りにいくことが最優先。そのために一番いい選択肢は何かと考えたときにリージョンごとに分けるほうが最適だと判断をしました。

小嶋：全リージョンで、完全に共通のコードベースを持つことは大切なんですけど、必ずしも日本のUIが全世界で最適だとは限らない面もあります。民族性や国土の広さなど、様々な違いがあるし、前提として物を売ったり買ったりするマインドの違いもある。そのときに共通のUIベースで勝負するのは難しいという課題もありますね。

白石：とはいえ、決断にはかなりの覚悟が必要だったんじゃないかと思います。そんなことないですか？

坂本：メルカリのバリューの一つに「Go Bold（大胆にやろう）」があります。経営陣も迷ったと思いますが、かなりスピーディに進めていたと思います。

白石：ちなみに、最近GoogleがWeb PaymentsやShippingの機能をブラウザで共有のUIを提供するらしいという話を聞いたのですが、メルカリさんはどう考えますか？

小嶋：Google Paymentsはかなり親和性はあるんじゃないかと思ってます。Webの可能性という話になるんですけど、決済に関して標準化されたものがあるなら、使っていきたい気持ちはあります。もちろんお客様にとって便利になるかどうかを検討してからになりますが、特にPWAやWebベースでのプラットフォーム化が加速していったときに十分可能性がありますね。

白石：個人的にもPWAにはご興味があるとのことでしたけど、社内ではどうPWAを活用していきたいですか？

小嶋：去年もサンフランシスコで開催された「Chrome Dev Summit」というカンファレンスに参加させてもらったのですが、現地ではトラフィックに弱いインドなどではかなり可能性があると発表されていました。話を戻すとお客様にとっての体験向上という意味で、正しいプラットフォームは何なのかを考えながら、特に細かくどんどん変わっていくべきだと考えています。

僕の個人的な意見ですが、例えば会社がビジネスを選定するときは、端末の保有台数や通信インフラの整備の高さなどを含めて海外進出を考えていくと思うんです。いわゆるネイティブライクな体験がWebベースでもできるように担保されるのであれば、Push Notificationなどもありなんじゃないかと。PWAを一番最初に導入してユーザー数を3倍に増やしたインドのFlipkartのように、インドという巨大な人口を有する国でも戦えるんじゃないかと期待しています。

白石：PWAをやるときはWebViewでやってたコードがまた使えるようになるんですか？

小嶋：それでいうと、PWAのアーキテクチャにも最適解がかなりあって。例えばService Workerのオフラインキャッシュ、ヘッダー部分とかグローバルナビ部分などはきっちりコンテンツ部分とは分けるべきだと思います。

App Shellモデルの概念もあるし、既存のWebで培われているコードべースができるとは思っていないのと、メルカリの課題としてリプレイスとかもあると思っているので、新しいものは新しく作りたいですね。

メルカリの開発体制や、サービスのリプレイスは？

白石：続いては、メルカリの開発体制や、サービスのリプレイスをどう進めていくのかなどについて聞かせてください。

小嶋：フロントエンドの文脈で言うと、一部リプレイスの必要があって、常に現場から上げるようにしています。今進んでいるプロジェクトとバランスを持って進められるように意識しています。

白石：それはメルカリJP Webの話ですか？

小嶋：そこもやりたいのですが、もっと優先度が高いところもあります。なぜ今そこをやるのかというのを説明した上でやるようにしています。Webだけではないかなと思っています。

白石：御社でいうフロントエンドというのは、もうWebに限らない？

小嶋：そうですね。フロントエンドはアプリのWebViewの開発をしている人もいるし、Webの開発をしている人もいるし、USはJavaScriptエンジニアが開発しています。Node.jsなども使われています。領域は広がっています。

白石：小嶋さんがフロントエンドだからあまり話に出てこないのかもしれないのですが、思いっきりネイティブで書かれているところも結構あるんですか？

小嶋：かなりあります。うちは優秀なiOSエンジニア、Androidエンジニアが相当数いるので、ロイヤルティ高くお客様の体験向上のために寄与しています。フロントエンドは現状では更新性の高いところを担当していますね。

白石：さらにメルカリの開発の裏側を知りたいと思うんですが、クラウドやデータベースの話から聞かせてもらってもいいでしょうか。

坂本：サーバーサイドはいろいろな会社のサービスを使っていますね。日本のサーバーサイドがメインで動いているのは、さくらの専用サーバーですし、USではAWSを使っていたり、現在では裏側のドメインごとによるマイクロサービス化の流れがあります。

白石：サーバ―サイドは何を使っているんですか？

坂本：サーバ―サイドで最初からコードべースで一番使っているのは、PHPです。

白石：それ以外の言語も増えているということでしょうか。

坂本：マイクロサービスの文脈の中で基本的にインターフェイスが定義されていれば、中身はなんでもOKです。その中でもいろいろな利点からGoを使っているケースが多いです。

チーム体制は3カ月ごとに適したチームを模索

白石：続いては、チーム作りや開発体制について聞いていこうと思います。先ほどフロントエンドの定義についてお聞きしましたけど、大まかにいうとフロントエンド、iOS、Android、サーバーサイドエンジニアというかんじなんですか？

小嶋：開発体制でいうと、さらにプロダクトマネージャーとデザイナーが入ってきます。いわゆるチームプロダクトという大きなくくりで、プロダクトを推進するためのチームになっています。チーム体制についてはクォーター（四半期）制という3カ月ごとに適したチームを模索しています。

僕の経験でいうと、かなりフレキシブルに動いていて、プロジェクトにプロダクトマネージャー、エンジニア、デザイナーと就くこともあれば、僕はJPフロントエンドという横ぐしのチームで動いています。その時にどういうチームが最適なんだろうと結構模索された上でチームを構成します。3カ月後に同じチームがあるとも限らないし、まったく違うチームでやる人もいるし、ずっと同じチームでやる人もいます。

白石：3カ月ごとに編成されるというのは、大分スピーディですね。ちなみにどう開発しているか、どう開発を進めているかもお聞きしたです。相当UXにはこだわっていると思いますが、事前の調査やテスト、それをどうフィードバックして、どう開発やデザインに反映しているんでしょうか。

小嶋：UXに関しては1年前くらいからユーザービリティテストをかなり活発にやっています。お客様に使ってもらって、ご意見を聞きながら、UI/UXの改善しています。あとはABテスト基盤があるので、プロダクトマネージャーが数値をもとに10%改善に基づいて、数値を見ながら取り組んでいます。常にPDCAが回っているかんじです。

ターゲットや契約している会社があるわけではなく、社員は参加も自由で公募もされています。行きたい人が行ける。全社的にプロダクト志向が高いですね。エンジニアだからプロダクトに意見を言わないという風土はないですね。

白石：クォーターごとにチームが変わっていくというお話ですけど、タスク管理などはどうされているんですか？

小嶋：タスク管理に関してはアトラシアンのJIRAを使っていて、全社的にチケット駆動開発で進んでます。情報管理はOSSのコミッターがいるんですが、CrowiというWikiを使っています。チーム移動したからツールが違うというのはないですね。プロジェクトごとに切っているチームもあります。

開発速度が早いがゆえの課題

白石：現在の課題と自慢できること、今後やりたいことについて聞かせてください。

小嶋：メルカリではクォーターごとにプロジェクトのゴールを設定しているので、開発速度が相当早いんです。さらに新規事業も多い。開発速度が早いとなると、エンジニアとしては、技術的負債を早く返したいと考えます。その辺のバランスを見直そうという動きも出ていますが、開発スピードの早い組織ならではの課題だと考えています。

白石：技術的負債をどうするかという問題ですね。

小嶋：スピードも大事ではあるのですが。

白石：自動テストもきっちり書いているとそれだけで時間がかかったりするから、省略するところもあったりしますよね。

CTOとVo/Eの二頭体制

白石：メルカリ開発チームならではの自慢できることは何ですか?

小嶋：現場が技術選定をある程度任されているところですね。あとは月並みですけど、全社員に開発者端末が支給されるんですね。iOSを使っている人だったらAndroid端末、Androidを使っている人ならiOS端末が入社時に無償で貸与されます。パフォーマンス出せるための備品や、エンジニアが最適だと考えるソフトウェアに対してはかなり優遇されていると思います。

坂本：メルカリは退職者が圧倒的に少ないですね。エンジニアに限らず、会社が成長を続けているので離れていく人が少ないし、 ネガティブなことを考える必要がない。プロダクトに集中できるし、今の環境をよくすることに注力できます。

またCTOとVP of Engineerがそれぞれ1名いて、技術的なトップと開発チームのマネジメントのトップが分かれているので、バランスがとれていると思います。CTOが開発体制に入り込んでしまうと、技術的な進歩に貢献することに時間がさけなくなってしまう恐れがありますが、そういうことがありません。

圧倒的に会社の技術を引っ張るという意味で、会社全体を先導しているという姿勢を見せてくれている。リアルな開発現場はVP of Engineerがコミットしてくれている体制があるので、エンジニアたちはよけいなことに時間を使わずに本質的なことにフォーカスできる環境だと思います

白石：CTOがこうだと言っても、現場が異議を唱えることはないんですか？

小嶋：トップダウンというより、どちらかといえば方向性を提示した上でテック寄りな人たちでデスカッションしている。距離が近いので、導入するにしてもしないにしても議論が頻繁に行われています。

白石：現場とトップの距離が近いとのことですが、CTOとのコミュニケーションもフラットにできるということですか？

小嶋：そうですね。かなりオープンな文化なので、CTOと1on1したいときも自由に設定できます。「必ずマネージャーを通すように」などの文化はないです。それから、メルカリでは3カ月に一回、Be Professional Dayという、普段はできないことをやろうという取り組みがあり、誰が何を開発してもいいことになっています。

前回はオートメーションというテーマを設けて箱根で開発合宿をしたのですが、CTOも来てくれて、いろいろアドバイスしてくれました。関係性としてはフラットなのかなって思います。

白石：エンジニアにとってはいい開発環境とチーム体制ですね。これからのメルカリにも期待しています！今日はいろいろ面白い話をありがとうございました。

▲メルカリのバリュー「Go Bold」グッズがたくさん！

今年も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に登壇するエキスパートに、予定しているセッションのトピックを中心に、いろいろ伺ったものです。セッションの内容をより深く理解する手助けになるだけでなく、本記事単体でも面白く読んでいただけることを目指しています。

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

関口さんのセッションは「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くらい眺めて特徴を把握するだけでもいいと思います。

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

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

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

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

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

今回お話を伺ったのは、株式会社サイバーエージェントにお勤めの佐藤歩さんです（ネット上では「あほむ」「ahomu」のIDで有名）。 （プロフィールはこちら）

あほむさんのセッションは「最近のWebパフォーマンス改善について知っておきたいコト」（ホール 13:20-14:00）です。 （現在HTML5 Conference 2017は定員オーバーの状態ですが、無料イベントということもあってキャンセルも多めに出るらしいので、あきらめずにキャンセル待ちすることをお勧めします！）

パフォーマンスはなぜ重要か？を違う切り口から伝える

白石: Webパフォーマンスについて、「ベーシックな話を少々と、最近の動向」をお話されるということですね。

あほむ: はい、そうですね。まあ、まだセッションの内容はほとんど固まっていないので、当日は全然違った話をすることになるかもしれないのですが。

普通パフォーマンスに関する「ベーシックな話」というと、「なぜパフォーマンス改善は重要か」ということを語られることが多いと思うんです。でも、「パフォーマンスが重要」というのは、もうエンジニアには広く認識されているんですよね。

足りないのは、パフォーマンス改善を「開発者の自己満足」で終わらせないことなんじゃないかと。パフォーマンス改善が、自社のビジネスにどう寄与するのか。そこを考えないと、意味のないパフォーマンス改善を行ってしまう恐れもあるし、社内の理解も得られない。

「パフォーマンスは重要である」というメッセージを、そういう観点からも伝えたい気がします。それも他社の事例とか一般論から語るんじゃなくて、私自身が遭遇した実体験などを踏まえて語りたいな…と思ってます。

白石: それは面白そうですね！具体的には、どんな実体験になりますか？

あほむ: 例えば、弊社のサービスってSNSでWebページが拡散されることが、非常に大きな比重を占めているんです。つまり、TwitterやFacebookのアプリ上で、WebViewでページを表示されることがすごく多いんです。そうなると、実はブラウザのキャッシュにすら期待できないことが多い。弊社のサービスはiOSのユーザーが多いのでなおさらです（※）。

とはいえ、SNSを通じてたまたま遭遇した、っていう千載一遇のチャンスは活かさなくてはならない。そういう限定された環境でも最高のUXを実現するため、最大のパフォーマンスを発揮するにはどうしたらよいかを常に試行錯誤しているんです。

白石: なるほど。確かにそれは、パフォーマンスが非常に重要なシチュエーションと言えそうです。

あほむ: こういう例を含めていろいろ紹介できるといいかもしれません。URLさえあればどこからでもアクセス可能というのはWebの利点ですが、要はどんな環境で見られるかわからないということです。だから、Webのパフォーマンス改善には終わりがないし、少しでもその助けになるよう、常に新しいアイデアや技術が考案されています。そういう技術のうち、比較的新しくて、活用しがいのあるテクニックや仕様について、いろいろご紹介できればと思っています。

※弊社のサービスはiOSのユーザーが多いのでなおさら…Androidであれば、Chrome Custom Tabという仕組みでメインブラウザ（Chrome）とキャッシュなどのリソースが共有されることも期待できる。iOSは、Chrome Custom Tabに近いSafari View Controllerという仕組みがあるが、あまり利用されていない。

ページロードパフォーマンスの改善テクニック

白石: では、パフォーマンスを改善していくテクニックや仕様をいくつかご紹介いただけますか？

あほむ: Webパフォーマンスを考える際には、やはりページロード (ページの読み込み速度)と ランタイム （ページ実行中のパフォーマンス）に分けて考えるのが王道です。ページロードの改善については、最近だとHTTP/2の話が中心になると思います。

白石: なるほど、御社のサービスでは、HTTP/2対応はもうかなり進められている感じなのですか？

あほむ: はい。できるところからHTTP/2にしていくというアプローチで、現在は多くのサービスがHTTP/2を利用して動いています。

白石: 実際にHTTP/2に対応してみていかがですか？苦労した点とかはありましたか？

あほむ: 具体的な切り替え作業については、インフラの専門チームが実施してくれるので、あくまで開発側からの意見になりますが…ほとんど苦労していることはないですね。

白石: おお、本当ですか。それは素晴らしい。

あほむ: はい、HTTP/2に切り替えても、開発への影響はほとんどなかったという点はとても重要ですね。アプリケーションとネットワークで、レイヤーが違うから当然といえば当然なのですが、やはり実際に経験してみると、そのありがたさが実感できます。トレードオフがほとんどないにも関わらず、パフォーマンスの向上が見込めるのですから。

白石: でも、HTTP/2に切り替えたことで、本当にパフォーマンスアップするのか、懐疑的な意見も目にしたことがあります。実際のところどうなんでしょうか？

あほむ: うーん…実際のところ、それはありますね。HTTP/2にしただけだと、体感的に良くなったっていう実感があまりないのは、正直なところです(笑)。

白石: それも正直な意見として、貴重だと思います(笑)。

あほむ: 例えばHTTP/2でヘッダ圧縮されてデータ転送量が多少減ったとしても、アプリケーションで扱うデータが最適化されてなかったら、誤差みたいなレベルになってしまいますからね。HTTP/2によるパフォーマンス向上は、確実に効いているとは思います。ですが、実際のサービスでは、常に別のところにパフォーマンスのボトルネックが潜んでいて、効果のほどが見えにくいんですよね。

白石: 他には、ページロードの最適化で知っておいたほうがいいテクニックとかありますか？

あほむ: ほかには、コンテンツの圧縮にZopfliやBrotliを利用していますね。他にはResource Hintsなども使っているので、お話したいですね。

※参考記事：FRESH! Web パフォーマンス改善 〜サーバサイド編〜

白石: Zopfli…？そんな圧縮形式があるんですか？

あほむ: はい、ZopfliもBrotliも、どちらもGoogleが開発した圧縮形式です。

Zopfliは、圧縮の速度は遅いですが、そのかわりに圧縮効率は非常に良い。そしてgzipとの互換性があるので、gzipに対応したブラウザであればだいたい扱えるという大きな利点があります。

Brotliは、gzipとの互換性はありませんが、非常に効率のよい圧縮アルゴリズムです。こちらは現在のところ、Chrome, Firefox, Edgeでのみ利用可能です。

白石: Resource Hintsというのはどういうものですか？

あほむ: 利用するリソースを先読みするヒントをブラウザに与えるための仕様です。これを利用すると、現在のWebページに含まれていないリソースであっても、ブラウザに先読みさせることができます。dns-prefetch (名前解決を実行しておく）, preconnect （サーバ接続を行っておく）, prefetch （リソースのフェッチを実行しておく）, prerender （ページのレンダリングをバックグラウンドで実行しておく）といったタイプの先読みが可能です。 （筆者注: Jxckさんのブログで詳しく解説されています）。

ランタイムパフォーマンスの改善テクニック

白石: ランタイム （アプリケーション実行時）のパフォーマンスを向上させるために使用している技術にはどんなものがありますか？

あほむ: Intersection ObserverやPassive Event Listenersは利用しがいがあると思います。

Intersection Observerというのは、要素同士の領域が交差したり、もしくはビューポート（ユーザーに見えている範囲）に要素が入ったかどうかなどを検出できるAPIです（筆者注: Intersectionとは「交差」の意味）。これを利用すると、ビューポート外で行われる処理を抑制したり、遅延させたりすることが可能になるので、パフォーマンス向上には非常に効果的です。わかりやすいのは、img要素がビューポート内に現れるまで画像の読み込みを遅延させる…などですね。

Passive Event Listenersというのは、UIイベントが preventDefault() （デフォルトの動作をキャンセルする）されないことを保証するための仕組みです。

スクロールイベントなどは、 preventDefault() を行うことでブラウザのスクロール処理そのものをキャンセルすることができます。逆に言うと、ブラウザはスクロールがキャンセルされる可能性を考えると、イベントハンドラを実行してから実際のスクロールを行わなくてはならない。だから、イベントハンドラの実行に時間がかかったりすると、スクロール処理が詰まってしまうんです。これがスクロールジャンクと呼ばれる現象です。

ただ、実際に preventDefault() でスクロール処理を止めたいというケースは多くはありません。なので、「このイベントハンドラはpreventDefault()を呼ばないよ」ということをブラウザに伝える手段として用意されたのがPassive Event Listenersです。

（筆者注: これらも、Jxckさんのブログに詳しい解説がある。Intersection Observer Passive Event Listeners）

白石: 今おっしゃったIntersection ObserverやPassive Event Listenersは、全てのブラウザで動くわけではありませんよね？

あほむ: はい。なので、動作しないブラウザ用にFeature Detectionで分岐を設けたり、Polyfillも活用しています。

白石: なるほど。ただ、最初にお聞きした例だと「SNSで拡散されたページの最適化に注力している」というお話でした。こういうランタイム系のパフォーマンス改善って、SPA (Single Page Application) ではない通常のランディングページやメディアのサイトなどでも重要なのでしょうか？

あほむ: そう思います。先程も申し上げたように、SNSを通じてサイトにアクセスしてくれるのって、ユーザーと接触できる千載一遇のチャンスなわけです。そこからモバイルアプリへの誘導を行うこともできる。なので、そういう千載一遇のチャンスで少しでも機会損失を起こさないように、入念にパフォーマンスをチューニングするのは非常に重要です。

個人的には、jQueryを使った普通のWebサイトこそ、ランタイムのパフォーマンスにもっと気を使うべきだし、できるとも思います。jQueryのプラグインが最新の仕様に追従すれば、プラグインをアップデートするだけで恩恵を得られるわけですから。

ただ逆に、プラグイン側が対応してくれなかったりすると、プラグインの中に手を入れるわけにもいかず、対応が進まないということの裏返しでもありますけどね…悩ましい問題です。

パフォーマンス改善を「開発者の自己満足」で終わらせないために

白石: これまでご紹介いただいた様々なテクニックですが、これらを活用してパフォーマンスを実際に改善していくのは、実際には骨の折れる作業だと思います。そうした、パフォーマンス改善作業に投下するコストと、それによって得られるリターンについては、どのようにお考えでしょうか？

あほむ: はい、おっしゃるとおり、これらのテクニックをただ使って、目に見えない部分でパフォーマンスを改善しても、単なる開発者の自己満足に終わってしまいます。それを避けるためには、まずは正しく計測することと、それがビジネス上のKPIとどう関連付けているかを検証していくことが必要です。

まず計測についてですが、クライアントサイドのパフォーマンスを計測する指標は、現在も様々なものが考案され、利用可能です。

例えばFirst Paint。Webページの描画が開始されたタイミングを表す指標で、ChromeやEdgeでは非標準のAPIから値を得ることができます。

ただ、First Paintだけでは、コンテンツの表示が完了するまでの速度などについてはわかりません。最も重要なのは、ユーザーに見える範囲、つまりビューポートの描画がいつ完了するかです。

そういう観点での指標としてはSpeed Indexがあります。Speed Indexを計測する基本的な方法としては、描画中の画面をキャプチャして、最終的な表示結果が得られるまでにどれくらいかかるかを測るというものです。弊社のサービスでは、ページビューや直帰率といったKPIとSpeed Indexの間に相関関係が認められたため、Speed Indexを中心にパフォーマンス改善を行いました。

さらにこうした指標は実際のユーザーの環境で得られた値を一定量集めることも大事なので、集計結果をGoogle Analyticsに送信しています。そうすることで、GAを使いなれたプロに分析をお任せすることもできますからね。

そうした経緯は弊社技術ブログの記事に詳しく書かれています。

白石: なるほど…パフォーマンス改善がビジネスに寄与するという道筋を立てることで、パフォーマンス改善が業務として意味にあるものになるわけですね。

あほむ: そうですね。パフォーマンス改善とビジネスが両輪としてうまく回るためにも、やはり様々なパフォーマンス指標や計測が大事になってきます。

指標は他にもFirst Contentful Paint （コンテンツが表示され始めた時）や First Meaningful Paint （ユーザーに意味のある表示になったとき）など様々なものが考案され、実装も行われています。よければそういう話をまとめた私のブログ記事も見てみてください。

白石: なるほど、今日は貴重なお話をお聞かせいただきありがとうございました！HTML5 Conferenceでのセッションも楽しみにしています。

そこで今回編集部では、スペシャリストにアドバイスを受けながら、データ分析を自動化したり、執筆陣ともっと気軽に議論できる編集プロセスの「自動化＆見える化」にチャレンジしてみました。

「日本にもっとエキスパートを」の指標をつくる

今回編集部が指導を仰いだのは、NTTレゾナントのUX戦略チームで「goo」全体のSEOなどを担当する大谷祥さん。また、全社横断のマーケティング室という組織でアクセス解析やABテストツールを利用したデータ主導によるサイト改善に対する取り組みも行っています。

まずは、HTML5 Experts.jp（以下、HX)が目指す「日本にもっとエキスパートを」というビジネスゴールが、どういう状態になれば達成されたと見なすのか、その成果を測る指標を定めるところから開始しました。

大谷：「日本にもっとエキスパートを」がビジネスゴールといっても、これが指標だと示すのはすごく難しいと思うんです。どうなった状態が、エキスパートが増えたと言えるのか、まずは皆さんの意見をお聞きしたいんですよ。

　▲NTTレゾナント株式会社 UX戦略チーム 大谷祥さん

白石：そうですね。HXは、高い技術力を持ち、専門技術の啓蒙活動を行っている知名度の高いエキスパートや、技術コミュニティや自らの専門技術の知識を世に発信したがっているコントリビューターの方たちを、数多く執筆陣に迎えています。

HXを読むことで専門知識や技術力を高めてもらい、次はその人がいいアウトプットをたくさんしてエキスパートになる。そうした広い意味でのエキスパートの人が増えて、どんどんいい情報や知識が循環されていくことも目標の一つです。技術コミュニティの考え方に近いんですが、それをメディアという場で活性化させたいんですよね。

仲：記事のPVやUU数を増やすことはもちろんですが、有益な情報を発信してくれるエキスパートの執筆陣も増やしていきたいです。コントリビューターがエキスパートになったり、記事を読んでくれた読者がエキスパートになってくれたら素敵ですね。

　▲左から大谷さん、HTML5 Experts.jp編集部 桂 健太さん、仲 裕介さん

白石：ただ、ここでエキスパートって言っているのは、僕らの定義してるHXのエキスパート（エキスパート一覧ページに掲載されている方々）と、一般的な意味（「専門家」という意味）でのエキスパートを増やすっていう、どっちの意味もあると思ってて。広い意味でのエキスパートが増えて、HXというメディアという場で、何か書いていただいたり交流する機会みたいなのを作っていければと。

大谷：技術コミュニティの考え方に近いかんじですね。

白石：HXは、もともとそんなに閉じたコミュニティにするつもりはなかったんです。僕はhtml5jというコミュニティを立ち上げて、管理人をやっていたことがあるんです。それは誰でも入れる『Everyone is welcome！』というかんじで運営していました。でも一方で、入るのにはハードルがあるコミュニティも作ってみたかった。卓越した技術や知識を持つエキスパートだけが入れるような。そのコミュニティというのは、今、メーリングリストで運営されています。でも、メーリングリストって、情報が一方通行なんですよね。HXもメーリングリストでエキスパートたちとやりとりしていますが、それをやめて、Slackに移行したいなと。

企画のアイデア出しはもちろん、執筆の依頼や原稿の催促なども、メールでがっつりやるよりも、Slackとかでbotを作って締め切りを伝えてくれるようなことが、気軽にできたらいいなとか。さらに妄想すると、PV報告botみたいなの作ってみたい。そういう気軽に意見を言い合ったり、お互いに編集し合えるスタイルにしたいですね。

　　▲HTML5 Experts.jp編集長　白石俊平さん

仲：そこを面白がってくれた人がエキスパートになってたくさん記事を書いて、それを見た人が自分も書きたいと言ってくれたら嬉しいですね。

白石：そうですね。あと、エキスパートのサイト登録をしてると毎回思うんですけど、すっごく面倒なんですよ。Googleのスプレッドシートに書いてもらったプロフィールを、僕らが手作業でWordPressに転記しなきゃならない。しかもね、そのやり方が煩雑なので、いつも忘れて、前の人がどんなメールの文面を送ってたか参照して…。ソーシャルログインとか、パスワードをこっちから発行して、これでログインしてってかんじでできるといいんですけどね。

仲：それ、ありですね。

白石：メンバー用のSlackにも登録されて、WordPressにも自動的に登録されたらいいなと。エキスパートやコントリビューターをどんどん増やすなら、こういう作業はどんどん自動化したいですね。

桂：いいですね、URLとか何かアクセススキームみたいなものを相手に送ったら、勝手に登録が簡単にできるようになるといいですね。そうなると、パスワードみたいなものを発行しなきゃですね。

仲：プロフィールページもエキスパートが自分で登録できるようにしましょう。そのほかにも対応できそうなのはこの機会に全部自動化しちゃいましょう。

大谷：ところで、読者のベネフィットはどうでしょう？どのようなバリューを届けたいのか、読者の位置づけって、どう考えていますか。

白石：ほかのメディアとあまり変わらないとは思いますけど、こちらとしては、いい記事を届けているつもりなので、読者にとってのメリットは、やはりいい記事を読めることですね。

大谷：なるほど。読者のほうからコミュニティに入っていくという流れも、あると思いますけど、その辺はいかがですか。

白石：いや、作りたいですね。昔はライター募集みたいなのをやろうとしたんですけど、今はやれてないんです。なので、こっちがスカウトしてくる、みたいな。

大谷：読者と執筆者（エキスパート）のバリューが、どうやったら、マッチングできるのかというところを考えてあげるのが、編集部の役割かもしれませんね。そのマッチングするポイントというのを、見える化することで、エキスパートも、読者も、より改善できていくサイクルになるのが、一番よい気がします。

仲：エキスパートと読者の交流イベントや、コメント欄の設置もやってたことはあるんですけどね。途中でやめちゃったので、また何かのかたちで復活させてもいいかもしれません。

白石：僕はコミュニティ活動を結構していたので、コミュニティの価値って何なんだろうみたいなことを考えたり、いろんなところで話したりするんです。そのうちの一つにですね、暗黙知を形式知化するってことがあると思うんです。それを蓄積する、集積するみたいなかんじで、イベントや勉強会でプレゼン資料が作られる。それが、その道に詳しい人たちが持っている暗黙知が、そこで形式知化される。

そういう機能をコミュニティが持っていて、例えば、Q&Aがすごい盛り上がってたりすると相互にコミュニケーションが発生する。そこで知識が出てくることで、インターネット上に形式知化されていくみたいな。もしかしたら同じように、エキスパートとかが持っている暗黙知を形式知化をすることができるんじゃないか、というのをHXの価値として考えています。

既にエキスパートの人はある程度知名度がある人が多くて、いまさらHXに書かなくても、既に知名度がある。HXに書く意義としては、編集者がついて企画の壁打ちや締め切りをつついてくれる、原稿チェックもしてくれる、で、そこにお金みたいなね、金銭的動機みたいなのを交えて、さらに、なめらかにそれが形式知化されるのを助ける気になる、それも、あるといいのかな、かもしれない。

大谷：なるほど。いまの白石さんのお話を絵にしてみました。

　　▲HTML5 Experts.jp企画会議メモより　by大谷さん

HXのメディアとしてのバリューは以下の3つにまとまると思います。

1. 編集部として、エキスパートから知識を形式知化して引き出す
2. HXを通じたコミュニティを形成し、エキスパートを増やす
3. 上記を繰り返すことで、さらに新しい情報を読者に届け続ける

これらのバリューを最大化させるためには、目指す指標が必要です。その指標をどこに置くか探るために、Analyticsを使ったHXの現状レポートがいくつか作ってきたので、それを見ながら探っていきましょうか。

バリューを最大化するための指標設定をどうする？

大谷：まずは、月別のページビュー数、セッション、ユニークユーザー数などの基本情報から。月別に比較してみると、2013年の7月が一番数字が高く、2014年に一度跳ね上がり、2015年くらいにもう一段階上がってからは、ほぼ横ばいという状況が続いています。

次に時間別に見てみると、日中の時間帯が多く見られていることがわかります。

仲：HXでは、通常午前9時に記事を公開しているから、ちょうど会社に出勤したあたりから、仕事しながら記事を見てもらっているようですね。公開時間は朝・昼・夜のいずれがいいのか悩むことが多いです。

大谷：こうしたボリュームゾーンを見る限り、9時公開は間違っていないと思いますよ。

大谷：曜日別では火曜がもっとも多く、次いで水曜、金曜と続きます。記事の公開が少ない土日が低いのは当たり前として、月曜が低いのは休み明けの影響からかもしれませんね。もちろんこれらのアクセスデータは、メディアの性質やターゲット特性によっても変わってきます。アクセス経路などのデータも検証してみると、8割近いユーザーがPC（desktop）経由です。

桂：スマートフォンやタブレット（mobile・tablet）経由が約2割と少ないですね、その要因も考えていかなくてはならないと感じました。

大谷：次にお見せしたいのは、分析の対象を条件で絞り込めるアドバンスドセグメントと必要な情報だけをチェックすることができるカスタムレポート。記事ページだけではなく、記事毎に付与しているタグや、特集や連載などのシリーズなどからもアクセス数をチェックできるので、効果の検証も効率が上がります。

セグメント条件

• ユーザーセグメント：１回しかこないユーザー
• ユーザーセグメント：月に２回
• ユーザーセグメント：週に２回

▲「行動」から「セッション」と「セッションの間隔（日数）」を設定。月2回は「セッション 2」と「セッションの間隔（日数） 30」、週2回は「セッション 2」と「セッションの間隔（日数） 6」というように設定する。

カスタム レポートの内容

• 流入数
• タグページ
• シリーズページ
• 記事ページ
• 基本情報

大谷：実際に流入経路を見てみると、検索流入の割合が非常に多く、FacebookとTwitterからの流入と、はてなブックマーク（はてブ）からの流入が続きます。技術系のメディアにしてはソーシャルメディアからの流入が少ないのは気になりますね。ソーシャルからの流入が多いほうが記事が話題になるのでそちらも注力すべきですが、検索からの流入が多いということは、白石さんが言う『知識を文章化して残す』という点ではまさにそれができているとも言えます。

そのほかにも、タグのページカテゴリの流入の方や、著者別のページやトップページへの回遊が一般のメディアに比べて少ないです。たしかに一回の訪問で複数記事が読まれないメディアも多いのですが、エキスパートたちが書く技術系のメディアなので、もっと多くてもいいかなという気がします。

あと気になったのは、人気があった記事の滞在時間は長いけど、下位にいくほど短くなる。こうしたユーザーの行動が見えてきたら、いろいろと打つ手が見えるくるはずです。カスタムレポートからユーザーの傾向や記事の貢献度などを著者に伝えることで、より高い価値創造・提供が実現していくのではないでしょうか。

自動化・見える化を、さらに仕組み化する

大谷：メディアとしての傾向がつかめてきたら、次は指標化です。目標値の設定と記事別に期間を定めて、その貢献度を指数化・スコア化していきます。この際に重要なのが、冒頭でディスカッションしたHXのビジネスゴールを正確に測ることのできる指標になっているということ。

そのため、PV数などの数値の高さだけが価値になるとは限りません。例えば、高度な専門技術の場合、どうしても幅広いユーザーを集めることは難しい。その場合は、記事の滞在時間やソーシャルで展開された記事の感想などが指標となってきます。普通は公開後1週間の数字をウォッチするケースが多いですが、レポートを見てみると1カ月とか1年という期間で見られている記事も存在する。サイト全体PVを支えるロングテールとなっていて興味深いですね。

ロングテール事例(1)

▲2015年3月4日公開の「今話題のReact.jsはどのようなWebアプリケーションに適しているか？」

ロングテール事例(2)

▲2013年8月20日公開の「Bootstrap3超速レビュー！刷新されたグリッドシステムを理解しよう！」

HXの場合、まずは指標化しやすい「記事を読む」部分のバリューを評価するための指標を決め、それが機能し始めたら「記事を書く」という指標につなげていましょう。HXならではの技術キーワードのタグや、特集・連載などシリーズ企画に対する記事の貢献度をスコア化して短期・長期で検証した数字を見える化すると、編集企画会議をする時にも必ず役立つと思います。

こうしたサイトでの傾向と著者に求める価値（記事のクオリティなのか、専門性なのか、ソーシャルでの影響度なのかなど）がはっきりすれば、依頼内容も明確になってくるし、記事のスコアリングも伝えやすくなりますよ。

さらに、記事単体の指標化や自動取得だけにとどまらず、メディアで技術コミュニティを実現するという目標に対してKGI（目的を達成できたかどうかを計測する指標）を設定するところまでつなげてほしいです。

グロースハックの話になるんですが、指標化された定常的なデータをもとに、メディアの成長を見える化させてモデルを作るということですね。改善を繰り返していく仕組み化が必要になってきます。どうやって、エキスパートが増えるモデルを作るのか、ここを次のステップとしてやらなきゃいけないところ。編集部のビジョンが重要になります。

▲GrowthHackとは数値やユーザーの声を分析し、ユーザーの数や質をGrowthさせる仕組みをプロダクトの中に組み込むこと

ビジョンを達成するためのゴール設定が決まると、PV数やシェア数を伸ばすとか1年後も検索流入があるといった流入改善や、読了率や回遊率を上げるにはどうすればいいかを考えるようになるし、記事のテーマや書き方をどうするかなどにつながってくると思います。あともう一つ大事なことは、ユーザーである読者のロイヤリティをどう指標化するかですね。読了率はもちろんですが、再来訪してくれかも大事な指標です。

▲ユーザーの行動モデルをもとに5つのステップに分けたフレームワーク「AARRR」

大谷さんの指摘からアドバンスドセグメントの機能を使ってマンスリーアクティブ率、ウィークリーアクティブ率などで見てみると、一回しか訪れてくれないユーザーが95％と、極端に少ない…。エキスパートを増やす＝継続して技術情報にアクセスしてくれる読者を増やすという視点でいうと、アクティブユーザーが少ないのは、編集部側の課題として大きな指標となります。

また、技術専門サイトならではの著者や技術タグをよりクローズアップさせるなど、サイト改善の必要性などについても指摘をいただきました。

さらに議論を重ね、指標化の方針が決まったところで、いよいよ自動化や見えるかを実装していきます。まず、Google AnalyticsのCore Reporting APIを使って数値を自動的に取得し、スプレッドシートのAPIを使って自動的にレポートを作成する実装を行います。

さらにエキスパートとのコミュニケーションツールをSlackに移行し、執筆陣のモチベーションアップや次回の企画へつながる体制をバージョンアップしていきます。個人的には技術用語などの自動校正ツールとかほしいです。

これらのシステム化の詳細についてのレポートは白石さんにバトンタッチするので、ぜひ再来訪してくださいね！

Firebaseとは

Firebaseはデータストレージ、ユーザー管理などアプリケーションのバックエンドとして必要となる機能をサービスを提供することで、アプリケーション開発者がクライアントサイドの開発に集中できるようにしてくれるBaaS（Backend as a Service）の一種です。

2014年10月にGoogleに買収され、Google Cloud Platform（GCP）の一員となりました。この買収によりGCPにはPaaS（Platform as a Service）としてGoogle App Engine、IaaS（Infrastracture as a Service）としてGoogle Compute Engine、BaaSとしてFirebaseと、いわゆるXaaS系が一通り揃ったことになります。

Firebaseの特徴

Firebaseはもともとは開発者用APIを持つウェブサイトに埋め込み可能なリアルタイムチャットサービスとして始まりました。

しかし、多くのユーザーがチャットサービスとしてではなく、ゲームなどのアプリケーションでリアルタイムにデータを同期するために使用したため、創業者たちはチャットサービスのリアルタイムメッセージングシステムを切り出して別サービスとしました。これが現在のFirebaseの元となっています。

そのため、Firebaseは数あるBaasの中でも特にチャットアプリのようなリアルタイムにデータを同期する必要があるサービスに適しています。

Firebaseの機能

リアルタイムデータベース

FirebaseのデータベースはスキーマレスないわゆるNoSQLで、特定のアプリケーションに関係するデータ全体がひとつのJSONオブジェクトとして保持される点が大きな特徴です。

これによりデータが階層構造をなすため、それぞれのデータが一意のURLを持つことができます。例えばデータベース全体を指すURLは以下のようになります。

• https://アプリケーションID.firebaseio.com/

特定のデータを示すURLは以下のようになります。

• https://アプリケーションID.firebaseio.com/プロパティのパス

例えばアプリケーション名 my-first-chat-app のデータ全体が以下の様であるとして

{
  "messages" : {
    "-K5kPGFquoTbqHYQqBRS" : {
      "body" : "message",
      "name" : "name"
    },
    "-K5kPUqfBfdj4bAa1fyv" : {
      "body" : "message2",
      "name" : "name2"
    },
    "-K5kR-lwtG4I5w9T36Xq" : {
      "body" : "message3",
      "name" : "name3"
    }
}

最初のメッセージ（messages/-K5kPGFquoTbqHYQqBRS）の内容だけを確認したいのであれば、次のURLをブラウザで表示すればいいということになります。

• https://my-first-chat-app.firebaseio.com/messages/-K5kPGFquoTbqHYQqBRS

特定データの表示

認証

Firebaseを使用すると非常に簡単にユーザー認証をアプリケーションに組み込むことができます。組み込みの認証機構としては、メールアドレスとパスワードを使用した認証、OAuthを使用した認証（Facebook, Twitter, GitHub, Google）、匿名ログインがあり、加えてJSON Web Tokens (JWTs)を使用して既存の任意の認証システムと連携することも容易です。

ホスティング

HTML、CSS、JS、画像などの静的なアセットは、Firebaseコマンドラインツールを使用して自身のドメイン上（アプリケーションID.firebaseapp.com）、もしくは有料プランであれば独自ドメイン上に簡単にデプロイすることができます。

さらにデプロイの履歴は管理画面で見ることができ、問題があった場合には以前のバージョンにロールバックすることも可能です。

コマンドラインツール

Firebaseのホスティングサービスを利用するにはFirebaseコマンドラインツールを使用する必要があります。node.jsとnpmがインストールされていればコマンドツールは以下のコマンドで簡単にインストールできます。

$ npm install -g firebase-tools

firebaseコマンドで利用可能なサブコマンドは、以下のとおりです。

firebase init

プロジェクトディレクトリを初期化します。ホスティングサービスに必要なすべての設定は当コマンドによりプロジェクトディレクトリルートに作成されるfirebase.jsonファイルに含まれます

firebase deploy

現在のプロジェクトをサーバーにデプロイします

firebase disable:hosting

ホスティングを無効にし、アクセスに対し”Site Not Found”ページを表示するようにします

firebase login

コマンドラインツールをログインします

firebase logout

コマンドラインツールをログアウトします

firebase list

現在ログイン中のユーザーが利用可能なFirebaseアプリの一覧を表示します

APIとSDK

FirebaseデータベースにはREST APIがあり、さらにそのAPIを利用する各種環境用のクライアントライブラリが標準で用意されています。

• Web（JavaScript）
• iOS（Objective C）
• Android（Java）

なお、これらの標準クライアントライブラリを使用するとFirebaseはオフラインでの動作が保証されます。つまりネットワーク接続がない場合でも、Firebaseデータベースの読み書きの対象を一旦ローカルのキャッシュとすることで、アプリケーションは正常に動作します。その後、接続が復活した時に内容がサーバーと同期されます。

また、標準ライブラリに加えて、REST APIを使用する非公式なライブラリとして以下の様なものもあります。これ以外にもいろいろとありますので、サーバーサイドで自分の好きな言語を利用したい場合はGitHubなどで検索してみるといいでしょう。

• Python-Firebase（Python）
• Firebase-Php（PHP）
• Firebase-Ruby（Ruby）
• BigBertha（Ruby）
• Rest-Firebase（Ruby）

なお、標準クライアントライブラリを使用した場合はオフラインでの動作が保証されますが、非公式ライブラリを使用した場合はその限りではありません。

サンプルアプリケーション

Firebaseを使用した基本的なアプリケーション開発の流れを確認するために簡単なチャットアプリケーションを作成してみましょう。先に紹介したとおりFirebaseクライアントライブラリは環境に応じて複数ありますが、今回はJavaScript版クライアントライブラリを使用してWebアプリケーションを作成します。

サンプルチャット

Firebaseアプリケーション作成

まずはじめに、今回のサンプルから使用するデータベースを用意するため、ウェブコンソールからFirebaseアプリケーションを作成します。http://firebase.com/ を開き、画面右上のログインボタンをクリックしてログインしてください。

アカウントを新たに作成しても構いませんし、GoogleアカウントやGitHubアカウントを使用してログインすることもできます。

Firebaseログイン後

ログイン後、左下の入力エリアにアプリ名とアプリURLを入力して、アプリを作成します。今回は以下の様な設定を使用するものとします。

Firebaseアプリ新規作成

サーバーサイドで行う作業は以上です。これだけでNoSQLデータベースが作成され、クライアントアプリから自由に利用できるようになりました。

サンプルアプリケーションの初期化

サンプルアプリケーションは最終的にFirebaseホスティングサービスを利用するため、まずfirebase initコマンドを実行してプロジェクトディレクトリを初期化します。

% firebase init

? What Firebase do you want to use? my-first-chat-app
? What directory should be the public root? public
✔  Public directory public has been created
Firebase initialized, configuration written to firebase.json

初期化にあたって

1. アプリ名
2. デプロイするファイルを配置するディレクトリ

を聞かれるので、アプリ名は先程作成したものを、ディレクトリ名はデフォルトのpublicを設定してください。

ウェブアプリケーション作成

それではここから実際に冒頭のサンプルアプリケーションを作成していくこととします。といっても必要となるのはHTMLファイルが一つだけ、それも非常に小さなものですので先に全体を見てしまいましょう。

<!DOCTYPE html>
<html lang="ja">
  <head>
    <meta charset="utf-8" />
    <title>Firebaseサンプル1</title>
  </head>
  <body>
    <div>
      <input id="name" placeholder="名前" />
      <input id="message" placeholder="メッセージ" />
      <button id="send">投稿</button>
    </div>
    <ul id="messages">
    </ul>

    <script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.0.0-alpha1/jquery.min.js"></script>
    <script src="https://cdn.firebase.com/js/client/2.3.2/firebase.js"></script>
    <script>
      // データベースの参照を準備
      var firebaseRef = new Firebase("https://my-first-chat-app.firebaseio.com/"); // ... 1
      var messagesRef = firebaseRef.child('messages'); // ... 2

      // 既存メッセージを表示
      messagesRef.on('child_added', function(snapshot) { // ... 3
        var msg = snapshot.val();
        $('<li>').text(msg.name + ': ' + msg.body).prependTo('#messages');
      });

      $('#send').click(function() {
        // 新規メッセージを投稿
        messagesRef.push({ // ... 4
          name: $('#name').val(),
          body: $('#message').val()
        });
      });
    </script>
  </body>
</html>

今回のサンプルアプリケーションのコードはこれだけ、コメントや空行を除けばJavaScript部分はたったの12行です。このコードをローカルに保存し、ブラウザで開いてみてください。HTMLを含めて全体でも40行弱のコードですが、複数ブラウザで開いて、一方でメッセージを入力すればその内容はリアルタイムに他方に反映され、（かろうじて）チャットとして利用できます。

コードの詳細については次回以降に譲りますが、簡単に説明すると、行われている処理は以下のとおりです。

1. アプリケーションURLを引数としてFirebaseオブジェクトをインスタンス化し、前節で作成したFirebaseデータベースに接続するためのオブジェクトを生成します。
2. Firebaseデータベースのmessagesオブジェクトへの参照を取得します。この参照への操作はサーバー上のFirebaseデータベースに保存されることになります。
3. messagesオブジェクトに子ノードが追加された場合のコールバック関数を登録します。今回はコールバック関数内でメッセージの内容をli要素としてul要素に追加しています。なお、onメソッドで登録されたコールバック関数はHTMLの初回読み込み時にも実行されるため、初回読み込み時用の処理を特別に記述する必要はありません。
4. messagesオブジェクトに子ノードを追加します。

オフライン対応の確認

さて、ここで一つ面白い実験をしてみましょう。複数のブラウザでサンプルアプリを開き、使用しているコンピューターのネットワークをOFFにしてください。

そのまま一方の画面でメッセージをいくつか入力すると、メッセージを入力した画面では新しいメッセージがリストに追加されますが、他方の画面にはメッセージが追加されません。

その状態でコンピューターのネットワークをONにするとどうでしょう。少し経って他方の画面にもメッセージが表示されるのが確認できるはずです。

ネットワークが正常

実はFirebaseデータベースの読み書きはいったんローカルDBを経由して行われています。そのためネットワーク接続が不通の場合もローカル側の処理は正常に完了し、ネットワークが回復すると自動的にデータがサーバーと同期されるのです。

ネットワーク異常発生

ネットワーク復旧

これによりアプリケーション開発者はネットワークの状態を一切意識することなくリアルタイムアプリケーションを作成することができます。

リアルタイムに状態を同期する必要がある場合、この機能だけでもFirebaseを採用する価値があるのではないかと私は思うのですが、みなさんはいかがでしょうか？

データベースの内容確認

サンプルアプリにメッセージをいくつか書き込んだらダッシュボードでデータベースがどうなっているか、内容を確認してみましょう。https://アプリケーションID.firebaseio.com/ にアクセスしてみてください。

データベース確認

ちゃんと登録されています。

ちなみにこのダッシュボードから値を変更することもでき、その場合ももちろんクライアント側のイベントハンドラが発火され、ブラウザ側の表示はリアルタイムに変更されます。

デプロイ

最後に、今回のアプリケーションをFirebaseにデプロイして実際に利用できるようにします。firebase initコマンドを実行したディレクトリでfirebase deployコマンドを実行してください。

% firebase deploy

=== Deploying to 'my-first-chat-app'...

i  deploying hosting
i  preparing public directory for upload...
✔  1 files uploaded successfully

✔  Deploy complete!

URL: https://my-first-chat-app.firebaseapp.com/
Dashboard: https://my-first-chat-app.firebaseio.com/

Visit the URL above or run firebase open

では、ブラウザで https://my-first-chat-app.firebaseapp.com/ を開いてみましょう。開発時と同じデータベースを参照しているので先ほど入力したメッセージがここでも表示されています。

ちなみにアプリのドメインは firebaseapp.com で、ダッシュボードのドメインは firebaseio.com です。うっかり打ち間違えないように気をつけましょう。

まとめ

いかがでしょう。Firebaseを使用すれば非常に簡単にリアルタイムアプリケーションが作成できるということが分かっていただけたのではないでしょうか。

今回はFirebaseの全体的な機能の概要を説明しました。次回はもう少し複雑なアプリケーションを作りながら、Firebaseのそれぞれの機能をより詳細に掘り下げていきたいと思います。お楽しみに。