メルカリで重要な役割を果たしている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」グッズがたくさん！

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

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

今回お話を伺ったのは、html5j パフォーマンス部を運営していらっしゃる竹洞 陽一郎さんです。

▲HTML5 Conference 2017セッション風景 （写真提供：html5j　撮影：刑部友康）

竹洞さんのセッション「テクニックではなく、今、本気で取り組むべきWebパフォーマンス」に関するスライド資料は、こちらで公開されています。

民法（債権法）が改正されて、何が変わる？

白石: 民法（債権法）が改正された、ということに注目なさってるそうですね。

竹洞: はい、民法の大規模な改正法案が今年5月に成立しました。3年以内に施行されることになっており、備えが必要です。様々な改正項目がありますが、中でも品質の担保を行う義務が明文化されたことで、ソフトウェア業界にも大きな影響が及ぶものと考えています。

白石: 具体的にはどういうことなのでしょうか？

竹洞: 「瑕疵担保」っていう概念がなくなるんです（参考: 改正民法が成立、「瑕疵担保責任」などシステム開発契約に影響大 (ITpro)。

今までは「瑕疵担保」という概念があったおかげで、とりあえずは品質を担保しない状態で納品を行い、その後の瑕疵期間で問題を修正していく…というのが一般的に行われていました。ですが今後は、納品時に一定の品質を保証することが開発側に求められるようになります。

白石: そのことが、どういう影響をおよぼすと考えられますか？

竹洞: 私としては、ソフトウェア品質が全般的に向上することで、市場が健全化すると考えています。

品質への理解が低い市場は、必ずと言っていいほど衰退するんです。 消費者が品質の善し悪しが判断できない状態だと、価格が一番の判断材料になります。 そうなると結局、品質を犠牲にした価格競争にならざるを得ない。

白石: 「安かろう悪かろう」が当たり前になってしまうわけですね。

竹洞: そう。そういうスパイラルに陥らないためには、品質への意識を高く保つ必要があるんです。

例として適切かはわかりませんが、たとえば麻薬の売人って、品質にものすごく気を使うんです。 質の悪い麻薬が出回るようになると、価格に対する期待と同程度の「ハイ」の状態を得られず、その結果、価格の下落を招き、結局市場が衰退してしまうからです。こうした現象を、アメリカの中古車市場の分析から「情報の非対称性」として研究したジョージ・アカロフ博士は、2001年にノーベル経済学賞を受賞しています。

「品質保証」がウェブ業界を変える

白石: しかし、品質保証が義務付けられるとなると、開発のコストが上がるということになりませんか？

竹洞: それはあり得ます。そのことが、受託開発のビジネスなどをより難しくしてしまうことも考えられます。

例えばウェブ制作会社は、一般的には納品後に入金が入るという仕組みになっていますよね。 だから、まずは品質がそこそこの状態で納品してしまう…ということも起きるわけです。 パフォーマンスはその悪い例で、まずはチューニングしていない状態で納品する。すると、後でパフォーマンス・チューニングの依頼が来てまた売上につながる…なんて事情も実際にはあるわけです。

こうしたこれまでの商慣行が崩れてしまう可能性はありますね。 品質保証が義務付けられるせいで、納品までにより時間がかかるようになるとすると、入金が遅くなるということに繋がる。しかし、民法債権法改正では、部分単位やステージ毎の請負金額の要求ができるようになっています。

白石: それだけ聞くと、受託開発や制作を行っている企業にとっては、ただただ厳しくなるようにも聞こえますね。 そもそも、「品質を保証して納品」ってどういうことなんでしょう？ 完璧なソフトウェアを作らねばならない…なんてそもそも無理だとも思うのですが。

竹洞: その点については安心していいと思います。 「品質を保証する」というのは、「完璧な製品」を意味しているわけじゃないんです。 テスト項目について顧客と合意し、その結果を提出すればいい。実は、ソフトウェア品質には、V&Vといって、Verification(検証)とValidation(妥当性確認)という二つの概念があります。

検証(Verification)とは、仕様・設計・計画などの要求事項を満たしているかどうかの確認です。妥当性確認(Validation)とは、機能や性能が本来意図された用途や目的に適っているか、実用上の有効性があるかの確認です。Webパフォーマンスは、品質においては、妥当性確認にあたります。

従来、ソフトウェア開発における「品質」、特に受託開発においては、検証確認が主体でした。もちろん、応答速度の遅延などで使いものにならないという妥当性確認もあったものの、それはハードウェア性能であったり、データベース設計の問題であったりと、「表示」そのもののロジックに原因はあまりなかったのです。

要求仕様の実現という意味での検証については、仰るとおり「完璧な製品」というのは、ほぼ存在し得ない。それは、ソフトウェアが、論理記述であって、物理法則の縛りがなく、かつ、連続性の保証がないためです。

連続性の保証とは、物理法則であれば、100Kgの重さまで耐えられるテーブルであれば、当然ながら、80Kgや10Kgなど、100Kg以下の重量に耐えられることです。しかし、ソフトウェアは二値論理がベースであるために、100という値で大丈夫であっても、80や10という値で大丈夫であるという保証がない世界です。

2002年に亡くなられた、オランダの著名な計算機科学者で、構造化プログラミングの提唱者でチューリング賞を受賞しているエドガー・ダイクストラ博士が「テストは誤謬を見つけることはできるが、それがないことを証明することはできない」と指摘しています。

ですから、バグや欠陥がないことを保証するというのは無理なんです。

白石: なるほど、それなら少し安心です。バグや欠陥のないソフトウェアなんて不可能ですし。

竹洞: 品質についても顧客との合意内容に盛り込む必要が生じる、ってことですよね。 そうした合意があるのとないのとでは、品質に対する意識が全然違ってきます。品質については、検証として従来もやってきたことです。ところが、WebがソフトウェアのUIの主体となることによって、今まで問題にならなかった「表示」に関するロジックが突如、問題となり始めた。突如といっても、もう20年ぐらいになるわけですが…

その部分は、検証ではなくて、妥当性確認なんですが、妥当性確認のテストのノウハウが日本では普及していなかった。今、そこが問われているわけです。

白石: なるほど。「完璧な製品を作る」ことが品質保証なのではなく、「妥当性品質に対してどこまで保証するかを明確にする」ということなんですね。

竹洞: そうです。そうして、妥当性品質についての期待値を高く保つことは、Webに関する業界として必要なことだと思いますよ。

例えば日本の住宅市場は、品質保証がうまくいっていない例だと思うんです。 日本の住宅って、非常に寿命が短いじゃないですか。その理由は様々ですが、一つに中古住宅に対する品質の期待値が低いことがあると思っています。 品質保証がない空き家を買うくらいなら、新築のほうがいいって心理です。

白石: 確かにそういう一面はある気がしますね。ぼくは安さに釣られて中古住宅を買ったクチですが(笑)、一生住めるなんて少しも期待してませんし。

竹洞: それって、結局その家はいつか捨てることになるってことで、財の蓄積が進んでいないとも言えると思うんです。 社会的に見ると、将来世代に引き継ぐ財が形成されていないとも言える。財の蓄積が期待できないと、そこの投資は進まない。お金が集まってこないのです。

ウェブのように技術がどんどん進歩していく世界に財の蓄積は有り得るのか？システム構築費用は5年で償却されるのであれば、5年持てばいいじゃないか？という考えられるのは、仰るとおりです。

しかし、プレゼンテーションとしてのUIデザインと、データとしてのコンテンツやユーザのデータは分けて考えるべきで、だからこそ、HTMLとCSS、JavaScriptで役割分担をしているわけじゃないですか。システムの永続性というものを考慮してWebサイトの設計を行うことは非常に重要なのです。

減価償却期間の5年も持たない、3年程度で捨てざるを得ないとなれば、企業財務的にはそこはできるだけ安く済ませるべきなのです。しかし、品質が保証されて、減価償却の5年を超えて使えるとなると、将来価値が上がる。企業財務的にはおいしいお話なのです。そこに気付いてほしい。メンテナンス費用は当然発生するでしょうけど、新規で作るより安いですし、何より「継承」できることが大きなメリットなんです。

UIデザインや技術力だけで勝負しているWeb制作会社さんは、その点に、早く気づかれた方が良いと思います。お金を握っている経営者や財務担当者は、別のロジックで判断しているわけですから。

ですから、ウェブサイトも、いつか捨てるものとなれば、そこに予算を掛けようとは思わない。品質が保証されないのであれば、なおさらのことです。

「お客様からあまり予算をいただけない」と嘆くことがあるかと思いますが、その背景には、品質が保証されていないので修正するより作り直した方がいいと考えられていること、いつかWebサイトは捨てて新しく作るものと考えられている背景は認識しておくべきだと思います。

ウェブサイトの品質を決める3つの要素

白石: では具体的に、ウェブサイトにおける品質を保証するというのは、何をすればいいんでしょうか？

竹洞: ウェブサイトの品質は主に3つの要素から成っていると言っていいでしょう。

一つはアクセシビリティ。 一つはセキュリティ。 最後がパフォーマンスです。

Webサイトの三大品質

これらはそれぞれJISで規定されてもいる重要な指標です。これらをしっかり担保していく体制づくり、それがウェブサイトの品質保証に繋がります。

白石: ウェブサイト制作にも、これらを担保するワークフローを確立していくべきということですね。

竹洞: そうです。そしてこれらは、運用と一体になって改善していくべきものでもありますので、DevOpsの観点から考えるのも重要です。

ただ一つ不思議なのが、日本でDevOpsに関して述べている文献や書籍って、ほとんどの場合品質保証のことが抜けてしまっているんですよね。 品質に対する意識が高まらない原因は、こういうところにもあると思います。

DevOps

ウェブサイトの品質を高めるための心構え

白石: 品質を向上させるためのコストが低く見積もられがちというところもあるんでしょうか。

竹洞: というよりは、そのコストが認識されていないというのが正しい気がします。 「品質、費用、期間の3要素を同時に満たすことはできず、トレードオフの関係にある」といった、プロジェクトマネジメントやソフトウェア開発見積りの基本もあまり浸透していない感覚がある。

白石: なるほど。当たり前の話ですが、品質を高めようとすれば、時間的、金銭的なコストを支払う必要があるということですね。

竹洞: はい。そして品質保証が当たり前になれば、品質保証のためのコストがかかるのも当たり前になる。今は、その当たり前のコストを払っていないだけとも言えるのです。

白石: では、そうした品質保証、特にパフォーマンスについて、状況を改善していくにはどんな知識が必要になるんでしょう？

竹洞: そうですね、小手先のテクニックはたくさんありますし、いろんなところで語られてもいますので、もう少し根源的なところから考えると、結局「基礎」と「長期的な視野」が重要になると思うんです。

基礎というのは、コンピューターやネットワークに関する基本的な知識。 長期的な視野と言うのは、数年後にインターネットがどうなっているか、といった話です。

白石: なるほど。

竹洞: 例えば、パフォーマンスに関する話を突き詰めていくと、意外なほどハードウェアに関する知識って大事なんです。 パフォーマンスって、最終的には絶対にハードウェアに依存するわけですからね。

例えば、とある大規模サイトで遅延が発生していたんですが、その原因を追求するのすごく大変だったんです。 アプリケーションをいくら調べても、データベースのクエリをいくら見直しても、ネットワークの状態を見ても、原因がわからなかった。

白石: 結局、どんな原因だったんですか？

竹洞: そのサーバはVMWareで仮想化されていて、サーバ負荷に応じてCPUリソースが動的に割り当てられるようになっていました。ただ、あらかじめ割り当てられているCPUリソースが足りなかったせいで、CPUの動的割り当てが頻繁に発生してしまっていたんです。 その割り当てが行われる際に、サーバの処理が遅延してしまっていたんですね。

白石: それは深い原因ですね…

竹洞: ここまで奥深くに原因がある場合って、ハードウェアを含めたアーキテクチャ全般の知識が必要になります。 だから結局、コンピューター全般の知識って必要だなと。だから私の会社では、入社したら最初の一歩として、まずPCを自作してもらうようにしています(笑)。

全てを変える、5Gネットワーク

白石: 数年後にインターネットがどうなっているか、というお話も聞かせていただけますか？

竹洞: はい、具体的には5Gネットワークの話になりますね。5Gはアプリケーションの作り方を含め、全てを変える可能性がある技術だと思っています。

白石: 5Gネットワークって全然知らないのですが、どんな感じなんでしょう？

竹洞: 大きく3つのトピックがあると考えています。

一つはネットワークスライス。インターネットを「輪切り」にするイメージで、用途に応じて別々のネットワークを提供していくようになります。

電波には周波数によって特性があり、サービスの特性に応じて周波数を割り当てて異なるネットワークを構成できるので、ネットワーク全体の利用効率が大きく向上すると考えられています。

ネットワークスライス

次に指向性アンテナです。今までは、基地局といういわば「傘」を中心として、そこから広がるように無線ネットワークが構築されていました。

しかしこれからは、パネル型のアンテナがビルの壁面に貼られるようになり、そこから端末と直接「ビーム」をやり取りするように通信を行います。通信の受信強度が高まるだけでなく、他の電波との干渉も減らせます。

指向性アンテナ

最後にモバイル・エッジ・コンピューティングです。これは、4Gですと、地域の基地局をまとめているRNC(Radio Network Controller)配下に、仮想サーバー（エッジサーバー）を設置できるようになるのです。 今まで携帯の会社はコアネットワークを公開していなかったので、これは大きな変化です。

モバイルエッジコンピューティング

これは分散コンピューティングの新たな可能性を示しているといえます。インターネットより手前でトラフィックを捌けるわけですから、サーバーの応答性も大きく向上します。

白石: へえ、知りませんでした！世界中のエッジサーバー上に、静的リソースのキャッシュを置けたりしたら、すごく速くなりそうですね。

竹洞: それだけではありません。エッジサーバーで可能な限り処理を行い、必要な処理だけインターネット上のサーバーに送るようにすることもできます。アプリケーションの処理を、エッジサーバーとインターネット上のサーバーで分担するというわけです。

もしくは、全てエッジサーバー上で処理を行うような、非インターネットのローカルなサービスを行うことも可能です。

白石: そうなると、アプリケーションの作り方も大きく変わってきそうですね。夢が拡がりますね…。5Gネットワークって、具体的にはいつ頃普及が見込まれているのでしょうか？

竹洞: 2020年の東京オリンピックまでには使えるようになるだろうと言われています。

10月12日に、NTTドコモ、富士通、富士通研究所がモバイル・エッジ・コンピューティングを使った高画質動画配信や映像解析を活用した人物検知システムの実証実験を行って成功した旨のプレスリリースを発表してています。

また10月13日には三菱商事が、この分野のリーディングカンパニーであるJIG-SAWと、モバイル・エッジ・コンピューティングの実証実験成功のプレスリリースを発表しています。

白石: ワクワクしますね。本日は民法から5Gネットワークまで、幅広いお話を聞かせていただき、ありがとうございました！

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

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

今回お話を伺ったのは、株式会社ACCESSの梅田雅士さんです。

梅田さんのセッション「TV・車・ゲームに搭載されているブラウザってどうなってるの？」に関するスライド資料は、こちらで公開されています。

組み込みブラウザって…なに？

白石:では、まずは簡単に自己紹介をお願いできますか？

梅田:株式会社ACCESS IoT事業本部課長の梅田 雅士です。 もともとはエンジニアでして、ブラウザ開発からWebサービスまで、組み込みからフロントエンドまで開発していました。

白石:すごく幅広い経歴をお持ちですね！今回はPCやスマートフォン「以外」の環境におけるブラウザのお話を伺えると聞いています。

梅田:はい、今やブラウザはテレビにも、自動車にも、ゲームにも搭載されています。それらを総じて「組み込みブラウザ」と呼んでいます。

白石:組み込みブラウザと言うのは、PCやスマートフォンのブラウザとどう違うんでしょうか？

梅田:Webを閲覧できると言うのは、ブラウザの基本的な機能ですので、組み込みブラウザであっても変わりません。違うのはまず動作環境ですね。例えばOSも、LinuxからiTronまで、様々な環境があります。中にはタッチ操作やマウス操作が存在しない環境でも動作することが求められることもあります。

白石:ACCESSさんの組み込みブラウザは、今は主にChromiumやWebKitをベースにして開発してらっしゃるんですよね。組み込み向けに機能を追加したり、ということもあるんでしょうか？

梅田:はい、例えばテレビのリモコンとか、ゲームのコントローラーとかでブラウジングを可能にすると言った機能の追加は一般的にありますね。ブラウザの操作に関しては、「組み込みならでは」という部分は多いです。

テレビとブラウザ

白石:では、テレビ、クルマ、ゲームに搭載されているブラウザの状況について、詳しく教えてください。

梅田:ではテレビからいきましょう。実はテレビには昔から身近にありまして、テレビのdボタンを押して立ち上がる画面は、実はブラウザなんです。

白石:dボタンはブラウザ起動ボタンでもあったわけですね。

梅田:はい、それにテレビのメニュー選択を行うアプリもHTMLで書かれていたりしますね。

白石: ハイブリッドキャストと言うのは何でしょうか？

梅田:テレビ向けのブラウザでは、以前はBML (Bloadcast Markup Language)という、XHTMLベースの独自言語が利用されていました。ですが現在では、HTML5をベースとしたテレビ用の規格がありまして、それが「ハイブリッドキャスト」です。

ハイブリッドキャストは「放送と通信の連携」を目的として、NHKさんを中心とした標準化が行われています。単にHTML5が使えると言うだけではなく、スマートフォンとの連携（セカンドスクリーン）機能なども備えています。

白石:民放局の、ハイブリッドキャストへの対応度合いとかはいかがですか？

梅田:各社とも、現在対応を拡充している段階ですね。2020年の東京オリンピックで、テレビ放送をより楽しく観せるのが、各社共通の目標になっています。

白石:ちなみに昔聞いた話なのですが、テレビって意外にも低スペックで、重たいWebページを表示させるのは難しいと聞いたことがあります。その状況は現在では変わりましたか？

梅田:いえ、あまり変わりないです。テレビの中で一番高価な部品はやはりパネル。その他の部品、例えばCPUなどは、やはり廉価なものが使われることが多いんですね。なのでテレビ向けのWebページは、軽量であることが望まれます。

車とブラウザ

白石:では次は車とブラウザの関係について教えてください。

梅田:自動車業界では、カーナビを中心とした、操作可能な中央のスクリーンを「HMI (Human Machine Interface)」と呼びます。HMIでブラウザを利用できると、例えば自動車のマニュアルをHTMLで書いたりできます。HTMLは多言語化しやすいのでメリットは大きいですね。

あとは車載システムにアプリを追加することができるものもあります。インターネットと繋がって、例えば天気を表示したり、運転を楽しくするようなアプリがインストールできたりします。車載システムは「情報（インフォメーション）」と「娯楽（エンターテインメント）」を提供するという概念から、「インフォテインメント」とか、「IVI（In-Vehicle Infotainment：車載インフォテインメント）」と呼ばれたりします。HMIでブラウザが利用できるなら、そうしたアプリもWeb技術で開発できるようになります。

白石:車載システムにブラウザを搭載するという動きは、どれくらい進んでいるものなんでしょうか？

梅田:海外では結構進んでいます。車載システムのOSは共通化が進みつつあって、主要なものとしてはAGL (Automotive Grade Linux)やGENIVIがありますが、これらには今後ブラウザが搭載される予定があります。

ちなみにAGLって、Tizen IVIが元になっているんですよ。Tizenは一時期HTML5にも注力していましたので、白石さんはご存知じゃないかと思いますが。

白石:ええっ！Tizenって久しぶりに聞いた名前です。そうだったのか…そういう風に受け継がれていたんですね。IT業界って、思わぬところが繋がってたりするので面白い(笑)

ところでそういう車載システムとかだと、テスラの車とかは進んでるイメージありますけど、実際のところどうなんでしょう？

梅田:確かにテスラは進んでいて、WebKitを搭載した車載システムを既に積んでいますね。ただ、古いバージョンのWebKitを搭載していたため、そのセキュリティホールを突かれてハッキングが可能な状態になっていたことがあったりします。車載システムの高度化に伴って、セキュリティリスクも高まりつつあるというのが実情です。

ゲームとブラウザ

白石:ゲーム機にブラウザが搭載されているという点についてはいかがでしょう？

梅田:実は、ゲーム機にブラウザが搭載されているのは結構昔からなんです。2003年に発売されたPlayStation 2や、2004年に発売されたPlayStation Portableには、もう入っていましたからね。

白石:そんなに昔から入っていたんですね。そう言えば、ガラケーとかにもブラウザ積まれてたし、そう言えば組み込みブラウザって結構昔からあったんですよね。

梅田:そうですね。それに、ゲームソフト自体にブラウザが積まれていたこともありましたよ。

白石:ええっ！ゲームソフトがブラウザを内蔵していたんですか？

梅田:そうです。例えばモンスターハンター3には、弊社のNetFrontというブラウザが内蔵されていました。

白石:ゲームソフトにブラウザが入ってるなんて、考えたこともありませんでした。すごい世界だ。

ブラウザ開発ってどんな仕事？

白石:そもそもブラウザ作ってる会社ってあまりないですよね。そこら辺の実際をお聞きしてみたいです。ブラウザ開発って、どのように進めるものなんですか？

梅田:基本的には、W3Cの仕様を満たすように実装するというのがブラウザ開発の中心になります。ただ、今はオープンソースのブラウザをベースに開発していますので、少し仕事の範囲が変わりましたね。W3Cの仕様を満たすために開発するのは、主にChromiumやWebKitのコアチームに任せて、私たちはその移植が中心になりました。

白石:なるほど、今はブラウザエンジンそのものの開発に深く食い込んでいるわけではないと。

梅田:ただ、弊社ではEPUBのエンジンも作っていまして、そのために独自開発した部分とかは結構ありますね。例えば縦書きレイアウトとかは、W3Cに提案されている仕様を元に弊社で開発したコードを、ブラウザエンジン側にコントリビュートしたりもしています。

白石:ちなみにブラウザ開発って、どんな言語を使って行うんですか？

梅田:WebKitやChromiumはC++で書かれているので、C++ですね。C++ってメモリマネジメントが重要な言語ですが、WebKitとかってそこら辺が少しいいかげんだったりするんです(笑)。

白石:え、そうなんですか？メモリリークしたり、とかですか？

梅田:さすがに派手なメモリリークとかはめったにありませんが、メモリ確保に失敗した時の処理が甘かったり、とかですね。で、車載システムとかで利用する場合って、「動かない」って状況になるのはすごくまずいわけです。運転中は安全がなにより最優先ですから。そういう穴を潰して本家にコントリビュートする…というのもたまにありますね。

組み込みブラウザベンダーはつらいよ

白石:ACCESSさんはブラウザと言っても、更に「組み込みブラウザ」を作っているという数少ない存在。そういう、数少ない組み込みブラウザベンダーならではの苦労などをお聞きしたいです。

梅田:そうですね、まず先ほども申し上げたように、現在はChromiumやWebKitをベースに開発しています。以前は独自のブラウザエンジンでしたが、数年前にWebKitに切り替えたんです。ただ、WebKitはそもそも組み込み用途が主ではありませんでしたから、当初はハードのスペック的な制約との折り合いを付けるのが大変でしたね。（Webページが）メモリに乗り切らないので、数キロバイト単位に分割してメモリに載せるようにしたり…

白石:うわー、それは大変そう…。

梅田:最近はハードのスペックが向上したので、そういう苦労をすることも少なくはなってきましたけどね。あとは、レンダリングのパフォーマンスを改善するのも大変ですね。車載システムだと、最低でも60fpsは要求されるので、動画のデコードをハードウェアに行わせるようにするとか、CanvasをGPUレンダリングするとか。スクロールが滑らかになるようチューニングするのも大変でした。

白石:WebKitとChromiumは使い分けてるんですか？

梅田:お客様からのご要望や、用途に応じて使い分けています。WebKitはリリースサイクルがだいたい年一回で安定していますが、Chromiumのリリースサイクルはもっと速くて、コードもどんどん変化していきます。どちらがいいということでもなくて、それぞれにメリットがありますね。

白石:大変興味深いお話です。組み込む製品ごとに異なる苦労とかはあったりするんですか？

梅田: 車の場合とかは、製品の開発サイクルが長いのが特徴です。一つの車を作るのに5年とかかかったりすることもあるので、何回もつなぎ込みが発生するわけです。

白石:5年！Webの世界で5年と言ったら、状況はかなり変わってしまいますよね。

梅田:そうですね。ベースになっているブラウザもどんどん進化していくので、つなぎ込みを行うたびに、できるだけ最新に近づけていくようにするんです。その際に、ブラウザエンジンが持つAPIが変わってしまうことも珍しくありません。そういう事態に対応しやすいように、APIを抽象化したレイヤーを持っていたりします。

白石:いやー、ぼくみたいなフロントエンドエンジニアが全然体験したことのない苦労だ(笑)

梅田:他には、ブラウザの機能を拡張しなくてはならないこともよくあります。組み込みの場合って、HTML5が元々持っている機能だけじゃ足りないことが多いんですよ。

ゲームの場合は、ゲーム機というハードに閉じているからか、独自に拡張することが多いのが特徴です。

車載の場合は、Vehicle APIっていうAPIがW3Cで標準化されていますので、その実装を行うのも仕事の一つです。このAPIを使うと、例えばキーロックの情報を取れたりと、車載システムならではの機能を利用することができます。

PCやスマホ「じゃない」Webアプリ開発とは

白石:では最後に、PCやスマホじゃない世界でのWebアプリ開発について、どのようなものかお聞かせください。

梅田:基本的には、それほど変わるところはありません。組み込みブラウザと言っても結局WebKitやChromiumをベースとしていますし、HTML5以降はブラウザ間の互換性も高くなっていますし。

ただ、市場によって制約はありますね。例えば車載システムで動作する場合は、運転手の気を逸らさないようUIガイドラインがあったりします。

一方で、市場ごとに特有の拡張機能を使うことも求められます。

白石:先ほどおっしゃっていた、車載システム上で使えるVehicle APIなどですね。

梅田:そうです。そして、そうした標準化されたAPIと言うのは、組み込みの世界で特に重要なんです。

基本的にオープンなPC/スマホに比べて、組み込みは市場に特化しがちな世界でもあります。クローズドな世界で、クローズドな技術を使っているのでは、スキル的にもビジネス的にも拡がりにくい。

オープンで標準化されたAPIを使うことで、そうした事態を避けることができる。Web技術者も、活躍できる場がどんどん広がっていきます。

白石:なるほど。ちなみに、車載の世界とかでは、App Storeのようなアプリプラットフォームが出てくる可能性はあるのでしょうか？そして、Webで作ったアプリであればそれらのプラットフォームにどこでもデプロイできるというような可能性はありますか？

梅田:はい、そういう可能性はもちろんあります。アプリプラットフォームみたいな構想は各社持っていて、今後登場してくるのは間違いありません。 その時に、Web技術を使ってアプリを開発できる可能性も、それが複数のプラットフォームで展開できる可能性も、大いにあると思います。

そうした世界を見据えて、総務省さんと一緒に「Webとクルマのハッカソン」というイベントをここ数年開催しています。10月下旬から申し込み開始ですので、興味のある方にはどんどん参加してほしいですね。

白石:あ、そのイベント去年ぼくが審査員やったやつだ(笑)。去年もすごく盛り上がりましたよね。本日は組み込みブラウザ開発の話、そしてPC/スマホ以外のWeb開発の話など、普段あまり聞けないお話をお聞かせいただき、ありがとうございました！

LINEのニュースタブをReact.jsで開発しているフロントエンド、JavaとPerlで開発しているサーバーサイドのエンジニアの方々に、どんな開発技術や体制で開発しているのか、HTML5 Experts.jp白石俊平編集長が直撃インタビューしてきました！

今回お話を聞いた「LINE NEWS」開発チームの皆さん

LINE株式会社 前澤 春樹さん
Javaのサーバーサイド担当。200以上の媒体社様向け管理画面のコンテンツ入稿システム開発や、公式アカウントから発信されるメッセージ配信システムが主な担当。

LINE株式会社 森藤 賢司さん
Perlで作られている一般ユーザーから見えるニュースタブ、記事ページのバックエンドや社内向けの管理画面を担当。

LINE株式会社 大槻 友諒さん
フロントエンドエンジニア。WebViewでつくられているニュースタブの実装を担当している。React.jsなどの最新技術に触れることも多い。

LINE株式会社 富田 梓さん
マークアップエンジニア。デザイナーの作成したPSDをもとにしたCSSの設計と実装を行う。ニュースタブの他、PC/SPのWeb、キャンペーンページなどニュース関連全般を担当。

なぜ、ニュースタブはWebViewなの？

白石：今日は主にニュースタブにフォーカスしてお話を聞いていきますね。LINEのニュースタブは、なぜWebViewを使ったのでしょうか。

大槻：もともと記事ページはWebViewで作っていました。ニュースタブを作ろうという話になったときに、記事ページと同じ技術で作るほうが開発スピードも早いし、やりやすい。バージョンアップなども、そろえたほうがリリースしやすいということでWebViewで作ることになりました。

白石：じゃあ、ニュースタブ以外はネイティブでできているんですね。

大槻：そうです。トークやタイムラインなど、メインの機能はネイティブで実装されています。並んでるタブの中だと、ニュースタブだけがWebViewです。

白石：WebViewとネイティブといった複数の技術を混ぜるのって、大変だったんじゃないでしょうか。

大槻：ネイティブとWebView間でデータやイベントをやり取りする必要があって、そのための仕組みをアプリエンジニアと協力して実現しました。ユーザーにはLINEアプリの一部として見えるので、挙動やパフォーマンスに違和感が出ないようにするのが大変でした。

白石：WebViewだと、読み込みや表示が遅かったりしません？

大槻：いえ、結果的にそこまで遅いということはなかったです。Webだからの限界はありましたけど、WebViewだから特別つらいことはありませんでした。

LINEバイトやLINEギフトといったファミリーアプリにはすでにWebViewの技術が使われていて、知見があったことも役立ったんだと思います。

白石：React.jsを使っているとのことですが、SPA的な開発だとマークアップはそんなに必要じゃないと思うんですが、両方必要なのはどうしてなんでしょう。

富田：うちは分業体制をとっていて、僕と大槻さんが所属しているチームはフロントエンドを担当しています。案件によってJSとマークアップの両方を一人が担当することもありますが、newsでは規模の大きさもあって担当が分かれています。

デザインからHTMLを起こして、それを渡しているので、一般的に言われているReactを使うイメージとはちょっと違うかもしれません。

大槻：セマンティックなHTMLを書くとか、CSSを設計するといったところは完全にお任せしてします。一回組んだものを、パーツとして分解してJSXに落とし込んでいます。

白石：PCでも記事ページそのものは見られるんでしたっけ？

富田：記事ページは見られます。

白石：あ、レスポンシブ対応しているんですね。

富田：いえ、レスポンシブとかではなくて、PC専用に作っています。SNSなどでシェアされたURLはPCからでもアクセスできるため、PC用の記事ページを用意しています。

JavaとPerlでサーバー管理

白石：サーバーサイドでJavaとPerlという複数言語を使っているのはなぜですか？

森藤：もともとPerlで全体が作られていたのですが、社内の方針で最近はJavaで作ろうという流れになってきています。なので、最近のレポジトリとかはJavaで作ってます。まあ、歴史的背景です(笑)。

Perlはニュースタブと記事ページ、あと社内向けのCMSもPerlで作られています。

白石：へえ！CMSは自作なんですね。ちなみに、ReactはAPIを出すのに使ってるんですか？

森藤：はい、ニュースタブの部分は、全てAPIで実装されています。

白石：Reactでサーバーサイドレンダリングしているのでしょうか。

大槻：いえ、クライアント側でレンダリングしています。

APIでとってきたデータをローカルストレージにのせておいて、ネットワークがないところでも画面が真っ白にならないように工夫しています。

白石：JavaとPerlで分かれていますけど、システム間連携しているんですか？

森藤：データベースで連携しています。データベースはMySQLを使っています。

白石：MySQLをクラウド上で？

森藤：いえ、オンプレです。本番環境は、現在ほとんどオンプレのサーバーで動いていますが、最近構築したサーバーや開発環境はプライベートクラウドの「Verda」というサービスを使っています。

白石：えっ、どこかの製品を買うのではなく、自分たちで作ってるんですか。かっこいいですね。

森藤：DB周りはDBA（データベース管理者）のチームが運用しています。DBサーバーの構成は、マスター1台に参照やバックアップに使うスレーブが数台ある感じです。テキストで入稿するデータなので、データ容量が一気に増えて困ったとか、容量が足りなくなったという話も聞いたことがないですね。

白石：Javaで入稿システムを作っていらっしゃるんですよね。ScalaやKotlinなんかも使っているんでしょうか？

前澤：Javaだけです。最近のモダンな言語に比べると、やっぱりJavaは冗長というかすごいコード量を書かないといけないのは大変なんですが…。

白石：ぼくは昔Javaエンジニアだったのですごく気になるんですが、Javaのバージョンは何ですか？

前澤：Java 8です。

大槻：僕も前職では、エンタープライズ系のサービスをJavaで書いていました。その時はバージョンが古くて4でした。あと8をちょっと触ったくらい。当時はジェネリクスもアノテーションもなくて(笑)。

白石：僕はXML地獄でしたね(笑)。EclipseみたいなIDEとかは使ってますか？

前澤：Eclipseは使ってなくて、IntelliJ IDEAを使ってます。

React.jsを選択した背景は？

白石：フロントエンドのReact.jsはいつから使ってるんですか？

大槻：ニュースタブができてからなので、2017年2月からですね。

白石：苦労したこととかありますか？

大槻：React.jsだから苦労したことは特になかったんですが、どのライブラリにするかは結構検証しました。Vue.jsやRiot.jsなんかもいろいろ試してみたのですが、結局React.jsにしました。

Create React Appでベースを立ち上げた経緯もあって、最初の環境を整えるのはすごくスムーズでした。React.jsは結構書きやすくて、世の中で使われているアプリも多く、バージョンアップも早いし、安定していて信頼できました。

白石：なるほど。stateの管理とか、Reduxは使ってますか？

大槻：Reduxは最初は使おうと思ったのですが、意外と過剰なスペックがあってやめました。代わりにFlux Utilsを使っています。

足りない開発ツールはどんどん作る

白石：ほかにLINEさん独自の開発手法があれば教えてください。

大槻：フロントのアクセス解析はGoogle アナリティクスを使っているんですが、そのほかに社内で開発した「LINE Analytics」という解析ツールを使っています。JavaScriptのエラー部分もリアルタイムに収集できるので、リリース直後に増減を確認したりしています。

白石：LINEさんは結構社内で作る文化があるんですね。自分たちでも作るというのは、意思決定が必要だと思うんですが、どんなかんじで決めているんですか？

富田：その辺は結構自由にやらせてもらえる風土ですね。プロジェクトで使うツールだけでなく、たとえばメーラーやスケジュール管理といった社内システムについて内製する部署があります。既製品でもの足りなかったら、自分たちで作っちゃおうみたいな。

大槻：分業しているのでサーバーに触れること自体は少ないんですが、JSやCSSの配信ツールをフロントエンドチーム内で開発したりと、役割内で足りないものは作って配布させたりする人が多いですね。

サーバー側はCIも自前で作ってると聞きました。社内の承認フローがそれほどかたくないので、わりと気軽に自前で作ってます。

白石：CIもですか！Jenkinsとかを使わずに？

前澤：Perlでは内製のCIを使っていますが、JavaではJenkinsを使ってビルドしていて、ビルドした成果物をサーバーに配布するシステムは内製です。CDNのオリジンサーバーも自作してますね。

秒間2万のアクセスを捌くパフォーマンス

白石：パフォーマンスなんかもかなり気をつかっているんじゃないでしょうか。

森藤：はい。APIアクセスが秒間2万くらいのアクセスがあるので試行錯誤しています。APPサーバーの台数は約30台くらいなんですが。

森藤：去年の6月に高速化プロジェクトがあって、CDNを追加しました。CDNはAkamaiを使っています。クエリーをちゃんと書いてなかったりするとサービスが止まるので、SQLには気をつけてキャッシュに貯めるようにしていますね。

白石：フロントエンドのパフォーマンスで工夫した点はどうですか？

大槻：ニュースタブは縦に長いんですけど、DOMが増え過ぎるとメモリを食ってアプリがクラッシュしてしまう問題がありました。

iPhoneでは横スワイプでタブ移動できるので、左右のタブを予め描画している分よりDOMが多く、見えないDOMをいかに削除していくかなどの工夫をしています。

タスク管理・チーム間の共有ツールは？

白石：皆さんは所属する組織は違うとのことですが、「LINE NEWS」プロジェクトのタスク管理やチーム間の共有ツールはどうしていますか。

富田：ニュースチームのプロジェクトとして定例ミーティングをして、進捗管理しています。管理に使っているツールはJIRAですね。

白石：進め方はアジャイルですか？

富田：そんなにアジャイルぽくはないです。企画チームが20人くらいいて、案件ベースを作ってくれるので、早い段階で開発からもフィードバックしたり、企画と一緒に練ったりします。1週間のスプリント制でやっています。

白石：ニュースチームは全体で何人くらいいらっしゃるんですか？

前澤：企画や開発、制作、編集、アライアンス、モニタリング、PR・マーケティングなどを含めると、プロジェクトに関わっている人は100人を超えています。エンジニアは現在、バックエンドが8人、フロントエンドが4人です。

白石：大型プロジェクトですね。CIは自作されてるとのことでしたけど、DevOpsみたいな工夫ポイントはありますか？

前澤：これまでは五月雨で流動的だったけど、人が増えてきたので週1回のサイクルを整えたり、模索しているところです。

白石：ソースコードの管理やリリースのルールとかはどうでしょう。

森藤：ソースコードの管理はGitHubです。Perl側は最低2人レビュアーがいないとリリースやマージしちゃいけないことになっています。

急成長するサービスと開発体制に合った環境を構築

白石：最後に今後こうしたいという抱負や、チャレンジしたい目標を教えてください。

前澤：LINEのサービスが急速に成長して、エンジニアも増えているので、開発時期によってリポジトリやフレームワークの使い方も違ってきています。それを統一したいと思っているんですけど、結構大変そうです(笑)。

森藤：これまでのサーバーサイドはほとんどPerlだったんですけど、ここ数年みんなJavaを書くようになって、Perlを書くエンジニアが減ってきているんです。サーバー側をもっとJavaに置き換えていけたらと思ってます。

大槻：TypeScriptを導入も検討していきたいです。依存するライブラリの都合もあって、簡単ではないかもしれませんが。

富田：ニュースのプロジェクトが始まったのが2013年で、最近では更新が滞っているruby-sassやgrunt、compassといった古い環境に依存しており、日々の更新に忙しくてそういった根幹部分はなかなか手を入れることが難しかったんですが、最近のリリースで、タスクランナーに依存したコンパイルをやめたり、node-sassへの移行したりしました。

それに伴ってチームで使っている社内用のツールやsassのライブラリを更新しているので、今後も新しい技術についてそれらに生かせるか検証しつつ対応できればと思っています。

白石：LINEさんは独自の開発ツールをどんどんつくっていく行動力と技術力が素晴らしいですね。今日はいろいろ面白い話をありがとうございました！

LINEさんでは、9月28日(木) にエンジニア向け技術カンファレンス「LINE DEVELOPER DAY 2017」を開催するそうです。LINEの様々なサービスにおける技術領域でのチャレンジや開発体制などについて語られるとのことなので、興味のある方はぜひ参加してみてください。

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

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

今回お話を伺ったのは、ヤフー株式会社にお勤めの大津繁樹さんと新部長則さんです。

▲左から、ヤフー株式会社 大津繁樹さん、新部長則さん

お二人のセッションは「大規模運用で見えるWebプロトコルの理想と現実、そして今後」（ルームB 13:20-14:00）です。 （現在HTML5 Conferenceは定員オーバーの状態ですが、無料イベントということもあってキャンセルも多めに出るらしいので、諦めずにキャンセル待ちすることをお勧めします！）

日本最大級のHTTPS & HTTP/2化案件の実際

白石: まず簡単な自己紹介からお願いできますでしょうか？

新部: 私は2005年の7月に入社し、Yahoo!メールや広告の画像配信を行うCDNの運用などを経て、現在は全社で利用しているリバースプロキシの運用を行っています。 現在、社内でプラットフォームと呼ばれる部分にはだいたい関わっている感じですね。

大津: まさに、新部さんのチームは、ヤフーのトラフィックをほとんど全て受け止めていると言って間違いありません。国内最大級のトラフィックを支えているんです、半端ないですよ。

白石: では大津さんも自己紹介をお願いできますか？

大津: 私は昨年の10月に入社したばかりです。大きく2つの仕事をしていまして、Node.jsのコミッターとして社内のサポートを行っているのと、IETFでネットワークプロトコルの標準化活動に関わっています。

白石: ありがとうございます。では、ヤフーのサービスをHTTPS + HTTP/2化した際のことを伺ってもいいですか？

新部: まずはヤフーのサービスをHTTPSに移行するところから始めたんです。HTTPS化に伴うコストや影響の試算を踏まえて、2015年10月に、全社横断でHTTPS化するプロジェクトが発足したんです。

HTTPS化するにあたっては大きな問題が2つありました。1つは、TLSの暗号化・復号化の処理が重たいということ。もう1つは、証明書の管理が煩雑にならないようにしなくてはならないということでした。なにせドメインでいうと1,000以上、サービスも100以上ありますので。

白石: 規模感が普通の会社とは桁違いだ…。

新部: なので、全社共通のリバースプロキシを作って対応することになったんです。そのリバースプロキシでTLSを一旦終端させて、そこから先は通常のHTTP/1.1に変換し、各サービスにリクエストを転送する。

白石: そのリバースプロキシって、だいたいサーバ何台分くらいになるんでしょう…？

新部: 500台以上ですね。

大津: 「以上」と言っても幅があると思いますが、そのかなり上の方ですよ、実際の数字は(笑)。

白石: す、すごい…！

新部: そして、2016年3月、最初にリバースプロキシに乗ったのはヤフオク！です。

白石: なんでヤフオク!を最初のサービスに選んだんですか？

新部: 検証の意味も強かったので、ある程度以上の規模感のあるサービスをデプロイしたかったんです。あと、下手すると人命を左右するような「何があっても絶対に止められない」サービスは避けたかった。

白石: なるほど。

新部: ヤフオク！も、いきなり全部をHTTPS化したわけじゃなくて、最初は一部だけ、その後範囲を広げていったという感じです。 幸いにもそれほど大きな事故も起こることなく進んでいき、2017年の3月末には、特定のクライアントに提供しているところを除いたすべてのサービスがHTTPSで動作するようになりました。

HTTP/2化は正直、「エイヤ」でやった

白石: なるほど、HTTPS化は、様々なご苦労はあったことと思いますが、比較的順調に推移したということですね。そして今では多くのサービスがHTTP/2を利用しているんですよね。HTTP/2化はどういう流れで進んでいったんですか？

新部: これはちょっと言いにくいし、言っていいのかもわからないんですが…正直、「エイヤ」でやってしまったところもありますね(笑)。

全社共通のリバースプロキシを構築できたし、ここをHTTP/2化してしまえば、全部HTTP/2にできるじゃん、と。弊社のエンジニアもHTTP/2サーバの実装に携わっていたりもしたので、自分たちで作った成果を自分たちで使いたいという要望もありまして…。

白石: で、「エイヤ」でやっちゃったと(笑)。

新部: まあ、全部をいきなり切り替えたわけじゃないですけどね。こちらも一部のサーバだけを切り替えて、問題がないことを確認しつつ、だんだんと。

白石: なるほどー。ちなみにその、最も重要なリバースプロキシですが、具体的にはどのソフトを利用しているんですか？nginxとか？

新部: いや、Apache Traffic Serverというプロダクトです。元々これは米国のYahoo! Inc.が開発していたものをApache Software Foundationに寄贈したものです。

白石: では、Apache HTTP Serverとは関連がないんですね。

新部: そうです。このサーバをHTTP/2対応させるパッチの開発に、弊社のエンジニアもコミットしているんです。

「HTTP/2化で速くなったかは…正直わかりません(笑)」

白石: では、HTTP/2への切り替えは、それほど大きな問題もなくうまく行ったと。そうした環境で運用を行ってみて、実際にわかったことや問題などはありますか？例えばHTTP/2化することで、パフォーマンスが向上するんじゃないかという期待はあったと思うのですが。

大津: そうですね…正直に言ってしまうと、HTTP/2でパフォーマンスが上がったかどうかはよくわからないんです。

白石: ああ、それ先日インタビューしたあほむさん も同じこと言ってました(笑)。

大津: 個別に見れば、速度が上がっている部分は確実にあるんです。ただ、トータルで向上したかどうかは結局よくわからないんですよね。

例えば、window.onload が速くなったかというと、そうでもないんです。ただ、onloadについてはあまりにも様々な要因が絡むんで、測定の指標としてあまり有効でないという問題もありますけどね。なにせ、ずっと昔から運営しているサービスなので、 document.write にブロックされているページも残っていたりしますし。

白石: 確かに、「トータルで向上したか」と言っても「トータル」ってそもそも何なんだという定義が難しそうです。

大津: そういうところも含めて、測定が十分に行えていないというのも課題ですね。サーバ側のログを見ると、リクエスト数ベースでHTTP/1.1とHTTP/2の割合は現在4:6くらいです。

白石: 1.1がまだいるっていうのは…ああそうか、(HTTP/2に対応していない)古いブラウザを使っているクライアントですね。クライアントの環境も様々だから、余計測定が難しいですね…。

大津: そうなんです。一気に切り替えてしまったことで、A/Bテストなども行えていないですしね。A/Bテストを行うために、一部を一旦HTTP/1.1に戻すというのもありかもしれません(笑)。

HTTP/2がサーバの処理負荷を下げる？

白石: HTTP/2に移行する前の、HTTPSへの切り替えではいかがでしたか？先程、「TLSの処理が重たい」という懸念が事前にあったとのことでしたが。

新部: 一度それで問題になったことはありますね。

弊社のサービスからプッシュ通知を送った時とかは、ユーザーが一斉に接続するので負荷が一時的に高まるんですが、それでCPUがパツパツになってしまったことがありまして。ただ、HTTPS化する前はCPUがボトルネックになるようなことはなかったので、やはりTLSの処理が影響していたんだろうなあと思います。

大津: ただ、その後そういう問題は起きていないのは、HTTP/2が一役買っているのかもしれません。

HTTP/2はTCPセッション数が減るので、TLSの暗号化・復号化に伴う処理負荷も減ります。単純に言えば、HTTP/1.1の時に6セッションだったものがHTTP/2で1セッションになったら、TLSのコストは1/6になるわけで。

白石: なるほど！HTTP/2がサーバの処理負荷を下げるという可能性は、今まで思い至りませんでした。

HTTP/2のさらに先へ。新しいプロトコルを知る – TLS 1.3とは？

白石: HTML5 Conferenceでは、さらに新しいプロトコルについてもご紹介があるとのことですね。

大津: はい、TLS 1.3やQUICについて紹介しようかと思います。

TLS 1.3というのは、1.2までの技術的負債を精算しつつ、ハンドシェイクを速くすることを目的とした仕様です。仕様はだいたい固まっていて、現在Googleをはじめとした企業が、実験的に使用して調査中です。

白石: 技術的負債を精算して、さらに速く…って、いいことづくめですね。

大津: ただ、TLS 1.3にはまだ大きな問題が残っています。後方互換性に関わる透過性の問題があって、通信できない場合があることが報告されているのです。

TLS 1.3に対応していない中間機器が、接続を無断で切断しちゃうことがあるんですよね。そういうファイアウォール、IDS（Intrusion Detection System:不正侵入検知システム）、IDP（Intrusion Prevention System:不正侵入予防システム）などが中間経路にあると、ネットワーク全体がダウンしてしまうこともあります。本来は、TLS 1.2にフォールバックしてほしいのですが…現在Googleなどが後方互換の問題を最小にするために透過性の調査を行っているところです。

白石: 通信を遮るものをどう扱うか、は難しい問題ですね。正直、簡単に解決する問題には全く聞こえませんね…

大津: そうなんですよ。少し前に、GoogleがTLS 1.3を試験的に有効化していたところ、ある学校で問題が発生し、数万台のChromebookが通信もアップデートも行えなくなってしまうということがありました。 こうなるとGoogleですらお手上げなんですよね。TLSに完全に依存しているので。

そう考えると、HTTP/2って「幸運」だったと思うんですよね。

白石: 「幸運」ですか。

大津: はい、TLS 1.2という「枯れた」プロトコル上の動作を前提にできたのがラッキーでした。TLS1.2って、2008年に登場したプロトコルで、今は完全に普及しきっていますから。

そういう前提のないプロトコルや機能拡張だと、大変なんです。

例えば、TCPのデータ送受信開始を速める「TCP Fast Open」という仕様もあるのですが、うまく通じない現象がAppleのエンジニアによって報告されていて、最近Linuxで緩和策が講じられたにもかかわらず、Microsoft Edgeではついにデフォルトで無効化されてしまいました。

TCP Fast Openは2014年に標準化されており、Linux、 macOS、 WindowsなどOSの対応も進んでいるのですが、それでもまだこういう状況です。それほど、低レイヤーのプロトコルを普及させていくのは難しい。

だから、私たちがHTTP/2の移行にあまり苦労しなかったことも含め、HTTP/2のアップグレードがこれほどスムーズなのは大変幸運なことなのです。

QUICという「プラットフォーム」の可能性

白石: QUICについても教えていただけますか？

大津: QUICは、ざっくり言うとUDPの上でTCP、TLS 1.3、そしてHTTP/2の一部をごちゃっとやる感じのプロトコルです。

白石: ごちゃっと(笑)。

大津: IETFでの標準化も進められていて、今度の10月で1年になりますね。非常に有望なプロトコルで、今後のネットワークのプラットフォームになっていくポテンシャルを秘めていると期待しています。

白石: なぜそこまで期待していらっしゃるのでしょう？

大津: 「UDPなので疎通性が良い」というのと「ユーザーランドで動作するプロトコルなのでデプロイが容易」ということが挙げられます。

先程TLS 1.3の普及には苦労しそうだ、という話をしましたが、QUICはUDPなので比較的通りやすいんです。また、通じなかった場合はTCPにフォールバックする機能もある。通信を行うコンピューター同士が、エンドツーエンドでQUICに対応していればいいのです。

ユーザーランドで動作する…というのは、TCP BBR (※) と比較するとわかりやすいと思います。

※参考: 「Google、TCPのスループットとレイテンシを改善する輻輳制御アルゴリズム「TCP BBR」をGoogle Cloudで利用開始 (Publickey)」

TCP BBRは、Googleが開発した新しい輻輳制御のアルゴリズムです。モバイル環境のように、パケットロスが非常に多い環境でも速度を最大化できるという利点があります。

しかし欠点としては、TCPのスタックってOSのカーネルに実装されているので、使おうとするとカーネルのアップデートが必要になるということです。できれば通信を行うコンピューターがどちらもTCP BBRに対応したカーネルにアップグレードしていることが望ましいのですが、OSのアップグレードサイクルを考えると、どれほど少なく見積もっても普及には数年かかるでしょう。

その点QUICはUDPの上で構築されている。プロトコルの処理はユーザーランドで行われるので、デプロイするのにOSのアップグレードなどを伴いません。プロトコルのバージョンアップも、機能追加も比較的簡単だと考えられます。将来的にHTTPだけでなくDNSやWebRTCなどでQUICが利用されることも検討されています。

白石: それが、「QUICはプラットフォームになりうる」という先程の言葉の意味ですね。

大津: はい。ただ、QUICも実際には良いことばかりではありません。「QUICを無効にしたらChromeが軽くなった」などのノウハウが最近巷に広まってきています（※）。さきほどUDPの透過性の良さについて話しましたがやはり完全に透過ではなく、これも中間経路での問題が出てきている現象だと見られています。

※参考: 「最近 Chrome が「重くなった・ひっかかる」と感じたら試してみてほしいこと (Tanweb.net)」

白石: やはり、ネットワークプロトコルのデプロイって難しいんですね…。ただ、QUICが持つ素晴らしい可能性についても、よくわかりました。

本日は、実際の大規模なHTTPS & HTTP/2への移行経験から新しいWebプロトコルのお話まで聞けて、大変勉強になりました！ どうもありがとうございました。

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

この記事は、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でのセッションも楽しみにしています。

HTML5Experts.jp名物、いろんな会社におじゃまして開発環境や開発体制とかを根掘り葉掘り聞く企画、今回はIoT通信プラットフォームとして大変な注目を集めるソラコムさんに伺ってきました。

インタビューに答えてくれたのは、執行役員プリンシパルソフトウェアエンジニアの片山暁雄さん、シニアソフトウェアエンジニアの清水雄太さん、同じくシニアソフトウェアエンジニアの小熊崇さんです。
今回は副編集長の仲さんがインタビュアーを務めます。

まずは自己紹介から！

仲 本企画は、イケてるサービスを作っている会社を訪問して、どう開発しているのかなどを根掘り葉掘り聞く企画です。まずは、自己紹介からお願いできますか？

片山 イケてるっていう前提がハードル高いですね(笑) 。

私は現職ではソフトウェアエンジニアで、課金の周りやSIMを管理する仕組みなどを開発しています。どちらかというとバックエンド寄りですね。もともとはJavaのプログラマーを10数年やっていて、以前は金融業界にいたので、ずっとBigDecimalとかを扱うプログラムを書いていました。結局今も同じようなことをやっていますけど(笑)。

前職はAWSでサービスの普及に務めていたのですが、だいぶ普及も進んだのでプログラマーに戻ろうかなと思い、転職して今ここにいるというかんじです。

▲株式会社ソラコム 執行役員 プリンシパルソフトウェアエンジニア 片山暁雄さん

小熊 私はソラコムに入社した当初は、Webの管理コンソールを開発していました。

今はAPIのゲートウェイになる部分を作っています。ソラコムのバックエンドは、実際にはいくつものマイクロサービスに分かれているのですが、それを外から見た時に単一のAPI群に見えるようなゲートウェイを作っています。

あとは、コマンドラインインターフェースやSDKなど、開発者の皆様に使っていただく部分を開発しています。

▲株式会社ソラコム シニアソフトウェアエンジニア 小熊崇さん

清水 私はフロントエンドを中心に担当しています。例えば、先ほどの小熊が以前開発していたWebの管理コンソールは、現在私が開発を引き継いでいます。

前職でRuby on Railsを使ってフロントエンド・バックエンドの開発を行っていましたので、ここでもそういう役割が多いですね。

ほかにも、普段の開発作業で行うスタンドアップ・ミーティングやSlackなど、開発体制の整備も行っています。このオフィスを作るにあたってのディレクションなど、開発から少し外れた部分も担当しています。

▲株式会社ソラコム シニアソフトウェアエンジニア 清水雄太さん

ソラコムって…なに？

仲 では、ソラコムさんのサービスの概要を教えていただけますか？

片山 はい、私たちのサービスを一言で言うならIoT向けの通信プラットフォームです。IoTのサービスを実際に展開しようとした際に発生する、技術的な課題やビジネス上の課題解決を支援するためのプラットフォームです。

具体的には、3GやLTEといったモバイル通信を使った通信サービス、そしてそれらをうまくクラウドにつなぐためのサービスです。 SIMカード「SORACOM Air」は、Amazon.co.jpで1枚から通販で購入可能です。また、世界の120の国と地域で通信を行えるようになります。

SIMカードを提供するとだけでは従来の通信事業者さんと変わらないのですが、私たちの特徴はIoTに特化しているというところです。

まず私たちの特徴の一つとしては、通信事業者であれば通常必要とされるようなパケット交換機や顧客管理といった通信用のハードウェアを一切持っていません。専用のハードウェアを用意する代わりに、それらを実現するソフトウェアコンポーネントを用意して、AWS上ですべてを実現しています。

通信に必要な基地局などは、MVNOとして通信キャリアから借りて、クラウド上ですべてを処理できる仕組みを持っています。

仲 なるほど、IoTに特化した、クラウドネイティブなMVNOというかんじですね。

片山 こうしたサービスをAPIの形で公開している、というのも大きな特徴と言えるでしょう。

IoTをやろうと考えるお客様は、数万から数十万の回線を扱うことも、特別なことではありません。例えばビーコンに通信機器を入れて全国にばらまく、といったことをする場合は相当な回線数になるので、人手では管理しにくい。

そこをAPIで管理できるようにしているので、通信量のモニタリングや、異常があったら通信を止めたりということを自動化していただくことができる。こうしたあたりが、私たちが「IoT向け」と謳っている強みになります。

また、3G網からAWSに専用線でつなぐこともできるので、Internet of Thingsといえども「インターネットを使わない」という環境を作ることもできます。

例えば自社システムがAWSの中だけにあったりする場合に、SIMカードを持っている人しか閉域に入れないような仕組みも簡単に作ることができる。そういった、セキュリティが重視されるIoTのシステムなんかも作ることが可能です。

また最近のアップデートとしては、「LoRaWAN」という通信量は限られているのですが、非常に省電力で広域まで届く通信プロトコルにも対応します。 そうなってくると、さらに多くのお客様に使っていただけるんじゃないかと思っています。

白石 私のようなWebエンジニアが、ソラコムさんのサービスを使って、何かしらIoTを試してみたい…ということもできるんでしょうか。

片山 はい、最近だとRasberry Piのような汎用的なデバイスもありますし、簡単に試せると思います。SIMのソケットを持つIoTデバイスを用意して、ほんとに簡単なロジックを書くだけで、クラウドまでデータが届きます。

例えばcurlコマンドでHTTP POSTするだけとかでもいい。JSON形式のデータでクラウドまで届きますので、後はご自由にどうぞというかんじです。

ソラコムの開発はどのような体制で行われている？

仲 ソラコムさんはWebのフロントエンドから通信キャリア的なバックエンドまで幅広く開発をされていますね。開発チームの体制などについて伺ってもよろしいでしょうか？

片山 あまり、チームに分かれて開発…というっかんじではないかもしれません。私たちは2週間のイテレーションをベースとして開発しており、2週間に1回インテグレートしてリリース、というのを繰り返しています。

なので、イテレーションを開始する際に次に実現する機能のプランニングや担当を割り振って、あとは個々人がそれぞれ進めていきます。

仲 なるほど。

片山 ただ、担当の割り振りについては、決まったものがあるわけではありません。エンジニアの平均年齢は30代中盤、ぼくらは各分野で経験を積んできたメンバーが集った、言ってみれば「おっさんベンチャー」なので(笑)、「これしかできません」っていう人はあんまりいない。

足りないところがあったら「代わりにやりますね」という雰囲気です。

仲 皆さん、一番得意なスキルはあれども、その他のこともこなせるというかんじなんですね。

清水 開発者としては実際に10名ちょっとなので、基本的に1チームで開発を進めている雰囲気です。

片山 弊社は、ベースが開発者っぽい人が多いんです。例えば、ビジネス開発をしているメンバーも、実はデバイスにものすごく詳しかったりして、コマンドラインで作業したり、ハードウェアの調査をしたりというのを普通にやったりするので…。だから、そういうところからも開発リソースを調達したりしています(笑)。

雨だから人が来ていない(笑)

仲 グローバル展開されているので、海外にも開発者がいるわけですよね。海外メンバーとのコミュニケーションはどのように取っていらっしゃいますか？

片山 基本的にはSlackとかGoogle Hangoutとかですね。ビデオ会議システムについては、いろいろ紆余曲折がある(笑)。

清水 例えばSlack Callsはまだリリースされたばかりで、機能も不足しています。スクリーン共有ができなかったり。なのでappear.inとかGoogle HangoutとかSkype for Businessとか、いろいろ試しましたね。まだここについては決定版がないという状態です。

白石 リモートワークが可能な体制になっているわけですね。そういえばこのオフィスも、他にほとんど人がいない状態ですが、皆さん別の場所で仕事してらっしゃるんでしょうか？

片山 はい、今日人が少ないのは雨だからだと思います(笑)。生産性を高く保てる環境で仕事をしているはずです。

清水 もちろんオフィスにいないと困る職種の人もいるので、そういう人は基本的に出社していますね。

マイクロサービス・アーキテクチャが実現する「開発者の自由」

仲 では実際の開発をどのように進めているかも教えてください。具体的にはどのようなプログラミング言語を使って開発していますか？

小熊 基本的には、先ほども申し上げたように、ソラコムの内側はマイクロサービスとして分かれているので、それぞれのサービスを開発者が選んだ言語で開発しています。

片山 例えば「使いたいライブラリがその言語にあるから」という理由で言語を採用することもありますね。ぼくらはスタートアップなので、一番早く実装できる方法を選択したいというのがその理由です。

今のところ、使っている言語としてはGo、Java、Node.js、C…。あと、AWS Lambdaの開発は、実はPythonが一番やりやすかったりもするので、Pythonを使ったりということもしていますね。

仲 その技術を採用する前に、誰かに相談したりはしないんですか？

片山 CTOに相談したり、といったことは多少ありますけど、基本的には開発者の自由ですね。

仲 なるほど、マイクロサービスに分けているからこそ、様々な言語を混在させることも可能なわけですね。興味本位で伺いますが、そこまで自由だと今後エンジニアが増えていったときとかに、「既存のコンポーネントを自分の好きな言語で書き直したい」なんて要望も出てきたりしないのかな…なんて。

小熊 書き直す正当な理由があるなら、それも許されるとは思います。REST APIの定義さえ変わらなければ、あるコンポーネントの中身がごっそり置き換わっても他の部分には影響ないですし。

片山 あとマイクロサービスのいいところは、オーナーシップがわかりやすいことですね。サービスごとに開発した人が大体分かれているので、担当者が自然と定まってくる。もし今後開発者が増えていって、100人とかになった時に、今と同じことができるかはわからないです。

そうなったら、ある程度統一しようという話も出てくるのかもしれませんが、とりあえず現在の段階では、マイクロサービスを開発者それぞれが開発するという体制でスケールアウトを目指したほうが素早くサービスを拡張できると考えています。

仲 マイクロサービスによる開発には、開発そのものをスケールアウトできるというメリットもあるわけですね。

白石 しかしそれだけ多様で自由に開発しているとなると、コードレビューなどが難しくなったりはしないのでしょうか？

片山 コードそのものよりも、仕組みやアーキテクチャ、APIのほうを重点的にレビューするようにしていますね。

小熊 開発をしていると、呼び出す相手のコンポーネントについて APIの挙動がよく分からなかったり、バグっぽかったりしても、相手に聞いたりする前にまずコンポーネントのコード読んじゃって、「あ、なるほど、こうやってこのAPI呼び出すのか」とかって自己解決しちゃったりすることもあります。

その際に、そのコードが難解すぎて読めないとか、何をするためのコードなのか理解できないとかいったようなことはこれまで経験していません。事前にアーキテクチャなどをレビューしているからということもありますし、各コンポーネントを担当しているエンジニアのスキルが一定以上の水準だからだと思います。

清水 私の担当しているユーザーコンソールなどは複数人で開発しているので、少しレビューを綿密にやっていたりはしますね。

（筆者補足: ソラコムさんは「理想的なリーダーシップ」について書かれた15の項目「リーダーシップ・ステートメント」をメンバー内で共有し、定期的に議論、各自が実践することで、自由なワークスタイル、自由な開発体制、そして各自が責任を持って仕事をすることを同時に実現しているのだそう。見習いたい！）

DevOpsではなくOpsDev

仲 サービスの運用などについても聞いてみたいです。DevOpsのあたりとかは、どのように運用を自動化しているのでしょうか？

小熊 そこは、弊社だとOpsDevと呼んでいるんです。Opsをメインでやっている人間が強いこだわりを持っていまして(笑)。開発したものを運用するんじゃなくて、運用のためにこそ開発がある、と。

仲 運用をメインで行うチームがあるというわけではないんですか。

小熊 まず、そもそも開発メンバー自体が、日々の運用やサポートにも直接参加しています。いわゆるDevOpsです。さらに弊社では、運用の自動化にメインで取り組むエンジニアが一人いて、彼を中心に様々な自動化や監視を行っています。

片山 メインはZabbixによる監視と、Ansibleによる自動化をしています。何か問題があったら、次はどうそれを自動化するかとか、次に問題をどうやって起こさなくするかとかを決めて、あとはそれを担当のOpsDevエンジニア中心にやる、という運用になっていますね。

白石 御社だと、運用そのものがビジネスかもしれませんよね。

片山 はい、そうなんです。通信コア部分を安定的に、そしてスケーラブルにAWS上で動かすというのが我々のビジネスの根源と言えば根源なので、そこは一番力を入れています。

なのでそれ以外の、例えば私が書いているバックエンドの部分などは、AWSのBeanstalkなどにを使えばそれなりにスケールアウトするし、それに頼って作っているという部分はありますね。

仲 先ほど「スケーラブル」という単語が出てきましたが、スケーラビリティを担保するためにどのようなアーキテクチャになっていますか？

片山 一言で言うのは難しいですが、例えば一番ネックになるデータベース部分はDynamo DBをメインで使っています。メインとなる通信サービスで、RDB使ってるところはほとんどないんじゃないかな。

ただDynamo DBだと、アプリケーション側で頑張らなきゃいけない部分が出てくるので、そこは頑張るといった感じですね(笑)。

白石 マイクロサービスだし、DBも分けてらっしゃるんですよね？

片山 はい、そうです。ただ、使っているDBはみなDynamo DBですね。

白石 決済の部分とかは、トランザクション処理が必要だと思いますが、そこはどうしてるんでしょう？

片山 そこもDynamo DBで頑張っています。Dynamo DBはトランザクションがあるにはあるのですが、2レコードをアトミックに更新できないので、極力1レコードに寄せるようにしたりとか。あと公式のトランザクションライブラリもありますし。

仲 ほかには、ログの管理などはどうしてらっしゃいますか？

片山 Logglyというサービスを使っていますね。ライブラリを使ってログを送ると、よしなにインデックスしてくれるようなサービスです。

仲 Elastic Searchを自前で運用したりはしていないのですね。

片山 はい。弊社のサービスは、ログの分析などがビジネスの源泉になるものではないので。ビジネスの源泉になる部分は自社開発にこだわっていますが、それ以外の部分は積極的に外部のサービスを使用するようにしています。

ソラコムの課題・改善点

仲 では、ソラコムの開発において、課題だと感じていることや今後改善していきたい点などはありますか？

片山 個人的に継続的に追求していきたい課題としては、いかにチームを小さく保っていられるかというところですね。

人が増えるといろんなロスが発生してくるじゃないですか。機動性を確保しておくために、人をなるべく増やさない。そのために必要なのは生産性を上げることなのか、一人が何役もできるようにすることなのか、ということですが、そこを追求していきたいと思っています。

清水 私も、今の片山の話ともリンクしていると思いますが、作るものをいかに小さく保っておけるかが大事だと考えています。大きなものを作ろうと思うと、沢山の人が必要になるし、メンテナンスも必要になってくる。

なので、同じ価値を少ない機能やコンポーネントで実現するということにはこだわっていきたいですね。今はまだぼくらは、機能やツールを追加していくフェーズではありますが、ある程度、一通り揃ったタイミングで、いかにそれらを減らしていけるか、シンプルにしていけるかは考えていきたいと思います。

小熊 ぼくは…課題とか不満とか、あんまりないですねえ(笑)。すごく自由だし、生産性も高いし、今のところ申し分ありません。

あらゆるものが「目」を獲得し進化する

白石 では最後になりますが、まだIoTに取り組んだことのないエンジニアに対して、IoTにどう取り組むべきかを教えてください。

清水 私はもともとWebエンジニアなんですけれども、IoTをやると、様々な業種の人々と接することになるのが楽しかったりします。

例えばWeb系の勉強会だったら、Webのトピックがやっぱり一番熱いので、Webの話が中心になる。それはそれで楽しいのですけど、ソラコムのユーザーグループだったり、メイカーズ・ムーブメントだったりに顔を出していくと、自分と同じくらいのスキルセットを持った人がぜんぜん違うことをやっていたりするわけです。

サーバーサイドもできるんだけど、Arduinoで何かやっていたりもする。そういう人たちに接すると、IoTに取り組むモチベーションも上がったりするんじゃないかなと思います。

小熊 私はもともと組み込み系の出身なんです。組み込みの業界のエンジニアは、「Webやクラウドについてはまだわからない」という人も多いですが、エンジニアリングの基礎がしっかりしているので、吸収も速いと感じています。

なので、組み込みの方々がIoTに取り組むのはすごく向いているので、ぜひトライしてみるといいと思います。

片山 個人的には、IoTでワクワクすることの一つは、あらゆるものに「手足」や「目」ができることだと思っています。どんなものにもセンサーが付き、デジタルデータ化できる可能性がある。

例えばぼくは、部屋のあらゆるものの最終アクセス日時が分かったら、片付けとかにすごく便利じゃないかと考えているんですよね。

白石 確かに(笑)。

片山 センサーだけじゃなくて、Amazon Goみたいに画像解析によるアプローチもあるし、そういうアイデアが実現可能な時代はもう来ている。これが進んで、身の回りのものがデジタルデータになることで、世界はもっと面白く、便利になるんじゃないかと思っています。

生物はカンブリア紀に目を獲得したことで、大幅に進化が進んだと言われているのですよね。それと同じことが、今まさに起ころうとしているんじゃないかなと。現在、そういう進化の途上なのだと考えると、IoTの波に乗っかってみるのも悪くはないと思えるんじゃないでしょうか。

社内のエンジニア向けツールを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は僕も使っているので、すごく興味深く聞けました。これからの新機能拡充も期待しています。今日はいろいろ面白い話をありがとうございました。

今回は、Webパフォーマンスに関する特集の一環として、株式会社Spelldata CEO、html5j パフォーマンス部 部長などを歴任されている竹洞陽一郎さん（エキスパートNo.54）にお話を伺ってきました。

竹洞さんはWebパフォーマンスについて10年以上従事しており、現在でも年間200サイト以上を計測・分析・評価しているという、その道のエキスパート。テクノロジーの知識はもちろんのこと、アカデミックな話題から業界動向まで幅広く押さえていらっしゃる竹洞さんに、「竹洞さんにしか語れないパフォーマンスの話」を聞いてきました。

「ADN」や「パフォーマンス・バジェット」など、Webパフォーマンス業界の最新動向の話も盛りだくさん！めちゃくちゃ面白くて歯ごたえのあるインタビューに仕上がったと思います。
どうぞお楽しみください。

「Webパフォーマンス大事」ってわかってる人は2割しかいない

白石 改めて伺いたいんですが、Webパフォーマンスはなぜ重要なのでしょう？

竹洞 根本的な話から言うと、Webサイトがある、ってことは伝えたいメッセージがあるわけですよね。 そして、多くのサイトは複数のページにまたがっているわけですが、それは伝えたいメッセージが複数ある、もしくは複数に分けているということ。 Webサイトを高速に表示するということは、それらのメッセージを高速に伝えるということにつながるわけです。

ですが、UX業界で著名なロバート・ヤコブソンによると、1秒以上のインタラプトが入ると人間は思考を中断されてしまうといいます。このインタラプトは、可能な限り避けなくてはなりません。 それによって、ユーザーを「フロー状態」に導くことを作り手としては目標にすべきであり、それがパフォーマンスを重視する理由となります。

白石 そうしたフロー状態にユーザーを導くことが、営利企業にとってはビジネス上も大きなアドバンテージになるということですね。 ただ例えば、「パフォーマンスを向上させるとKPI達成につながりやすい」、もしくは端的に「儲かる」といったことを表すデータなどがあれば、多くの企業がパフォーマンスの優先順位を上げると思うのですが、そうしたデータはあるのでしょうか？

竹洞 GoogleやYahoo!が出しているデータはあるのですが、あらゆる業界をおしなべて平均化してしまっているので、正直それほど使えるデータだとは思っていません。 業界によって、業務上のKPIって全然違ってきますからね。

となると、業界や企業ごとの事例になってくるのですが、そういう点でまとまったデータは今のところ存在しません。モデルもできていない。 例えばAmazonだと0.1秒パフォーマンスを改善すると売上が1%上がる、といったデータが示されたこともありますが、これも「Amazonだから（特別なんだろう）」の一言で済まそうと思えば済まされてしまう。

私が担当している仕事でなら、具体例はいくらでも挙げられるんですけどね。あるメディアは、表示に6秒かかっていたところを3秒にしたことでPVが倍になったり、売上が3倍になった会社もあります。

白石 それはすごいですね。ちなみにパフォーマンスがそこまで重要である、という認識は、日本で今どれくらい浸透しているとお考えですか？

竹洞 うーん、エンジニア界隈にはそれなりに浸透しているとは思うのですが、全体でいうと2割くらいの浸透度じゃないですかね…。そして、「浸透していない」というのは、「パフォーマンスの重要性に確信が持てなくて投資に至らない」というレベルではありません。単純に「知らない」ということが多いです。パフォーマンスについて考えたこともない、という。

白石 なるほど…。もう少し「パフォーマンス大事」という認識を広めたいところではありますね。この記事が多少なりともそのお役に立つといいんですけど。

あなたが統計を学ぶべき理由

白石 では、パフォーマンスが大事だという前提に立って、パフォーマンスの問題を解決しようとしたら、まずは原因の調査からですよね。具体的に言えば測定という話になりますが、竹洞さんは統計に関する知識を学ぶべき、と普段からおっしゃってますよね。これはなぜですか？ツールが生成するグラフやアドバイスに従うだけではいけないんでしょうか？

竹洞 まずですね、パフォーマンスの原因を調べるにあたっては、「先入観を持たない」ことが重要なんです。私の経験から言うと、パフォーマンスの問題を抱えたお客様は、まず「データベースが原因だと思う」と必ずおっしゃいます。でも、ちゃんと調べてみると違ってみたりする。統計学を学ぶと、こういう「バイアス」との付き合い方も学びますので、先入観を持って事に当たることが少なくなります。

白石 なるほど。

竹洞 あと、統計を学ばずにデータに当たると、「データに騙されちゃう」ということが往々にしてあるんですね。「データは何も語らない。語るのは人間である。」という言葉があるんですが、データを解釈して行動に繋げるのは人間なのです。統計について学んでおくと、そこで誤った判断をする可能性を下げることができる。

また、そもそもデータが正しいのか、という問題もある。正しくないデータに基づいても、有意な判断は下せないわけです。ただここで一つ重要なのは、「真の値」を知ることなんてそもそもできないわけですよ。いろんなゆらぎもありますから、一意に定まるわけがない。絶対ズレている。だからその、神様しか知り得ない「真の値」から、得られたデータがどれだけズレているのかを推測し、それも含めて判断が必要になるわけです。

ちなみに、こういう「ズレの推測」も含めてデータを扱うことを「推測統計」、一方、得られたデータをただ（グラフなどに）記述して扱うことを「記述統計」と言います。

白石 推測統計まで行うことが望ましいってことですね。

竹洞 そうです。とはいえ、まずそもそものデータを信頼度高く取るに越したことはない。そのために、近代統計学の確立者で、実験計画法という手法を編み出したロナルド・フィッシャーは、「3つの原則」を打ち出しています。その原則とは、以下の3つです。

• 反復…長期間に渡り、繰り返し採取する。
• ランダム…単純無作為抽出を行い、計測を行った値同士が影響を及ぼさないようにする
• 層別…変数を局所化し、影響を見たい変数だけ可変にする

こういう知識があるのとないのとでは、データやグラフに対するスタンスが全然違ってきます。「バイアスを排除して、先入観を持たない」「正確性の高いデータに基づき、精度の高い判断を行う」といったスタンスを身につけるためにも、統計をきちんと学ぶことはお勧めしています。

なぜGoogle Analyticsでパフォーマンスを測ってはいけないか？

白石 竹洞さんは、Google Analyticsとかでは、パフォーマンスを正確に計測できない、と以前からおっしゃっていますね。その理由を教えていただけますか？

竹洞 まず、GAで「遅い」という問題に気付けたとしても、原因追求ができないんです。原因となりうる要因が多すぎるし、絞り込むこともできない。 もう一つは、欠損値が多いことです。遅いということはそもそもGAのスクリプトが読み込まれていないことも多い。そういうのが全てデータから抜けてしまうんですね。

白石 なるほど。遅いなーと思ってリロードしたり、途中で離脱したりしちゃうと、そもそもそれがデータから漏れてしまうんだ。

竹洞 そうです。その影響は実は大きくて、データにバイアスがかかってしまうんですよ。本来注目すべき「遅い」データが見えなくなってしまう。 その状態でデータを眺めると、問題が隠蔽されてしまう。こうなると、アメリカの鉄道と同じです。

白石 どういうことですか？

竹洞 アメリカの鉄道が廃れた理由って、遅延やサービスの低品質に利用客も慣れてしまい、不満が上がってこなかったことにあると言われているんです。 で、不満が上がってこないから、企業は「顧客は満足している」と判断し、更にコストカットなどを進めてしまう。その結果、鉄道が衰退してしまった。

白石 なるほど…。GAで欠損値が出るだろう、というのは想像できていたことではありますが、それが経営判断を誤る一因にまでなりうるということですね。 では、パフォーマンスを測定するにあたって、良いサービスはありますか？

竹洞 たくさんありますよ。例えばcatchpointやdynatraceとか。こういったサービスは、実際のユーザー群に近い環境を国ごとに構築していて、継続的にデータを収集してくれます。こうしたサービスで得たデータと、GAで得られるパフォーマンスデータって実際にかなり開きが出てくるので、面白いですよ。

Webページの遅延原因の80%を占めるのは…？

白石 では、もう少し具体的に、パフォーマンスボトルネックの原因や改善方法についてお話を伺っていきたいと思います。Webサービスのネットワーク遅延の原因は、フロントエンド、ネットワーク、バックエンドに分かれると思いますが、バックエンドの話は原因も多岐に渡りそうですし、時間もないので、今回はフロントエンドとネットワークに絞ってお話を聞かせてください。

まずはフロントエンドからいきましょうか。

竹洞 はい、ではまずは前回の座談会でもお話したとおり、Webページの遅延原因の80%はサードパーティから読み込むリソースにあります。

白石 それって、例えばCDN (Contents Delivery Network) からjQueryのJavaScriptファイルを読み込むとか、ソーシャルボタンとか、広告とかいろいろありますよね。

竹洞 はい。で、あえて言うならやはり広告とかですかね。広告のパフォーマンスを見てみると、サーバーのDBがボトルネックになってるんだろうなあ…とは推測しています。そうなると、こちらでは手が出しようがないんですよね。広告を配信している企業に直接改善を要求するしかない。

白石 なるほどー。じゃあ、パフォーマンスの観点から言うと、やはり広告はボトルネックになりやすいと。ほか、「いいね！」ボタンとかのソーシャルボタンや、CDNで配信されてる静的なリソースとかはどうなんでしょう？

竹洞 ソーシャルボタンも遅いですよ。ソーシャルボタンのスクリプトって、キャッシュの時間も15分くらいと短いものが多いので、ネットワークアクセスが増加する一因にもなりますしね。CDNについては…いろいろあるので、あとでじっくり語らせてください(笑)。

ちなみに、アメリカだとサードパーティのスクリプトと言えども、速いんですよ。遅いと（ユーザー企業に）呼び出されるから(笑)。

白石 そうなんですか！アメリカだとユーザー企業の意識も高いんですかねえ。逆に言うと、日本の企業はそこまでパフォーマンスに対する意識が高まってなくて、結局遅いサイトが多数を占めるようになってしまってる、ってことなんでしょうか。

竹洞 そういうことです。あとはフロントエンドで言うと、画像じゃなくてもいいものを画像にしてる、ってのがすごく多いです。ちょっと秘密の資料お見せしますけど、ほら。これ全部画像ですよ。誰でも知ってるような企業のサイトなんですが…。

白石 CSSとかでできそうなものばっかり…

竹洞 そうなんです。HTML5やCSS3のおかげで、Webのポテンシャルってすごく広がりましたけど、そもそもそのポテンシャルが全然理解されてないんです。残念ながら。

ミニファイは不要？目からウロコのパフォーマンス改善術あれこれ

白石 では次は、ネットワークのパフォーマンスについてのお話を聞かせていただければと思います。ネットワークのパフォーマンスって、転送量、転送速度、転送距離の話に分けられると思います。

まずは転送量の話からいきましょうか。ここは、例えばJavaScriptやCSSのミニファイや結合、画像の最適化など、すでに読者に馴染みのある話も多そうなので割愛してもいいでしょうか？

竹洞 あ、一つだけいいですか？実際のところ、実はスクリプトのミニファイとかって、あんまり必要ないんです。

白石 ええっ！そうなんですか？そこを頑張ってるエンジニアたち、ぼくも含めていっぱいいると思うんですけど。

竹洞 もちろんやらないよりはやったほうがいいですけど、パフォーマンス全体から言うと、あまり効果のある施策ではありません。そこに開発コストを投じるべきかどうかは疑問ですね。

それよりもやはりネットワークアクセスの回数、もっと厳密に言えばTCPの3ウェイハンドシェイクの回数の方が重要。で、そこを改善すべくHTTP/2などのプロトコルが登場したわけです（筆者注: HTTP/2は、1本のTCP接続内で複数のHTTPメッセージのやり取りを可能にする）。

ちなみに私としては、HTTP/1.1とHTTP/2は、Webサーバのリソース特性や配信対象地域などを分析した上で、適切に使い分けてほしいですね。

白石 え、そうなんですか？全部HTTP/2にすればいいのかと思ってました。

竹洞 近所のスーパーに車で行くか、自転車で行くかってなると、自転車のほうが速い場合も多いわけじゃないですか。それと同じで、条件によっては、実はHTTP/1.1の方が速い場合も存在します。

白石 具体的にはどんな条件でしょう？

竹洞 ネットワーク距離、リソース配信サーバ数、オブジェクト数、転送容量などですね。ネットワーク距離の観点では、HTTP/1.1は近いほど、HTTP/2は遠いほど有利です。リソース配信サーバ数の観点では、HTTP/1.1は多いほど、HTTP/2は少ないほど有利です。単純にオブジェクト数だけを考えると、HTTP1.1は少ないほど、HTTP/2は多いほど有利です。

白石 じゃあ、例えば先ほどから話に上がってるサードパーティのスクリプトなんかは、ドメインもバラバラだし、アクセスはほとんど1回こっきりだし、HTTP/1.1が活きてくる分野かもしれませんね。

CDNは遅い？？？？？？そして「ADN」ってなんだ？

白石 あと、先ほど「後で語る」とおっしゃっていた、CDN (Contents Delivery Network)についてもお話いただきましょうか。

竹洞 CDNについては、実際のところを知ると、皆さん驚かれると思いますよ。実は、CDNはもう速くないんです。

白石 えっ…！そうなんですか？ちょっと意味がよくわからない。

竹洞 ネットワークに対する投資額の規模を表した図としては、こういうものがよく使われます。上がファーストマイル、事業者に最も近い部分で、サーバーやクラウドに代表されるレイヤーです。一方一番下がラストマイル。ユーザーに最も近い部分ですね。

この図を見てわかる通り、ラストマイルとファーストマイルには多くの投資が行われてきました。エンドユーザーに近い部分のネットワークは、相当高速化されてきている。

以前はCDNは、ラストマイルを高速化するためのサービスとして有力でした。ただ、業界全体でラストマイルに多くの投資が行われた結果、CDNの有用性そのものが薄れてしまいました。なので、CDNに置くよりも自前で配信したほうが速いという状態が一般的になっているのです。

白石 そうなんですか。CDNが速くないなんて…。

竹洞 なので、CDNのベンダーは速度じゃなくてロバストネス、堅牢性をウリ文句に変えるところも出てきています。ただそれは、第一世代のCDNと言われていたサービスの話です。

Fastlyに代表される第2世代のCDNは、POPs (Points of Presense:CDNのサーバーを物理的に配置する位置)を最適化するというアプローチで、大きくこの分野を前進させました。

そして今、この分野は第三世代に入ろうとしています。Instart Logic社なんかはその代表で、私もエヴァンジェリストを務めていますが、自身を「Application Delivery Network」と呼んでいますね。

白石 それは、具体的にはどう違うんですか？

竹洞 ひとことで言うと、非常にインテリジェントなのです。まずサーバー側では、機械学習を用いて基地局ごとに最適な経路を割り出すので、非常に動的な最適化が行える。

また、クライアントとサーバーがコミュニケーションしながら、リソース取得の最適化を図ります。具体的には、クライアント側に「ナノバイザー」と呼ばれるJavaScriptのエージェントを走らせます。ブラウザ側の仮想マシンと言ってもいい。そのナノバイザーが、サーバーと様々な情報を常にやり取りしながら、リソースの最適な取得方法を探るわけです。

白石 なるほど。そういうことをするには、クライアントとサーバー間でステートフルなコネクションが必要になりそうですが、そこはどうしてるんですか？WebSocket？HTTP/2？

竹洞 HTTP/2です。HTTP/2をフル活用して、初めて実現するアーキテクチャですね。他にも、サーバ側でJavaScriptコードを分析して必要な関数のみをクライアントに送るといったアグレッシブな転送量削減や、サードパーティ製スクリプトを自分のドメインから配信してHTTP/2の恩恵を最大限受けることも可能です。

白石 それはすごい。

竹洞 モバイル向けのライブラリとかもあるのですが、本当に高速ですよ。速度のためにTCPの代わりにUDPを使用していて、そうなるとパケットのエラー検知と再送制御が必要になるわけですが、一定のパケット数ごとに誤り検知のためのチェックサムを付与して、ライブラリ内でエラー制御することで解決しています。

白石 機械学習やHTTP/2といった、基盤技術の進化をフル活用して、コンテンツの配信をこれまでにないレベルで最適化するというわけですね…。面白い。

「パフォーマンス・バジェット」というパラダイムシフト

竹洞 あと、パフォーマンス業界の最新動向という点でいくと、アメリカでは「パフォーマンス・バジェット」という考え方が浸透してきています。

白石 なんですかそれは？初めて聞く単語ですが。

竹洞 パフォーマンスの目標を立てると、使えるリソースの量は限られてくるわけです。例えば、前回の座談会でもお話した「モバイルで3秒以内に表示を開始するためには、リソースを200kb以内に抑えるべき」といったように。で、そのリソースをどう割り振るかをサイトの設計段階から計画しておくという考え方です。（筆者注: パフォーマンスバジェットについては、ミツエーリンクスさんのブログに詳しい紹介があります）

白石 その考え方は面白いですね！全然知りませんでした。そして、そういう概念が出てくるくらい、海外ではパフォーマンスの重要性が浸透しているということなんですねえ…。パフォーマンスを「リソースの量」という点で定量化することで、リソースのサイズやフェッチのタイミング、開発コストの投下量など、いろんなものをコントロールできるようになりそうです。

うちみたいなスタートアップ企業（TechFeedというサービスの運営企業）とかだと、機能実装が優先になっちゃって、パフォーマンスという項目がどうしても優先順位上がらないんですが、そういう状況の改善にも役立つかもしれませんね。

竹洞 そうですね、パフォーマンス・バジェットの考え方は、スタートアップにも有効だと思います。計測サービスにお金を払い続けるのが厳しい…という事業規模の企業にも有用かな、と。

白石 え、それどういうことでしょう？

竹洞 優秀な計測サービスって、やはりそれなりに高額なんですよね。規模の小さい企業だと、サービスを運営しながらずっと使っていくのは厳しい。 ただそれでもパフォーマンスを担保したいという場合、パフォーマンス・バジェットを見積もるために、最初だけ計測サービスを使用するということができるわけです。あとはそのバジェット内でリソースをやりくりするよう注意していけば、一定のパフォーマンスが担保された状態になります。

白石 なるほど。まずそもそも、パフォーマンス・バジェットを見積もるには、ある程度の計測と実績値が必要だと。そのために計測サービスに最初だけ課金するということですね。一旦見積もったバジェットを守りさえすれば、パフォーマンスが担保された状態になる、というのもロジカルでスッキリしますね。

品質保証（Quality Assurance）は今後重要なキャリアになる！

白石 では、お時間もかなりオーバーしてしまいましたが、最後に読者に向けて伝えたいこととかありますか？

竹洞 そうですねえ、私はパフォーマンスも含め、Webサイトの品質保証というところにずっと注力しているわけですが、今後このQA (Quality Assurance)という分野は非常に重要になると思っているのです。例えば、2019年に民法が改正されて、システム開発の受注側が品質保証の責任を負わなくちゃいけなくなります。現在の「瑕疵担保期間」という単語は条文から消えて、品質保証を行って納入しないと「重過失」という扱いになって、永遠に瑕疵責任を負うことになるんです。つまり、品質を満たすまで、タダ働きになるってことです。

白石 それはすごい変化ですね…。開発や制作を受託している企業にとっては大問題だ。

竹洞 こういうこともあるので、今後はQAのスキルが非常に求められてくるのは間違いありません。現在日本にはQAという職種がほとんどない状態ですが、だからこそQAを行えるエンジニアは非常に希少価値があると思います。それができるようになれば、今後のキャリアを考える上でも非常な強みになるのではないでしょうか。

白石 うーん、最後まで大変示唆に富む発言、感謝です。本日は大変勉強になりました。貴重なお時間を割いてインタビューに答えていただき、どうもありがとうございました！

今回は、HTML5 Experts.jpでWebパフォーマンスに関する特集を行うにあたって、エキスパートの皆様による誌上座談会を開催してみました。

通常であれば数時間語っても尽きないような話を、1時間強でみっちり聞いてきました。 Webパフォーマンスの改善について、初心者から上級者まで楽しめる、有用な記事になっているかと思いますのでどうぞお楽しみください。

エキスパート紹介

白石 皆様、本日はお集まりいただいてありがとうございました！まずは簡単に自己紹介をお願いできますでしょうか？

竹洞 株式会社SpellDataのCEOを務めている、竹洞です。Webパフォーマンスには10年間くらい関わっており、年間200サイトくらいの計測に携わっています。 今度から、Instart Logicのエヴァンジェリストも務めることになりました。Instart Logicは、Application Delivery Networkを標榜する、いわばCDNの第三世代とも言えるものです。

白石 Contents DeliveryじゃなくてApplication Deliveryなんですね。その用語は、Instart Logicが独自で使っている用語なのか、それとも広く使われようとしている用語なんでしょうか？

竹洞 業界では広まりつつある用語ですね。具体的には仮想化技術と機械学習と組み合わせて、アプリケーションのリソース配信をこれまでにないレベルで最適化しようとするものです。

白石 なるほど、コンテンツデリバリーの業界は、そんなふうな進化が起こっているんですね…全然知りませんでした。次は川田さん、お願いします。

川田 川田です。ピクシブ株式会社の執行役員で、Chief Culture Officer (CCO:最高文化責任者) を務めています。 ここ最近は少しエンジニアリングから離れていますが、以前はWebパフォーマンス関連の記事を執筆したり、W3Cのメーリングリストで発言したりしていました。

最近だと、さくらインターネットさんと組んでImageFluxという画像変換のクラウドサービスを提供開始しました。弊社のサービスは、画像についてはユーザー様の要求レベルが極めて高いのです。

そこで得たノウハウを、モバイル時代のサービスの課題、それこそ、低速なネットワーク、多様なスクリーンサイズといった、画像の変換ニーズにあわせる形で他のサービス提供者のみなさんにも使ってもらえるようにしてます。

矢倉 ピクセルグリッドという会社でフロントエンドエンジニアを務めている矢倉です。Webの標準化にも関心がありまして、いろいろと関わっています。 パフォーマンスについては、レンダリングやスクロールと言った、クライアントサイドでの最適化に関心があります。

Webパフォーマンスについて、まず思うこと

白石 ではまずは、Webパフォーマンスについて思うところをざっくり語っていただけますでしょうか？

竹洞 そうですね、まず総じて言えるのは、Webページのパフォーマンスに悪影響を及ぼしているのは主にサードパーティ（が配信するリソース）だということです。この1年で200以上のWebサイトを見てきましたが、その80%以上で、ページ内のソーシャルボタンや広告など、サードパーティによって配信されるリソースがパフォーマンス悪化の主な原因になっていました。

またちなみに、モバイルネットワークについては、この1年でdocomoさんがだいぶ頑張ったので、ボトルネックがかなり解消されました。最近だと、SoftBankさんの遅延が少し目立ってきている印象です。

白石 なるほど、サードパーティが80%…ちなみに、広告がパフォーマンスのボトルネックになっているとして、それをどうやって改善するんですか？手を付けられない部分なのでは？

竹洞 広告配信側の企業との交渉ですね。

白石 なるほど(笑)

竹洞 とはいえ海外の企業だと、そういう交渉に応じて改善してくれるところはまずありませんが、国内だと改善してくれる場合はありますね。

白石 でも、広告のパフォーマンスが悪いというのは配信側にとっても問題なんじゃないでしょうか？

竹洞 そのはずなんですが、今のところあまりそこに気を払っている業者は少ないです。ただ、海外のアドテク大手である「Criteo」と「SteelHouse」が裁判で争った結果、いろいろな問題のある証拠が出てきたこともあり、アドテク業界そのものがいろいろと見直される時期に来ているのは間違いない。そういう流れの中、広告のパフォーマンスなどについても注目が集まるようになるかもしれません。

川田 アド周りの問題を除くと、フロントエンドのパフォーマンスにおいては、ページのリフローがほとんどと言えるんじゃないかなと思ってます。

矢倉 確かに、動きの少ないサイトとかだと、リフローが主な要因なのは間違いないですね。ただ、JavaScriptを多用したインタラクティブなWebアプリとかだと、そもそも「速い、遅い」の定義をどこに置くかというところから問題になってくると思ってます。

インタラクティブになればなるほど、操作にかける時間や回数が多くなるので、その反応速度なども見るのが重要になるんじゃないかと。、そうなると、リフローもそうですが、画面のペイント処理も問題になることが多いですね。たとえば、動きのある要素が別のレイヤーに分けられておらず、画面全体が再描画されちゃう、そういうことが多いかなあと。

白石 ではそろそろ、具体的なパフォーマンス改善テクニックについて、詳しくお聞きしていきたいと思います。本媒体（HTML5 Experts.jp）はフロントエンドエンジニアが主な読者なのと、インタビュー時間も限られていますので、今回はバックエンドのパフォーマンス改善は取り上げず、フロントエンドとネットワークに絞ってお話をお聞きしたいと思います。

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

白石 では、フロントエンドのパフォーマンス改善テクニックについてお聞きします。ここについては、以下のような項目についてお聞きしようかと思います。

• リフロー
• ペイント
• スクロール
• DOM

先ほどリフローのお話が出ていましたが、リフローに関してパフォーマンスを改善するというのは、具体的にどのようなことなのでしょうか？

川田 単純に言うと、リフローを発生させないか、発生してしまったとしてもそのコストを減らすということに尽きると思います。

白石 なるほど。それは、widthやheightと言った、レイアウトに影響のあるプロパティの操作を最小限に抑えるとか、でしょうか。

矢倉 そうですね。最近だと、CSS ContainmentっていうCSSプロパティもあります。これは、リフローなどのレイアウト変更や、描画の範囲を制限するためのプロパティです。 （筆者注: 現在はChromeのみ実装で、実装された際の紹介エントリが詳しい）

川田 あとこれは以前からあるテクニックですが、リフローを発生させることなく要素の見た目を変化させるためにtransform:scale()などを使用したり、transform:translateZ()を指定して合成レイヤーを生成したり、でしょうか。 ここらへんは、GPUをいかにうまく活用するか、という話と重なるところがありますね。

白石 GPUの活用、という点で言うと他にもありますか？

川田 will-changeプロパティとかでしょうか。結局、「いかにGPUに載せるか」って話になるんですよね。あと、GPUの活用を始めたブラウザは（意外にも）Internet Explorerだった記憶があります。 （筆者注: will-changeについてはこちらが詳しい）

矢倉 ちょっと違う話ですが、Windows Vistaの動作要件にそれなりの性能を持つGPUが求められていたこともあり、ラップトップでもGPUが普及したという話を聞きました。現在ブラウザでGPUが一般的に使われるようになった遠因とも言えるかもしれませんね。OSとしては、評判良くなかったですが…。

白石 他には、ペイント処理を改善するとしたら、border-radiusやbox-shadowなど、負荷が高いと言われているCSSプロパティの使用をなるべく控える、といったところでしょうか。 （筆者注: border-radiusとbox-shadowを併用すると遅くなる、というのは有名な話です）

白石 スクロールについてはいかがでしょう？

矢倉 スクロールや初期ロードについては、ユーザーとのインタラクションを阻害して、体験を損ねてしまう「ジャンク」と呼ばれる処理をいかにうまく避けるかが重要になってきます。 そのためのAPIはいくつかあります。

例えば Passive EventListenerは、イベントハンドラ内で preventDefault() が呼ばれないことをブラウザに伝える機能を addEventListener()に加えたものですが、これを使用すれば、ブラウザはイベントハンドラの戻りを待たずにスクロール処理を進められます。 （筆者注: JxckさんのPassive Event Listeners によるスクロールの改善という記事が参考になります）。

川田 また、スクロール中に走る処理を throttleする（筆者注: 一定期間内に発生した処理をまとめ、一度の処理としてしまう）とかもやりますね。

矢倉 ほかパララックスなページなどで、scrollイベントに引っ掛けて何かするという処理は多いですが、結局のところ「特定のDOMが出現したら何かの処理を行う」ということでまかなえることが多い。そんな話があって登場したIntersectionObserverというAPIを使うと、要素が画面内に入ったことや、要素同士が交差したことを検知できます。

（筆者注: こちらもJxckさんの記事が参考になります: Intersection Observer を用いた要素出現検出の最適化）。

白石 すごく勉強になります、ありがとうございます。ほか、最初に挙げていたトピックとしてはDOMに関する最適化が挙げられますが、ここは何かありますでしょうか？

川田基本的な話としては、Forced Synchronous Layoutを避けるというのがありますね。

白石 ふぉーすどしんく…？なんですか？

川田 Forced Synchronous Layoutっていうのは、例えば要素の幅（width）や高さ（height）、位置など、「レイアウト処理を行ってみないと決まらない」タイプの値をJavaScriptから参照したりすると発生する強制レイアウト処理のことです。できる限りそういう値を参照するのは避けなくてはなりません。

白石 なるほど。ただ経験から言うと、そういうプロパティを参照したくなることって割としょっちゅうあるのではないでしょうか？

矢倉 はい、なので、そういう処理を可能な限り減らすようにコードを書く努力が必要になります。例えば、一度取得した値を変数にキャッシュして使いまわす、とかですね。どのコードの負荷が高いのかを見極めて、意識したプログラミングが重要ですね。

白石 ここまでで、たくさんのJavaScript APIが紹介されていましたね。requestAnimationFrame()、IntersectionObserver、Passive EventListenerとか。他にもありますか？

川田 例えば、requestIdleCallback()とかですかね。これはそれほど優先度の高くない処理を、ブラウザがアイドル状態な時に実行するというものです。 ちなみにこのAPIは、「setImmediate()が必要かどうか」という議論の中から生まれたものです。ただ、少し用途は違うんですよね。

白石 setImmediate()は、ただ単に処理をイベントループの末尾に回したいだけですもんね。

川田 ほかは計測系のAPIでしょうか。Navigation Timingとか、Resource Timingとか。こうしたAPIを使えば、JavaScriptからパフォーマンス計測が行えるので、最適化に役立てられます。

ネットワーク関連処理の改善

白石 ではここからは、ネットワーク関連のパフォーマンス・チューニングについて語っていただきたいと思います。まずは転送量の削減についてですが、基本的な項目としては、例えばソースコードのminifyと結合などが挙げられるかと思います。

他には画像の最適化なども含まれると思います。imageminなどを使ってサイズを減らしたり、webpに変換するなども挙げられますよね。

矢倉 ほか、レスポンシブイメージのテクニックも重要ですね。img要素のsrcset属性や、picture要素とかで、不必要に大きな画像を送らないようにすると。 ただ、最近はスマートフォンの画面のピクセル密度が3倍、4倍とかになっています。そんな端末に合わせて、ばか正直に高解像度の画像を書いてしまうと、転送量も非常に大きくなってしまう。 そうならないようきれいなものを提供したい画像を優先度つけて選ぶとか、あとは可能な限りSVG…ベクター画像を用いるようにも心がけるべきですね。

白石 ベクターといえば、アイコンフォント（筆者注: アイコンをWebフォントとして作成して利用する）もよく使われるテクニックですよね。

矢倉 ただ、最近はアイコンフォントは良くないプラクティスとして認識されつつあります。

白石 え、そうなんですか。

矢倉 テキストコンテンツなので、Webフォントファイルが読み込まれた際にリフローが起こることや、Webフォントのファイルががダウンロードされるまでにタイムラグが大きいことが問題です。 あと、iOS Safariのコンテンツブロッカーには、Webフォントをブロックするものもあるんです。そうなると、アイコンが全く表示されないことになってしまう。

そういうこともあって、SVGスプライトなどをを使うのが望ましいという流れになっています。

白石 そうなんですね…ちなみにWebフォントのダウンロードについてですが、CDNで共有されているものがクライアントのブラウザ上にキャッシュされていることを期待してしまうのですが、実際のところどうなんでしょう？

竹洞 いや、あまり期待できないですね。

白石 ええっ！？

竹洞 基本的には自分のサーバーで配信するのが一番速いです。

白石 そうなんですか！？それは…割とショックです。むしろ「CDNが使えなかったら自分のサーバーからフェッチする」みたいなコードの書き方をしていました。 サードパーティのライブラリも、わざわざファイル結合やモジュールバンドルの対象から外して、CDNから読むようにしていたり。。

竹洞 冒頭で申し上げた「遅延原因の80%がサードパーティ」というのは、そこにCDNも含まれるんです。自前で配信するのが結局一番速い。

白石 なるほど。ではこの流れで竹洞さんに、ネットワーク関係の最適化のお話をもう少し伺いたいと思いますが、DNSに関してはいかがでしょう？

竹洞 DNSに関しては、世界的に遅延している状態です。どのサーバーもパンパンで。Bindのセキュリティ問題などもありますし、DNSは現在大きく問題になっています。 あと、皆さんTTL短すぎなんですよね。5分から10分とかに設定している。

白石 じゃあ、ちょっと長いコンテンツを読んだりしているうちに、DNSのキャッシュ切れちゃってたりすることもあるわけですね。 なんでそんなに短くしてしまうのでしょう？

竹洞 それはやはり、何か問題が生じた時に切り替えられないのが怖いからでしょうね。TTLをみんなが1時間とかに設定するだけで、DNSトラフィックの問題は大きく改善するのですが、難しい問題です。

白石 DNSの話から思い出したのですが、DNSの先行読み込みとか、HTMLで指定できるようになってますよね、たしか。

川田 はい、 <link rel="dns-prefetch" href="<origin>">という形式で指定できますね。あと、<link rel="prefetch" href="<URL>">というのもあって、DNSに限らず、任意のリソースをプリフェッチできます。

（筆者注: DNSプリフェッチでウェブページの読み込み速度をスピードアップ、Link prefetching FAQ）

矢倉 あと、プリロードという仕組みもあります。<link rel="preload" href="/styles/other.css" as="style"> のように指定して、リソースの先読みを行えます。

（筆者注: 仕様書によると、prefetchとpreloadの違いは、前者が必ずしも先読みされるわけではなく、低い優先度で先読みされるのに対し、後者は強制的、高い優先度で先読みされる）

矢倉 使うといいと思うのが、CSSファイルに書かれているWebフォントや画像でしょうか。ほとんどの場合、それらのファイルは読み込まれるのがわかっているので、それらをプリロードすると、CSSファイルの読み込みを待たずにダウンロードできます。

白石 他にお聞きしたいことがあるとすると、Service Workerのオフラインキャッシュとかです。これはどんどん使っていくべきでしょうか？

矢倉 自分自身まだ使ったことがないので、あまり語れませんが…Progressive Web Appsの文脈で、App Shellという、アプリの「ガワ」をService Workerにキャッシュさせて、最初の描画（First Paint）を速めようという話がありますね。

川田 ただ、キャッシュの更新方法についてもきちんと設計しないと酷いことになりますよね。Webアプリケーションにおけるデプロイを、Service Worker側でどのように扱うのかという問題。サーバー上のリソースが更新されたときに、ブラウザ側へどのように反映するのか。複雑化は避けられないですよね。

白石 確かに。それもあって、ぼくらも自分たちのサービスでは、Service Workerのキャッシュを利用するコードまでは用意したのですが、結局有効化してないです。

最後に、竹洞先生からひとこと

白石 では、だいぶお時間もかかってしまったので、まだまだお聞きしたいことはあるのですが、そろそろ締めに入りたいと思います。最後に、読者の皆様に伝えておきたいこととかありますか？

竹洞 じゃあ、最後に一つだけ。サーバの転送量削減についての目安ですが…。

白石 はい、お願いします。

竹洞 モバイルだと、全体で200kbを超えるページは、配信に3秒以上かかってしまいます。転送量削減については、これを目安にするのはいいのではないかと思います。

白石 えっ、200kbですか？クライアントにキャッシュされているリソースがあることは期待していいんですか？

竹洞 いえ、キャッシュなしで。先ほどもありましたが、モバイルだと、あんまりキャッシュが期待できないので。

ほか全員: (マジか…つらい…)

竹洞 頑張ってくださいね（ニッコリ）