『大規模メディアにおけるWeb開発の最前線』と題して、ニジボックス主催のオンラインイベントを行いました！
ニジボックスのマネジャーであり、Node.js日本ユーザーグループ代表を務めている古川陽介さんや、同じくマネジャーである新井智士さんなど、リクルートの大規模メディアに携わるエンジニア4名が登壇。Web　Performance/Accessibility/ Availabilityについて、熱く語っていただきました。

今回、参加者には事前にSlackチャンネルを共有し、質問や感想があればチャンネル上に随時投稿できるスタイルに。投稿内容が配信画面にもリアルタイムで共有される、ニジボックスのエンジニアが開発したコメント表示機能を採用しています。メディア開発に興味のある方、Webパフォーマンスの改善で頭を悩ませている方、スピードハッカソンをどのように活用しているのかを知りたい方に向けて開催した本イベント。ニジボックスのエンジニアのワークスタイルもイメージできる内容になっていますので、リクルートの大規模メディアでの開発業務に興味のある方はぜひ、ご参考になさってください！

フロントエンドエンジニアの能力は、非機能要件で決まる。リクルートで実際に行ってきた施策を紹介。

「非機能要件を文化に」と題して登壇したのは、古川陽介さんです。
複合機メーカーやゲーム会社を経て2016年にリクルートへ入社し、プロダクト開発室でアプリ基盤の改善や運用、各種開発支援ツールの開発、エンジニアの支援や育成までを行い、現在ニジボックスのクリエイティブ室でマネジャーを兼務しています。Node.js 日本ユーザーグループの代表としても知られる古川さん。今回は非機能要件の大切さや、その取り組みを文化として定着させるために行ってきたことについてお話ししました。

エンジニアの腕の見せどころ「非機能要件」とは

機能要件とは、実装しなければならない基本的な機能のことで、ユーザーからの要求を叶えるためのものです。それに対し非機能要件とは、必ずしも実装しなければいけない訳ではありませんが、プロジェクトの質を向上させるために必要な機能のことです。
セキュリティ面で言うとXSS・XSRF・DoS、パフォーマンス面で言うとSPA・PWA・AMPなどが挙げられます。
機能要件を満たした上で、期日に追われる中、どこまで非機能要件を入れ込むことができるか、そこがエンジニアとしての腕の見せどころです。さらに、この非機能要件を文化にし、一時的な対策だけでなく恒久的に続けていくことが必要です。

リクルートとニジボックスで行ってきた試み

ニジボックスのフロントエンドエンジニアは、リクルートのエンジニアと協業し、リクルートグループが運営する数々のメディアを高速化し、ユーザビリティを向上させる活動を行ってきました。

一例を挙げると、『SUUMO』では性能の定点観測ツールを作成し、競合との差分を定常的に比較。『AirSHIFT』では、クライアントを直接訪問し、速度が遅くなっていた原因を突き止め、改善。『ホットペッパービューティーコスメ』では、AMPファーストなサイトを構築し、パフォーマンスを改善しながらノウハウが全体に浸透するような施策を行ってきました。

しかし、プロダクト品質を改善しただけでは道半ば。この改善施策を継続的に続け、ビジネスゴールにつなげてこそ成功と言えます。リクルートやニジボックスでは、この非機能要件が文化になりつつあります。

非機能要件を文化にするために取り組んできたこと

いきなり場当たり的に改善を行うのはNG。非機能要件を上げていくには戦略が必要です。そこで重要なのが、可視化です。
『AirSHIFT』では、ユーザーの実際の操作を基に、表示にかかる時間を見える化しています。数値が見えると、自然と改善したくなります。ダイエットと同じで、数値を測り続ける習慣を作ることが重要です。さらに測り続ける習慣が定着したら、その後の改善も習慣として継続的に行っていきます。
しかし、パフォーマンス改善を継続的に行うにはメンバーの能力向上も必要不可欠。そのため私たちの現場では、メンバーの育成もセットで考え、一時的な改善で終わりにしない取り組みを行ってきました。

一つ目は、「ゲーミフィケーション」です。ゲームの個体値グラフのようなスキルマップを一人ひとりに作成し可視化することで、ゲーム感覚でスキルアップを目指せるように工夫しています。
二つ目は、「スピードハッカソン」です。フロントエンド領域だけでどこまでLighthouseのスコアを上げられるかを競うのですが、実践形式で短期的なスキルアップが期待できます。

楽しく継続的に学んでいける仕組みづくりを行うことで、エンジニアの育成を行っており、非機能要件を文化にする取り組みを今後も続けていく予定です。

◾古川さんの登壇資料はこちらです！『非機能要件を文化に』

SUUMO開発現場におけるパフォーマンス改善とは？施策と改善結果をリアルに紹介。

「SUUMOでのパフォーマンス」と題して登壇したのは、リクルートでWebアプリケーションの開発・設計に携わりながら、ニジボックスのクリエイティブ室でマネジャーを兼務する新井智士さんです。
新井さんは現在、リクルートの住宅系メディア『SUUMO』の開発現場に所属し、パフォーマンスのモニタリングを中心に、エンジニアの育成と中長期でのアーキテクチャ方針の検討やプロダクト開発を担当しています。今回は開発現場におけるパフォーマンス改善の実際の取り組みや、その成果などについてお話ししました。

『SUUMO』の歴史とパフォーマンス

『SUUMO』は、国内最大級の不動産情報サービスです。2009年にスタートした歴史あるメディアで、近年はどうしてもパフォーマンスが落ちている箇所が出てきていました。そこで、2年ほど前から主要なページについて継続的に計測し、大きな劣化がある場合には検知してアラートを出すようにしています。週次でレポートを作成し、スピードハッカソン形式で改善を行ってきました。

パフォーマンス改善に取り組むべき理由

なぜ、パフォーマンス改善が必要なのでしょうか。それは、単に性能が落ちてきているからだけでなく、ユーザーが「ページが早く読み込まれるかどうか」を重視しているからです。Googleの調査によると、デザインや使い勝手の良さを抑え、ユーザーはページを読み込む速度を一番気にしているという結果が出ています。
さらに2018年、Googleのアップデートでページの読み込み速度がモバイルの検索順位に反映されるようになり、ますますパフォーマンスの重要性が高まっています。

『SUUMO』での実際の改善施策とその結果

『SUUMO』では、パフォーマンスバジェットの設定や性能改善のためのスピードハッカソンを軸に、予防・維持・改善という活動を行ってきました。最初に、実際に行ってきた改善活動例を二つ紹介します。
一つ目は、CSSの最適化です。これにより、性能がぐんと向上しました。
二つ目は、ページローディングの仕様を改善した施策です。一度に全ての画像を読み込むのではなく、表示するものだけを都度読み込む仕様に変更したことで、表示速度が改善されました。

次に、過去２年間でアラートが出た時の印象的な事例をいくつか紹介します。
一つ目の事例です。アラートが出たため数値を見てみると、前日に比べて点数が劣化し、読み込みサイズが大幅に増えていました。原因を調べてみると、最適化されていない画像があったのです。1ファイルで２GBある画像もあり、それがパフォーマンスに影響していました。運用を徹底することで、今ではこのような問題は起きていません。
続いてもう一例。こちらのアラート検知では、スクリプトが増加し、Speed Indexも悪化していました。この現象は、広告タグの追加が要因となっていました。

サービスの拡大と共に性能の劣化要因のリスクも多くなります。多くのユーザーに利用してもらうサービスにとって、改善の第一歩としてパフォーマンス状況の可視化とモニタリングはとても重要だと考えています。

◾新井さんの登壇資料はこちらです！『SUUMOでのパフォーマンス』

スマホユーザーが圧倒的に多いサイトの開発現場における、パフォーマンスを極限まで高めるためのチーム作りと環境整備。

「モダンWebパフォーマンス」と題してお話ししたのは、ニジボックスのフロントエンジニア、入澤佑紀さんです。入澤さんは現在、リクルートのコスメ口コミサイト『ホットペッパービューティーコスメ』の開発に携わっており、立ち上げからリリースまでを経験。その傍ら、グループリーダーとしてエンジニアの育成も行っています。今回は、サービスサイトのパフォーマンス改善についてや、パフォーマンスを高めるためのチーム作りについて語りました。

『ホットペッパービューティーコスメ』が速さにこだわる理由

『ホットペッパービューティーコスメ』の現場では、表示速度にこだわって日々開発・運営を行っています。なぜ速度にこだわるのかと言うと、本サービスは圧倒的にスマホユーザーの割合が高く、移動中や屋外での表示速度が特に求められると考えているからです。
Googleが公開したレポート（※1）によると、UXにおいてユーザーが重視する要素の75％は表示速度という結果が出ています。また、サイトの表示速度はGoogleの検索順位にも影響する（※2）との報告もされています。そのため、後発サービスが検索順位を上げていく際の大切な要素となります。

◾参考資料
※1　BRAINFOOD! vol.3 for Didital Creatives, SPEED MATTERS Designing for Mobile Performance, Google AWWWARDS
※2　Google Developers Japan モバイルページのスピードに関する新たな業界指標

『ホットペッパービューティーコスメ』の改善施策

Googleが推奨する、Webサイト閲覧を高速化することに特化したフレームワークにAMPというものがあります。しかし、AMP化したからと言って必ず速度が速くなるわけではありません。例えば、サイズの大きな画像を最適化するなど、地道な改善も積み重ねながら速度向上に努めています。

改善を文化にするためのチーム、環境作り

パフォーマンス改善を文化にするためには、開発に携わる全てのメンバーがその重要性を理解しなければなりません。例えば、私たちの現場では、自身の専門職域では解決できない部分は他の職域のメンバーと積極的に連携して業務を進めています。そんな環境で意識合わせを頻繁に行う中で、共通認識が生まれ文化として根ざしてゆくと感じています。
ここまでお話すると、現場のメンバー全員が経験豊富なエンジニアだからでしょう？ と思われるかもしれませんが、そうではありません。開発に携わる5人のフロントエンドエンジニアのうち、Reactの経験も豊富なメンバーが二人いるものの、実務でReactを触るのはほぼ初めてのエンジニアが二人、入社３ヶの新人エンジニアが一人という体制です。
つまり、全員がリードエンジニアでなくても、仕組み作りができていれば、パフォーマンス改善を文化にすることはできるのです。

Lighthouse CIで日々自動的にパフォーマンスを計測。さらには、パッケージ更新管理の自動化を行うRenovateというツールを活用し、継続的な業務の効率化も実施。メンバーの能力を向上させる取り組みとしてモブプログラミングを週2で開催し、分からないことを放置しない仕組みを作るという取り組みも行っています。その結果、チーム内でパフォーマンス改善が文化になりつつあります。

◾入澤さんの登壇資料はこちらです！『モダンWebパフォーマンス2020』

最前線のWeb開発の重要キーワード「アクセシビリティ」にどう取り組むか。

「アクセシビリティ」についてお話ししたのは、フロントエンドエンジニアの軽部勝仁さんです。アクセシビリティの考え方や開発現場の最前線で実際に行ってきた取り組みについて紹介しました。

そもそもアクセシビリティとは

Webアクセシビリティとは、Webページにある情報や機能の利用しやすさのことです。
具体的には、ボイスオーバーなどのスクリーンリーダーで読み上げられるようなシーン。アクセシビリティが配慮されていないHTMLだと、ただ単に文字が読み上げられるだけで、耳から入る情報だけでは必要なことが伝わらないことがあります。

このように、アクセシビリティには目、耳、Webサイトを見る状況など、さまざまな切り口があり、そこには国際的な達成基準WCAGがあります。
多様な人、デバイス、環境で見る可能性があるWebサイトには、アクセシビリティは必要不可欠です。

開発現場のアクセシビリティ

「送信に失敗しました」というエラー表示を、Webサイト内に作成するとします。その場合、エンジニアが見る仕様書には「最大256文字の動的テキスト」「エラーが起きた時に表示」「『閉じる』ボタンをクリックすると非表示」という基本的な定義にとどまり、アクセシビリティ要件までは定義されないことが多いです。
ここにアクセシビリティを考慮した要件を付け加えると、「role="alert"をつける」「『閉じる』ボタンがbuttonとして認識される」「Tabキーで『閉じる』ボタンにフォーカス」「『閉じる』ことができるということが明示される」など複数要件が出てくるでしょう。
アクセシビリティは、仕様書を見て実際に開発するエンジニアの力量によって完成度が大きく変わってくると考えています。

実際に行ってきたアクセシビリティ改善の取り組み

WCAGに適合しているかどうかをチェックするツールは複数あり、Lighthouseをはじめ、URLを入力して計測するツール、外部からCSSを挿入してハイライトするツールなどが挙げられます。しかし、ツールには限界があり、人の手でチェックすることも求められます。例えばカラーコントラストのチェックなどをはじめとし、自動化できることはツールに任せ、人が考えられる時間を増やすことが効率的にアクセシビリティを改善する方法です。

ここからは、ツールでのチェックをさらに飛躍させた実例をご紹介します。
私が携わる現場ではStorybookで開発を行い、Reactのコンポーネントを投稿してカタログのように管理しています。Storybookにはstorybook-addon-a11yというアドオンがあり、コンポーネントごとにWCAGに適合しているかをチェックすることができます。しかし、このアドオンは全体管理が難しいことが難点でした。そこで、アドオンが出すエラーを網羅的にレポートしてくれるCLIツールを作成し、簡単に全体的な管理をすることで、エラーが無い状態を維持できるようになりました。
このように、ツールに任せられるところは任せたおかげで時間が増え、人力が必要な部分に注力できるようになりました。

ニジボックスのエンジニアはリクルートの各部署で常駐しているメンバーが多いですが、作業者としてもくもくと仕事をこなすだけのエンジニアという役割ではなく、開発メンバーの一人として誇りを持って仕事ができる環境にいます。私がこのようにアクセシビリティに注力できることも、そのおかげです。

今後は、アクセシビリティ改善を文化にしていきたいと考えています。

◾軽部さんの登壇資料はこちらです！『アクセシビリティ』

「アクセシビリティを文化に」その目標に向けて

全4名の登壇終了後は、質疑応答の時間へ。
「アクセシビリティ改善を文化にしていきたいという話がありましたが、エラーの検知以外で始めている取り組みはありますか？」という質問に対し、
軽部さんから「Storybookによってエラーを検知できるようになったのは、ベースラインができたという段階。スクリーンリーダーを実際に使ってみて見えてきたものもあり、このように人の手で判断し改善していくという作業を進めています。今後は社内勉強会なども行い、文化を築き上げていきたいです」との回答が。
加えて古川さんも「アクセシビリティに関してはまだまだ社内でも浸透しきっていません。ですが、課題であるということには社内も気付いているはずなので、軽部さんのような個人からの働きかけと、会社的な働きかけ、両面でアクセシビリティ改善を文化にする取り組みを進めていかなければと思っています」と語りました。

パフォーマンス改善に関してはリクルート、ニジボックスでは文化になりつつあります。
Webサイトを運営していくことや、非機能要件もこだわるということに対して、さらなる気づきも得られ、参加いただいた方も含め、登壇者にもとても良い機会となったのではないでしょうか。

当日の配信動画はこちらです！

「大規模メディアにおけるWeb開発の最前線」

ニジボックスメンバーのQiita記事も更新中！

「社内のリモートイベントを盛り上げるツールを作ったら予想以上に好影響があった話」@Kontam