ダッシュボードが、同じデータを三回読んでいた

運用ツールのダッシュボードを調べると、概要、分析、進捗の表示が、それぞれ同じ種類のデータを取りに行っていました。購買、メール、タスク、会計、プロジェクト。関数単体では必要な取得でも、一画面に集めると重複していました。

2026年8月に、この取得経路を見直しました。キャッシュを追加する前に、まず一回の表示で何を何回読んでいるかを追った記録です。

表示ごとの関数が、それぞれ取得まで担当していた

概要を返す関数、分析を返す関数、進捗を返す関数に処理を分けると、それぞれの役割は読みやすくなります。ただ、この構成では各関数が元データの取得まで担当していました。

ダッシュボードからまとめて呼び出すと、同じデータベースへの往復が繰り返されます。画面の部品が分かれていることと、その裏でデータを別々に取得する必要があることを、同じように扱ってしまっていました。

一度取得して、表示に必要な値を組み立てる

修正では、ダッシュボード全体に必要な情報を返す取得経路を用意しました。共有できるデータはそこで取得し、分析、進捗、承認件数などを組み立てます。

既存の個別APIは、モバイル側との互換性のため残しました。ブラウザの都合だけで取得経路を置き換えると、別の利用側を壊してしまいます。共通化する範囲と、外に公開しているインターフェースは分けて考えました。

認証表示でも、ユーザーとアクセス権の情報を重ねて問い合わせていた部分を整理しました。読み取りに不要な初期化処理は外しつつ、管理操作で必要な権限確認、同期、監査は残しています。問い合わせを減らすために、必要なチェックまで省くわけにはいきません。

「重複を消した」と「何秒速くなった」は別

修正後はlint、テスト、本番向けビルド、隔離した環境でのブラウザテストを通しました。取得経路の重複を減らし、既存の動作が保たれることを確認しています。

ただし、この記録の時点では、ログインした本番画面での変更前後の時間を測り直せていません。「何％速くなった」と書ける結果はまだありません。

今回面白かったのは、一つの遅いクエリを探すだけでは見えない問題だったことです。次に画面の待ち時間を調べるときも、まず、その画面が裏で何回同じ情報を取りに行くのかを見たいです。