ExcelでVBAを使った業務ツールを運用していると、
Googleスプレッドシート（以下、スプレッドシート）への移行や併用を検討する場面があります。
VBAとGASはいずれも処理を自動化するための仕組みですが、
実際に置き換えを進めてみると、単純なコード変換では対応できない違いがいくつもあることに気づきます。
本記事では、VBAからGASへ置き換える過程で、
事前に整理しておいた方が理解しやすかった点をまとめています。
特定の実装方法や移行方針を示すものではなく、
検討時の整理資料として共有する内容です。
VBAとGASは似ているが前提が異なる
VBAとGASはいずれもスクリプトで処理を記述しますが、
動作環境の前提が大きく異なります。
VBA
- Excelアプリケーション上で動作する
- ユーザーが操作している画面と処理が密接に結びつく
- アプリケーションの状態（表示・入力・対話）を前提に処理を書きやすい
GAS
- クラウド上で実行される
- スプレッドシートは処理対象となるデータの一部
- 実行時にユーザーがどの画面を見ているかとは独立して処理が動く
この前提の違いを意識せずに置き換えを進めると、
「同じことをしているつもりなのに動きが違う」
と感じる原因になります。
オンライン前提か、オフラインでも動作するか
VBAとGASの違いとして、
動作時にネットワーク接続を前提とするかどうか も整理しておく必要があります。
GASはクラウド上で実行されるため、
ネットワーク接続がない状態では処理を実行できません。
スクリプトの実行やデータの取得・更新は、
オンライン環境が前提となります。
一方で、VBAはExcelアプリケーション上で動作するため、
- ローカルに保存されたファイル
- ローカル環境で完結する処理
であれば、
ネットワーク環境が整っていなくても動作するケースがあります。
この違いは、
- 利用場所
- 通信制限のある環境
- 一時的なネットワーク断
といった状況で、
使い勝手や運用面の差として表れることがあります。
まずはVBAが「何をしているか」を分解する
VBAをGASに置き換える前に、
元のVBAが どのような役割の処理をしているのか を整理する必要があります。
例えば、
- データを取得している
- 条件によって処理を分けている
- 別のシートやファイルに書き込んでいる
- ユーザーに確認や結果を返している
といった処理を、
Excel操作の流れではなく、処理の目的単位で分解すると、
GASでどう構成するかを考えやすくなります。
VBAにおける「画面操作」とGASのUIは同じではない
VBAでは、Excelアプリ上で動作することを前提としているため、
次のような 画面（UI）と一体になった処理 が書かれることがあります。
- ユーザーフォーム（UserForm）を表示して入力を受け取る
- メッセージボックスや入力ボックスで対話する
- シート表示の切り替えやスクロールなど、見えている画面の状態を変更する
- 処理中の画面更新を制御する
これらは、
ユーザーが操作しているExcel画面そのものを前提にした実装です。
一方でGASはクラウド上で実行されるため、
Excelのようにアプリ画面を直接操作することはできません。
ただし、GASでも HtmlService を使うことで、
- サイドバー
- ダイアログ
- HTMLベースの入力画面
といった UI（画面）を作成することは可能です。
この場合、
- 画面（HTML + JavaScript）
- 処理（GAS側の関数）
を分けて設計し、
ユーザー操作をきっかけに処理を実行する構成になります。
そのため、VBAからGASへ置き換える際は、
「画面を使う／使わない」ではなく、
「Excel画面に依存した処理か、UIと処理を分離した構成か」
という違いとして整理する方が、実態に近いと感じました。
データ操作の考え方は大きく変わる
VBAでは、
セルを1つずつ読み書きしても問題にならないケースが多くあります。
一方、GASでは、
- スプレッドシートとの通信回数
- 実行時間の制限
といった制約があるため、
データを配列としてまとめて取得し、まとめて処理する
書き方が基本になります。
この点は、
VBA経験が長いほど最初に戸惑いやすい部分です。
実行タイミングの違いを整理する
VBAでは、
- ボタンを押す
- ファイルを開く
といった操作を起点に処理が実行されることが一般的です。
GASでは、
- スプレッドシートのメニューから実行
- トリガーによる定期・自動実行
- UI（サイドバーやダイアログ）からの実行
など、
実行の入口が複数存在します。
VBAと同じ感覚で移行すると、
「いつ処理が動くのか分かりにくい」
と感じる原因になるため、
実行タイミングの整理が重要になります。
すべてをGASに置き換える必要はない場合もある
VBAで作られた処理の中には、
- 手動でも十分対応できるもの
- GASにしても運用が楽にならないもの
が含まれていることもあります。
そのため、
VBAをそのまますべてGASに移す
のではなく、
GASに置き換える意味がある処理を切り分ける
という考え方も、
検討時の整理として有効だと感じました。
おわりに
VBAからGASへの置き換えは、
単なるコード変換ではなく、
前提や構成を整理し直す作業に近い印象でした。
特に、
オンライン前提かどうか、
画面操作の考え方、
実行環境の違いといった点は、
事前に整理しておかないと見落としやすい部分です。
同様の検討を行う際の整理資料として、
参考になれば幸いです。
コメント