【脱・重いスプレッドシート】サクサク動くシートを作るための設計術

チームで共有しているスプレッドシート。

最初はサクサク動いていたはずなのに、データが増えるにつれてどんどん重くなり、今では開くだけで数分待たされる…。

そんな経験はありませんか？

• 不要な行はすべて削除した
• 複雑な関数も見直した
• 重いと言われる条件付き書式も減らした

それなのに、なぜか軽くならない。

もしあなたが今、

という手詰まり感を感じているなら、この記事は、あなたのためのものです。

実は、あなたのシートが重い本当の原因は、小手先のテクニック不足ではありません。

データが、あらゆるところで複雑に絡まりあってる、シートの設計自体に問題があります。

多くの重いシートは、必要なデータを最短ルートで取得する設計がされておらず、非効率な計算の連鎖が起きているのです。

この記事では、そういったデータが複雑に絡み合ったシートをサクサク動くシートに変える設計術について解説します。

設計の鉄則：「データ」と「見た目」を混ぜない

多くの重いシートに共通するのは、1枚のシート上で、

• データの入力
• 計算
• レポート表示

のすべてを行ってしまっていることです。

上部に集計表があり、データの途中に小計行が挟まり、右端にはマスタデータが置いてある…。

一見、情報を一つのシートにまとめていて、便利そうに見えますが、サクサク動くシートを作る上では、やってはいけない典型的なNG例です。

この状態だと、データと見た目が複雑に絡み合っているため、たった1行データを追加するだけで、シート全体に再計算と再表示の負荷がかかります。

その結果、スプレッドシートの動作は重くなってしまいます。

これを解消する鉄則は、役割ごとにシートを明確に分けることです。

ここからは、先ほどのNGシートを元に、具体的にどのようにデータと見た目を分けるかについて解説していきます。

① データベースシート（数式・装飾がないデータの保管場所）

まずは、すべての土台となるデータベースシートを作ります。

さきほどのNGシートから、入力データ（商品名など）だけを移行したシートを作ります。

守るべきルール

「値」のみを入れる（数式禁止）

ここには SUM や VLOOKUP などの関数は一切入れません。

計算前の生のデータだけを入力します。

「素」のままで使う（装飾禁止）

「見やすくするために色を塗る」「セルを結合する」などは、データベースシートではNGです。

ここは人間が見る場所ではないので、見た目を整える必要はありません。

これだけで軽くなる理由

スプレッドシートが最も重くなる原因は、「セルの色や罫線を表示すること」と「複雑な計算をすること」です。

このシートを「文字だけのただのリスト」に徹底することで、データが数万行に増えても、驚くほど軽い動作を維持できます。

② バックヤードシート（ユーザーの目に触れない計算専用シート）

次は、計算だけに特化したバックヤードシートを作ります。

①で作ったデータベースから必要な数字を抜き出し、ここで集計や加工を行います。

守るべきルール

関数はすべてここに集約する

ここで初めて SUMIFS COUNTIF QUERY などの関数を使用します。

「NGシート」で散らばっていた計算式は、すべてこのシートに移動させます。

見た目は最低限（自分が分かればOK）

ここはチームメンバーの目には触れない計算処理専用の場所です。

人に見せるためのシートではないため、見やすさや装飾を気にする必要は無く、管理者の方だけが分かればOKです。

これだけで軽くなる理由

重い計算処理を表示側（ダッシュボード）から切り離すことで、データベースシートを計算だけに集中するシートに変える事が出来ます。

ダッシュボードは、バックヤードの計算結果をただ見ているだけで良いので、負荷が劇的に下がります。

③ ダッシュボード（結果を表示する閲覧場所）

最後は、チームメンバーが閲覧・操作するためのダッシュボードシートを作ります。

②で作ったバックヤードの計算結果を、ここに見やすく表示させます。

守るべきルール

複雑な計算はしない（参照するだけ）

ここで行うのは、バックヤードで計算された結果を持ってくる（='バックヤード'!A1）だけです。

重い関数は一切使わず、シンプルな＝の参照のみで構成します。

ここでの装飾は惜しまない

これまで禁止していた「セルの色付け」「太字」「罫線」「グラフ」などは、すべてこのシートで行います。

ここはチームメンバーも見る場所なので、分かりやすいシートを作る事を徹底しましょう。

これだけで軽くなる理由

このシートは、裏側ですでに計算し終えた結果を表示しているシートです。

シートの中に計算処理と表示するための処理が混ざらないので、スクロールやフィルタリングをしても、カクつくことなくサクサク動きます。

注意点：設計を台無しにする5つのNG行動

① 未使用の空白列を放置する

スプレッドシートは、文字が書いてあるかどうかに関わらず、存在するセルの数だけメモリを消費します。

特に、行よりも列の無駄がパフォーマンスに響きます。

データがF列までしかないのに、デフォルトのZ列まで放置してるのであれば、残りの余分な列は削除するべきです。

② 条件付き書式の広範囲指定

など、異常値を見つけやすくしたいがために、シート全体に条件付き書式を設定していませんか？

気持ちはわかりますが、これは落とし物を探すために東京ドームの照明を全開にするようなもので、PCへの負荷が特大です。

異常値をわかりやすくするためには、IF 関数などを使って、別シートや別の列に異常値検知専用の箇所を作るなどで対策を取れます。

条件付き書式は負荷が高いので、基本的には本当に必要な列などに留める事が重くなる事を防ぐ事が出来ます。

③ 揮発性関数の多用

NOW() TODAY() RAND() の様な、常に動き続ける関数は、揮発性関数と呼ばれます。

これらは、シート上のどこかのセルを編集するたび、あるいは単にシートを開いているだけでも、再計算が走り続けます。

もしTODAY()を使った計算を数千行レベルで行うなら、GAS（Google Apps Script）などを使って、1日に1回だけ更新するなどの設定にした方がシートも圧倒的に軽くなります。

④ クロス集計に大量のSUMIFSを使う

「担当者別・月別の売上表」などを作る際、大量の SUMIFS や COUNTIFS を並べていませんか？

関数による集計は、セル一つひとつが独立して計算を行うため、数が数千個になると、かなり重くなります。

対策として、クロス集計には、ピボットテーブルを使う事を推奨します。

ピボットテーブルは、大量のデータを集計するために作られた機能なので、処理が重くなりづらい仕組みになっています。

数千個の関数を並べるのであれば、ピボットテーブルを活用するのがベストです。

⑤ 確定した過去データを数式のまま放置する

「2023年の売上」など、もう絶対に変わらない過去のデータまで VLOOKUP や SUM が入ったままになっていませんか？

絶対に変わらない数式をそのまま放置すると、シートを開くたびに計算し直されて、結果としてシートが重くなります。

確定したデータは、「コピー」→「値のみ貼り付け」を行い、数式を数字としして固定してしまうのが鉄則です。

これでも重いなら

ここまで紹介した3層構造への設計変更とNG行動の回避を行えば、あなたのシートは間違いなく軽くなります。

しかし、データが数万行を超えたり、非常に複雑な計算が必要だったりする場合、標準機能だけではどうしても超えられない壁が存在します。

例えば、

• 5万行を超える売上データに対し、全行で VLOOKUP を使って商品名を表示している。
• 累計や残高の推移など、1行計算するのに過去のデータをすべて参照しなければならない処理を行っている。
• 複数のシートから条件に合うデータを抽出し、さらに複雑な計算をする処理が、数千行に及ぶ。

これらは、設計や関数だけでは解決しない問題です。

GASを使って計算そのものを無くす

ここで登場するのが、GAS（Google Apps Script）です。

GASを使えば、複雑な処理をすべて裏側で済ませて、計算し終わった答えだけをセルに置くことができます。

関数の様に、常に計算をする必要がないので、開いた瞬間に表示される待ち時間ゼロのシートを実現できます。

私は、まさにこのGASを用いた業務効率化・システム構築を専門としています。

もし

「設計を見直してもまだ重い」「自社だけでは解決が難しい」

とお困りであれば、ぜひ一度ご相談ください。

まとめ

重いシートを使い続けることは、時間という貴重なリソースをジワジワと垂れ流し続けます。

今日から、「シートが重い」と感じた時は、シートの設計を見直すことから始めてみてください。

• データベースシート（数式・装飾がないデータの保管場所）
• バックヤードシート（ユーザーの目に触れない計算専用シート）
• ダッシュボード（結果を表示する閲覧場所）

この３つを意識した設計にするだけでシートの重さは大きく変わります。

データと見た目を分けるという意識を持つだけで、あなたのチームの生産性は劇的に向上するはずです。

この記事が、あなたの重いシートをサクサク動くシステムに変えるきっかけになれば幸いです。