地道だけど重要な「Webパフォーマンス改善」をいかに進めるか？ヤフーとリクルートにおける社内横断的な改善の取り組み

今なぜ「Webパフォーマンスの改善」が重要なのか、その意義と効果的な進め方を考える

2022/03/18 12:00

　企業の「Webパフォーマンス」に対する意識が、ここ数年の間に大きく変わりつつあります。特にGoogleが、検索ランキングの指標となる「Core Web Vitals」を発表し、その構成要素のひとつに「Webパフォーマンス」を挙げたことから、UX向上の観点だけでなく「検索順位の向上」というビジネス的な観点からも、優先度の高い課題と認識されるようになっています。今回、プロダクト横断でWebパフォーマンスの改善に取り組んできた、ヤフー浜田真成さん、リクルート古川陽介さんの2人に、その意義や活動の効果的な進め方について語っていただきました。

全社的に「Webパフォーマンス改善」に取り組む2人のエンジニア

浜田：ヤフーの浜田です。2015年の入社で、動画配信サービスの「GYAO!」や、映画情報サービスの「Yahoo!映画」などで、主にフロントエンド領域を担当してきました。現在は、CTO室で、全社横断でのWebパフォーマンス改善プロジェクトに取り組んでいます。また、ヤフーには「黒帯」という、技術分野ごとのスペシャリストを認定する制度があるのですが、2021年度には第11代「Webフロントエンド」黒帯を務めています。

　今日は、自分がエンジニアとして仕事を始めたころから憧れだった古川さんとお話ができるということで楽しみにしてきました。よろしくお願いします。

古川：こちらこそ、よろしくお願いします。ヤフーの黒帯制度については知っていましたが、Webフロントエンド領域にも黒帯の方がいらっしゃるのですね。

浜田：この領域に黒帯ができたのは、比較的最近ですね。通常、黒帯は各領域に1人ずつなのですが、2021年度のWebフロントエンド黒帯は、特別に2名が任命されていて、私はそのうちの1人です。古川さんは、最近リクルートでどのようなお仕事をされているのでしょうか。

古川：肩書きとしては、アプリケーションソリューショングループのグループマネージャーで、シニアソフトウェアエンジニアを兼任しています。主にNode.jsやフロントエンド周りについて、グループ内で困りごとがあれば、エキスパートとして話を聞いたり、一緒に手を動かしたりしながら解決策を見つけています。

　専門知識を社内に展開するだけではなく、実際に現場と一緒にアプリケーションを作りながら、ナレッジをプロダクトチームに根付かせることや、そこでの課題を吸い上げてライブラリ化し、全体に形式知として共有することなどを意識しています。

　あと、最近では、リクルートグループの「ニジボックス」という会社で、デベロップメント室の室長兼開発リーダーも務めており、UXデザインのコンサルティングなども手がけています。研究開発と、現場での開発を半々ぐらいでやっているという状況でしょうか。

浜田：開発組織のマネジメント的な仕事の比率も多そうですね。

古川：自分が実際に開発するのは、アプリケーションよりも、アプリケーションで利用するライブラリが中心になっています。あとは、研究開発全体の方向性を決めるようなことをしていて、開発の中心になるのは主にグループのメンバーですので、たしかにマネジメントの比重は大きくなってきていると感じます。

社内で「パフォーマンスへの意識」をどう高めるか

――Webパフォーマンスの改善について、ヤフーとリクルートでは、それぞれどのような取り組みをしてこられたのでしょうか。

浜田：ヤフーには、大規模なものから小さなものまで、多くのサービスがあります。私が推進しているWebパフォーマンス改善プロジェクトでは、その中から30以上の対象サービスについて、それぞれのパフォーマンスを計測して可視化し、改善策をレポートしています。

　小規模なサービスでも、コードレベルまで見て「こうするとパフォーマンスが出ますよ」とアドバイスしてまわる感じで、作業としては地味ですね。ただ、実際に現場が対応してくれれば、目に見える数値も上がってきますので、やりがいがあります。

浜田真成（はまだ・まさなり）氏

　ヤフー COOメディア統括本部メディア開発本部開発9部開発1 リーダー。2015年に入社し、動画配信サービス「GYAO!」でフロントエンド領域を中心とした技術リードを担当。現在は、全社横断でのWebパフォーマンス改善プロジェクトを推進している。2021年度第11代「Webフロントエンド黒帯」。

古川：リクルートでも、だいたい同じような感じです。Webパフォーマンスの改善に関わる活動は、最初は特定のサービスで、ゲリラ的にボトムアップで始まりました。

　特に早い時期から始めていたのは、不動産情報サービスの『SUUMO』ですね。パフォーマンスを定点観測できるツールを作り、常に状況を計測しながら、レギュレーションよりも数値が落ちていたら、原因を探して対応していました。そこで蓄積した知見は他のサービスへ横展開していきました。

　2020年以降に、Googleが「Core Web Vitals」を検索ランキングの指標にしていくと発表し、パフォーマンス改善が注目を浴びるようになってからは、各サービスからアセスメントの依頼が来るようになり、問題をいくつかまとめて改善することもやりました。以前からの取り組みで蓄積してきた知見が生きて、ここ1～2年は特に有意義な活動ができているように思います。最近の改善活動については、リクルートのメンバーズブログにも記事としてまとめています（参考：Core Web Vitals に対応するため、各サイトの改善活動を実施しました）。

　リクルートとヤフーは、展開しているサービスの数が多い点で似た状況があると思うのですが、個別のサービスだけではなく、全社で組織的にパフォーマンス改善を進めていく上で、課題に感じていることはありますか。

浜田：サービスによって、パフォーマンス改善に対するプライオリティや意識にかなりばらつきがある、というのは当初感じました。開発側が意識をしていないと、パフォーマンスが上がらず、結果としてUXも良くならないので、組織としての意識合わせは大切だと感じます。全社横断的なWebパフォーマンス改善プロジェクトは、サービスごとの意識のギャップを埋めて、全体的に底上げを図る意味でスタートした取り組みでもあります。

　特に、先ほど古川さんが触れられた「Core Web Vitals」が発表されてからは、Webパフォーマンスがビジネス面でも大切な要素のひとつと認識されるようになり、経営陣を含めて意識が変わった印象があります。

古川：一般的な話として、長く運営されているサービスほど、どうしても前例に従った継続運用が優先されがちで、パフォーマンス改善についてのプライオリティは低くなりますよね。運用の歴史が積み重なると、サーバサイドにも、フロントエンドにも、パフォーマンスを悪化させる要因がたまっていきます。

　フロントエンドは特にそれが顕著で、例えば「ABテスト」をやるときに、AとB両方のデザインを同じCSSファイルに含めてしまい、テストを終えた後も、未使用のコードを残したままにしてしまうケースなどがあります。これを後から改修しようとすると、単に記述を消せば済むという話ではなくて、ページが表示される際のモーダルに影響がないか、各記述が本当にいらないものかなどを確認する必要があり、とにかく大変です。

　1回作ったものは、継続してメンテナンスすることが必要で、作るときからそれを前提としておかなければならないという意識を、組織全体に根付かせるのはかなり苦労しました。

浜田：ヤフーの場合は、古くからあるサービスの一部で、フロントエンドのモダン化が遅れていたものがあったのですが、ある時CTOの号令で、全社的なアーキテクチャ刷新のプロジェクトが始動しました。この刷新のプロジェクトとタイミングが合致したサービスは、フロントエンドの刷新にWebパフォーマンス改善の内容も取り入れて開発され、結果として速度改善が見られたサービスは多かったです。その際に採用された、Next.jsを始めとするパフォーマンスが考慮されたフレームワークによる恩恵も多くあります。

古川：大規模なリアーキテクトが全社的なプロジェクトとなったことが、Webパフォーマンスの改善の良いきっかけになったのですね。

　われわれも、大規模、小規模な改善をいろいろとやってきたのですが、件数で言えば「肉体改造」のような大規模なリアーキテクトよりも、CSSやJavaScriptのスリム化、画像のサイズ見直しといった小規模な「ダイエット」をするケースが多かったと思います。もっとも、サービスによっては小手先のダイエットでは、どうにもならないケースもあったので、それについては、一つずつ問題を見つけ出して潰していくというストイックな対応を続けています。

改善は「トップダウン」と「ボトムアップ」のどちらが効果的？

――Webパフォーマンスを改善するにあたって、具体的にどのような方法をとっていますか。手法や事例を教えてください。

浜田：実際に私がやっているのは、サービスごとのパフォーマンス計測と可視化。合わせて、改善のためのアドバイスを現場に伝えるということですね。具体的には、WikiツールのConfluence上に、パフォーマンスの計測状況を一覧表示しています。

　Google Lighthouseのベンチマークを、競合サービスとの比較でグラフ化し、Core Web Vitalsを構成するLCP（Largest Contentful Paint）をはじめとする指標を100点満点でスコアリングして、日次で見られるようにしました。

　そこに、こちらで見つけた問題点と、改善のための具体的な改善策を書き加えて、各サービスのチームと連絡を取りながら作業を進めてもらうという感じです。ただ、私にできるのはアドバイスまでで、それを実行するかどうかは、サービス側に委ねています。そのため、対応状況に差が出てしまうのが難しいところです。

古川：この可視化の仕組みは素晴らしいですね。対応指針が具体的なタスクにまで落とし込まれているようですが、可視化された状況から、実際の改善作業につなげる部分は、私も難しいと思っています。

　こうした改善を進めるときのアプローチとしては「トップダウン」と「ボトムアップ」の2パターンがあると思います。「トップダウン」は、ガイドラインやチェックリストのような形式で全体の型を決めてしまい、それに準じてもらう進め方。「ボトムアップ」は、それぞれの現場で、サービスの問題点を見つけ出し、改善する進め方です。

　これまでパフォーマンス改善を進める中で感じたのですが、「トップダウン」は「ボトムアップ」と比べて、効果がそれほど高くないようです。ガイドラインを作っても、形骸化が早いというか、結局は現場のモチベーションを高めて、維持していくほうが、成果への影響がより大きいと思うのです。

古川陽介（ふるかわ・ようすけ）氏

　複合機メーカー、ゲーム会社を経て、2016年にリクルートテクノロジーズ（現リクルート）入社。シニアソフトウェアエンジニアとしてWeb開発をけん引し、現在ではマネジメントも担当する。Japan Node.js Association代表理事、Node.js Core Collaboratorとしても活動。

　私が工夫としてやっていたのは、「ハッカソン」です。リクルートでは「スピードハッカソン」と呼ばれている、全社で丸1日を使って行うハッカソンイベントがあるのですが、そこで、パフォーマンス改善をテーマにしました。「お祭り感」のあるイベントとしてパフォーマンス改善に目を向けてもらうことで、現場のモチベーションを高め、実際のサービス改善につなげていってほしいという試みです。

　パフォーマンスは、結果が見えやすい領域でもあるので、実際に改善される様子を見て「参加して良かった」と言ってくれるエンジニアも多かったですね。ガイドラインとチェックリストをベースにしたトップダウンの進め方だけだと、どうしても「健康診断」のようになってしまい、現場のやる気を高めるところまでは到達しづらいかもしれないです。ちなみに、こうした「イベント化」によるモチベーションアップは、私がエンジニアリングコミュニティから学んだ手法です。

浜田：ハッカソンのようなエンジニアが能動的に参加するイベントは、一方的にパフォーマンスを「診断される」のと違い、現場の意欲向上に効果がありそうですね。

古川：もっとも、こうしたイベントに参加するには、現場にもある程度の余裕が必要なのですよね。それが難しい現場では、やはり個別にアセスメントして、改善を促すのが現実的だと思います。

　それとは別に課題に感じているのは、Google Tag Managerなどでコードに挿入される「サードパーティスクリプト」の扱いです。「Webパフォーマンス改善」の観点だけに立てば、これらを削減していくことは正当な対応なのですが、ビジネスとして見た場合に、各スクリプトがどうビジネスに寄与しており、効果を生んでいるのかは、開発者の視点だけでは判断できないことも多いのです。

　このあたりを整理しようとし始めると、ビジネス面でのステークホルダーにも動いてもらう必要があり、一気に対応のスピードが落ちます。このあたり、ヤフーではどのように進めていますか。

浜田：サードパーティスクリプトの課題はヤフーでも感じています。タグマネージャーは、管理が開発側ではなく、広告や宣伝の担当です。これらの改善は、サービス間をまたぐために改善を運用にのせることが非常に難しい課題があります。一部サービスでは、担当者にアプローチして見直しをしてもらい、既に使っていないものや、期限切れのものを削除するような取り組みを地道に進めた経験もあります。

　その後、挿入したいタグについては、広告や宣伝側で直接挿入するのではなく、開発側に依頼して入れてもらうよう、作業のプロセスを変えました。いわゆる「パフォーマンスバジェット」のような考え方を取り入れて、Webパフォーマンスとタグの効果のバランスを考えつつ、期間を決めて入れるようなワークフローを作っています。

古川：開発、営業、広告の各担当で、サービスやリソースへの視点が異なるというのは避けられないのですが、同じ方向を向いて対処していくにあたって「パフォーマンスバジェット」を取り入れるというのは良いですね。

　パフォーマンスバジェットは、サービスのパフォーマンスを、SREにおける「エラーバジェット」と同じようなスキームで見ていこうというやり方で、開発以外の担当者にも理解しやすい概念だと思います。リクルートでも、パフォーマンスバジェットについての説明会を行って、「Webパフォーマンスは、ビジネスの予算と一緒。やりたいことはいっぱいあるかもしれないけれど、有限のリソースであり、使い放題ではない。きちんと計画を立ててモニタリングしていかないと、サービス自体が大変なことになる」ということを、開発だけでなく、より多くの担当者に理解してもらう機会を作りました。

　Core Web Vitalsは、Webパフォーマンスの問題に企業全体で向き合うきっかけになった点では良かったと思っています。タグマネージャーは「開発に依頼しなくても、スクリプトタグの挿入をビジネス側で実行、管理できる」点がメリットでしたが、その裏では、システムリソースが消費されています。そこに生まれる、開発側とビジネス側の意識のギャップを可視化する、よいきっかけになったのではないでしょうか。

　もちろん、パフォーマンス至上主義に陥って、サービスに必要な要素以外はすべて削るようなことをすれば、何もできなくなり、テストやビジネスの面でも悪影響が出てくるでしょう。そこを「バジェット」という考え方でバランスをとっていこうというのは、うまいやり方だと思います。

Webパフォーマンスは豊かな広がりをもった技術領域

――「自社サービスのパフォーマンスに課題を感じているが、改善をどう進めればいいのか分からない」というエンジニアに向けて、アドバイスをお願いします。

浜田：一般的かもしれませんが、何となく「パフォーマンスを改善しよう」と考えるのではなく、現状のどこに問題があるのかを具体的に見つけ出すことから始めるのがよいと思います。Googleが公開している「Lighthouse」や「Search Console」のようなツールを使えば、状況を大まかに把握できますし、どこに手を付けられそうかの見当もつけられます。その上で、個別の課題に優先順位をつけて進めていくとよいのではないでしょうか。

古川：私も同意見ですね。Lighthouseは、Webパフォーマンスを点数化してくれるツールです。パフォーマンスに点数付けすること自体への是非はあるとは思いますが、まずは現状を数値として可視化することが、改善に向けた第一歩です。数値化された指標をゲーミフィケーション的に高めていくことが好きなエンジニアも多いですしね。

　そこで興味を持って、Webパフォーマンスをさらに究めたいと思った人は、『超速! Webページ速度改善ガイド ── 使いやすさは「速さ」から始まる』（佐藤歩・泉水翔吾著、技術評論社) という書籍を読んでみることをおすすめします。この分野について、日本ではかなり進んだことが書かれている本です。

　ネットワークレイヤに関しては『ハイパフォーマンスブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化』（Ilya Grigorik著、オライリージャパン）がおすすめです。今となっては、若干古い内容もありますが、「なぜネットワークは遅くなるのか」のエッセンスを知る上で、今でも参考にできる部分が多い名著です。

　このあたりの本を読み込むと、書かれているアドバイスの裏付けとして、Webブラウザやネットワークがどう動いているかが分かるようになります。そうすると、さらに深く面白い世界が広がりはじめます。

　ブラウザやネットワークそのもの仕組みが分かると、例えば、Webブラウザに実装される新しいAPIについて、それは現状のどんな課題を解決するために用意されるものなのかを理解できるようになるわけです。パフォーマンス改善をきっかけに、ブラウザやネットワークの領域に進むと、より深いフロントエンドエンジニアリングの世界に到達できます。興味がある方は、ぜひ目指してみると、面白いと思います。

浜田：そうしたフロントエンド領域の面白さは、私も感じます。Webパフォーマンスやブラウザ最適化といったテーマは、新しいWeb APIやPWA（Progressive Web Apps）のような、Webの最新の技術領域とつながっています。一口に「Webパフォーマンス」と言ってしまうと、非常に限られた分野のようなイメージがありますが、実際には豊かな広がりを持った技術領域なんですよね。

Webの進化を「気持ちの良いサービス」の提供につなげていく

――最後に、お二人がWebパフォーマンスの領域で、今後どんなテーマに注目をされているのか。それに関連して、どんなチャレンジをしていきたいかについてお聞かせいただけますか。

浜田：Webパフォーマンスの改善というテーマは、サービスを提供する企業や開発者にとって、今後、さらに身近なものになっていくと思います。GoogleがCore Web Vitalsという指標を作ったことは、開発以外の部門がWebパフォーマンスを意識するきっかけになりましたし、今後、よりビジネスやUX（使いやすさ）の観点とのデータの紐付けが強化され、全員がパフォーマンスについて意識する方向性は強まっていくだろうと感じています。

　現状のCore Web Vitalsは、「LCP」（ページの読み込み開始から表示までの時間）、「FID」（First Input Delay：ユーザーのアクションに対する反応までの時間）、「CLS」（Cumulative Layout Shift：レイアウトずれのような視覚的な安定性）の3つの指標から構成されていますが、その内容や基準は変わっていくと、Google自身も明言しています。

　この先、特に変わっていきそうだと私が感じているのが、タップなどのユーザー操作に対する応答性の部分です。Core Web Vitalsが、より本質的な意味で「ユーザーが、使っていて気持ちのいい体験」を計測できる指標になっていけばいいと期待しつつ、われわれもユーザーに「気持ちの良いサービス」を提供できるよう、改善を続けていきたいと思っています。

古川：Webパフォーマンスの考え方も、時代と共に変化します。例えば、2000年代にはユーザーがアクセスしてから、ページが見えるようになるまでのスピードだけが「Webパフォーマンス」だったのですが、Core Web Vitalsによって、操作への反応性や、レイアウトの安定性なども、その一部として意識されるようになりました。

　これからは「ユーザーが操作しながら感じる快適さ」が、Webパフォーマンスの指標として、今まで以上に重要視されるようになってくると思います。「すぐに見える」ことは当たり前で、そこからのUXやパフォーマンスが大切になるということですね。それを念頭に置いて、技術へのキャッチアップと改善活動を続けていきたいと思っています。

　関連して、今後の動向に関心を持っているのは、エッジでのHTML生成です。Next.jsやRemixのようなフレームワークも、それを意識した動きを見せているのですが、CDN（Contents Delivery Network）のような、エッジにあるサーバ上に、単なるコンテンツキャッシュを置くだけではなく、「ワーカー」と呼ばれる仕組みを乗せ、そこでHTMLを作成して、クライアントに返そうとする人が増えています。

　世界中に散らばっている、ユーザーにより近い、エッジでのコンピューティングが市民権を得ると、コンテンツが表示されるまでの時間、操作中のUXの向上といったパフォーマンス改善の取り組みも、さらに別の視点から、いろいろなことができるようになるのではないかと期待しています。

　今日は、ヤフーがWebパフォーマンスの改善に、どのように取り組んでいるかを伺えて、とても良かったです。以前から興味はあったのですが、なかなか聞くことができなかったので、良い機会になりました。実現可能性は別にして、ヤフーとリクルートの合同で、お互いのサービスを改善し合うようなイベントができたら面白いかもしれませんね。

浜田：それは面白いですね。いつかぜひ企画できたらと思います。こちらこそ、本日はどうもありがとうございました。

著：高橋美津