開くまで待つ。入力しても反映が遅い。数式が壊れないよう、触る場所を担当者しか分かっていない。

スプレッドシートが重くなったとき、ファイルを分割すれば一時的に軽くなることがあります。しかし、管理するファイルが増えるだけでは、会社全体の数字はさらに見えにくくなります。

大切なのは、重さの原因を見分け、今のシートを整える段階なのか、データの保管場所を分ける段階なのかを判断することです。

まず、何が増えたかを確認する

「データが多い」だけが原因とは限りません。次のうち、どれが増えたかを確認します。

  • 行数や列数
  • IMPORTRANGEなど、別ファイルを参照する数式
  • 全列を対象にした集計式
  • 複雑な検索、配列、条件付き書式
  • グラフやピボットテーブル
  • 同時に編集する人
  • Apps Scriptや外部サービスからの更新
  • 店舗・部署ごとに複製したシート

Google Driveの公式仕様では、Googleスプレッドシートとして作成または変換できるファイルには最大1,000万セルという上限があります。ただし、上限へ達していなくても、数式や参照関係、利用方法によって日常業務に支障が出ることはあります。

セル数だけで判断せず、入力待ちや集計待ちが業務を止めているかを基準にします。

選択肢1：今のシートを整理する

最初に、仕組みを変えずに改善できる範囲を確認します。

  • 使っていない行、列、シート、条件付き書式を減らす
  • 全列参照を、実際に使う範囲へ狭める
  • 同じ計算を何度も行う数式をまとめる
  • 過去の確定データを別の保管場所へ移す
  • 入力用、マスタ、集計用の役割を分ける
  • 自動更新が必要な時間帯と頻度を見直す

この方法は、利用人数とデータ量がまだ小さく、シートの構成を理解している場合に向いています。

ただし、改善後も誰か一人しか修正できないなら、性能だけでなく属人化も残っています。数式や連携の目的、更新方法、エラー時の対応を文書化します。

選択肢2：入力と集計を分ける

一つのスプレッドシートに、入力、保管、加工、集計、グラフのすべてを任せている場合は、役割を分けます。

たとえば、次のような構成です。

  • 入力：現場が使う単純なフォームやスプレッドシート
  • 保管：変更しにくい原本データ
  • 加工：店舗名や商品コードをそろえる処理
  • 集計：会議で使う指標を計算する処理
  • 表示：必要な数字だけを見せるレポートやダッシュボード

役割を分けると、入力シートへ複雑な数式を集中させずに済みます。入力方法を急に変えず、裏側から段階的に改善することもできます。

選択肢3：ファイル間の集計を自動化する

店舗や担当者ごとにファイルを分ける必要があるなら、集計担当者が毎回コピーするのではなく、決めた形式のデータを自動的に集める方法を検討します。

ただし、自動化の前に次を統一します。

  • 項目名
  • 日付や金額の形式
  • 店舗・担当者を識別するID
  • 重複データの判断方法
  • 修正・取消の扱い
  • 締め後に変更できる範囲

形式がそろっていない状態で自動化すると、転記作業が「エラー修正作業」に置き換わるだけです。

選択肢4：BigQueryを保管・集計に使う

明細が増え続ける、複数システムのデータを合わせる、全社で同じ数字を使いたい場合は、BigQueryなどのデータベースへ保管と集計を移す選択肢があります。

GoogleのConnected Sheetsを使うと、BigQueryに保存したデータを、使い慣れたGoogleスプレッドシートから分析できます。Googleの公式案内では、BigQueryへの接続、ピボットテーブルやグラフでの分析、手動またはスケジュールによる更新が説明されています。

この構成では、すべての明細を通常のセルへコピーするのではなく、BigQuery側で必要な範囲を集計し、その結果をスプレッドシートで確認できます。

スプレッドシートは捨てなくてよい

BigQueryを使う場合でも、スプレッドシートは次の用途に残せます。

  • 担当者が使う一時的な分析
  • 会議前のコメントや補足
  • 小規模なマスタの確認
  • BigQueryの集計結果を使ったピボットテーブル
  • 導入初期の検証画面

「スプレッドシートかBigQueryか」の二者択一ではなく、スプレッドシートを人が考える場所、BigQueryをデータを保管・集計する場所として分ける考え方です。

BigQueryへ移す前に知っておきたいこと

BigQueryは、大量データを扱える一方、導入すれば自動的に運用が整うわけではありません。

権限を設計する

誰が元データを閲覧できるか、誰が集計を実行できるかを決めます。Connected Sheetsの更新や新しい分析には、利用者側にも適切なBigQuery権限が必要です。

更新方法を決める

Connected Sheetsのデータは、接続しただけで常時同期されるわけではありません。Googleの更新方法に関する公式説明にあるように、手動更新またはスケジュール更新を設計します。

費用を管理する

BigQueryには保管とクエリ処理の費用があります。オンデマンドクエリでは読み取るデータ量が費用に影響するため、対象列や期間を絞り、必要に応じて日次クエリ容量の上限を設定します。Google Cloudは費用の見積もりと制御方法を公開しています。

修正・確定ルールを決める

売上や件数が後から変わったとき、元データを直すのか、訂正履歴を追加するのかを決めます。システムより先に「正しい数字」の決め方が必要です。

どの選択肢から始めるか

今のシートの整理から始める

  • 利用者が少ない
  • データは一つの業務だけ
  • 更新は週次または月次
  • 数式や参照を減らせば改善できそう

入力と集計の分離から始める

  • 現場の入力画面はすぐ変えられない
  • 集計用の数式が入力を遅くしている
  • 店舗・部署ごとのデータをまとめたい

BigQueryなどのデータベースを検討する

  • データが継続的に増える
  • POS、会計、CRMなど複数の情報を合わせる
  • 部署によって数字が異なる問題をなくしたい
  • 権限、履歴、定期更新が必要
  • 複数のレポートで同じ集計結果を使いたい

移行は一つの会議から試す

全ファイルを一度に移す必要はありません。まず、毎月時間がかかっている会議資料を一つ選びます。

  1. 会議で本当に見る指標を3〜6個に絞る
  2. その指標の元データと計算方法を確認する
  3. 現在の集計結果を基準として保存する
  4. 新しい方法で同じ数字を再現する
  5. 4週間ほど並行運用し、差異と使い勝手を確認する

重いファイルを軽くすることが目的ではありません。数字を待つ時間を減らし、問題へ早く対応できる状態を作ることが目的です。

関連記事