導入したばかりの頃、そのシステムは驚くほど快適だった。受注一覧の画面を開けば一瞬で表示され、検索も入力した瞬間に結果が返ってくる。担当者は「これで手作業の集計から解放される」と胸をなで下ろし、現場にも自然と定着していった。ところが一年ほど経ち、受注データが数万件を超えたあたりから、様子が変わり始めた。
朝いちばんに一覧画面を開くと、以前は一瞬だった表示に数秒かかる。月末の集計画面に至っては、担当者が席を立ってお茶を淹れて戻ってくるまで終わらない。最初は「そんなものか」と我慢していた現場も、繁忙期になると「システムが固まった」という声が上がるようになった。開発会社に問い合わせると「データ量が増えたので仕方ない」という説明を受けたが、本当にそれだけが原因なのだろうか。実はこの手の遅さの多くは、キャッシュという仕組みの設計不足によって引き起こされている。
なぜデータが増えると表示が遅くなるのか
理由の一つ目は、画面を表示するたびにデータベースへ同じ計算を何度も投げ直していることだ。例えば「今月の売上合計」を表示するだけの画面でも、裏側では毎回すべての受注データを読み込んで合計し直している。データが千件のうちは一瞬で終わる処理も、数万件になれば時間がかかる。
二つ目は、検索や絞り込みの条件が複雑になるほど、データベースが探す範囲が広がることだ。特に複数の条件を組み合わせた検索や、他のテーブルと突き合わせる処理は、データ量に比例して重くなりやすい。
三つ目は、こうした負荷が積み重なった結果、システム全体の反応が遅れ、他の利用者の操作にも影響が及ぶことだ。一人が重い集計処理を実行している間、他の担当者の画面まで固まってしまうケースは珍しくない。
遅さを放置するとどうなるか
表示の遅さは、単なる「ちょっと待たされる不便」では済まない。まず現場の作業効率が下がる。一回あたり数秒の待ち時間でも、一日に何十回と操作を繰り返せば、積み重なった時間は無視できない大きさになる。
次に、システムへの不信感が生まれる。動作が遅いシステムは、たとえ機能が優れていても「使いにくいもの」という印象を現場に植えつけ、結果としてExcelなど従来の手作業に戻ってしまう逆行が起きやすい。
そして最も見落とされがちなのが、後から手を入れる難しさが増すことだ。表示が遅い原因がデータ構造の奥深くに絡んでいる場合、後付けの改修では対応しきれず、作り直しに近い規模の工事が必要になることもある。早い段階で気づき、手を打てるかどうかが、その後のコストを大きく左右する。
キャッシュとは何か、何を解決してくれるのか
毎回計算し直さない仕組み
キャッシュとは、よく使うデータや計算結果を一時的に手元に置いておき、次に同じものが必要になったときはゼロから計算し直さずに済ませる仕組みのことだ。たとえば「今月の売上合計」を一度計算したら、その結果をしばらく保管しておき、次に画面を開いたときはその保管された数字をそのまま表示する。こうすることで、データベースに何度も重い問い合わせを投げる必要がなくなる。
台所に例えると分かりやすい
料理をするたびに毎回だし汁を一から取るのではなく、まとめて作った出汁を冷蔵庫に置いておき、必要なときに使う。それがキャッシュの考え方に近い。頻繁に使うものほど手元に置いておいたほうが、全体の作業は速く進む。
どこに置くかで効果が変わる
キャッシュには、利用者のパソコンのブラウザに置く方法、システムのサーバー側に置く方法など、いくつかの置き場所がある。どこに何を置くかは、データの更新頻度や利用者数によって設計が変わるため、開発側の技術的な判断が問われる部分でもある。
発注時に確認すべきポイント
発注者がすべての技術的な仕組みを理解する必要はないが、いくつかの質問を投げかけることで、開発会社がパフォーマンスをどこまで考えているかを見極めることはできる。まず「データが増えた場合、表示速度はどう担保する設計になっているか」を尋ねてみるとよい。明確な答えが返ってこない場合、設計段階でパフォーマンスが検討されていない可能性がある。
次に注意したいのが、キャッシュのやりすぎによって起きる別の問題だ。キャッシュは表示を速くする一方で、保管しているデータが実際の最新の状態とずれてしまうリスクを持っている。例えば在庫数をキャッシュしていた場合、実際には売り切れているのに画面上はまだ在庫があるように見えてしまう、といったことが起こり得る。速さと正確さは、しばしばトレードオフの関係にあるため、「どのデータは多少古くても構わないか」「どのデータは常に最新でなければならないか」を発注者側であらかじめ整理しておくことが望ましい。
また、契約や見積もりの段階で「想定するデータ量まで動作確認を行うか」を確認しておくことも重要だ。開発時のテストデータが数十件程度では、本番で数万件になったときの遅さは事前に見抜けない。将来の運用規模を伝え、それに見合った検証をしてもらえるかどうかは、発注時に確認しておくべき点である。
現実的な進め方
すべての画面を最初から完璧に高速化しようとすると、コストも期間も膨らんでしまう。現実的には、まず現場で最も使用頻度が高い画面や、待たされることで業務が止まりやすい処理から優先的に手を入れるのが望ましい。導入後にデータ量が増えてから初めて遅さが表面化することも多いため、リリース後も定期的に表示速度を確認し、必要に応じて調整していく運用体制を、開発会社とあらかじめ取り決めておくことも有効だ。
パフォーマンスの問題は、派手さのない地味な作業の積み重ねで解決される。だからこそ、発注段階でこの視点を持っているかどうかが、後々の差になって表れる。
壁を越えて働く人たちへ
画面が固まった数秒の間にも、現場では受注の電話が鳴り、納期の確認を待つ取引先がいる。その見えない苦労を、日々の業務の中で乗り越えているのは、システムを使いこなそうとする現場の人たちだ。キャッシュという地味な設計判断も、突き詰めれば、そうした人たちが余計な待ち時間に煩わされず、本来やるべき仕事に集中できるようにするための工夫にすぎない。私たちは、目に見えにくい技術の積み重ねを通じて、日々壁を越えて働く人たちを支えていきたいと考えている。