DXの入口として勧められるGoogle Workspace
中小製造業のDXを検討していると、「まずはGoogle Workspaceを導入しましょう」という提案に出会うことが多い。メール、カレンダー、ファイル共有、表計算がすべて一つのサービスで揃い、月額数百円から始められる。確かに入口としてはわかりやすい。
自分は「機能だけ借りて、データは手元に持つ」という使い方をしてきた。ただ、検討した上でGWSに全面的に乗るのも一つの選択肢になりうる。この記事では、どちらを選ぶにしても知っておきたい判断材料を整理したい。
全部入りの手軽さは本物
Google Workspaceは「全部入り」のサービスだが、中小製造業の現場で日常的に使われるのは、だいたい次の五つに絞られる。
- Gmail： メールの送受信と、迷惑メールフィルタ
- Googleカレンダー： スケジュール共有
- Googleドライブ： ファイルの保管と共有
- Google Meet： リモート会議、拠点間の打ち合わせ
- Google Chat： 社内のチャット連絡
全部の機能を使いこなしている会社は少ないだろう。ただし、使わない機能があるから無駄かというと、そうでもない。メールはレンタルサーバー、カレンダーはサイボウズ、ファイル共有はNAS——と個別に手当てすれば、それぞれに契約・管理・保守の手間がかかる。GWSなら1つのアカウントでメール・カレンダー・ファイル共有が揃い、管理も一元化される。月額数百円でこれが全部入りなら、バンドルとしてのコスパは悪くない。
ただし、この「手軽に全部揃う」便利さが、後述するロックインの入口にもなる。
見落とされる長期コスト
Google Workspace Business Starterは1ユーザー月額680円。安く感じるが、これは積み上がる。
社員20人の会社なら、680円 × 20人 × 12ヶ月 = 年間163,200円。5年で約80万円、10年で160万円を超える。これは「全員がメールとカレンダーを使っているだけ」の費用になる。
コスト差が決定的というわけではないが、「クラウドの月額課金は永遠に続く」という点は意識しておく必要がある。
本当のリスクはコストではない
コストよりも深刻なのは、データの主権の問題になる。
Google Workspaceにデータを蓄積するということは、自社の業務データをGoogleに預けるということ。「預ける」という表現は上品すぎるかもしれない。実態としては、Googleの規約とインフラの上にデータが存在し、Googleのさじ加減一つでアクセスできなくなるリスクを負うということになる。
実際に起きている事象として：
- アカウント停止のリスク。 Googleの規約違反と判定されると、アカウントが停止される。法人アカウントでも例外ではない。停止されると、メール、ドライブ、カレンダーのすべてに一切アクセスできなくなる
- 復旧の困難さ。 問い合わせ窓口はbot対応が中心で、人間の担当者に辿り着くまで時間がかかる。中小企業には専任の法務もいない。停止期間中、業務は止まる
- 料金改定の一方的な通告。 Googleは過去に何度も料金を引き上げている。ストレージの無料枠の縮小やAPIの仕様変更も、利用者への事前相談なく行われる
ローカルにデータがあれば、HDDが壊れてもRAIDやNASのバックアップから自分の意思で復旧できる。しかしクラウドのアカウントが停止された場合、自分では何もできない。この非対称性が最大のリスクになる。
ただし、ローカルなら安全かといえば、そう単純でもない。ランサムウェアに感染すれば、ローカルのデータもネットワーク上のNASも丸ごと暗号化される。バックアップを取っているつもりで、実際には復元できる状態になっていない会社も少なくない。ローカル環境を維持するには、バックアップの運用と検証を継続的にやる必要があり、その手間は決して軽くない。
→ 中小製造業のセキュリティは「守り方」より「戻し方」
→ 中小製造業のDXとランサムウェア ── 便利にした分だけ攻撃面が増える
クラウドにもローカルにも、それぞれ違う性質のリスクがある。大事なのは「どちらが安全か」ではなく、リスクの中身を理解した上で使い分けることになる。
段階的にロックインされる構造
意識しておくべきなのは、便利に使えば使うほど抜け出しにくくなる構造があること。これはGWSに限らず、クラウドサービス全般に共通する話になる。
最初はメールとカレンダーだけ使う。この段階なら乗り換えは簡単。次にGoogleドライブにファイルを蓄積し始める。これもまだ頑張ればデータを移行できる。
問題はその次。Googleスプレッドシートに業務ロジックを載せ始めると、状況が変わる。関数やGoogle Apps Script（GAS）で集計処理を組み、Google Formsで入力を受け付け、GASで通知を飛ばす——こうなると、業務フロー全体がGoogle前提で構築される。
この段階で「やっぱりローカルに戻そう」と思っても、データはエクスポートできるが、業務ロジックはエクスポートできない。GASで書いた処理はGoogle環境でしか動かない。業務フローを一から組み直す必要がある。つまり、移行コストが残留コストを上回り、事実上のロックインが完了する。
GASやスプレッドシートの機能自体が悪いわけではない。開発プラットフォームとしてのExcel VBAとの得意・不得意の違いは、別の記事で詳しく書いた。
併用という現実解
自分がやってきたのは、機能だけ借りてデータは手元に持つ併用になる。GWSに全面的に乗る選択を否定はしないが、機能とデータは分けられるという点は知っておいて損はない。
たとえばGASのトリガーが便利だからといって、処理するデータ本体までスプレッドシートに置く必要はない。トリガーで起動してローカルのデータを処理する、あるいはトリガーで通知だけ飛ばしてデータ処理はローカルで行う、といった分離は十分に可能になる。
データの置き場所を意識的に決める
結局のところ、重要なのは何をどこに置くかを意識的に決めることだと思っている。
外に預けていいもの： メールのやりとり、スケジュール、一般的な社内連絡。これらは最悪失っても業務が止まるわけではない。
手元に持つべきもの： 見積データ、受注履歴、原価情報、顧客情報、図面。これらは自社の業務の根幹であり、消失したら事業が止まる。アカウント停止や規約変更で突然アクセスできなくなるリスクに晒すべきではない。
この線引きができるかどうかが、Google Workspaceを「道具として使う」か「依存する」かの分かれ目になる。
道具は「借り物」か「持ち物」か
クラウドサービスは本質的に「借り物」になる。便利だが、貸主の都合で条件が変わる。料金が上がる、仕様が変わる、最悪の場合はアクセスを止められる。
ローカルの環境は「持ち物」になる。メンテナンスは自分でやる必要があるが、誰かの都合で突然使えなくなることはない。
自分は「機能だけ借りてデータは手元に持つ」というやり方をしてきた。ただ、GWSの手軽さや管理の一元化を重視して全面的に乗る選択も、トレードオフを理解した上でなら間違いではない。
大事なのは、何も考えずに流されることではなく、自社のデータがどこにあり、何に依存しているかを把握した上で選ぶこと。その判断ができていれば、GWSに全面的に乗っても、部分的に借りても、リスクは管理できる。
このシリーズの他の記事：