生産性の爆上げにも注力している
林仁氏（以下、林）：これまで「爆速のユーザー体験のための取り組み」を紹介してきましたが、次は、「爆速の開発者体験への取り組み」も紹介したいと思います。
実は、日経は2022年に開催された「JSConf 2022」のスポンサーをやっており、そこのスポンサー紹介文にこんな文章があります。
ちょっと時間がないのでかいつまんで読み上げると、日経といえば爆速の電子版というブランドイメージがありますが、昨今では生産性の爆上げにも注力しています、うんたらかんたら、みたいな感じのことを書いてあります。
本セクションでは、その爆速の生産性実現のための、爆速の開発者体験における取り組みを紹介します。
なぜ“爆速の開発者体験”の実現に取り組むのか？
まず、爆速の開発者体験を実現するモチベーションについてお話ししたいと思います。
私たちWebチームが担当するコードベースは、先ほど紹介した2017年に刷新された電子版を引き継いでいるのですが、どうしても歴史あるコードベースのため、ところどころ生産性に支障をきたすような技術的負債が存在しています。
先ほどもお話ししたとおり、開発対象サービスが多く、それに比例して多くの人員で開発されているため、こうした技術的負債がチーム全体の生産性にもたらす影響は大きくなってしまっています。
開発者体験を向上して、チームとしての生産性を改善することは、ある種新しいサービスの開発や、より良いユーザー体験を実現するための開発をより速いサイクルで回すために必要な土台であると言えるでしょう。
取り組み1 アプリケーションパフォーマンスの外形監視
それでは、爆速の開発者体験のための直近の具体的な取り組みをいくつか紹介していこうと思います。
まず、アプリケーションパフォーマンスを外形監視できる基盤をリブートしています。
もともと日経電子版には「SpeedCurve」が導入されており、外形監視自体もできてはいたのですが、チームであまり意識されていない状況が続いていたため、SpeedCurveによるレポーティングにデプロイピンを立てて、パフォーマンスリグレッションが生じた時などに、どのリリース起因でそれが生じたのかをわかりやすくしました。
あとは、開発中に「Lighthouse CI」や、クライアントに配布するJavaScriptのバンドルサイズ「通知する GitHub Action」などをCI上でプルリクエストごとに実行するようにして、開発者が開発中にパフォーマンスリグレッションに気づきやすい環境を整えました。
また、リアルユーザーモニタリングも導入しています。実際のユーザー環境でのパフォーマンスメトリクスも収集されるようにしており、かつ競合他社と比較して日経の電子版のパフォーマンスはどうであるのかなどの設定を見直しビジュアライゼーションしてあげることで、開発チームだけでなく、上層部や横のレイヤー……組織中の別の開発チームまでアプリケーションパフォーマンスへの意識が向上する効果を実感しました。
取り組み2 ビルドパフォーマンスの改善
次に、ビルドパフォーマンスの改善の取り組みについても紹介します。
電子版は、コードベース自体のサイズがかなり大きいため、ビルドやテストにかなりの時間がかかってしまっていました。私が新卒で入社した2022年4月当時、試しに1サービスをビルドしてみたところ、130秒ぐらいかかり、「これ余裕でTwitter休憩できるじゃん」と驚いたのはちょっといい思い出です。
こうしたビルドパフォーマンスの悪さは、電子版開発チームの人数に比例して、チーム全体の生産性に悪影響を生じさせてしまうため、ビルドパフォーマンスの改善に取り組んでいました。
ビルドパフォーマンス改善のための最近の取り組みですが、単純にTypeScript、JavaScript、コンパイラ、トランスパイラを「Babel」から「SWC」へと移行することで、ビルドパフォーマンスの改善を図っていました。
事前の調査・計測によって、「SWCにすればビルドパフォーマンスは改善されるじゃん」ということはわかっていたのですが、JavaScriptのコンパイラが変わることで、開発者の予期せぬ変換などが行われて、それが起因でサービスが落ちたら嫌だなという心配があったため、SWCの導入はけっこう慎重に行いました。
まずフラグ付きで有効にするようにし、次に、開発者のローカル環境でSWCでビルドされるようにして、dev／staging環境で、SWCでビルドされるようにして、最後にようやく本番環境に投入する、という感じで順序立ててプログレッシブに移行を行いました。
結局事故はなく、現在では本番向けのビルドもSWCが用いられており、これのおかげで1サービスのビルドで、130秒ほどかかっていたのが、75秒ほどにまで改善されました。ちなみに、これ以外にも最適化にすることにより、今はもっと速くなっています。
SWCへと移行する最中にSWC本体のバグをいくつか見つけて、自分で直しちゃうかと SWCにいくつかpatchを投げられたのもいい思い出です。
取り組み3 「Fastly VCL」から「Compute@Edge」への移行検証
また、「Fastly VCL」から、Fastlyの提供しているCDN上でのネットワークエッジコンピューティングランタイムである「Compute@Edge」への移行の検証も行っています。
先ほどお話ししたとおり、電子版ではFastlyのCDNを大いに活用しており、ルーティングやキャッシュの制御のためにFastlyのVCL、Varnish Configuration Languageを使っているため、VCLで書かれたロジックも多く存在するのですが、こうしたプログラマブルな処理は、VCLで記述すること自体がけっこう難しく、しかもFastly Varnishの場合、ローカル環境でのVCLのデバッグもできないため、ローカル／CI環境でのテストもできません。ある種、電子版のCDNの部分はプロダクトの根幹を担う部分であるのにもかかわらず、メンテナンス性が非常に低いという、かなり重大な課題がありました。
JavaScriptやRustでCDN上での処理を記述できるCompute@Edgeを用いることで、そうしたメンテナンス性の課題を解消できないかと、現在移行について鋭意検証中です。
まだ実戦投入とまでは至れていませんが、法人プランである「日経電子版 FOR OFFICE」の社内報サービスや、「NIKKEI Financial」という金融情報を扱うサービスで、Fastly VCLからCompute@Edgeへの移行の検証が行われています。
これからも“爆速”を目指し続ける
ここでまとめに入ります。セッションのタイトルを「爆速の日経電子版開発の今」としましたが、その「爆速」を「日経電子版」にかけて、爆速の電子版を実現すべく日経電子版の刷新当時根づいていた“爆速の電子版”というブランドを守り抜き、日経電子版開発チームでは、今なお爆速の情報メディアを目指し続けて開発し続けています。
さらに、「爆速」を「開発」にかけて、爆速に日経電子版を開発するための取り組みとして、爆速の電子版というブランドの維持や更なるユーザー体験の爆速化のため、開発者体験の爆速化への取り組みも同様に行っています。
これで、日経電子版の取り組みについての私からの紹介は終わりにさせていただきます。ご清聴ありがとうございました。
「やりたい」と手を挙げたら信じて任せてくれる
司会者：林さん、どうもありがとうございました。
ご紹介にもありましたが、林さんは2022年4月に入社されたということで、まだ入社して1年も経っていない状況で今日発表をしていただいています。みなさんにとって、かなり有益な情報もご提供できたかなと思っているのですが、ぶっちゃけ今のチームの雰囲気はどうなのかなと思っていて、ちょっと聞いてみたいと思います。
林：そうですね。同じチームの先輩方も発表を聞いているので、「本音をしゃべってないんじゃないか、こいつ？」と思われるかもしれませんが、僕は、新卒としてどこの会社に入ろうかなと思って悩んでいた時に、仲が良かった、当時日経のWebチームに勤めていた先輩から、日経をお薦めされて、「あぁ、この人が言うなら本当にいい職場なんだろうな」と思って入社しました。
その人の言っていたとおり、本当にいい職場だと思っています。僕のような新卒のぺーぺーのクソガキの意見もきちんと聞いてくれますし、必要があれば一緒に議論したり、オンボーディングなどで助けも得られますし、けっこう信じて任せてくれるので裁量も大きいです。
例えば、先ほどスライドの中で紹介していたビルドパフォーマンスの改善で、SWCに移行した取り組みは、僕が8月から10月ぐらいまでの間にちまちま行っていたもので、「こういうことをやりたい」と言ったらやらせてくれるいい職場、いいチームだと思っています。あとチームの外でも僕に構ってくれる先輩がいるので、いい職場だなと思っていますね（笑）。
司会者：ありがとうございます。
さまざまな就業形態のメンバー20〜30名で開発をしている
司会者：質問がいろいろ来ているので、林さんにしていきたいと思います。チームも絡んできますが、「どれぐらいの人数で開発しているんでしょうか？」という質問です。
林：まず社員メンバーが10人に満たない程度です。そこに業務委託の方やインターン生の方が2、3人いて、協力会社の方を合わせてだいたい20人から30人といった人員構成で開発しています。
司会者：ありがとうございます。
FastlyのVCLでどんなロジックを書いているのか？
司会者：続いての質問です。「CDN、Edge周辺はほぼ触った経験がないので素人質問なのですが、現状のFastlyのVCLでどんなロジックを書いていますか？」という質問です。
林：いい質問ですね（笑）。例えば先ほど紹介した、パスを見てルーティングするというロジックはVCLで書かれています。
あと代表的なもので言えば、例えばオリジンサーバー。ここでトップページのサーバーや記事ページのサーバーから「404」とか「500」といった異常系のレスポンスが返ってきた時に、それぞれのサーバーから「404」用のページを返すのはちょっとしんどいので、それがHTMLへのリクエストのものであれば共通の「404」ページをクライアントに返してしまう。「500」ページをクライアントに返してしまうという共通化するための処理や、ロギングの処理などもCDN上で書いたりはしています。
司会者：ありがとうございます。
もともと技術周りでエンジニアリングをすることが大好きだった
司会者：それから、チャットで質問をいただきました。「林さんは、なぜ情報メディア開発の道に歩もうと思ったんでしょうか？」。これは個人的な質問ですね。
林：僕は学生の時からWeb畑の人間といいますか、Web技術周りでエンジニアリングをすることが大好きなWebっ子学生だったんです。入社する会社を選ぶ時もやはりWebの事業系会社になるなと思っていろいろ調べていたんですけど、僕はWebフロントエンドというよりは、もうちょっと原義のWeb寄りのHTTPがうんぬんとか、Web標準がうんぬんという話が好きで、日経はそういったWeb標準に興味がある方がすごく多い会社であるなと、過去の発表を見て思ったんですよね。
かつ、情報メディアサービスという、HTTPやWebスタンダードのAPIなど、Webの中では比較的ローレイヤーな部分を触りながら開発できることが多く、修行になるんじゃないか、おもしろいんじゃないかと思って、日経で働くぞとなりましたね。
司会者：ありがとうございます。
パフォーマンス分析について
司会者：では、Twitterに上がっていたので、これを最後の質問にしたいと思います。
「ユーザー環境のパフォーマンス追跡はChrome User Experience Reportを使っているのでしょうか？」
林：今回リブートした際のスコープには入っていないはずですが、過去SpeedCurveなどで外形監視基盤を入れた時に、もしかすると入っている可能性はなきにしもあらずだと思います。ちょっとこのへんはよく知らないという感じです。
司会者：答えていただきありがとうございます。お時間が来てしまいましたので、ここまでとさせていただければと思います。
