食わず嫌いされているスプレッドシート
以前の記事で、Google Workspaceのデータ主権の問題について書いた。機能だけ借りてデータは手元に持つ、という使い分けを提案した。
→ 中小製造業に Google Workspace は必要か
ただ、リスクがあるから使うなという話ではない。開発プラットフォームとして見ると、Googleスプレッドシート＋GAS（Google Apps Script）にはExcel VBAにはないメリットが確実にある。今回はその具体的な得意・不得意の話をしたい。
まず言っておきたいのは、スプレッドシートは食わず嫌いされていることが多いということ。サービスが出始めた頃は確かに使い物にならなかった。Excelと比べて遅い、関数が少ない、操作感が違う。その頃の印象を引きずっている人がまだ多い。
しかし今のスプレッドシートは相当進化している。例えば、1つのセルに関数を入れれば末尾の行まで自動で展開されたり、別のスプレッドシートからデータを引っ張ってこられる関数がある。他にも同時編集ができるので「誰かが開いているから編集できない」がないなど、Excelにはない便利さが確実にある。
ただしプラットフォームごと入る必要がある
スプレッドシートとGASの話をする前に、大前提がある。 Google Workspaceはチーム単位で導入しないとメリットが出にくい。
全員がMicrosoft Officeを使っている中で、1人だけGoogleスプレッドシートを使っても、ファイルのやりとりのたびに変換が発生する。同時編集もできない。GASで作った仕組みも、Googleアカウントを持っていない人には使えない。
使えないわけではないが、メリットが限定される。スプレッドシート＋GASの強みは、チーム全員がGoogle Workspace上にいる前提で成立する。
導入を検討するなら、外出やリモートワークが多い会社は相性がいい。ブラウザさえあれば同じファイルにアクセスできるので、場所を選ばない。逆に全員が同じ事務所にいて、ローカルのExcelで十分回っているなら、あえて乗り換える理由は薄い。
Excel VBAとは得意・不得意が逆
このシリーズではExcel VBAを中心に書いてきた。スプレッドシート＋GASはその「クラウド版」のような存在だが、得意・不得意がきれいに逆になる。
→ 中小製造業の内製DX ── Excel VBAで済む領域と、専用言語で作るべき領域
Excel VBAが得意でGASが苦手なこと：大量データの処理。 Excelは手元のPCで動くので、数万行のデータでもストレスなく扱える。VBAの処理も、PCのスペックが許す限り一気に回せる。
スプレッドシートはブラウザ上で動くため、数千行あたりからもたつきが出る。描画が非同期で、セルに値を入れてもワンテンポ遅れて反映されることがある。Excelに慣れた人にとっては、この遅延が地味にストレスになる。GASにも実行時間の制限がある。処理が長くなるとタイムアウトする。VBAなら気にしなくていい「トリガー」や「バッチ処理」という概念を意識して設計する必要が出てくる。
GASが得意でExcel VBAが苦手なこと：共有と定時実行。 スプレッドシートは最初から共有前提で作られている。同時編集、権限管理、変更履歴が標準で付いている。VBAのExcelファイルで「共有ブック」を使ったことがある人なら、あのつらさとの差は歴然としている。
GASのトリガー機能も大きい。「毎朝8時にこの処理を実行する」がコード数行で実現できる。VBAで同じことをやるには、PCを常時起動してタスクスケジューラを設定する必要がある。
| Excel VBA | スプレッドシート＋GAS | |
|---|---|---|
| 大量データ（数万行〜） | 得意 | 苦手（数千行で重くなる） |
| 処理速度 | PC性能次第で高速 | 実行時間制限あり |
| 同時編集 | 苦手 | 標準機能 |
| 定時実行 | 環境構築が必要 | トリガーで簡単 |
| 環境構築 | バージョン差・設定の罠あり | ブラウザだけで動く |
| オフライン | 問題なし | 基本的にネット必須 |
データが増えると別の道具が必要になる
Google Workspace環境で開発を進めていくと、ある時点で壁にぶつかる。データ量の壁になる。
スプレッドシートで数千行のデータを集計するGASを書いて、トリガーで毎朝実行する。最初は快適に動く。しかしデータが増えてくると、処理が重くなり、タイムアウトに引っかかるようになる。
Excel VBAなら、同じデータ量の増加に対して「PCのメモリを増やす」「処理を最適化する」で対応できる。しかしスプレッドシート＋GASでは、プラットフォーム側の制約を超えられない。
結果として、Google Workspace環境ではデータ量が増えるとBigQueryやAppSheetのような専用サービスにデータ処理を移行する流れになりやすい。これは3層モデルで言えば第三層への移行と同じ構造だが、移行先がGoogleのエコシステム内に限定されやすいという点が異なる。
→ 中小製造業のExcel業務が「1シート」で止まる理由 ── 関数の限界と次の一歩
Excel VBAの場合、第三層への移行先はC#やPythonなど、プラットフォームに依存しない選択肢が取れる。ここに、以前の記事で書いた「入れ替えられる設計」の考え方がつながる。
ファイル形式の選択は思った以上に重い
技術的な得意・不得意とは別に、もう一つ考えておくべきことがある。 データをどのファイル形式で蓄積していくか という問題になる。
Google Workspaceを数年運用すると、スプレッドシート、ドキュメント、スライド、GASのスクリプト——すべてがGoogleの形式でデータが積み上がっていく。お試しで使っている段階なら乗り換えは簡単だが、数年分の業務データとロジックが載った状態から別のプラットフォームに移行するのは、現実的にはかなり厳しい。
ただし、これはGoogleだけの問題ではない。Microsoft 365に全部載せても同じことが起きる。Excelのマクロ付きファイル、SharePointのワークフロー、Power Automateの設定——どのプラットフォームでも、深く使えば使うほど移行コストは上がる。Googleが潰れるリスクを心配するなら、Microsoftにも同じことは言える。
大事なのは、どちらが安全かではなく、 データをプラットフォーム固有の形式に閉じ込めすぎないこと になる。以前の記事で「データの文法」として書いたCSVで出力できる形でデータを持つ、という原則はここでも効く。スプレッドシートでもExcelでも、業務データ本体はCSVやDBに落とせる構造にしておけば、プラットフォームの乗り換えが必要になったときにデータだけは救える。
どちらを選ぶかは働き方で決まる
結局のところ、Excel VBAとスプレッドシート＋GASのどちらが優れているかという話ではない。
事務所にいる時間が長く、手元のPCでデータを扱う業務が中心なら、Excel VBAのほうが自然。 PCのパワーをフルに使える。データ量の制約も緩い。オフラインでも動く。
外出やリモートが多く、複数拠点でデータを共有する必要があるなら、スプレッドシート＋GASが向いている。 ブラウザさえあればどこでも使える。同時編集とトリガーが最初から使える。
中小製造業の場合、工場と事務所が一体になっていて、ほぼ全員が同じ場所で働いているケースが多い。そういう環境ではExcel VBAのほうが素直にハマることが多い。このシリーズでExcel VBAを中心に書いてきたのは、そういう現場が想定読者だからになる。
ただ、拠点が複数あったり、営業が外で動く時間が長かったりする会社なら、Google Workspace＋GASのほうが合う場合もある。道具の選択は、技術の優劣ではなく、自分たちの働き方に合っているかどうかで決めるべきものになる。
このシリーズの他の記事：