KARTEの管理画面の読み込み速度が大幅に向上。ユーザー目線で改善を重ねるエンジニアたちの挑戦

KARTEではこれまで、管理画面のパフォーマンスについてお客様から多くのフィードバックを得ている状況がありました。

今回、改めてこの課題の解決に取り組み、数値的な改善はもちろん、利用者の体感レベルでも差を感じられるほどに速度の改善を実施。

改善に取り組むに至った背景や取り組み内容、今後の改善の展望について、プレイドエンジニアの大矢 康介と土佐 陽生の二人に聞きました。

長年の課題に、ボトムアップ的に解決に挑む

管理画面のパフォーマンスについての課題とはどのようなものだったのでしょうか。

土佐：今のKARTEは大量のデータを扱うプロダクトで、その規模は国内でも有数です。一人ひとりの顧客を解像度高く、リアルタイムに解析できるのが最大の特徴ですね。プロダクトの進化も速く、次々と機能が追加されています。お陰様でご活用いただく企業数も増え続けており、その領域も多種多様です。

これらの要素が含まれるプロダクトの管理画面をKARTEを活用するユーザーにとって使いやすいものにするというのは、非常に重要なことです。この管理画面の改善において、長年取り組み続けてきたのがパフォーマンスの向上でした。

もちろん、これまでにもパフォーマンスの向上には取り組んできたのですが、一度向上したように見えても、しばらくするとパフォーマンスが低下してしまい、良好な状態が継続できていなかったのです。

管理画面のパフォーマンスに影響する根本的な原因を究明する必要がありましたが、他の機能開発や改善などの対応も必要な中で、解決のためにエンジニアのリソースを十分に割けていませんでした。

改めて、今回パフォーマンス改善に取り組んだのはどういった理由だったのでしょう。

土佐：いくつかのきっかけが重なり、今が取り組むタイミングだと判断しました。きっかけのひとつは、私と大矢さんが所属しているKARTEの核となる機能開発を担うチームが組成されたこと。もうひとつは、社内からも強い要望があったこと。

前者については、チームとして「プロダクトフィードバックサイクル」という定期的にフィードバック内容から着手する課題を決めて、改善に取り組むという活動をトライアル的に始めました。

後者については、管理画面のパフォーマンスを向上させたいという強い思いを持ったビジネス側のメンバーが自発的にチームを組成し、発生している課題や要望をまとめた上で、エンジニア側に提案がありました。

私も管理画面のパフォーマンスはなんとか改善したいと考えていたので、ビジネス側のメンバーと一緒に、フィードバックサイクルの活動の一環として、この課題を解くプロジェクトチームの一員として活動を始めました。

土佐 陽生/ソフトウェアエンジニア　インターンを経て、2022年4月にプレイドへ新卒入社。Journeyチームで開発に携わっている。

チームが組成された後、どのように進めていったのでしょうか？

土佐：まずは、管理画面のパフォーマンスに関する課題の洗い出しと整理を始めました。ビジネス側のメンバーが再現方法を確認したり、発生状況を動画で記録したり、と課題を集めてくれていたので、課題をまとめるところには時間はかからなかったですね。

課題の数が多かったので、優先度を整理した上で解決できそうなところから取り組んでいこうとしたのですが、これが難しくて。対症療法的な解決ではなく、根本的な課題の解決をしようとすると、どう解けばいいのかが自分だけではわからない状態でした。

同じチームで活動している大矢さんに管理画面のパフォーマンス改善のために動いていることは共有していたので、「どう解決したらいいでしょうか？」と相談したんです。

大矢：KARTEの管理画面は活用企業の方々はもちろん、プレイドのメンバーも頻繁に利用しています。その画面がパフォーマンスが低下しているということは、お客様に負担がかかっているだけでなく、会社全体の生産性低下にもつながっていることも意味します。この問題はなんとか解決したいと考えていたので、自分もチームに入って土佐さんと一緒に解決に乗り出しました。

パフォーマンスを監視するモニタリング環境を整備し、数字で状況を把握

大矢さんが入った後はどのように進めていったのでしょうか。

大矢：ビジネス側のメンバーと土佐さんでまとめてもらった課題をさらに細かく見ていきました。「管理画面のパフォーマンスが良くない」というのは、トップページのユーザーリストなのか、接客施策を編集する画面なのかなど、数値で客観的に見ていこうと。まずは、そのためのモニタリング環境を準備するところから着手しました。

プレイドではモニタリングツールとして「Datadog」というツールを活用しています。元々の活用方法で、どのAPIのレイテンシが悪いか、そのAPIのどのデータベースへのリクエストに時間がかかっているかなどは特定できていました。

ですが、画面でコンテンツが表示されるまでにどれくらい時間がかかっているかということはわからない状態。まずは、Datadogを利用してパフォーマンスの監視をする方法を調べました。

DatadogRUMを使えば、うまくモニタリングできそうだったので、数字で各ページのパフォーマンス状況を見ていきました（※技術的にどうモニタリングを行っていったのかは、エンジニアブログのこちらの記事にて紹介しています）。

大矢 康介/ソフトウェアエンジニア インターンを経て、2020年4月にプレイドへ新卒入社。KARTE Talk の開発および KARTE のコア機能の改善に携わっている。

モニタリングができそうだ、となった後は何に着手したのでしょうか。

大矢：次は、監視対象のメトリクスの検討や、どういった軸で監視するかというのを決めていきました。Datadogのダッシュボードを見てみると、FID（First Input Delay）とCLS（Cumulative Layout Shift）の値はそれぞれ Core Web Vitals では「Good」の評価となる値でした。もともと気になっていたのは読み込み速度だったため、LCP（Largest Contentful Paint） と LT（Loading Time）を監視対象のメトリクスと定義しました。

Core Web Vitals：ページの読み込みパフォーマンス、インタラクティブ性、視覚的安定性に関するUXを測定する一連の指標
FID：ページが読み込まれてからユーザーがページ上で何かのアクションを行ったときに、ブラウザがそのアクションに応答するまでの時間
CLS：ページの読み込み中に発生する予期しないレイアウトのシフトの総量を測定する指標
LCP：ページの主要なコンテンツが読み込まれて表示されるまでの時間
LT：ページが完全に読み込まれるまでの総時間

大矢：その後は、比較できるように一覧化し、どこを集中的に見るかを決め、解決のコストパフォーマンスがよさそうなページや、改善のインパクトが大きい部分はどこかを見つけようとしました。

また、フィードバックの内容と照らし合わせながら、数値の状況を見ていきました。パフォーマンスに影響する要因は、KARTEの実装以外にも通信環境やハードウェアの状況など、いくつか挙げられます。プロダクトに起因しないものを除外していきながら、原因の特定に取り組みました。

土佐：大矢さんは簡単に話しますが、KARTEは利用するお客様も多種多様ですし、利用環境の変数も多いので、細かくデータで見えるように整理していったというのはすごいことだと思います。少なくとも、今の自分にはできないですね。

予想外の原因を発見し、課題を解決

モニタリングし、メトリクスを設定して、見えてきたことはあったのでしょうか？

大矢：全体的にパフォーマンスが低い、特定ページのパフォーマンスが低いというわけではなく、誰が見てもパフォーマンスが良くないときがあるし、パフォーマンスが良いときもある、ということがランダムに発生する状態だったということがわかりました。データが大量にあったとしても、同じページを2回読み込んだら、同じくらいの速度になるはず。それがランダムに速度が変化していたんです。これはパフォーマンスに影響する要因を発見する大きなヒントになりました。

その要因は予想外のものだったのでしょうか？

大矢：予想とは違っていましたね。例えば、接客に関する情報を取得するAPIのレスポンスタイムが遅ければ、その影響を受けて表示が遅くなる、というケースはよくあります。その場合、APIを改善すれば解決するのですが、これが原因ではありませんでした。

遅いページを見つけたときに、特定のAPIが問題だろうと思って見ていると、速いときもある。データが影響しているのかと考えて調べてみると、これも違う。いろいろな可能性が想定される中で、一つひとつ確認しながら、検討していきました。

パフォーマンスに影響していた原因はなんだったのでしょう。

大矢：調べていくと、どうやらAPIを読み込む以前に、HTMLなど静的ファイルの読み込みが遅いのだとわかりました。通常、これらのファイルの読み込み速度はテキストサイズに依存し、テキストサイズが大きいものほど読み込みが遅くなるのが普通です。ただ、テキストサイズが小さいものでも、読み込み速度が異常に遅かったため、サーバー状態が悪いのではと仮説を立てました。

サーバーの状態が悪いと、どのAPIを読み込んでも遅くなる可能性があります。特定の画面を改善するのではなく、サーバー全体の健康状態をよくすることに注力すれば、全体がよくなるのではないか、と考えました。

KARTEのサーバサイド言語はNode.jsを使用しているのですが、ブロッキング操作が長い時間行われており、イベントループがJavaScriptの実行を継続できない状態になっていると予想しました。この現象が起こらないようにコードを書き換えたことで、管理画面のパフォーマンスは大きく向上しました。

その課題はこれまで項目として上がったことはなかったのでしょうか。

土佐：原因がわかると解決方法は難しくないのですが、「ここに課題がありそうだ」と予想することが難しいものだったと思います。今回のように大矢さんが数値を細かく観測していったことで、ようやく発見できたものだと思いますね。

パフォーマンスの基準を定め、継続してプロダクトを改善

改善して、パフォーマンスはどの程度変わったのか教えてください。

大矢：最終的に、監視対象だった利用頻度が高くパフォーマンスが悪い画面の読み込み速度は50%以上改善しました。

土佐：大矢さんが改善したあと、社内の人たちに共有したら、「明確に速くなっている」と好反応でした。実際にパフォーマンスに関してフィードバックをいただいていたお客様からも、「明確に軽くなっていますが、何かしましたか？」といった声をいただきました。

通常、管理画面の読み込み速度の変化は気づかれにくいのですが、読み込みにかかる時間が約半分に縮まったことによって、お客様はもちろん、社内の人たちの作業のやりやすさもだいぶ変わってきているのではないかなと思います。

管理画面のパフォーマンス改善は継続して取り組んでいくのでしょうか？

大矢：今後も、引き続き様子を見ながら必要に応じて改善のアクションをとっていく予定です。今回の取り組みで、パフォーマンス状況を計測できるようになり、どの数値になるとパフォーマンスが悪化しているといえるのかの基準を定めることができました。「パフォーマンスが低い」という状態を数値的に判断できるようになったので、どの数値を超えたらエンジニアはリソースを割いて対応するのかのルールも定められると考えています。

土佐：今回、お客様と接しているビジネス側から声が挙がり、それを開発側で受け止めた上で課題を解決するというフィードバックサイクルを回せたというのも意義があったと思います。ビジネス側、開発側の垣根なく、会社全体としてプロダクトを磨き上げていく活動の一例を作れたのは嬉しいですね。

大矢：また、パフォーマンス状況のモニタリング方法については、他のプロダクトでも同じようにやってみよう、という話をしています。今回の取り組みにより、プレイドの他のプロダクトでもパフォーマンスを改善できるかもしれません。今後も継続してプロダクトの改善に取り組んでいきたいと思います。